SAP-Projekte – Erfolgskriterium Change/Configuration Management

In umfangreichen und komplexen SAP-Projekten kommt es zwangsläufig zu einem intensiven Verkehr auf den Transportschienen der Entwicklungsumgebung in die Konsolidierungs- und zuletzt auch in die Produktivumgebungen. Es liegt in der Natur der Sache, dass es insbesondere bei den Importen in die Konsolidierungsumgebungen oftmals viele Transporte gibt, die nach Test (und Behebung möglicher Fehler in Folgetransporten) oder aufgrund wegfallender Relevanz gezielt nicht Bestandteil der Produktivsetzung sind. Gerade bei komplexen Entwicklungsprojekten mit einem hohen Customizing- und Eigenentwicklungsanteil, ggf. sogar begonnen auf der grünen Wiese, kann sich hier eine immense Anzahl an Transporten ergeben, deren Produktivsetzung gezielt gesteuert werden muss.

Obwohl keine neue Erkenntnis, und trotz bei vielen Anwendern sehr restriktiv geregelten Change Prozessen – immer wieder kommt es (insbesondere bei kompletten Neuaufbau von Systemen oder Mandanten die ggf. nicht von Anfang an einer technischen Kontrolle der Veränderungen in diesen Systemen/Mandanten unterliegen) dazu, dass diese Aspekte vernachlässigt werden. Wie ein Beispiel aus meiner jüngsten Projektvergangenheit in der Energieversorgungsbranche zeigt, kann sich die Situation bei komplexen Landschaften schnell zur Projektkrise auswachsen, die typischerweise gerne erst gegen Ende  des Projekts (wenn es an die Produktivsetzung der Projektergebnisse kommt) zuschlägt:

Der Aufbau eines SAP IS/U-Systems für einen Messstellenbetreiber (MSB) wurde unter der Verwendung von Mastermandanten in dreifacher Ausprägung (je eine Ausprägung pro möglicher Marktrolle des MSB) vorgenommen. Initial diente dazu das Template eines IS/U Systems für den Netzbetreiber, da sich hier eine hohe Abdeckung durch dort bestehende Funktionalität ergab. Die drei MSB-Mandanten wurden gemäß der Marktrollen unterschiedlich ausgeprägt – und zu allem Überfluss war (und ist) das MSB-System mit dem Template des Netz-Systems synchron zu halten – zumindest was die funktionalen Abdeckungen mit dem zu Grunde liegenden Netzsystem anbelangt …..

Stellen Sie sich vor, dass an dieser Gesamtausprägungen viele unterschiedliche Entwickler über einen jahrelangen Zeitraum aktiv sind – am Ende ergeben sich Konsolidierungssysteme mit einer sechsstelligen Anzahl an importierten Tarnsporten. Gegen Ende des Projekts (oder auch schon immer mal wieder zwischendurch) stellt sich dann die Frage, welche dieser Transporte in welcher Reihenfolge in die Produktivsysteme übernommen werden können, ohne hier einen kapitalen Schiefstand anzurichten ….

Aus diesem komplexen Bild wird klar, wie entscheidend es ist, bereits vom ersten Anlegen eines Transportauftrages an eine strukturierte Dokumentation aller Änderungen fortzuschreiben, sodass es später jederzeit möglich ist, gezielt einzelne oder alle Funktionalitäten und Einstellungen in die Produktivumgebung transportieren zu können. Und dreht es sich um bilanzrelevante Veränderungen, so schaut zudem auch gerne der Wirtschaftsprüfer zu.

Der Aspekt des Change Managements (im Sinne des Konfigurationsmanagements) geht gerade während der oftmals hektischen Initialisierung komplexer Projekte vergessen, liegt dann gerne im Verborgenen um dann mit den ersten (missglückten) Produktivstellungen gnadenlos zuzuschlagen und die Projektkosten (durch die dann notwendige Arbeit zur Rekonstruktion und Korrektur) in die Höhe zu treiben und Terminplanungen zu gefährden.

Fazit: auch wenn es zu Projektbeginn als eines der weniger relevanten Themen erscheint, das Aufsetzen bzw. die Integration der Projektabläufe in ein bestehendes Konfigurationsmanagement stellt einen wesentlichen Erfolgsfaktor dar – halten Sie vom ersten Tag des Projekts hier ein (oder beide) Auge(n) darauf!

 

P.S.: Darüber hinaus gilt dies nicht nur für SAP-Systeme, sondern analog auch für jedes weiter Stück Software, welches im Kontext komplexer Projekte erstellt und auch nach Abschluss des Projekts gepflegt, gewartet und weiterentwickelt werden soll ….