Philosophie

“Culture eats strategy for breakfast”

Peter Drucker

Eine ChaRM-Einführung bedeutet immer einen Kulturschock. Die wohl größte Herausforderung einer ChaRM Implementierung ist daher die notwendige Veränderung der Mentalität bei den Beteiligten.

Kulturschock

Zunächst reagieren die alten Haudegen mit Schock, gehen dann in eine ignorierende Haltung über und versuchen, wie bisher an den Transporten herumzuschrauben – genau das versucht aber der ChaRM zu unterbinden.

Es gibt Konflikte und Schuldzuweisungen an den ChaRM, der wie ein enges Korsett empfunden wird. Auch kommen Selbstzweifel hoch.

Doch nach einer Gewöhnungsphase macht sich Akzeptanz breit, man beginnt, die neue – anfangs unheimliche – Strukturiertheit des Änderungsprozesses zu schätzen, findet Gefallen am Komfort der mächtigen Werkzeuge, die man langsam für sich entdeckt, um schließlich erfreut den positiven Sprung bei der eigenen Produktivität anzuerkennen. Manuelle Pflege von Transportlisten für die Revision war gestern. Der ChaRM vergisst nichts. Aufwändige Kommunikation zwischen Entscheidern, Entwicklern, Testern und Operatoren ist obsolet geworden.

Einzeländerung

Die meisten ABAP Entwickler und Customizer sind Artisten der Einzeländerung, sie jonglieren mit den Transportobjekten in „ihren“ Transporten und verbringen viel Zeit mit der Analyse der richtigen Importreihenfolge, um schließlich akrobatisch Transporte ein- oder auszuplanen.

Irgendwann verknotet sich das Ganze derart, dass man sich gezwungen sieht, das Entwicklungssystem per Systemkopie dem Produktivsystem wieder anzugleichen.

Das SAP-ABAP Transportwesen folgt hingegen seit R/3 Einführung einem industriellen Paradigma. Alles was im Startsystem automatisch aufgezeichnet wird, muss in identischer Reihenfolge bis zum Zielsystem durchtransportiert werden. Keine Ausnahmen: Möchte man eine Änderung zurücknehmen, so muss man diese und ihre Löschung durchtransportieren. Der ChaRM folgt diesem Paradigma und verstärkt es.

Das muss erstmal sacken. Denn das Denken in Einzeländerungen ist sehr zäh.

Phasen

Ein Aspekt der Einzeländerung ist die besonders hartnäckige Gewohnheit, die „eigene“ Änderung sofort nach erfolgreichem Funktionstest produktiv setzen zu wollen. Man vergisst dabei gerne, dass jeder Import von Workbench-Objekten das Produktivsystem stresst. Anfangs reagiert man allergisch auf die Einführung von Änderungszyklen mit Phasen, weil sie ein gemeinsames Vorgehen erzwingen: Bei der Test-Phase wird gemeinsam getestet, in der Go-Live Phase wird alles was getestet wurde, gleichzeitig in das Produktivsystem importiert.

Doch in den Phasen steckt eine Weisheit, die beim Testen sichtbar wird.

Test-Phase

Nachdem ein Fehler die Neu-Inventarisierung des Stockholmer Hochregallagers erzwungen hat und man wegen des wochenlangen Ausfalls seinen besten schwedischen Kunden verloren hat (ist echt passiert!), macht man sich Gedanken, ob der alte Witz, dass der echte Test sowieso erst im Produktivsystem erfolgt, nicht doch ziemlich blöd sei, und man beginnt – ganz gebranntes Kind -, den nicht unerheblichen Aufwand von Integrations- und Regressionstests mit dem Risiko eines heftigen Umsatzrückgangs ernsthaft abzuwägen.

Integrations- und Regressionstests

Diese überlebenswichtigen Tests haben aber eigene Regeln, die der ChaRM mit der Test-Phase unterstützt: In dieser Phase (und auch in der Go-Live Phase) können keine weiteren Transporte mehr freigegeben und in das QA-System importiert werden. Denn jeder Import nach dem Beginn dieser Tests würde die Ergebnisse der bereits ausgeführten Testskripte invalidieren; man müsste sie wiederholen (im validierten Umfeld wird das gesetzlich erzwungen).

Übrigens, nur in diesen zwei Phasen hat der Hotfix seinen Sinn. Da er einen eigenen Aufgabenplan hat, kann er trotz Export-Import Sperre eine Notkorrektur produktiv setzen.

Auch hier wirft das Denken in Einzeländerungen seinen üblen Schatten. Wird in der Test-Phase ein Fehler gefunden, so sucht man gleich das Änderungsdokument, das daran schuld gewesen sein muss. Oft werden viele neue Status angelegt, um diese Identifizierung zu erleichtern.

Man vergisst bei diesem Tunnelblick auf das einzelne Änderungsdokument, dass man während der Test-Phase nicht mehr in die Richtung der Entwicklung schaut, um möglichst viele Fehler korrigieren zu lassen, denn die Fehlerfreiheit einer neuen oder geänderten Funktion wurde ja bereits vom Einzeltester bestätigt.

Nein: Während der Integrations- und Regressionstests, bei denen die E2E-Prozesse durchgetestet werden, dreht man sich um 180° und schaut jetzt in die Richtung der Produktion. Ziel ist es jetzt, dem Business zu beweisen, dass der nächste Go-Live funktional vollständig und fehlerfrei sein wird (hörte ich hier homerisches Lachen ausbrechen?).

Testmeldung

Sollten in der Test-Phase dennoch Fehler auftauchen, die nur durch eine Korrektur behoben werden können, so sind das Seiteneffekte; es hat keinen tieferen Sinn, sie einem Änderungsdokument zuzuordnen.

Um trotzdem einen importierbaren Korrektur-Transport erzeugen zu können, gibt es die nette kleine „Testmeldung“ (alt: SDMT, neu SMTM), die ohne Zuordnung zu einem Änderungsantrag extra zum Korrigieren und Nachtesten angelegt wird. Dessen Korrekturtransporte werden beim späteren Go-Live automatisch mit importiert.

Go-Live Phase

Der Hauptvorteil einer Go-Live Phase mit dem Massenimport der getesteten Änderungen ist, dass das Produktivsystem nur ein einziges Mal gestresst wird. Wenn man diesen Zyklus-Import zu regelmäßigen Terminen durchführt (z.B. jeden Mittwoch um 11:00), wird dieser Zeitpunkt wohlbekannt und das Business reagiert nicht mehr mit Panik, wenn es mit Abbrüchen wegen veralteter Ladephasen konfrontiert wird.

Aufwiedersehen

Ich hoffe, dass man, wenn man dieses zugegebenermaßen etwas längere Kaffeekränzchen verlässt, die Frage „ChaRM, warum, weshalb, wieso? – Ein kurzer Abriss eines ALM-Enthusiaten “ nicht mehr zu stellen haben wird.