Wenn Daten im Unternehmen ankommen, aber nicht stimmen

Warum das neue System die alten Daten nicht versteht

Wenn ein Unternehmen ein neues System einführt und die Daten aus dem alten übernimmt, entsteht häufig dasselbe Bild: Die Felder sind befüllt, die Zahlen stimmen, und trotzdem ist irgendetwas falsch. Einige Einträge fehlen, andere stehen an falscher Stelle, und manche sehen vollständig aus, sind es aber nicht.

Das liegt selten daran, dass der Übertrag technisch schief gelaufen ist. Es liegt daran, dass das alte System über Jahre hinweg stillschweigende Absprachen gespeichert hat — und das neue diese Absprachen nicht kennt.

Was das alte System wusste, ohne es zu sagen

Nehmen Sie ein einfaches Beispiel: Ein Kürzel im Kundenstatus. Im alten System steht bei einem Teil der Einträge „B", bei einem anderen „K", bei einigen nichts. Die Mitarbeiterin, die das System vor acht Jahren eingerichtet hat, weiß noch, was das bedeutet. Alle anderen nicht mehr. Das neue System soll „B" und „K" in eine Auswahlliste übersetzen — aber in welche?

Oder nehmen Sie Adressfelder. Im alten System gab es ein einziges Textfeld für „Ort". Manche haben dort „München" eingetragen, manche „80331 München", manche „München, Bayern". Das neue System erwartet getrennte Felder für Postleitzahl und Stadt.

Diese Situationen entstehen nicht durch Nachlässigkeit. Sie entstehen, weil Software immer dort angepasst wird, wo gerade Bedarf ist — und weil die Anpassungen selten dokumentiert werden. Nach zehn Jahren trägt das System ein Wissen, das nirgendwo aufgeschrieben steht.

Felder, die leer sein dürfen — und solche, die es nicht sein sollten

Ein weiteres Problem sind Pflichtfelder. Im neuen System ist die Branchenzuordnung eines Kontakts ein Pflichtfeld. Im alten war sie optional — und wurde bei einem Drittel der Einträge nie befüllt. Das neue System weist diese Einträge beim Import zurück, oder es befüllt das Feld mit einem Platzhalterwert, der später nie korrigiert wird.

Dieselbe Schwierigkeit entsteht bei Kategorien oder Statusangaben, die im Laufe der Zeit umstrukturiert wurden. Ein Eintrag, der 2014 unter einer Bezeichnung angelegt wurde, die heute nicht mehr existiert, passt in keine der aktuellen Auswahlmöglichkeiten. Er landet im Import irgendwo, oder er landet gar nicht.

• Datumsfelder, die als Freitext geführt wurden: „01.03.2019", „März 2019", „03/19" — drei Formate, ein Feld, kein einheitliches Ergebnis.
• Kundennummern, die einen internen Code enthalten, den das neue System als bedeutungslosen Text liest.
• Anredefelder, in denen „0", „1", „2" für Unternehmensform, Frau und Herr stehen — und „3" für eine Sonderlösung, die irgendwann einmal jemand eingebaut hat.

Es geht nicht darum, dass die Daten falsch sind. Im alten System waren sie richtig. Sie waren richtig für das System, in dem sie entstanden sind — mit seinen Feldern, seinen Konventionen, seinen ungeschriebenen Regeln. Das neue System hat andere Regeln. Und niemand hat je einen Übersetzungsschlüssel geschrieben.

Was in Exportdateien steckt, das niemand erwartet hat

Wenn ein altes System seine eigenen Daten ausgibt, sieht das auf den ersten Blick ordentlich aus. Eine Tabelle, tausende Zeilen, alle Spalten beschriftet. Das Gefühl trügt.

Die erste Überraschung kommt meist bei den Datumsangaben. Manche Einträge wurden mit Punkt getrennt, andere mit Bindestrich, wieder andere tragen ein vierstelliges Jahr, einige ein zweistelliges. Das alte System hat das immer klaglos verarbeitet — weil es nie auf ein einheitliches Format bestanden hat. Das neue System besteht darauf.

Was vor Jahren eingetragen wurde, steht heute noch drin

In einer exportierten Kundenliste finden sich regelmäßig Einträge, die zehn oder fünfzehn Jahre alt sind. Firmen, die längst nicht mehr existieren. Ansprechpersonen, die das Unternehmen verlassen haben. Adressen, die zweimal gespeichert wurden — einmal mit Abkürzung, einmal ausgeschrieben. Das alte System hat das nie beanstandet, weil es keine Regeln dafür hatte.

Hinzu kommen Felder, die im Laufe der Zeit ihren Zweck gewechselt haben. Eine Spalte, die ursprünglich für interne Notizen gedacht war, enthält heute Lieferadressen — weil jemand irgendwann keinen besseren Platz gefunden hat. Diese Entscheidung ist nirgends dokumentiert. Sie ist nur noch im Export sichtbar.

Zeichen, die das System nie beanstandet hat

Umlaute werden nicht überall gleich gespeichert. Ein System, das seit Jahren unter Windows läuft, gibt sie manchmal in einem Format aus, das ein anderes System als unleserliche Zeichenfolge einliest. Aus „Müller" wird dann „Müller". Das fällt nicht auf, wenn man nur stichprobenartig prüft — und stichprobenartig wird fast immer geprüft.

Ähnliches gilt für unsichtbare Leerzeichen am Anfang eines Felds und für Zeilenumbrüche, die innerhalb eines einzelnen Eintrags stecken. Im alten System war das folgenlos. Im neuen System bricht eine Zeile um, wo keine sein darf, und der Einlesevorgang schlägt fehl — ohne zu erklären, an welcher Stelle und warum.

• Pflichtfelder, die im alten System freiwillig waren und deshalb tausendfach leer geblieben sind
• Kundennummern, die als reine Zahl gespeichert wurden, obwohl sie Buchstaben enthalten sollten — und die das neue System deshalb nicht als Nummer erkennt
• Spalten, die im alten und im neuen System denselben Namen tragen, aber inhaltlich etwas anderes meinen
• Einträge, die doppelt vorhanden sind, weil zwei Abteilungen denselben Kontakt unabhängig voneinander angelegt haben

All das wäre im alten System nie aufgefallen. Es ist kein Fehler des Systems — es ist das Ergebnis davon, dass niemand je einen Grund hatte, genauer hinzuschauen. Der Export legt es offen. Und zwar in dem Moment, in dem die Zeit für eine gründliche Bereinigung bereits verplant ist.

Wer zuständig ist — und warum das niemand klar beantworten kann

Wenn ein Datensatz im neuen System falsch ist, beginnt meistens dieselbe Runde. Die Fachabteilung sagt, sie habe die Daten so übergeben, wie sie waren. Die IT sagt, sie habe das importiert, was ihr vorlag. Der Softwaredienstleister sagt, die Rohdaten seien Kundensache. Und das stimmt — formal betrachtet — alles.

Das Problem ist nicht, dass jemand lügt. Das Problem ist, dass niemand von Anfang an vereinbart hat, wer für Datenqualität zuständig ist. In den meisten Projekten gibt es eine Zuständigkeit für die Technik und eine für das Ergebnis. Was dazwischen liegt — die Frage, ob die Daten inhaltlich stimmen — fällt durch das Raster.

Die drei häufigsten Lücken

• Die IT übernimmt einen Export, ohne zu prüfen, ob die Inhalte plausibel sind — das ist auch nicht ihre Aufgabe.
• Die Fachabteilung prüft die Daten im neuen System erst Wochen nach dem Go-live, wenn sich Fehler schon fortgepflanzt haben.
• Der Dienstleister liefert ab, was vereinbart war — einen funktionierenden Import — aber nicht das, was alle erwartet hatten: saubere Stammdaten.

Ein Maklerunternehmen, das seine Objektverwaltung wechselt, weiß in der Regel, wer die Schlüssel übergibt und wer die Übergabe quittiert. Wer aber dafür verantwortlich ist, dass die Wohnflächen im neuen System mit den Unterlagen übereinstimmen — das steht in keiner Projektdokumentation.

Bei Hausverwaltungen sieht es ähnlich aus. Mietverträge, Bankverbindungen, Eigentümerstrukturen: Die Daten stammen aus verschiedenen Quellen, wurden über Jahre gepflegt — manchmal von einer Person, manchmal von mehreren, manchmal von niemandem mit einer klar benannten Verantwortung. Ein Systemwechsel legt diese Unschärfe nicht offen, er verstärkt sie.

Warum Zuständigkeit so schwer zu benennen ist

In kleineren Unternehmen weiß oft eine einzelne Person, wie die Daten wirklich sind — welche Felder verlässlich sind und welche seit Jahren nur geschätzt werden. Diese Person ist selten an der Projektplanung beteiligt. Sie wird gefragt, wenn etwas nicht stimmt, aber nicht, bevor das Projekt beginnt.

In größeren Unternehmen ist das Gegenteil das Problem: Zu viele Menschen haben an denselben Datensätzen gearbeitet, und niemand hat einen vollständigen Überblick. Wenn dann ein Fehler auftaucht, beginnt die Suche von vorn — wer hat das wann geändert, und warum.

Das lässt sich auch mit einer besseren Projektstruktur nicht vollständig lösen. Es ist ein strukturelles Merkmal von Daten, die über Jahre in der Praxis entstanden sind: Sie spiegeln Entscheidungen, Annahmen und Behelfe wider, die niemand mehr vollständig rekonstruieren kann. Wer im Projekt die Verantwortung für diese Daten übernehmen soll, muss zunächst verstehen, was er da eigentlich übernimmt.

Wenn Bereinigung länger dauert als die Einführung

Der Zeitplan im Angebot hatte für die Datenmigration eine Woche vorgesehen. Die Realität waren drei Monate — und am Ende waren trotzdem nicht alle Bestände vollständig überführt. Das neue System lief, aber ein Teil der Arbeit geschah weiterhin im alten, weil die bereinigten Daten dort noch fehlten.

Das ist kein Ausnahmefall. Es ist das häufigste Muster, das auftritt, wenn ein Betrieb langjährige Daten in eine neue Umgebung überträgt. Die technische Einführung dauert Wochen. Die Bereinigung des Bestands, der in dieser Umgebung landen soll, dauert länger — oft ein Vielfaches.

Warum der Aufwand erst sichtbar wird, wenn er anfängt

Solange Daten nur in ihrem Ursprungssystem gelesen werden, fallen viele Inkonsistenzen nicht auf. Ein Kundenname, der zweimal angelegt wurde. Eine Adresse, die nie aktualisiert wurde, weil die Änderung mündlich kam. Ein Artikel, der drei verschiedene Bezeichnungen trägt, je nachdem, wer ihn zuletzt bearbeitet hat.

Erst wenn diese Daten in ein neues System überführt werden, zeigt sich das Ausmaß. Das neue System erwartet ein Feld, das im alten nie gepflegt wurde. Oder es verweigert Einträge, die doppelt vorhanden sind. Was im Alltag funktioniert hat, weil alle wussten, welchen Datensatz sie meinen, wird jetzt zum Problem.

• Kundendaten, die über Jahre von verschiedenen Personen angelegt wurden, ohne einheitliche Schreibweise
• Artikel- oder Objektnummern, die in einer Tabelle existieren, in einer anderen aber fehlen
• Ansprechpartner, die dem falschen Unternehmen zugeordnet sind, weil ein Umzug nie nachgepflegt wurde
• Felder, die technisch befüllt sind, aber inhaltlich falsche oder veraltete Werte tragen

Jeder dieser Einträge muss geprüft werden — nicht vom System, sondern von einem Menschen, der die Zusammenhänge kennt. Das ist die Person, die ohnehin ausgelastet ist. Die Bereinigung kommt obendrauf.

Was das für den laufenden Betrieb bedeutet

Während die Bereinigung läuft, läuft der Betrieb weiter. Neue Daten entstehen täglich. Die bereinigten Bestände von gestern sind morgen schon wieder nicht mehr aktuell. Es gibt Momente, in denen ein Betrieb mit zwei parallelen Ständen arbeitet: dem alten, der noch gepflegt wird, und dem neuen, der noch nicht vollständig stimmt.

Der Aufwand dafür erscheint in keiner Projektzusammenfassung. Er wird von den Mitarbeiterinnen und Mitarbeitern getragen, die ihn neben ihrer eigentlichen Arbeit erledigen. Abends, zwischen Terminen, an Freitagnachmittagen. Wer den Fortschritt des Projekts von außen beurteilt, sieht das neue System laufen — und schließt daraus, dass die Einführung abgeschlossen ist.

Was übrig bleibt, wenn das Projekt abgenommen wurde

Das System ist eingeführt. Die Schulung hat stattgefunden. Der Dienstleister hat die Abnahme erhalten und seine Schlussrechnung gestellt. Auf dem Papier ist das Projekt abgeschlossen.

In der Praxis beginnt in diesem Moment oft ein anderes Kapitel — eines, das im Angebot nicht erwähnt wurde.

Die Lücken, die sich erst im Alltag zeigen

Wer in den ersten Wochen nach der Einführung genau hinschaut, findet in vielen Unternehmen dasselbe Bild: Das neue System läuft, aber daneben laufen auch die alten Listen weiter. Nicht aus Bequemlichkeit, sondern weil bestimmte Fragen, die vorher die Tabelle beantwortet hat, das neue System nicht beantworten kann — oder weil die Antworten dort nicht stimmen.

Eine Mitarbeiterin pflegt beide Stände parallel. Sie weiß, welche Einträge zuverlässig sind und welche man besser noch einmal nachschaut. Dieses Wissen liegt in ihrem Kopf, nicht im System. Wenn sie das Unternehmen verlässt, verlässt dieses Wissen das Unternehmen mit ihr.

Was aus dem Projektteam wird

Während der Einführung gibt es klare Zuständigkeiten: ein Projektleiter, ein externer Berater, vielleicht eine interne Projektbeteiligte. Nach der Abnahme löst sich dieses Gefüge auf. Die Berater sind abgezogen. Der interne Projektleiter hat sein altes Tagesgeschäft wieder übernommen.

Was bleibt, sind Fragen, die niemand eingeplant hat. Neue Mitarbeitende, die nicht geschult wurden. Prozesse, die sich verändert haben, seit die Anforderungen formuliert wurden. Daten, die nicht sauber eingeflossen sind und die jetzt in laufenden Auswertungen einen Fehler produzieren — einen kleinen, der deshalb so lange unbemerkt bleibt.

Berichte, denen niemand mehr traut

Nach einigen Monaten zeigt sich häufig ein bestimmtes Muster: Die Berichte aus dem neuen System werden nicht mehr unhinterfragt verwendet. Jemand hat einmal nachgerechnet und eine Abweichung gefunden. Seitdem prüft die Geschäftsführung Zahlen aus dem System gegen Zahlen, die anderswo gepflegt werden — in einer Tabelle, in einer E-Mail-Kette, in handschriftlichen Notizen vom letzten Quartal.

Das ist kein Zeichen von schlechter Technik. Es ist ein Zeichen davon, dass die Datenbasis, auf der das System aufgebaut wurde, nicht so vollständig und konsistent war, wie das Projekt vorausgesetzt hatte. Die Einführung hat dieses Problem nicht gelöst — sie hat es übernommen.

Was in solchen Situationen fehlt, ist meist nicht eine weitere Schulung oder ein weiteres Update. Es fehlt eine ehrliche Bestandsaufnahme dessen, was tatsächlich im System steht — und was bewusst oder unbewusst außen vor geblieben ist. Diese Frage stellt sich nach der Abnahme niemand mehr von Berufs wegen. Sie bleibt an denjenigen hängen, die täglich damit arbeiten.