Beim Go-live getroffene Datenmodellentscheidungen werden zu strukturellen Einschränkungen.
ERP-Datenmodelle werden selten mit Blick auf Skalierung entworfen. Die initiale Implementierung optimiert dafür, das System live zu bringen, bestehende Prozesse abzubilden und unmittelbare Reporting-Bedürfnisse zu erfüllen. Das resultierende Datenmodell ist eine Momentaufnahme davon, wie das Unternehmen zu einem Zeitpunkt operierte.
Mit dem Wachstum des Unternehmens, dem Hinzufügen von Entitäten, dem Ändern von Prozessen und dem Bedarf an ausgefeilterem Reporting wird diese Momentaufnahme zu einer Einschränkung.
Der Weg von einem funktionalen ERP zu einem einschränkenden ist fast immer ein Datenmodellproblem — und es beginnt fast immer bei der Implementierung.
1. Was ein Datenmodell im ERP-Kontext tatsächlich ist
Das Datenmodell eines ERP-Systems ist die Menge struktureller Entscheidungen, die bestimmen, wie Informationen organisiert, verknüpft und zugänglich sind. Es umfasst: wie Produkte kategorisiert werden, wie Kunden und Lieferanten segmentiert werden, wie Organisationseinheiten strukturiert sind.
Diese Entscheidungen gehen nicht nur darum, wo Daten gespeichert werden. Sie gehen darum, welche Fragen das System beantworten kann. Datenmodellentscheidungen sind architektonische Entscheidungen. Sie bestimmen, was das System tun kann, nicht nur was es aktuell tut.
2. Warum Datenmodelle unter Skalierung brechen
Die Probleme in ERP-Datenmodellen entstehen unter Skalierung, weil Skalierung die Konsequenzen früher Entscheidungen verstärkt. Ein Produktkategorisierungsschema, das für 500 SKUs funktioniert, erzeugt Reporting-Komplexität bei 5.000.
Das zugrundeliegende Problem ist, dass initiale Datenmodellentscheidungen mit den zum Zeitpunkt verfügbaren Informationen getroffen werden: das aktuelle Betriebsmodell, die aktuellen Reporting-Bedürfnisse, die aktuelle Organisationsstruktur. Skalierung erzeugt keine Datenmodellprobleme. Sie macht bestehende sichtbar und teuer.
3. Die Kosten von Datenmodellschulden
Datenmodellprobleme nach dem Go-live zu beheben ist teuer. Die Daten selbst tragen den Abdruck des ursprünglichen Modells: Jahre von Transaktionen, kodiert nach dem ursprünglichen Kategorisierungsschema.
In der Praxis beheben die meisten Organisationen Datenmodellschulden nicht. Sie umgehen sie: benutzerdefinierte Berichte, die strukturelle Lücken kompensieren, Data Warehouses, die Informationen re-normalisieren, manuelle Prozesse, die die Lücken füllen, die das ERP nicht füllen kann.
4. Datenmodelle für Skalierung entwerfen
Datenmodelldesign für Skalierung erfordert explizit zu fragen: Welche Fragen wird diese Organisation in drei bis fünf Jahren beantworten müssen, und unterstützt dieses Datenmodell diese Fragen?
Das Ziel ist kein perfektes Datenmodell. Es ist ein Datenmodell, das weiterentwickelt werden kann, ohne eine vollständige Neuimplementierung zu erfordern.
5. Governance für laufende Datenmodellgesundheit
Selbst ein gut entworfenes initiales Datenmodell wird im Laufe der Zeit Weiterentwicklung erfordern. Governance für Datenmodellgesundheit bedeutet, einen Prozess zur Bewertung von Änderungen zu haben: wer sie vorschlägt, wer sie genehmigt, wie ihre Auswirkungen bewertet werden.
Ohne diese Governance akkumulieren sich Datenmodelländerungen genauso wie Datenmodellschulden akkumulieren: eine kleine Entscheidung nach der anderen, jede isoliert vernünftig erscheinend, zusammen strukturelle Komplexität schaffend.
Fazit
ERP-Datenmodelle, die nicht für Skalierung entworfen wurden, werden schließlich das Unternehmen einschränken, das von ihnen abhängt. Die Probleme, die unter Skalierung auftauchen, waren fast immer bei der Implementierung vorhanden — sie waren nur noch nicht sichtbar.
Datenmodelldesign als architektonische Investition zu behandeln ist eine der wirkungsvollsten Entscheidungen in jeder ERP-Implementierung. Es bestimmt nicht nur, was das System heute tun kann, sondern was das Unternehmen in den nächsten zehn Jahren über sich selbst wissen kann.
