Was Datenarbeit von ERP-Systemen lernen kann

ERP-Systeme werden häufig als große Integrationsleistung beschrieben. Das stimmt, greift aber zu kurz. Entscheidend war nicht allein, dass Daten zwischen Modulen fließen konnten. Entscheidend war, dass die beteiligten Bereiche innerhalb eines gemeinsamen Rahmens arbeiten mussten. Begriffe, Objekte, Zuständigkeiten und Abläufe wurden verbindlich genug, damit ein Ende-zu-Ende-Prozess funktionieren konnte. Die Struktur war oft unbequem. Genau dadurch wurde sie wirksam.

Ein Auftrag konnte nicht je nach Abteilung etwas völlig anderes bedeuten, ohne dass der Prozess an einer Stelle sichtbar brach. Die Organisation musste Differenzen klären oder zumindest sauber abbilden. Das ist ein wichtiger Unterschied zu vielen heutigen Dateninitiativen. Dort können unterschiedliche Realitäten lange nebeneinander existieren, weil die technische Verarbeitung trotzdem irgendwie funktioniert. Die Unklarheit zeigt sich erst später: in widersprüchlichen Kennzahlen, doppelten Datenprodukten und endlosen Abstimmungen.

Die Lösung kann nicht darin bestehen, ein neues monolithisches ERP für alle Datenfragen zu bauen. Unternehmen sind heute deutlich dezentraler. Cloud-Plattformen, Fachanwendungen, Data Products, APIs, BI-Lösungen und KI-Systeme verändern sich schnell. Viele relevante Zusammenhänge verlaufen quer zu stabilen Prozessen.

Ein Datenprodukt kann mehrere Domänen bedienen. Eine Kennzahl kann strategische, regulatorische und operative Bedeutung besitzen. Ein Use Case verbindet Ziele, Fachobjekte, Daten, Modelle, Entscheidungen und Aktionen. Diese Realität passt nicht in ein einziges starres Prozessmodell. Trotzdem bleibt die alte Aufgabe bestehen: Unterschiedliche Bereiche brauchen eine gemeinsame operative Grundlage.

Ein Betriebssystem ist nicht die Anwendung selbst. Es schafft die Bedingungen, unter denen viele Anwendungen zuverlässig zusammenarbeiten können. Übertragen auf Datenarbeit bedeutet das: Data Warehouse, Lakehouse, Katalog, BI, Governance-Tool und KI-Plattform bleiben bestehen. Was häufig fehlt, ist eine verbindende Arbeitsschicht zwischen Daten und täglicher Arbeit.

Diese Schicht beschreibt nicht nur Informationen. Sie organisiert die Logik der Datenarbeit: Welche fachlichen Objekte existieren? Wie hängen Domänenperspektiven zusammen? Welche Ziele und Entscheidungen erzeugen Anforderungen? Welche Datenprodukte stellen Fähigkeiten bereit? Welche Regeln und Verantwortlichkeiten gelten? Welche Workflows setzen eine fachliche Absicht um? Welche Ergebnisse und Wirkungen entstehen? Anders als ein altes ERP darf diese Struktur nicht auf Jahrzehnte eingefroren sein. Sie muss serviceorientiert, erweiterbar und lernfähig bleiben. Stabil genug für Verbindlichkeit. Beweglich genug für neue Realität.

Angenommen, ein Data Steward legt ein neues Datenprodukt für steuerbare Anlagen an. In einer klassischen Katalogwelt werden Name, Beschreibung, Owner und Assets gepflegt. In einem Betriebssystem für Datenarbeit beginnt ein Prozess. Das System zeigt ähnliche Produkte in anderen Domänen. Es fragt nach dem fachlichen Zweck und der Abgrenzung. Bestehende Objekte wie Anlage, Betreiber, Netzgebiet und Vertrag werden eingeblendet. Governance-Regeln führen durch notwendige Entscheidungen. Verantwortliche prüfen den Entwurf. Später bleibt sichtbar, welche Berichte, Workflows und Ziele das Produkt verwenden.

Die Struktur entsteht nicht im Nachhinein durch Dokumentation. Sie entsteht während der Arbeit. Genau darin lag auch die Stärke von ERP: Die gemeinsame Beschreibung war nicht freiwillige Zusatzpflege. Sie war Teil des Prozesses.

Ein Betriebssystem für Datenarbeit sollte bestehende Plattformen nicht ablösen. Kataloge liefern Metadaten, Datenplattformen stellen Daten bereit, BI-Werkzeuge visualisieren und Workflow- oder KI-Komponenten führen Aufgaben aus. Was häufig fehlt, ist der gemeinsame Rahmen aus Geschäftszweck, Verantwortung, Regeln und nachvollziehbarer Arbeit.

Das Ziel ist keine neue zentrale Datenfestung. Dezentrale Lösungen sollen anschlussfähig bleiben und auf einen geklärten Stand zurückgreifen können.

ERP-Systeme haben Unternehmen nicht durch Motivationskampagnen verändert. Sie haben Arbeitsabläufe, Rollen und Abhängigkeiten so strukturiert, dass neues Verhalten notwendig wurde. Bei Datenarbeit wird häufig der umgekehrte Weg versucht: Erst soll eine bessere Datenkultur entstehen, dann werden Menschen hoffentlich konsequenter dokumentieren, abstimmen und wiederverwenden. Das kann punktuell funktionieren. Dauerhaft setzt sich meist die Struktur durch, die im Alltag am einfachsten ist.

Wenn lokale Lösungen schneller sind als gemeinsame, entstehen lokale Lösungen. Wenn Entscheidungen unsichtbar bleiben können, bleiben sie unsichtbar. Wenn Wiederverwendung mehr Aufwand macht als Neubau, wird neu gebaut. Ein Betriebssystem für Datenarbeit verändert diese Anreize. Es macht vorhandenen Kontext sichtbar, führt durch notwendige Klärungen und lässt neue Arbeit auf bestehender Struktur aufbauen. Die wichtigste Lektion aus der ERP-Geschichte lautet deshalb nicht: Alles muss in ein großes System. Sie lautet: