Die Daten sind aktuell — sagt welches System?

Wenn das System korrekt ist und die Adresse trotzdem falsch

Es gibt Situationen, in denen der Fehler nicht im System liegt. Das System hat gespeichert, was es erhalten hat. Es hat die Adresse nicht erfunden und sie nicht verändert. Es zeigt genau das, was jemand irgendwann eingetragen hat — technisch gesehen ist alles in Ordnung.

Das Problem ist, dass es nicht das einzige System ist.

Eine Maklerin trägt die neue Anschrift eines Kunden in die Verwaltungsoberfläche ein. Der Kollege, der den Besichtigungsbrief verschickt, öffnet ein anderes Programm — eines, das für den Postversand besser eingerichtet ist. Dieses Programm kennt die Aktualisierung nicht. Es zeigt die Adresse von vor vier Monaten. Beide Angaben sind korrekt — im jeweiligen System.

Was hier passiert, ist kein Datenfehler im technischen Sinn. Es ist ein Synchronisationsproblem. Beide Systeme stimmen mit sich selbst überein. Sie stimmen nur nicht miteinander überein.

Wann eine Korrektur zur Quelle für den nächsten Fehler wird

Besonders schwierig wird es, wenn ein Datensatz in mehreren Systemen gleichzeitig gepflegt wird. Eine Adressänderung wird in System A eingetragen. Wenige Tage später wird in System B eine andere Angabe desselben Datensatzes aktualisiert — die Telefonnummer, der Ansprechpartner, ein Notizfeld. Beim nächsten Abgleich zwischen den beiden Systemen entscheidet irgendeine Regel darüber, welche Version die andere überschreibt. Manchmal ist das die neueste. Manchmal ist es die aus dem System, das als führend gilt. Manchmal ist es keine nachvollziehbare Regel, sondern ein Verhalten, das niemand bewusst eingestellt hat.

Das Ergebnis kann sein, dass die korrigierte Adresse in System A beim nächsten Abgleich wieder auf den alten Stand zurückgesetzt wird — obwohl in System A niemand an der Adresse etwas verändert hat. Der Datensatz wurde nicht manipuliert. Er wurde nur von einer anderen, älteren Version überschrieben.

Zwei Kolleginnen pflegen denselben Kunden in unterschiedlichen Programmen.
Beide halten ihre Angaben für aktuell.
Beim nächsten Abgleich gewinnt eine Version — die andere verschwindet still.

Das ist kein Ausnahmefall. Es ist das normale Verhalten von Systemen, die nicht entworfen wurden, um miteinander zu arbeiten, sondern die nachträglich verbunden wurden.

Hinzu kommt, dass solche Abgleiche oft automatisch laufen — nachts, ohne Meldung, ohne Protokoll, das jemand tatsächlich liest. Wer den Fehler bemerkt, stellt ihn meist dort ab, wo er sichtbar wird: im Programm, das den falschen Brief erzeugt hat. Die Ursache liegt woanders. Und beim nächsten Abgleich ist die Korrektur womöglich wieder weg.

Die Frage, ob ein System korrekt ist, lässt sich isoliert nicht beantworten. Korrekt im Vergleich womit — und zu welchem Zeitpunkt?

Die Exportdatei, die noch durch Excel muss

Viele Büros haben eine Datei, die einen Namen trägt, der sich über die Jahre nicht verändert hat: „Kundenliste_Export_bereinigt_NEU.xlsx". Sie stammt aus einem System, das Daten exportiert, die ein anderes System erwartet — aber eben nicht in der Form, in der sie ankommen.

Der Export selbst dauert zwei Minuten. Was danach kommt, dauert zwanzig. Jemand öffnet die Datei, löscht drei Spalten, benennt zwei um, passt das Datumsformat an — weil das Zielsystem ein anderes erwartet — und trägt in einer weiteren Spalte einen Wert ein, den das erste System nicht mitliefert, der aber zwingend benötigt wird. Dann wird die Datei gespeichert und hochgeladen. Läuft alles durch, ist der Tag gerettet.

Was diese Datei trägt

Es geht nicht um die zwanzig Minuten. Es geht darum, dass diese Datei ein Wissen trägt, das nirgendwo aufgeschrieben ist. Die Person, die den Export durchführt, weiß, dass das Feld „Datum_Ersterfassung" im Zielsystem als „Eingang" heißen muss. Sie weiß, dass leere Zellen in einer bestimmten Spalte später zu Fehlermeldungen führen. Sie hat es einmal gelernt — vermutlich durch einen Fehler — und seither hält sie es still für sich.

Das ist kein Vorwurf. Es ist ein Muster, das in fast jedem Betrieb vorkommt, der zwei Systeme parallel betreibt: Das eine wurde eingeführt, weil das andere etwas nicht konnte. Das andere wurde nicht abgelöst, weil zu viel darin steckt. Zwischen beiden liegt Excel.

Ein Immobilienbüro exportiert Objekte aus der Verwaltungssoftware, damit ein Mitarbeiter sie manuell ins Präsentationstool überträgt — weil die Felder nicht übereinstimmen.
Ein Handwerksbetrieb exportiert Stundenzettel, bereinigt sie und importiert sie ins Abrechnungssystem — jeden Monat, seit Jahren.
Eine Kanzlei pflegt Stammdaten in zwei Systemen, weil der Export des einen nie sauber in das andere passt.

Was diese Situationen verbindet: Der Weg funktioniert. Er ist verlässlich, weil dieselbe Person ihn immer geht. Und er ist fragil aus genau demselben Grund.

Wenn diese Person ausfällt — Urlaub, Krankheit, Kündigung — steht jemand anderes vor einer Datei, die aussieht wie eine gewöhnliche Tabelle, aber einen stillen Ablaufplan enthält, den niemand dokumentiert hat. Der Import schlägt fehl. Die Fehlermeldung nennt keine Ursache, die weiterhilft. Der Tag ist im Stau.

Dabei ist der eigentliche Inhalt der Datei korrekt. Die Daten stimmen. Nur das Format passt nicht — und dieses Wissen sitzt in einem Kopf, nicht in einem System.

Die Person, die weiß, wie es geht

In fast jedem Büro gibt es sie: eine Person, die genau weiß, welchem System man bei welcher Frage vertrauen kann. Nicht weil das irgendwo aufgeschrieben steht — sondern weil sie es über Monate oder Jahre herausgefunden hat. Durch Fehler, durch Nachfragen, durch den einen Vorfall, der nicht in Vergessenheit geraten ist.

Diese Person weiß zum Beispiel, dass die Quadratmeterzahl im Verwaltungsprogramm oft von der im Exposé abweicht — und welche der beiden für den Mietvertrag zählt. Sie weiß, dass der Exportlauf am Montagmorgen manchmal einen veralteten Stand liefert, weil das System die Nacht zuvor nicht synchronisiert hat. Sie weiß, wen man anrufen muss, wenn ein Datensatz in zwei Systemen unterschiedliche Werte trägt und eine Entscheidung nicht warten kann.

Kein Titel, keine Zuständigkeit — nur Erfahrung

Diese Person heißt offiziell nicht Datenverantwortliche. Ihr Stellenprofil erwähnt diese Aufgabe nicht. Sie macht es, weil sie da ist, weil sie es kann und weil irgendwann klar wurde, dass es sonst niemand tut.

Das ist kein Vorwurf an sie — im Gegenteil. Aber es ist ein strukturelles Risiko, das selten als solches benannt wird. Denn solange diese Person da ist, läuft der Betrieb. Ihr Wissen gleicht die Lücken zwischen den Systemen aus. Es füllt die Stellen, an denen Daten auseinanderdriften, ohne dass jemand einen Alarm sieht.

Was passiert, wenn sie in Urlaub fährt? Oder wenn sie das Unternehmen verlässt?

Wissen, das nirgends steht

Die Antwort lautet meistens: Verwirrung. Nicht sofort, aber spätestens dann, wenn jemand eine Entscheidung treffen muss, die früher einfach war. Welcher Wert gilt für die Nebenkostenabrechnung — der aus dem alten Programm oder der aus dem neuen? Wurde die Adresse nach dem Umzug in beiden Systemen geändert oder nur in einem?

Dieses Wissen existiert. Es ist nur nicht dort, wo es hingehört: in einer Regel, in einer Vereinbarung, in einem Ablauf, den jeder im Büro nachlesen kann. Es steckt im Kopf einer Person, die eigentlich für etwas anderes bezahlt wird.

Das ist der Moment, in dem ein Datenproblem zu einem Personalproblem wird — und ein Personalproblem zu einem Betriebsrisiko.

Warum das alte System nicht einfach abgeschaltet wird

Die Frage wird irgendwann gestellt, meistens von jemandem, der das System von außen sieht: Warum schalten wir es nicht einfach ab? Es läuft seit Jahren, niemand will mehr damit arbeiten, und das neue System ist produktiv. Die Antwort ist selten befriedigend — und sie klingt von außen wie eine Ausrede.

Tatsächlich gibt es in den meisten Betrieben eine Liste von Gründen, die niemand aufgeschrieben hat, weil sie sich nie zusammen angefasst worden sind. Das alte System läuft noch, weil es Aufgaben übernimmt, die im neuen nicht abgebildet sind. Nicht weil das neue schlechter wäre, sondern weil beim Wechsel nicht jede Funktion mitgewandert ist.

Was im alten System noch gebraucht wird

Ein häufiges Muster: Das neue System deckt das Tagesgeschäft ab. Angebote, Verträge, aktuelle Kundendaten. Das alte enthält die Vorgeschichte — Vorgänge aus früheren Jahren, Dokumente, die bei einer Prüfung noch einmal gebraucht werden könnten, eine Preistabelle, die nie migriert wurde, weil sie „eigentlich kein normaler Vorgang" mehr ist.

Jahresabschlüsse aus früheren Perioden, die das Steuerbüro noch einmal im Original sehen will
Auftragsdaten von Bestandskunden, die im neuen System keinen eigenen Eintrag haben
Spezialauswertungen, die nur eine Person erstellt und die sonst niemand nachbauen kann
Berichte, die in einem Format ausgegeben werden, das ein Dienstleister nach wie vor erwartet

Für jeden dieser Punkte einzeln genommen wäre der Aufwand überschaubar. Zusammen ergeben sie eine Abhängigkeit, die sich nicht an einem Tag auflösen lässt — und über die niemand eine vollständige Übersicht hat.

Die Kosten des Parallelbetriebs trägt niemand bewusst

Das alte System kostet Geld: Lizenzen, möglicherweise Wartungsverträge, eine Infrastruktur, die am Leben gehalten wird. Es kostet auch Zeit — die der Person, die weiß, wie man damit umgeht, und die Einarbeitungszeit für jede neue Kollegin, die einmal eine Auskunft braucht, die nur dort abrufbar ist.

Diese Kosten werden selten addiert, weil sie in verschiedenen Budgets verschwinden. Die Lizenz steht irgendwo in den laufenden Kosten. Die Zeit für Sonderauskünfte erscheint im Kalender einer Kollegin, die eigentlich für andere Aufgaben zuständig ist.

Was sich rechnerisch nicht zusammenführen lässt, wird deshalb oft nicht abgewogen — weder gegen die Kosten einer vollständigen Übernahme aller Altdaten noch gegen den Aufwand, die Datenhaltung dauerhaft zwischen zwei Systemen aufzuteilen. Das alte System bleibt nicht aus Überzeugung. Es bleibt, weil der Moment, es aufzugeben, noch nicht vollständig vorbereitet worden ist.

Solange dieser Moment nicht hergestellt wird — mit einer klaren Entscheidung darüber, welche Daten noch gebraucht werden, in welchem System sie landen sollen und wer das verantwortet — bleibt das alte System das Lager, in dem Dinge aufbewahrt werden, für die der neue Ort noch fehlt.

Wer entscheidet, welches System recht hat

Zwei Systeme, zwei Antworten auf dieselbe Frage. Das Warenwirtschaftssystem zeigt einen Lieferanten mit einer Adresse; die Buchhaltungssoftware zeigt dieselbe Firma unter einer anderen. Welche Adresse stimmt, ist keine technische Frage. Sie ist eine Frage der Zuständigkeit — und die ist in den meisten Unternehmen nicht schriftlich geregelt.

In der Praxis entscheidet oft derjenige, der gerade gefragt wird. Die Kollegin aus dem Einkauf kennt die aktuelle Adresse, weil sie letzte Woche mit dem Lieferanten telefoniert hat. Die Buchhaltung vertraut auf das, was beim letzten Jahresabschluss im System stand. Beide haben Recht und Unrecht zugleich — und keiner der beiden hat die Befugnis, das andere System zu korrigieren.

Das ist kein Fehler einzelner Personen. Es fehlt eine Entscheidung darüber, welches System für welche Art von Daten als maßgeblich gilt. Diese Entscheidung wurde in den meisten Betrieben nie getroffen, weil nie jemand gefragt hat.

Wenn die Zuständigkeit im Raum hängt

Besonders deutlich wird das bei Stammdaten: Kundenadressen, Preislisten, Artikelnummern. Diese Daten werden von mehreren Abteilungen gleichzeitig genutzt — und oft auch von mehreren gleichzeitig gepflegt. Vertrieb, Buchhaltung und Lager arbeiten mit denselben Datensätzen, aber in verschiedenen Systemen, mit verschiedenen Möglichkeiten, Daten zu ändern.

Wenn ein Auftrag nicht zugestellt wird, weil Straße und Hausnummer im Versandsystem nicht mit dem Auftragssystem übereinstimmen, beginnt eine Suche, die manchmal Stunden dauert. Wer hat zuletzt geändert? In welchem System? Und warum wurde die Änderung nicht in beiden hinterlegt?

Die Antwort auf diese Fragen führt fast immer zu einer einzelnen Person, nie zu einem geregelten Ablauf. Das ist das eigentliche Problem: Solange diese Person im Büro ist, läuft es. Wenn sie im Urlaub ist oder kündigt, läuft es nicht mehr — und niemand weiß zunächst, warum.

Die Frage nach dem letzten Wort

In größeren Unternehmen gibt es dafür oft eigene Rollen: jemand, der Stammdaten verantwortet, der Freigaben erteilt und der entscheidet, wenn zwei Systeme widersprechen. Im Mittelstand ist diese Verantwortung selten ausdrücklich vergeben. Sie liegt irgendwo zwischen Buchhaltung, Einkauf und der Geschäftsführung — und damit oft nirgendwo konkret.

Neue Software löst dieses Problem nicht von allein. Eine Migration überträgt die Daten, aber nicht die Entscheidung darüber, wer sie künftig pflegt und welches System bei Widersprüchen gilt. Unternehmen, die einen Systemwechsel abschließen und kurz darauf feststellen, dass die Daten schon wieder auseinanderlaufen, haben meistens genau diesen Schritt übersprungen.

Die technische Verbindung zweier Systeme ist machbar. Die organisatorische Frage — wer darf was ändern, wer wird informiert, wer hat das letzte Wort — bleibt die schwierigere Aufgabe. Und sie lässt sich weder einrichten noch einstellen.