SolMan - Solution Manager

Der richtige Umstieg auf SolMan 7.2

Im Rahmen der Wartungsstrategie werde ich immer wieder gefragt, wie Unternehmen die Umstellung auf den Solution Manager 7.2 gestalten und planen sollen.

Für viele IT-Verantwortliche ist die Umstellung auf den Solution Manager 7.2 immer noch ein Buch mit sieben Siegeln.

Zudem hat sich auch noch nicht bei allen Kunden herumgesprochen, dass das Wartungsende 31.12.2017 wirklich final ist.Von einer Verlängerung der Wartung durch SAP sollte man – bedingt durch technische Restriktionen – besser nicht ausgehen.

Die Planung beginnt damit, dass man sich ganz konkret fragen sollte, auf welcher Plattform der SolMan künftig betrieben wird.

ad_banner

Die Hana-Lizenz für den Betrieb des SolMan wird von SAP ohne Lizenzkosten dem Kunden zur Verfügung gestellt.Dies gilt insbesondere auch dann, wenn der SAP-Anwender noch gar kein Hana lizenziert hat.

Im Jahr 2020 wird die neue S/4 Hana Business Suite eingeläutet. Spätestens bis 2025 haben dann Kunden den Zwang, auf Hana umzustellen.

Mit der Einführung und dem Quantensprung auf S/4 Hana sind ohnehin genug Themen für eine IT zu erledigen, sodass eine neue Technik dann noch ein Thema mehr wäre.

Es macht daher Sinn, sich durchaus bereits jetzt mit der Umstellung zu befassen und den Solution Manager auf Hana umzustellen. Neben den rein technischen Voraussetzungen ist zu bedenken, dass SAP eine Feature-Liste aufgelegt hat.

Technisch würde ich jedem Kunden empfehlen, eine Kopie des bestehenden produktiven Solution Managers durchzuführen. Auf dieser kann dann das Upgrade in „aller Ruhe“ geprobt werden.

Zwar ist gerade die Systemkopie des SolMan mit viel Nacharbeit verbunden, dies macht aber im vorliegenden Kontext definitiv Sinn.

Der größte Bereich der Änderungen betrifft die Lösungsdokumentation. Dies wird aber auch klar seitens SAP kommuniziert. Was einigen Anwendern sicherlich nicht bekannt ist, ist die Form der Umstellung und Konvertierung.

Prinzipiell können Artefakte und Dokumente beim Upgrade übernommen werden.

Alles, was nicht übernommen wird, ist nach dem Upgrade nur noch im Read-only-Modus zugreifbar. Die Festlegung des Contents, der übernommen wird, nennt sich Scoping.

Das Pikante ist, dass der Konvertierungsreport nur ein einziges Mal, nämlich während des Upgrades, ausgeführt werden kann. War also das Scoping nicht korrekt, müssen alle Dokumente händisch neu erstellt und verknüpft werden.

Gerade in diesem Zusammenhang lohnt es sich für Kunden definitiv, auf einer Sandbox das Upgrade zu üben, sodass man bei einem fehlerhaften Scoping wieder auf einen alten Snapshot zurückkehren kann.

Testmanagement

Der zweite große Bereich, der Änderungen erfährt, ist das Thema Testmanagement.

Testdokumente und Pläne sind eng mit der Lösungsdokumentation verknüpft. Da sich die Struktur und Definition der Lösungsdokumentation ändert, muss dies auch in Zusammenhang mit Testplänen und Vorgehensweisen beim Test konzeptionell abgesprochen werden.

Etwaige Schnittstellen zu externen Werkzeugen sind hinsichtlich Verfügbarkeit und Nutzung mit Fremdherstellern abzuklären. Beim Change Request Management gibt es zwar Änderungen, diese betreffen aber glücklicherweise nicht die Oberfläche.

Hinsichtlich der neuen Struktur, des Wegfalls der Transaktionen SOLAR01 und SOLAR02 sowie der SolMan-Projekte ändert sich auch das Release-Management.

Im Rahmen des Upgrades sollte auch geprüft werden, ob die definierten und etablierten ChaRM-Prozesse nicht gegebenenfalls auch an die neue Version 7.2 anzupassen sind.

Neben dieser Anpassung ändern sich auch Berechtigungsobjekte und die Oberflächen der Administration. Hierzu sind sicherlich neue Betriebshandbücher zu verfassen und Change Manager müssen sich mit den neuen Oberflächen vertraut machen.

Auch in Hinblick auf offene Changes ist der Zeitpunkt des Upgrades so zu planen, dass möglichst wenig offene Changes vorhanden sind. In den Bereichen Application Operations und Monitoring sind die Änderungen nicht ganz so gravierend.

Hier betreffen die Anpassungen auch keinen Fachbereich, sondern können im Kreis einer SAP-Basis geklärt werden.
Zusammengefasst stellt das Upgrade sicherlich eine größere Herausforderung dar, ist aber mit einer Sandbox und einer guten Vorbereitung und Inventarisierung aller Prozesse machbar.

Allzu lange sollten IT-Verantwortliche mit ihrer Planung jedoch nicht warten. Das Wartungsende naht und das Upgrade muss durchgeführt werden.

Das könnte Sie auch interessieren

0 Kommentare

Dein Kommentar

Möchten Sie uns Ihre Meinung zum Thema sagen?
Hinterlassen Sie uns einen Kommentar!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.