In Teil 1 dieser Serie haben wir den Rahmen dafür gesetzt, wie das Autonomous Enterprise die Arbeit im Change Management neu definiert. Klassische Transports und die Changes, die sie ausliefern, bewegen sich jetzt in einer Welt, in der intelligente Agents die nachgelagerten Konsumenten sind. Change Management ist nicht kleiner geworden. Es ist spannender geworden.
Was bedeutet die SAP Business AI Platform für diese sich wandelnde Landschaft? In Teil 2 analysiere ich die erweiterte Change-Fläche selbst. Sie ist nicht mehr nur die Umgebung, in der intelligente Agents arbeiten; sie steht für eine deutliche Ausweitung des Territoriums, das Governance abdecken muss.
BTP, Business Data Cloud, und Business AI unter einer einzigen Plattform zu bündeln, verschafft Unternehmen nicht nur neue Fähigkeiten. Es erweitert den Umfang von Governance, Nachvollziehbarkeit und Change Control weit über die traditionelle ERP-Grenze hinaus – und vermutlich weit über das hinaus, wo viele SAP-Change-Management-Praktiken heute stehen.
Warum SAP Agent Governance bei ERP Change Control beginnt
SAP hat sich intensiv mit Agent Governance beschäftigt, aber die vollständige Change-Story muss auch die darunterliegenden Systeme einbeziehen.
Beim Lesen von SAPs Ankündigung sieht man, wie viel Aufwand in die Governance von Agent-Aktivitäten geflossen ist. Das Kern-Framework ist architektonisch in sich schlüssig:
- Der Knowledge Graph: Gibt Agents strukturierten Business-Kontext
- Joule Studio: Versioniert Agent-Definitionen
- NVIDIAs OpenShell: Stellt eine „trusted secure runtime“ bereit
- Vollständige Action-Traceability: Ein Audit Trail für jede Agent-Aktion
Der nächste Schritt ist, das gleiche Governance-Niveau auf die alltäglichen ERP-Systeme zu übertragen, auf die der Agent angewiesen ist, um Arbeit zu erledigen. Agents erfinden keine Fähigkeiten; sie rufen sie auf. Ein Joule Assistant, der Bestellungen anlegt, lebt weiterhin in VA01 oder nutzt kundeneigene Z-Programme, die jemand 2014 (oder 2004!) geschrieben hat.
Die Kompetenz des AI-Agents ist an die Fähigkeiten des darunterliegenden Core-Systems gebunden. Und dieses System verändert sich ständig. Genau deshalb gibt es überhaupt Transport Management und einen Release-Kalender.
Die Frage ist also: Wenn ein Basis-Team am Freitag einen Transport ausliefert, der das Verhalten einer Z-Transaktion verändert – was passiert am Montag, wenn der Agent, der von dieser Transaktion abhängt, seine Arbeit erledigen soll? Und jetzt, da die Mitarbeitenden, die diese Tätigkeiten früher ausgeführt haben, auf höherwertige Aufgaben gehoben wurden: Wer behält die Produktion im Blick?
Die wachsende SAP Change-Fläche: 5 neue Change-Vektoren
Die SAP Business AI Platform erweitert den Change-Umfang auf eine Weise, die nicht immer offensichtlich ist. Mehrere der neuen Change-Vektoren liegen außerhalb dessen, was die meisten Teams heute unter „SAP Change Management“ verstehen. Hier sieht man, wo sich die Fläche ausdehnt.
- Der Knowledge Graph
Eine Kostenstellen-Reorganisation, ein neuer Buchungskreis – der Knowledge Graph bildet das alles ab. Agents lesen aus dem Knowledge Graph, um zu wissen, was zu tun ist. Eine Konfigurationsänderung, die früher als „geringe Auswirkung, nur ein Customizing-Eintrag“ galt, verändert jetzt das Agent-Verhalten auf eine Weise, die sich möglicherweise erst zur Laufzeit zeigt. Customizing hatte schon immer Auswirkungen; neu ist, dass der Wirkbereich größer ist und die Konsequenzen manchmal erst im Nachhinein sichtbar werden.
2. Die Datenebene
Business Data Cloud führt das, was früher viele getrennte Daten-Dialoge waren, in einem einzigen Plattform-Dialog zusammen. Das ist eine gute Nachricht, um Daten zu Agents zu bringen. Für Governance ist es eine komplexere Nachricht. Data-Product-Definitionen, Sharing Agreements, Refresh Schedules, Lineage Assertions – das sind alles Changes, die das Agent-Verhalten beeinflussen, und die meisten davon liegen außerhalb der klassischen ABAP-Transport-Grenze. Wenn Ihre Change-Praxis an der SAP-Systemgrenze endet, haben Sie möglicherweise eine Lücke.
3. SAP BTP Development
ABAP Cloud, Side-by-Side Extensions, Integration Suite, kundeneigene Tools, die in Joule Studio registriert sind – nichts davon ist im klassischen Sinne „in S/4HANA“, aber alles liegt auf derselben Skala der Change-Kritikalität. Eine fehlerhaft arbeitende BTP-Extension wirkt sich auf einen Agent genauso sicher aus wie ein kaputtes Z-Programm. Die Business AI Platform verlagert zudem mehr Business-Logik in diese Ebene.
Eine wirklich moderne Transport-Management-Strategie erfordert eine einzige Lösung über klassisches ABAP und cTMS hinweg – mit vollständiger Orchestrierung und Dependency Management für lose gekoppelte Komponenten. Ohne das riskieren Sie die unvermeidliche Rückkehr zu Excel und die Abhängigkeit von manueller Kontrolle.
4. Dynamische Agent-Definitionen
Agent-Definitionen bleiben Changes. Darauf sind wir in Teil 1 eingegangen, aber im Plattform-Kontext muss man es noch einmal klar sagen: Prompts, Guardrails, Tool-Berechtigungen und Grounding-Konfigurationen, die in Joule Studio versioniert werden, sind in jeder Hinsicht audit-relevante Changes. SAP liefert Native Versioning, aber es liegt an SAP-Managern sicherzustellen, dass Change mit denselben Controls und derselben Disziplin gemanagt wird wie der Rest der SAP-Landschaft.
5. Autonome Migrationstools
Migrationstools sind jetzt selbst ein Change-auslösender Agent. SAP hat agentengeführte Transformationstools angekündigt, um Systemanalyse, Code Remediation, Konfiguration, und Tests zu automatisieren. Das ist autonomer Code-Change. Der Migrations-Agent ist selbst eine Change-ausführende Entität, die über Landscape-Grenzen hinweg arbeitet, und er braucht dieselbe Governance, die der Rest des Systems bekommt.
Die hybride Realität: Change über Cloud, AI und On-Premises hinweg managen
Hybrid ist weiterhin der Status quo – nur noch mehr. SAP hat auf der Sapphire ausdrücklich gesagt, dass ECC- und S/4HANA-On-Premises-Kunden ausgewählte AI-Szenarien erhalten, wenn sie sich zum Übergang auf Cloud ERP verpflichten. Ebenso klar ist: Die meisten großen Kunden werden über Jahre hinweg hybrid betreiben.
Agentische Ausführungen auf Cloud ERP werden über Systemgrenzen hinweg wirken, die weiterhin durch traditionelle Basis-Disziplin gesteuert werden. Change-Management-Praktiken, die nur eine Seite dieses Zauns sehen, sind unvollständig.
AI Governance beginnt bei Agents – endet aber nicht dort
Agent Governance bekommt gerade die meiste Aufmerksamkeit – und das ist nachvollziehbar, denn Agents sind das neue und ungewohnte Element im Gesamtbild. Aber die Governance der Agents selbst ist nur einer der Change-Vektoren, der in einem Autonomous Enterprise Aufmerksamkeit braucht.
Wenn Sie nur eine Sache aus diesem Beitrag mitnehmen, dann diese: Agents erben die Disziplin (oder deren Fehlen), die auf alles angewendet wird, was sie berühren. Den Prompt zu governieren und die zugrunde liegenden Systeme nicht zu governieren, ist nur die halbe Arbeit. Die Joule-Studio-Konfiguration zu governieren und die BTP-Integration, die sie speist, nicht zu governieren, ist nur die halbe Arbeit. Die Identität des Agents zu governieren und die Stammdaten, auf die er wirkt, nicht zu governieren, ist nur die halbe Arbeit.
Die SAP Business AI Platform hat die Fläche erweitert. Die Change-Management-Praxis muss mitwachsen.
Der Umfang des Change Management ist gerade größer geworden
Die SAP Business AI Platform ist das architektonische Element, das das Autonomous Enterprise real macht. Was sie außerdem tut: Sie erweitert den Umfang des Change Management über das hinaus, wo viele Praktiken heute operieren. Das ist kein Grund, Bewährtes aufzugeben – Transport, Approval Gate, Regression Test und Audit Log werden wichtiger, nicht weniger. Was sich ändert, ist die Fläche, auf die sie angewendet werden.
SAP-CEO Christian Klein hat es von der Bühne aus gesagt: „Der Weg zum Autonomous Enterprise erfordert ernsthaftes Change Management.“ Das ernst zu nehmen heißt auch zu erkennen: Die Plattform-Erweiterung ist selbst eine Erweiterung des Change Management. Agents sind nicht das Einzige, was in dieser neuen Welt governed wird. Vielleicht sind sie nicht einmal das Wichtigste.
Als Nächstes, in Teil 3, schauen wir auf praktische Best Practices, warum ein belastbarer, sauberer Clean Core weiterhin so wichtig ist wie eh und je – und warum der Erfolg in der Cloud am Boden beginnt.
