Digitalisierung scheitert an Stammdaten, nicht an Software

Die Oberfläche ist nicht das Problem

Wer ein Digitalisierungsprojekt startet, denkt zunächst an Oberflächen: Dashboards, Formulare, Workflows. Was dann wochenlang die Arbeit blockiert, sieht man im Kick-off selten: Datenqualität, Exportformate, ungeklärte Zuständigkeiten zwischen Abteilungen und Altsystemen, die niemand mehr vollständig versteht — aber alle täglich nutzen.

Ein Muster, das sich in Integrationsprojekten immer wiederholt: Die neue Software funktioniert. Die alte auch, für sich genommen. Aber dazwischen liegt ein Graben, den niemand eingeplant hat — und der sich erst zeigt, wenn echte Daten fließen sollen.

Stammdaten: die unterschätzte Komplexität

Stammdaten sind Kundendaten, Artikelnummern, Lieferanteninformationen, Kostenstellen — alles, was im Betrieb als Referenz gilt und das andere Systeme benutzen, um zu arbeiten. In der Theorie gepflegt und strukturiert. In der Praxis oft gewachsen, historisch belastet und wenig konsistent.

Was „schlechte Stammdaten" konkret bedeutet

Nicht abstrakt gemeint. Typische Situationen aus der Projektpraxis:

Kundennummern existieren dreifach, weil über die Jahre drei verschiedene Systeme parallel geführt wurden.
Adressen wurden immer im Freitextfeld eingetragen — PLZ, Ort und Straße zusammen, ohne Struktur.
Artikelbezeichnungen enthalten veraltete Codes aus einem System, das vor acht Jahren abgelöst wurde.
Pflichtfelder im Altsystem sind mit Dummy-Werten gefüllt, weil sie damals keine geschäftliche Relevanz hatten.

Keiner dieser Punkte ist ein Katastrophenfehler für sich. Zusammen aber erzwingen sie Bereinigungsaufwand, der in keinem Angebot steht — und den niemand beauftragt hat.

Wie Daten in der Praxis entstehen

Stammdaten entstehen nicht durch Planung, sondern durch Nutzung. Eine Kollegin trägt eine Lieferantenadresse ein, weil sie gerade gebraucht wird. Ein Jahr später übernimmt das System eine andere Person, mit anderen Konventionen. Zehn Jahre später gibt es 400 Lieferanten im System — und niemand weiß mehr, welche davon noch aktiv sind, welche doppelt angelegt wurden und warum manche Felder leer geblieben sind.

Das ist kein Versagen. Das ist normale Betriebsrealität. Aber es ist eben auch die Realität, auf die ein neues System trifft.

Schnittstellen: Wer ist eigentlich zuständig?

Eine Schnittstelle zwischen zwei Systemen klingt technisch. Tatsächlich ist die schwierigste Frage oft keine technische: Wer ist für die Daten auf welcher Seite der Schnittstelle verantwortlich?

In vielen Mittelstandsprojekten gibt es darauf keine klare Antwort. Der ERP-Hersteller liefert eine Schnittstelle. Der neue Software-Dienstleister baut darauf auf. Aber was passiert, wenn die Daten, die das ERP liefert, nicht dem Format entsprechen, das die neue Lösung erwartet? Dann fängt die Zuständigkeitsdiskussion an.

Die Exportformat-Falle

Viele ältere Systeme exportieren Daten in Formaten, die technisch lesbar sind — CSV, XML, manchmal sogar PDF — aber inhaltlich nicht standardisiert. Ein konkretes Beispiel: Eine Exportdatei enthält Datumsangaben im Format TT.MM.JJJJ in einer Spalte, aber JJJJ-MM-TT in der nächsten, weil die Felder von unterschiedlichen Modulen geschrieben wurden. Das importierende System scheitert — nicht weil es schlecht gebaut ist, sondern weil niemand wusste, dass das Quellsystem intern inkonsistent ist.

Solche Probleme treten fast immer erst auf, wenn echte Produktionsdaten fließen. Testumgebungen laufen durch, weil die Testdaten sauber waren — sie wurden manuell angelegt. Die ersten 10.000 echten Datensätze dann nicht.

Zuständigkeitslücken im Projektalltag

Ein häufiges Szenario: Das ERP-System wird vom IT-Dienstleister A betreut. Die neue Fachsoftware baut Dienstleister B. Dazwischen gibt es eine Schnittstelle — aber keinen gemeinsamen Ansprechpartner, keinen abgestimmten Datenvertrag und keine Eskalationslinie, wenn etwas nicht passt.

Dienstleister A sagt: „Unser Export ist korrekt." Dienstleister B sagt: „Wir können nur verarbeiten, was wir bekommen." Der Auftraggeber sitzt dazwischen und wartet. Manchmal Wochen.

Was fehlt, ist kein technisches Tool — sondern ein Schnittstellenvertrag: wer liefert was in welchem Format, wann, mit welcher Validierung, und wer reagiert bei Abweichungen. Dieses Dokument existiert in den meisten Projekten nicht — oder wird mündlich besprochen und dann vergessen.

Typische Fallstricke in Integrationsprojekten

Aus der Praxis destilliert — keine erschöpfende Liste, aber die häufigsten Stolperstellen:

Datenmigration wird systematisch unterschätzt

Die Datenmigration — also das Übertragen bestehender Daten ins neue System — taucht im Projektplan oft als ein einziger Schritt auf. In Wirklichkeit besteht sie aus mehreren Phasen: Daten exportieren, analysieren, bereinigen, transformieren, importieren, validieren, nachbereinigen und nochmals validieren. Und das meistens mehrfach, weil beim ersten Lauf Fehler auftauchen, die vorher nicht sichtbar waren.

Projekte, die vier Wochen für die Migration einplanen, brauchen oft drei Monate. Das liegt nicht am schlechten Willen irgendjemandes — sondern daran, dass Datenqualität sich erst unter Produktionsbedingungen vollständig zeigt.

Kein fachlicher Daten-Eigentümer

Technisch können Daten migriert werden. Aber wer entscheidet, welche Datensätze doppelt vorliegen und welcher der „richtige" ist? Wer legt fest, welche Felder in den Altdaten ignoriert werden können, welche Pflicht sind? Diese Entscheidungen sind fachlich, nicht technisch — und sie brauchen jemanden im Unternehmen, der die Daten kennt und Entscheidungsgewalt hat.

Fehlt diese Person, verzögert sich jede Klärung um Tage. Manchmal werden Entscheidungen dann technisch umgangen — mit Dummy-Werten, leeren Feldern oder doppelten Einträgen. Das Problem verschiebt sich, löst sich aber nicht.

Altsysteme ohne aktuelle Dokumentation

In vielen Unternehmen läuft Software, die seit 12 oder 15 Jahren produktiv ist — und für die es keine aktuelle Dokumentation gibt. Die Logik steckt im System. Wer sie heute anpassen will, braucht oft den ursprünglichen Hersteller oder eine Reverse-Engineering-Phase, die niemand eingeplant hat und für die niemand bezahlen möchte.

Besonders heikel: Altsysteme, die eigentlich abgelöst werden sollen, aber noch für kritische Berechnungen zuständig sind. Solange der Ersatz nicht vollständig validiert ist, läuft das Altsystem weiter. Das ergibt Parallelbetrieb — mit doppelter Datenpflege und Synchronisationsproblemen als unmittelbare Folge.

Schnittstellen, die technisch grün sind und fachlich falsch liefern

Eine Schnittstelle kann technisch fehlerfrei sein — keine Exceptions, keine Timeouts, grüne Logs — und trotzdem fachlich falsch liefern. Wenn ein Pflichtfeld immer gesetzt ist, aber manchmal den falschen Wert trägt, merkt das kein Monitoring. Das merkt erst der Sachbearbeiter, wenn eine Rechnung mit dem falschen Kundennamen rausgeht oder ein Auftrag der falschen Kostenstelle zugeordnet wurde.

Fachliche Validierung ist deshalb kein Nice-to-have. Sie gehört in die Schnittstelle — nicht ins manuelle Nacharbeiten.

Was man konkret tun kann

Kein Patentrezept, aber Maßnahmen, die in der Praxis einen messbaren Unterschied machen:

Datenanalyse vor der Konzeptionsphase: Einen echten Datenauszug des Altsystems anfordern und analysieren, bevor irgendein Screen designt wird. Was ist tatsächlich drin? Welche Felder sind leer, welche inkonsistent, welche im Format variierend? Diese Analyse kostet wenig und spart viel.
Schnittstellenvertrag schriftlich: Format, Takt, Feldbelegung, Validierungsregeln und Fehlerbehandlung zwischen beiden Systemen schriftlich festhalten — mit Unterschrift beider Dienstleister. Nicht mündlich besprochen und im nächsten Meeting vergessen.
Fachlichen Daten-Eigentümer benennen: Eine konkrete Person im Unternehmen, die für Klärungen bei Datenqualitätsfragen zuständig ist und Entscheidungen treffen darf — und nicht jede Rückfrage erst durch drei Hierarchieebenen eskalieren muss.
Migrationslauf früh mit echten Daten: Nicht erst kurz vor Go-live mit Produktionsdaten starten. Je früher ein echter Datensatz durch die Pipeline läuft, desto früher tauchen Überraschungen auf — zu einem Zeitpunkt, an dem sie noch handhabbar sind.
Parallelbetrieb zeitlich begrenzen: Wenn Altsystem und neues System gleichzeitig laufen, braucht es eine klare Regel, welches System führend ist — und ein verbindliches Enddatum für den Parallelbetrieb. Sonst läuft er unbegrenzt, und die doppelte Datenpflege wird zum Dauerzustand.

Das eigentliche Thema ist Koordination

Die beschriebenen Probleme sind nicht neu — und sie treten nicht nur bei kleinen Unternehmen auf. Was sie verbindet: Sie entstehen an den Übergaben, nicht in den Systemen selbst. Zwischen Abteilungen, zwischen Dienstleistern, zwischen alten und neuen Prozessen.

Digitalisierung ist deswegen weniger ein Technologieprojekt als ein Koordinationsprojekt. Die Software lässt sich beschaffen. Die Klärung darüber, wer welche Daten verantwortet und in welchem Format sie wohin fließen — die lässt sich nicht abkürzen. Wer das früh ernst nimmt, hat eine deutlich bessere Chance, das Projekt in der Zeit zu halten, die dafür eingeplant war.

Mehr dazu, wie solche Fragen in der Praxis angegangen werden, findet sich auf innosirius.de.