Darum empfehlen unsere Experten eine mehrstufige SAP Solution Manager-Systemlandschaft

Bei der Einführung des SAP Solution Managers stellt sich vielen nicht nur die Frage, welche Anwendungen im SAP Solution Manager genutzt werden sollen, sondern auch die, wie das System von der Architektur her aufgebaut werden soll.

Konkret geht es darum, ob es in Form einer einstufigen, zweistufigen oder dreistufigen Systemlandschaft ausgebaut und mit welchem Patch Level es installiert wird.

Grundsätzlich empfehlen wir den Aufbau einer zweistufigen Systemlandschaft, allerdings ist auch der Betrieb einer einstufigen SAP Solution Manager-Landschaft möglich. Dieses hängt aber ganz vom Anwendungsfall ab. Besonders bei der Nutzung des ITSM oder Change Request Managements (ChaRM) – also zur zentralen Steuerung von Transporten und Änderungen – ist der Sachverhalt sehr empfindlich. Daher möchten wir in diesem Blogbeitrag einige Nachteile aufzeigen, die es bei dem Betrieb einer einstufigen Solution Manager-Systemlandschaft gibt.

Gerade beim Einsatz des ChaRMs haben Änderungen am System direkte Auswirkungen:

• Änderungen des Workflows (neue Statuswerte, Fehler haben direkte Auswirkung, im schlimmsten Fall könnten Transporte nicht importiert werden) wirken sich auf den produktiven Betrieb aus.
   
• Tests bleiben aus. Es wird im laufenden Betrieb getestet.
   
• Es muss eine „Frozen Time“ eingeplant werden, in der alle User gesperrt werden. In dieser Zeit können Tests der Änderungen durchgeführt werden, wobei das System nicht zur Verfügung steht. Bei der Nutzung von ChaRM erhält der Solution Manager allerdings eine andere Bedeutung als System für das Unternehmen. Es wird zu einem 24/7-System und muss jederzeit zur Verfügung stehen, um Änderungen implementieren zu können. Natürlich gibt es auch ein Notfallkonzept, in diesem können Änderungen am ERP-System auch ohne den Solution Manager vorgenommen werden. Allerdings könnten in der „Notfallkonzeptphase“ Lockerungen im Umgang mit Änderungen ausgenutzt werden oder Richtlinien (z.B. nachträgliche Dokumentation der Änderung) vergessen werden.
   
• Beim Einspielen von Support Packages muss für das System eine „Frozen Time“ eingeplant werden. Es wird regelmäßige Zeitfenster geben, in denen kein Transport möglich ist. Eventuell kann es bei Problemen während eines Updates bzw. während der Nacharbeiten zu längeren Ausfällen kommen.
   
• Sowohl bei Einrichtung als auch beim Testen (z.B. nach dem Einspielen von Support Packages) des Change Request Managements müssen zwangsläufig Testbelege erzeugt werden, um den Änderungsprozess oder einzelne Funktionalitäten zu verproben. Bei einer einstufigen Systemlandschaft bedeutet dies, dass Testbelege und produktive Belege ohne klare Abgrenzung innerhalb eines Systems vermischt werden. Auch Auswertungen (z.B. „Wie viele Änderungen gab es diese Woche?“) können dadurch ihre Aussagekraft verlieren.

Daher empfehlen wir, bei der Nutzung der Transportverwaltung ein zweistufiges Solution Manager-System aufzubauen, damit Änderungen und Updates sorgfältig geprüft werden können und um dadurch einen größtmöglichen störungsfreien Ablauf der Änderungs- und Transportkontrolle mit den entsprechenden Schutzmechanismen zu gewährleisten.