SAP wird am akzeptierten Datensatz gemessen, nicht an der Suite

Zusammenfassung

• SAPs stärkstes Argument ist nicht die Breite der Suite. Es ist die Fähigkeit, den Zustand eines Geschäftsprozesses in den Bereichen Finanzen, Beschaffung, Personal, Lieferkette, Betrieb, Berechtigungen, Integration, Prüfnachweise, Support-Lebenszyklus und Cloud-Betrieb als akzeptiert zu erhalten.
• Die Kosten für Migration und Betrieb stehen im Mittelpunkt der kommerziellen Prüfung. SAP kann die Fragmentierung von Infrastruktur und Prozessen reduzieren, aber der Wert hängt ab von der Fit-to-Standard-Disziplin, Datenqualität, Clean-Core-Governance, Partnerausführung, Integrationsverantwortung, Ausnahmebehandlung, Schulung und nachhaltigem Support.
• Business AI und Joule machen SAP strategisch relevanter, aber sie erhöhen auch den Akzeptanzstandard. KI kann nur dann Vorschläge machen, zusammenfassen, weiterleiten und Arbeit koordinieren, wenn der zugrunde liegende Datensatz, Berechtigungen, Richtlinien, Prüfpfad und 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. Ein Bestellvorgang wird verbindlich. Ein Wareneingang aktualisiert den Bestand. Ein Geschäftspartner wird gültig. Eine Personalveränderung wird maßgeblich für Gehaltsabrechnung und Zugriff. Ein Abschlussposten wird Teil des Finanzbuchs. Ein Produktionsplan wird zur Grundlage für Einkauf, Arbeit und Lieferzusagen. Dies sind keine Demonstrationen. Es sind wiederholte Akte institutionellen Vertrauens.

So sollte SAP SE beurteilt werden. Das Unternehmen hat eine enorme Produktpalette: SAP S/4HANA Cloud, RISE with SAP, Business Technology Platform, Integration Suite, SuccessFactors, Ariba, Concur, Analysen, Business Data Cloud, Joule, Cloud ALM und ein tiefes Dienstleistungs- und Partner-Ökosystem. Die Breite ist wichtig, weil Unternehmensprozesse selten in einem einzigen Bildschirm ablaufen. Aber Breite ist nicht Akzeptanz.

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

SAPs eigene Unternehmensbeschreibung weist auf das richtige Terrain hin. SAP beschreibt sich selbst als globales Unternehmen für Unternehmensanwendungen und KI, dem in den Bereichen Finanzen, Beschaffung, Personal, Lieferkette und Kundenerfahrung vertraut wird. Das Unternehmensprofil listet mehr als 110.000 Mitarbeiter aus mehr als 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 der Cloud-Wechsel kein Experiment mehr ist: Im ersten Quartal 2026 meldete SAP einen aktuellen Cloud-Auftragsbestand von 21,932 Milliarden Euro und Cloud-Umsätze von 5,962 Milliarden Euro.

Diese Zahlen belegen Größe und Richtung. Sie beweisen nicht, dass der Monatsabschluss, die Lieferantenanbindung, die Lagerausnahme oder die Personalveränderung eines Kunden mit weniger Gesamtaufwand als zuvor akzeptiert werden. Der Wert von SAP muss dort getestet werden, wo die Software zur operativen Wahrheit wird. Ein Käufer sollte fragen: Hat der Workflow den manuellen Abstimmungsaufwand reduziert oder nur in ein anderes Team verlagert? Hat das Berechtigungsdesign das Risiko gesenkt oder die Arbeit verlangsamt, so dass die Benutzer Workarounds erfunden haben?

Hat die Cloud-Migration den Infrastrukturaufwand beseitigt oder eine neue Abhängigkeit von Partnern und Produkt-Roadmaps geschaffen? Hat KI Routinearbeit entfernt oder zusätzliche Überprüfungsarbeit geschaffen, weil die Mitarbeiter nicht mehr wissen, warum ein Datensatz geändert wurde?

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 Unternehmen tatsächlich angewiesen sind. SAP ist teuer, weil diese Nähe bedeutet, dass das Unternehmen in Prozesse involviert ist, die nicht einfach zurückgesetzt werden können.

SAPs kommerzielle Dynamik ist ein Cloud-Übergang, kein Workflow-Ergebnis

SAPs öffentliche Finanzdaten zeigen ein Unternehmen, das seinen Schwerpunkt hin zu Cloud-ERP und verwandten Dienstleistungen verlagert. Der integrierte Bericht 2025 von SAP zeigt, dass die Cloud-Umsätze von 17,141 Milliarden Euro im Jahr 2024 auf 21,023 Milliarden Euro im Jahr 2025 gestiegen sind. Die Cloud-ERP-Suite-Umsätze stiegen von 14,165 Milliarden Euro auf 18,119 Milliarden Euro und trugen 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 Umsätze mit Softwarelizenzen und Support gingen zurück, was SAP auf den beschleunigten Wechsel der Kunden in die Cloud zurückführt.

Das erste Quartal 2026 setzte das Muster fort. Auf der Investorenseite von SAP wurde ein Cloud-Umsatzwachstum von 19 % auf berichteter Basis und 27 % zu konstanten Währungen gemeldet, wobei die Cloud-ERP-Suite-Umsätze um 23 % berichtet und 30 % zu konstanten Währungen stiegen. Der Ausblick von SAP für 2026 erwartet Cloud-Umsätze von 25,8 bis 26,2 Milliarden Euro zu konstanten Währungen und Cloud- und Software-Umsätze von 36,3 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 individualisierte SAP-Landschaften, On-Premises-Infrastruktur und jahrelange lokale Praktiken rund um Upgrades, Transporte, Schnittstellen und Berichte. Im Cloud-Modell möchte SAP, dass mehr Kunden standardisieren, modernisieren, S/4HANA nutzen, kontinuierliche Innovation konsumieren und KI- und Datendienste anbinden. Das kann eine rationale Verschiebung sein. Es kann den Infrastrukturaufwand reduzieren, einige Upgrades vereinfachen und neue Funktionen weniger abhängig von individuellen Kundenprojekten machen.

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

Ein Cloud-ERP-System kann standardisierter sein und dennoch teuer in der Wahrheit.

Deshalb sollte die finanzielle Dynamik als Nachfragebeweis behandelt werden, nicht als Workflow-Beweis. 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 auf S/4HANA Cloud Private Edition umstellt, hat ein anderes Risikoprofil als ein mittelständisches Unternehmen, das einen Public-Cloud-ERP-Umfang einführt. Eine öffentliche Einrichtung hat andere Prüfungs- und Datenlokalitätsbeschränkungen 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, langlebiger Anbieter ist. Es ist, ob jeder akzeptierte Workflow nach der vollständigen Übergangskostenzählung billiger, sauberer und prüfbarer wird. Die öffentlichen Beweise unterstützen SAPs Größe. Sie heben jedoch nicht die Notwendigkeit von Akzeptanzbelegen auf Kundenebene auf.

Migration ist der erste Zuverlässigkeitstest

Das meiste SAP-Risiko zeigt sich vor dem ersten normalen Geschäftstag nach dem Go-Live. Es erscheint in der Migration: Stammdaten, die in Legacy-Systemen toleriert wurden, aber in S/4HANA blockierend wirken, Felder, die in verschiedenen Abteilungen unterschiedliche Bedeutungen haben, offene Posten, die nicht abgestimmt sind, benutzerdefinierte Berichte, die undokumentierte Logik verbergen, Lieferantensätze mit Duplikaten, in alten Rollen verankerte Berechtigungsannahmen und Schnittstellen, die seit einem Jahrzehnt „vorübergehend" sind. Migration ist keine Dateneingabeaufgabe.

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

SAPs Lernmaterial für SAP S/4HANA Cloud Public Edition macht dies konkret. Es beschreibt ein Migrations-Cockpit, Migrationsprojekte, Migrationsobjekte, Staging-Tabellen, Problembehandlung, zugehörige Apps, Best Practices und unterstützende Anforderungen. Eine Lektion über lokale Vorlagen besagt, dass der Benutzer ein Migrationsprojekt erstellt, ein oder mehrere Migrationsobjekte zuweist und das Migrations-Cockpit für jedes Objekt eine Staging-Tabelle in SAP S/4HANA Cloud generiert. Sobald die Tabelle gefüllt und das Projekt abgeschlossen ist, werden die Daten in die SAP S/4HANA Cloud-Datenbank verschoben.

Es sagt auch, dass sichtbare Migrationsobjekte auf aktiven Geschäftsprozessen basieren und dass zusätzliche Prozesse, die später aktiviert werden, möglicherweise weitere Migrationsobjekte sichtbar machen.

Diese Mechanik ist nützlich, weil sie die Migration zwingt, der Form des Geschäftsumfangs zu folgen. Sie zeigt 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, wer die Daten besitzt, welche Vorgängerobjekte zuerst existieren müssen, welche Berechtigungen erforderlich sind, wie Fehler behoben werden und wie die geladenen Datensätze mit nachgelagerten Systemen abgestimmt werden. Eine Staging-Tabelle kann die Arbeit organisieren.

Sie kann nicht entscheiden, ob ein Lieferant, ein Material, ein Kostenplatz, ein Mitarbeiter oder ein offener Bestellvorgang maßgeblich ist.

Der akzeptierte Unternehmensworkflow hängt von dieser Autorität ab. Ein Finanzworkflow kann fehlschlagen, weil die Lieferantenstammdaten falsch sind. Ein Beschaffungsworkflow kann fehlschlagen, weil Produkt-, Steuer- und Zahlungsbedingungen nicht übereinstimmen. Ein Supply-Chain-Workflow kann fehlschlagen, weil Materialien, Werke, Vorlaufzeiten und Bestandsbestände ohne Einigung über die Eigentümerschaft geladen wurden. Ein Personal-Workflow kann fehlschlagen, weil organisatorische Zuordnungen und Zugriffsrechte migriert wurden, als wären sie nur Datensätze, obwohl sie auch definieren, wer handeln darf.

SAP-Käufer sprechen oft davon, „zu S/4HANA zu migrieren", als ob das Ziel das System wäre. Der bessere Ausdruck ist „Umzug in einen akzeptierten Geschäftszustand". Das System kann Daten empfangen. Das Geschäft muss sie akzeptieren. Diese Akzeptanz erfordert Datenverantwortliche, Migrationsproben, Fehlertriage, Cutover-Disziplin, Vergleichsberichte, geschäftliche Freigabe und eine Möglichkeit, neue Daten sauber zu halten, nachdem das Migrationsteam gegangen ist. Wenn diese Aufgaben schwach sind, kann SAPs Werkzeugkasten weiterhin wie vorgesehen funktionieren, während der Workflow als Geschäftsdatensatz fehlschlägt.

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

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

Fit-to-Standard ist mächtig, wenn es echt ist. Wenn ein Kunde standardmäßige Finanz-, Beschaffungs-, Vertriebs-, Supply-Chain- oder HR-Prozesse übernehmen kann, reduziert das benutzerdefinierten Code, macht Upgrades einfacher, senkt die Partnerabhängigkeit und ermöglicht es dem Kunden, von SAPs laufenden Releases zu profitieren. Aber Fit-to-Standard ist oft der Ort, an dem Politik in die Implementierung einfließt. Eine lokale Geschäftseinheit kann darauf bestehen, dass ihr alter Prozess wesentlich ist. Ein Finanzteam akzeptiert einen Standardprozess möglicherweise nur, wenn ein Bericht neu erstellt wird.

Ein Werk kann einen manuellen Workaround beibehalten, weil der Standardablauf die Verantwortlichkeit ändert. Ein Beschaffungsteam möchte möglicherweise Ausnahmen, die den Standard untergraben. Ein Berater kann 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 ist, ob der letztendliche Workflow mit weniger manuellen Ausnahmen, klarerer Eigentümerschaft, geringerem Prüfungsrisiko und einer niedrigeren Support-Belastung wiederholt werden kann. Wenn der Standardprozess akzeptiert wird, hat SAP ein starkes Argument. Wenn der Standardprozess durch Tabellenkalkulationen, Schattenfreigaben, manuelle Neueingaben oder inoffizielle Berichte umgangen wird, hat die Implementierung nur die Reibung verschoben.

Clean Core verschärft dieselbe Frage. SAPs Clean-Core-Erweiterbarkeitsmaterial besagt, dass die Strategie darauf abzielt, S/4HANA Cloud-Kunden die Erweiterung zu ermöglichen, wo nötig, während dennoch reibungslose Upgrades und die Handhabung von Erweiterungen ermöglicht werden. Der Clean-Core-Kurs von SAP Learning behandelt das S/4HANA Cloud-Erweiterbarkeitsmodell, ABAP Cloud und besondere Überlegungen für Private Edition und S/4HANA. Die Botschaft ist kommerziell wichtig: Anpassungen sind nicht verboten, aber sie müssen so gesteuert werden, dass sie den Kunden nicht in einer fragilen, nicht upgradebaren Umgebung festhalten.

Das ist leichter gesagt als getan. Ein klassischer SAP-Kunde kann Jahre von ABAP-Benutzercode, modifizierten Workflows, maßgeschneiderten Berichten, Integrationen und lokalen Richtlinien haben. Ein Teil davon kodiert legitime Wettbewerbsunterschiede. Ein Teil davon kodiert veraltete Workarounds. Ein Teil davon existiert, weil eine frühere Implementierung eine Betriebsfrage nicht geklärt hat. Clean Core fordert den Kunden auf, notwendige Erweiterungen von Anpassungsschulden zu trennen. SAP kann Modelle, Werkzeuge und Anleitungen bereitstellen.

Der Kunde und der Partner müssen dennoch entscheiden, welche alten Verhaltensweisen bestehen bleiben sollen.

Hier treffen SAPs kommerzieller Wert und kommerzielles Risiko 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: Nach Fit-to-Standard- und Clean-Core-Entscheidungen, kann die Organisation dem Datensatz vertrauen, ohne das alte System darum herum neu aufzubauen?

Integration entscheidet, ob der Datensatz reist

Ein akzeptierter SAP-Datensatz bleibt selten innerhalb von SAP. Ein Bestellvorgang kann die Lieferantenzusammenarbeit, Logistikaktualisierungen, Bestandsänderungen, Genehmigungen, Cash-Prognosen, Steuerbehandlung und Analysen auslösen. Eine Personalveränderung kann zu Identitätssystemen, Gehaltsabrechnung, Spesenwerkzeugen, Lernsystemen und Gebäudezugang fließen. Ein Verkaufsauftrag 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 der Abstimmung.

SAPs öffentliches Produktmaterial erkennt dies an. Die Seite für S/4HANA Cloud Public Edition besagt, dass es mit anderen Unternehmensanwendungen über SAP Business Technology Platform und SAP Integration Suite integriert. SAP Help Search-Auszüge beschreiben Integration Suite als eine unternehmensweite Integrationsplattform als Dienstleistung zur Verbindung und Integration von Geschäftsanwendungen und -daten.

SAP Learning-Implementierungsinhalte enthalten Integrationskonzepte, Analyse der Integrationslandschaft, SAP Integration Suite, SAP Best Practices-Integrationsinhalte, Cloud Integration Automation Service, Best Practices-Integrationssetup, kundengesteuerte Integrationen und Überwachung von Integrationen mit SAP Cloud ALM.

Das ist die richtige Funktionsgruppe für das Problem. Aber der Akzeptanztest ist nicht „existiert eine Integration?" Es ist „bleibt der integrierte Workflow unter Ausnahmen wahr?" Eine erfolgreiche Bestellvorgangsschnittstelle ist nicht genug, wenn eine Lieferantenänderung, Steuerregel, Teilwareneingang, Genehmigungsablehnung, Wiederholung, Zeitüberschreitung oder doppelte Nachricht die Abstimmung unterbricht. Eine Humankapitalintegration ist nicht genug, wenn Kündigungen, Rollenwechsel, Auftragnehmerumwandlungen oder Identitätskonflikte Zugriff hinterlassen.

Eine Finanzintegration ist nicht genug, wenn Nebenbücher und Hauptbuchzustände divergieren und Teams es in Tabellenkalkulationen lösen.

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

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

In der System-of-Record-Arbeit können Integrationsfehler gefährlicher sein als sichtbare Ausfälle. Ein sichtbarer Ausfall stoppt die Arbeit und erhält Aufmerksamkeit. Ein leiser Integrationskonflikt lässt die Menschen mit inkonsistenten Datensätzen fortfahren. Die Kosten erscheinen später als schlechter Bestand, verpasste Zahlung, doppelter Lieferant, falsche Berechtigung, unvollständiger Prüfpfad oder Managementberichte, die nicht abgestimmt werden können. SAPs Integrationsfläche ist notwendig. Sie ist nicht ausreichend, es sei denn, das Unternehmen baut eine Ausnahmeverantwortung darum herum.

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

Berechtigung und Prüffähigkeit sind Produktionsfunktionen

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

SAPs Wert in regulierten und komplexen Organisationen hängt von der Fähigkeit ab, Berechtigungs- und Prüfnachweise operativ und nicht nur dekorativ zu machen.

SAP Learnings User Access and Security Journey behandelt Berechtigungskonzepte und Werkzeuge für SAP Business Suite, SAP HANA, S/4HANA und S/4HANA Cloud Public Edition. Es umfasst SAP Identity Access Management, SAP HANA User Administration, S/4HANA User Maintenance, Business-Rollen- und Berechtigungskonzepte, SAP Fiori-Berechtigungen und Business-Rollen, Cloud Identity Services sowie Fehlerbehebung und Analyse von Berechtigungen und Benutzerzugriff durch Berichte und Analysen.

SAP Learning-Implementierungsinhalte listen auch das Erstellen und Anpassen von Business-Rollen, das Definieren von Einschränkungen und das Ausrichten des Fiori-Launchpads an Rollen auf.

Das sagt Käufern, wie die Kontrolloberfläche aussieht. Es beweist nicht, dass das Rollenmodell gut ist. Unternehmensweite Berechtigungen sind schwierig, weil Rollen nahe an der organisatorischen Wahrheit sind. Ein Einkaufssachbearbeiter, Käufer, Werksleiter, Shared-Services-Benutzer, Finanzgenehmiger, Projektbuchhalter, HR-Administrator und externer Prüfer können jeweils Zugriff benötigen, der alte Abteilungsgrenzen überschreitet. Zu wenig Zugriff schafft Workarounds. Zu viel Zugriff schafft Kontrollrisiko. Temporärer Zugriff wird dauerhaft, wenn niemand die Überprüfung besitzt.

Notfallzugriff wird normal, wenn Prozesse schlecht gestaltet sind.

SAP Help Search-Auszüge identifizieren auch S/4HANA Cloud Public Edition-Sicherheitsprüfprotokolle, die sicherheitsrelevante Ereignisse enthalten, und stellen fest, dass Protokolle abgerufen und in eine Sicherheitsinformations- und Ereignisverwaltungslösung integriert werden können. Das ist wichtig, aber die Prüffähigkeit 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, könnte Analysten überfluten.

Eine Rollenänderung, die technisch protokolliert wird, kann für einen Prüfer dennoch unerklärt sein.

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 es einfacher macht, offene Bestellungen zu finden, ist wertvoll. Ein System, das über Anwendungen hinweg 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 der Befugnisnachweis formal bleibt.

SAPs Sicherheits-, Identitäts- und Prüfoberflächen sind glaubwürdig, weil das Unternehmen jahrzehntelang großen regulierten Unternehmen dienen musste. Die Schwäche ist nicht das Fehlen von Kontrollen. Die Schwäche ist, dass Kontrollen Design erfordern. Ein Käufer sollte Berechtigungsdesign, Zugriffsüberprüfung, Rollentests, Prüfprotokollabruf und Sicherheitsüberwachung als Produktionsarbeit behandeln, nicht als späte Implementierungsaufgaben.

Cloud-Betrieb verschiebt die Kontrollgrenze

RISE with SAP und S/4HANA Cloud verlagern SAPs Schwerpunkt hin zum Cloud-Betrieb. SAPs RISE-Seite positioniert das Angebot als eine Möglichkeit, On-Premises-ERP in die Cloud zu transformieren, ERP zu modernisieren und KI-Wert durch eine Methodik, Expertenberatung, Migrations- und Modernisierungsassistenten und kontinuierliche Innovation zu erschließen. Ein aktuelles öffentliches Marktsignal verstärkt das Muster: SAP gab am 30. Juni 2026 bekannt, dass Nokia eine mehrjährige Vereinbarung mit SAP unterzeichnet hat, um die RISE with SAP-Methodik zu nutzen, mit SAP S/4HANA, gehostet auf Microsoft Azure.

SAP sagte, die Vereinbarung umfasse die Migration der SAP-Landschaft von Nokia über Prozesse, Daten, Anwendungen und Betriebsmodelle hinweg, und SAP werde die S/4HANA-Softwareumgebung in der Cloud betreiben und verwalten.

Diese Art von Vereinbarung zeigt, warum SAP strategisch relevant bleibt. Große Unternehmen kaufen nicht nur eine neue Anwendung. Sie verlagern kritische operative Datensätze in ein verwaltetes Cloud-Modell, das SAP, einen Hyperscaler und oft große Implementierungspartner umfasst. Der Vorteil ist der Fokus: Der Kunde kann weniger Aufwand für Infrastruktur und mehr für Geschäftsprozesse, Daten und Innovation aufwenden. Das Risiko ist die Abhängigkeit: Der Kunde ist jetzt den Service-Grenzen des Anbieters, der Partnerausführung, den Cloud-Region-Entscheidungen, Release-Zeitplänen, Support-Prozessen und Vertragsbedingungen ausgesetzt.

SAP Trust Centers Seite zum Cloud-Service-Status ist gerade deshalb nützlich, weil sie öffentliche Sichtbarkeitsgrenzen definiert. SAP sagt, die Seite gebe aktuelle Verfügbarkeit und Leistungshistorie für SAP-Cloud-Dienste, während das SAP for Me-Kundenportal kundenspezifische Tenant-Details bereitstellt.

SAP sagt, dass es über Cloud-Dienste hinweg eine Verfügbarkeit von 99,7 % anstrebt, sofern nicht anders angegeben, dass geplante Wartungs- und größere Upgrade-Ausfallzeiten nicht auf der öffentlichen Statusseite angezeigt werden, und dass Störungen oder Verschlechterungen nur sichtbar sind, wenn sie mindestens fünf Minuten dauern und mindestens 5 % der Produktivsysteme in einem Rechenzentrum betreffen. Der öffentliche Status ist daher nicht die Tenant-Wahrheit.

Für akzeptierte Workflows sind diese Grenzen wichtig. Ein Finanzabschluss kann durch einen kurzen Tenant-spezifischen Vorfall, geplante Wartung, Integrationsausfall, Identitätsproblem oder Partnersystemfehler gestört werden, der nicht als breite öffentliche Störung erscheint. Eine Beschaffungsgenehmigung kann verzögert werden, weil ein externer Dienst oder Identitätspfad fehlschlägt. Ein Supply-Chain-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 operative Hauptbuch für den Geschäftsprozess eines Kunden.

SAPs Rechenzentrums- und Datenschutzseiten fügen eine weitere Ebene hinzu. SAP sagt, einige Cloud-Dienste ermöglichen es Kunden, während der Implementierung ein Rechenzentrum auszuwählen, und dass sekundäre Rechenzentren in derselben Region Backup und Disaster Recovery unterstützen. Es sagt auch, dass das Portfolio schrittweise in die Rechenzentrumskarte integriert wird und dass einige Dienste in anderen als den angezeigten Rechenzentren bereitgestellt werden können.

SAP listet Datenresidenz, Compliance, Disaster Recovery, Verschlüsselung, Zugriffskontrollen, Prüfungen, redundante Systeme, geografische Verteilung, automatisches Failover und Tests als Rechenzentrumsfunktionen auf. Die Datenschutzseite beschreibt Datenverarbeitungsvereinbarungen, technische und organisatorische Maßnahmen, Unterauftragsverarbeiter, Standardvertragsklauseln, Zertifizierungen, Prüfberichte und Privacy by Design.

Das sind notwendige Zusicherungen für einen globalen ERP-Anbieter. Sie ersetzen keine kundenspezifische Due Diligence. Die Datenresidenz hängt vom Dienst, Land, Region, Unterauftragsverarbeiter, Vertrag, Integration, Supportpfad und Implementierungswahl ab. Disaster Recovery ist nicht sinnvoll, bis ein 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. Sie können das Versagen auch schwerer nachvollziehbar machen, es sei denn, die Verantwortung ist explizit.

Support-Lebenszyklus-Druck ist Teil des Kaufarguments

SAP-Kunden bewerten S/4HANA nicht im luftleeren Raum. Viele bewerten es unter dem Druck des Support-Lebenszyklus. SAPs Support-Seite besagt, dass es mindestens eine SAP S/4HANA-Version geben wird, die bis Ende 2040 im Wartungsbetrieb ist. Dieselbe Seite besagt, dass SAP Business Suite 7-Kernanwendungen bis Ende 2027 im regulären Wartungsbetrieb sind, gefolgt von optionaler erweiterter Wartung von Anfang 2028 bis Ende 2030 mit einem Aufschlag von zwei Prozentpunkten auf die Wartungsbasis. Kunden, die sich nicht für die erweiterte Wartung entscheiden, oder nach Ende der erweiterten Wartung, wechseln zur kundenspezifischen Wartung.

Diese Zeitachse ist kommerziell zentral. Sie schafft ein Migrationsfenster für langjährige SAP-Kunden, die immer noch von Business Suite, ECC oder verwandten Landschaften abhängig sind. Für einige ist die Entscheidung nicht „sollten wir jetzt modernisieren?", sondern „wie vermeiden wir es, in teurem Support gefangen zu sein, während die Geschäftskontinuität gewahrt bleibt?" Die Antwort kann S/4HANA Cloud Public Edition, S/4HANA Cloud Private Edition, RISE with SAP, selektive Transformation, eine gestaffelte 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 das Inventar von benutzerdefiniertem Code, Datenqualität, Prozessvarianten, nicht unterstützten Integrationen und veralteten Berichten erzwingen. Er kann die Aufmerksamkeit der Führungsebene erzeugen, die normalen Modernisierungsprogrammen fehlt. Aber Druck kann auch zu schlechter Akzeptanz führen. Ein Projekt, das hauptsächlich von einer Frist getrieben wird, kann migrierte Komplexität ohne Neugestaltung akzeptieren. Es kann Tests komprimieren. Es kann einer Partnerkonfiguration erlauben, der De-facto-Prozess zu werden.

Es kann die Datenbereinigung auf nach dem Go-Live verschieben, wo sie zu dauerhafter Support-Arbeit wird.

Deshalb sollte der Support-Lebenszyklus Teil des Kostenmodells sein, keine Einschüchterungstaktik. Erweiterte Wartung hat einen Preis. Das gilt auch für die Migration. Das gilt auch für die Verschiebung der Migration. Das gilt auch für ein gescheitertes Go-Live. Das gilt auch für ein Clean-Core-Redesign, das alten benutzerdefinierten Code entfernt, aber die Mitarbeiter zwingt, neu zu lernen, wie Arbeit erledigt wird. SAPs Cloud-Strategie kann für viele Kunden richtungsmäßig richtig sein, aber ein Kunde sollte dennoch die Kosten jedes akzeptierten Workflows berechnen, nicht nur die Kosten des Verbleibs auf altem Support.

Die S/4HANA-Wartungsverpflichtung bis 2040 ist auch kein Versprechen, dass jede Implementierungswahl zukunftssicher ist. Ein stark angepasstes Private-Cloud-System kann immer noch Upgrade-Reibung aufweisen. 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 upgradebar halten.

Cloud ALM zeigt die Form der Betriebsarbeit

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

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

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

Das Operations Expert Portal 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 Ausnahmeverwaltung auf.

Diese Liste ist eine ernsthafte Betriebskarte. Sie erkennt an, dass akzeptierte Workflows auf viele Arten fehlschlagen. Ein Geschäftsprozess kann langsam sein, nicht ausgefallen. Eine Integration kann wiederholen, nicht unterbrochen sein. Ein Job kann spät abgeschlossen werden. Eine Benutzererfahrung kann sich verschlechtern, bevor jemand ein Ticket meldet. Eine Ausnahme kann unzugewiesen bleiben. Eine Bereitstellung kann technisch erfolgreich sein, während sie nachgelagerte Fehler verursacht. Das richtige Überwachungsmodell muss über Geschäftsprozess-, Anwendungs-, Integrations-, Job-, Benutzer- und Erweiterungsebenen hinwegsehen.

Die Vorsicht ist, dass die Überwachung nur so wertvoll ist wie das Betriebsmodell darum herum. Cloud ALM kann Dashboards, Aufgaben, Rückverfolgbarkeit und Warnungen bereitstellen. Es kann nicht entscheiden, welche Ausnahme eine Sendung blockieren sollte, welche fehlgeschlagene Schnittstelle die Freigabe der Finanzabteilung erfordert, welche Jobverzögerung tolerierbar ist oder welches Support-Team eine benutzerdefinierte BTP-Erweiterung besitzt. Es kann auch keine Kultur der kontinuierlichen Verbesserung nach dem Go-Live von selbst schaffen. Die Ausführungsphase in SAP Activate ist keine Formalität.

Sie ist der Ort, an dem Akzeptanz kontinuierlich wird.

Für Käufer ist die praktische Frage, ob Cloud ALM zu dem Ort wird, an dem Arbeit verwaltet wird, oder nur ein weiteres Dashboard. Ein starker SAP-Kunde wird Cloud ALM mit der Verantwortung verbinden: benannte Prozessverantwortliche, Support-Warteschlangen, Release-Kalender, Datenqualitätssanierung, Testautomatisierung, Regressionsnachweise, Integrationsausnahmeüberprüfung und geschäftliche Freigabe. Ein schwacher Kunde wird die Überwachung einschalten und das reale System weiterhin per E-Mail, Tabellenkalkulation und Eskalation auf dem Flur verwalten.

SAPs Betriebswerkzeuge sind glaubwürdig, weil sie auf reale Fehlermodi abzielen. Der kommerzielle Wert hängt davon ab, ob der Kunde die Menschen und die Prozessdisziplin finanziert, die erforderlich sind, um auf das zu reagieren, was die Werkzeuge offenbaren.

Business AI ist sowohl ein Akzeptanzrisiko als auch eine Chance

SAPs KI-Geschichte ist strategisch wichtig, weil SAP nahe am Geschäftskontext sitzt, der generischen KI-Systemen oft fehlt. SAPs Joule-Seite sagt, Joule bringe KI-Assistenten und automatisierte Workflow-Funktionen in einem einheitlichen Arbeitsbereich zusammen, nutze Geschäftsdaten und SAP-Geschäftsprozessexpertise, vereinheitliche SAP- und Nicht-SAP-Systeme und basiere auf Sicherheits-, Governance- und Daten-Frameworks. SAPs zugehöriges Joule-Produktmaterial 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 Datenebene in SAP Business Data Cloud.

SAP Business Data Cloud ist das begleitende Argument. SAP sagt, es vereinheitliche und steuere SAP- und Drittanbieterdaten mit einer Business-Daten-Fabric, unterstütze eine vertrauenswürdige Datenbasis für KI-gesteuerte Automatisierung, harmonisiere geschäftskritische Daten mit Geschäftsprozessen, Richtlinien und Logik und umfasse Funktionen wie Analytics Cloud, Datasphere, Business Warehouse-Modernisierung, SAP Databricks, HANA Cloud und Master Data Governance. In einfachen Worten argumentiert SAP, dass KI auf Geschäftsdaten basieren sollte, die ihre Semantik, Richtlinien und Prozesskontext kennen.

Das ist eine bessere KI-These als „einen Chatbot zu ERP hinzufügen". Unternehmensworkflows sind voller Bedeutung, die aus Rohtext nicht ersichtlich ist: Genehmigungsgrenzen, Zahlungsbedingungen, Werkscodes, Buchungsperioden, Materialarten, Steuerjurisdiktionen, Lieferantenrisiko, Arbeitsregeln, Vertragsdaten und Beschränkungen der Funktionstrennung. 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 ändert auch den Akzeptanzstandard. Ein menschlicher Benutzer, der durch eine Fiori-App klickt, hinterlässt eine Art Spur. Ein Assistent, der automatisierte Schritte über Systeme hinweg koordiniert, hinterlässt eine andere. Wer hat die Aktion genehmigt? Welche Daten hat die KI verwendet? War die Empfehlung richtlinienkonform? Hatte die KI-Ebene die Berechtigung, den Zustand zu ändern, oder nur, um Vorschläge zu machen? Welcher Ausnahmepfad existiert, wenn die KI falsch liegt? Wie wird eine schlechte automatisierte Aktion rückgängig gemacht? Welche Protokolle sind für die Prüfung ausreichend? Was passiert, wenn sich ein Modell ändert?

Die öffentlichen Beweise beantworten diese Fragen nicht auf Tenant-Ebene. Sie unterstützen SAPs Positionierung: KI wird in Unternehmensworkflows eingebettet, und SAP möchte sie in governierten 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 immer noch menschliche Akzeptanz erfordern: Auffinden von Datensätzen, Zusammenfassen von Ausnahmen, Entwerfen von Erklärungen, Vorschlagen von nächsten Schritten, Identifizieren von Anomalien, Generieren von Testunterstützung oder Hilfe bei Implementierungsanleitungen. Vollständig autonome, zustandsändernde Workflows erfordern viel stärkere Beweise. SAP könnte auf diese Zukunft hinarbeiten, aber der Datensatz muss wichtiger bleiben als die Automatisierungsebene.

Partner und Kunden besitzen immer noch einen großen Teil des Ergebnisses

SAPs Produktfläche 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, in einigen Modellen von Hyperscale-Infrastruktur, Implementierungspartnern, kundeneigenen Prozessverantwortlichen, Datenverantwortlichen, Sicherheitsteams, Prüfern, Integrationsteams und Endbenutzern ab. Fehler können in jeder dieser Ebenen entstehen.

Diese Grenze ist wichtig, weil Kunden oft im Nachhinein die Schuld zuweisen. Wenn bei einer Migration Daten fehlen, war das Werkzeug unzureichend, das Mapping falsch, die Quelldaten schlecht, der Partner gehetzt oder der Geschäftsinhaber abwesend? Wenn ein Workflow langsam ist, liegt das Problem in der Konfiguration, im benutzerdefinierten Code, in der Integration, in der Benutzerschulung, im Netzwerkpfad, im Release-Timing oder im Prozessdesign?

Wenn eine KI-Empfehlung falsch ist, liegt das Problem im Modellverhalten, im fehlenden Kontext, in schlechten Stammdaten, in schwachem Instruktionsdesign, in der Berechtigung oder im übermäßigen Benutzervertrauen? Die Antwort kann geteilt sein.

Das kommerzielle Risiko ist die Partnerabhängigkeit. SAP-Implementierungsarbeit ist spezialisiert, und große Programme erfordern oft Systemintegratoren, Beratungsfirmen, Datenspezialisten, Change Manager, Sicherheitsexperten und laufende Managed Services. Gute Partner können SAP-Wert realisieren. Schwache Partner können SAP in einen teuren Satz von Kompromissen verwandeln. Der Kunde benötigt dennoch interne Verantwortung, weil kein Partner dauerhaft die geschäftliche Bedeutung eines Datensatzes besitzen kann.

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 akzeptiert, wenn Lieferantenstammdaten, Bestellanlage, Genehmigungen, Wareneingang, Rechnungsabgleich, Ausnahmen, Zahlung, Prüfnachweise und Berichterstattung sowohl in normalen als auch in Grenzfällen funktionieren.

Ein Record-to-Report-Workflow wird nur akzeptiert, wenn Buchungen, Nebebuchabstimmung, Kontrollen, Abschlussaufgaben, Konsolidierung, Berichterstattung und Prüfungsunterstützung ohne versteckte Tabellenkalkulationen funktionieren. Ein HR-Workflow wird nur akzeptiert, wenn Mitarbeiterdaten, Rollenwechsel, Gehaltsabrechnungsabhängigkeiten, Identitätsbereitstellung, Genehmigungen und Datenschutzkontrollen übereinstimmen.

Diese Kriterien sollten vor dem Go-Live geschrieben und nach dem Go-Live beibehalten werden. Sie verwandeln SAP von einer Systemimplementierung in eine operative Verpflichtung. Sie machen auch die Partnerleistung messbar. Ein Partner, der Bildschirme konfiguriert, aber keine akzeptierten Workflow-Nachweise erklären kann, ist nicht fertig.

Das Kostenmodell muss Aufsicht 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. Die Aufsichtskosten 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-Outputs müssen überprüft werden. Workarounds müssen aufgespürt werden. Berichte müssen Vertrauen genießen oder ausgemustert werden.

SAPs öffentliche Seiten geben die Form dieser Kosten an, ohne sie pro Workflow zu bepreisen. SAP Activate umfasst Tests, Qualitätsgates, Fit-to-Standard-Workshops, Bereitstellung und Run. SAP Cloud ALM umfasst Testorchestrierung, Rückverfolgbarkeit, Betriebsüberwachung und Ausnahmebereiche. SAP Learning-Migrationsinhalte umfassen Problembehandlung und Vorgängeranforderungen. Sicherheitsschulungen umfassen Berechtigungsdesign und Fehlerbehebung. Trust Center-Seiten umfassen 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 Berührungen sind für eine Lieferantenrechnung vor und nach SAP erforderlich? Wie viele Ausnahmen erfordern eine Expertenüberprüfung? Wie oft verlassen Benutzer SAP für 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 Support-Aufwand bleibt nach der Stabilisierung bestehen? Wie viel KI-Unterstützung übersteht die Compliance-Prüfung?

Dieser Ansatz wird manchmal stark für SAP sprechen. Ein fragmentiertes Unternehmen, das viele lokale Systeme, manuelle Genehmigungen, inkonsistente Stammdaten, schwache Prüfnachweise und fragile Integrationen betreibt, kann durch Standardisierung viel gewinnen. SAP kann eine gemeinsame Prozesssprache, Kerndatensatz, Kontrollen, Analysen und Integrationspfad bereitstellen, deren unabhängiger Aufbau 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 ist.

Derselbe Ansatz kann SAPs Fall auch schwächen. Wenn ein Kunde eine begrenzte Prozesskomplexität, schlechte Führungsabstimmung, schwache Datenverantwortung oder mangelnde Änderungsbereitschaft hat, kann SAP zu einer teuren Art werden, Unordnung zu formalisieren. Wenn die Organisation keine Standardprozesse, Clean-Core-Grenzen oder Cloud-Betriebsgrenzen akzeptieren kann, kann sie für Modernisierung bezahlen, während alte Supportkosten in neuer Form erhalten bleiben. Wenn Benutzer weiterhin Nebenkalkulationstabellen mehr vertrauen als SAP-Berichten, wurde das System of Record nicht akzeptiert.

Es gibt keine universelle SAP-ROI. Es gibt nur die operative Mathematik eines bestimmten Unternehmensworkflows, nachdem alle Aufsichts-, Integrations-, Ausnahme-, Support- und Änderungskosten gezählt sind.

Was würde SAPs Wert stärker beweisen?

Die öffentlichen Beweise reichen aus, um ein vorsichtiges Urteil zu stützen, aber kein vollständiges betriebliches Urteil. Stärkere Beweise würden auf Workflow-Ebene gemessen. Für Finanzen könnte dies die Dauer des Abschlusszyklus, das manuelle Buchungssatzvolumen, Abstimmungsfehler, Prüfungsanpassungen, Kontrollausnahmen und Support-Tickets nach dem Go-Live umfassen. Für die Beschaffung könnte dies die Bestellzykluszeit, Rechnungsabgleichsausnahmen, Lieferantenstammdatenfehler, Genehmigungsnacharbeit und Zahlungssperren umfassen.

Für Personal könnte dies die Mitarbeiterdatengenauigkeit, die Bereitstellungszeit für Zugriffe, Gehaltsabrechnungskorrekturen und Datenschutzvorfälle umfassen. Für die Lieferkette könnte dies die Bestandsgenauigkeit, Planungsausnahmen, die Zuverlässigkeit von Lieferversprechen und Integrationsfehler umfassen.

Migrationsnachweise wären besonders wertvoll: Anzahl der Migrationsobjekte, Fehlerraten nach Objekt, Cutover-Dauer, offene kritische Fehler zum Go-Live, Datenqualitätssanierungsstunden und nachgelagerte Abstimmungsergebnisse. Integrationsnachweise würden Nachrichtenvolumina, Wiederholungsraten, ungelöste Ausnahmen, Duplikatsbehandlung und geschäftliche Freigabe zeigen. Sicherheitsnachweise würden Rollenüberprüfungsergebnisse, Konflikte bei der Funktionstrennung, Notfallzugriffsnutzung, Prüfprotokollabruf, SIEM-Korrelation und Zugriffsrezertifizierung zeigen.

Cloud-Nachweise würden Tenant-spezifische Verfügbarkeit, Wartungsfenster, Wiederherstellungstests und Support-Reaktionszeiten zeigen.

KI-Nachweise würden einen anderen Standard erfordern. Sie sollten nicht nur zeigen, dass Joule oder eine verwandte KI-Automatisierung eine Aufgabe erledigen kann, sondern dass sie dies wiederholt mit korrekten Berechtigungen, angemessenen Nachweisen, zuverlässiger Ausnahmebehandlung, klarer menschlicher Aufsicht und Rollback tun kann. 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.

Kundenberichte und Pressemitteilungen können nützliche Signale sein, aber sie sollten vorsichtig gewichtet werden. SAPs Nokia-Ankündigung ist aktuell und relevant, weil sie zeigt, dass ein großes Unternehmen SAP S/4HANA in ein RISE with SAP- und Azure-Betriebsmodell verlagert. Sie zeigt nicht das realisierte Betriebsergebnis. Die eigentlichen Beweise werden später kommen, wenn Nokia und ähnliche Kunden akzeptierte Workflows mit geringerer Komplexität, besserer Prüffähigkeit und niedrigeren Gesamtänderungskosten betreiben können.

Bis diese Beweise öffentlich sind, sollte die Sicherheit des Artikels moderat bleiben. SAP hat die Produkttiefe, die finanzielle Größe, den Lebenszyklushebel und die Cloud-Strategie, um für Unternehmensdatensätze zentral zu bleiben. Die schwierige Frage ist, ob jeder Kunde dies in akzeptierte Workflows umsetzen kann.

Das Urteil

SAP SE sollte am akzeptierten Unternehmensdatensatz gemessen werden, nicht an der Eleganz der Suite-Karte. Nach diesem Maßstab ist SAP glaubwürdig, aber niemals selbstbeweisend. Das Unternehmen verfügt über die Größe, Produkttiefe, Support-Lebenszyklus, Implementierungsmethodik, Überwachungsoberfläche, Integrationsplattform, Sicherheitsvokabular, Data-Governance-Geschichte und KI-Ambition, 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 ist, dass SAPs schwierigste Arbeit mit dem Kunden geteilt wird. Migrationsqualität, Prozesspassung, Clean-Core-Disziplin, Stammdaten-Governance, Integrationssemantik, Rollendesign, Prüfungsüberprüfung, Ausnahmeverantwortung, Release-Tests, Partnerleistung und Benutzerakzeptanz werden nicht durch den Kauf der Suite gelöst. Sie sind die Arbeit, die Software in institutionelle Wahrheit verwandelt. Wenn diese Arbeit gut gemacht ist, kann SAP fragmentierte Systeme und manuelle Abstimmungen durch einen zuverlässigeren Betriebsdatensatz ersetzen. Wenn sie schlecht gemacht ist, kann SAP zu einer neuen Heimat für alte Komplexität werden.

Business AI ändert dieses Fazit nicht. Es macht den Datensatz wichtiger. Ein KI-Assistent oder automatisierter Workflow kann nur nützlich sein, wenn er innerhalb eines governierten Prozesses mit korrektem Kontext, Berechtigungen, Nachweisen und Wiederherstellungspfaden handelt. Die Zukunft, die SAP verkaufen möchte, ist nicht nur Cloud-ERP mit intelligenteren Schnittstellen. Es ist ein Unternehmensbetriebsmodell, in dem Daten, Prozess, Richtlinien und KI um vertrauenswürdige Datensätze koordiniert werden.

Das ist ein ernstes Angebot. Es ist auch eine hohe Messlatte. Die richtige Kauf Frage ist nicht, ob SAP ein breites Produktportfolio zeigen kann. Es ist, ob ein wiederholter Finanz-, Beschaffungs-, Personal-, Lieferketten- oder Betriebsworkflow nach Migration, Integration, Berechtigung, Prüfung, Ausnahmebehandlung, Cloud-Betrieb, Support-Lebenszyklus und KI-Unterstützung akzeptiert werden kann. SAPs Argument ist am stärksten, wenn die Antwort Ja lautet und wenn die Kosten, um dieses Ja zu erreichen, niedriger sind als die Kosten, die unternehmensweite Wahrheit verstreut zu lassen.