In den ersten drei Teilen dieser Serie haben wir über den KI-Agenten als Objekt des Change Managements gesprochen: den neuen nachgelagerten Konsumenten jedes Transports, den Sie versenden, die neuen Gründe, warum ein Customizing-Eintrag mit geringer Auswirkung überhaupt keine geringe Auswirkung haben könnte, und den neuen Stakeholder, der keine Fragen stellt, bevor er auf den Zustand reagiert, den er vorfindet.
Diese Sichtweise ist zutreffend. Aber es steckt mehr dahinter.
Der folgenreichere Wandel, den die meisten SAP-Organisationen noch nicht vollständig bewältigt haben, ist der Agent als Akteur im Change-Prozess selbst.
In Teil vier zeige ich, wie Sie sich auf die Business-KI-Plattform von SAP vorbereiten können.
Wichtige Erkenntnisse
- SAP-Agenten gehen von der Unterstützung bei Änderungen dazu über, selbst Änderungen vorzunehmen, oft ungeprüft
- Agentenprotokolle und ERP-Aufzeichnungen kommunizieren nicht miteinander – hier liegt das Auditrisiko
- Die Auswirkungsanalyse muss jetzt Agenten-Ausführungspfade abdecken, nicht nur menschliche
- Hybride SAP-Landschaften sind eine dauerhafte Governance-Herausforderung, keine vorübergehende Lücke
- Die Organisationen, die sich jetzt vorbereiten, werden für das autonome Unternehmen positioniert sein
Nimmt das autonome Migrationstooling von SAP selbstständig Änderungen vor?
Das autonome Migrationstooling von SAP, das auf der Sapphire 2026 angekündigt wurde, ist das klarste aktuelle Beispiel. Es wird erweitert, um Systemanalysen, Code-Remediation, Konfigurationsarbeiten und Testgenerierung autonom durchzuführen. Das ist kein Tool, das bei Änderungen unterstützt; das ist ein Tool, das Änderungen vornimmt, über Landschaftsgrenzen hinweg agiert und in einem Tempo und Umfang, den kein menschlicher Change Manager in Echtzeit überprüfen kann.
Die Joule Assistants selbst sind nicht weit dahinter. Heute orchestrieren sie Prozesse innerhalb definierter Leitplanken. Morgen stehen Agenten, die Konfigurations- und Workflow-Änderungen vorschlagen, weiterleiten und in einigen Kontexten ausführen, auf der Roadmap von SAP.
Die sich daraus ergebende Governance-Frage wurde ursprünglich von keinem bestehenden Change-Management-Framework beantwortet: Wer genehmigt die Änderung eines Agenten?
Wenn ein Basis-Administrator am Freitag um 23 Uhr einen Transport versendet, gibt es eine Person, ein Ticket, einen Genehmigungsdatensatz und einen Audit-Trail. Wenn ein autonomer Migrationsagent um 2 Uhr morgens ein Z-Programm korrigiert oder ein Joule Assistant einen Beschaffungs-Workflow basierend auf aktualisierten Stammdaten umleitet, gilt dieselbe Frage. Der Audit-Trail kümmert sich nicht darum, ob die initiierende Entität eine Benutzer-ID oder ein Servicekonto hat. Der Auditor tut es sicherlich nicht.
Umfasst die KI-Governance von SAP auch ERP-Änderungsdatensätze?
SAP hat eine durchdachte Governance in die Business-KI-Plattform integriert. Joule Studio versioniert Agentendefinitionen. Die Aktionstraceability-Schicht zeichnet auf, was Agenten tun. NVIDIAs OpenShell bietet eine vertrauenswürdige Laufzeitumgebung. Dies sind die richtigen Investitionen.
Was sie nicht tun, ist die Lücke zu schließen zwischen dem, was der Agent getan hat, und warum das System, auf dem er operierte, ihm dies erlaubt hat. Das Aktionsprotokoll des Agenten sagt Ihnen, dass der Agent eine Bestellung aufgegeben hat. Der ERP-Änderungsdatensatz sagt Ihnen, wie die Preiskonfiguration aussah, als er dies tat. Beide Datensätze sind notwendig. Keiner der Datensätze verweist standardmäßig auf den anderen.
Die Lücke zwischen Agenten-seitiger Governance und ERP-seitiger Governance ist der Ort, an dem die Haftung liegt. Ein Agent, der nur innerhalb des Frameworks arbeitet, ist lediglich ein etwas intelligenterer RPA. Keiner von uns tätigt diese Investitionen für einen fragilen Screen-Scraping-Roboter, um weiterhin Skriptwartungsaufgaben zu produzieren. Wir wollen etwas Besseres, aber dieses Bessere erfordert ein viel robusteres und aufschlussreicheres Management.
Interne Audit-Teams, die unter SOX-, GxP- oder GDPR-Regimen arbeiten, werden einen nachvollziehbaren Datensatz anfordern, der die Agentenaktion mit dem Systemzustand und der autorisierten Änderung verknüpft. „Der Agent hat es getan“ ist keine akzeptable Antwort. Auch „SE10 scheint in Ordnung zu sein und wir haben den Joule-Audit-Trail“ ist keine, wenn diese Protokolle nicht miteinander kommunizieren und sich nicht auf die definierte Agentenautorität für Änderungen beziehen lassen.
Der Aufbau der Nachvollziehbarkeit über Änderung → Objekt → Agent → Prozess → Geschäftsergebnis erfordert mehr als native Tools auf beiden Seiten. Er erfordert einen Integrationspunkt über den gesamten Änderungslebenszyklus hinweg.
Wie verändert KI die SAP-Auswirkungsanalyse?
Das Problem der Auswirkungsanalyse ändert sich auch in einer agentenbasierten Umgebung. Heute fragt die Auswirkungsanalyse: Welche Prozesse und Benutzer sind von dieser Änderung betroffen? Diese Frage wurde in der Praxis immer unzureichend beantwortet, da die technische Analyse von statischem Code bestenfalls unvollkommen und schlimmstenfalls völlig unvollständig ist, aber das Ziel war zumindest gut definiert.
Wenn Agenten ins Spiel kommen, verschiebt sich das Ziel. Ein Transport, der eine BAPI modifiziert, betrifft nicht nur die menschlichen Benutzer und automatisierten Jobs, die sie heute aufrufen. Er betrifft jeden Agenten, der sie aufrufen könnte, jeden Prozess, den diese Agenten orchestrieren, und jedes nachgelagerte System, das diese Prozesse berühren. Und da Agenten in großem Maßstab und außerhalb der Geschäftszeiten agieren, ist der Explosionsradius einer Fehlkonfiguration nicht auf den UAT-Zyklus des nächsten Geschäftstages beschränkt.
Die praktische Implikation ist, dass die Auswirkungsanalyse auf die Agentenschicht ausgedehnt werden muss – nicht nur, welche menschlichen Prozesse diese Änderung betrifft, sondern welche Agenten-Ausführungspfade sie schneidet, welche Agenten-Pfade sie schneiden könnte und wie? Diese Fähigkeit existiert heute in den meisten SAP-Landschaften nicht als Standardfunktion. Der Aufbau in diese Richtung ist Teil dessen, was es bedeutet, sich auf die Business-KI-Plattform vorzubereiten.
Erschweren hybride Umgebungen die Agenten-Governance?
Die andere Variable, die nicht verschwindet, ist Hybrid. SAP hat klargestellt, dass die volle KI-Fähigkeit mit Cloud ERP einhergeht. SAP hat auch akzeptiert und anerkannt, dass viele große Organisationen jahrelang hybride Landschaften betreiben werden. Cloud ERP-Kunden werden KI-gestützte Beschaffungs-Workflows auf S/4HANA Cloud ausführen, während ihre verbundenen Altsysteme noch in On-Premises ECC leben, wobei ein Basis-Team Transporte auf traditionelle Weise verwaltet.
In dieser Umgebung teilt sich die Änderungsfläche nicht sauber in „KI-Seite“ und „klassische Seite“ auf. Ein Agent, der auf Cloud ERP ausgeführt wird, greift in ein verbundenes On-Premises-System für Stammdaten, Preiskonfiguration oder Legacy-Integration ein. Der Unternehmenskontext bedeutet, dass Joule intelligent genug ist, um zu wissen, wo die benötigten Daten heute leben, und wahrscheinlich über einen BTP-Integrationssuite-Konnektor. Eine Änderung, die an diesem On-Premises-System vorgenommen wird – unter Verwendung desselben Transportprozesses, der immer verwendet wurde – hat jetzt Agenten-seitige Konsequenzen, die das Basis-Team nicht sehen kann.
Die Change-Management-Praxis, die nur die Hälfte der Landschaft regelt, ist darauf nicht vorbereitet. Und die Organisationen, die die grundlegende Arbeit ernsthaft angehen, bevor die Agenten eintreffen, sind diejenigen mit der am besten verteidigbaren Position, wenn die KI-Schicht darüber liegt.
Was sollten SAP-Teams jetzt tun, um sich auf das agentenbasierte Change Management vorzubereiten?
„Vorbereitung auf die SAP Business-KI-Plattform“ ist kein einzelnes Projekt. Es ist eine kontinuierliche Disziplin, die beginnt, bevor eine KI-Funktion eingesetzt wird, und sich durch jedes Agenten-Onboarding, jede Landschaftserweiterung und jeden folgenden Transportzyklus fortsetzt.
In der Praxis bedeutet das ein paar Dinge:
Behandeln Sie jede Änderung standardmäßig als potenziell agentenrelevant. An dem Tag, an dem der erste Joule Assistant in Produktion geht, hat jede Auswirkungsanalyse eine neue Überlegung. Die Organisationen, die diese Disziplin bereits aufgebaut haben – indem sie agentenrelevante Änderungsvektoren als Teil des Standard-Release-Managements kennzeichnen – sind denjenigen voraus, die planen, dies später hinzuzufügen.
Bringen Sie die Agentenschicht in den Änderungskontrollbereich. Agentendefinitionen, BTP-Artefakte, Datenproduktkonfigurationen und Joule Studio-Versionen sind Änderungen in demselben Sinne wie ABAP-Transporte Änderungen sind. Der Genehmigungs-Workflow, die Regressionstests und der Audit-Trail müssen auch für die Agentenschicht gelten, auch wenn die bestehenden Tools dies heute nicht einfach machen.
Bereiten Sie sich jetzt auf das Audit-Gespräch vor. Die Audit-Teams, die die Änderungsdatensätze der KI-Ära überprüfen werden, arbeiten bereits in Ihrer Organisation. Was sie verlangen werden, unterscheidet sich im Grunde nicht von dem, was ein SOX-Audit heute verlangt: einen nachvollziehbaren, verfolgbaren Datensatz darüber, wer welche Änderung wann, an was und mit welcher Wirkung autorisiert hat. Der Unterschied besteht darin, dass „wer“ jetzt automatisierte Entitäten mit Servicekonten und Ausführungsberechtigung umfasst. Der Datensatz muss dies erfassen.
Machen Sie Hybrid zur ersten Klasse, nicht zu einem Grenzfall. Die Change-Praxis, die eine reine Cloud-Landschaft annimmt, ist nicht die Change-Praxis, die die nächsten fünf Jahre erfordern. Die hybride Grenze ist keine Lücke, die irgendwann geschlossen werden muss – sie ist eine aktive Änderungsfläche, die jetzt geregelt werden muss.
Change-Governance ist die Grundlage des autonomen Unternehmens
Christian Klein sagte auf der Sapphire 2026: „Der Übergang zum autonomen Unternehmen erfordert ein ernsthaftes Change Management.“
Wir haben vier Beiträge damit verbracht, zu erläutern, was das in der Praxis bedeutet. Die Änderungsfläche hat sich erweitert. Die Agenten sind jetzt nachgelagerte Konsumenten jeder vorgenommenen Änderung. In einigen Kontexten sind sie bereits selbst Akteure der Änderung, und die Governance-Frameworks, die für von Menschen initiierte Änderungen gelten, gelten auch für sie. Die Grundlage unter den Agenten, einschließlich Clean Core, Migrationsdisziplin und strukturiertem Release Management, ist jetzt wichtiger, da die Agenten alles verstärken werden, was sie dort finden.
Nichts davon macht das autonome Unternehmen weniger überzeugend. Die Richtung stimmt. Die Fähigkeiten sind real. Es bedeutet, dass die Organisationen, die am besten positioniert sind, den von SAP versprochenen Wert zu erzielen, diejenigen sind, die Change-Governance als strategische Fähigkeit und nicht als operativen Overhead betrachten.
Rev-Trac wurde genau dafür entwickelt: End-to-End-Transparenz und -Kontrolle über den gesamten SAP-Änderungslebenszyklus, von der Entwicklung bis zur Produktion, über ABAP, BTP und hybride Landschaften hinweg. Wenn sich die Änderungsfläche erweitert und die Akteure darin sich vervielfachen, wird die Fähigkeit, Änderungen im gesamten Umfang zu verfolgen, nachzuverfolgen und zu autorisieren, zur Grundlage, auf der ein vertrauenswürdiges autonomes Unternehmen aufgebaut wird.
Dieses Fundament baut sich nicht von selbst auf. Aber die Organisationen, die es jetzt aufbauen, werden diejenigen sein, von denen die Agenten erben – und das ist genau das richtige Erbe, das man hinterlassen sollte. Die Organisationen, die es jetzt aufbauen, werden diejenigen sein, von denen die Agenten erben – und das ist genau das richtige Erbe, das man hinterlassen sollte.
