Operational Debt entsteht in SAP-Landschaften durch viele einzelne Entscheidungen, die zum jeweiligen Zeitpunkt völlig sinnvoll waren.
Die Hotfix-Transportroute wurde während eines Notfalls eingerichtet und war damals die richtige Lösung. Die direkte RFC-Verbindung wurde erstellt, als die Middleware nicht verfügbar war. Sie funktionierte, also blieb sie bestehen. Eine Berechtigungsrolle wurde aus der Konfiguration des vorherigen Consultants kopiert, weil ein vollständiger Neuaufbau eine weitere Woche gedauert hätte.
Keine dieser Entscheidungen war für sich genommen zwingend falsch.
Die eigentliche Schuld entsteht durch ihre Summe und dadurch, dass sie sich über Jahre hinweg weiter aufbauen.
Die folgenden Anzeichen sind keine katastrophalen Systemfehler. Es handelt sich um Architekturmuster, die langsam zusätzliche Betriebskosten erzeugen, bei Incidents Stunden an Analysezeit verursachen und jede Systemänderung komplizierter machen, als sie sein müsste.
Jedes dieser Muster ist leicht erkennbar.
Die meisten SAP-Landschaften weisen mindestens drei davon auf.
Anzeichen 1. SM59 enthält RFC-Destinationen, deren Verbindungstest fehlschlägt, und niemand weiß, ob sie noch benötigt werden
Öffnen Sie SM59 in Ihrem Produktionssystem. Führen Sie den Verbindungstest für jede RFC-Destination vom Typ 3 aus. Zählen Sie, wie viele davon fehlschlagen. Fragen Sie anschließend das Team, welche dieser Destinationen sicher gelöscht werden können.
In den meisten Landschaften, die seit mehr als vier Jahren betrieben werden, lautet die ehrliche Antwort: Wir sind uns nicht sicher.
Verbindungen wurden im Rahmen von Projekten, dringenden Integrationen, Migrationen oder Consulting-Einsätzen angelegt, die längst beendet sind. Das Zielsystem wurde möglicherweise bereits stillgelegt.
Es kann aber ebenso gut noch existieren und aktiv Aufrufe von einem Programm erhalten, das durch den Verbindungstest nicht abgedeckt wird.
Die operative Konsequenz sind nicht die toten Verbindungen selbst.
Das Problem ist das unsichtbare Netz an Abhängigkeiten, das sie repräsentieren.
Wenn ein verbundenes System stillgelegt wird, wissen die Verantwortlichen für die Decommissioning-Entscheidung möglicherweise nicht, dass noch drei RFC-Destinationen in Produktion darauf zeigen.
Sie erfahren davon erst, wenn ein Interface in Produktion ausfällt und die Analyse schließlich zu einer Destination führt, die noch immer einen Server anspricht, der längst nicht mehr existiert.
Ein SM59-Audit, das jede Destination, den Owner, das Datum des letzten erfolgreichen Aufrufs und den unterstützten Business-Prozess dokumentiert, benötigt ungefähr einen halben Tag.
Es beseitigt diese Unsicherheit dauerhaft und zeigt klar, welche Verbindungen bereinigt werden können und welche echte operative Abhängigkeiten darstellen, die überwacht werden müssen.
Anzeichen 2. Der Batch-Plan existiert in SM36, in einem Spreadsheet und im Service-Management-Tool, aber keine Version stimmt mit der anderen überein
Dies ist eine der häufigsten Formen von Operational Debt im SAP Batch Management.
Der offizielle Zeitplan befindet sich in SM36. Ein Projekt hat vor drei Jahren zusätzlich ein Spreadsheet zur Nachverfolgung erstellt, das seit dem letzten Consultant-Wechsel nicht mehr aktualisiert wurde. Im ITSM existieren wiederkehrende Tasks für besonders kritische Jobs, die ursprünglich für SLA Tracking angelegt wurden und den damaligen Zeitplan abbilden, nicht den heutigen.
Wenn ein Job geändert wird, werden vielleicht ein oder zwei dieser drei Stellen aktualisiert.
Die anderen beginnen zu driften.
Ein Job, der von 03:00 Uhr auf 02:00 Uhr verschoben wurde, kann weiterhin einen ITSM Task besitzen, der jeden Morgen um 04:30 Uhr die erfolgreiche Ausführung prüft. Niemand hat den Task angepasst, und die Kontrolle funktioniert weiterhin auf Basis eines Referenzwerts, der längst nicht mehr korrekt ist.
Die operativen Kosten werden sichtbar, sobald etwas schiefläuft.
Die Analyse verwendet das Spreadsheet oder den ITSM Task als Referenz statt SM36, weil diese Informationen schneller zugänglich sind.
Die Referenz ist falsch.
Die Untersuchung verfolgt die falsche Richtung.
Zusätzliche 45 Minuten Analysezeit fallen in einem einzelnen Post-Incident-Review kaum auf. Über ein gesamtes Quartal summieren sich diese Stunden jedoch deutlich.
Anzeichen 3. Die „Hotfix“-Transportroute wird häufiger genutzt als der reguläre Weg von Entwicklung über QA nach Produktion
Fast jede SAP-Transportlandschaft besitzt oder besaß irgendwann eine Hotfix-Route.
Sie ermöglicht es, Transporte aus einem Korrektursystem direkt in Produktion zu bringen und dabei den regulären Quality Gate zu umgehen.
Diese Route existiert aus legitimen Gründen: Eine SAP Note muss sofort eingespielt werden, eine gesetzliche Änderung besitzt ein festes Wirksamkeitsdatum oder eine dringende Korrektur kann nicht bis zum nächsten Release-Zyklus warten.
Operational Debt entsteht, wenn diese Hotfix-Route zum Standardweg für einen erheblichen Anteil der Transporte wird.
Das Team verwendet den regulären Weg Entwicklung, QA, Produktion nicht mehr für die meisten Changes, weil QA drei Versionen hinterherhinkt, weil der Testing-Zyklus länger dauert, als das Business warten möchte, oder weil der Freigabeprozess des regulären Transportwegs selbst zum Bottleneck geworden ist.
In diesem Fall ist der Quality Gate kein wirklicher Gate mehr.
Er ist lediglich eine optionale Station für Changes, die als nicht dringend gelten, was in der Praxis häufig bedeutet, dass fast nichts mehr regulär darüber läuft.
Die Konsequenz ist im Transportsystem selbst nicht sichtbar. Dort erscheinen alle Transporte als freigegeben und importiert.
Sie wird bei Produktions-Incidents sichtbar, wenn ein Change nicht in einer Umgebung getestet wurde, die die Produktion ausreichend realistisch abbildet, und ein Fehler, der in QA hätte erkannt werden können, stattdessen von einem Anwender entdeckt wird.
Anzeichen 4. Qualitäts- und Produktionssystem laufen auf unterschiedlichen HANA-Versionen oder ihre Datenvolumen unterscheiden sich um mehr als eine Größenordnung
QA soll Probleme erkennen, bevor sie Produktion erreichen.
Der Wert eines QA-Systems hängt deshalb vollständig davon ab, wie realistisch es die Produktionsbedingungen abbildet.
Ein QA-System mit einer älteren HANA-Version oder lediglich 15 % des Produktionsdatenvolumens bietet eine andere Art von Absicherung als ein System, das Produktion möglichst eng entspricht.
Der typische Fehlermodus ist ein Problem, das sich in QA nicht reproduzieren lässt.
Ein Performance-Problem, das nur bei realistischen Produktionsdatenmengen auftritt, kann in einer Kopie mit 15 % des Datenvolumens nicht sinnvoll getestet werden.
Eine Verhaltensänderung aufgrund unterschiedlicher HANA-Versionen zwischen QA und Produktion wird möglicherweise erst sichtbar, nachdem das Produktionssystem aktualisiert wurde.
Beide Probleme benötigen einen Produktions-Incident, um überhaupt entdeckt zu werden.
Die organisatorische Reaktion lautet anschließend: „Das hätte in QA erkannt werden müssen.“
Die technische Antwort lautet: „Mit der aktuellen QA-Konfiguration konnte es dort nicht erkannt werden.“
Nichtproduktive Systeme ausreichend eng an Produktion auszurichten, erfordert Budget, Planung und operative Disziplin.
Das Budget für regelmäßige Systemkopien und Versionsangleichungen wird jedoch häufig zugunsten sichtbarerer Projektinvestitionen reduziert.
Die Operational Debt wächst jedes Mal, wenn ein Produktionsproblem in einer realistisch gepflegten QA-Umgebung hätte erkannt werden können, es aber nicht wurde.
Anzeichen 5. Berechtigungsrollen sind Kopien von Kopien und niemand kann erklären, warum bestimmte Transaktionen enthalten sind
Bitten Sie den Berechtigungsadministrator zu erklären, warum ein bestimmter Transaktionscode in einer kritischen Rolle enthalten ist.
Lautet die Antwort „er war schon in der Rolle, als wir sie kopiert haben“ oder „ich glaube, ein Consultant hat ihn irgendwann für eine bestimmte Anforderung hinzugefügt“, besteht Authorization Debt.
Der Mechanismus ist einfach.
Eine Rolle wird durch Kopieren einer SAP-Standardrolle erstellt. Anschließend wird sie an einen konkreten Use Case angepasst.
Später wird eine ähnliche Rolle benötigt und statt erneut von der Standardrolle auszugehen, wird die bereits modifizierte Rolle kopiert.
Die Kopie übernimmt sämtliche Anpassungen der ersten Rolle, einschließlich Berechtigungen, die ausschließlich für den ursprünglichen Use Case relevant waren und im zweiten Szenario nicht benötigt werden.
Anschließend wird die zweite Rolle für einen dritten Anwendungsfall kopiert.
In der vierten Generation enthält die Rolle Berechtigungen aus drei verschiedenen Use Cases, die sich seit ihrer ursprünglichen Erstellung möglicherweise ebenfalls verändert haben. Niemand kann mehr vollständig nachvollziehen, warum jede einzelne Berechtigung enthalten ist.
Das ist nicht zwingend ein Security Incident im Sinne eines unautorisierten Zugriffs.
Es ist ein Governance-Problem, das Access Reviews weniger aussagekräftig macht und Audit Findings praktisch vorprogrammiert.
Die Rolle enthält mehr Berechtigungen als notwendig, aus Gründen, die niemand dokumentieren kann, innerhalb eines Systems, das unter Umständen kritische Finanztransaktionen verarbeitet.
Anzeichen 6. Kundeneigene ABAP-Erweiterungen sind nicht dokumentiert und die Person, die sie entwickelt hat, arbeitet nicht mehr im Unternehmen
Die Erweiterung existiert. Sie verändert SAP-Standardverhalten. Sie läuft seit vier Jahren in Produktion.
Dann wird ein neues ABAP Enhancement Package installiert und eine SAP-Standardfunktion verändert sich.
Die Erweiterung funktioniert nicht mehr.
Das Team öffnet den Code und stellt fest, dass keine Kommentare vorhanden sind, nicht standardisierte Techniken verwendet werden und direkt auf Datenbanktabellen zugegriffen wird, obwohl SAP-Standard-APIs dieselbe Funktion sauberer bereitgestellt hätten.
Die Behebung benötigt dreimal so lange wie bei einer gut dokumentierten Erweiterung, weil das Team zunächst die ursprüngliche Intention rekonstruieren muss, bevor überhaupt eine Lösung entwickelt werden kann.
Auch das Risiko des Fixes ist höher, weil die ursprünglichen Design Constraints nicht mehr bekannt sind.
Dieses Muster verschärft sich mit jedem Upgrade der Landschaft, jeder Änderung an einem Standardprogramm, von dem die Erweiterung abhängt, und jedem neuen Consultant, der im Code eine nicht dokumentierte Funktion entdeckt, von deren Verhalten das Business längst abhängig ist, ohne überhaupt zu wissen, dass sie kundenspezifisch ist.
Operational Debt entsteht nicht durch die bloße Existenz von Custom ABAP.
Sie entsteht durch Custom ABAP ohne Dokumentation.
Das eine ist eine Architekturentscheidung.
Das andere ist eine langfristige Maintenance Liability, deren Kosten mit jeder Systemänderung weiter steigen.
Anzeichen 7. Die Liste der „Known Issues“ wächst seit zwei Jahren in jedem Quartal und wird nie kürzer
Jedes SAP-Operations-Team besitzt eine Liste bekannter Probleme.
Darauf stehen beispielsweise fehlgeschlagene SM37-Jobs aus einem 2021 abgebrochenen Migrationsprojekt, die eigentlich bereinigt werden müssten. Eine RFC-Destination zum bereits stillgelegten CRM-System, die weiterhin in SM59 auftaucht. Ein Development Client, der vor sechs Monaten versehentlich geöffnet und nie wieder gesperrt wurde. Ein Background Job, der während eines Incidents manuell abgebrochen und anschließend nie neu eingeplant wurde.
Die Liste wächst, weil die Behebung dieser Punkte Aufwand benötigt und gegenüber der aktuell dringenden Arbeit immer eine niedrigere Priorität besitzt.
Jeder einzelne Punkt ist klein genug, um verschoben zu werden.
Zusammen bilden sie jedoch das explizite Schuldenregister der Landschaft: eine dokumentierte Liste bekannter Fehlzustände, die vom Team als permanentes Hintergrundrauschen akzeptiert wurden.
Die operativen Kosten liegen nicht nur in den Punkten selbst.
Sie beeinflussen jede Incident-Analyse.
Tritt ein neuer Fehler in einer Landschaft mit 40 bekannten Problemen auf, lautet eine der ersten Fragen, ob der Incident mit einem dieser Known Issues zusammenhängt.
Dieser zusätzliche Schritt, zu überprüfen, ob ein neuer Incident mit einem bestehenden bekannten Problem verbunden ist, verlängert jede Analyse, wenn die Liste so lang geworden ist, dass sie selbst zu einem umfangreichen Referenzdokument geworden ist.
| In der Praxis: Eine Known-Issues-Liste, die seit zwei Jahren nicht kleiner geworden ist, ist kein echter Backlog mehr. Sie bedeutet, dass diese Zustände faktisch als permanent akzeptiert wurden. Die richtige Reaktion besteht nicht darin, sofort alle Punkte zu schließen. Stattdessen sollte explizit entschieden werden, welche Zustände dauerhaft toleriert werden können, inklusive dokumentierter Begründung, und welche innerhalb eines definierten Zeitplans behoben werden sollen. Eine aktiv verwaltete Liste erzeugt selbst bei langsamer Bearbeitung weniger operative Reibung als eine Liste, die unbegrenzt wächst, weil ihr Inhalt implizit als normal akzeptiert wurde. |
|---|
Operational Debt in SAP-Landschaften ist kein Zufall und entsteht in der Regel nicht durch schlechte Absichten.
Sie ist das kumulierte Ergebnis sinnvoller Entscheidungen, die unter realen Einschränkungen getroffen wurden und über Jahre bestehen bleiben, ohne regelmäßig überprüft oder bereinigt zu werden.
Ein Review, der diese Anzeichen identifiziert, benötigt keine langwierige Architekturberatung.
Es genügt, die Landschaft mit einer anderen Frage zu betrachten: Welche Muster erzeugen tatsächlich zusätzliche operative Kosten, statt nur danach zu fragen, welche Architektur theoretisch am elegantesten ist?
Die meisten der oben beschriebenen Anzeichen lassen sich innerhalb eines halben Tages erkennen, wenn die richtigen Transaktionen und Informationsquellen geprüft werden: SM59, SM36, SE01, PFCG und die eigene Known-Issues-Liste des Teams.
Entscheidend ist anschließend, die Ergebnisse als konkrete Handlungsfelder zu behandeln und nicht als normalen Hintergrundzustand eines Systems, das seit vielen Jahren betrieben wird.
Operational Debt verschwindet nicht von selbst.
Redpeaks macht mehrere dieser Operational-Debt-Indikatoren kontinuierlich sichtbar: Zustand von RFC-Verbindungen, Integrität von Batch-Zeitplänen, Berechtigungsänderungen und Configuration Drift gegenüber dokumentierten Baselines.
