ERP ist nicht die Wahrheit: Wo Unternehmensdaten wirklich entstehen (2/5)

In vielen Unternehmen gilt eine unausgesprochene Regel: Was im ERP steht, muss stimmen. Das ist verständlich. ERP-Systeme sind für zentrale Geschäftsprozesse gebaut. Oracle beschreibt ERP als integrierte Software für das Tagesgeschäft – von Accounting über Procurement bis Supply Chain – und betont, dass ERP gemeinsame transaktionale Daten zusammenführt. IBM wiederum ordnet ERP als eines von mehreren Systems of Record ein und grenzt dieses Konzept ausdrücklich von einer Single Source of Truth ab. Genau hier liegt der Kern des Problems: ERP ist autoritativ für Transaktionen, aber nicht automatisch für die gesamte betriebliche Realität.

Warum das so wichtig ist, zeigt die Praxis moderner Unternehmen. Laut Okta nutzen Organisationen inzwischen im Durchschnitt mehr als 100 Apps pro Kunde, nach 9 Prozent Wachstum im Jahresvergleich. Gleichzeitig nutzen B2B-Entscheider laut McKinsey heute im Schnitt zehn Interaktionskanäle entlang ihrer Buying Journey – 2016 waren es noch fünf. Wer Entscheidungen nur aus ERP-Daten ableitet, betrachtet also zwangsläufig nur einen Ausschnitt der Wirklichkeit. (Okta)

ERP bildet Transaktionen ab – nicht die Realität

ERP-Systeme sind stark, wenn es darum geht, Geschäftsvorfälle sauber zu dokumentieren: Bestellung, Rechnung, Buchung, Bestandsveränderung, Wareneingang, Kostenstelle. Genau dafür wurden sie entwickelt. Oracle beschreibt ERP als Plattform zur Steuerung operativer Kernprozesse und zur Zusammenführung geteilter Transaktionsdaten zwischen Funktionen. SAP formuliert ähnlich: ERP integriert zentrale Unternehmensprozesse in einem einzigen System und liefert Echtzeit-Einblicke über die Organisation hinweg. (Oracle)

Was ERP aber meist nicht abbildet, ist der Ursprung dieser Daten. Ein Preis entsteht nicht im ERP, sondern in einer Verhandlung. Ein Bedarf entsteht nicht im ERP, sondern beim Kunden, im Vertriebsgespräch oder im Nutzungskontext einer Maschine. Ein Servicefall beginnt nicht im ERP, sondern im Feld – oft lange bevor daraus ein Auftrag oder eine Rechnung wird. IBM macht in seiner Definition von Systems of Record deutlich, dass Unternehmen mehrere autoritative Systeme für unterschiedliche Datentypen brauchen und dass der „golden record“ erst durch deren Zusammenführung entsteht. (ibm.com)

Anders gesagt:
ERP zeigt zuverlässig, was verbucht wurde. Es zeigt oft nicht, warum es dazu kam.

Die wichtigsten Daten entstehen außerhalb des ERP

Vertrieb: Der Entscheidungskontext liegt in Kanälen, Gesprächen und Konfigurationen

Im Vertrieb entstehen die wertvollsten Informationen häufig vor dem Auftrag: in Meetings, Calls, E-Mails, CPQ-Konfigurationen, Preisfreigaben, Produktdemos oder im E-Commerce. McKinsey zeigt, wie stark dieser Kontext heute verteilt ist: B2B-Kunden nutzen im Durchschnitt zehn Interaktionskanäle, und mehr als die Hälfte der Befragten erwartet ein nahtloses Omnichannel-Erlebnis. Zudem gilt inzwischen die „Rule of Thirds“: Ein Drittel bevorzugt persönliche Interaktionen, ein Drittel Remote-Kontakt und ein Drittel digitale Self-Service-Strecken. (McKinsey & Company)

Das ERP sieht am Ende meist nur das Ergebnis: Auftrag, Preis, Menge, Rabatt, Liefertermin. Was fehlt, ist der Kontext hinter der Entscheidung. War der Preis Ergebnis einer strategischen Verhandlung? Wurde ein Angebotsumfang kurzfristig angepasst? Kam der Auftrag aus einem Portal, einem Außendienstgespräch oder einer Servicebeziehung? Ohne diesen Kontext werden Vertriebsdaten schnell falsch interpretiert – besonders in Pricing, Forecasting und Segmentanalysen.

Aftersales: Die Ursache liegt im Feld, nicht in der Buchung

Im Aftersales ist die Lücke zwischen ERP und Realität oft noch größer. Hier entstehen relevante Daten in Maschinen, Sensoren, Serviceeinsätzen, Diagnosemeldungen und Nutzungsprofilen. IoT Analytics beziffert die Zahl der vernetzten IoT-Geräte auf 18,5 Milliarden im Jahr 2024 und erwartet 39 Milliarden bis 2030. Die Menge realer Nutzungs- und Ereignisdaten wächst also massiv – und ein großer Teil davon entsteht weit außerhalb klassischer ERP-Systeme. (IoT Analytics)

Wie wertvoll diese Daten sind, zeigt Deloitte: Schlechte Instandhaltungsstrategien können die produktive Kapazität eines Werks um 5 bis 20 Prozent verringern; ungeplante Stillstände kosten industrielle Hersteller laut Deloitte geschätzt 50 Milliarden US-Dollar pro Jahr. Gleichzeitig kann Predictive Maintenance auf Basis von Echtwelt-Daten die Wartungsplanung um 20 bis 50 Prozent beschleunigen, die Anlagenverfügbarkeit um 10 bis 20 Prozent steigern und die Wartungskosten um 5 bis 10 Prozent senken. Diese Effekte entstehen nicht aus Buchungsdaten allein, sondern aus Sensor-, Zustands- und Ereignisdaten aus dem Feld. (Deloitte)

Das ERP sieht in diesem Umfeld typischerweise nur den Serviceauftrag, die Ersatzteilbewegung und die Rechnung. Die eigentliche Ursache – etwa Verschleißmuster, Einsatzbedingungen, Fehlbedienung oder eine technische Änderung – liegt woanders.

Das eigentliche Problem: Entscheidungen auf Basis verkürzter Realität

Solange ERP-Daten als alleinige Wahrheit behandelt werden, entsteht eine gefährliche Verkürzung. Analysen wirken präzise, sind aber inhaltlich unvollständig. Genau das macht schlechte Daten so tückisch: Der Fehler fällt selten dort auf, wo er entsteht, sondern oft erst später – in Fehlentscheidungen, unnötigen Kosten oder verpassten Chancen. IBM berichtet, dass 43 Prozent der Chief Operations Officers Datenqualitätsprobleme als wichtigste Datenpriorität nennen. Zudem schätzt mehr als ein Viertel der Unternehmen, jährlich über 5 Millionen US-Dollar durch schlechte Datenqualität zu verlieren; 7 Prozent berichten sogar von 25 Millionen US-Dollar oder mehr Verlust pro Jahr. (ibm.com)

Beispiel Pricing

Wenn im ERP nur der finale Verkaufspreis steht, fehlt für eine belastbare Analyse oft der eigentliche Kontext: Kundensegment, Angebotsphase, Wettbewerbsdruck, Verhandlungssituation, Kanal und strategische Zielsetzung. In einem Markt, in dem Käufer laut McKinsey zehn Kanäle nutzen und nahtlose Wechsel zwischen ihnen erwarten, reicht der Blick auf den Endpreis allein nicht mehr aus. Dann werden Durchschnittspreise verglichen, obwohl sie unter völlig unterschiedlichen Bedingungen entstanden sind. Das Ergebnis: scheinbar harte Pricing-Analysen, die in Wahrheit Äpfel mit Birnen vergleichen.

Beispiel Ersatzteilgeschäft

Im Ersatzteilgeschäft zeigt ERP oft nur den Absatz. Nicht sichtbar sind häufig Gerätegeneration, installierte Basis, Einsatzbedingungen, Wartungszustand, technische Modifikationen oder Ausfallursachen. Gerade Deloitte zeigt, dass Wartungs- und Verfügbarkeitsverbesserungen aus der Verknüpfung realer Anlagen- und Zustandsdaten kommen – nicht aus der isolierten Betrachtung von Ersatzteilbuchungen. Wer nur ERP-Absatz analysiert, verwechselt Nachfrage mit Ursache.

Warum die „Single Source of Truth“ oft ein Mythos ist

Viele Unternehmen reagieren auf diese Lücke mit Zentralisierung: Data Warehouse, Data Lake, Lakehouse, Reporting-Plattform, MDM. Das ist grundsätzlich sinnvoll – aber nur dann, wenn vorher geklärt ist, wo welche Daten tatsächlich entstehen. IBM beschreibt diesen Punkt sehr klar: Ein System of Record ist nicht dasselbe wie eine Single Source of Truth. Vielmehr liefern unterschiedliche Systeme jeweils autoritative Daten für unterschiedliche Domänen, und erst durch MDM bzw. einen „golden record“ entsteht ein konsolidiertes Gesamtbild. (ibm.com)

In der Praxis bedeutet das: ERP kann die autoritative Quelle für finanzielle und operative Transaktionen sein. CRM kann für Kundeninteraktionen führend sein. Ein MES oder IoT-System kann für Maschinen- und Prozessereignisse führend sein. Wer all diese Ebenen in ein ERP pressen will, erhält nicht automatisch Wahrheit – sondern oft nur zentralisierte Unschärfe. Dass moderne Unternehmen inzwischen mit durchschnittlich über 100 Apps arbeiten, macht diesen Punkt noch deutlicher: Die Wahrheit lebt heute verteilt.

Daten entstehen im Prozess – nicht im System

Im Modell der Serie ist das der Übergang vom Origin zur Structure: Erst wenn klar ist, ob Daten aus Verhalten, Transaktionen oder Ereignissen entstehen, lassen sie sich fachlich sauber klassifizieren, mit Zeitbezug versehen, versionieren und einer Verantwortung zuordnen. Ohne diesen ersten Schritt bleibt auch die beste Architektur unscharf – weil sie dann lediglich Daten bewegt, deren Ursprung und Bedeutung nicht eindeutig geklärt sind.

Eine tragfähige Datenstrategie beginnt deshalb nicht mit der Frage: „Welches System ist führend?“ Sie beginnt mit der Frage: „An welchem Punkt im Prozess entsteht die Information?“

Sinnvoll ist eine Unterscheidung in drei Ursprünge:

1. Verhalten

Hierzu gehören Interaktionen zwischen Menschen und Systemen: Preisverhandlungen, Angebotsanpassungen, Freigaben, Kanalwechsel, Self-Service-Nutzung oder digitale Beratung. Gerade im B2B-Vertrieb ist dieser Layer hochrelevant, weil Kaufentscheidungen heute kanalübergreifend entstehen.

2. Transaktionen

Das ist die natürliche Stärke von ERP: Aufträge, Rechnungen, Lieferungen, Zahlungen, Materialbewegungen, Bestandsveränderungen. Diese Daten sind strukturiert, prüfbar und für Finanzen, Operations und Audit unverzichtbar.

3. Ereignisse

Dazu zählen Maschinenzustände, Sensordaten, Ausfälle, Nutzungsdaten, Tickets, Serviceeinsätze oder Diagnosen. In Industrie und Service sind diese Daten oft entscheidend, weil sie Ursache, Timing und Muster von Problemen sichtbar machen. Genau daraus entsteht später der Serviceauftrag im ERP – aber eben erst später.

Was das für moderne Datenarchitektur bedeutet

Genau hier wird die Logik des Modells vollständig sichtbar:

• Origin klärt, wo Information entsteht.
• Structure legt fest, wie diese Information semantisch, zeitlich und fachlich beschrieben wird.
• Architecture sorgt dafür, dass diese Daten über Systemgrenzen hinweg belastbar integriert und nutzbar werden.
• Value entsteht schließlich erst dann, wenn aus dieser Kette bessere Entscheidungen, bessere Automatisierung oder neue Geschäftsmodelle resultieren.
  ERP ist darin wichtig – aber eben nur als ein Baustein innerhalb dieser Wertlogik, nicht als deren alleiniger Mittelpunkt.

Wenn ERP nicht die ganze Wahrheit ist, muss sich auch die Datenarchitektur ändern. Nicht ein einziges System sollte im Zentrum stehen, sondern ein klar modelliertes Zusammenspiel mehrerer Ebenen:

• Quellsysteme, in denen Daten entstehen, etwa CRM, CPQ, E-Commerce, MES, IoT oder Field Service.
• Transaktionssysteme, in denen Geschäftsvorfälle verbindlich verbucht werden, vor allem ERP.
• Analyse- und Konsolidierungsschichten, in denen Daten zusammengeführt, harmonisiert und für Entscheidungen nutzbar gemacht werden.

IBM weist darauf hin, dass Systems of Record laufend validiert, synchronisiert und über Integrationen oder APIs mit anderen Systemen verbunden werden müssen. Genau das ist die eigentliche Architekturaufgabe: nicht nur Daten zentralisieren, sondern Ursprünge, Verantwortlichkeiten, Zeitbezug und fachliche Semantik sauber definieren.

Die Konsequenz ist strategisch wichtig:
ERP bleibt unverzichtbar – aber in einer klaren Rolle.
Es ist das System der Transaktion, nicht das System der gesamten Realität.

Fazit

ERP-Systeme sind das Rückgrat vieler Unternehmen, weil sie Transaktionen zuverlässig dokumentieren, Prozesse integrieren und betriebliche Stabilität schaffen. Aber sie sind nur ein Teil der Wahrheit. Vertriebskontext entsteht in Interaktionen über viele Kanäle. Servicewissen entsteht in Maschinen, Sensoren und Einsätzen. Der „golden record“ entsteht nicht automatisch im ERP, sondern aus dem Zusammenspiel mehrerer Systems of Record.

Wer Daten ausschließlich aus ERP-Systemen interpretiert, riskiert verkürzte Sichtweisen – und damit teure Fehlentscheidungen. Unternehmen, die ihre Datenursprünge sauber verstehen, gewinnen dagegen bessere Pricing-Logiken, bessere Serviceentscheidungen, bessere Forecasts und belastbarere Datenarchitekturen. In einer Welt mit über 100 Business-Apps pro Unternehmen, zehn B2B-Kanälen pro Buying Journey und Milliarden vernetzter Geräte ist das kein Architekturdetail mehr, sondern eine Managementaufgabe.