Viele Unternehmen haben heute Probleme mit der Integration und Orchestrierung von Tools in ihre SAP- und Nicht-SAP-Landschaften. Diese Trennung kann zu Ineffizienzen, erhöhtem manuellen Arbeitsaufwand und einem höheren Fehlerrisiko bei der Verwaltung von SAP-Änderungen führen.
Agiles SAP-Änderungsmanagement ist für den Erfolg auf nahtlose Integration und einen automatisierten, einheitlichen Workflow angewiesen. In diesem Blog beleuchten wir den Weg, den einer unserer Kunden, ein deutsches Versicherungsunternehmen, eingeschlagen hat, um seine Agile/DevOps-Ziele für SAP und operative Exzellenz zu erreichen.
Ein Hintergrund zum agilen SAP-Wandel!
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-Änderungen manuell verwaltet und waren stark fragmentiert.
Das Unternehmen verwaltete Anforderungen und Vorfälle in JIRA und ServiceNow. Es gab jedoch keinen automatischen Informationsaustausch zwischen diesen Tools und SAP. Daher mussten die Entwickler ihre SAP-Transporte mühsam manuell dokumentieren, indem sie Daten kopierten und einfügten usw. Trotz aller Bemühungen wurden nur etwa 80 % davon 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 zeitraubende Aufgaben für Systementwickler und -tester, die viel Zeit mit manuellen Prozessen verbringen mussten. Die tägliche Arbeit beinhaltete viele mühsame, lästige Aufgaben für die Leute, die mit der Systementwicklung und dem Testen beschäftigt waren, da sie viel Zeit mit der Erfüllung des Prozesses verbringen mussten.
- Verzögerungen beim Erreichen agiler/DevOps-Ziele für SAP, da manuelle Schritte die Bereitstellung von Änderungen verlangsamten.
- Auswirkungen auf die Qualität
Es war sinnvoll für sie, nach einer Lösung zu suchen, die die Lücke schließen könnte – ein Tool, das ihre Prozesse auch in ihren SAP-Landschaften durchsetzen und automatisieren würdes den Änderungsprozess so weit wie möglich zu unterstützen. Außerdem wollten sie TOSCA automatisiert auf SAP nutzen, um die DevSecOps-Kette zu schließen.
Sprint 1 – Rev-Trac-Implementierung
Ihre Reise zu DevSecOps begann 2019 mit einer eigenständigen Implementierung von Rev-Trac Platinum.
Rev-Trac ging weniger als drei Monate nach Unterzeichnung der Verträge in Betrieb. Die Implementierung umfasste Administratorschulungen, Workflow-Konfiguration und Endbenutzerschulungen.
Dieser erste Sprint stellte Prozesskonsistenz sicher und erhöhte die Compliance, da Rev-Trac sicherstellt, dass ein Ticket einem Transport zugewiesen wird und diesen Prozess durchsetzt. Dennoch waren einige manuelle Aufgaben erforderlich, beispielsweise die Zuweisung von ServiceNow-Änderungsanforderungen zum Rev-Trac-Ticket und umgekehrt.
Sprint 2 – ServiceNow-Integration
ServiceNow verwaltet Vorfälle als eine Quelle für Änderungen. Vor der Inbetriebnahme erfordert der Prozess eine ServiceNow-Änderungsanforderung, um CAB-Genehmigungen zu erhalten.
Die Integration von ServiceNow mit Rev-Trac über REST-APIs bietet erhebliche Vorteile:
- Automatisieren Sie den Prozess weiter, indem Sie Rev-Trac-Tickets aus ServiceNow generieren
- Compliance verschärfen: SAP-Änderungen sind nur mit zugewiesenem ServiceNow-Ticket möglich
Die Konfiguration dauerte nach einigen organisatorischen Hürden zum Herstellen von Netzwerkverbindungen etwa zwei Tage.
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
ServiceNow bearbeitete jedoch nur Vorfälle, wodurch eine Lücke entstand. Neue Anforderungen werden in Jira geplant und weiterhin manuell gepflegt. Daher war die Integration von Jira in Rev-Trac Sprint 3 der logische nächste Schritt.
Um diese Lücke zu schließen, definierten sie in Jira-Problemen, wo eine Verbindung zu Rev-Trac hergestellt werden sollte. Für diese Integration wählten sie Subtasks. Das Ergebnis war eine bidirektionale Integration, die Jira und Rev-Trac zum richtigen Zeitpunkt im Prozess aktualisierte.
Der Prozess beginnt mit der Erstellung eines Rev-Trac-Tickets, sobald eine Subtask vom Typ „Rev-Trac“ in Jira erstellt wurde. Das Rev-Trac-Ticket enthält Verweise (mit Links) auf die Jira-Subtask und deren übergeordnetes Element (normalerweise die User-Story) und die Jira-Subtask erhält einen Link zum Rev-Trac-Ticket und allen Statusaktualisierungen.
Letzter Schritt zu SAP DevSecOps
Sprint 4 – Tricentis Tosca Integration
Bei Tosca an Ort und Stelle, es Sinn macht integrieren inzu einheitliche Toolchain, die Rev-Trac, Jira und ServiceNow umfasst.
Technisch kann Rev-Trac Tosca anrufen um automatisierte Testskripte auszuführen. Tosca gibt die resultund der Rev-Trac Workflow-Ergebnis basierend auf dem Ergebnis.
Zum Zeitpunkt des Schreibens befindet sich Sprint 4 noch in der Planungsphase.
Kontakt einen unserer Change-Management-Experten für weitere Informationen zu Rev-Trac Platinumbidirektionale Integration mit beliebten ITSM- und ALM-Tools.
