Viele Unternehmen haben heute Schwierigkeiten damit, Tools in ihren Nicht-SAP- und SAP-Landschaften zu integrieren und zu orchestrieren. Diese fehlende Verbindung kann zu Ineffizienzen, erhöhtem manuellem Arbeitsaufwand und einem größeren Fehlerrisiko bei der Verwaltung von SAP-Änderungen führen.
Agiles SAP-Change-Management ist für den Erfolg auf eine nahtlose Integration und einen automatisierten, einheitlichen Workflow angewiesen.
In diesem Blog beleuchten wir den Weg, den einer unserer Kunden, eine deutsche Versicherungsgesellschaft, eingeschlagen hat, um seine Agile/DevOps-Ziele für SAP und operative Exzellenz zu erreichen.
Hintergrundinformationen zu agilem SAP-Change!
Dieses Versicherungsunternehmen, eine Tochtergesellschaft eines größeren Konzerns, betrieb seine IT agil und nutzte Tools wie Jenkins, Jira, Tricentis Tosca und ServiceNow. Während diese Tools gut in ihre Nicht-SAP-Landschaften integriert waren, wurden SAP Changes manuell verwaltet und waren stark fragmentiert.
Das Unternehmen verwaltete Anforderungen und Incidents in JIRA und ServiceNow. Es fand jedoch kein automatischer Informationsaustausch zwischen diesen Tools und SAP statt. Infolgedessen arbeiteten die Entwickler hart daran, ihre SAP-Transporte manuell zu dokumentieren, indem sie Daten kopierten und einfügten usw. Trotz größter Bemühungen wurden nur etwa 80 % korrekt durchgeführt.
Dieser Mangel an Integration und Automatisierung führte zu verschiedenen Problemen:
- Teure Audits aufgrund unvollständiger und ungenauer Berichte
- Mühsame und zeitintensive Aufgaben für Systementwickler und Tester, die viel Zeit für manuelle Prozesse aufwenden mussten. Die tägliche Arbeit war mit vielen mühsamen, lästigen Aufgaben für die Personen verbunden, die die Systementwicklung und das Testen durchführten, da sie viel Zeit für die Erfüllung des Prozesses aufwenden mussten.
- Verzögerungen beim Erreichen der Agile/DevOps-Ziele für SAP, da manuelle Schritte die Bereitstellung von Änderungen verlangsamten.
- Auswirkungen auf die Qualität
Es war für sie sinnvoll, nach einer Lösung zu suchen, die diese Lücke schließen konnte – ein Tool, das ihre Prozesse auch in ihren SAP-Landschaften durchsetzt und den Change-Prozess so weit wie möglich automatisiert. Sie wollten TOSCA zudem automatisiert auf SAP einsetzen, um die DevSecOps-Kette zu schließen.
Sprint 1 – Rev-Trac-Implementierung
Ihr Weg zu DevSecOps begann 2019 mit einer eigenständigen Implementierung von Rev-Trac.
Rev-Trac ging weniger als drei Monate nach Vertragsunterzeichnung live. Die Implementierung umfasste Admin-Schulungen, die Workflow-Konfiguration und Go-Live-Endbenutzerschulungen.
Dieser erste Sprint sicherte die Prozesskonsistenz und erhöhte die Compliance, da Rev-Trac sicherstellt, dass einem Transport ein Ticket zugewiesen wird, und diesen Prozess erzwingt. Dennoch waren einige manuelle Aufgaben erforderlich, zum Beispiel die Zuweisung von ServiceNow-Change-Requests zum Rev-Trac-Ticket und umgekehrt.
Sprint 2 – ServiceNow-Integration
ServiceNow verwaltet Incidents als eine Quelle für Änderungen. Vor dem Go-Live erfordert der Prozess einen ServiceNow-Change-Request, um CAB-Genehmigungen zu erhalten.
Die Integration von ServiceNow mit Rev-Trac über REST-APIs bietet erhebliche Vorteile:
- Weitere Automatisierung des Prozesses durch die Erstellung von Rev-Trac-Tickets aus ServiceNow
- Verschärfung der Compliance: SAP-Änderungen sind nur mit einem zugewiesenen ServiceNow-Ticket möglich
Die Konfiguration dauerte etwa zwei Tage, nach einigen organisatorischen Hürden beim Aufbau der Netzwerkverbindungen.
Die Ergebnisse dieses Sprints brachten dem Management und den Entwicklern große Erleichterung. Ihr Prozess erfordert das Ausfüllen vieler Felder in ServiceNow, was nun automatisch, konsistent und konform erfolgt.
Sprint 3 – Jira-Integration
Dennoch bearbeitete ServiceNow nur Incidents, was eine Lücke hinterließ. Neue Anforderungen werden in Jira geplant und immer noch manuell gepflegt. Daher war die Integration von Jira mit Rev-Trac in Sprint 3 der logische nächste Schritt.
Um diese Lücke zu schließen, definierten sie in Jira-Issues, wo die Verbindung zu Rev-Trac hergestellt werden soll. Für diese Integration wählten sie Subtasks. Das Ergebnis war eine bidirektionale Integration, die Jira und Rev-Trac zum richtigen Zeitpunkt im Prozess aktualisiert.
Der Prozess beginnt mit der Erstellung eines Rev-Trac-Tickets, sobald in Jira ein Subtask vom Typ „Rev-Trac“ erstellt wurde. Das Rev-Trac-Ticket enthält Referenzen (mit Links) zum Jira-Subtask und dessen Parent (normalerweise die User-Story), und der Jira-Subtask erhält einen Link zum Rev-Trac-Ticket sowie alle Status-Updates.
Letzter Schritt zu SAP DevSecOps
Sprint 4 – Tricentis-Tosca-Integration
Mit Tosca ist es sinnvoll, dies in die einheitliche Toolchain zu integrieren, die Rev-Trac, Jira und ServiceNow umfasst.
Technisch gesehen kann Rev-Trac Tosca aufrufen, um automatisierte Testskripte auszuführen. Tosca gibt das Ergebnis zurück, und der Rev-Trac-Workflow wird basierend auf dem Ergebnis fortgesetzt.
Zum Zeitpunkt der Erstellung dieses Textes befindet sich Sprint 4 noch in der Planungsphase.
Kontaktieren Sie einen unserer Experten für Change-Management, um weitere Informationen zur bidirektionalen Integration von Rev-Trac Platinum mit gängigen ITSM- und ALM-Tools zu erhalten.
