SAP wird am akzeptierten Datensatz geprüft – nicht an der Suite

Zusammenfassung

• SAPs stärkstes Argument ist nicht die Suite-Breite. Es ist die Fähigkeit, den Status von Geschäftsprozessen in den Bereichen Finanzen, Beschaffung, HR, Lieferkette, Betrieb, Berechtigungen, Integration, Prüfnachweise, Support-Lebenszyklus und Cloud-Betrieb akzeptiert zu halten.
• Die Migrations- und Betriebskosten stehen im Zentrum der kommerziellen Prüfung. SAP kann die Fragmentierung von Infrastruktur und Prozessen reduzieren, aber der Wert hängt von der Fit-to-Standard-Disziplin, Datenqualität, Clean-Core-Governance, Partnerumsetzung, Integrationsverantwortung, Ausnahmebehandlung, Schulung und nachhaltigem Support ab.
• Business AI und Joule machen SAP strategisch relevanter, erhöhen aber auch den Akzeptanzstandard. KI kann Arbeit nur dann vorschlagen, zusammenfassen, weiterleiten und koordinieren, wenn der zugrunde liegende Datensatz, die Berechtigungen, Richtlinien, der Prüfpfad und der Rollback-Pfad vertrauenswürdig bleiben.

Der akzeptierte Unternehmensdatensatz ist die eigentliche Werteinheit

Ein ERP-Verkauf kann wie eine Plattformentscheidung aussehen, aber die dauerhafte Werteinheit ist kleiner und weniger glamourös: ein akzeptierter Unternehmensdatensatz. Eine Lieferantenrechnung wird zahlbar. Eine Bestellung wird verbindlich. Ein Wareneingang aktualisiert den Bestand. Ein Geschäftspartner wird gültig. Eine Mitarbeiteränderung wird für Gehaltsabrechnung und Zugang maßgeblich. Ein Abschlussposten wird Teil der Finanzbücher. Ein Produktionsplan wird zur Grundlage für Einkaufs-, Personal- und Lieferzusagen. Dies sind keine Demonstrationen. Es sind wiederholte Akte institutionellen Vertrauens.

Das ist der richtige Maßstab, um SAP SE zu beurteilen. Das Unternehmen verfügt über eine riesige Produktoberfläche: SAP S/4HANA Cloud, RISE mit SAP, Business Technology Platform, Integration Suite, SuccessFactors, Ariba, Concur, Analytik, Business Data Cloud, Joule, Cloud ALM und ein tiefes Dienstleistungs- und Partnerökosystem. Breite ist wichtig, weil Unternehmensprozesse selten innerhalb eines Bildschirms ablaufen. Aber Breite ist keine Akzeptanz.

Ein Workflow wird erst dann akzeptiert, wenn seine Daten sauber genug sind, seine Konfiguration zum Prozess passt, seine Integrationen abgestimmt sind, sein Berechtigungsmodell vertretbar ist, sein Prüfpfad verfügbar ist, seine Ausnahmen sichtbar sind und seine Wirtschaftlichkeit die Kosten übersteigt, dorthin zu gelangen.

Die eigene Unternehmensbeschreibung von SAP weist auf das richtige operative Terrain hin. SAP beschreibt sich selbst als globales Unternehmen für Unternehmensanwendungen und Business AI, dem in den Bereichen Finanzen, Beschaffung, HR, Lieferkette und Kundenerfahrung vertraut wird. Das Unternehmensprofil listet mehr als 110.000 Mitarbeiter aus über 157 Ländern, mehr als 100 Entwicklungsstandorte, mehr als 300 Millionen Cloud-Nutzer-Abonnenten und einen nicht-IFRS-Gesamtumsatz von 36,8 Milliarden Euro im Geschäftsjahr 2025.

Die Investorenergebnisse zeigen, dass die Cloud-Verlagerung kein Experiment mehr ist: Im ersten Quartal 2026 meldete SAP einen aktuellen Cloud-Auftragsbestand von 21,932 Milliarden Euro und einen Cloud-Umsatz von 5,962 Milliarden Euro.

Diese Zahlen belegen Größe und Richtung. Sie belegen nicht, dass der Monatsabschluss, die Lieferanteneinrichtung, die Lagerausnahme oder die HR-Änderung eines Kunden mit weniger Gesamtaufwand als zuvor akzeptiert wird. Der Wert von SAP muss dort geprüft werden, wo die Software zur betrieblichen Wahrheit wird. Ein Käufer sollte fragen: Hat der Workflow den manuellen Abgleich reduziert oder ihn lediglich in ein anderes Team verlagert? Hat das Berechtigungsdesign das Risiko gesenkt oder die Arbeit verlangsamt, sodass die Benutzer Workarounds erfanden?

Hat die Cloud-Migration den Infrastrukturaufwand beseitigt oder neue Abhängigkeiten von Partnern und Anbieter-Roadmaps geschaffen? Hat KI Routinearbeit entfernt oder zusätzliche Prüfarbeit hinzugefügt, weil die Menschen nicht mehr wissen, warum sich ein Datensatz geändert hat?

Der akzeptierte Datensatz hält all diese Fragen zusammen. Er verhindert eine einfache Geschichte, in der SAP gewinnt, weil die Suite breit ist, oder verliert, weil die Implementierung schwierig ist. SAP ist glaubwürdig, weil es nahe an den Geschäftsdaten sitzt, auf die sich Unternehmen tatsächlich stützen. SAP ist kostspielig, weil dieselbe Nähe bedeutet, dass das Unternehmen in Prozesse involviert ist, die nicht einfach zurückgesetzt werden können.

Das kommerzielle Momentum von SAP ist ein Cloud-Übergang, kein Workflow-Ergebnis

Die öffentlichen Finanzkennzahlen von SAP zeigen ein Unternehmen, das seinen Schwerpunkt auf Cloud-ERP und damit verbundene Dienste verlagert. Der integrierte Bericht von SAP für 2025 besagt, dass der Cloud-Umsatz von 17,141 Milliarden Euro im Jahr 2024 auf 21,023 Milliarden Euro im Jahr 2025 gestiegen ist. Der Umsatz mit der Cloud ERP Suite stieg von 14,165 Milliarden Euro auf 18,119 Milliarden Euro und trug 86 % zum gesamten Cloud-Umsatz bei. Der aktuelle Cloud-Auftragsbestand stieg auf 21,05 Milliarden Euro, während der gesamte Cloud-Auftragsbestand 77,29 Milliarden Euro erreichte.

Die Einnahmen aus Softwarelizenzen und Support gingen zurück, was SAP auf den beschleunigten Übergang der Kunden in die Cloud zurückführt.

Das erste Quartal 2026 setzte das Muster fort. Die Investorenseite von SAP meldete einen Anstieg des Cloud-Umsatzes um 19 % auf berichteter Basis und um 27 % zu konstanten Wechselkursen, wobei der Umsatz der Cloud ERP Suite um 23 % auf berichteter Basis und um 30 % zu konstanten Wechselkursen zulegte. Der Ausblick von SAP für 2026 erwartete einen Cloud-Umsatz von 25,8 Milliarden bis 26,2 Milliarden Euro zu konstanten Wechselkursen und einen Cloud- und Softwareumsatz von 36,3 Milliarden bis 36,8 Milliarden Euro. Die finanzielle Richtung ist klar: Die kommerzielle Zukunft, die SAP verkauft, ist eine Cloud- und Suite-Zukunft.

Dieser Übergang verändert das Verhandlungsproblem des Kunden. Im älteren Software-Support-Modell betrieben viele Kunden stark angepasste SAP-Landschaften, On-Premises-Infrastruktur und jahrelange lokale Praktiken rund um Upgrades, Transporte, Schnittstellen und Reporting. Im Cloud-Modell möchte SAP, dass mehr Kunden standardisieren, modernisieren, S/4HANA nutzen, kontinuierliche Innovationen konsumieren und KI- und Datendienste anbinden. Das kann eine rationale Verschiebung sein. Sie kann Infrastrukturaufwand reduzieren, einige Upgrades vereinfachen und neue Funktionen weniger abhängig von einmaligen Kundenprojekten machen.

Aber der Cloud-Übergang verändert auch, wo Kosten auftauchen. Ein Kunde schenkt möglicherweise weniger Aufmerksamkeit der Serverwartung und mehr den Fit-to-Standard-Workshops, der Datenbereinigung, dem Integrations-Redesign, der Benutzerschulung, den Änderungen am Support-Modell, der Partner-Governance, dem Rollendesign und dem Release-Management. Die Rechnung kann sich von Lizenz und Support zu Abonnement und Implementierungsdiensten verlagern. Die betriebliche Abhängigkeit kann sich von einem lokalen Basis-Team zu SAP, einem Hyperscaler, einem Systemintegrator und einem kleineren internen Produktteam verschieben.

Ein Cloud-ERP-System kann stärker standardisiert sein und dennoch teuer sein, um es wahrhaftig zu machen.

Deshalb sollte das finanzielle Momentum als Nachfragebeleg und nicht als Workflow-Beweis behandelt werden. Unternehmen kaufen oder verpflichten sich in großem Umfang zu SAP-Cloud-Diensten. Sie kaufen nicht alle das gleiche Ergebnis. Ein globaler Hersteller, der Finanz- und Lieferkettenprozesse in die SAP S/4HANA Cloud Private Edition verlagert, hat ein anderes Risikoprofil als ein mittelständisches Unternehmen, das einen Public-Cloud-ERP-Umfang übernimmt. Eine öffentliche Einrichtung hat andere Prüfungs- und Datenlokalisierungsvorschriften als ein Einzelhändler.

Ein Beschaffungsteam, das Ariba-Integrationen nutzt, hat eine andere Ausnahmebehandlung als ein Finanzteam, das sich um Konsolidierung und Abschluss kümmert.

Die kommerzielle Frage ist daher nicht, ob SAP ein großer, beständiger Anbieter ist. Es geht darum, ob jeder akzeptierte Workflow nach Berücksichtigung der vollständigen Übergangskosten billiger, sauberer und besser prüfbar wird. Die öffentlichen Belege untermauern die Größe von SAP. Sie beseitigen nicht die Notwendigkeit von Akzeptanznachweisen auf Kundenebene.

Die Migration ist der erste Zuverlässigkeitstest

Das meiste Risiko bei SAP zeigt sich vor dem ersten normalen Geschäftstag nach dem Go-Live. Es erscheint bei der Migration: Stammdaten, die in Altsystemen toleriert wurden, aber in S/4HANA blockierend werden, Felder, die abteilungsübergreifend unterschiedliche Bedeutungen haben, offene Posten, die nicht abgestimmt sind, kundenspezifische Berichte, die undokumentierte Logik verbergen, Lieferantendatensätze mit Duplikaten, in alten Rollen eingebettete Berechtigungsannahmen und Schnittstellen, die seit einem Jahrzehnt "vorübergehend" sind. Migration ist keine Datenladeaufgabe.

Sie ist der erste Test, ob das Unternehmen seinen eigenen Datensatz tatsächlich versteht.

Das Lernmaterial von SAP für SAP S/4HANA Cloud Public Edition macht dies konkret. Es beschreibt ein Migrationscockpit, Migrationsprojekte, Migrationsobjekte, Bereitstellungstabellen, Problembehandlung, zugehörige Apps, Best Practices und unterstützende Anforderungen. Eine Lektion zu lokalen Vorlagen besagt, dass der Benutzer ein Migrationsprojekt erstellt, ein oder mehrere Migrationsobjekte zuweist und das Migrationscockpit eine Bereitstellungstabelle in SAP S/4HANA Cloud für jedes Objekt generiert. Sobald die Tabelle gefüllt und das Projekt abgeschlossen ist, werden die Daten in die Datenbank von SAP S/4HANA Cloud übertragen.

Es besagt auch, dass sichtbare Migrationsobjekte auf aktiven Geschäftsprozessen basieren und dass später aktivierte zusätzliche Prozesse mehr Migrationsobjekte sichtbar machen können.

Diese Mechanismen sind nützlich, weil sie die Migration zwingen, der Form des Geschäftsumfangs zu folgen. Sie zeigen auch, warum Migration nicht durch Werkzeuge gelöst wird. Wenn ein Migrationsobjekt sichtbar ist, weil ein Geschäftsprozess aktiv ist, muss der Kunde dennoch wissen, ob der Prozess aktiv sein sollte, wem die Daten gehören, welche Vorgängerobjekte zuerst existieren müssen, welche Berechtigungen erforderlich sind, wie Fehler behoben werden und wie geladene Datensätze mit nachgelagerten Systemen abgestimmt werden. Eine Bereitstellungstabelle kann die Arbeit organisieren.

Sie kann nicht entscheiden, ob ein Lieferant, ein Material, eine Kostenstelle, ein Mitarbeiter oder eine offene Bestellung maßgeblich ist.

Der akzeptierte Unternehmensworkflow hängt von dieser Autorität ab. Ein Finanzworkflow kann scheitern, weil die Lieferantenstammdaten falsch sind. Ein Beschaffungsworkflow kann scheitern, weil Produkt-, Steuer- und Zahlungsbedingungen nicht übereinstimmen. Ein Lieferketten-Workflow kann scheitern, weil Materialien, Werke, Durchlaufzeiten und Bestandssalden ohne Einigung über die Zuständigkeit geladen wurden. Ein HR-Workflow kann scheitern, weil Organisationszuweisungen und Zugriffsrechte so migriert wurden, als wären sie nur Datensätze, obwohl sie auch definieren, wer handeln darf.

SAP-Käufer sprechen oft von "Umzug zu S/4HANA", als ob das Ziel das System wäre. Der bessere Ausdruck ist "Umzug zu einem akzeptierten Geschäftszustand". Das System kann Daten empfangen. Das Unternehmen muss sie akzeptieren. Diese Akzeptanz erfordert Datenverantwortliche, Migrationsproben, Fehlertriage, Umstellungsdisziplin, Vergleichsberichte, geschäftliche Freigabe und eine Möglichkeit, neue Daten sauber zu halten, nachdem das Migrationsteam gegangen ist. Wenn diese Aufgaben schwach sind, kann sich die Tool-Landschaft von SAP weiterhin wie vorgesehen verhalten, während der Workflow als Geschäftsdatensatz scheitert.

Fit-to-Standard ist eine Governance-Entscheidung, kein Slogan

SAP Activate ist die Methode, die SAP um die Implementierung legt. Die öffentliche Seite beschreibt sechs Phasen: Discover, Prepare, Explore, Realize, Deploy und Run. Sie betont auch Fit-to-Standard-Workshops, betriebsbereite Best Practices, Vorlagen und Beschleuniger, Test-Sprint-Anleitung, Cloud ALM, Qualitätstore, Checkpoints und kontinuierliche Übernahme nach dem Go-Live. Das ist das richtige Vokabular für einen System-of-Record-Workflow, denn die schwierigsten Probleme sind keine isolierten Codefehler. Es sind Entscheidungen darüber, welche Prozessvarianten überleben sollten.

Fit-to-Standard ist mächtig, wenn es echt ist. Wenn ein Kunde Standardprozesse für Finanzen, Beschaffung, Vertrieb, Lieferkette oder HR übernehmen kann, reduziert dies benutzerdefinierten Code, erleichtert Upgrades, senkt die Partnerabhängigkeit und ermöglicht dem Kunden, von den fortlaufenden Veröffentlichungen von SAP zu profitieren. Aber Fit-to-Standard ist oft der Punkt, an dem Politik in die Implementierung einzieht. Eine lokale Geschäftseinheit kann darauf bestehen, dass ihr alter Prozess unverzichtbar ist. Ein Finanzteam akzeptiert einen Standardprozess möglicherweise nur, wenn ein Bericht neu erstellt wird.

Ein Werk behält vielleicht einen manuellen Workaround bei, weil der Standardablauf die Verantwortlichkeit ändert. Ein Beschaffungsteam möchte möglicherweise Ausnahmen, die den Standard untergraben. Ein Berater könnte Komplexität konfigurieren, weil dies einen Workshop-Konflikt schneller löst als die Änderung des Prozesses.

Der akzeptierte Workflow ist die Disziplin, die Fit-to-Standard messbar macht. Die Frage ist nicht, ob der Kunde SAP-Activate-Folien verwendet hat. Es geht darum, ob der endgültige Workflow mit weniger manuellen Ausnahmen, klarerer Zuständigkeit, geringerem Prüfungsrisiko und geringerem Supportaufwand wiederholt werden kann. Wenn der Standardprozess akzeptiert wird, hat SAP ein starkes Argument. Wenn der Standardprozess durch Tabellenkalkulationen, Schattenfreigaben, manuelle Neuerfassung oder inoffizielle Berichte umgangen wird, hat die Implementierung nur Reibung verlagert.

Clean Core schärft dieselbe Frage. Das Material von SAP zur Clean-Core-Erweiterbarkeit besagt, dass die Strategie es S/4HANA-Cloud-Kunden ermöglichen soll, bei Bedarf zu erweitern und dennoch reibungslose Upgrades und den Umgang mit Erweiterungen zu ermöglichen. Der Clean-Core-Kurs von SAP Learning behandelt das S/4HANA Cloud-Erweiterbarkeitsmodell, ABAP Cloud und spezielle Überlegungen für die Private Edition und S/4HANA. Die Botschaft ist kommerziell wichtig: Anpassungen sind nicht verboten, müssen aber gesteuert werden, damit sie den Kunden nicht in einem spröden, nicht aktualisierbaren Zustand festhalten.

Das ist leichter gesagt als durchgesetzt. Ein klassischer SAP-Kunde verfügt möglicherweise über jahrelangen ABAP-Custom-Code, modifizierte Workflows, maßgeschneiderte Berichte, Integrationen und lokale Richtlinien. Einiges davon kodiert legitime Wettbewerbsunterschiede. Einiges davon kodiert veraltete Workarounds. Einiges existiert, weil eine frühere Implementierung eine Betriebsfrage nicht geklärt hat. Clean Core verlangt vom Kunden, notwendige Erweiterungen von Anpassungsschulden zu trennen. SAP kann Modelle, Werkzeuge und Anleitung bereitstellen.

Der Kunde und der Partner müssen immer noch entscheiden, welche alten Verhaltensweisen weiterleben dürfen.

Hier treffen der kommerzielle Wert und das kommerzielle Risiko von SAP aufeinander. SAP ist wertvoll, weil es unternehmensübergreifende Prozesse in großem Maßstab standardisieren kann. SAP ist riskant, weil der Prozessstandard nicht immer der Prozess ist, den die Organisation auszuführen weiß. Der akzeptierte Datensatz ist der Test: Kann die Organisation dem Datensatz vertrauen, ohne das alte System darum herum neu aufzubauen, nachdem Fit-to-Standard- und Clean-Core-Entscheidungen getroffen wurden?

Integration entscheidet, ob der Datensatz weiterkommt

Ein akzeptierter SAP-Datensatz bleibt selten innerhalb von SAP. Eine Bestellung kann Lieferantenzusammenarbeit, Logistikaktualisierungen, Bestandsänderungen, Genehmigungen, Cashflow-Prognosen, Steuerbehandlung und Analysen auslösen. Eine Mitarbeiteränderung kann in Identitätssysteme, Gehaltsabrechnung, Ausgabenwerkzeuge, Lernsysteme und Gebäudezugänge fließen. Ein Kundenauftrag kann Preisgestaltung, Kredit, Fertigung, Lieferung, Umsatzrealisierung und Kundensupport berühren. Wenn die Integration schwach ist, wird SAP nur zu einer maßgeblichen Insel in einem Meer von Abstimmungen.

Das öffentliche Produktmaterial von SAP erkennt dies an. Die Seite zu S/4HANA Cloud Public Edition besagt, dass es sich über SAP Business Technology Platform und SAP Integration Suite mit anderen Unternehmensanwendungen integriert. SAP-Hilfe-Suchausschnitte beschreiben Integration Suite als eine Integrationsplattform der Unternehmensklasse (iPaaS) zum Verbinden und Integrieren von Geschäftsanwendungen und Daten.

Die Implementierungsinhalte von SAP Learning umfassen Integrationskonzepte, Analyse der Integrationslandschaft, SAP Integration Suite, SAP-Best-Practices-Integrationsinhalte, Cloud Integration Automation Service, Best-Practices-Integrationseinrichtung, vom Kunden gesteuerte Integrationen und das Überwachen von Integrationen mit SAP Cloud ALM.

Das ist der richtige Funktionsumfang für das Problem. Aber der Akzeptanztest lautet nicht: "Existiert eine Integration?", sondern: "Bleibt der integrierte Workflow unter Ausnahmebedingungen wahr?" Eine erfolgreiche Bestellschnittstelle reicht nicht aus, wenn eine Lieferantenänderung, eine Steuerregel, ein teilweiser Wareneingang, eine Genehmigungsablehnung, ein Wiederholungsversuch, eine Zeitüberschreitung oder eine doppelte Nachricht die Abstimmung zerstört. Eine Integration von Humankapital reicht nicht aus, wenn Beendigungen, Rollenänderungen, Auftragnehmerumwandlungen oder Identitätskonflikte Zugriffe hinterlassen.

Eine Finanzintegration reicht nicht aus, wenn Nebenbuch- und Hauptbuchzustände auseinanderdriften und Teams dies in Tabellenkalkulationen lösen.

Integration Suite und BTP können kundenspezifische Verrohrungen reduzieren. Sie können Integrationsmuster, APIs, Ereignissteuerung, Adapter, Überwachung und Governance-Oberflächen bereitstellen. SAP Cloud ALM kann bei entsprechender Konfiguration Integrations- und Ausnahmebereiche überwachen. Aber der Kunde besitzt weiterhin die Integrationssemantik. Welches System ist maßgeblich? Wie ist der Wiederherstellungspfad nach einer fehlgeschlagenen Nachricht? Wer darf eine Ausnahme beheben? Wie werden Duplikate erkannt? Wie werden verspätet eintreffende Aktualisierungen behandelt? Was passiert, wenn ein Partnersystem sein ändert?

Welche Protokolle sind Prüfnachweise und welche nur betriebliche Spuren?

Bei System-of-Record-Arbeiten können Integrationsfehler gefährlicher sein als sichtbare Ausfälle. Ein sichtbarer Ausfall stoppt die Arbeit und erregt Aufmerksamkeit. Eine stille Integrationsinkonsistenz lässt die Menschen mit inkonsistenten Datensätzen weitermachen. Die Kosten erscheinen später als fehlerhafter Bestand, verpasste Zahlung, doppelter Lieferant, falsche Berechtigung, unvollständiger Prüfpfad oder Management-Berichterstattung, die nicht abgestimmt werden kann. Die Integrationsoberfläche von SAP ist notwendig. Sie ist nicht ausreichend, es sei denn, das Unternehmen baut eine Ausnahmeverantwortung darum herum auf.

Der kommerzielle Punkt ist einfach: Je mehr SAP zum Kern wird, desto mehr muss jedes Nicht-SAP-System den Datensatz von SAP respektieren oder ihn explizit in Frage stellen. Das ist ein Governance-Problem, das als Technologieproblem getarnt ist. Ein Käufer sollte die Schnittstellen bewerten, aber auch die Menschen, die sie nach dem Go-Live betreuen werden.

Berechtigung und Prüfbarkeit sind Produktionsmerkmale

In einem unternehmensweiten System of Record ist Sicherheit nicht nur eine Perimeter-Angelegenheit. Sie ist Teil der Bedeutung des Datensatzes. Eine Buchung, die von einer falschen Rolle akzeptiert wird, ist nicht dasselbe Geschäftsereignis. Eine Lieferantenänderung ohne ordnungsgemäße Genehmigung ist nicht nur eine Datenaktualisierung. Ein Workflow, der es demselben Benutzer erlaubt, eine Transaktion zu beantragen, zu genehmigen und freizugeben, kann gleichzeitig effizient und inakzeptabel sein.

Der Wert von SAP in regulierten und komplexen Organisationen hängt von der Fähigkeit ab, Berechtigungs- und Prüfnachweise betriebsfähig und nicht dekorativ zu machen.

Die Benutzerzugriffs- und Sicherheitsreise von SAP Learning deckt Berechtigungskonzepte und -werkzeuge für SAP Business Suite, SAP HANA, S/4HANA und S/4HANA Cloud Public Edition ab. Sie umfasst SAP Identity Access Management, SAP HANA-Benutzerverwaltung, S/4HANA-Benutzerwartung, Geschäftsrollen- und Berechtigungskonzepte, SAP Fiori-Berechtigungen und Geschäftsrollen, Cloud Identity Services sowie Fehlerbehebung und Analyse von Berechtigungen und Benutzerzugriffen durch Berichte und Analysen.

Die Implementierungsinhalte von SAP Learning umfassen auch das Erstellen und Anpassen von Geschäftsrollen, das Definieren von Einschränkungen und das Abstimmen des Fiori-Launchpads mit Rollen.

Das zeigt Käufern, wie die Kontrolloberfläche aussieht. Es beweist nicht, dass das Rollenmodell gut ist. Unternehmensberechtigungen sind schwierig, weil Rollen nah an der organisatorischen Wahrheit liegen. Ein Einkaufssachbearbeiter, Einkäufer, Werksleiter, Shared-Services-Benutzer, Finanzgenehmiger, Projektbuchhalter, HR-Administrator und externer Prüfer benötigen möglicherweise jeweils Zugriffe, die alte Abteilungsgrenzen überschreiten. Zu wenig Zugriff schafft Workarounds. Zu viel Zugriff schafft Kontrollrisiken. Vorübergehender Zugriff wird dauerhaft, wenn niemand die Überprüfung verantwortet.

Notfallzugriff wird normal, wenn Prozesse schlecht gestaltet sind.

SAP-Hilfe-Suchausschnitte identifizieren auch, dass Sicherheitsauditprotokolle von S/4HANA Cloud Public Edition sicherheitsrelevante Ereignisse enthalten und weisen darauf hin, dass Protokolle abgerufen und in eine Security-Information-and-Event-Management-Lösung integriert werden können. Das ist wichtig, aber die Prüfbarkeit hängt wiederum von Konfiguration und Überprüfung ab. Ein Protokoll, das existiert, aber nicht überwacht wird, verhindert keine schlechte Änderung. Eine SIEM-Integration, die Ereignisse ohne Geschäftskontext sammelt, kann Analysten überfluten.

Ein Rollenwechsel, der technisch protokolliert ist, kann einem Prüfer dennoch unerklärt bleiben.

Hier erhöht KI den Einsatz. Wenn Joule oder eine andere KI-gestützte Oberfläche Benutzern hilft, zu navigieren, zusammenzufassen, zu empfehlen oder Arbeit zu koordinieren, muss das Berechtigungsmodell die Grenze für Aktionen bleiben. Ein hilfreicher Assistent, der das Auffinden offener Bestellungen erleichtert, ist wertvoll. Ein System, das anwendungsübergreifend handeln kann, muss durch Geschäftsrollen, Richtlinien, Genehmigungen und Prüfnachweise eingeschränkt sein. Je natürlicher die Schnittstelle wird, desto wichtiger ist es, dass die Autoritätsaufzeichnung formell bleibt.

Die Sicherheits-, Identitäts- und Prüfungsoberflächen von SAP sind glaubwürdig, weil das Unternehmen seit Jahrzehnten große regulierte Unternehmen bedienen muss. Die Schwäche liegt nicht im Fehlen von Kontrollen. Die Schwäche liegt darin, dass Kontrollen Gestaltung erfordern. Ein Käufer sollte Berechtigungsdesign, Zugriffsüberprüfung, Rollentests, Abruf von Prüfprotokollen und Sicherheitsüberwachung als Produktionsaufgaben behandeln, nicht als späte Implementierungsaufgaben.

Cloud-Betrieb verschiebt die Kontrollgrenze

RISE mit SAP und S/4HANA Cloud verlagern den Schwerpunkt von SAP in Richtung Cloud-Betrieb. Die RISE-Seite von SAP positioniert das Angebot als Möglichkeit, On-Premises-ERP in die Cloud zu transformieren, ERP zu modernisieren und KI-Werte durch eine Methodik, Expertenanleitung, Migrations- und Modernisierungsassistenten sowie kontinuierliche Innovation zu erschließen. Ein aktuelles öffentliches Marktsignal verstärkt das Muster: SAP gab am 30. Juni 2026 bekannt, dass Nokia einen mehrjährigen Vertrag mit SAP zur Nutzung der RISE with SAP Methodology unterzeichnet hat, wobei SAP S/4HANA auf Microsoft Azure gehostet wird.

SAP erklärte, dass die Vereinbarung die Migration der SAP-Landschaft von Nokia über Prozesse, Daten, Anwendungen und Betriebsmodelle hinweg abdeckt und dass SAP die S/4HANA-Softwareumgebung in der Cloud betreiben und verwalten wird.

Diese Art von Vereinbarung zeigt, warum SAP strategisch relevant bleibt. Große Unternehmen kaufen nicht einfach eine neue Anwendung. Sie verlagern kritische Betriebsdatensätze in ein verwaltetes Cloud-Modell, das SAP, einen Hyperscaler und oft große Implementierungspartner umfasst. Der Vorteil ist Fokus: Der Kunde kann weniger Aufwand in die Infrastruktur und mehr in Geschäftsprozesse, Daten und Innovation stecken. Das Risiko ist Abhängigkeit: Der Kunde ist nun den Servicegrenzen des Anbieters, der Partnerumsetzung, der Wahl der Cloud-Region, den Veröffentlichungsplänen, Supportprozessen und Vertragsbedingungen ausgesetzt.

Die Cloud-Service-Statusseite des SAP Trust Center ist genau deshalb nützlich, weil sie öffentliche Sichtbarkeitsgrenzen definiert. SAP gibt an, dass die Seite die aktuelle Verfügbarkeit und den Leistungsverlauf für SAP-Cloud-Dienste anzeigt, während das Kundenportal SAP for Me kundenspezifische Mandantendetails bereitstellt.

SAP erklärt, dass es bei Cloud-Diensten eine Verfügbarkeit von 99,7 % anstrebt, sofern nicht anders angegeben, dass regelmäßige Wartungsarbeiten und größere Upgrade-Ausfallzeiten nicht auf der öffentlichen Statusseite angezeigt werden und dass Störungen oder Beeinträchtigungen nur dann sichtbar sind, wenn sie mindestens fünf Minuten andauern und mindestens 5 % der produktiven Systeme in einem Rechenzentrum betreffen. Der öffentliche Status ist daher nicht die Mandantenwahrheit.

Für akzeptierte Workflows sind diese Grenzen von Bedeutung. Ein Finanzabschluss kann durch einen kurzen mandantenspezifischen Vorfall, geplante Wartung, einen Integrationsausfall, ein Identitätsproblem oder einen Ausfall eines Partnersystems gestört werden, der nicht als breite öffentliche Störung erscheint. Eine Beschaffungsgenehmigung kann sich verzögern, weil ein externer Dienst oder ein Identitätspfad ausfällt. Ein Lieferketten-Workflow kann von einer Cloud-Region, einem sekundären Rechenzentrum oder einem Netzwerkpfad abhängen. Die öffentliche Statusseite kann ein Signal sein.

Sie ist nicht das Betriebsbuch für den Geschäftsprozess eines Kunden.

Die Rechenzentrums- und Datenschutzseiten von SAP fügen eine weitere Ebene hinzu. SAP gibt an, dass einige Cloud-Dienste es Kunden ermöglichen, bei der Implementierung ein Rechenzentrum auszuwählen, und dass sekundäre Rechenzentren in derselben Region Backup und Disaster Recovery unterstützen. Es wird auch darauf hingewiesen, dass das Portfolio schrittweise in die Rechenzentrumskarte integriert wird und dass einige Dienste möglicherweise in anderen als den angezeigten Rechenzentren bereitgestellt werden.

SAP listet Datenresidenz, Compliance, Disaster Recovery, Verschlüsselung, Zugriffskontrollen, Audits, redundante Systeme, geografische Verteilung, automatisiertes Failover und Tests als Rechenzentrumsfähigkeiten auf. Die Datenschutzseite beschreibt Datenverarbeitungsvereinbarungen, technische und organisatorische Maßnahmen, Unterauftragsverarbeiter, Standardvertragsklauseln, Zertifizierungen, Auditberichte und Privacy by Design.

Dies sind notwendige Zusicherungen für einen globalen ERP-Anbieter. Sie sind kein Ersatz für eine kundenspezifische Due Diligence. Die Datenresidenz hängt vom Dienst, Land, der Region, dem Unterauftragsverarbeiter, dem Vertrag, der Integration, dem Supportpfad und der Implementierungsentscheidung ab. Disaster Recovery ist erst dann aussagekräftig, wenn der Kunde die Wiederherstellungszeit, den Wiederherstellungspunkt, Abhängigkeiten und den Prozess zur Abstimmung wiederhergestellter Datensätze kennt. Cloud-Betrieb kann SAP zuverlässiger machen als eine fragile lokale Umgebung.

Er kann aber auch die Fehleranalyse erschweren, es sei denn, die Zuständigkeiten sind explizit.

Support-Lebenszyklus-Druck ist Teil der Kaufentscheidung

SAP-Kunden bewerten S/4HANA nicht im luftleeren Raum. Viele bewerten es unter dem Druck des Support-Lebenszyklus. Die Support-Seite von SAP besagt, dass es mindestens eine SAP S/4HANA-Version bis Ende 2040 in der Wartung geben wird. Dieselbe Seite besagt, dass die Kernanwendungen von SAP Business Suite 7 bis Ende 2027 Mainstream-Wartung erhalten, gefolgt von einer optionalen erweiterten Wartung von Anfang 2028 bis Ende 2030 mit einem Zuschlag von zwei Prozentpunkten auf die Wartungsbasis. Kunden, die sich nicht für die erweiterte Wartung entscheiden, oder nach deren Ende, wechseln in die kundenspezifische Wartung.

Dieser Zeitplan ist kommerziell zentral. Er schafft ein Migrationsfenster für langjährige SAP-Kunden, die noch auf Business Suite, ECC oder verwandte Landschaften angewiesen sind. Für einige lautet die Entscheidung nicht: "Sollten wir jetzt modernisieren?", sondern: "Wie vermeiden wir es, in teurem Support gefangen zu sein und gleichzeitig die Geschäftskontinuität zu wahren?" Die Antwort kann S/4HANA Cloud Public Edition, S/4HANA Cloud Private Edition, RISE mit SAP, selektive Transformation, eine schrittweise Einführung oder ein langsamerer Weg mit erweiterter Wartung sein. Jede Wahl hat ein anderes Risikoprofil.

Der Druck des Support-Lebenszyklus kann Unternehmen helfen, schwierige Entscheidungen zu treffen. Er kann eine Bestandsaufnahme von Custom-Code, Datenqualität, Prozessvarianten, nicht unterstützten Integrationen und veralteter Berichterstattung erzwingen. Er kann Aufmerksamkeit der Geschäftsleitung schaffen, die gewöhnlichen Modernisierungsprogrammen fehlt. Aber Druck kann auch zu schlechter Akzeptanz führen. Ein Projekt, das hauptsächlich von Terminen getrieben wird, kann migrierte Komplexität ohne Neugestaltung akzeptieren. Es kann Tests komprimieren. Es kann zulassen, dass eine Partnerkonfiguration zum De-facto-Prozess wird.

Es kann die Datenbereinigung bis nach dem Go-Live verschieben, wo sie zur permanenten Supportarbeit wird.

Deshalb sollte der Support-Lebenszyklus Teil des Kostenmodells sein und keine Angsttaktik. Erweiterte Wartung hat einen Preis. Migration ebenso. Das Verschieben der Migration ebenso. Ein fehlgeschlagenes Go-Live ebenso. Ein Clean-Core-Redesign, das alten Custom-Code entfernt, aber erfordert, dass die Mitarbeiter neu lernen, wie die Arbeit erledigt wird. Die Cloud-Strategie von SAP mag für viele Kunden richtungsweisend sein, aber ein Kunde sollte dennoch die Kosten jedes akzeptierten Workflows berechnen und nicht nur die Kosten für das Verbleiben in alter Wartung.

Die Wartungszusage für S/4HANA bis 2040 ist auch kein Versprechen, dass jede Implementierungsentscheidung zukunftssicher ist. Ein stark angepasstes Private-Cloud-System kann weiterhin Upgrade-Reibung verursachen. Eine Public-Cloud-Implementierung kann immer noch unter Prozessinkongruenz leiden. Eine Integrationslandschaft kann immer noch schlecht altern. SAP kann eine unterstützte Produktlinie bereitstellen. Der Kunde muss seinen Geschäftsdatensatz aktualisierbar halten.

Cloud ALM zeigt die Form der Betriebsaufgaben

Die Aufmerksamkeit für die Implementierung erreicht ihren Höhepunkt in der Regel vor dem Go-Live, aber der eigentliche Test für SAP ist der Betriebszustand. Ein System-of-Record-Workflow wird nur dann wertvoll, wenn er betrieben, überwacht, verbessert und repariert werden kann, nachdem die Berater gegangen sind und die Benutzer zur normalen Arbeit zurückgekehrt sind. SAP Cloud ALM ist wichtig, weil es zeigt, wie SAP sich die Betriebsaufgaben vorstellt.

SAP beschreibt Cloud ALM als eine sofort einsatzbereite native Cloud-Lösung und zentralen Einstiegspunkt für die Verwaltung von SAP-Landschaften durch geführte Implementierung und hochautomatisierten Betrieb. Die Support-Seite besagt, dass es in berechtigten Cloud- oder Enterprise-Support-Abonnements enthalten ist.

Dieselbe Seite listet Wertbereiche auf: Fit-to-Standard-Workshops, automatische Zuweisung von Teamaufgaben, zentrale Orchestrierung von Testaktivitäten, konsistente Bereitstellung in der Produktion, durchgängige Nachverfolgbarkeit, Geschäftsprozessleistung, Anomalievorhersage, Automatisierung zur Verkürzung der Lösungszeit, Analytik, Clean-Core-Übernahme, konforme Datenkontrolle und zuverlässiger Betrieb.

Das Betriebsexpertenportal listet Bereiche wie Geschäftsprozessüberwachung, synthetische Benutzerüberwachung, Integrations- und Ausnahmeüberwachung, Job- und Automatisierungsüberwachung, Benutzer- und Leistungsüberwachung, Zustandsüberwachung, Echtbenutzerüberwachung und Ausnahmemanagement auf.

Diese Liste ist eine ernsthafte Betriebszustandskarte. Sie erkennt an, dass akzeptierte Workflows auf vielfältige Weise scheitern können. Ein Geschäftsprozess kann langsam sein, nicht ausgefallen. Eine Integration kann Wiederholungsversuche durchführen, nicht defekt sein. Ein Job kann verspätet abgeschlossen werden. Eine Benutzererfahrung kann sich verschlechtern, bevor jemand ein Ticket meldet. Eine Ausnahme kann unbearbeitet bleiben. Eine Bereitstellung kann technisch erfolgreich sein, aber nachgelagerte Fehler verursachen.

Das richtige Überwachungsmodell muss über Geschäftsprozess-, Anwendungs-, Integrations-, Job-, Benutzer- und Erweiterungsebenen hinweg sehen können.

Die Vorsicht besteht darin, dass die Überwachung nur so wertvoll ist wie das sie umgebende Betriebsmodell. Cloud ALM kann Dashboards, Aufgaben, Nachverfolgbarkeit und Warnungen bereitstellen. Es kann nicht entscheiden, welche Ausnahme eine Lieferung blockieren sollte, welche ausgefallene Schnittstelle eine Finanzfreigabe erfordert, welche Jobverzögerung tolerierbar ist oder welches Support-Team eine benutzerdefinierte BTP-Erweiterung besitzt. Es kann auch nicht von sich aus eine Kultur der Verbesserung nach dem Go-Live schaffen. Die Run-Phase in SAP Activate ist keine Formalität. Hier wird Akzeptanz kontinuierlich.

Für Käufer ist die praktische Frage, ob Cloud ALM der Ort wird, an dem Arbeit verwaltet wird, oder nur ein weiteres Dashboard. Ein starker SAP-Kunde wird Cloud ALM mit Zuständigkeiten verbinden: benannte Prozessverantwortliche, Support-Warteschlangen, Release-Kalender, Datenqualitätsbehebung, Testautomatisierung, Regressionsnachweise, Überprüfung von Integrationsausnahmen und geschäftliche Freigabe. Ein schwacher Kunde wird die Überwachung einschalten und die eigentliche Systemverwaltung weiterhin per E-Mail, Tabellenkalkulation und Flur-Eskalation betreiben.

Die Betriebswerkzeuge von SAP sind glaubwürdig, weil sie auf reale Fehlermodi abzielen. Der kommerzielle Wert hängt davon ab, ob der Kunde die personellen und prozessualen Disziplinen finanziert, die erforderlich sind, um auf das zu reagieren, was die Werkzeuge aufdecken.

Business AI ist ein Akzeptanzrisiko ebenso wie eine Chance

Die KI-Geschichte von SAP ist strategisch wichtig, weil SAP nahe am Geschäftskontext sitzt, der generischen KI-Systemen oft fehlt. Die Joule-Seite von SAP besagt, dass Joule KI-Assistenten und automatisierte Workflow-Funktionen in einem einheitlichen Arbeitsbereich zusammenführt, Geschäftsdaten und SAP-Geschäftsprozessexpertise nutzt, SAP- und Nicht-SAP-Systeme vereinheitlicht und auf Sicherheits-, Governance- und Datenrahmenwerken aufbaut. Das zugehörige Joule-Produktmaterial von SAP besagt, dass diese KI-Funktionen Geschäftsprozessexpertise, Rollenkontext und Prozesskontext nutzen, um Arbeit zu koordinieren.

Es verweist auch auf SAP Knowledge Graph, Geschäftsdaten, Governance und eine einheitliche vertrauenswürdige Datenschicht in SAP Business Data Cloud.

SAP Business Data Cloud ist das begleitende Argument. SAP gibt an, dass es SAP- und Drittanbieterdaten mit einem Business Data Fabric vereinheitlicht und steuert, eine vertrauenswürdige Datengrundlage für KI-gesteuerte Automatisierung unterstützt, geschäftskritische Daten mit Geschäftsprozessen, Richtlinien und Logik harmonisiert und Funktionen wie Analytics Cloud, Datasphere, Business Warehouse-Modernisierung, SAP Databricks, HANA Cloud und Master Data Governance umfasst. Einfach ausgedrückt argumentiert SAP, dass KI auf Geschäftsdatensätzen handeln sollte, die ihre Semantik, Richtlinien und ihren Prozesskontext kennen.

Das ist eine bessere KI-These als "Fügen Sie einen Chatbot zum ERP hinzu". Unternehmensworkflows sind voller Bedeutung, die aus Rohtext nicht ersichtlich ist: Genehmigungslimits, Zahlungsbedingungen, Werkscodes, Buchungsperioden, Materialarten, Steuerjurisdiktionen, Lieferantenrisiko, Arbeitsregeln, Vertragsdaten und Funktionstrennungsbeschränkungen. Ein KI-Assistent, der diese Strukturen nicht versteht, ist gefährlich. Ein KI-Assistent, der im SAP-Prozesskontext verankert ist, kann Benutzern möglicherweise helfen, zu navigieren, zusammenzufassen, zu entwerfen, zu empfehlen, abzugleichen, zu triagieren oder Routinearbeit zu koordinieren.

Aber KI verändert auch den Akzeptanzstandard. Ein menschlicher Benutzer, der sich durch eine Fiori-App klickt, hinterlässt eine Art von Spur. Ein Assistent, der automatisierte Schritte systemübergreifend koordiniert, hinterlässt eine andere. Wer hat die Aktion genehmigt? Welche Daten hat die KI verwendet? War die Empfehlung richtlinienkonform? Hatte die KI-Schicht die Berechtigung, den Zustand zu ändern, oder nur vorzuschlagen? Welcher Ausnahmepfad existiert, wenn die KI falsch liegt? Wie wird eine schlechte automatisierte Aktion zurückgesetzt? Welche Protokolle sind für die Prüfung ausreichend? Was passiert, wenn sich ein Modell ändert?

Die öffentlichen Belege beantworten diese Fragen nicht auf Mandantenebene. Sie stützen die Positionierung von SAP: KI wird in Unternehmensworkflows eingebettet, und SAP möchte sie in gesteuerten Geschäftsdaten verankern. Das macht SAP relevanter, nicht weniger. Es bedeutet auch, dass Kunden Joule oder KI-Automatisierung nicht nach Konversationsflüssigkeit bewerten sollten. Sie sollten bewerten, ob KI-gestützte Arbeit zu einem akzeptierten Datensatz werden kann, ohne Berechtigung, Nachweise oder Rechenschaftspflicht zu schwächen.

Der sicherste kurzfristige KI-Wert könnte in der Unterstützung bei Aufgaben liegen, die noch menschliche Akzeptanz erfordern: Auffinden von Datensätzen, Zusammenfassen von Ausnahmen, Entwerfen von Erklärungen, Vorschlagen nächster Schritte, Identifizieren von Anomalien, Generieren von Testunterstützung oder Hilfe bei der Implementierungsanleitung. Vollständig autonome, zustandsändernde Workflows erfordern viel stärkere Belege. SAP mag auf diese Zukunft hinarbeiten, aber der Datensatz muss wichtiger bleiben als die Automatisierungsschicht.

Partner und Kunden besitzen weiterhin einen großen Teil des Ergebnisses

Die Produktoberfläche von SAP kann den irreführenden Eindruck erwecken, dass SAP das gesamte Ergebnis kontrolliert. Das tut es nicht. Ein akzeptierter Unternehmensworkflow hängt von SAP-Software, SAP-Cloud-Diensten, Hyperscale-Infrastruktur in einigen Modellen, Implementierungspartnern, Kundenprozessverantwortlichen, Datenbesitzern, Sicherheitsteams, Prüfern, Integrationsteams und Endbenutzern ab. Fehler können in jeder dieser Schichten entstehen.

Diese Grenze ist wichtig, weil Kunden oft im Nachhinein Schuld zuweisen. Wenn eine Migration Daten vermisst, war dann das Werkzeug unzureichend, die Zuordnung falsch, die Quelldaten schlecht, der Partner in Eile oder der Geschäftseigentümer abwesend? Wenn ein Workflow langsam ist, liegt das Problem dann an der Konfiguration, am Custom-Code, an der Integration, an der Benutzerschulung, am Netzwerkpfad, am Release-Zeitpunkt oder am Prozessdesign?

Wenn eine KI-Empfehlung falsch ist, liegt das Problem dann am Modellverhalten, am fehlenden Kontext, an schlechten Stammdaten, an schwachem Instruktionsdesign, an der Berechtigung oder am übermäßigen Vertrauen des Benutzers? Die Antwort kann geteilt sein.

Das kommerzielle Risiko ist die Partnerabhängigkeit. SAP-Implementierungsarbeit ist spezialisiert, und große Programme erfordern oft Systemintegratoren, Beratungsfirmen, Datenmigrationsspezialisten, Change-Manager, Sicherheitsexperten und laufende Managed Services. Gute Partner können den Wert von SAP realisieren. Schwache Partner können SAP zu einem kostspieligen Kompromisspaket machen. Der Kunde benötigt dennoch interne Zuständigkeit, denn kein Partner kann dauerhaft die geschäftliche Bedeutung eines Datensatzes besitzen.

Der akzeptierte Workflow bietet eine Möglichkeit, die Grenze zu verwalten. Anstatt zu fragen, ob SAP oder der Partner "das System geliefert hat", kann der Kunde Akzeptanzkriterien für wiederholte Workflows definieren. Ein Purchase-to-Pay-Workflow wird nur dann akzeptiert, wenn Lieferantenstammdaten, Bestellerstellung, Genehmigungen, Wareneingang, Rechnungsabgleich, Ausnahmen, Zahlung, Prüfnachweise und Reporting allesamt in gewöhnlichen und Grenzfällen funktionieren.

Ein Record-to-Report-Workflow wird nur dann akzeptiert, wenn Buchungen, Nebenbuchabstimmung, Kontrollen, Abschlussaufgaben, Konsolidierung, Reporting und Prüfungsunterstützung ohne versteckte Tabellenkalkulationen funktionieren. Ein HR-Workflow wird nur dann akzeptiert, wenn Mitarbeiterdaten, Rollenänderungen, Gehaltsabrechnungsabhängigkeiten, Identitätsbereitstellung, Genehmigungen und Datenschutzkontrollen aufeinander abgestimmt sind.

Diese Kriterien sollten vor dem Go-Live festgelegt und nach dem Go-Live beibehalten werden. Sie verwandeln SAP von einer Systemimplementierung in eine betriebliche Verpflichtung. Sie machen auch die Leistung der Partner messbar. Ein Partner, der Bildschirme konfiguriert, aber keine Nachweise für akzeptierte Workflows liefern kann, ist nicht fertig.

Das Kostenmodell muss Überwachung und Ausnahmebehandlung einschließen

SAP kann auf offensichtliche Weise teuer sein: Abonnement, Lizenzen, Implementierung, Partnergebühren, Schulung, Support, Integration, Datenmigration, Change-Management und interne Zeit. Die weniger offensichtlichen Kosten entscheiden oft über den Business Case. Überwachungskosten laufen nach dem Go-Live weiter. Ausnahmen müssen triagiert werden. Rollen müssen überprüft werden. Schnittstellen müssen abgestimmt werden. Stammdaten müssen gesteuert werden. Releases müssen getestet werden. KI-Ergebnisse müssen überprüft werden. Workarounds müssen aufgespürt werden. Berichten muss vertraut oder sie müssen ausgemustert werden.

Die öffentlichen Seiten von SAP skizzieren diese Kosten, ohne sie pro Workflow zu beziffern. SAP Activate umfasst Tests, Qualitätstore, Fit-to-Standard-Workshops, Bereitstellung und Run. SAP Cloud ALM umfasst Testorchestrierung, Nachverfolgbarkeit, Betriebsüberwachung und Ausnahmebereiche. Die Migrationsinhalte von SAP Learning umfassen Problembehandlung und Vorgängeranforderungen. Die Sicherheitsschulung deckt Berechtigungsdesign und Fehlerbehebung ab. Die Seiten des Trust Center behandeln Datenschutz, Unterauftragsverarbeiter, Rechenzentren und Verfügbarkeitsgrenzen. KI-Seiten betonen Governance und vertrauenswürdige Daten.

Nichts davon ist in der Praxis kostenlos.

Der Nenner des Käufers sollte der akzeptierte Workflow sein. Wie viele manuelle Schritte sind für eine Lieferantenrechnung vor und nach SAP erforderlich? Wie viele Ausnahmen erfordern eine Expertenprüfung? Wie oft verlassen Benutzer SAP zugunsten von Tabellenkalkulationen? Wie viele fehlgeschlagene Integrationsnachrichten treten pro tausend Transaktionen auf? Wie viele Rollenänderungen erfordern ein Eingreifen des Sicherheitsteams? Wie viele Release-Tests sind erforderlich, um einen Schlüsselprozess zu erhalten? Wie viel Supportaufwand bleibt nach der Stabilisierung? Wie viel KI-Unterstützung übersteht die Compliance-Prüfung?

Dieser Ansatz wird SAP manchmal stark begünstigen. Ein fragmentiertes Unternehmen mit vielen lokalen Systemen, manuellen Genehmigungen, inkonsistenten Stammdaten, schwachen Prüfnachweisen und spröder Integration kann von der Standardisierung stark profitieren. SAP kann eine gemeinsame Prozesssprache, einen zentralen Datensatz, Kontrollen, Analytik und einen Integrationspfad bereitstellen, die selbst zu bauen teuer wäre. Der Wert ist besonders plausibel, wenn die Geschäftskomplexität real ist und die Alternative nicht Einfachheit, sondern angehäufte lokale Schulden sind.

Derselbe Ansatz kann den Fall von SAP auch schwächen. Wenn ein Kunde eine begrenzte Prozesskomplexität, schlechte Abstimmung der Führungskräfte, schwache Datenverantwortung oder eine mangelnde Änderungsbereitschaft hat, kann SAP zu einem teuren Weg werden, um Unordnung zu formalisieren. Wenn die Organisation Standardprozesse, Clean-Core-Grenzen oder Cloud-Betriebsgrenzen nicht akzeptieren kann, zahlt sie möglicherweise für die Modernisierung, während sie alte Supportkosten in neuen Formen beibehält. Wenn Benutzer weiterhin Neben-Tabellenkalkulationen mehr vertrauen als SAP-Berichten, wurde das System of Record nicht akzeptiert.

Es gibt keinen universellen SAP-ROI. Es gibt nur die Betriebsmathematik eines bestimmten Unternehmensworkflows, nachdem alle Überwachungs-, Integrations-, Ausnahme-, Support- und Änderungskosten berücksichtigt wurden.

Was den Wert von SAP stärker belegen würde

Die öffentlichen Belege reichen aus, um ein vorsichtiges Urteil zu stützen, aber keinen vollständigen betrieblichen Befund. Stärkere Belege würden auf Workflow-Ebene gemessen. Für den Finanzbereich könnten dies die Dauer des Abschlusszyklus, das Volumen manueller Buchungen, Abstimmungsfehler, Prüfungsanpassungen, Kontrollausnahmen und Support-Tickets nach dem Go-Live umfassen. Für die Beschaffung könnten es die Durchlaufzeit von Bestellungen, Ausnahmen beim Rechnungsabgleich, Fehler in Lieferantenstammdaten, Genehmigungsnacharbeit und Zahlungssperren sein.

Für HR könnten es die Genauigkeit von Mitarbeiterdaten, die Bereitstellungszeit für Zugriffe, Gehaltsabrechnungskorrekturen und Datenschutzvorfälle sein. Für die Lieferkette könnten es Bestandsgenauigkeit, Planungsausnahmen, Zuverlässigkeit von Lieferzusagen und Integrationsfehler sein.

Migrationsbelege wären besonders wertvoll: Anzahl der Migrationsobjekte, Fehlerraten pro Objekt, Umstellungsdauer, offene kritische Fehler beim Go-Live, Stunden für die Datenqualitätsbehebung und nachgelagerte Abstimmungsergebnisse. Integrationsbelege würden Nachrichtenvolumen, Wiederholungsraten, ungelöste Ausnahmen, Duplikatsbehandlung und die Freigabe durch den Geschäftseigentümer zeigen. Sicherheitsbelege würden die Ergebnisse von Rollenüberprüfungen, Funktionstrennungskonflikte, die Nutzung von Notfallzugriffen, den Abruf von Prüfprotokollen, SIEM-Korrelation und die Rezertifizierung von Zugriffen zeigen.

Cloud-Belege würden mandantenspezifische Verfügbarkeit, Wartungsfenster, Wiederherstellungstests und Support-Reaktion zeigen.

Für KI-Belege wäre ein anderer Standard erforderlich. Sie sollten nicht nur zeigen, dass Joule oder eine verwandte KI-Automatisierung eine Aufgabe abschließen kann, sondern dass dies wiederholt mit korrekten Berechtigungen, angemessenen Nachweisen, zuverlässiger Ausnahmebehandlung, klarer menschlicher Aufsicht und Rollback möglich ist. Eine Demonstration, bei der ein Assistent einen Datensatz findet oder eine Antwort entwirft, ist nützlich. Ein Produktionsworkflow, bei dem automatisierte Software den Unternehmenszustand ändert, erfordert den Nachweis, dass die KI die Autorität des Datensatzes nicht geschwächt hat.

Kundengeschichten und Pressemitteilungen können nützliche Signale sein, sollten aber sorgfältig gewichtet werden. Die Nokia-Ankündigung von SAP ist aktuell und relevant, weil sie zeigt, wie ein großes Unternehmen SAP S/4HANA in ein Betriebsmodell mit RISE mit SAP und Azure überführt. Sie zeigt nicht das realisierte Betriebsergebnis. Die echten Belege werden später kommen, wenn sich zeigt, ob Nokia und ähnliche Kunden akzeptierte Workflows mit weniger Komplexität, besserer Prüfbarkeit und niedrigeren Gesamtänderungskosten betreiben können.

Solange diese Belege nicht öffentlich sind, sollte die Gewissheit des Artikels moderat bleiben. SAP verfügt über die Produkttiefe, finanzielle Größe, den Lifecycle-Hebel und die Cloud-Strategie, um für Unternehmensdatensätze zentral zu bleiben. Die schwierige Frage ist, ob jeder Kunde dies in akzeptierte Workflows umwandeln kann.

Das Urteil

SAP SE sollte nach dem akzeptierten Unternehmensdatensatz beurteilt werden, nicht nach der Eleganz des Suite-Plans. An diesem Standard gemessen ist SAP glaubwürdig, aber niemals selbsterweisend. Das Unternehmen verfügt über die Größe, Produkttiefe, den Support-Lifecycle, die Implementierungsmethodik, die Überwachungsoberfläche, die Integrationsplattform, das Sicherheitsvokabular, die Data-Governance-Story und die KI-Ambitionen, die erforderlich sind, um im Zentrum großer Unternehmensworkflows zu stehen. Sein Cloud-Übergang ist kommerziell real, und seine Relevanz könnte zunehmen, da KI vertrauenswürdigen Geschäftskontext wertvoller macht.

Die Schwäche besteht darin, dass die schwierigste Arbeit von SAP mit dem Kunden geteilt wird. Migrationsqualität, Prozesspassung, Clean-Core-Disziplin, Stammdaten-Governance, Integrationssemantik, Rollendesign, Prüfungsdurchsicht, Ausnahmeverantwortung, Release-Tests, Partnerleistung und Benutzerakzeptanz werden nicht durch den Kauf der Suite gelöst. Es ist die Arbeit, die Software in institutionelle Wahrheit verwandelt. Wenn diese Arbeit gut gemacht wird, kann SAP fragmentierte Systeme und manuelle Abstimmung durch einen zuverlässigeren Betriebsdatensatz ersetzen.

Wenn sie schlecht gemacht wird, kann SAP zu einer neuen Heimat für alte Komplexität werden.

Business AI ändert diese Schlussfolgerung nicht. Es macht den Datensatz wichtiger. Ein KI-Assistent oder automatisierter Workflow kann nur dann nützlich sein, wenn er innerhalb eines gesteuerten Prozesses mit korrektem Kontext, Berechtigungen, Nachweisen und Wiederherstellungspfaden handelt. Die Zukunft, die SAP verkaufen will, ist nicht einfach Cloud-ERP mit intelligenteren Schnittstellen. Es ist ein unternehmensweites Betriebsmodell, in dem Daten, Prozesse, Richtlinien und KI um vertrauenswürdige Datensätze herum koordiniert werden.

Das ist ein ernstzunehmender Vorschlag. Es ist auch eine hohe Hürde. Die richtige Kaufentscheidungsfrage lautet nicht, ob SAP ein breites Produktportfolio vorweisen kann. Es geht darum, ob ein wiederholter Finanz-, Beschaffungs-, HR-, Lieferketten- oder Betriebs-Workflow akzeptiert werden kann, nachdem Migration, Integration, Berechtigung, Prüfung, Ausnahmebehandlung, Cloud-Betrieb, Support-Lebenszyklus und KI-Unterstützung alle berücksichtigt wurden. Der Fall von SAP ist am stärksten, wenn die Antwort Ja lautet und die Kosten, um dieses Ja zu erreichen, niedriger sind als die Kosten, die Unternehmenswahrheit verstreut zu halten.