SolMan 7.2: Mehr als die Summe einzelner Werkzeuge
Immer wieder treffe ich auf Kunden, die in der Vergangenheit bei IT-Service-Management- Werkzeugen mehr den Best-of-Breed Ansatz verfolgt haben. Dies wird aber mit dem Solution Manager 7.2 unweigerlich zum Scheitern führen.
Solange der Solution Manager nur als reines Vehikel für Early Watch Alerts verwendet wird, stellt dies natürlich keinerlei Probleme dar.
Bekommt der Solution Manager nur diesen Stellenwert in einer IT, dann wird bei Weitem der Vorteil des Werkzeugs nicht genutzt und liegt brach. Darüber hinaus sollten sich dann Anwender überlegen, wie sie denn den Umstieg auf S/4 Hana meistern wollen und welche Werkzeuge stattdessen dafür herangezogen werden sollen.
Möchte man den Solution Manager sinnvoll ausbauen, so sind zumindest die Lösungsdokumentation und das Change und Request Management (ChaRM) Pflicht.
Generell empfehle ich in diesen Bereichen SAP-Anwendern nur dann eine Nutzung, wenn der SAP-Anteil und dessen Bedeutung innerhalb der IT die Fünfzig-Prozent-Schwelle überschreitet. Denn Anwender und Entwickler im Java-Umfeld zu einem Solution-Manager-Umstieg zu zwingen ist kein besonders großes Vergnügen.
Hat man in der Vergangenheit noch mit zwei unterschiedlichen Werkzeugen im Bereich Change Management oder im Bereich der Softwaredokumentation gearbeitet, so macht dies im Solution Manager nur noch bedingt Sinn.
Einige Kunden, die ich in den letzten Wochen beraten durfte, haben Lösungen gesucht, ein Projekt- Managementwerkzeug, eine separate Kosten- und Leistungsverrechnung sowie ein externes Dokumentationswerkzeug mit dem Solution Manager Service Desk und dem Change Management zu verknüpfen.
Eine solche Integration mag zwar möglich sein, eröffnet aber an zahlreichen Stellen zusätzliche Schnittstellen, die der Solution Manager im Standard so gar nicht besitzt.
Die einzige offiziell verfügbare Schnittstelle stellt die Kopplung eines externen Service Desks mit dem Incident Management des Solution Managers dar.
Die Gesamtlösung zum Management der IT im Solution Manager ist mit der Version 7.2 gar nicht so weit weg. Aufgrund der erheblichen Verbesserung der Umfänge und Funktionen stellt dies auch in der Umsetzung kaum noch Probleme dar.
Die größte Herausforderung liegt darin, die gesamte IT auf das Werkzeug zu eichen. Dies macht natürlich nur dann Sinn, wenn SAP die Mehrheit in der IT-Umgebung darstellt.
Im Gesamtkontext beginnt alles mit der Lösungsdokumentation und der Abbildung von Geschäftsprozessen und Geschäftsprozessschritten. Im ersten Schritt muss dies nicht vollständig sein, eine Annäherung und Nachdokumentation sollte jedoch alleine schon aus dem Gesichtspunkt der S/4-Umstellung erfolgen.
Nur wenn die Prozesse sinnvoll und entsprechend der Realität in Prozessschritten abgebildet sind, kann daraus auch ein Testplan sowie ein Testvorgehen abgebildet werden.
Im Rahmen des Change Request Managements ist natürlich die Änderung eng mit der Dokumentation sowie den davon betroffenen Prozessen und -schritten verbunden. Somit soll und muss sichergestellt werden, dass Änderungen nicht undokumentiert produktiv gesetzt werden.
Wer nun sinnvoll seine IT auch im SAP-Umfeld steuert, entscheidet sich zwangsläufig für ein Release Management, das auf das Change Management aufbaut. Möchte man hier ein sinnvolles Controlling, so kann das Release Management mit dem Projekt- und Portfolio-Management im Solution Manager verbunden werden.
Damit können dann auch nicht nur auf Einzelebene Changes gemanagt werden. Vielmehr können im Projektmanagementteil auch Aufgabenpakete erfasst werden, die keine softwaretechnische Änderung mit sich ziehen.
Entscheiden sich nun IT-Verantwortliche für eine verursachungsgerechte Zeiterfassung, so können Aufwände direkt auf die Aufgabenpakete im Projekt erfasst werden. Mit Abgleich der Planzahlen können dann typische Projektmanagement-Kennzahlen abgegriffen werden.
In Summe ergibt sich also ein sinnvoller Verbund aus einzelnen Werkzeugen. Eine Trennung dieser Werkzeuge führt immer wieder zu Wartungsaufwänden, aufwändigen Schnittstellen sowie massiven Funktionsverlusten.
