Alles unter Kontrolle beim SAP Änderungs- und Release-Prozess? Teil 1

Einleitung

Vielleicht glauben Sie, Sie hätten Ihren Änderungs- und Release-Prozess für SAP vollständig unter Kontrolle. Wer gibt schon zu, dass er Änderungen in die Produktion überführen würde, wenn dem nicht so wäre? In zwanzig Jahren Arbeit mit SAP habe ich allerdings einige Fälle erlebt, die nicht gerade Lehrbuchcharakter hatten – und ich hatte vielleicht sogar meinen Anteil daran. Möglicherweise wissen Sie es auch einfach nicht so genau, weil sich das Basis-Team darum kümmert. Sei‘s drum, ich werde in diesem Blogbeitrag jedenfalls einige Szenarien beschreiben, die häufig vorkommen – in Unternehmen, die nicht alles unter Kontrolle haben. Hoffentlich hilft Ihnen dieser Beitrag, sich darüber klar zu werden, wo Ihr Unternehmen steht und ob Sie, ohne es zu wissen, unnötige Risiken eingehen, die im schlimmsten Fall zu erheblichen Ausfällen in Ihren Produktionssystemen führen können. 

Vielleicht haben Sie auch Probleme, an die Informationen zu gelangen, die zur Beantwortung der von mir gestellten Fragen nötig sind. Eine solche Situation würde schon für sich sprechen und zeigen, dass Sie nicht alles so unter Kontrolle haben, wie es sein sollte oder wie Sie es gern hätten.

Ich werde nicht auf die allgemein bekannten „Kernelemente“ eines robusten Änderungs- und Release-Prozesses eingehen – wie automatisierte Prüfungen, Workflows, Benachrichtigungen, Genehmigungen und die Integration mit anderen Tools. Ich setze diese Dinge einfach mal als bekannt voraus (wenn dies in Ihrem Unternehmen nicht der Fall ist, würde ich sagen, dass die Frage in der Überschrift bereits beantwortet ist). Stattdessen werde ich mich auf ein paar häufige Grenzfälle konzentrieren,auf die unsere Kunden stoßen, bevor sie ActiveControl, die DevOps-Automatisierungssoftware von Basis Technologies, implementieren. In Teil 1 des Blogs werde ich mich mit entwicklungsbezogenen und in Teil 2 mit Szenarien der Produktivumgebung befassen. 

Gewährleisten der Integrität Ihrer Entwicklungssysteme

Ein gut verwaltetes Entwicklungssystem ist die Grundlage für einen robusten, sicheren und qualitativ hochwertigen Lebenszyklus bei der Anwendungsentwicklung. Ein typisches SAP-Entwicklungssystem wird von vielen Teammitgliedern gemeinsam genutzt (in großen Unternehmen sogar von Hunderten von Mitarbeitern), und häufig fehlt es da ein bisschen an Pflege und Zuwendung. Während meiner beruflichen Laufbahn sind mir drei wichtige Bereiche aufgefallen (zweifellos gibt es noch viele andere), die den Aufbau eines soliden ALM-Fundaments untergraben können. 

1. Nicht freigegebene Customizing-Transporte, die älter als ein paar Tage sind

Anders als bei Workbench-Objekten gibt es für Änderungen an Customizing Objekten keinen Sperrmechanismus. Im Transportauftrag wird nur der Schlüssel erfasst (Änderungen jedoch nicht). Bei Freigabe des Transports wird ein Snapshot der zum Schlüssel gehörenden Felder in Transportdateien geschrieben. Erst zu diesem Zeitpunkt wird die Änderung „eingesperrt“.

Daher kann es relativ leicht passieren, dass bei Freigabe eines seit einiger Zeit offenen Customizing-Auftrags etwas Unerwartetes oder Ungetestetes mit in den Transport eingeschlossen wird. Dies kann dazu führen, dass unbeabsichtigte Änderungen ohne Wissen des Änderungsverantwortlichen oder Entwicklers ins Produktionssystem gelangen, was wiederum zu Produktionsausfällen führen kann. Es ist schwer genug, Ausfälle zu diagnostizieren und zu beheben. Ungleich schwieriger wird es jedoch, wenn nicht einmal die für die Änderung zuständigen Personen wissen, was in den Änderungen enthalten ist! 

Welche Fragen sollte ich beantworten können

• Können Sie erkennen, wie viele nicht freigegebene Änderungen in Ihrem Entwicklungssystem vorhanden sind und wie alt sie sind (1 Woche, 1 Monat, 6 Monate usw.)?
• Wer ist für diese Änderungen verantwortlich (Funktionsbereich, Partnerunternehmen usw.)?
• Wie können Sie den Fortschritt messen, wenn Sie die Anzahl älterer, nicht freigegebener Änderungen reduzieren?
• Werden Entwickler vor einem möglichen Konflikt gewarnt, wenn sie die Konfiguration ändern, die gleichzeitig auch von anderen geändert wird?

Was ActiveControl für Sie tun kann

• Über die Berichterstattung, die mit nur wenigen Klicks verfügbar ist, kann jedes Teammitglied nachvollziehen, welche Arbeiten gerade ausgeführt werden und wo bestimmte Aktivitäten möglicherweise noch nicht abgeschlossen sind. Mit diesen Informationen – die sonst aus Spreadsheets zusammengetragen werden müssten (sofern sie überhaupt dokumentiert sind) – kann ein Prozess gesteuert werden, der den Umfang der in Arbeit befindlichen Konfiguration und das Risiko begrenzt, das mit der Übertragung einer fehlerhaften Änderung ins QA-System einhergeht. 
• Automatische Benachrichtigungen verbessern diesen Prozess. Sie warnen den Zuständigen und/oder den Entwickler der Änderung, dass für einen bestimmten Zeitraum etwas offen gelassen wurde. Wenn innerhalb dieser Zeit keine Maßnahmen ergriffen werden, kann automatisch eine Eskalations-E-Mail an den Projektmanager oder Systemverantwortlichen ausgelöst werden.
• Wenn ein Entwickler ein Customizing-Objekt oder einen Schlüssel ändert, wird die Warnung ausgegeben, dass eine offene Änderung und ein potenzieller Konflikt vorliegt.

2. Entwicklungssystem als Sandbox

Ein Sandbox-System wird verwendet, um eine Lösung zu untersuchen, neue Ideen auszuprobieren oder Geschäftsfunktionen und Add-Ons zu aktivieren, die möglicherweise nicht rückgängig gemacht werden können. Viele Unternehmen arbeiten damit. Eine Sandbox ist ein bisschen Wildwest, und das soll auch so sein. Eigentlich ist es sogar der Sinn der Sache. Zum Problem wird es erst dann, wenn das Entwicklungssystem – was nur allzu oft geschieht – gleichzeitig als gemeinsame Entwicklungsumgebung und für Sandkastenspiele verwendet wird. 

In einer Sandbox-Umgebung werden häufig nicht autorisierte Änderungen (ohne genehmigte Änderungsanforderung) am Entwicklungssystem vorgenommen. In diesem Fall besteht das Risiko, dass das System wiederhergestellt werden muss, dass Entwicklungsaktivitäten gestört oder unbeabsichtigte Änderungen ohne Kontrollmechanismus entwickelt werden. 

Welche Fragen sollte ich beantworten können

• Haben Sie eine Richtlinie für den Einsatz einer permanenten oder temporären Sandbox?
• Können Sie feststellen, ob Personen ohne Berechtigung Änderungen am Entwicklungssystem vornehmen?

Was ActiveControl für Sie tun kann

• Bei entsprechender Konfiguration gelangen nur genehmigte Arbeiten ins System. Sie können sicherstellen, dass Transporte nur dann im Entwicklungssystem erstellt werden können, wenn sie mit einem genehmigten Auslöser (Änderungsanforderung, Vorfall usw.) verknüpft sind.
• ActiveControl bietet einen flexiblen Transportwege Editor. Es ist sehr einfach, Systeme zu Transportwegen hinzuzufügen und aus ihnen zu entfernen. Es erfordert also nur minimalen Aufwand, temporäre, experimentelle Systeme einzurichten oder stillzulegen. Das Tool kann fehlende Transporte automatisch identifizieren und so sicherstellen, dass jedes System „aktuell“ ist – je nach seiner Position im Pfad.

3. Angemessener Umgang mit kritischen Objekten

In SAP-Landschaften jeder Größe gibt es eine Reihe von Objekten, die für den ordnungsgemäßen Betrieb entscheidend sind (Fabrikkalender, Tabellen mit sensiblen Daten, Programme, die als Hintergrundjobs in der Produktion ausgeführt werden, kritische Abrechnungsschnittstellen und SAP-OSS-Hinweise – um nur einige Beispiele zu nennen).

Dabei kann es sich auch um benutzerdefinierte Objekte handeln. Unabhängig davon müssen sie jedoch mit mehr Sorgfaltgehandhabt werden, weil sie ein höheres Risiko als andere Objekte bergen. Die Beschädigung kritischer Objekte kann schwerwiegende Folgen nach sich ziehen. – Ich habe schon viele Unternehmen erlebt, die Änderungen in ihrer Landschaft im Blindflug vorgenommen haben, ohne riskante Änderungen von harmlosen zu unterscheiden.

Welche Fragen sollte ich beantworten können

• Sind die kritischen Objekte Ihrer Lösung dokumentiert? 
• Woher wissen Sie, ob ein Transport eines dieser Objekte enthält? 
• Gibt es einen „erweiterten“ Prozess, der für Transporte erzwungen wird, die diese Objekte enthalten? 

Was ActiveControl für Sie tun kann

• Die Funktion Risk Guard markiert alle Transporte mit Objekten, die als kritisch oder riskant identifiziert wurden. Dazu gehören z. B. Änderungen an Buchungskreisen, Nummernkreisen oder geplante Änderungen. Sie können Objekte mit hohem Risiko automatisch kennzeichnen lassen und bestimmte Genehmigungen auf Basis ihres Risikogrades erzwingen.
• Die Analysefunktion „Impacted Batch Jobs“ signalisiert, welche geplanten Batch-Jobs von den in SAP-Transporten ausgelieferten Objekten betroffen sein können. Sie haben dann die Möglichkeit, die Übernahme von Änderungen in die Produktion zu unterbinden, wenn die Ausführung kritischer Batch-Jobs geplant ist. Sie können die Aufteilung von Transporten in geeigneter Weise erzwingen, um zu vermeiden, dass bestimmte Objekttypen gemischt werden.

Dies sind für mich die drei wichtigsten Problembereiche im Änderungsmanagement, über die Sie sich zu Beginn des Prozesses in Ihren Entwicklungssystemen Gedanken machen müssen. Hoffentlich konnte ich Ihnen einige Anregungen vermitteln. Wenn Sie mehr darüber erfahren möchten, wie ActiveControl dazu beitragen kann, die gestellten Fragen zu beantworten und eine solide Grundlage für Ihren gesamten ALM-Prozess zu schaffen, fordern Sie einfach eine Demo an.

Wie ich bereits erwähnt habe, ist das noch nicht das Ende der Geschichte. Unabhängig davon, wie viel Zeit und Mühe Sie sparen können, wenn Sie mit einem „sauberen“ Änderungs- und Release-Prozess beginnen: Das Entscheidende sind die Produktionssysteme. Lesen Sie deshalb auch den zweiten Teil dieses Blogs. Ich stelle darin einige wichtige Überlegungen vor, die enger mit Live-Systemen und der Bereitstellung von Änderungen zusammenhängen.