SAPs dritte Wette aufs Ganze: Gelingt sie ohne Plattner?

Am 23. April 2026 meldete SAP ein starkes erstes Quartal. Der aktuelle Cloud-Auftragsbestand (Current Cloud Backlog) lag bei 21,9 Milliarden Euro, währungsbereinigt ein Plus von 25 Prozent. Der Cloud-Umsatz stieg um 27 Prozent, die Cloud ERP Suite um 30 Prozent. SAP-Chef Christian Klein führte die Ergebnisse in der Telefonkonferenz zu den Quartalszahlen auch auf den Schwung bei Business AI zurück. SAP sieht sich auf Kurs, die Prognose für 2026 zu erreichen.

Der Markt bewertet die strategische Lage anders. Eine Woche später schloss die in New York gehandelte SAP-Aktie (ADR) bei 169,49 Dollar, 42 Prozent unter dem Vorjahreswert und rund 46 Prozent unter dem 52-Wochen-Hoch von 313,28 Dollar. Der Kursverlauf zeigt einen stetigen Rückgang, keinen einzelnen Einbruch, und im ersten Quartal wurde das Gefälle steiler.

Zwei Bilder desselben Unternehmens. Der Cloud-Auftragsbestand misst die Stärke des bestehenden Kanals. Der Kursrückgang deutet darauf hin, dass Investoren eine andere Frage stellen als die, die operative Kennzahlen beantworten. Der verstorbene Clayton Christensen hat dieses Muster vor Jahrzehnten beschrieben, und es gilt bis heute: Etablierte Marktführer, denen eine Disruption bevorsteht, liefern in den Jahren davor typischerweise starke Finanzergebnisse. Gerade die finanzielle Stärke macht es schwer, auf die Disruption zu reagieren.

Dieser Text schließt an meine Analyse von SAPs API Policy 4.2026a aus der Vorwoche an. Dort habe ich argumentiert, dass die Richtlinie rationales Verteidigungsverhalten eines dominanten Anbieters ist, für sich genommen aber keine langfristige Strategie sein kann. Hier geht es um die Frage, wie diese langfristige Strategie aussehen müsste und ob SAP sie noch aufbauen kann.

SAP hat in seiner Geschichte mehrere große strategische Übergänge bewältigt. Zwei davon heben sich ab: Es waren vom Gründer getriebene architektonische Neuerfindungen, organisatorisch von der bestehenden Kultur getrennt, um das Neue vor ihr zu schützen, und durchgesetzt gegen die Schwerkraft der bestehenden Organisation und ihres Ökosystems. Beide hat Hasso Plattner selbst vorangetrieben. Plattner ist inzwischen emeritiert. Die Bedrohung auf der Agentenebene ist da. Die Frage ist, ob seine Nachfolger noch einmal schaffen, was ihm zweimal gelang.

Christensen in Kürze

Christensens These von 1997 ist bis heute aktuell: Erfolgreiche Marktführer scheitern an disruptiver Innovation nicht, weil sie sie nicht kommen sehen, sondern weil genau das, was sie im bestehenden Geschäft erfolgreich macht, sie daran hindert, eine aufkommende Disruption selbst voranzutreiben. Das Modell benennt fünf Mechanismen.

Ressourcenabhängigkeit von bestehenden Kunden. Unternehmen hängen bei Umsatz und Roadmap von ihren bestehenden Kunden ab. Die erfolgreichsten Unternehmen sind am besten darin, Ideen zu beerdigen, die ihre bestehenden Kunden nicht wollen. Genau diese antrainierte Disziplin hat ihren Erfolg hervorgebracht.

Kleine Märkte lösen nicht das Wachstumsproblem großer Unternehmen. Ein Unternehmen mit 40 Milliarden Dollar Umsatz braucht für 20 Prozent Wachstum jedes Jahr 8 Milliarden Dollar neuen Umsatz. Disruptive Innovationen beginnen in Märkten, die für den Marktführer zu klein sind, um ins Gewicht zu fallen. Sie wirken unbedeutend, wenn sie auftauchen, weil sie es in diesem Moment auch sind.

Märkte, die es noch nicht gibt, lassen sich nicht analysieren. Unternehmen brauchen Daten, um zu entscheiden. Disruptive Innovationen schaffen Märkte, für die es noch keine Daten gibt. Die Entscheidungsdisziplin des Marktführers wird zu seiner Schwäche. Disruptoren handeln aus Überzeugung. Marktführer warten auf Belege.

Die Fähigkeiten einer Organisation bestimmen ihre Unfähigkeiten. Fähigkeiten stecken in Ressourcen, Prozessen und Werten, wobei zu den „Werten“ auch Vergütungsstrukturen gehören und das, was gefeiert wird. Die Prozesse, die den Marktführer im bestehenden Geschäft exzellent machen, machen ihn für disruptive Innovation ungeeignet. Der eigene Vertrieb wird nach Quote auf das bestehende Produkt vergütet. Ein neues Produkt ohne installierte Basis, ohne Referenzkunden, ohne Zertifizierungen und mit anfangs kleineren Abschlüssen lässt sich gegen eine Quote auf das bestehende Produkt nur schwer verkaufen. Das neue Produkt zielt zudem meist auf ein anderes Kundensegment als das, auf das die bestehende Vertriebsorganisation ausgerichtet ist. Und das bestehende Partnerökosystem ist auf das alte Produkt zertifiziert.

Technologisches Angebot entspricht nicht unbedingt der Marktnachfrage. Disruptive Technologien schneiden anfangs oft bei den Kriterien schlechter ab, die bestehenden Kunden wichtig sind, glänzen aber bei einer anderen Eigenschaft, die einen neuen Markt schafft. Bis die disruptive Technologie bei den ursprünglichen Kriterien „gut genug“ ist, hat sich das Zeitfenster des Marktführers zum Aufholen bereits verengt.

Die fünf Mechanismen verstärken sich gegenseitig. Christensen behauptet nicht, dass Managern Intelligenz oder Mut fehlt. Er sagt, dass ihre Anreize, Kennzahlen, Kundenzusagen und Umsatzabhängigkeiten den disruptiven Schritt aus der bestehenden Organisation heraus zum Karriereende machen. Organisatorische Trennung ist nicht deshalb wichtig, weil Marktführer nicht klar denken können, sondern weil klares Denken innerhalb der bestehenden Struktur zu Recht zu dem Schluss kommt, dass der disruptive Schritt nicht im Interesse der Organisation liegt. (Auch ausgegliederte Inkubatoren können scheitern.)

Das Cash-Cow-Problem, konkret

Das deutlichste Beispiel für diese Mechanismen bei SAP, aus derselben Zeit, in der Plattner am HPI an HANA arbeitete, ist die Abhängigkeit von Oracle.

Über weite Teile von SAPs Geschichte bis 2015 war Oracle die dominierende Datenbank unter SAP-Anwendungen. Gartner schätzte, dass rund 40 Prozent der SAP-Kunden Oracle-Datenbanken einsetzten. Die meisten bezogen diese Lizenzen über SAPs Wiederverkaufsvertrag mit Oracle, nach einem Preismodell namens SAP Application Value (SAV). Beim SAV zahlt der Kunde einen Prozentsatz seiner gesamten SAP-Softwareausgaben, wenn er eine Datenbank eines Drittanbieters über SAP lizenziert. Von Gartner dokumentierte Zahlen zeigen, dass Oracles Preis für die Runtime-Datenbanklizenz unter SAV innerhalb von drei Jahren von rund 11 auf 25 Prozent des SAV stieg. Ende der 2010er-Jahre konnte bei einem SAP-Lizenzvolumen von 10 Millionen Dollar allein der Oracle-Aufschlag 2,5 Millionen Dollar zusätzlich ausmachen, an SAP gezahlt und an Oracle weitergereicht.

Das war eine Preisstruktur im Milliardenumfang, fest verankert in den Kundenverträgen. SAPs Vertrieb war darauf trainiert, Pakete aus SAP und Oracle zu verkaufen. SAPs Partnerökosystem aus Beratern, Integratoren und Hosting-Anbietern war auf Oracle zertifiziert. Vergütung, Zertifizierung, Schulung und Account-Management im gesamten Go-to-Market-Apparat von SAP waren auf die Annahme ausgerichtet, dass unter SAP eine Oracle-Datenbank lief.

Diese Abhängigkeit aus SAPs Produktorganisation heraus zu beenden, hätte bedeutet: den Vertrieb aufzufordern, genau die Kundenbeziehungen zu gefährden, von denen seine Vergütung abhing, das Partnerökosystem aufzufordern, Fähigkeiten aufzugeben, die es sich über ganze Karrieren erarbeitet hatte, und den SAV-Umsatz selbst zu kannibalisieren. Die bestehende Organisation hatte jeden Anreiz, diese Wette nicht von innen einzugehen.

SAPs Konzernführung versuchte durchaus, über andere Kanäle mehr Umsatz aus der Oracle-Abhängigkeit zu ziehen. 2005 übernahm SAP TomorrowNow, einen Drittanbieter, der günstigen Support für Oracles Unternehmensanwendungen anbot. Die Wette: einen Teil des Support-Budgets zu gewinnen, das Oracle bei gemeinsamen Kunden abschöpfte. 2007 klagte Oracle mit dem Vorwurf, TomorrowNow habe systematisch Tausende urheberrechtlich geschützter Oracle-Dokumente heruntergeladen. SAP schloss TomorrowNow, räumte die Haftung ein und bot einen Vergleich an. Im November 2010 sprach eine Jury Oracle 1,3 Milliarden Dollar zu, damals der höchste Schadenersatz wegen Urheberrechtsverletzung aller Zeiten. Nach Jahren der Berufungsverfahren endete der Fall im November 2014 mit einem Vergleich über 356,7 Millionen Dollar, zuzüglich 120 Millionen Dollar Anwaltskosten.

Zwischen 2005 und 2014 liefen zwei Antworten auf dasselbe Oracle-Problem parallel. Der frontale kommerzielle Vorstoß innerhalb der bestehenden Organisation, per Übernahme, führte zum größten Urheberrechtsvergleich der Softwaregeschichte. Die organisatorisch getrennte Forschungswette am HPI brachte HANA hervor, das Oracle als Datenbank unter SAP-Anwendungen verdrängte. Der Unterschied zwischen beiden Antworten war die organisatorische Trennung.

Die Lehre aus ByDesign

Ein zweiter Präzedenzfall lohnt einen Blick, weil er den Christensen-Mechanismus auf der Plattformebene zeigt.

Unter CEO Henning Kagermann startete SAP ein Vorhaben, das intern als Project Vienna und später als A1S bekannt war: ein Großprojekt für eine SAP-Suite der nächsten Generation, die R/3 durch etwas Einfacheres, Modulareres und Cloudfähiges ersetzen sollte. Shai Agassi und Peter Zencke leiteten es. Im Kern sollte es für die Anwendungsebene leisten, was HANA bald für die Datenbankebene leisten würde.

Das Projekt kam 2007 als Business ByDesign auf den Markt. Öffentlichen Rückblicken zufolge stürzten Konflikte zwischen Zencke, dem SAP-Veteranen, der Teile von R/3 gebaut hatte, und Agassi, dem jüngeren Manager, der auf den architektonischen Bruch drängte, das Projekt ins Chaos. Zeitpläne und Kosten liefen aus dem Ruder. Die Leute, die Kagermann mit dem Bau eines grundlegend einfacheren, schnelleren ERP beauftragt hatte, waren zu einem erheblichen Teil dieselben, die R/3 gebaut und erfolgreich gemacht hatten. Das Ergebnis: Sie bauten noch einmal R/3.

ByDesign überlebte als Produkt, aber nicht als die Suite der nächsten Generation, die das Unternehmen neu definieren sollte. Inzwischen bietet SAP ByDesign Neukunden nicht mehr an.

Das Vienna-Muster sollte man für das Folgende im Kopf behalten. Die Leute, die R/3 so erfolgreich gebaut hatten, sollten R/3 aus der bestehenden Organisation heraus ablösen, und sie griffen zu dem, was beim letzten Mal funktioniert hatte. Die entscheidende Frage für die Agentenebene ist, ob jetzt die Leute, die S/4HANA und Joule gebaut haben, die Enterprise-KI-Architektur der nächsten Generation bauen sollen. Das historische Muster sagt voraus, dass sie für die Welt bauen werden, die sie kennen, nicht für die Welt, die gerade entsteht.

Zwei Züge des Gründers

Genau dieses Modell brachte Plattner im Juni 2014 auf die Keynote-Bühne der Sapphire, wo er es mit Christensen selbst diskutierte. SAPs eigener Artikel von diesem Tag zitiert ihn: „SAP ist der Musterkandidat für das Innovator’s Dilemma. Ich sehe das Dilemma überall.“ Er sprach an diesem Morgen, so der Artikel, in seiner Funktion als Professor am HPI, nicht als Vorsitzender des SAP-Aufsichtsrats. Die Einordnung war damit öffentlich.

Die Geschichte zeigt mindestens zwei Momente, in denen das Unternehmen einer architektonischen Bedrohung seiner Kernrelevanz gegenüberstand und Plattner persönlich das Unternehmen auf eine organisatorisch getrennte, disruptive Antwort setzte.

Im April 2001 zahlte Plattner 400 Millionen Dollar in bar für TopTier, ein israelisches Portal-Unternehmen mit rund 30 Millionen Dollar Umsatz. Er kaufte keinen Umsatz. Er kaufte eine Befürchtung. Sechs Jahre vor dem Marktstart von ByDesign hatte Shai Agassi Plattner eine Demo gezeigt, in der Nutzer Objekte aus SAP, Oracle und Siebel in einen einzigen Arbeitsablauf ziehen konnten, ohne die zugrunde liegenden Anwendungen je zu öffnen. Agassi sagte ihm, SAP werde zu einem „irrelevanten Hintergrundsystem und Datenspeicher“ degradiert, wenn Portale den Desktop übernähmen. Plattner holte Agassi in den Vorstand und beschrieb ihn gegenüber Kollegen als „Retrovirus“, eingeschleust in SAPs DNA. Das Ergebnis war NetWeaver. SAP behielt die oberste Schicht die 2000er-Jahre hindurch.

Im Herbst 2006 stand Plattner vor Doktoranden am Hasso-Plattner-Institut, der Hochschuleinrichtung, die er 1998 gegründet hatte, um Forschung zu betreiben, die SAP intern nicht leisten konnte. Er forderte sie auf, die Annahme aufzugeben, auf der seit vierzig Jahren jede kommerzielle Datenbank gebaut war: dass transaktionale Lasten schreiblastig seien und zeilenorientierte Speicherung auf Festplatte erforderten. Der Benchmark TPC-C modellierte OLTP mit 46 Prozent Schreibzugriffen. Als Plattners Team am HPI später zwölf reale SAP-Kundensysteme vermaß, fand es etwas anderes: Echte transaktionale ERP-Lasten bestanden zu über 80 Prozent aus Lesezugriffen. Der Benchmark, auf den die Datenbankbranche optimiert hatte, hatte wenig mit dem zu tun, was ihre größten Kunden tatsächlich taten. Wenn OLTP in Wahrheit leselastig war, ließen sich OLTP und OLAP in einem einzigen spaltenorientierten In-Memory-System zusammenführen. Diese Zusammenführung ist die Architektur von HANA.

Die Arbeit entstand am Fachgebiet EPIC (Enterprise Platform and Integration Concepts), das Plattner 2006 am HPI eigens für diese Art von Forschung gegründet hatte. Stanford war Forschungspartner. Zeithorizont: fünf Jahre. Beteiligt waren Plattner, Alexander Zeier, Jens Krüger, Matthias Uflacker und Vishal Sikka. Plattner veröffentlichte das grundlegende Paper 2009 auf der SIGMOD. HANA kam 2011 auf den Markt. Es machte S/4HANA möglich und verschaffte SAP ein weiteres Jahrzehnt Relevanz.

Zwei Wetten, fünf Jahre auseinander, mit derselben Struktur. Beide setzten auf organisatorische Trennung von der bestehenden Organisation. Beide räumten mit Annahmen auf, deren Aufgabe die Bestandskunden noch gar nicht verlangt hatten. Beide brauchten die Autorität des Gründers, um die Trennung gegen Vertrieb, Partnerökosystem und bestehende Ergebnisrechnung durchzusetzen.

Der anschließende Cloud-Übergang, RISE with SAP, Anfang 2021 gestartet, war ein anderer Zug. Er war gutes Management eines branchenweiten Übergangs, in den die Kunden SAP bereits hineinzogen. Der aktuelle kommerzielle Schwung des Unternehmens beruht darauf. Der Übergang war aber nicht die Art von organisatorisch getrennter, mehrjähriger, vom Gründer getriebener Architekturwette, aus der die beiden früheren Neuerfindungen hervorgingen. Die beiden früheren Züge erfolgten ohne äußeren Zwang. RISE war der Zug der ganzen Branche. SAP hat ihn gut umgesetzt.

Rückfall in alte Muster

Was zwischen 2014 und 2025 geschah, passt zu dem, was das Modell vorhersagt, wenn der Schutz durch den Gründer wegfällt.

Die Palo Alto Labs im Stanford Research Park, seit 1996 SAPs größter Standort außerhalb Deutschlands, schrumpften Jahr für Jahr. Auf dem Höhepunkt um 2015 umfasste SAPs Präsenz dort rund fünfzehn Gebäude mit Tausenden Entwicklern und Forschern. Im Oktober 2025 meldete SAP für das letzte noch genutzte Gebäude der Palo Alto Labs, Hillview Avenue 3410, 82 Entlassungen an, wie es das kalifornische Recht vorschreibt (WARN Notice), und begründete sie mit einer KI-getriebenen Umstrukturierung. Das Pendel schwang zurück nach Walldorf. In SAPs strategischen Entscheidungen wurde das Silicon Valley zur Nebensache.

Gleichzeitig hat sich die Spitze der KI-Entwicklung weiter in der San Francisco Bay Area konzentriert und beschleunigt: dort, wo Foundation Models trainiert werden, wo die neuen agentischen Architekturen Gestalt annehmen und wo Talente frei zwischen OpenAI, Anthropic, Google, Meta, Tesla und der Welle agentennativer Startups wechseln. Bei Gesprächen in der Mittagspause und bei Grillabenden am Wochenende zwischen Entwicklern, Gründern und Investoren wird aus beiläufigem Austausch eine Beziehung, eine Idee und schließlich disruptive Innovation. Diese Dichte, aus der mit der Zeit Können erwächst, ist an einen Ort gebunden. Abstand zu ihr ist ein messbarer Nachteil.

Mitte 2023 wurde das Fachgebiet EPIC aufgelöst. Plattner hielt im Frühjahr 2023 seine letzte Vorlesung am HPI und wurde emeritiert. Michael Perscheid, Plattners Stellvertreter bei EPIC und in den späten Jahren des Fachgebiets der am engsten mit ihm verbundene leitende Forscher, wechselte zu SAP, wo er den Bereich „Chairman and Strategic Projects“ leitete. Heute ist er dort VP Applied Research. Damit wurde genau das Vehikel stillgelegt, das HANA hervorgebracht hatte: das organisatorisch getrennte Fachgebiet, mit dem Plattner Forschung ermöglicht hatte, die SAP intern nicht leisten konnte. Am HPI gibt es kein Nachfolge-Fachgebiet, das sich gezielt mit agentennativer Unternehmensarchitektur befasst. Die Forschung, die am HPI auf EPIC folgt, ist exzellent und konzentriert sich auf benachbarte Felder: KI für Nachhaltigkeit, digitale Gesundheit, Softwaretechnik. Nichts davon zielt auf die Frage, die SAP jetzt beantworten muss.

Die Nachfolge an der Spitze verlief auf derselben Bahn. Die Generation, die Plattner selbst geprägt hatte, die Leute, die SAP von einem kleinen deutschen Unternehmen zu einem globalen Konzern gemacht haben, wurde von einer Führung abgelöst, die ihre gesamte Laufbahn im Unternehmen verbracht hat. Klein ist seit 1999 bei SAP, CTO Philipp Herzig seit 2007. Die Führung ist kompetent und hat echte Produkte geliefert. Die Perspektive aus einer ganzen Karriere im Haus macht sie wirksam darin, das Unternehmen zu führen. Es ist aber auch die Perspektive, aus der der disruptive Schritt strukturell schwer zu erkennen ist, geschweige denn zu finanzieren.

Joule als erhaltende Innovation

Die architektonische Bedrohung auf der Agentenebene war spätestens 2023 sichtbar. SAPs Antwort ist Joule, eine Agentenplattform, die inzwischen in 35 SAP-Lösungen integriert ist, mit mehr als 30 spezialisierten Agenten und mehr als 2.500 Skills. Joule wird in SAPs zentraler Produktentwicklung in Walldorf und Bangalore gebaut, im Quartalsrhythmus, eng verzahnt mit den Teams, die ERP-, HR-, Finanz-, Supply-Chain- und Einkaufsanwendungen entwickeln. Das ist kompetente Produktentwicklung. Es ist aber auch genau das, was das Modell vorhersagt, wenn die bestehende Organisation die Agentenebene bauen soll: tiefere Integration von KI-Funktionen in das bestehende Produkt, im bestehenden Release-Rhythmus, durch die Leute, die das bestehende Produkt gebaut haben.

Die frühen Belege dafür, ob das funktioniert, sind inzwischen umfangreich. Das stärkste einzelne Signal kommt von SAP selbst. In der Telefonkonferenz zum ersten Quartal am 23. April sagte Klein: „Die breite Einführung von Enterprise-KI steht noch am Anfang. Auch wir bei SAP lernen jeden Tag mit unseren Kunden, was es wirklich braucht, damit KI in Geschäftsprozessen verlässlich funktioniert. Agenten haben oft noch nicht das volle Verständnis von Geschäftsdaten und Prozessen, um sehr genaue Ergebnisse zu liefern.“ Auf die Frage von Adam Wood (Morgan Stanley) nach der Roadmap für generative KI ergänzte Klein, SAP müsse „bei der Genauigkeit die letzte Meile gehen“. Frederic Boulan (BNP Paribas) sprach die konkrete Sorge an, Kunden könnten SAP Business Data Cloud nutzen, um Daten zu extrahieren und Agenten außerhalb des SAP-Ökosystems zu bauen.

Auch von Kundenseite gibt es Belege. Für den Investitionsreport 2026 der Deutschsprachigen SAP-Anwendergruppe (DSAG) wurden knapp 200 Mitgliedsunternehmen befragt, überwiegend aus Deutschland, Österreich und der Schweiz. 43 Prozent haben KI-Anwendungsfälle umgesetzt. Von diesen Unternehmen betreiben 77 Prozent ihre KI-Anwendungsfälle produktiv mit Lösungen außerhalb von SAP, nur 3 Prozent setzen dafür auf SAP. Bloomberg berichtete im Februar, frühe Joule-Nutzer hätten das Produkt als schwer zu bedienen, begrenzt und den Preis nicht wert beschrieben. Das E3-Magazin berichtet unter Berufung auf Insider bei Volkswagen, die Lösung sei noch unausgereift, und es fehle ein greifbarer Einspareffekt in Geld oder Ressourcen.

Deloitte, Accenture, PwC, IBM Consulting und der Rest des SAP-Partnerökosystems haben starke Anreize, Joule einzuführen. Ihre Zertifizierungen, Schulungsinvestitionen und Partnerstufen sprechen alle dafür. Diese Schwerkraft der Partner ist real und einer der Gründe, warum der Cloud-Auftragsbestand im ersten Quartal wächst.

In Enterprise Software kann die Schwerkraft der Partner kommerziellen Schwung noch lange tragen, nachdem sich die Präferenzen der Kunden bereits verschoben haben. RISE und GROW geben SAP einen kommerziellen Kanal, über den sich Joule bündeln, bewerben und ausbauen lässt, noch bevor die Nutzung durch Kunden eine dauerhafte Präferenz belegt.

Mautstellen

Auf die sichtbar werdenden Schwächen von Joule als Antwort auf der Agentenebene hat SAP bislang mit drei defensiven Schritten reagiert.

Erstens kündigte Klein im März 2026 an, SAP werde für KI zu verbrauchsabhängigen Preisen übergehen und ab Juli Teams von Forward Deployed Engineers aufbauen, die direkt beim Kunden arbeiten. Es ist die größte Änderung an SAPs Geschäftsmodell seit dem Cloud-Übergang.

Zweitens kam am 24. April die neue API Policy 4.2026a. Abschnitt 2.2.2 untersagt die Nutzung von APIs für die „interaction or integration with (semi-) autonomous or generative AI systems that plan, select, or execute sequences of API calls“, also für (teil)autonome oder generative KI-Systeme, die Abfolgen von API-Aufrufen planen, auswählen oder ausführen, sofern sie nicht über von SAP freigegebene Wege kommen. Das ist die Lehrbuchdefinition eines KI-Agenten. SAP hat die Bedrohung im Klartext benannt und ihr den Zugriff auf SAP-APIs verboten, solange sie nicht durch SAPs eigene Vordertür kommt.

Drittens die Infrastruktur für das Model Context Protocol (MCP), den offenen Standard, über den KI-Agenten an Daten und Werkzeuge angebunden werden. SAP liefert sie seit dem vierten Quartal 2025 aus und stellt sie jetzt in den Mittelpunkt: das MCP Gateway in der Integration Suite, MCP-Unterstützung für HANA Cloud, ein ABAP-MCP-Server, ein Storefront-MCP-Server für Commerce Cloud, Open-Source-MCP-Server für UI5 und CAP. Die technischen Bausteine sind real. Die strategische Logik: Wenn SAP die Agentenebene nicht direkt gewinnen kann, brauchen Agenten von Drittanbietern einen standardisierten Zugang zu SAP-Daten, und SAP kann für das Gateway, über das dieser Zugang läuft, Gebühren verlangen.

Eine Mautstelle. Eine Mautstelle vor den eigenen Daten des Kunden.

Ob der MCP-Schritt eine bewusste, mit Clean Core und den Preisen in AI Units abgestimmte Strategie ist oder eine späte Umwidmung vorhandener technischer Kapazität als Reaktion auf Joules sichtbare Akzeptanzprobleme, ist eine interessante Frage. Für diese Analyse ist es aber die falsche Frage. Beide Varianten sind dieselbe Art von Schritt. Die API Policy hält Agenten von Drittanbietern an der Grenze in Quarantäne. Das MCP-Gateway monetarisiert den Zugang, den SAP nicht verhindern kann. Beides sind kommerzielle Verteidigungszüge. Beide verschaffen etwas Zeit. Keiner ist eine architektonische Neuerfindung.

In SAPs direkter Nachbarschaft haben ServiceNow (rund 95 Milliarden Dollar Börsenwert) und Salesforce (rund 150 Milliarden Dollar) angekündigt, sich als Plattformen ohne eigene Benutzeroberfläche („headless“) für die Agentenebene neu aufzustellen. Die strategische Logik ist dieselbe wie bei SAPs MCP-Schritt: Wer die Agentenebene nicht direkt gewinnen kann, positioniert sich als das Fundament, das die Agenten nutzen müssen. Beide haben dasselbe Problem wie SAP und lösen es vorerst auf dieselbe Weise. Keines der drei Unternehmen hat die Architekturwette gewagt, die der Moment verlangt.

Hier tun Manager, was Manager eben tun.

Die Übernahmen vom 4. Mai

Eine Woche vor der Sapphire in Orlando, am 4. Mai 2026, kündigte SAP gleichzeitig zwei Übernahmen an.

Die erste ist Dremio, eine auf Iceberg basierende Data-Lakehouse-Plattform, die SAPs Reichweite auf den gesamten Datenbestand des Kunden ausdehnt.

Die zweite ist Prior Labs, ein Forschungs-Startup hinter einem Foundation Model für tabellarische Daten.

Beide verdienen eine genaue Lektüre. Ihre jeweilige Struktur verrät, was SAP für das Gebot der Stunde hält.

HANAs Kinder

Als HANA 2011 auf den Markt kam, bestand die architektonische Einsicht in spaltenorientierter In-Memory-Speicherung, bei der OLTP- und OLAP-Lasten in einem einzigen System zusammenfallen. Diese Wette verschaffte SAP ein Jahrzehnt.

Die Wette blieb nicht bei SAP. Snowflake und Databricks griffen verwandte Architekturideen auf, darunter spaltenorientierte Speicherung, Cloud-Elastizität, die Trennung von Speicher und Rechenleistung sowie offene Analyseformate, und machten daraus die dominierenden modernen Analyseplattformen. SAP hat eine Version der These vom spaltenorientierten In-Memory-Ansatz innerhalb von Unternehmensanwendungen bewiesen. Der breitere Cloud-Datenmarkt hat sich anderswohin bewegt.

Der offene Tabellenformat-Standard Iceberg wurde zum Bindegewebe, das spaltenorientierte Lakehouse-Speicherung zwischen Anbietern portabel macht. Die architektonische Einsicht, die HANA sein Jahrzehnt verschaffte, hat der Markt verallgemeinert, und geerbt hat sie eine Generation von Unternehmen, die SAP nicht aufgebaut hat.

SAP HANA Cloud und SAP Datasphere ziehen bei Analyseplattformen seit Jahren gegenüber Snowflake und Databricks den Kürzeren. Kunden kaufen SAP für ERP und legen ihre breiteren Analyselasten auf die Kinder der HANA-Architektur. Die Entwicklung vom Business Warehouse über den Data Lake zum Data Lakehouse fand außerhalb von SAP statt. SAP hat die Wette nicht ins nächste Jahrzehnt der Analyse im Cloud-Maßstab verlängert. Der Markt hat es getan.

Mit Dremio kauft sich SAP in den Markt für Cloud-Analyse zurück, in dem es nie ganz vorn lag: Iceberg-natives Lakehouse, föderierte Abfragen über SAP- und Nicht-SAP-Daten, ein universeller Katalog auf Basis von Apache Polaris. Die Pressemitteilung stellt die Übernahme als Schritt für agentische KI dar. Bei näherem Hinsehen ist die Substanz aber Aufholen im Wettbewerb. Erneut also erhaltende Innovation, in einer Kategorie, die SAP verteidigen musste.

Hier tun Manager, was Manager eben tun.

Ein Verzweiflungswurf?

Die zweite Ankündigung lohnt einen genaueren Blick.

Prior Labs ist ein fünfzehn Monate altes Forschungs-Startup aus Freiburg. Es wurde Ende 2024 rund um TabPFN gegründet, ein Transformer-basiertes Foundation Model für tabellarische Daten, das Frank Hutter und Noah Hollmann Anfang 2025 in Nature veröffentlicht haben. Die technische Substanz ist echt. TabPFN-2.5 steht an oder nahe der Spitze von TabArena, dem Standard-Benchmark für maschinelles Lernen auf Tabellendaten. Die Open-Source-Modelle wurden mehr als drei Millionen Mal heruntergeladen. Das Nature-Paper kommt auf fast eine halbe Million Zugriffe und Hunderte Zitierungen.

Das Team ist ein Forschungsteam. Frank Hutter ist ordentlicher Professor an der Universität Freiburg und der meistzitierte AutoML-Forscher seines Fachs. Noah Hollmann ist Informatiker und Mitautor des ursprünglichen TabPFN-Papers. Sauraj Gambhir kommt aus Venture Capital und M&A. Bernhard Schölkopf, Gründungsberater, ist Direktor am Max-Planck-Institut. Ein starkes Team. Ihre öffentlichen Profile zeigen allerdings vor allem Laufbahnen in Forschung, Hochschule sowie Investment und M&A, keine operative Erfahrung mit Enterprise-SaaS. Ich sehe keinen öffentlichen Beleg dafür, dass das Führungsteam schon einmal ein kommerzielles Softwareunternehmen skaliert hat. Noch im April 2026 suchte Prior Labs seinen ersten Account Executive. SAP gab die Übernahme am 4. Mai 2026 bekannt.

Auch die technische Realität verdient einen kurzen Blick. Seine Stärken spielt das offene, gut dokumentierte TabPFN-2.5 bei kleinen bis mittleren Datensätzen aus. Prior Labs selbst positioniert es bei etwa 50.000 Zeilen und 2.000 Merkmalen. Inzwischen gibt Prior Labs an, ein Scaling Mode erweitere die Architektur auf Millionen Zeilen. Das ist aber noch eher ein entstehendes Produktversprechen als ein breit belegtes Muster für den Produktiveinsatz in SAP-Größenordnung. In der Größenordnung, in der SAP-Kunden tatsächlich arbeiten, mit Millionen Zeilen strukturierter ERP-Daten, bleiben Gradient-Boosted Trees der Standard: günstig, auf CPUs lauffähig, mit geringer Latenz und betrieblich unspektakulär. TabPFN braucht GPU-Speicher, Baummodelle nicht. Die Technologie ist für kleine bis mittlere Tabellendaten wirklich fortschrittlich. Sie ist aber noch nicht das, was bei den Zeilenzahlen und Latenzvorgaben eines SAP-Produktivsystems läuft.

Die Wette auf Prior Labs

Im Februar 2025 sammelte Prior Labs 9 Millionen Euro in einer Pre-Seed-Runde ein. Lead-Investor war Balderton Capital. Beteiligt waren XTX Ventures, Atlantic Labs, Galion.exe und die Hector Stiftung, die Familienstiftung des SAP-Mitgründers Hans-Werner Hector. Der Fortune-Artikel zur Finanzierungsrunde erwähnte, dass einer der beiden ersten Kunden von Prior Labs SAP war, im Stadium eines Proof of Concept. Gemessen an europäischen Pre-Seed-Runden waren 9 Millionen Euro ungewöhnlich viel. Bei marktüblicher Verwässerung entspricht die Runde einer Post-Money-Bewertung von 40 bis 60 Millionen Euro, etwa dem Vierfachen dessen, was in Europa in dieser Phase typisch ist.

Im Januar 2026 trat Yann LeCun dem wissenschaftlichen Beirat von Prior Labs bei, vier Monate vor der Ankündigung.

Ein rationaler, von Wagniskapital getragener Wachstumspfad für ein Unternehmen in der Phase von Prior Labs im Mai 2026 wäre eine Series A über 20 bis 40 Millionen Dollar gewesen, angeführt von einem führenden US-Fonds für Enterprise-KI, bei einer Bewertung von 180 bis 400 Millionen Dollar und mit zwei bis vier weiteren Jahren Unabhängigkeit, um Zugkraft zu zeigen, bevor über eine Übernahme gesprochen würde. Dieser Weg wurde nicht gewählt. Gewählt wurde eine Zusage in Milliardenhöhe, bei einem Unternehmen, an dem die Hector Stiftung bereits beteiligt war.

Fünfzehn Monate nach der Seed-Runde, am 4. Mai 2026, gab SAP die Übernahme bekannt, verbunden mit der Zusage, über vier Jahre mehr als 1 Milliarde Euro zu investieren. Der Kaufpreis selbst wurde nicht veröffentlicht. Sieben Tage vor der Sapphire.

Auf den ersten Blick klingt das, als hätte jemand Christensen zugehört. Prior Labs hat die richtige Struktur: eigenständige Einheit, Forschungskultur, langer Horizont, technische Tiefe unter Führung der Gründer und eine Kategorie, die SAP nicht ignorieren kann. Prior Labs bleibt eine eigenständige juristische Person. Marke, Team und Open-Source-Zusagen bleiben erhalten. Ein Horizont von vier Jahren. Ein Team, das in der Forschung wirklich stark ist. Technische Arbeit, die wirklich wichtig ist.

Und doch fällt die Gestalt dieses Deals auf. Eine Zusage in Milliardenhöhe für ein Team im Forschungsstadium ohne kommerzielle Erfolgsbilanz, mit einer Technologie, die auf kleinere Datenmengen beschränkt ist, als sie bei SAP-Kunden tatsächlich anfallen, eingegangen unter strategischem Zeitdruck, in einem Moment, in dem SAP seine KI-Geschichte für Investoren und Kunden schärfen musste.

Der Zeitpunkt, die auf vier Jahre angelegte Zusage in Milliardenhöhe, SAPs frühere Proof-of-Concept-Beziehung und die Lücke zwischen Benchmark-Führerschaft und Produktreife in SAP-Größenordnung lassen den Deal weniger wie eine fertige Antwort aussehen als wie den Versuch, eine Tür wieder zu öffnen, die SAP bereits geschlossen hatte. Ein Weitwurf aus dem Rückstand.

Zwei Türen

Christensens Modell bietet Marktführern zwei Auswege aus dem Innovator’s Dilemma: die Disruption in einer organisatorisch getrennten Einheit selbst bauen oder den Disruptor kaufen, bevor er skaliert.

Die erste Tür schloss SAP 2023, als EPIC ohne gleichwertigen Ersatz aufgelöst wurde. Das institutionelle Vehikel, das HANA hervorgebracht hat, ist weg. Es gibt keine akademische Partnerschaft am HPI oder anderswo, die sich auf agentennative Architektur für Unternehmenssoftware konzentriert. Die Einheit Composable Process Platform innerhalb von SAP, in der heute ein Großteil der früheren EPIC-Führung arbeitet, ist reguläre Produktentwicklung im Konzern. Ihr fehlen die Bedingungen, die das HPI 2006 bot: lange Horizonte, Hochschulpartnerschaft, Freiheit von vierteljährlichem Lieferdruck, Freiheit von den Forderungen bestehender Kunden, Freiheit von der Sorge, bestehenden Umsatz zu kannibalisieren.

Die zweite Tür ist durch die Bewertungen verschlossen. Die Unternehmen auf der Agentenebene, die wirklich zählen könnten, sind außer Reichweite. OpenAI wird mit mehreren Hundert Milliarden Dollar bewertet, Anthropic in derselben Größenordnung. Microsoft Copilot steckt in einem Unternehmen mit 4 Billionen Dollar Börsenwert. Es gibt kleinere agentennative Startups, die SAP kaufen könnte, aber die architektonisch bedeutenden sind entweder bereits bei Hyperscalern oder so bewertet, als stünden sie kurz davor.

Strategische Käufer zahlen durchaus Preise über Marktniveau, wenn die Bedrohung real und belegt ist. Im Februar 2014 zahlte Facebook 19 Milliarden Dollar für WhatsApp. Der Preis lag beim rund 950-Fachen des Umsatzes der letzten zwölf Monate und galt weithin als defensiv. WhatsApp hatte damals 450 Millionen monatlich aktive Nutzer, eine Million neue Nutzer pro Tag und Gründer, die bereits ein Produkt im großen Maßstab betrieben hatten. Der Preis war hoch. Die Zugkraft war echt.

Prior Labs hat 3 Millionen Open-Source-Downloads, Kunden in der Pilotphase (Proof of Concept), keinen sichtbaren kommerziellen Umsatz, eine im April 2026 begonnene Suche nach dem ersten Account Executive, eine auf Datensätzen bis 50.000 Zeilen validierte Technologie und Gründer, deren Erfolgsbilanz in der akademischen Forschung liegt. Die Vorhersage des Modells bestätigt sich.

Marktführer unter Druck machen Züge, die strukturell richtig aussehen, wirtschaftlich aber überhastet sind. Die Struktur entspricht Christensens Rezept. Die wirtschaftlichen Eckdaten entsprechen dem, was das Modell vorhersagt, wenn der Zug zu spät kommt. Die Größe der Zusage verändert zudem das Umfeld. Ein Forschungsteam, das für langfristige Arbeit geschützt sein sollte, kann sich plötzlich strategischen Erwartungen gegenübersehen, die weit über seine kommerzielle Reife hinausgehen. Genau dieser Druck von oben erstickt interne Innovation normalerweise.

Die Reaktion des Marktes passt zum Modell. Die Ankündigungen zu Dremio und Prior Labs kamen am 4. Mai, und die erste Reaktion fiel verhalten aus. Das beweist nicht, dass die Strategie falsch ist. Es deutet aber darauf hin, dass Investoren die Ankündigungen nicht sofort als Wende ihrer Investmentthese verstanden haben.

Das ist die Lage. Der Ausweg über organisatorische Trennung wurde genau in dem Moment verschlossen, in dem SAP ihn gebraucht hätte. Der Ausweg über Zukäufe wurde vom Markt verschlossen, während SAP Joule baute. Die Züge, die SAP derzeit macht, sind kommerzielle Antworten auf diese Lage: die API Policy, das MCP-Gateway, die Übernahme von Dremio und die Investition in Prior Labs. Ein Ausweg aus ihr ist keiner davon.

Sapphire 2026

Nach Kleins Ausführungen in der Telefonkonferenz zum ersten Quartal, festgehalten von Constellation Research, soll sich die Keynote darauf konzentrieren, „tiefes Domänenwissen in SAPs KI-Agenten einzubringen“. Branchenpartner erwarten eine neu gestaltete Joule-Oberfläche, die Vision der SAP AI Foundation, Neuigkeiten zur Roadmap der Business Data Cloud und die Richtung für S/4HANA Cloud in den nächsten 18 Monaten.

Im April 2001 erkannte Plattner die Bedrohung früh und schleuste ein Retrovirus in SAPs DNA ein. Er kaufte das Unternehmen, das die Gefahr verkörperte, und machte dessen Gründer für den Umbau verantwortlich. 2006 gründete er ein Fachgebiet an einer Hochschule, um die Antwort außerhalb der Reichweite der eigenen Antikörper zu bauen. Beides waren Züge des Gründers. Beide verlangten eine Autorität, die sich über die Managementlogik der bestehenden Organisation hinwegsetzt. Beide brachten architektonische Neuerfindungen hervor, die SAP zwei weitere Jahrzehnte Relevanz verschafften.

SAP besitzt weiterhin die Schicht des Geschäftskontexts, die Enterprise-KI braucht: Prozesssemantik, Berechtigungen, Datenherkunft, Prüfbarkeit und transaktionale Tiefe. Das ist kein kleiner Vorteil. Er könnte reichen, um das Geschäft eine Weile zu verteidigen.

Aber jeder Zug bisher war defensiv: Joule innerhalb der Suite, API-Kontrollen an der Grenze, MCP als genehmigtes Gateway, Dremio als Aufholen bei der Datenplattform und Prior Labs als Import von Spitzenforschung, nachdem das eigene Forschungsvehikel stillgelegt worden war.

Steht hier das ganze Unternehmen auf dem Spiel, und kann die neue Generation darauf eine Antwort geben?

Klein und sein Team haben am 11. Mai die Bühne.