Das zentrale Customizing, welches die Integrität der übergreifenden SAP-Firmenstruktur sicherstellen soll, wird in den meisten Firmen im zentralen SAP-Template-Customizing-Mandant erstellt und gepflegt. Von hier wird es mittels BC-Set und Transportmanagementsystem zu den dezentralen Customizing-Entwicklungssystemen transportiert. Allerdings ist es nicht einfach, die SAP-Customizing-Einstellungen firmen-übergreifend konsistent zu halten, gerade für SAP-Anwender, die mit mehreren dezentralen Systemlandschaften arbeiten.
Denn bereits mit dem ersten dezentralen Customizing werden oft bewusst, aber auch unbewusst Änderungen am vorgängig verteilten, zentral unterhaltenen SAP Company Template vorgenommen. Die Folge davon ist, dass das dezentrale Customizing nicht dem zentral gemanagten SAP Company Template entspricht. Die entstehenden Inkonsistenzen müssen immer wieder teuer und mit viel Aufwand beseitigt werden.
Organisatorische Massnahmen, um diese Widersprüchlichkeiten zu verhindern, zeigen bislang kaum Wirkung, denn die autonom handelnde dezentrale Entwicklung wird nicht technisch überwacht und kann vom System nicht gewarnt werden. Updates am zentralen SAP Company Template können folglich nach dem Transport zu den dezentralen Systemlandschaften nicht mehr aktiviert werden, da sie möglicherweise das vorgenommene dezentrale Customizing wieder überschreiben. Um trotzdem geänderte zentrale SAP Company Templates dezentral aktivieren zu können, bedarf es sehr grosser Abstimmaufwände.
Das Inkonsistenz-Problem beim SAP Company Template Roll-out kann man systemtechnisch mit dem SAP Solution Manager in den Griff bekommen. Mittels Einstellungen verhindert dieser, dass die Modifikationen für das Company Template in dezentralen Systemlandschaften überschrieben werden können – eine wirksame, systemtechnische Qualitätssicherungsmassnahme. Das zentrale Customizing ist damit dezentral sichergestellt. Der SAP Solution Manager kann auch dann noch eingeführt werden, wenn diverse zentrale und dezentrale Anpassungen und Roll-outs bei einem Anwender bereits durchlaufen wurden.
Ein weltweit operierender Konzern mit Dutzenden von SAP-ERP-Systemen, davon mehrere Produktivsysteme, definierte vor Jahren ein globales Template. Damit wurden für das Customizing globale Einstellungen definiert, die in allen Produktivumgebungen identisch sein mussten. Die Einhaltung der Einstellungen sollte mittels organisatorischer Massnahmen erreicht werden, deren Umsetzung erwies sich aber als schwierig. Die Vorgaben konnten zu einfach umgangen werden. So nahmen Entwickler Änderungen zum Teil nur auf ihren Entwicklungsmandanten vor, die restlichen wurden «vergessen». Die Situation spitzte sich zu, als sich das Unternehmen und damit auch die Systemumgebung, unter anderem durch Übernahmen, vergrösserte und komplexer wurde. Nach einer Weile entwickelte sich ein massives Delta der wichtigsten 5-Customizing-Mandanten. In einem ersten Versuch probierte das Unternehmen, die Situation durch die zentrale Zusammenlegung der Entwicklungsmandanten zu verbessern. Dieser Ansatz scheiterte aber auf Grund der Komplexität. Ausserdem benötigte ein neues Geschäft in Nordamerika zwingend einen eigenen Mandanten.
So machte man sich auf die Suche nach einer anderen Lösung. Dabei kristallisierten sich Fra-gen heraus, die für die Definition und spätere Umsetzung zwingend berücksichtigt werden mussten:
? Wie kann erreicht werden, dass die Einstellungen des Global Template auf allen Entwicklungsmandanten konsistent sind?
? Wie wird sichergestellt, dass Einstellung am Global Template in einem dedizierten Mandanten durch das Template vorgenommen werden können?
? Wie kann durchgesetzt werden, dass Einstellungen des Global Template auf den Entwicklungsmandanten nicht verändert werden können?
? Wie kann gewährleistet werden, dass bestimmte Schlüsselbereiche in Customizing-Tabellen gesperrt werden?
? Wie kann bewerkstelligt werden, dass nur ausgewählte Schlüsselbereiche in Custom-izing-Tabellen verteilt werden?
Zur Diskussion standen schliesslich mehrere Lösungsansätze:
1. Single-Client-Strategie
Hierbei wird das Abgleichen und dann Zusammenführen der fünf bestehenden Customizing-Mandanten in einen zentralen Customizing-Mandanten angestrebt. Die grosse Komplexität und das grosse Delta zwischen den bestehenden Mandanten könnten zu Problemen führen. Zudem sind die Anforderungen des Geschäfts aus Nordamerika wegen Benutzung des New Ledger mit diesem Ansatz nicht zu erfüllen.
2. Organisatorische Regelung und manuelle Verteilung durch Transporte
Im Zentrum dieses Ansatzes steht das erneute Aufstellen von organisatorischen Regelungen in Form von Richtlinien. Diese sehen vor, dass Einstellungen am globalen Template auf einem Entwicklungsmandanten vorgenommen werden, die restlichen Mandanten werden dann mittels manuell angelegten Transporten beliefert. Dieser Ansatz bietet jedoch keine Möglichkeit, Customizing-Einstellungen auf anderen Mandanten zu sperren. Zudem ist diese Lösung mit der grossen Anzahl von Entwicklern kaum umsetzbar beziehungsweise sehr umständlich in einer möglichen späteren Anwendung.
3. Customizing Synchronisation mit SAP Solution Manager
Mit der Customizing Synchronisation werden globale Einstellungen in den lokalen Mandanten gesperrt beziehungsweise zentral verändert und in die Zielmandanten verteilt. Lokale Einstellungen können weiterhin dezentral in den Zielmandanten vorgenommen werden. Customizing-Einstellungen, die zu einer Synchronisationsgruppe gehören, werden über mehrere Customizing-Mandanten synchron gehalten. Damit entsteht die Möglichkeit, Cus-tomizing-Einstellungen zentral vorzunehmen und gleichzeitig in weiteren Mandanten oder gar Systemen synchron zu halten. Gleichzeitig können diese Einstellungen auf den Zielmandanten oder Systemen für Änderungen gesperrt werden. Die grösste Herausforderung dieser Variante besteht darin, das bestehende Global Template in Synchronisationsgruppen zu «verpacken», die Zielmandanten vorgängig abzugleichen und Objekte als global oder lokal zu definieren.
Auf Grund der Fragestellungen, der Anforderungen sowie den bereits in früheren Versuchen gemachten Erfahrungen mit organisatorischen Richtlinien und der Single-Client-Strategie wurde Variante 3 ausgewählt und eine Umsetzungsplanung erstellt.
Wegen der komplexen Systemumgebung und der Auswirkungen auf die Organisation musste die Umsetzung in kontrollierbaren Teilschritten vorgenommen werden. In einer ersten Phase wurden die Systeme zudem auf zwei produktive Entwicklungsmandanten reduziert. Dies auf Basis des grössten gemeinsamen Nenners und auf Grund der grossen Deltas zwischen den Systemen.
So sollte das neue Produktivsystem für Nord-amerika mit kleinstmöglichem Aufwand aus dem Template erstellt werden können. Gleichzeitig konnte man alle Template-Einstellungen sperren. Die weiteren Mandanten sollten dann im Anschluss in einer zweiten Phase abgeglichen und das Template entsprechend angepasst werden.
Die wichtigsten Meilensteine der Umsetzung:
? Unterteilung in Phasen und Iterationen, Definition der Lieferobjekte, Festlegung der Projekt-Organisation, Vereinbarung über Vorgehen betreffend Kommunikation/Risiken/Pendenzen/Entscheidungen/Projektumfang sowie Änderungen daran/Fortschritts-Reporting, Kontrollpunkte für Qualitätssicherung, Rollen und Verantwortlichkeiten
? Dokumentierte Richtlinien, Namenskonventionen und dokumentierte SAP-Unternehmensstruktur, Verteil-Strategie, Mandanten-Strategie, Locking-Strategie
? Einrichten von SAP Solution Manager in produktiver Umgebung, Konfiguration für den Einsatz der Customizing Synchronisation
? Einstellungen, die im Global Template gehalten werden, zusammen mit Fachbereich erarbeiten, definieren und dokumentieren
? Sicherstellen der Sys-temvoraussetzungen für die Vergleichsläufe, Durchführung der Vergleichsläufe zwischen den Mandanten, Erstellen einer Differenz-analyse, Eruieren von Altlasten
? Aufteilung der Synchronisationsgruppen anhand der eingesetzten SAP-Module, im Bereich Logistik entstanden so zum Beispiel über 25 Synchronisationsgruppen mit ungefähr 1500 einzelnen Synchronisationsobjekten
? Definition von Bereichen, das heisst Einstellungen, die nicht synchronisiert, aber dennoch in Zielmandanten gesperrt werden, Zuteilung der Bereiche auf Synchronisationsgruppen
? Aufbau des Mandanten durch Abgleich und Zusammenführung der fünf bestehenden Customizing-Mandanten, Synchronisation der Objekte auf den Zielmandanten, Aktivierung der Synchronisation
? Testen, Schulung
? Aktivierung der Sperren auf den Zielmandanten, Aktivierung der Verteilung
In einem weiteren Schritt sollen nun Finanz und Controlling (FI/CO) erweitert sowie die Templates verfeinert werden. Nachdem nun also im Logistikbereich sämtliche Objekte des Template synchronisiert werden, wird die Lösung nun auf den Bereich Finanz und Controlling ausgeweitet. Des weiteren werden Objekte, die in der ersten Phase nicht oder nur teilweise synchronisiert werden konnten, nun einzeln betrachtet, analysiert, abgeglichen und nach Möglichkeit ins globale Template aufgenommen.
Die Gründe, wieso Unternehmen ähnliche Ansätze verfolgen sollten, sind vielfältig. So werden beispielsweise die Einstellungen der globalen Templates geschützt und können nur durch ein entsprechend autorisiertes und geschultes Template-Team angepasst werden. In der Standard-Version des Customizing-Mandanten sind die Einstellungen des globalen Template gesperrt und können nicht verändert werden. Ungewollte Einstellungen führen also nicht mehr zu Fehlern in der Produktion. Ausserdem erfolgt die Verteilung automatisiert, Deltas zwischen den Mandanten werden proaktiv unterbunden. Ebenso können neue Produktivmandanten mit minimalem Aufwand erstellt und gleichzeitig in die Verteilung angebunden werden.
