Wenn das neue System die alten Daten nicht kennt

Was beim Systemwechsel wirklich Zeit kostet

Die eigentliche Arbeit beginnt nicht am Einführungstag. Sie beginnt in den Wochen davor, wenn jemand anfängt, die alten Daten anzuschauen — und merkt, dass sie nicht so sind, wie erwartet.

In den meisten Betrieben gibt es Datenbestände, die über Jahre gewachsen sind. Kundenadressen, die mehrfach angelegt wurden. Felder, die unterschiedlich befüllt wurden, je nachdem wer gerade am System war. Kategorien, die irgendwann eingeführt und nie konsequent gepflegt wurden. Das ist kein Versagen — das ist der Alltag eines wachsenden Unternehmens.

Aber wenn diese Daten in ein neues System sollen, wird sichtbar, was vorher unsichtbar war. Und jemand muss entscheiden: Was übernehmen wir? Was bereinigen wir zuerst? Was lassen wir zurück?

Die Bestandsaufnahme, die niemand eingeplant hat

Wer ein neues System einführt, plant meistens die Einführung — nicht die Vorbereitung. Die eigentliche Zeitinvestition liegt aber dort: in der Durchsicht von Daten, die seit Jahren niemand geprüft hat. Ein Kundenstamm mit 4.000 Einträgen, von denen 600 doppelt sind und 300 keine gültige Adresse mehr haben.

Das ist keine Stunde Arbeit. Das ist eine Aufgabe, die über Wochen verteilt läuft — oft neben dem normalen Tagesgeschäft, oft ohne eine klare Verantwortung.

Welche Felder sind im alten System Pflicht, im neuen optional — und was fehlt dann?
Welche Bezeichnungen wurden über die Jahre umbenannt, ohne dass die alten Einträge angepasst wurden?
Wer entscheidet, welcher von zwei doppelten Einträgen der richtige ist?

Diese Fragen klingen klein. Zusammen sind sie der Grund, warum Projekte, die für drei Monate geplant waren, nach sechs Monaten noch laufen.

Was den Übergang in die Länge zieht

Ein weiterer Teil ist der Moment, in dem das neue System bereits eingerichtet ist — aber noch nicht vollständig genutzt werden kann. Nicht weil etwas fehlt, sondern weil die Daten, auf die es sich stützen soll, noch nicht vollständig übertragen oder noch nicht geprüft sind.

In dieser Phase wird oft parallel gearbeitet: das alte System läuft weiter, das neue wird befüllt, und irgendwo dazwischen liegt die Frage, welchem der beiden man vertrauen soll, wenn sie unterschiedliche Stände zeigen. Das kostet nicht nur Zeit — es kostet Entscheidungssicherheit.

Manche Betriebe merken erst in dieser Phase, dass bestimmte Auswertungen, die sie im alten System gewohnt waren, im neuen so nicht mehr möglich sind. Nicht weil das neue System schlechter ist, sondern weil die Datenstruktur eine andere ist. Die gewohnte Jahresübersicht lässt sich nicht mehr auf Anhieb aufrufen. Die Verteilung nach Region ist plötzlich umständlich. Jemand muss lernen, wie es jetzt geht — und das passiert meistens unter Zeitdruck, während Anfragen hereinkommen und Termine laufen.

Der stille Aufwand, der in keinem Projektplan steht

Was fast immer unterschätzt wird: die Rückkopplungen. Ein Mitarbeiter stellt fest, dass ein Wert im neuen System nicht stimmt. Er fragt nach. Es stellt sich heraus, dass das Feld beim Export anders befüllt wurde als angenommen. Das wird korrigiert — aber die Korrektur zieht weitere Prüfungen nach sich. Nicht weil jemand einen Fehler gemacht hat, sondern weil beim Übertragen von einem System in ein anderes Annahmen sichtbar werden, die vorher nie ausgesprochen wurden.

Wie ein Objekt kategorisiert ist. Ob ein Datum das Eingangsdatum oder das Abschlussdatum meint. Ob eine Zahl inklusive oder exklusive einer bestimmten Position gerechnet wurde. Diese Fragen kosten keine großen Stunden einzeln — aber sie summieren sich. Und sie kommen meistens dann, wenn man eigentlich schon fertig sein wollte.

Das Problem mit den Daten, die niemand angefasst hat

Wenn ein neues System eingeführt wird, beginnt irgendwann das Gespräch über die Altdaten. Meistens später, als es sinnvoll wäre. Und dann stellt sich heraus, dass niemand genau weiß, in welchem Zustand sie sind.

Das liegt nicht daran, dass die Daten schlecht gepflegt wurden. Es liegt daran, dass das alte System gelernt hat, mit ihnen umzugehen. Es hat Fehlstellen still übergangen. Es hat Lücken mit Standardwerten gefüllt, die irgendwann eingetragen wurden und nie wieder hinterfragt wurden. Es hat funktioniert — und das war genug.

Das neue System weiß das nicht. Es erwartet vollständige Adressen, eindeutige Kundennummern, einheitliche Schreibweisen. Was das alte System als "München" gespeichert hat und was ein anderer Mitarbeiter als "Muenchen" eingetragen hatte, sind für das neue System zwei verschiedene Orte. Was früher einfach "Herr Meier" war, braucht jetzt einen Vor- und einen Nachnamen in getrennten Feldern — aber die Trennung hat niemand vorgenommen, weil es nie nötig war.

Was dann sichtbar wird

Erst wenn die Daten in das neue System wandern sollen, zeigt sich, was wirklich vorhanden ist. Datensätze ohne Pflichtfelder. Felder, die jahrelang mit Freitext befüllt wurden, weil das Auswahlfeld nicht das Richtige enthielt. Einträge, die doppelt vorhanden sind, weil ein Kollege sie neu angelegt hat, statt die vorhandene Version zu suchen. Kundendaten, die ein ehemaliger Mitarbeiter als einziger kannte und die seit seinem Weggang nicht mehr berührt wurden.

Adressen, die aus einem handschriftlichen Fax übertragen wurden und nie geprüft worden sind
Vertragsnummern, die nach einem Systemwechsel vor acht Jahren doppelt vergeben wurden
Kontaktpersonen, die seit Jahren nicht mehr in diesem Unternehmen arbeiten
Kategorien, die im alten System existierten und im neuen keine Entsprechung haben

Keiner dieser Einträge hat jemals einen Fehler verursacht. Im alten System. Dort wusste man, wie man damit umgeht — aus Erfahrung, aus Gewohnheit, aus dem kollektiven Gedächtnis eines Teams, das gelernt hat, was die Daten wirklich bedeuten, auch wenn sie das nicht vollständig abbilden.

Die Frage nach der Zuständigkeit

Wer soll die Daten bereinigen? Das ist keine technische Frage. Es ist eine Frage nach Zeit, nach Wissen und nach Verantwortung — und alle drei sind in einem laufenden Betrieb knapp.

Die Person, die den Kunden kennt, führt gerade Besichtigungen durch. Die Person, die das alte System gebaut hat, ist nicht mehr im Unternehmen. Die Person, die den Auftrag für das neue System gegeben hat, hat eine Deadline und keinen Puffer. Und so landet die Datenbereinigung dort, wo sie immer landet: als Aufgabe, die "nebenbei" erledigt werden soll, von jemandem, der den Kontext nicht vollständig kennt.

Was dabei entsteht, sind bereinigte Daten, die formal korrekt sind — und inhaltlich ein Stück weit weniger verlässlich als vorher. Nicht weil jemand nachlässig war. Sondern weil Datenpflege Zeit braucht, die im Projektplan nicht vorgesehen war.

Wenn zwei Systeme nebeneinander laufen — und keines dem anderen traut

Es gibt eine Phase in fast jedem Systemwechsel, die offiziell „Parallelbetrieb" heißt und im Projektplan zwei bis vier Wochen dauern soll. In der Praxis zieht sie sich. Drei Monate nach dem geplanten Abschluss läuft das alte System noch, weil irgendjemand darauf besteht, dass „nur für den Notfall" — und weil dieser Notfall tatsächlich eingetroffen ist, einmal, und niemand vergessen hat.

Das eigentliche Problem ist nicht, dass zwei Systeme gleichzeitig laufen. Es ist, dass die Daten in beiden nicht mehr identisch sind. Das alte System wurde nach dem Stichtag noch einmal angefasst. Jemand hat eine Adresse korrigiert, einen Auftrag nachgetragen, eine Notiz ergänzt. Das neue System weiß davon nichts. Jetzt gibt es zwei Versionen der Wahrheit, und keine trägt eine Markierung, die sagt, welche stimmt.

Die tägliche Entscheidung, die niemand treffen will

Wer mit beiden Systemen arbeitet, lernt schnell: Man schaut in das eine, zweifelt, schaut in das andere, vergleicht — und wählt dann die Version, die plausibler klingt. Das ist kein Prozess, das ist Schätzung. Bei einer Kundenadresse mag das folgenlos bleiben. Bei einem offenen Betrag oder einem vereinbarten Termin nicht.

Typische Situationen aus diesem Stadium:

Eine Mitarbeiterin trägt Neukunden in beide Systeme ein, weil sie nicht weiß, ob die Übergabe vollständig abgeschlossen ist.
Ein Kollege verlässt sich auf das alte System für Bestandskunden und nutzt das neue nur für alles ab dem Wechseldatum — ohne dass das abgesprochen wäre.
Die Buchhaltung zieht ihre Zahlen aus dem alten System, der Vertrieb aus dem neuen. Beide Auswertungen stimmen intern, aber sie ergeben zusammen kein Bild.

Keiner dieser drei macht etwas falsch. Jeder reagiert rational auf eine Situation, in der die Spielregeln nicht festgelegt wurden.

Wenn der Parallelbetrieb endet, ohne dass jemand es bemerkt

Irgendwann wird das alte System abgeschaltet — oder es läuft einfach weiter, wird aber nicht mehr aktiv gewartet. Die Daten, die nur dort stehen, bleiben dort. Manchmal fällt das erst auf, wenn jemand einen Kunden sucht, der seit Jahren nicht mehr aktiv war, und im neuen System leer ausgeht. Manchmal fällt es nie auf. Beides ist ein Problem, nur das zweite ist das stillere.

Die Frage, die in diesem Stadium selten gestellt wird: Wer ist verantwortlich dafür, dass die Daten im neuen System vollständig sind — nicht technisch vollständig, sondern inhaltlich? Wer prüft, ob eine Adresse stimmt, ob ein Vertrag korrekt übertragen wurde, ob eine Notiz, die jemand vor drei Jahren handschriftlich in das alte System getippt hat, irgendwo im neuen auftaucht?

Diese Frage landet meistens bei niemandem. Und das ist nicht Nachlässigkeit — es ist das Ergebnis davon, dass sie beim Projektstart nicht gestellt wurde.

Zuständigkeiten, die bei der Einführung nicht geklärt waren

Die Software läuft. Der Anbieter hat übergeben, der Projektbetreuer verabschiedet sich mit einem Abschlussprotokoll. Was danach fehlt, steht in keiner Rechnung: wer jetzt für was zuständig ist.

In vielen Betrieben ist das nie explizit entschieden worden. Die Einführung konzentrierte sich auf das, was sichtbar ist — auf Oberflächen, Zugänge, erste Schulungen. Wer die Kundendaten künftig pflegt, wer Änderungen freigibt, wer entscheidet, wenn zwei Einträge voneinander abweichen: das blieb offen. Nicht aus Nachlässigkeit, sondern weil diese Fragen im Projektstress als selbstverständlich galten.

Wenn alle zuständig sind, ist niemand zuständig

Das Ergebnis sieht meist so aus: Die Buchhaltung pflegt Kundenadressen im Abrechnungsprogramm, der Vertrieb in einer eigenen Liste, die Assistentin im neuen Tool. Drei Stellen, drei Versionen — und sobald ein Brief zurückkommt oder eine Rechnung falsch adressiert ist, beginnt die Suche, welche Fassung stimmt.

Niemand hat das absichtlich falsch gemacht. Es hat nur nie jemand gesagt: Diese eine Stelle ist die Quelle. Alle anderen schauen dort nach.

Entscheidungen, die vertagt wurden

Manche Zuständigkeitsfragen wurden während der Einführung bewusst offengelassen — weil man sich nicht einigen konnte, weil die Zeit fehlte oder weil man hoffte, sie würden sich von selbst klären. Sie klären sich nicht. Sie entstehen neu bei jedem Vorgang, der die ungeklärte Stelle berührt.

Wer darf Stammdaten ändern — und wer nicht?
Was passiert, wenn ein Mitarbeiter das Unternehmen verlässt: Wer übernimmt seine Einträge?
Wer wird informiert, wenn ein Datensatz gelöscht wird?
Welche Version gilt, wenn Altdaten und neue Eingaben einander widersprechen?

Diese Fragen klingen klein. In der Praxis entscheiden sie, ob das neue System nach einem Jahr noch das ist, was es beim Start war — oder ob es zu einem weiteren Ort geworden ist, den niemand mehr vollständig überblickt.

Das stille Parallelsystem

Häufig entsteht in solchen Situationen ein Behelfsweg: Eine Kollegin führt eine eigene Tabelle, weil sie dem neuen System nicht traut. Ein Abteilungsleiter leitet weiterhin Mails mit Rohdaten weiter, weil er keinen Überblick hat, was davon tatsächlich eingegangen ist. Das sind keine Fehler einzelner Menschen — es sind Anzeichen dafür, dass die Einführung die Frage der Verantwortung nicht beantwortet hat.

Solange das ungeklärt bleibt, arbeiten Menschen in zwei Systemen gleichzeitig. Das kostet Zeit — aber das eigentliche Problem ist ein anderes: Es ist nicht mehr erkennbar, welche Seite die verlässliche Grundlage für eine Entscheidung ist. Wer eine Offerte schreibt, wer ein Angebot nachfasst, wer eine Mahnung versendet — alle handeln nach bestem Wissen. Aber nach welchem Stand?

Was bleibt, wenn das Projekt abgeschlossen ist

Der Projektabschluss ist ein Datum, kein Zustand. Das System ist live, die Einführungsphase ist offiziell beendet, die Dienstleister haben abgerechnet. Was bleibt, ist oft das, worüber vorher nicht gesprochen wurde.

In vielen Unternehmen läuft das alte System still weiter — nicht weil jemand es beschlossen hat, sondern weil es Daten enthält, die ins neue nie übertragen wurden. Nicht aus Nachlässigkeit, sondern weil der Aufwand während der Einführung zu groß war und weil die Entscheidung, ob diese Bestände überführt werden sollen oder nicht, nie wirklich getroffen wurde. Jetzt sind sie eingefroren: zu alt, um sie zu ignorieren; zu unstrukturiert, um sie einfach zu übernehmen.

Mitarbeiterinnen und Mitarbeiter, die seit Jahren mit dem alten System arbeiten, wissen, wo die Ausnahmen liegen. Sie kennen die Kunden, deren Adresse in zwei Feldern steht. Sie wissen, welche Kategorie nur deshalb existiert, weil 2019 jemand etwas falsch angelegt hat. Dieses Wissen war nie aufgeschrieben. Nach dem Projektabschluss ist es das einzige, was den Betrieb noch zusammenhält — solange diese Personen da sind.

Die stille Parallelführung

Was häufig entsteht, ist keine saubere Ablösung, sondern eine stille Parallelführung. Neue Vorgänge laufen im neuen System. Alles, was vorher war, bleibt im alten. Auswertungen, die beide Zeiträume abdecken sollen, müssen aus zwei Quellen zusammengesetzt werden — von Hand, in einer Tabelle, von jemandem, der das Verfahren kennt.

Nach einem Jahr ist dieses Verfahren so selbstverständlich, dass es niemand mehr hinterfragt. Nach zwei Jahren weiß die Hälfte der Belegschaft nicht mehr, dass das alte System überhaupt noch läuft.

Berichte, die intern verlässliche Zahlen zeigen — aber nur, weil jemand die Lücke jeden Monat von Hand schließt
Kundenanfragen zu älteren Vorgängen, die im neuen System schlicht nicht auffindbar sind
Neue Kolleginnen und Kollegen, die in der Einarbeitung nur das neue System kennenlernen und später ohne Vorwarnung mit dem alten konfrontiert werden

Die Frage, die kein System beantwortet

Es geht nicht darum, dass Systeme fehlerhaft sind. Es geht darum, dass ein Systemwechsel zwei Fragen aufwirft, die nicht das System beantworten kann: Was soll mit dem, was vorher war, passieren? Und wer ist dafür zuständig, wenn das Projekt längst abgeschlossen ist?

Wenn diese Fragen während der Einführung nicht gestellt wurden, stellen sie sich danach — leiser, aber mit mehr Konsequenz. Dann ist kein Projektteam mehr da, das Antworten gibt. Und das Datum auf dem Abschlussbericht hilft dabei nicht weiter.