10 Jahre S/4: Rennwagen mit angezogener API-Handbremse

Wir haben eng mit unseren Kunden zusammengearbeitet, die sich in der digitalen Wirtschaft weiterentwickeln, um herauszufinden, an welchen Stellen digitalisierte Prozesse den größten Mehrwert bringen können“, sagte damals Bernd Leukert, Vorstandsmitglied der SAP. Sein Name ist wie kaum ein anderer mit dem strategischen und technologischen Übergang von der SAP Business Suite zu S/4 – inklusive Cloud-Fokus, In-memory-Technologie (Hana) und Fiori-Nutzererlebnis – verbunden. Und weiter: „Das Ergebnis ist ein vollständig neu gestalteter Kern – SAP S/4 Hana ist damit der erste digitale Kern für das digitale Geschäft in der Branche. Mit dieser Lösung können Unternehmen bislang unerreichte Mehrwerte erzielen, etwa durch innovative Anwendungsfälle in zentralen Bereichen wie Finanzen und Logistik. Sie profitieren dabei von vereinfachten Datenmodellen und einer reaktionsschnellen Benutzererfahrung.“

S/4 zwingt zur Neuausrichtung

Seitdem ist eine ganze Menge passiert. Die Plattform hat SAP-Kunden tatsächlich dazu gezwungen, ihre Prozesse neu zu denken. Sie hat Diskussionen über Datenmodelle, Automatisierung und Geschäftsarchitektur neu entfacht. Und sie hat nicht unwesentlich dazu beigetragen, dass IT nicht länger als reiner Dienstleister, sondern als strategischer Partner im Unternehmen agiert. Auch kulturell wirkt S/4 Hana: Die Plattform bringt Business und IT an einen Tisch – oder zumindest näher zusammen. In der Community wird das vielfach gewürdigt.

Aber bei aller Anerkennung: Ein Thema sorgt nach wie vor für Stirnrunzeln, vielleicht auch für Bauchschmerzen: die nach wie vor eingeschränkte Verfügbarkeit offener, konsistenter Schnittstellen (APIs). In einer Zeit, in der Innovation durch Integration entsteht, wirkt genau das wie ein Bremsklotz. Man könnte sagen: S/4 Hana könnte wie ein hochgezüchteter Rennwagen fahren – aber er ist auf die ersten beiden Gänge gedrosselt. Leistung ist da, aber sie kann sich nicht frei entfalten. Das ist keine Lappalie. Moderne Geschäftsmodelle setzen nun mal auf Modularität. Ja, SAP ist häufig das Rückgrat – aber drumherum arbeiten oft Dutzende spezialisierter Tools, Plattformen und Services. Die Integration dieser Lösungen entscheidet über Agilität, Geschwindigkeit und Innovationskraft.

Fehlende oder unklare APIs führen nicht nur zu Verzögerungen in Projekten, sondern schränken auch die technologische Gestaltungsfreiheit ein. Und genau das empfinden viele Unternehmen zunehmend als Wettbewerbsnachteil. Das hat wenig mit Leukerts Versprechen von „vereinfachten Daten­modellen und einer reaktionsschnellen Benutzer­erfahrung“ zu tun. Die Frage liegt nahe: Warum bekommt ein großer Konzern mit über 100.000 Mitarbeiterinnen und Mitarbeitern dieses Problem nicht besser in den Griff? Die Gründe sind vielfältig.

Erstens: Altlasten. Die SAP-Welt ist historisch gewachsen – über Jahrzehnte hinweg. Nicht alles lässt sich nahtlos in ein modernes API-Paradigma überführen, ohne technische Konflikte zu riskieren. Zweitens: Prioritäten. Der Fokus lag lange auf Migration, Stabilität und Lizenzsicherung – weniger auf radikaler Öffnung. Drittens: Schutzlogik. Offene APIs stellen unter Umständen bestehende Geschäftsmodelle infrage. Wer alles anbietet, macht sich angreifbar. Und viertens: strukturelle Trägheit. Rückmeldungen aus der Community finden oft nur verzögert oder selektiv Eingang in die Produktentwicklung – trotz intensiver Partnernetzwerke.

Das Fundament steht

Zehn Jahre nach dem Start von S/4 ist klar:
Das Fundament steht. Jetzt kommt es darauf an, die Architektur weiter zu öffnen. Wer SAP zukunftsfähig machen will, muss APIs als strategische Infrastruktur begreifen – nicht als technische Kür. Es wäre schade, wenn der Rennwagen dauerhaft im zweiten Gang bliebe.

Weiter zum Partnereintrag: