Das Fundament muss stehen

Automatisierungen greifen oft nur punktuell, Prognosen werden vorsichtig genutzt, und das Vertrauen in datenbasierte Entscheidungen ist brüchig. Das Problem liegt selten in der KI selbst. Es liegt tiefer – in der Architektur. In meiner Praxis an der Schnittstelle von Daten­architektur und Unternehmenssteuerung habe ich eines gelernt: Die glänzende Oberfläche neuer Technologien ist wertlos, wenn der Maschinenraum darunter nicht funktioniert.

Operative Stabilität

Wer sich S/4-Transformationen genauer ansieht, erkennt ein bekanntes Muster. Priorität hat, was den Betrieb absichert: sta­bile Prozesse, saubere Releases, ein möglichst störungsfreier Go-live. Analytics gilt als komplex, potenziell riskant oder als Thema für eine spätere Phase. Erst einmal live gehen – dann weitersehen.

Nach dem Go-live zeigt sich jedoch, was diese Entscheidung kostet. Historische ­Daten fehlen oder sind nur noch eingeschränkt nutzbar. Kennzahlen wurden neu definiert, oft ohne nachvollziehbare Übergangslogik. Reports liefern andere Werte als früher, ohne dass sich operativ etwas geändert hätte. Genau hier beginnt das KI-Problem. Modelle benötigen stabile Zeitreihen, konsistente Logiken und reproduzierbare Datenstände. KI wird dann nicht zur Produktivkraft, sondern zum Experiment. Der Denkfehler liegt im Ansatz: Operative Architektur und analytische Architektur werden getrennt gedacht. KI gilt als Aufsatz auf ein fertiges System. Dabei werden Architekturentscheidungen getroffen, ohne ihre analytischen Konsequenzen mitzudenken.

KI entsteht zwischen Systemen

Relevante KI-Anwendungen entstehen fast nie in einem einzelnen System. Sie entstehen zwischen Systemen. Transaktionale Daten aus S/4 liefern den fachlichen Kontext. Sensor- und Ereignisdaten bringen zeitliche Dynamik. Externe Daten ergänzen Markt- oder Lieferketteninformationen. Diese Daten sprechen unterschiedliche Sprachen. Zeitbezug, Granularität und Bedeutung unterscheiden sich – oft historisch gewachsen und nur implizit bekannt. Ohne klare Entkopplung entstehen fragile Abhängigkeiten. Technisch zeigt sich das in fehlenden oder nicht versionierten Schnittstellen, in sogenannten Data Contracts.

Ein Data Contract ist dabei mehr als ein technisches Dokument; er ist ein digitaler Handschlag zwischen der operativen IT und den Datennutzern. Er legt verbindlich fest, welche Datenqualität und welche ­Semantik aus dem ERP geliefert wird. Fehlt dieser „Vertrag“, bricht die Kette bei jedem kleinen Systemupdate. Ein Instandhaltungsprojekt aus der Praxis verdeutlicht das: Ziel war es, Maschinenausfälle vorherzusagen. Nach einem S/4-Release änderten sich Materiallogiken im ERP. Für die Fach­bereiche blieb alles gleich, doch für das ­Modell drifteten die Vorhersagen, ohne dass ein Fehler sichtbar war. Die Ursache war banal: ein Integrationsbruch, weil eine fachlich relevante Änderung weder versioniert noch kommuniziert worden war.

Mit generativer KI verschärft sich dieses Muster. Sprachbasierte Modelle sind besonders abhängig von konsistentem Kontext und historisierten Informationen. Wenn Daten bei jedem Release ihre Bedeutung ändern, bleiben Ergebnisse oberflächlich. Ohne stabile Semantik – also klar definierte Bedeutungen von Kennzahlen und Zeitbezügen – wird generative KI zur bloßen textlichen Assistenz, aber nicht zum Entscheidungsinstrument.

Dabei rückt oft das Thema Echtzeit in den Mittelpunkt. Doch für lernende KI ist etwas anderes entscheidend: Persistenz. Modelle, die primär auf aktuellen Streams reagieren, verlieren historische Muster und saisonale Effekte. Echtzeit steuert Verhalten, aber Persistenz schafft das notwendige Verständnis für echte Business-Intelligence.
Organisation schlägt Technik: Wer besitzt die Daten? Ein oft unterschätzter Faktor ist die Organisation. Datenverantwortung ist häufig unklar oder nur projekt­bezogen verteilt. IT optimiert auf Systembetrieb, Kosten und Verfügbarkeit. Wenn Zahlen nicht mehr passen, beginnt die ­Suche nach dem Schuldigen. Governance existiert häufig auf dem Papier, greift aber nicht im Alltag. Hinzu kommt eine fragmentierte Kompetenzlandschaft: BW-Experten verstehen Datenmodelle, Funktionsberater kennen Prozesse, und Data-­Scientists arbeiten modellgetrieben – oft ohne tiefen Einblick in die ERP-Semantik. Jeder ist gut in seinem Bereich, doch dazwischen entsteht wenig.

Echte Veränderung beginnt bei der fachlichen Ownership. Datenverantwortung darf kein IT-Ticket sein. Es braucht Verantwortliche in den Fachbereichen, die nicht nur für den Prozess (zum Beispiel den Wareneingang), sondern auch für die Datenqualität und deren analytische Bedeutung gerade­stehen. Nur wenn das Business erkennt, dass Daten ein Vermögenswert sind, wird die technologische Modernisierung nachhaltig.

Drei strategische Hebel für 2026

Aus diesen Beobachtungen lassen sich konkrete Chancen ableiten:

1. Analytik als Design-Kriterium: Analytische Anforderungen müssen von Beginn an Teil der Architektur sein – gleichwertig neben der operativen Stabilität.

2. Explizite Semantik: Data Contracts und versionierte Schnittstellen sind keine Theorie, sondern die Bauanleitung dafür, dass Daten über S/4-Hana-Releases hinweg ihre Bedeutung behalten.

3. Dauerhafte Verantwortung: Datenhoheit braucht klare, dauerhaft verankerte fachliche Ownership.

Wer Architektur weiterhin primär auf operativen Betrieb optimiert, wird auch künftig beeindruckende KI-Demos sehen – aber wenig Wirkung im Alltag erzielen. Wer den Unterbau jetzt aufräumt, gewinnt ein Unternehmen, das nicht nur bereit für KI ist, sondern das seine eigene Realität endlich präzise steuern kann. (Quelle: Stefan Maxones)