Aktuelles

Der MOP(z) stirbt aus

Folgende Situation erlebe ich als SAP Basis Administrator in letzter Zeit recht häufig: Das Telefon klingelt und der nette Vertriebskollege vom Büro nebenan ist am Hörer. „Ich habe hier einen Kunden, der ein ERP 6 EHP7 Upgrade für seine SAP Systeme wünscht. Recht schnell in der Durchführung wenn es geht und am besten ab sofort. Der Kunde sagte im Vorfeld aber auch, dass sein Solution Manager schon recht alt sei und damit keine Upgrade Files mehr generiert bzw. heruntergeladen werden können“.

Nach weiteren Details sage ich dem Vertriebler, dass ich das Upgrade Projekt gern annehme. Die Aussage bezüglich des Solution Managers in Kombination mit einem Upgrade „recht zeitnah“ bereitet mir jedoch im ersten Moment ein wenig Unwohlsein. Zeit, hätte ich eigentlich für ein „Upgrade nebenbei“ wie fast immer bedingt durch das Tagesgeschäft keine. Jedoch möchte man den Kunden ja glücklich machen und vielleicht in Zukunft dadurch neue Projekte generieren. Für mich klingt ein Upgrade, inklusive nicht funktionstüchtigen Solution Manager immer nach einer neuen Herausforderung, gefühlt wie die epischen Schlachten samt Quests und Level Up in einem Computerspiel mit anschließenden „Boss Fight“. Was der Fehlerbeseitigung im SAP Umfeld ja fast gleich kommt… Ist denn ein SAP Upgrade, egal welches Release, jemals fehlerfrei durchgelaufen? Nein, aber bis jetzt konnte doch jedes Problem in einem Upgrade erfolgreich beseitigt und zuletzt zufriedenstellend durchführt werden. Jedoch stellt ein existierender, aber nicht funktionierender Solution Manager vor dem eigentlichen Upgrade, eben diese bereits erwähnte besondere Herausforderung dar. 

Da der Solution Manager und auch Upgrade-Prozesse eines meiner Kerngeschäfte sind, rufe ich den Kunden direkt im Anschluss des Gesprächs mit dem Vertrieb an, um mir ein erstes Bild der Ausgangssituation zu machen. Der Kunde zeigt mir direkt, durch die doch schnelle Reaktion meinerseits, seine SAP Systeme via „Teamviewer“ Sitzung. Ich sehe die klassische SAP 3-Systemlandschaft. Release Stände und Datenbank inkl. Freiplatz passen für die anstehenden Tätigkeiten auch zusammen. Dann kommt das vom Kunden bereits angesprochene Sorgenkind, der Solution Manager an die Reihe. Der erste Blick auf die Produktversion, in dem Fall ein Solman 7.1, was im Moment das aktuellste ist bei SAP, klingt schon einmal vielversprechend. Die Komponenten mit steinalten Release (SP03 und aktuell ist SP14) jedoch, ein nicht aktuelles SLD (System Landscape Directory) und die LMDB (Landscape Management Database) mit SAP Systemen, welche nicht mehr in der Landschaft des Kunden existieren, bestätigten meine Befürchtungen. Ich überprüfe als nächstes die Solution Manager Konfiguration (Systemvorbereitung und Basiskonfiguration) teils unvollständig, teils mit falschen Parametern und anschließend noch die Konfiguration der verwalteten Systeme, welche zu 90% nicht durchgeführt wurden sind. Mein anfängliches Gefühl von Unwohlsein wird damit noch mehr bestätigt. Fazit: Meiner Erfahrung nach, ist dieser Solution Manager im aktuellen Zustand für einen zeitnahen und schnellen Upgrade nicht zu gebrauchen.

An dieser Stelle gibt es nur drei Möglichkeiten. Entweder eine Neuinstallation vom Solution Manager 7.1 inklusive aktueller Updates, korrekter Konfiguration und anschließender SAP Systemlandschaftspflege. Dies wäre eindeutig die sauberste, aber nicht schnellste Lösung und kommt für einen Kunden mit Customizing, Charm/ITSM, Monitoring usw. eh nicht in Frage. Die Alternative wäre, im existierenden Kunden Solution Manager die aktuellen Updates einzuspielen, die Konfiguration erneut durchzuführen und wie die Erfahrung sonst zeigte, alle „alten“ Einträge bzw. Konfiguration zu entfernen. Danach müsste ebenfalls die Konfiguration der verwalteten Systeme durchgeführt werden. Wer schon mehrfach Solution Manager aufgebaut und die Systemlandschaft an diesen angebunden hat weiß, dass dabei doch schnell eine Woche vergehen kann. Ich denke dabei nur an die, selbst bei der Minimal-Konfiguration anstehende und langwierige SLD – LMDB Synchronisation. Diese Tätigkeiten sind jedoch die Grundvoraussetzung für einen Upgrade der SAP Landschaft und es führt kein Weg daran vorbei. Beide Varianten scheiden also für das gewünschte schnelle Upgrade aus. Die erwähnte dritte Variante wäre, die Systeme an den eigenen Solution Manager anzubinden. Dieser ist direkt einsatzbereit und es würde „nur“ die Anbindung der Kundenlandschaft inklusive Kunden S-User Pflege ausstehen. Ok, dieses eben schnell also “nur“ sind im Nachgang betrachtet doch dann eben die Konfigurationsschritte wie SLD und LMDB Sync, korrekte Produktsystemzuordnung, logische Komponenten definieren, Lösung zuordnen, RFCs und User anlegen, Voraussetzungen prüfen und zu guter Letzt noch die „Mopz“ (Maintenance Optimizer) Pflichtbedingung, Verifikation Status prüfen. Hinzu kommt die „bidirektionale Verbindung“ zwischen den Kundensystemen und entfernten Solution Manager. Zu realisieren ok, aber in kürzester Zeit machbar sei dahingestellt. Es müssten außerdem beide Parteien in direkter Absprache, einiges an Konfigurationstätigkeiten leisten. Was also in diesem, sicherlich auch in zukünftigen Kundensituationen tun und für welche Variante entscheidet man sich am Ende?

Und genau an dieser Stelle kommt das neuste Produkt der SAP ins Spiel, der Maintenance Planner. Vorab ist zu sagen, dass auch der Maintenance Planner keine Wunderwaffe ist. Aber aus heutiger Sicht (Befindet sich derzeit noch in der letzten Entwicklungsphase und die Angaben hier könnten sich noch ändern) wird ein unkompliziertes und vor allem schnelleres Upgraden in Zukunft garantiert. Der entscheidende Vorteil hierbei ist, dass auch ein älterer Solution Manager 7.0 ab SP23 beim Kunden mit minimaler Konfiguration bis zum Schritt SLD/LMDB Aufbau und lediglich die SAP System Verbindung via Transaktion RZ70 benötigt wird. Die gesammelten Systemlandschaftsdaten werden vom Solution Manager an das SAP Support Portal gesendet und daraus ein Kunden Profil erstellt.

Durch einen beliebigen Browser ist es ab sofort uneingeschränkt möglich, sich an dem von der SAP in der Cloud gehosteten Maintenance Planner anzumelden. Die Anmeldung erfolgt mittels S-User vom jeweiligen Kunden für seine zugeordneten Systeme. 

Auf der Startseite, dem sogenannten Homescreen hat man jetzt die Auswahl zwischen der Liste aller angebundenen SAP Systeme, welche im Kunden Profil generiert wurde (Explore Systems), einer Liste der letzten Tätigkeiten (Transactions), die Planung eines komplett neuen Systems (Plan a New System) oder aber die Sichtung einer zusammengehörenden Systemlandschaft wie z.B. DEV-QAS-PRD (Explore System Tracks). 

Durch die Auswahl von Explore Systems gelangt man ohne Umwege in die Übersicht aller SAP Systeme. Hier kann man direkt den SAP System Typen (Abap, Java, Dual Stack), automatische Produktzuordnung, Quelle des Solution Managers und weitere Informationen im Überblick sehen. Nachdem man sich man sich für das zu wartende System (Upgrade, Update oder Addon Installation) entschieden und dieses auch ausgewählt hat, wird der Lifecycle Screen aufgerufen. 

Der Lifecycle des SAP Systems im Wartungsvorgang besteht aus 4 Teilbereichen. Als erstes sollte man die Daten vom Solution Manager zum SAP Support Portal noch einmal synchronisieren (Sync). Dies macht Sinn, falls während dem letzten hochladen der Daten aus dem LMDB, Änderungen z.B. durch Addon Installation im SAP System gemacht wurden. Im nächsten Schritt werden die synchronisierten Daten des SAP Systems mit gültigen Daten bei der SAP verifiziert. (Verify) Dabei werden die Software Stände, Komponenten und Addons auf Abhängigkeiten und Aktualität überprüft. 

Ist dies geschehen kann sofort im Anschluss die gewünschte Wartung berechnet werden. (Plan) Durch ein optisch ansprechendes Design dank UI5 und innovativ umgesetzte Oberfläche, wird man dabei bequem durch die entsprechenden Wartungsmöglichkeiten (Addon Installation, Updates oder Upgrades) mit modernster Benutzerführung geleitet. Im Hintergrund werden bei der jeweiligen Auswahl, gefühlt in Echtzeit, die Abhängigkeiten automatisch mit berechnet. Dadurch kann es zu keinerlei Verwechslung kommen und die am Ende erstellt Upgrade XML Datei entspricht genau dem, was man auch wirklich als Wartung durchführen will. Die XML wird ab diesem Schritt, weiterhin wie gewohnt mit den entsprechenden Tools der SAP, hier der SUM (Software Update Manager) verwendet.

Als Abschluss hat man noch die Möglichkeit, den davor gewählten Wartungsvorgang für einen gewünschten Zeitpunkt im Kalender einzuplanen. (Schedule) 

Zusammengefasst: Die SAP hat hier ein Wartungstool entwickelt, welches in der nächsten Zeit eine vereinfachte und vor allem schnelle Wartungs- und Installationsplanung zulässt. Dabei sind aber auch fortgeschrittene Prozesse sowie unkompliziertere Funktionen im Landschafts-Management möglich. Wartungsabhängigkeiten und Korrekturen der Landschaftsdaten geschehen automatisiert im Hintergrund durch eine integrierte Prüfung. Es wird ein Plattform unabhängiges Tool über den Browser bereitgestellt, welches ohne direkten Zugriff auf den Kunden Solution Manager, für die Planung und Berechnung von Wartungsvorgängen verwendet wird. Der Maintenance Planner selber, benötigt keinerlei Wartung oder Aktualisierung mehr, da dieser in der SAP Cloud angeboten wird. Es wird in Zukunft (ab Solution Manager 7.2) nur noch ein zentrales Planungstool benötigt, welches die bisher bekannten Tools wie LMDB Produktsystem Editor, LMDB Produktsystem Verifizierung, Mopz (Maintenance Optimizer), Landscape Planner und UDA (Upgrade Dependency Analyzer) komplett ersetzt. Mehrkosten entstehend dabei keine weiteren für den Endkunden. Falls nicht noch gravierende Änderungen gemacht werden, können durch den Maintenance Planner zukünftig tatsächlich Wartungsprozesse und deren Vorarbeiten durch den Solution Manager, mit weniger epischen Schlachten realisiert werden.