Wenn die Demo stimmt und die eigenen Daten nicht

Was eine Demo verspricht und was echte Daten mitbringen

In der Demo sieht alles aus wie versprochen. Die Kundenliste lädt in Sekunden, die Adresse erscheint im richtigen Feld, der Auftrag landet automatisch beim richtigen Ansprechpartner. Was die Demo zeigt, stimmt — für die Daten, mit denen sie aufgebaut wurde.

Diese Daten hat jemand gepflegt. Jeder Eintrag hat eine Postleitzahl. Kein Name erscheint zweimal. Jede Kundennummer folgt demselben Muster. Die Kategorie „Gewerbe" heißt überall „Gewerbe", nicht in einem Export „Gew.", im nächsten „G" und im dritten gar nichts.

Eigene Daten sehen anders aus

Wenn Sie Ihre eigenen Daten in dasselbe System laden, zeigt sich, was die Demo verborgen hat. Ein Adressfeld, das in Ihrer alten Tabelle „Straße + Hausnummer" zusammen enthält, passt nicht in ein System, das beides getrennt verlangt. Ein Kundenname, der in Ihrer Verwaltung mal mit Anrede, mal ohne eingetragen wurde, erzeugt Dopplungen, die das neue System nicht erkennen kann. Eine Artikelnummer, die vor acht Jahren aus einem anderen Programm übertragen und seitdem nie bereinigt wurde, kommt im Import als Fehler zurück.

Das ist kein Vorwurf an den Anbieter. Die Demo zeigt ein funktionierendes System — und das tut sie auch richtig. Aber ein funktionierendes System mit Musterdaten ist etwas anderes als ein funktionierendes System mit Ihren Daten.

Worin der Unterschied liegt

In einer Demo entscheidet jemand, welche Daten hineingeladen werden. In der Realität entscheidet Betriebsgeschichte — eine Übernahme, ein Systemwechsel Mitte der Nuller, ein Mitarbeiter, der Felder anders befüllt hat als alle anderen, und eine Exportdatei, die seitdem niemand mehr angefasst hat.

Kundenadressen, die halbautomatisch aus einer Immobiliensoftware übertragen wurden und deshalb Sonderzeichen enthalten, die kein anderes Programm versteht
Projektbezeichnungen, die im Laufe der Jahre umbenannt wurden, in alten Einträgen aber noch unter dem früheren Namen stehen
Pflichtfelder, die in der alten Software mit Platzhaltern gefüllt wurden, weil sie leer nicht erlaubt waren — und die jetzt als echte Daten ankommen

Wer den Demo-Termin als Entscheidungsgrundlage nimmt, bewertet das System an Daten, die nicht seine sind. Die schwierigere Frage stellt sich erst danach: was das System mit dem kann, was das eigene Unternehmen über Jahre angesammelt hat. Diese Frage lässt sich in keiner Präsentation beantworten — nur im tatsächlichen Import.

Altsysteme und ihre Exportformate

Die meisten Unternehmen, die ein neues System einführen, haben irgendwo ein altes. Manchmal seit zehn Jahren, manchmal länger. Es läuft. Es enthält alles. Und es kann exportieren — das steht auf jeder Produktseite, und es stimmt auch. Die Frage ist, was dabei herauskommt.

Ein typischer Export aus einer Hausverwaltungssoftware der ersten Generation liefert eine Excel-Datei. Die Datei enthält Spalten, deren Namen nur jemand versteht, der damals dabei war, als das System eingerichtet wurde. „Feld37". „KNR_alt". „Bem2". Manchmal stehen Mietername und Adresse in einer einzigen Zelle, durch Komma getrennt — oder durch ein Semikolon, je nach Version. Manchmal fehlen Umlaute, weil der Export in einem Zeichensatz aus den 1990er-Jahren kodiert ist und das neue System damit nichts anfangen kann.

Das ist kein Versagen des alten Systems. Es hat getan, was damals nötig war. Aber das neue System erwartet etwas anderes: Vorname und Nachname in getrennten Feldern, Postleitzahl als eigene Spalte, Datumsangaben in einem einheitlichen Format. Die Demo zeigt diese Felder sauber befüllt. Was die Demo nicht zeigt, ist der Schritt davor.

Was beim Überführen wirklich fehlt

Häufige Stolperstellen beim Datenexport aus Altsystemen:

Adressen in einem Freitextfeld, das nie für maschinelle Weiterverarbeitung gedacht war
Kategorien und Bezeichnungen, die das alte System anders nennt als das neue — „Mieter", „Pächter", „Nutzer" als freier Text statt als wählbare Option
Datumswerte im Format TT.MM.JJJJ in einer Spalte, die das neue System als Text und nicht als Datum erkennt
Gelöschte Einträge, die im Export weiterhin auftauchen, weil das alte System nicht zwischen „archiviert" und „aktiv" unterschieden hat
Dokumente, die im alten System mit einem Datensatz verknüpft waren — und die im Export gar nicht auftauchen, weil sie separat gespeichert wurden

Wer diese Lücken erst beim ersten Testimport bemerkt, fängt die eigentliche Arbeit in diesem Moment an. Nicht vorher. Das alte System lässt sich nicht befragen, wie es seine Daten strukturiert hat — man sieht es erst, wenn man den Export aufmacht.

Besonders heikel ist die Situation, wenn das Altsystem gar keinen strukturierten Export bietet. Manche ältere Software gibt nur PDF-Berichte aus. Manche läuft auf einem Rechner, der seit Jahren nicht mehr ans Netz angeschlossen ist, weil das lange gereicht hat. In solchen Fällen beginnt die Datenübernahme nicht mit einem Klick auf „Exportieren", sondern mit der Frage, wer die Einträge manuell überträgt — und bis wann.

Wie lange das dauert, hängt davon ab, wie viele Datensätze es gibt, wie sauber sie über die Jahre gepflegt wurden und wie viel Bereinigung nötig ist, bevor das neue System sie annimmt. Diese Frage lässt sich vor dem Projekt kaum beantworten. Sie lässt sich nur beantworten, wenn man den Export aufmacht und schaut — und das ist ein Schritt, der in keiner Demo vorkommt.

Wenn kein Mensch zuständig ist

In den meisten Einführungsprojekten gibt es jemanden für die Technik, jemanden für die Schulung und jemanden für die Abnahme. Was es selten gibt, ist eine Person, die für die Daten selbst verantwortlich ist — nicht für die Übertragung, sondern für ihren Inhalt und ihre Richtigkeit.

Das fällt erst auf, wenn das neue System läuft und die ersten Unstimmigkeiten sichtbar werden. Ein Kunde taucht zweimal auf, einmal mit der alten Adresse, einmal mit der neuen. Ein Vorgang, der vor dem Umstieg angelegt wurde, fehlt im aktuellen Bestand. Eine Bezeichnung, die früher „Interessent" hieß, wurde beim Wechsel anders eingeordnet oder gar nicht. Wer korrigiert das?

Auf diese Frage antwortet meistens jeder mit dem Finger auf den anderen. Der Vertrieb verweist auf die IT, die IT auf den Anbieter, der Anbieter auf den vereinbarten Leistungsumfang. Das Ergebnis ist weder ein Fehler im Protokoll noch eine Lösung — es ist ein Zustand, der einfach bestehen bleibt.

Die Lücke zwischen Abschluss und Betrieb

Viele Einführungsprojekte enden am Tag des Go-live. Das System steht, die Daten sind eingespielt, das Ticket beim Anbieter ist geschlossen. Was danach kommt — neue Einträge, überholte Angaben, widersprüchliche Einträge aus zwei Quellen — liegt in einem Bereich, für den im Projekt keine Rolle vorgesehen war.

Typische Folgen, die sich in den Wochen danach einstellen:

Korrekturen werden lokal vorgenommen und nicht ins System übernommen — weil unklar ist, wer dafür zuständig wäre.
Fehler werden nicht gemeldet, weil niemand weiß, an wen.
Entscheidungen entstehen auf Basis von Daten, deren Aktualität niemand einschätzen kann.
Das Vertrauen in den Bestand sinkt, ohne dass darüber gesprochen wird.

Das System bleibt in Betrieb. Aber die Menschen, die damit arbeiten, wissen zunehmend nicht, ob das, was sie sehen, stimmt. Sie prüfen gegenzuprüfen — per Telefon, per Rückfrage, per eigenem Aufschrieb. Das kostet Zeit, und niemand bucht diese Zeit auf das Einführungsprojekt.

Die Frage, die vor dem Kauf selten gestellt wird

In der Demo war das kein Problem. Die Beispieldaten waren vollständig, eindeutig und gepflegt — vorbereitet von jemandem, der genau das zur Aufgabe hatte. Im eigenen Betrieb ist das die Frage, die beantwortet sein müsste, bevor ein neues System eingeführt wird: Wer bei uns hat die Aufgabe, für die Qualität dieser Daten zu sorgen? Nicht einmalig beim Start. Fortlaufend.

Wenn diese Frage offen bleibt, beantwortet sie sich nach einigen Wochen von selbst — durch den Zustand, in dem sich die Daten dann befinden.

Welche Arbeit nach der Einführung wirklich entsteht

Die Demo ist vorbei, der Vertrag unterschrieben, das System eingerichtet. Ab diesem Moment beginnt eine Arbeit, die vorher selten jemand benennt: die Arbeit, die eigenen Daten dazu zu bringen, sich so zu verhalten wie die Beispieldaten in der Präsentation.

Das fängt damit an, dass der Import nicht vollständig ist. Nicht weil das System schlecht wäre, sondern weil Kundendatensätze aus sechs Jahren nicht alle dieselbe Struktur haben. Manche Einträge fehlen ein Feld, das das neue System als Pflichtfeld führt. Andere haben ein Feld mehrfach belegt, weil früher jemand entschieden hatte, die zweite Telefonnummer dort einzutragen, wo eigentlich die Abteilung stehen sollte. Diese Einträge landen beim Import entweder gar nicht oder mit Lücken — und wer sie prüft, ist meistens dieselbe Person, die bereits das Tagesgeschäft führt.

Was dann auf dem Tisch landet

Eine Exportdatei mit mehreren Tausend Zeilen, in der eine Spalte drei verschiedene Formate enthält — alle korrekt nach den Regeln, die jeweils galten, als sie eingetragen wurden.
Adressen ohne Postleitzahl, weil das Ursprungssystem sie nicht als Pflichtfeld kannte.
Dopplungen, die im alten System nie aufgefallen waren, weil dort niemand danach gesucht hat.
Kundenvorgänge, die über mehrere Datensätze verteilt sind und jetzt zusammengeführt werden müssten — von Hand, weil kein Algorithmus weiß, welche Schreibweise die richtige ist.

Parallel dazu laufen Fragen auf, die niemand vorab gestellt hat. Welche Datensätze sind tatsächlich noch aktiv? Wer hat Zugriff auf was bekommen, und ist das so gewollt? Welche Auswertungen, die bisher täglich aufgerufen wurden, gibt es im neuen System in dieser Form nicht — und welche davon braucht man wirklich?

Der stille Mehraufwand

Was dabei entsteht, ist kein Projektfehler. Es ist die normale Folge davon, dass echte Betriebe über Jahre hinweg Daten auf eine Art gepflegt haben, die für die damaligen Abläufe funktioniert hat. Das neue System kennt diese Geschichte nicht. Es kennt nur seine eigenen Felder, seine eigenen Regeln, seine eigene Logik.

Der Aufwand, beides in Einklang zu bringen, fällt auf die Zeit nach der Einführung — nicht auf die Phase davor. Er ist schwer zu schätzen, weil er von der Qualität der eigenen Datenbasis abhängt, die man erst dann wirklich kennt, wenn man sie exportiert und sich anschaut. Viele Unternehmen erleben in dieser Phase, dass das neue System zwar läuft, aber noch nicht das tut, wofür es angeschafft wurde: verlässlich auf vollständigen, bereinigten Daten arbeiten.

Bis dahin laufen beide Systeme. Das alte, weil man ihm noch traut. Das neue, weil man investiert hat. Und irgendwo dazwischen liegt die eigentliche Arbeit.

Wenn zwei Systeme parallel laufen

Die Parallelphase gilt offiziell als Übergangszeit. In der Praxis ist sie oft der Moment, in dem sich entscheidet, ob eine Einführung gelingt oder langsam einschläft. Denn zwei Systeme gleichzeitig zu betreiben bedeutet nicht, dass man doppelte Sicherheit hat — es bedeutet, dass jede Eingabe zweimal gemacht werden muss, und dass niemand mehr sicher ist, welche Seite gerade stimmt.

Ein Maklerbüro, das neu auf ein Verwaltungssystem umstellt, führt die Bestandsobjekte zunächst weiterhin in der alten Tabelle — „nur bis alles übertragen ist". Gleichzeitig werden neue Anfragen bereits im neuen System erfasst. Nach sechs Wochen gibt es Objekte, die nur in der Tabelle stehen, Anfragen, die nur im neuen System liegen, und eine Handvoll Datensätze, die in beiden existieren, aber nicht übereinstimmen: unterschiedliche Ansprechpartner, unterschiedliche Status, unterschiedliche Preise.

Wer ist für welche Version zuständig?

Die Frage klingt einfach, aber in der Praxis gibt es selten eine klare Antwort. Wer die Anfrage entgegengenommen hat, pflegt sie vielleicht im neuen System. Wer das Objekt seit Jahren betreut, bleibt bei der Tabelle. Die Assistenz aktualisiert, was sie sieht — und sieht je nach Tag unterschiedliche Versionen. Das führt nicht zu Chaos, sondern zu etwas Schlimmerem: zu stillem Misstrauen gegenüber beiden Seiten.

Monatliche Berichte werden aus unterschiedlichen Quellen zusammengestellt, weil niemand weiß, welches System vollständiger ist.
Rückfragen von Kollegen landen beim falschen Ansprechpartner, weil der Datensatz im neuen System einen anderen Namen trägt.
Kunden erhalten widersprüchliche Aussagen, weil zwei Mitarbeitende dieselbe Anfrage in zwei verschiedenen Systemen nachgeschlagen haben.

Die Parallelphase war für zwei Wochen geplant. Vier Monate später läuft das alte System noch, weil niemand das Risiko eingehen will, den Stecker zu ziehen — solange nicht klar ist, ob wirklich alles übertragen wurde.

Was in dieser Zeit wirklich passiert

Das neue System wird nicht vollständiger, weil parallel gearbeitet wird. Es wird unvollständiger — relativ zur alten Umgebung, die täglich weiter befüllt wird. Jede Woche, in der beide Seiten aktiv sind, wächst der Abstand zwischen dem, was übertragen wurde, und dem, was seither hinzugekommen ist. Die Übertragung, die eigentlich abgeschlossen werden sollte, wird schwieriger, nicht einfacher.

Und weil der Aufwand steigt, sinkt die Bereitschaft, ihn anzugehen. Die Parallelphase endet dann nicht mit einer bewussten Entscheidung, sondern damit, dass irgendwann nur noch das alte System benutzt wird — und das neue still als Fehlinvestition abgeschrieben.