Zukunft 7.2

Ein wichtiger Aspekt für die Planung des Releasewechsels liegt darin, dass der offizielle Standardsupport für den Solution Manager 7.1 am 31. Dezember 2017 endet.

Kunden, die danach noch den SAP Solution Manager 7.1 nutzen, bekommen weiterhin Unterstützung durch SAP, frei nach deren Grundsatz „support never ends“.

Dafür müssen Unternehmen aber im Rahmen des kundenspezifischen Supports gegebenenfalls zahlen oder länger auf Fehlerkorrekturen warten.

Gerade im zertifizierten Umfeld, in dem auch SAP-­Solution-Manager-Szenarien und -Prozesse auditiert werden, sehen Prüfer die Nutzung von Software, die nicht länger im Standardsupport unterstützt wird, kritisch.

S/4 Hana als Treiber

Für viele Kunden entsteht durch die im Unternehmen anstehenden S/4-Projekte großer Druck.

Sie müssen bereits im Vorfeld genau planen und entscheiden, welche ersten und welche folgenden Schritte für sie richtig sind.

So steht der SAP Activate Con­tent, die Best Practices für die S/4-Implementierung entlang der SAP-Activate-Methode, nur für den SolMan 7.2 zur Verfügung.

Für den Solution Manager 7.1 werden diese Inhalte nicht bereitgestellt. Die Implementierung eines SolMan 7.2 ist daher der erste wichtige Schritt für Kunden, die sich mit dem Thema S/4 Hana auseinandersetzen.

Nicht nur der Activate Content ist für S/4-Hana-Kunden relevant: Beim Blick auf die SAP-S/4-­Hana-Roadmap, die SAP ihren Kunden für die Erstellung einer individuellen Roadmap an die Hand gibt, finden sich Themen, die erst mit dem Release 7.2 im benötigten Funktionsumfang bereitstehen.

Alle Endgeräte

Passend zur Kopplung an S/4 Hana unterstützt auch der SolMan 7.2 die neue User-Interface-Technologie Fiori.

Kunden können, ausgehend von den zur Verfügung gestellten SolMan-Fiori-Apps, ebenso intuitive Benutzeroberflächen zur Verfügung stellen wie ITSM-Cloudlösungen, die in letzter Zeit gegen den SolMan positioniert wurden und bei einigen Kunden aufgrund der einfachen Bedienbarkeit zum Einsatz kamen.

Dank der Nutzung von HTML5 können die SolMan-Apps auf allen Endgeräten, die HTML5 unterstützen, eingesetzt werden, was für die gängigen Mobile Devices und Smartphones gilt.

Custom Code

Custom Code Management (CCM) bzw. Custom Code Lifecycle Management (CCLM) gab es schon in früheren Versionen des Solution Manager, wurden bisher aber nur von einer überschaubaren Anzahl von Kunden genutzt.

Die Umstellung auf Hana und S/4 Hana bedeutet, dass sämtliches Coding, das nicht im SAP-Standard verfügbar ist, hinsichtlich Hana überprüft und überarbeitet werden muss.

Bei Kunden, die SAP schon länger im Einsatz haben, hat sich über die Jahre womöglich einiges an eigenentwickeltem Coding angesammelt.

Man geht davon aus, dass bis zu 65 Prozent dieses Codings kaum oder gar nicht genutzt werden oder inzwischen im SAP-Standard verfügbar sind (Quelle: SAP SE).

Dieses Coding anzupassen ist nicht sinnvoll. Custom Code Management bietet sich an, das nicht genutzte Coding zu identifizieren und zu entfernen, um erst dann die eigenentwickelten Komponenten anzupassen.

Solution Documentation

SAP hat das Thema Solution Documenta­tion (Prozess- und Lösungsdokumentation) am intensivsten überarbeitet und unterstützt nun etliche Funktionen, die von Kundenseite seit Langem gefordert werden.

So löst der SAP Solution Manager 7.2 die seit Langem kritisierte Einschränkung auf eine Prozesshierarchie mit lediglich drei Ebenen auf und macht nun bis zu 99 Ebenen möglich.

Zudem wird ein integrierter und innerhalb des Supports kostenfreier Editor zur Abbildung der Prozesse nach BPMN (Business Process Model and Notation) zur Verfügung gestellt, sodass die Prozessdokumentation innerhalb des Solution Manager erfolgen kann, ohne dass ein zusätzlicher externer Editor angebunden werden muss.

Gerade für Kunden, die S/4-Projekte planen, ist diese Funktion interessant.

Im Rahmen des Wechsels zu S/4 werden die zukünftigen Prozesse dokumentiert – im SAP Solution Manager kann dies basierend auf Content der SAP innerhalb der etablierten Technologie erfolgen, ohne dass zusätzliche Lizenzen erworben werden müssen.

Die enge Verzahnung von Solution Documentation und ITSM-Szenarien ermöglicht es, die Dokumentation in Zukunft in das Change Management einzubinden, um die Dokumentation stets auf dem neuesten Stand zu halten.

Den größten Mehrwert kann man im Rahmen des Testmanagements für die S/4-Projekte erzeugen, wenn das Testmanagement basierend auf der neuen Lösungsdokumentation aufgebaut wird.

Um diese Erweiterungen der Lösungsdokumentation zu ermöglichen, wurde die komplette technische Basis der Solution Documentation umgestellt, sodass sich für alle Szenarien, die auf deren Inhalte und Funktionen zugreifen, teilweise erheblicher Anpassungsbedarf ergibt.

Content Activation

Der Schritt, in dem die bestehende Solution Documenta­tion auf die neue Basis migriert wird, heißt Content Activation.

Sie ist für Kunden mit produktiver Nutzung der Solution Documentation im Solution Manager 7.1 vor allem dann ein kritischer Punkt im Upgrade, wenn die technische Basis der Solution Documentation erweitert wurde.

Hier muss vor dem Upgrade genau analysiert werden, welche Anpassungen in der Modellierung gemacht wurden und wie sich diese während der Aktivierung verhalten bzw. welche Maßnahmen ergriffen werden müssen, um die Aktivierung innerhalb des Upgrades erfolgreich abzuschließen.

Kunden, für die ein Testlauf in der Cloud Appliance Library (CAL) aufgrund von Compliance-Bestimmungen nicht möglich ist, müssen diese Tests in einem eigens installierten System durchführen.

Dabei muss man berücksichtigen, dass die Aktivierung nicht schrittweise, sondern nur einmal pro System erfolgen kann.

Die neue Test-Suite

Das Thema Testmanagement ist von den Solution-Manager-Szenarien am intensivsten mit der Solution Documentation verknüpft.

Hier ergeben sich die größten Abhängigkeiten, sodass das Testmanagement auch nicht Teil des offiziellen Solution Manager 7.2 Ramp-up war und erst mit der General Availability (SP 3) im August verfügbar war .

Vor allem die neuen Möglichkeiten, die das Testmanagement bietet, fallen ins Auge. Hier wurde eine bestehende Lösung, die oft nur zusammen mit anderen Testmanagement-Lösungen zum Einsatz kam, so erweitert, dass nun alle Anforderungen an ein professionelles und vollumfängliches Testmanagement-Tool erfüllt sind – inklusive der Möglichkeit zum automatischen Testen.

Vor diesem Hintergrund wurden auch SAP TAO sowie der SAP Solution Manager Adapter for HP ALM von der SAP-Preisliste genommen. Sie werden nur noch für Kunden, die die Lösung im Einsatz haben, gewartet.

Upgrade: Planung und Roadmap

Aus technischer Sicht muss im Solution Manager Upgrade eine Instanz, in der beide Serverkomponenten vereint vorliegen, in Abap und Java-Server getrennt werden.

Viele Kunden spielen mit dem Gedanken, den SolMan 7.2 mit der Hana-Datenbank, die für den Solution Manager lizenzfrei verfügbar ist, zu implementieren, um erste Erfahrungen zu sammeln.

Besonders wenn Hana als Option infrage kommt, ist das kein einfaches technisches NetWeaver-Upgrade.

Die bereits beschriebenen Umstellungen in der Solution Documentation und die sich daraus ergebenden Herausforderungen für die abhängigen Szenarien machen aus dem SolMan-Upgrade ein aus fachlicher Sicht herausforderndes Projekt.

Optionen für den Releasewechsel

Erstens: Upgrade der bestehenden Solu­tion-Manager-Installationen.

Gilt vor allem für Kunden, die den Solution Manager für technische Szenarien bzw. Szenarien einsetzen, die wenig Abhängigkeiten von der Solution Documentation haben.

Zweitens: Neuinstallation des Solution Manager 7.2 mit anschließender Migration der Belege und Dokumente im Solution Manager 7.1.

Diese Option bietet die Möglichkeit, sich bei der Migration von nicht benötigten Zwischenversionen, die in der Solution-Manager-Datenbank gespeichert wurden, zu trennen.

Drittens: Komplette Neuimplementierung des SolMan-7.2-Systems und Neuaufbau der Dokumentation und der Szenarien.

Diese Option ist vor allem für Kunden interessant, die sich konkret mit dem Wechsel zu S/4 Hana befassen. Diese Kunden können für die neue Landschaft direkt das neue Release nutzen und die Dokumentation neu für die S/4-Umgebung erstellen.

Zwischen den beiden ersten Optionen gibt es einen recht großen Graubereich: Themen wie auditierte IT-Prozesse, komplexe Zusatzentwicklungen, aber auch Pläne für die Zusammenlegung mehrerer Solu­tion-Manager-Installationen innerhalb eines Unternehmens können den Ausschlag für die Entscheidung geben und müssen individuell bewertet werden.