ChaRM: Wie alles begann!

In unserer unserer dreiteiligen Sommerblog-Serie geht es um das Change Request Management (ChaRM) im SAP Solution Manager. 
Wie kam SAP überhaupt auf die Idee, sowas wie ChaRM zu etablieren? Was stekt technisch und was ist die Philosphie dahinter? All das erfahrt ihr in meiner dreiteilen Sommerblog-Serie.

Geschichte

Wenn man nach so viel Jahren tief in die Vergangenheit eintaucht und sich die Dokumente der Anfänge anschaut, staunt man, wie enorm das Change Request Management (ChaRM) im SAP Solution Manager im Laufe der Jahre gewachsen ist. Ich kenne kein Werkzeug für die Verwaltung von Änderungen, das so mächtig und perfekt mit anderen integriert ist:

• Komfortable Orchestrierung der SAP-Transporte
• Umfangreiche Überprüfungen der Transporte und dessen Inhalte (kritische Transportobjekte, systemübergreifende Sperren, Downgrade-Schutz, Querverweisprüfung usw.)
• Unterstützung dualer Systemlandschaften mit Retrofit und Cutover (Focused Build Extentions)
• Mächtige Suchfunktionen, bis hinunter auf einzelne Transportobjekte
• Releasemanagement mit minor und major Releases
• Bidirektionale Integration mit dem SAP-Projekt und -Portfoliomanagement inklusive der aggregierten Rückmeldung der Zeiterfassung.
• Umfangreiche Integration mit der Test Suite
• End-to-End traceability
• Integration mit der Lösungsdokumentation
• Integration mit dem Incident und Problemmanagement
• Integration mit der Jobverwaltung
• Integration mit den System Recommendations
• Integration mit dem IT Kalender

Integration, wohin das mittlerweile feuchte Auge nur blickt 🙂

Tragezeit und Geburt

Anfang der Nuller Jahre sprossen in unserem Unternehmen R/3 Systeme wie Pilze aus dem Boden. Jedes Werk hatte seins, die Zentrale auch. Die Verwaltung der Transporte per STMS wurde zeitaufwändig. Wir stellten ein zentrales System TSM (unser erstes Testsystem für den SAP SolutionManager, Version 2.2) auf, um mit dem TMS Transport Workflow die Transporte zu verteilen. Wir wollten aber auch die TMS QA Approval einführen. Doch der TMS Workflow ignorierte die QA. Eine Meldung bei SAP bewirkte nur die Anlage eines Hinweises, mit dem SAP deklariert: Ist halt so, peng!

Brav gab ich bei SAP einen Erweiterungsantrag ab. Anfang 2004 kündigte Michael D. (SAP) seinen Besuch an, um sein Projekt „Venice“ vorzustellen. Motto: Es sei alles vorhanden, um ein Change Management Werkzeug zu entwickeln (cProject, Solution Manager for Implementation, Transport Management System, SMSY), man muss es nur verknüpfen.

Wir wurden Pilotkunden.

Es war dies die Geburt des ChaRMs, der erstmals als Addon TMWFLOW zum Solution Manager 3.2 ausgeliefert wurde und daher eigene, häufiger ausgerollte Support Packages hatte. Mit Solution Manager 4.0 wurde er Teil von ST.

Übersicht

Statt alles mit einer einzigen Monster-Transaktion zu erschlagen, besteht der ChaRM aus einzelnen spezialisierten CRM „Vorgangsarten“, die mit vier Buchstaben identifiziert werden.

Änderungsantrag

Eine Änderung startet mit einem Änderungsantrag (alt SDCR, heute SMCR), entweder durch Neuanlage oder als Folgebeleg eines Problems; er ist der Ort der betriebswirtschaftlichen Klärung, und dessen Genehmigung legte anfangs genau ein Änderungsdokument als Tochterbeleg an, mit dem man die technischen Änderungen (Transporte) steuerte; erst mit 7.1 wurde es möglich, mehrere Änderungsdokumente zu einem Antrag anzulegen.

Mit dem Releasemanagement kam noch die Geschäftsanforderung (SMBR) hinzu; sie bietet dem Business die Möglichkeit, eine Anforderung intern zu bewerten (passt sie in unsere Strategie? Ist Budget vorhanden?) und zu genehmigen, bevor sie an die IT übergeben wird.

Dabei entsteht als Folgedokument die IT-Anforderung (SMIR); erst wenn der Change Manager diese genehmigt, entstehen Änderungsdokumente wie beim analogen SMCR.

Änderungsdokumente

Aus den anfänglichen vier Änderungsdokumenten sind es mittlerweile sieben geworden. Hier eine kommentierte Liste (die ursprünglichen in Klammern):

• (SDMI) SMMJ: normale Korrektur, kann sich in eine dringende mit Vorabimport verwandeln.
• (SDHF) SMHF: dringende Änderung (aka Hotfix), anfangs sehr beliebt, doch heute sollte sie nur in Ausnahmefällen verwendet werden, bei denen eine Korrektur wie mit Sirene und Blaulicht Richtung Produktion rast.
• (SDAD) SMAD: administrative Änderung, ohne Transporte, dient der revisionssicheren Dokumentation von Änderungen an den Systemen eines Transporttracks wie z.B. Mandantenöffnung.
• (SDMT) SMTM: Testmeldung, dient der Fehlerkorrektur während des Testens (s.u.).
• SMCG: generische Änderung; ist völlig losgelöst vom Transportsystem und dient der ITIL konformen Dokumentation von Änderungen an Configuration Items (CI) oder bei der Freigabe von SolDoc Elementen unter Change Control.
• SMSG: Standardänderung; mit ihr kann ein Key User oder Business Experte ohne fremde Hilfe Änderungen am Produktivsystem vornehmen, die in seiner Verantwortung liegen, für die aber der Transportanschluss zwingend ist (Beispiele: ein Logistiker ändert Verkehrsträger, eine Einkäuferin legt neue Lieferantengruppen an)
• SMGH: Git-fähige Änderung. Der neueste Spross aus der Familie. Dient der Steuerung via ChaRM des gCTS, das mit SAP S/4HANA 1909 eingeführt wurde.

Probleme

Wie bei jeder Geburt gab es Nachwehen. Hätten Sie etwas anderes erwartet?

Asynchroner Export

Mit einem Problem hat der ChaRM seit allem Anfang zu kämpfen, dass nämlich der Export eines Transportes durch das Betriebssystem-Programm tp prinzipiell asynchron abläuft.

In der SE09 tut das nicht so weh, denn ein Export gibt sofort die Sitzung wieder frei, und statt immer den „Refresh“ Knopf zu drücken, kann man einfach etwas anderes machen.

Der ChaRM hingegen friert die Sitzung ein und zeigt eine nette animierte GIF (aus der Sanduhr der SAP Gui ist der Donut of Death der CRM WebUI geworden). Standardgemäß wartet der ChaRM 120 Sekunden auf das Ende vom Export, doch man kann mit dem User-Parameter CHECK_NTIMES_SOCM diese defaultmäßige 24 mal 5-Sekunden Warte-Einheiten erhöhen. Setzt man den Parameter mit der Transaktion SU3 zum Beispiel auf 50, dann würde der ChaRM maximal 250 Sekunden auf das Ende des Exportvorgangs warten.

Error absconditus

Das vielleicht größte Ärgernis im ChaRM war (und teilweise ist), dass der ChaRM ein ziemlich stummer Kellner ist, der die Probleme aus der Küche des Transportwesens (CTS) einfach nicht dem Kunden direkt kommuniziert, der daher an der schnöden Meldung „Status konnte nicht gesetzt werden“ schier verzweifeln kann. Denn die echte Fehlermeldung aus dem CTS ist tief im Monitor des Aufgabenplans oder im Anwendungslog (SLG1) versteckt.

Hier das Mitgefühl erregende Beispiel eines Kollegen, der – vielleicht weil sehr erfahren – sehr hartnäckig versuchte, den Statuswechsel auf „ToBeTested“ mit impliziter Transportfreigabe zu setzen.

Nachdem dem alten Haudegen die Seele vor Flüchen kochte, wendete er sich endlich an den ChaRM Experten. Dieser ist dann über eine Aktion in den Aufgabenplan navigiert und hat – nach mehreren Doppelklicks – die banale Fehlermeldung „Request/task C11K9A043A is not completely locked“ ans Licht des Tages gebracht.

Dieser Weg zur echten CTS Fehlermeldung war dokumentiert, aber welcher Entwickler liest denn schon Doku?

Auch heute, mit SolMan 7.2, tun sich immer noch Anwender schwer, die Transport-Fehler im Assignment Block „Application Log“ aufzuspüren, die immer noch ziemlich gut versteckt sind.

ChaRM, wir müssen reden

Die zwei Winde, die auf dem ersten Bild auf Aphrodite pusten, sind Gerhard B. von der Nordmilch AG und meine Wenigkeit, die dem ChaRM Wind machen.

Bei einem Treffen der DSAG AG Solution Manager wurden wir uns nämlich rasch über die vorhandenen Lücken einig und haben September 2007 die Workforcegruppe „Fehlerprotokollierung“ gegründet, die wir Dezember 2007 in Workforce „ChaRM Ergonomie und Stabilität“ umbenannten – der Name sagt schon alles.

Wir sammelten viele kundeneigene Entwicklungen als Anforderungsliste und haben diese Februar 2008 im Rahmen der DSAG Technologietage in Dresden vorgestellt und Herrn Matthias M. (SAP) übergeben.

Die Liste ist vermutlich in einem Schubfach in St. Leon-Rot verschwunden, denn es tat sich – nichts. Erst mit Solution Manager 7.1 und 7.2 gab es endlich substanzielle Verbesserungen.

Aber immerhin war es der Anfang eines jahrelangen Engagements im Rahmen der DSAG, um den ChaRM (und auch die Test Workbench) verbessern zu helfen.

Im zweiten Teil der Blogserie schauen wir dem ChaRM tiefer unter die Haube.