Offensive ChaRM

Mit Version 7.2 des s ändert SAP einiges auch im Change Request Management, vor allem in der Verknüpfung von Change Requests mit der Dokumentation.

Dies war bislang immer ein wunder Punkt, wenn ich mit Kunden über das Change Management und auch die Verwaltung der damit verbundenen Dokumentation gesprochen habe.

Eine ChaRM-Einführung macht definitiv Sinn, muss aber auch gut geplant sein. Es ist unmöglich, das sozusagen als U-Boot in der SAP-Basis zu lancieren und dann irgendwann auftauchen zu lassen.

Da das Change Management alle Disziplinen von der Antragsstellung bis hin zur Produktivsetzung über einen Workflow abbildet, sind natürlich auch verschiedene Bereiche in der IT bis hin zur Fachabteilung involviert.

Der erste Schritt beginnt mit einer wesentlichen Zielsetzung. Warum will eine IT-Abteilung überhaupt das Change Request Management einführen?

Was sind die damit verbundenen Ziele? Ich habe die letzten Jahre hier ein ganzes Portfolio an Zielen erlebt. Von der Vermeidung von Medienbrüchen bis zum Thema regulatorische Anforderungen sind viele Ziele legitim.

Wichtig ist jedoch diese Vorgabe, idealerweise verbunden mit Leitplanken, da man sich bei einer späteren Diskussion über Prozesse und Abläufe immer wieder vor Augen halten kann, wie viel die verschiedenen Varianten zum Ziel beitragen.

Die ChaRM-Einführungen, die einfach ein bestehendes Tool – und sei es ein Excel auf einem Windows Share – ablösen, sind meist zum Scheitern verurteilt. Mit einer ChaRM-Einführung sollte man auch bestehende Verfahrensweisen diskutieren.

Wichtig ist also, ein Konzept der Abläufe zu erarbeiten. Sogenannte ChaRM-Prototypen, die dann auf einer produktiven Systemlandschaft nach Abschluss des Grundcustomizings zum Einsatz kommen, halte ich für wenig zielführend, da hier meist auf Abläufe und Dokumentation verzichtet wird.

Erst wenn das Konzept steht, ist eine Umsetzung sinnvoll. Hierbei sollten zur Erstellung insbesondere folgende Punkte betrachtet und detailliert werden:

• Welche Change­Prozesse für SAP-Änderungen existieren aktuell?
• Wie soll künftig eine Softwareänderung dokumentiert werden?
• Wie sehen die Ziellandschaften aus?
• Wie wird mit der systemübergreifenden Objektsperre umgegangen?
• Wie werden Anforderungen beschrieben und von wem werden diese genehmigt und geplant?
• Ist ein Releasemanagement gewünscht?

Es existieren also jede Menge offene Punkte, die auch sicher nicht in einem Workshop geklärt werden können. Vielmehr erfordern diese auch innerhalb einer IT eine lebendige Diskussion.

Da IT-Prozesse auch nicht basisdemokratisch definiert werden können, ist hier eine Festlegung der IT-Leitung erforderlich. Das für mich überraschendste Thema war in den letzten Monaten ein Kunde, der zwar einen generellen Change-Prozess implementieren wollte, aber für zwei Key-User einen Sonderworkflow abbilden wollte. Genau solche Zöpfe sind sinnigerweise abzuschneiden.

Ein viel geliebtes Thema sind Berechtigungen. Nun ist es ja leider so, dass ohnehin ein Kunde ohne einen ChaRM-Workflow meistens nur sehr rudimentär seine Anforderungen und Changes dokumentiert.

Dennoch haben genau diese Kunden dann im ChaRM Bedenken, dass jeder Key-User auch die Änderungswünsche der Nachbarabteilung lesen könnte. Zwar kann man im Solution Manager wunderbar hierfür tiefgreifende Berechtigungskonstrukte aufbauen, nur sollte man sich dann auch genau überlegen, ob es den Verwaltungsaufwand wirklich wert ist.

Es ist nicht schwer einzustellen, dass nur der IT-Mitarbeiter, der dem Change zugewiesen ist, diesen auch bearbeiten kann. Es kommt jedoch dann von mir immer die Frage auf, wie der Kunde agieren möchte, wenn dann genau dieser Mitarbeiter erkrankt ist.

Da auch das Thema Dokumentation mit ChaRM eng verknüpft ist, muss auch dieser Aspekt geklärt werden. Hier ist es relevant, Vorlagen zu definieren und diese auch in den jeweiligen Workflows für einen Änderungsantrag oder eine Änderung einzufordern.

In Summe sind ein Konzept und ein Fahrplan das Wichtigste für eine erfolgreiche Einführung. Die technische Umsetzung ist – wie oft im Bereich der Application-Lifecycle-Werkzeuge – der geringste Aufwandstreiber.

Die organisatorischen Änderungen sind nicht zu vernachlässigen und häufig der Garant für eine erfolgreiche Einführung.