Eine Schnittstelle kann Daten fehlerfrei übertragen und dennoch die falsche Bedeutung weitergeben.
Dasselbe Produkt beginnt seine digitale Reise in unterschiedlichen Formen.
Der Vertrieb erfasst es im CRM als Teil einer kommerziellen Produktfamilie. Während der Angebotserstellung bildet CPQ es als konfigurierbares Modell mit Optionen und Regeln ab. Nach der Auftragserteilung erwartet das ERP eine oder mehrere Materialnummern. Im Engineering ist es möglicherweise unter einer weiteren technischen Bezeichnung bekannt, die mit Zeichnungen und Spezifikationen verknüpft ist.
Jede Beschreibung kann in ihrem eigenen Kontext richtig sein. Die Schwierigkeit beginnt, sobald die Informationen weitergegeben werden müssen.
Die Daten kommen an. Die Bedeutung nicht.
Eine technisch funktionierende Schnittstelle kann jedes erforderliche Feld fehlerfrei übertragen. Sie kann jedoch nicht entscheiden, ob eine kommerzielle Produktfamilie einer einzelnen Konfiguration, mehreren Konfigurationen oder einer vollständigen Materialstruktur entspricht.
Sie kann nicht wissen, welche technische Bezeichnung nach einer Produktänderung noch gültig ist. Ebenso wenig kann sie bestimmen, in welchem System die Information korrigiert werden muss, wenn zwei Definitionen nicht mehr übereinstimmen.
Ohne abgestimmte Zusammenhänge transportiert die Integration lediglich Unsicherheit schneller weiter.
Gemeinsame Bedeutung erfordert keine identischen Strukturen
Ziel ist es nicht, CRM, CPQ, ERP und Engineering-Systeme dazu zu zwingen, ein Produkt exakt gleich zu beschreiben. Jedes System erfüllt einen anderen Zweck und benötigt daher eine andere Sichtweise.
Entscheidend ist, zu definieren, wie diese Sichtweisen miteinander zusammenhängen. Eine kommerzielle Produktfamilie kann zu mehreren konfigurierbaren Modellen führen. Eine Konfiguration kann mehrere Materialpositionen erzeugen. Eine technische Bezeichnung kann das Ergebnis mit einer bestimmten Zeichnung oder Spezifikation verbinden.
Diese Zusammenhänge sind nicht nur technische Zuordnungen. Sie sind Geschäftswissen.
Verantwortung ist Teil der Architektur
Jede wichtige Definition und Zuordnung benötigt eine klare Verantwortung. Wenn sich ein Produkt ändert, muss feststehen, welche Systeme betroffen sind, wer den Zusammenhang aktualisiert und wie die Änderung geprüft wird.
Data Governance kann abstrakt klingen. Im Arbeitsalltag zeigt sich ihr Fehlen jedoch durch wiederholte Dateneingaben, manuelle Korrekturen, widersprüchliche Auswertungen und die Frage, welchem Wert vertraut werden kann.
Eine zuverlässige Integration benötigt daher mehr als eine Schnittstelle. Sie benötigt gemeinsame Definitionen, klare Verantwortlichkeiten und einen kontrollierten Prozess, um die Zusammenhänge aktuell zu halten.
Die Perspektive
Wenn zwischen den Systemen klar ist, wie ihre unterschiedlichen Sichtweisen zusammenhängen, wird eine Übergabe zu mehr als der Übertragung von Feldern. Die Information behält ihre Bedeutung, während sie den Prozess durchläuft.
Bevor Systeme Daten austauschen können, muss das Unternehmen klären, was diese Daten bedeuten — und wer diese Bedeutung aktuell hält.