6 Vorschläge, wie Sie Ihre Prozesse von der Anforderung zur Bereitstellung verbessern
„Neues Jahr, neues Ich!“ Wobei „ich“ hier nicht wörtlich gemeint ist: Die Aussage ist nicht von mir, ich bin nämlich kein großer Freund willkürlicher Vorsätze.
Tatsächlich hat das aber jemand aus meinem Team vor ein paar Tagen gesagt, wenn auch eher mit einem Seufzer als mit einem begeisterten Ausrufezeichen. Trotzdem, der Inhalt der Aussage war aufrichtig gemeint.
Keine Frage, der Beginn eines neuen Kalenderjahres ist für viele ein Ansporn, Dinge zu ändern. Im Sinne von Selbstevaluierung und Veränderung zum Besseren möchte ich Ihnen hier 6 Best Practices vorschlagen, mit denen Sie 2020 Ihre Change- und Release-Management-Prozesse in SAP verbessern können.
Lassen Sie Ihre Entwickler Verantwortung übernehmen
In einem ersten Schritt sollten Sie sich fragen, wie Sie dafür sorgen können, dass die Verantwortung für Qualität so weit links wie möglich im Software-Entwicklungslebenszyklus angesiedelt ist. Lassen Sie Ihre Entwickler die Verantwortung dafür übernehmen. Und wenn es sein muss, bringen Sie sie dazu.
Es hat enorm viele Vorteile, wenn Sie die Dinge von Anfang an (so weit wie möglich) richtig machen: Sie verhindern unter anderem technische Fehler, verringern den Testaufwand, verkürzen die Zyklen von der Entwicklung bis zur Lieferung und sparen sich unnütze Überarbeitung von Software-Code. All das schlägt sich in kürzeren Bereitstellungszeiten und weniger Produktionsproblemen nieder – und viel mehr interessiert das restliche Unternehmen, wenn man ehrlich ist, ja auch gar nicht.
Wie können Sie das nun erreichen? Da gibt es eine ganze Reihe von Möglichkeiten. Ein guter Anfang sind einfache Peer-Reviews: das heißt, dass die Ideen hinter jedem neuen Code-Abschnitt gemeinsam besprochen werden. Auch Unit Tests sind hilfreich, und so weiter bis zum echten DevOps-Ansatz, der in der Regel funktionsübergreifende Teams und die „Shift Left“-Methode als zentrale Elemente umfasst.
Egal, für welches Vorgehen Sie sich entscheiden: Change- und Release-Automatisierung ist dafür zwar keine Voraussetzung, aber in jedem Fall hilfreich. Mit den Worten eines unserer Kunden, Honda Europe: „Entwicklern stehen heute beinahe alle [Qualitäts-]Analysetools […] in der Entwicklungsumgebung zur Verfügung. Sie können sich also später nicht gegenüber dem Wartung-Team beklagen, dass ihnen keine Fehler bekannt gewesen wären.
Legen Sie Ihre Arbeitsabläufe und Verantwortlichkeiten fest
Vielleicht halten Sie diesen Vorschlag für eine Selbstverständlichkeit: So gibt es doch sicher in jedem Unternehmen klare Vorgaben, wer was in welchen SAP-Systemen genehmigen darf und welche Kriterien dabei gelten. Tja – könnte man meinen, ist unserer Erfahrung nach aber tatsächlich nicht der Fall.
Warum das so ist, ist durchaus nachvollziehbar: Häufig sind Änderungen ausschließlich irgendwo in langen E-Mail-Konversationen und Spreadsheets festgehalten, die sich nur schlecht nachverfolgen und noch schlechter analysieren lassen. Außerdem laufen womöglich verschiedene BAU- und Projektentwicklungen parallel mit unterschiedlichen Ownern. Bei Hotfixes und Sicherheitsproblemen schließlich kann nicht abgewartet werden, bis bestimmte Mitarbeiter im Büro sind. Sind alle Genehmigungen von derselben Person abhängig, oder gibt es unterschiedliche Prozesse für die einzelnen Elemente?
Vermutlich haben Sie diese Fragen in Ihrem Unternehmen bereits geklärt. Falls nicht, ist jetzt möglicherweise der richtige Zeitpunkt dafür. Es wird unter Umständen nicht ganz einfach – insbesondere, wenn die Leute in Ihrem Team es gewöhnt sind, selbst zu entscheiden, wann und wie sie ihre Arbeit erledigen –, aber es lohnt sich: Letzten Endes werden Änderungen besser umgesetzt und der Prüfprozess – dieser leidige Zeitfresser – erheblich vereinfacht.
Ein weiterer Kunde von Basis Technologies, der britische Einrichtungshändler Dunelm, hat ein solches Unterfangen während eines großen SAP-Transformationsprojekts mit Hilfe von Change- und Release-Automatisierung unterstützt: „[Wir] mussten verstärkte Governance um unsere Prozesse herum einführen, um zu verhindern, dass unsere Entwickler einfach etwas entwickeln, in Transporte verschieben und Änderungen im QA-System vornehmen. Um einen ordnungsgemäßen Zugriff der Entwickler sicherzustellen, haben wir darum neue Rollen entwickelt.“
Vergessen Sie Nachtarbeit und machen Sie „9 to 5“ zur Regel
Für viele SAP-Teams sind Änderungen außerhalb der üblichen Bürozeiten der Normalzustand. Es gilt als selbstverständlich, dass die Mitglieder des Teams abends und am Wochenende zur Verfügung stehen – weil geschäftskritische Systeme nun einmal nicht während des Bürotags geändert werden dürfen. Warum? Die ehrliche Antwort: Weil tatsächlich zu oft etwas schief geht.
Natürlich gibt es Situationen, in denen eine Bereitstellung außerhalb der Arbeitszeiten sinnvoll ist, etwa während eines wichtigen Projekt-Cutovers. Aber in den meisten Fällen können SAP-Änderungen sicher und unkompliziert innerhalb der normalen Bürozeiten bereitgestellt werden. Gegebenenfalls müssen Sie allerdings Ihre Arbeitsweisen ändern.
Hier kommen auch die oben genannten Vorschläge ins Spiel, da sie helfen, Produktionsprobleme zu reduzieren. Der entscheidende Faktor in diesem Zusammenhang ist allerdings Automatisierung: On-Demand-Bereitstellung anstelle langer Releasezyklen minimiert Risiken, automatisierte Sequenzierung und Bereitstellung lässt Ihrem Team mehr Zeit für andere Aufgaben, und die Möglichkeit, Änderungen praktisch sofort rückgängig zu machen, wenn Probleme auftreten, sorgt für mehr Vertrauen – um nur einige Beispiele zu nennen.
Letztlich ist Change- und Release-Automatisierung nicht nur vorteilhaft für die Unternehmensbilanz, sondern trägt auch dazu bei, dass SAP-Teams zufriedener und produktiver arbeiten. Das klingt jetzt übertrieben? Nicht, wenn es nach unseren Kunden geht:
„Mein jüngerer Kollege und ich mussten uns immer nachts Zeitfenster für den manuellen Import genehmigter Transporte freihalten … Die Belastung für unser Team war klar höher.“
„[Ohne ActiveControl] dauert es wirklich Stunden, um Änderungen vorzunehmen. Das verärgert die Mitarbeiter, die nachts aufbleiben müssen. Aber nicht nur das: Bei Problemen wird der Konfigurationsmitarbeiter angerufen, es muss alles neu gepackt werden, der Basisberater muss ebenfalls wach sein, kurz: Alle werden gestört. [Mit ActiveControl] fällt das alles weg.“
Gründen Sie Ihre Entscheidungen auf Daten
Es ist nicht einfach, Änderungen in komplexen SAP-Systemen fehlerfrei bereitzustellen. Aber für das Geschäft ist es extrem wichtig, dass SAP ordnungsgemäß funktioniert, und Fehler können sehr teuer werden.
Vor diesem Hintergrund ist es erstaunlich, dass so viele SAP-Teams nach wie vor auf manuelle Methoden und menschliche Erfahrung setzen, obwohl nützliche Technologien zur Verfügung stehen. Bei Spreadsheet-basierten Change- und Release-Prozessen werden Bereitstellungen leider nur zu oft anhand der angenommenen Auswirkungen genehmigt, anstatt eine empirische Analyse der tatsächlichen Auswirkungen zu berücksichtigen.
Die Best Practice besteht hier klar darin, datengestützte Entscheidungen über die Bereitstellung auf Grundlage einer technischen Analyse des Codes und der Transporte vorzunehmen. Die Bandbreite reicht von wichtigen, aber nicht wesentlichen Problemen wie der Code-Qualität bis zu kritischen Fragen wie der Ermittlung von Objekten mit hohem Risiko und Abhängigkeiten zwischen oder innerhalb von Systemen bei den einzelnen Transporten.
Sie ahnen vermutlich schon, was jetzt kommt – Richtig: Automatisierung ist – insbesondere bei großen Änderungsvolumen – die einzige Möglichkeit, datengestütztes Change- und Release-Management praktisch umzusetzen. Es ist mit manuellen Methoden schlicht nicht möglich, die erforderliche Analyse schnell und umfassend genug durchzuführen.
Ein weiterer Kunde von Basis Technologies hat das sehr anschaulich zusammengefasst: „ActiveControl hat in nur 5 Minuten das geschafft, wofür wir gestern einen ganzen Arbeitstag mit manuellen Analysen gebraucht haben.“
Hören Sie auf zu sagen: „So haben wir das schon immer gemacht“
Ich weiß, dass Sie das wahrscheinlich sehr ungern lesen, aber es muss einfach gesagt werden: SAP ist wirklich nicht so besonders.
Natürlich muss man anerkennen, dass SAP architektonische Eigenheiten hat. Das heißt, dass manches in den letzten Jahren anders gehandhabt werden musste als in anderen IT-Anwendungen. Es müssen Transporte berücksichtigt werden, gemeinsame Entwicklungsumgebungen, eigene Tools, die Kritikalität der Systeme usw.
Aber die Zeiten haben sich geändert, und heute lassen sich mit modernen Entwicklungsverfahren wie agiler Entwicklung oder DevOps selbst traditionelle ABAP-Stack-Systeme verwalten. Wenn wir SAP-Anwendungen effizienter betreiben und einen höheren Mehrwert für unser Unternehmen erzielen möchten, dann reicht es nicht zu sagen: „Aber wir haben das immer so gemacht!“ Oder, wie es ein Vertreter des Basis Technologies-Kunden Interpublic Group ausdrückt: „Die Leute glauben, dass agile Entwicklung und DevOps nicht für ERP geeignet sind. Das ist ein Mythos. Es ist möglich, [aber] es ist ein weiter Weg.“
Jetzt ist der richtige Zeitpunkt zu überlegen, wie Sie Dinge ändern können. Sprechen Sie mit Ihren Kollegen außerhalb des SAP-Teams. Schauen Sie sich neue Tools und Technologien an. Gehen Sie Schritt für Schritt vor, aber fangen Sie jetzt an, Ihren Änderungsplan für 2020 zu erstellen.
Setzen Sie auf Change- und Release-Automatisierung
Wenn Sie bis hierhin gelesen haben, wird Sie die letzte Empfehlung kaum überraschen: Die Automatisierung des Change- und Release-Managements ist ganz ohne Frage eine Best Practice – aus allen oben genannten und vielen weiteren Gründen.
Sie möchten mehr darüber erfahren, wie ActiveControl die Verwaltung Ihrer SAP-Systeme verändert? Dann vereinbaren Sie einen kostenlosen Demo-Termin mit unseren SAP-Experten.
