These: Agenten scheitern am Betriebsmodell – SAP rechnet 87 zu 8

87 zu 8. Merken Sie sich diese Zahl, denn sie erklärt mehr über das Scheitern von KI-Agenten-Projekten als jede Produktdemo. 87 Prozent der IT-Verantwortlichen sagen laut einer von SAP zitierten Gartner-Untersuchung, dass sich KI-Adoption in ihrem Unternehmen nicht von selbst einstellt. Nur 8 Prozent der Mitarbeitenden nutzen Enterprise-KI tatsächlich sinnvoll im Arbeitsalltag. Dazwischen liegt keine Technologielücke. Dazwischen liegt ein Betriebsmodell-Loch, in das seit zwei Jahren Milliarden an Agenten-Budgets fallen, ohne unten wieder herauszukommen.

Seien wir ehrlich: Die Modelle sind gut genug. GPT, Claude, Gemini, Joule – die Fluency stimmt längst. Das Problem war nie die Sprachfähigkeit der Agenten. Das Problem ist, dass niemand vorher geklärt hat, welcher Prozess überhaupt automatisiert werden soll, wer den Agenten betreibt, wo er im Unternehmen sitzt und wer nach sechs Monaten noch weiß, dass er existiert. SAP hat das auf dem Transformation Excellence Summit in Atlanta ziemlich unverblümt eingeräumt – und genau daraus eine Backbone-Strategie gebaut, die weniger nach Copilot-Hype klingt als nach Betriebshandbuch.

Der Summit in Atlanta und die vier Bausteine hinter dem Versprechen

Andre Wenz, General Manager und Chief Product Officer für Business Transformation Management bei SAP, hat am 22. September auf dem Summit vier Produktlinien zu einem gemeinsamen Betriebsmodell für Agenten zusammengeschaltet: Signavio, LeanIX, WalkMe und Cloud ALM. Die Logik dahinter ist simpel und trotzdem selten so klar formuliert worden: Signavio definiert, wie Arbeit laufen soll. LeanIX zeigt, wo Agenten operieren und ob man ihnen vertrauen kann. WalkMe sorgt dafür, dass Menschen und Agenten die Arbeit tatsächlich ausführen. Cloud ALM begleitet den gesamten Lebenszyklus und überwacht den Produktivbetrieb.

Das ist, laut SAPs eigener Ankündigung, kein neues Produkt, sondern eine Neuordnung bestehender Werkzeuge unter einem einzigen Anspruch: Agenten sind keine Spielerei, die man in einer Fachabteilung freischaltet und dann hofft. Agenten sind Betriebsmittel. Und Betriebsmittel brauchen ein Betriebsmodell – mit Prozesswissen, Architekturüberblick, Nutzungsanreiz im Arbeitsfluss und Lebenszyklus-Steuerung.

Genau hier trennt sich die Spreu vom Weizen. Wer Agenten kauft, ohne diese vier Ebenen zu bedienen, kauft Demo-Theater. Punkt. Die Demo läuft immer. Das Problem beginnt am Montagmorgen danach, wenn dreihundert Mitarbeitende den Agenten öffnen sollen und die Hälfte nicht weiß, wofür.

Process Intelligence statt Demo-Theater

Der erste Baustein heißt Signavio, und SAP positioniert ihn konsequent als Ausgangspunkt, nicht als Add-on. Der neue Process Consulting Agent kombiniert Process Mining mit einer Beratungsfunktion, die Engpässe im laufenden Betrieb aufspürt und konkret benennt, an welcher Stelle ein Agent tatsächlich Wirkung entfalten kann – und an welcher nicht. Das ist der entscheidende Unterschied zu dem, was die meisten Unternehmen bislang gemacht haben: Sie haben zuerst den Agenten gekauft und danach überlegt, wo er hinpasst. SAP dreht die Reihenfolge um.

Der Process Modeler wurde KI-nativ überarbeitet, ergänzt durch eine Process-Intelligence-Schicht, die aus echten Prozessdaten lernt statt aus Annahmen im Workshop. Neu und bemerkenswert ist die Company Memory Preview – ein Gedächtnis für Regeln, Standards und Prozesswissen, das sowohl Menschen als auch Agenten zugänglich ist. Die Idee dahinter: Ein Agent, der eine Freigabe erteilt oder eine Rechnung prüft, braucht denselben Kontext wie ein Mensch, der diese Aufgabe seit Jahren macht. Ohne dieses geteilte Gedächtnis handelt der Agent nach Trainingsdaten aus dem Internet statt nach den tatsächlichen Regeln Ihres Unternehmens.

Genau das ist der Punkt, an dem viele Projekte kippen. Ein Agent, der nicht weiß, welche Eskalationsstufen in Ihrem Freigabeprozess gelten, produziert am Ende zwar flüssige Sätze – aber falsche Entscheidungen. Fluency ist nicht Kompetenz. Ein Agent kann elegant klingen und trotzdem den völlig falschen Schritt vorschlagen, wenn ihm das Prozesswissen fehlt, das im Unternehmen eigentlich längst dokumentiert ist, aber nie strukturiert an die Maschine weitergegeben wurde. Wer sich näher mit der Frage beschäftigt, wie Kontext technisch überhaupt an Agenten herangetragen wird, findet dazu vertiefende Einordnung im Beitrag zu Context Engineering und Graphdatenbanken – die Mechanik hinter der Company Memory Idee ist im Kern dasselbe Problem, nur auf SAP-Produktebene übersetzt.

Company Memory: das Gedächtnis, das fehlt

Ein Agent ohne Unternehmensregeln ist ein Praktikant am ersten Tag – nur schneller und mit mehr Selbstvertrauen. SAP nennt die Antwort darauf Company Memory Preview, eine Wissensschicht, die genau das festhält, was in keinem Modell steckt: welche Ausnahme in der Buchhaltung erlaubt ist, welcher Freigabeweg für welche Region gilt, welche Kundenvereinbarung von der Standardklausel abweicht.

Ohne dieses Gedächtnis entscheidet der Agent nach Wahrscheinlichkeit. Mit ihm entscheidet er nach Regel.

Punkt.

Sprachmodelle kennen keine internen Richtlinien, sie kennen Muster aus Trainingsdaten. Company Memory ist der Versuch, diese Lücke zu schließen, bevor der Agent produktiv geht – und nicht erst danach, wenn der Schaden schon entstanden ist.

Architecture Inventory – wer weiß, wo die Agenten überhaupt laufen

Der zweite Baustein ist LeanIX, und hier wird es für viele IT-Abteilungen unangenehm ehrlich. Die harte Wahrheit: In den meisten Unternehmen weiß niemand vollständig, wie viele Agenten, LLM-Instanzen und MCP-Server aktuell im Einsatz sind. Nicht weil niemand es dokumentieren wollte, sondern weil Agenten in einem Tempo entstehen, das klassische Architektur-Governance nicht mehr abbildet. Eine Fachabteilung testet einen Copilot, eine andere baut sich mit einem Low-Code-Tool einen eigenen Bot, eine dritte verbindet über einen MCP-Server ein internes System mit einem externen Modell – und in der IT-Leitung liegt davon höchstens ein Bruchteil auf dem Tisch.

LeanIX begegnet diesem Wildwuchs mit dem, was SAP Architecture Intelligence nennt: ein Knowledge Repository, in dem Prinzipien und Sicherheitsstandards für Agenten hinterlegt sind, ergänzt durch einen AI Enterprise Architect Assistant, der Architekturentscheidungen gegen diese Standards prüft. Der eigentliche Kern ist aber der AI Agent Hub. Er inventarisiert sämtliche Agenten, Sprachmodelle und MCP-Server im Unternehmen und ordnet sie den jeweiligen Fähigkeiten und Verantwortlichen zu. Aus einem unsichtbaren Wildwuchs wird damit eine sichtbare, zuordenbare Landkarte.

Ohne dieses Inventar ist jede Governance-Diskussion Theorie. Man kann keine Risikoklasse für einen Agenten vergeben, den man in der offiziellen Liste gar nicht kennt. Genau hier setzt der AI Governance Assistant an, der laut SAP regulatorische Anforderungen des EU AI Act und des NIST-Frameworks direkt in die Architekturverwaltung einbettet. Jeder Agent bekommt eine Risikoklassifizierung – und bei Änderungen am Agenten, an seinen Berechtigungen oder an seinem Einsatzbereich erfolgt eine automatische Neubewertung. Das ist kein Nice-to-have, sondern eine direkte Antwort auf die Frage, die europäische Aufsichtsbehörden derzeit zunehmend stellen. Wie eng regulatorische Durchsetzung und operative Praxis inzwischen zusammengehören, zeigt der Beitrag zum EU AI Board und der Durchsetzungspraxis – ein Rahmen, an dem sich Unternehmen mit Agenten im Produktivbetrieb ab sofort messen lassen müssen, unabhängig davon, welchen Anbieter sie einsetzen.

Wir bei digital-magazin.de sehen in diesem Architektur-Baustein den eigentlich unterschätzten Teil der SAP-Ankündigung. Alle reden über die Agenten selbst. Kaum jemand redet darüber, dass ein Unternehmen erst einmal wissen muss, wie viele es überhaupt hat, bevor es über deren Nutzen sprechen kann.

AI Agent Hub und das MCP-Server-Inventar

Governance setzt Überblick voraus. Ohne Inventar keine Kontrolle, so einfach ist das. Der AI Agent Hub soll genau diesen Überblick liefern: welche Agenten laufen, mit welchen MCP-Servern sie sprechen, welche Datenquellen sie anzapfen.

Klingt nach Buchhaltung. Ist auch Buchhaltung, nur eben für Agenten statt für Rechnungen. Wer nicht weiß, wie viele Agenten im eigenen Unternehmen aktiv sind und worauf sie zugreifen, kann auch keine Aussage darüber treffen, ob sie EU AI Act oder NIST-Vorgaben einhalten.

Genau darauf baut der AI Governance Assistant auf. Er prüft nicht abstrakt, ob KI „verantwortungsvoll“ eingesetzt wird, sondern konkret, gegen welche Regelwerke ein bestimmter Agent verstößt. Ohne Inventar wäre das Behauptung. Mit Inventar wird es überprüfbar.

Adoption in the Flow – warum ein Enterprise-Assistent allein niemanden erreicht

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptDesk with adoption flow sticky notes and closed laptop, soft light, photorealistic, no logos, no readable text, 16:9

Damit sind wir beim eigentlichen Kernproblem, das die 87-zu-8-Zahl beschreibt. WalkMe liefert dazu den dritten Baustein, und der Ansatz ist bemerkenswert unspektakulär: Contextual AI Assistance bringt Joule-Agenten und andere KI-Funktionen direkt in den Arbeitsfluss der Mitarbeitenden, statt sie in ein separates Portal zu verbannen, das ohnehin niemand öffnet.

Denken Sie an Ihren eigenen Arbeitsalltag. Wie oft öffnen Sie zusätzlich zu Ihrer eigentlichen Software noch ein separates KI-Tool, nur um eine Frage zu stellen? Selten. Genau das ist der Grund, warum laut der von SAP zitierten Gartner-Untersuchung nur 8 Prozent der Belegschaft Enterprise-KI wirklich sinnvoll nutzen. Nicht weil die Tools schlecht sind. Weil sie außerhalb des Flow of Work sitzen – ein Klick zu weit weg von der eigentlichen Aufgabe.

Besonders praxisrelevant ist dabei der UI-native Agent von WalkMe. Er bedient bestehende Benutzeroberflächen direkt – auch bei Legacy-Systemen, individuell angepassten ERP-Installationen oder Drittanbieter-Software, für die schlicht keine API existiert. Das ist in der Realität der meisten Unternehmen kein Randfall, sondern der Normalfall. Wer seit fünfzehn Jahren mit einem gewachsenen, individuell angepassten System arbeitet, kann nicht einfach eine saubere API-Schnittstelle erwarten, nur weil der Agenten-Anbieter das gern hätte. Genau deshalb bekommen AI Authoring und AI Insights als Ergänzungen ihren Sinn: Fachbereiche können selbst Assistenzfunktionen anlegen, und aus den Nutzungsdaten entsteht ein Bild davon, wo Menschen tatsächlich hängen bleiben.

Nein, das ist kein Freifahrtschein für Wildwuchs im Fachbereich. Aber es ist die ehrliche Antwort auf ein Problem, das viele Enterprise-KI-Programme bislang ignoriert haben: Adoption entsteht nicht, weil das Management eine Lizenz verteilt. Adoption entsteht, wenn die Unterstützung genau dort auftaucht, wo jemand gerade feststeckt – und nicht drei Klicks weiter.

UI-native Agenten und die Legacy-Frage

Die unbequeme Wahrheit vieler ERP-Landschaften: Nicht jedes System hat eine API, mit der ein Agent sauber sprechen kann. Ältere Module, gewachsene Eigenentwicklungen, Individualanpassungen aus früheren Jahrzehnten – da hilft keine Schnittstellendokumentation, weil es schlicht keine gibt.

Genau hier setzt WalkMe an. Der UI-native Agent agiert nicht über eine API, sondern direkt auf der Oberfläche, so wie ein Mensch klicken, tippen, auswählen würde.

Notbehelf.

Ein wirksamer allerdings. Adoption-in-the-flow bedeutet: Der Agent taucht dort auf, wo die Mitarbeitenden sowieso schon arbeiten, nicht in einem separaten Portal, das ohnehin niemand öffnet. Die acht Prozent Nutzungsquote aus der Gartner-Zahl erklären sich zu einem guten Teil so – Werkzeuge, die zusätzlichen Weg verlangen, werden ignoriert, Werkzeuge im Arbeitsfluss eher nicht.

Lifecycle und Monitoring – Cloud ALM verfolgt jede Agentenaktion

Der vierte Baustein schließt den Kreis, und er ist der am wenigsten glamouröse, aber vermutlich der wichtigste: Cloud ALM übernimmt den vollen Lebenszyklus eines Agenten – von der ersten Konzeption über die Testphase bis in den Produktivbetrieb. Das AI Agent Monitoring innerhalb von Cloud ALM protokolliert dabei jede einzelne Aktion, die ein Agent ausführt.

Warum ist das entscheidend? Weil ein Agent im Produktivbetrieb kein statisches Programm ist. Er trifft laufend Entscheidungen, reagiert auf neue Daten, wird mit neuen Berechtigungen ausgestattet, verändert sein Verhalten durch Modell-Updates. Ohne durchgängiges Monitoring merkt niemand, wenn ein Agent nach einem Update plötzlich anders reagiert als vorher – bis ein Kunde sich beschwert oder eine Rechnung falsch verbucht wird. Lifecycle-Governance heißt nicht, den Agenten einmal freizuschalten und dann in Ruhe zu lassen. Es heißt, ihn wie jedes andere produktionskritische System zu behandeln, das Wartung, Audits und Rollback-Optionen braucht.

Genau diese Verbindung von Monitoring und laufender Bewertung ist der Grund, warum externe Prüfverfahren gerade an Bedeutung gewinnen. Wie Unternehmen KI-Agenten kontinuierlich evaluieren, statt sie einmalig abzunehmen, beschreibt der Beitrag zu eingebetteter Evaluation bei Anthropic und Accenture sehr konkret – und die Parallele zu Cloud ALM ist kein Zufall. Beide Ansätze gehen von derselben Prämisse aus: Ein Agent, der einmal gut getestet wurde, ist morgen nicht automatisch noch gut.

Cloud ALM: Tracking statt Türsteher

Einen Agenten freizuschalten ist keine einmalige Entscheidung, sondern ein Dauerzustand, der überwacht werden muss. Die meisten Unternehmen behandeln Freigabe wie einen Schalter: einmal umlegen, fertig. SAP behandelt sie wie einen Prozess ohne Endpunkt.

Cloud ALM protokolliert jede einzelne Aktion, die ein Agent im Betrieb ausführt. Nicht nur, ob er lief, sondern was er getan hat, an welcher Stelle, mit welchem Ergebnis. Das ist der Unterschied zwischen einem Werkzeug, dem man vertraut, weil man es einmal geprüft hat, und einem Werkzeug, dem man vertraut, weil man es dauerhaft beobachtet.

Sinn ergibt das erst im Störfall. Ohne diese Beobachtung wüsste niemand, wenn ein Agent nach einem Update plötzlich anders entscheidet als vorher. Mit ihr fällt das auf, bevor Kunden oder Bilanzen den Unterschied spüren.

Warum Fluency ohne Governance das Gap nur skaliert

Hand aufs Herz: Die meisten gescheiterten Agenten-Projekte scheitern nicht an schlechten Modellen. Sie scheitern, weil ein flüssig formulierender Agent mit einem funktionierenden Agenten verwechselt wird. Ein Sprachmodell, das überzeugend klingt, wird in der Vorstandspräsentation für Kompetenz gehalten. Aber Fluency ist eine Oberflächeneigenschaft. Sie sagt nichts darüber aus, ob der Agent den richtigen Prozess kennt, ob er in einer nachvollziehbaren Architektur betrieben wird, ob ihn irgendjemand im Arbeitsalltag tatsächlich benutzt und ob sein Verhalten über die Zeit überwacht wird.

Und genau das ist der Mechanismus hinter der 87-zu-8-Lücke. Ein Unternehmen kauft einen sprachlich brillanten Agenten. Die IT-Leitung merkt, dass Adoption nicht automatisch passiert – 87 Prozent sagen das laut der SAP-zitierten Gartner-Erhebung selbst. Also wird nachjustiert: mehr Schulungen, mehr interne Kommunikation, mehr Druck von oben. Nur: Wenn der Agent weiterhin außerhalb des Arbeitsflusses sitzt, weiterhin ohne Prozesswissen arbeitet und weiterhin unsichtbar in der Architekturlandschaft verschwindet, bringt keine Schulung etwas. Man optimiert Symptome, nicht die Ursache.

Das eigentliche Risiko ist damit nicht technischer, sondern struktureller Natur. Ein Agent ohne Process Intelligence trifft Entscheidungen ohne Kontext. Ein Agent ohne Architecture Inventory ist ein blinder Fleck in Ihrer Risikobewertung. Ein Agent ohne Adoption-in-the-Flow bleibt ein ungenutztes Werkzeug, egal wie leistungsfähig das zugrunde liegende Modell ist. Und ein Agent ohne Lifecycle-Monitoring ist ein Produktivsystem, das niemand wirklich beobachtet. Jede dieser vier Lücken für sich ist schon ein Problem. Zusammen ergeben sie exakt das Muster, das aus 87 Prozent Skepsis und 8 Prozent echter Nutzung ein strukturelles Dauerproblem macht statt einer vorübergehenden Einführungsschwierigkeit.

SAP verkauft mit diesem Vier-Säulen-Modell natürlich in erster Linie SAP-Produkte – das ist an dieser Stelle wichtig festzuhalten, denn Signavio, LeanIX, WalkMe und Cloud ALM sind kommerzielle Angebote mit entsprechendem Eigeninteresse des Anbieters. Aber die zugrunde liegende Diagnose ist unabhängig vom Anbieter richtig: Ein Betriebsmodell für Agenten braucht mindestens diese vier Dimensionen, egal ob Sie am Ende SAP, einen anderen Enterprise-Stack oder eine selbst gebaute Lösung einsetzen.

Demo montags, Betrieb nach neunzig Tagen

Jede Agenten-Demo funktioniert. Das ist keine Ironie, das ist die Natur der Demo: kontrollierte Umgebung, vorbereitete Daten, ein Ablauf, der zehnmal geprobt wurde. Genau deshalb sagt eine Demo praktisch nichts darüber aus, was in neunzig Tagen Produktivbetrieb passiert.

Der eigentliche Test beginnt, wenn dreihundert Mitarbeitende den Agenten in echten, unaufgeräumten Prozessen benutzen – mit Ausnahmefällen, mit Dateneingaben, die nicht dem Schema entsprechen, mit Fragen, die im Skript nicht vorkamen. Wer sein Betriebsmodell vorher nicht geklärt hat, merkt das genau hier.

Wir bei digital-magazin.de sehen deshalb bei jedem Agenten-Projekt zuerst auf die Frage nach dem Danach: Wer betreibt das Ganze in Monat vier, wenn die Neugier verflogen ist? SAPs Vierklang aus Signavio, LeanIX, WalkMe und Cloud ALM ist im Kern ein Versuch, genau diese Frage nicht dem Zufall zu überlassen.

Montag. Demo. Applaus. Und dann die viel unspektakulärere, aber entscheidende Arbeit danach.

https://digital-magazin.de/business-karriere/

Was Führung jetzt konkret prüfen muss

Wenn Sie in Ihrem Unternehmen für KI-Agenten verantwortlich sind, reicht es nicht, eine gute Demo gesehen zu haben. Prüfen Sie stattdessen vier Dinge, bevor der nächste Agent freigeschaltet wird.

• Prozesswissen vor Werkzeug: Existiert für den Prozess, den der Agent übernehmen soll, eine belastbare, aktuelle Prozessdokumentation – oder basiert der Agent auf Annahmen aus einem Workshop, der drei Jahre zurückliegt?
• Vollständiges Inventar: Können Sie an einem Tag mit Namen und Verantwortlichen aufzählen, welche Agenten, Modelle und Schnittstellen in Ihrem Unternehmen tatsächlich aktiv sind? Wenn nicht, ist jede Governance-Diskussion Theorie.
• Nutzung im Arbeitsfluss: Erscheint die KI-Unterstützung an der Stelle, an der Mitarbeitende tatsächlich arbeiten – oder in einem separaten Tool, das zusätzlichen Aufwand erzeugt und deshalb ignoriert wird?
• Laufende Überwachung: Wird jede Aktion des Agenten protokolliert und regelmäßig überprüft, oder verlässt sich Ihr Unternehmen auf den Test vor dem Go-Live und hofft danach das Beste?

Wer diese vier Fragen nicht sauber beantworten kann, sollte den nächsten Agenten-Rollout verschieben, egal wie überzeugend die Verkaufspräsentation war. Es lohnt sich außerdem, diese Fragen nicht nur technisch zu stellen, sondern organisatorisch: Wer im Unternehmen trägt die Verantwortung für Prozesswissen, wer für die Architektur, wer für Adoption, wer für Monitoring? Wenn die Antwort „irgendwie alle und niemand richtig“ lautet, haben Sie das eigentliche Problem bereits identifiziert. Solche Verantwortungsfragen berühren zunehmend auch klassische Karrierepfade und Kompetenzprofile in Unternehmen – ein Thema, das wir im Bereich Business und Karriere regelmäßig vertiefen, weil sich mit jedem produktiven Agenten auch die Frage verschiebt, welche menschliche Rolle künftig Prozesswissen, Architekturaufsicht und Adoption-Verantwortung trägt.

Die 87-zu-8-Lücke wird sich nicht durch bessere Modelle schließen. Sie schließt sich, wenn Unternehmen aufhören, Agenten wie Software-Lizenzen zu behandeln, und anfangen, sie wie Betriebsmittel zu führen – mit Prozessverantwortung, Architekturüberblick, echter Nutzung im Alltag und kontinuierlicher Beobachtung.

Wir bei digital-magazin.de halten die SAP-Diagnose für härter als die Produktfolie: Ohne Process Intelligence, Architecture Inventory und Adoption-in-the-flow bleibt jeder Agent eine teure Demo — egal wie flüssig das Modell formuliert.

Alles andere bleibt Demo-Theater mit Enterprise-Preisschild.