Wenn das neue System läuft und die Daten trotzdem fehlen

Das System läuft — aber die Daten stimmen nicht

Irgendwann in den ersten Wochen nach dem Umstieg passiert es. Jemand öffnet einen Datensatz, will eine Adresse nachschlagen oder den letzten Kontakt mit einem Kunden prüfen — und das Feld ist leer. Oder es steht etwas drin, das nicht stimmt. Eine Postleitzahl aus dem alten Export, die das neue System falsch zugeordnet hat. Ein Datum, das sich um einen Tag verschoben hat. Ein Name, der zusammengewachsen ist, weil das Quellformat keine Trennung zwischen Vor- und Nachname kannte.

Das ist keine Kleinigkeit. Für jemanden, der täglich mit diesen Daten arbeitet, ist jeder Fehler eine Unterbrechung: nachschlagen, korrigieren, weitermachen. Multipliziert über hundert Einträge verliert diese Unterbrechung ihren Status als Ausnahme.

Das Tückische ist, dass der Fehler nicht aus dem System kommt. Er kommt aus dem Übergang. Daten, die über Jahre in einem Programm gepflegt wurden, tragen die Logik dieses Programms in sich. Sie passen in die Felder, die dort vorgesehen waren. Das neue System hat andere Felder, eine andere Struktur, manchmal eine andere Vorstellung davon, was eine vollständige Adresse oder ein vollständiger Auftrag ist. Der Import läuft durch, ohne eine Fehlermeldung — weil technisch gesehen kein Fehler passiert ist. Was verloren gegangen ist, merkt man erst, wenn man konkret nachschaut.

Was während des Projekts weitergewachsen ist

Hinzu kommt, was in der Einführungsphase selbst entstanden ist. Eine Systemumstellung dauert Monate. In dieser Zeit wurde im alten System weitergearbeitet: neue Kunden angelegt, neue Aufträge erfasst, Notizen ergänzt. Einiges davon ist in die Nachführung eingeflossen, einiges nicht. Welches genau, weiß am Ende niemand mehr mit Sicherheit.

Das Ergebnis ist kein klarer Datenfehler, den man beheben kann. Es ist eine Unschärfe, die sich durch den gesamten Bestand zieht. Eine Kundin, die seit zwei Jahren im System ist, hat vielleicht eine Adresse, die noch aus dem Export stammt und seitdem nie aktualisiert wurde. Ein Auftrag trägt ein Datum, das nicht mit dem tatsächlichen Abschluss übereinstimmt, weil er kurz vor der Migration angelegt und kurz danach abgeschlossen wurde — und die beiden Systeme das unterschiedlich gehandhabt haben.

Die stille Mehrarbeit, die niemand einplant

Was dann folgt, ist kein Systemproblem mehr. Es ist eine Arbeit, die in der ursprünglichen Projektplanung schlicht nicht vorgekommen ist: Datensatz für Datensatz prüfen, abgleichen, ergänzen. Nicht weil die Einführung gescheitert ist. Sondern weil der Übergang selbst — mit seinen Formaten, Zuständigkeiten und Lücken — unterschätzt wurde.

Viele Unternehmen merken das erst, wenn sie das erste Mal eine Auswertung aus dem neuen System ziehen und die Zahlen nicht mit dem übereinstimmen, was sie im Kopf haben. Das System läuft. Die Daten erzählen nur nicht mehr die richtige Geschichte.

Warum Exportformate mehr Arbeit erzeugen als der Umstieg selbst

Wer ein neues System einführt, rechnet mit dem Aufwand für die Einrichtung, die Schulung, die ersten Wochen der Umgewöhnung. Was die meisten nicht einplanen: die Wochen, die damit vergehen, Daten aus dem alten System in eine Form zu bringen, die das neue überhaupt lesen kann.

Das alte System exportiert. Das neue importiert. Klingt nach einem Vorgang. In der Praxis ist es ein Projekt für sich.

Was eine CSV-Datei über das alte System verrät

Fast jede Fachsoftware bietet einen Datenexport an — meistens als CSV, manchmal als Excel, gelegentlich in einem Format, das nur die eigene Branche kennt. Die Datei landet auf dem Schreibtisch und sieht auf den ersten Blick vollständig aus. Erst beim genauen Hinsehen zeigt sich, was fehlt.

Spaltenbezeichnungen stimmen nicht mit den Feldern im neuen System überein.
Datumsangaben sind mal als „15.03.2023", mal als „2023-03-15", mal als „15/03/23" gespeichert — in derselben Datei.
Kundennummern, die im alten System eindeutig waren, tauchen im Export doppelt auf, weil eine Niederlassung anders nummeriert hat.
Felder, die im alten System als Freitextfeld geführt wurden, enthalten Informationen, für die das neue System drei separate Felder vorsieht.
Sonderzeichen — Umlaute, Bindestriche, Klammern — sind in einem Zeichensatz gespeichert, den das neue System nicht versteht.

Jedes dieser Probleme für sich ist lösbar. Zusammen bedeuten sie, dass jemand die Datei öffnet, bereinigt, testet, wieder öffnet und von vorn anfängt — nicht einmal, sondern für jeden Datensatztyp, den das alte System kannte.

Das Sonderfeld, das keine Entsprechung hat

Noch aufwendiger wird es bei Feldern, die das alte System über Jahre hinweg aufgenommen hat, ohne dass das je dokumentiert worden wäre. Notizfelder, in denen Sachbearbeiterinnen und Sachbearbeiter über Jahre Informationen gepflegt haben, die nirgendwo anders stehen. Kategoriensysteme, die jemand vor acht Jahren eingerichtet hat und die heute niemand mehr vollständig erklären kann.

Diese Felder tauchen im Export auf. Im neuen System gibt es für sie keine direkte Entsprechung. Entweder werden sie verworfen — mit allem, was darin stand — oder es wird eine Behelfsstruktur gebaut, die das neue System eigentlich nicht vorgesehen hat.

Beides kostet Zeit. Beides wird meistens erst entschieden, wenn der Importversuch schon einmal gescheitert ist.

Wann der Aufwand sichtbar wird

Das Schwierige an Exportformaten ist, dass der eigentliche Aufwand erst dann sichtbar wird, wenn das neue System schon steht. Die Einführung ist abgeschlossen, die Schulung ist gelaufen, die Lizenzen laufen — und dann beginnt die eigentliche Arbeit: herauszufinden, warum der Datenimport beim dritten Anlauf immer noch abbricht und welche Zeile in der Exportdatei dafür verantwortlich ist.

Wer das zum ersten Mal erlebt, fragt sich, ob das bei anderen Unternehmen genauso läuft. Die Antwort ist: meistens schon.

Altsysteme, die niemand abschalten kann

In vielen Unternehmen läuft das neue System bereits produktiv — und das alte läuft daneben. Nicht weil niemand es abschalten möchte, sondern weil sich herausstellt, dass das nicht so einfach geht.

Das fängt oft mit einer Kleinigkeit an: Ein Mitarbeiter erinnert sich, dass ein bestimmter Bericht aus dem alten System kommt. Nicht aus dem neuen — das lässt so etwas nicht ohne Weiteres exportieren. Also bleibt das alte offen, vorerst.

Dann kommt die nächste Kleinigkeit: Eine Buchhalterin, die seit zwölf Jahren mit dem alten System arbeitet, braucht für die Jahresabschlüsse Daten in einem Format, das nur das alte System ausgibt. Nicht weil das neue es nicht könnte, sondern weil noch niemand die Zeit hatte, das einzurichten.

Dann stellt sich heraus, dass bestimmte Kundenstammdaten nur im alten System gepflegt wurden, weil die Übertragung zum Zeitpunkt der Einführung „noch nicht final war".

Drei Monate nach der offiziellen Einführung gibt es zwei Systeme, die beide als aktuell gelten. Welches davon stimmt, hängt davon ab, wen man fragt.

Wie das in der Praxis aussieht

Ein Maklerbüro führt Objektdaten im neuen Verwaltungssystem, aber Besichtigungstermine im alten Kalender — weil die Synchronisation noch aussteht.
Eine Hausverwaltung hat Eigentümerinformationen nicht vollständig übertragen, weil Sondervereinbarungen im alten System in einem Freitextfeld standen, das sich nicht sauber überführen ließ.
Ein Handwerksbetrieb pflegt Kundenadressen in beiden Systemen parallel, weil niemand entschieden hat, welches davon führt.
Ein Steuerberater nutzt das neue Mandantenportal für neue Vorgänge, das alte aber für alles, was vor dem Stichtag angelegt wurde — weil eine rückwirkende Migration zu aufwendig erschien.

Dahinter steckt keine Nachlässigkeit. Das ist Pragmatismus unter Zeitdruck. Das neue System sollte die Arbeit erleichtern; stattdessen kommen Fragen hinzu, die vor der Einführung niemand gestellt hatte.

Besonders heikel wird es, wenn das alte System nicht mehr offiziell gewartet wird, aber trotzdem noch läuft. Lizenzen laufen still weiter, Sicherheitsupdates kommen nicht mehr, und niemand weiß genau, wer beim Anbieter noch Ansprechpartner ist. Abschalten kann man es trotzdem nicht — weil die Daten darin noch gebraucht werden.

Die eigentliche Frage ist nicht technischer Natur. Sie lautet: Wer im Unternehmen entscheidet, welche Daten ab wann nur noch an einer Stelle gepflegt werden — und wer trägt die Konsequenzen, wenn das falsch eingeschätzt wird?

Solange diese Frage offen bleibt, bleibt das alte System in Betrieb. Nicht als Altlast, sondern als Rückversicherung gegen eine Entscheidung, die noch niemand getroffen hat.

Wer ist für die Daten zuständig, wenn das Projekt abgeschlossen ist?

In den meisten Projekten gibt es einen Moment, in dem die Einführung offiziell als abgeschlossen gilt. Das System läuft, die Abnahme ist unterschrieben, das Projektteam löst sich auf. Was danach kommt, ist selten Teil des Plans.

Die Frage, wer die Daten im neuen System pflegt, wird oft erst dann gestellt, wenn etwas fehlt. Ein Datensatz ist falsch, ein Eintrag fehlt, ein Wert wurde beim Umzug irgendwie verdoppelt. Dann beginnt die Suche: Wer war damals zuständig? Wer hat die Tabelle befüllt? Wer weiß, wie das im alten System gemeint war?

Meistens gibt es keine klare Antwort — nicht weil niemand Verantwortung übernehmen will, sondern weil Datenzuständigkeit im Projekt nie explizit vergeben wurde. Das Projektteam hat die Einführung begleitet. Aber wer danach Eigentümer der Daten ist, stand in keiner Aufgabenbeschreibung.

Die drei häufigsten Lücken

Der Projektverantwortliche ist nicht mehr im Unternehmen. Die Nachfolgerin kennt die Herkunft der Daten nicht.
Zwei Abteilungen pflegen denselben Stammdatensatz — getrennt, ohne Abgleich.
Niemand weiß, ob die Kundendaten aus dem alten Export korrekt übernommen wurden, weil nie jemand einen systematischen Vergleich gemacht hat.

Das ist kein Versagen einzelner Personen. Es ist das Ergebnis einer Projektsystematik, die Einführung und Betrieb als zwei verschiedene Phasen behandelt — mit Übergabe an einem Datum, das nichts darüber aussagt, ob die Daten tatsächlich stimmen.

Ein konkretes Beispiel: Ein mittelständisches Unternehmen wechselt seine Kundenverwaltung. Die Übernahme der Daten läuft weitgehend reibungslos, die Abnahme ist positiv. Sechs Monate später stellt das Vertriebsteam fest, dass ein Teil der Kontakte doppelt angelegt ist — mit leicht abweichenden Adressdaten. Beide Versionen wurden seitdem gepflegt. Welche die richtige ist, kann niemand mehr sagen.

Der eigentliche Schaden ist nicht die doppelte Pflege. Er entsteht, wenn auf Basis dieser Daten Entscheidungen getroffen werden: Welche Kunden wurden kontaktiert? Welche nicht? Wie viele Adressen sind tatsächlich aktuell? Die Fragen lassen sich nicht mehr beantworten — nicht weil das System schlecht ist, sondern weil niemand zuständig war.

Was fehlt, ist keine Funktion — es ist eine Regelung

Datenzuständigkeit ist keine technische Frage. Kein System kann festlegen, wer dafür verantwortlich ist, dass ein Eintrag stimmt. Das ist eine organisatorische Entscheidung, die vor der Einführung getroffen werden muss — nicht danach, wenn der Druck des Projekts weg ist und alle wieder im Tagesgeschäft sind.

Das bedeutet konkret: Für jeden Bereich der Daten sollte feststehen, wer ihn pflegt, wer Fehler meldet und wer bei Widersprüchen entscheidet. Nicht als Bürokratie, sondern weil zwei Personen, die denselben Datensatz unabhängig voneinander aktualisieren, mit der Zeit unterschiedliche Wahrheiten entstehen lassen — und keine der beiden merkt es.

Viele Einführungsprojekte enden mit einer Schulung und einem Handbuch. Wer danach die Daten verantwortet, steht darin selten. Und wird deshalb mit der Zeit von niemandem mehr gefragt — bis wieder etwas fehlt.

Was aus einer Einführung eine Dauerbaustelle macht

Die meisten Projekte haben einen Go-live-Termin. Nur wenige haben ein klares Bild davon, was danach passiert. Das ist kein Versehen — es folgt einer Logik: Wer ein System einführt, denkt in Phasen. Planung, Umsetzung, Einführung. Danach beginnt der Betrieb, und der Betrieb gehört nicht mehr zur Projektlogik.

Was dann folgt, sieht von außen aus wie ein laufendes System. Es ist auch eines. Aber die Menschen, die damit arbeiten, wissen, dass etwas nicht stimmt. Sie haben eigene Listen geführt, um Lücken zu überbrücken. Sie haben Ausnahmen manuell nachgepflegt, weil der Import bestimmte Felder nicht sauber übernimmt. Sie erledigen Aufgaben auf zwei Wegen — einmal im neuen System, einmal auf dem alten, weil das alte noch nicht abgelöst ist.

Wenn der Übergangszustand zum Normalzustand wird

Übergangsregelungen, die für drei Wochen gedacht waren, halten sich manchmal ein Jahr. Nicht weil niemand daran denkt, sondern weil jeder Tag operative Arbeit bringt, die dringender erscheint als die Bereinigung. Die Tabelle, die als vorübergehende Brücke angelegt wurde, wächst. Sie bekommt Spalten, die jemand hinzufügt, weil das System sie nicht liefert. Sie bekommt eine Person, die sie pflegt. Irgendwann ist sie ein System.

Parallel dazu verändert sich, wie das offizielle System genutzt wird. Wer früh gemerkt hat, dass bestimmte Felder nicht verlässlich befüllt sind, hört auf, sie abzufragen. Abfragen, die keine brauchbaren Ergebnisse liefern, werden seltener gestellt. Seltener gestellt, seltener aktuell gehalten. Das Vertrauen in die Daten sinkt langsam, ohne dass ein Moment zu benennen wäre, an dem es begann.

Was die Einführung nicht entschieden hat

Häufig bleibt nach einem Projekabschluss offen, wie mit Ausnahmen umgegangen wird — Datensätzen, die nicht ins Schema passen, Vorgängen, die das neue System nicht kennt. In der Projektphase sind das Randfälle. Im Betrieb summieren sie sich zu einem erheblichen Teil der täglichen Arbeit.

Kunden, die unter mehreren Namen geführt werden, weil keine Deduplizierungsregel festgelegt wurde
Historische Vorgänge, die im alten Format vorliegen und nie überführt wurden
Felder, die unterschiedliche Teams unterschiedlich verstehen — und deshalb unterschiedlich befüllen
Berichte, die auf Daten basieren, die nur dann stimmen, wenn bestimmte Zwischenschritte manuell erledigt wurden

Keine dieser Fragen ist technischer Natur. Sie entstehen, weil Projekte eine Übergabelogik haben und Betrieb eine andere. Was in der Einführungsphase als Detail gilt, bestimmt danach den Alltag derer, die das System täglich benutzen.