Wenn die Zuständigkeit zwischen den Systemen fällt

Was zwischen zwei Systemen liegt – und wer es nicht sieht

Zwei Programme, beide in Betrieb, beide gepflegt, beide bezahlt. Und trotzdem stimmt am Monatsende etwas nicht. Die Zahl im Buchhaltungsprogramm weicht von der im Verwaltungssystem ab. Niemand hat einen Fehler gemacht – zumindest keinen, den jemand benennen kann. Das Unbehagen bleibt, weil die Ursache nicht dort sitzt, wo man sucht: nicht in einem der beiden Systeme, sondern zwischen ihnen.

Dieser Zwischenraum hat keinen offiziellen Namen im Unternehmen. Er hat keine Zuständige und keinen Termin. Er fällt auf, wenn etwas schiefläuft – und verschwindet aus dem Blick, sobald der Tag weitergeht.

Was in diesem Zwischenraum tatsächlich passiert

In vielen Büros sieht es so aus: Mitarbeiterin A trägt einen neuen Kunden ins Verwaltungssystem ein. Mitarbeiterin B braucht dieselben Angaben im Abrechnungsprogramm. Also tippt sie sie ab – oder kopiert sie aus einer E-Mail, die jemand ihr weitergeleitet hat. Manchmal passt es. Manchmal nicht ganz. Manchmal bemerkt es niemand, bis drei Wochen später eine Rechnung falsch adressiert zurückkommt.

Das ist keine Frage von Sorgfalt. Es ist eine Frage des Aufbaus. Zwei Systeme, die keine gemeinsame Sprache sprechen, produzieren automatisch einen Bereich, der menschliche Arbeit verlangt. Diese Arbeit ist unsichtbar, weil sie kein definierter Prozessschritt ist – sie passiert einfach, damit der Rest weiterläuft.

Wer diesen Zwischenraum sieht – und wer nicht

Die Personen, die ihn täglich überbrücken, wissen genau, was gemeint ist. Sie kennen die Felder, die nie übereinstimmen. Sie wissen, welcher Export erst manuell nachgearbeitet werden muss, bevor er irgendwo eingelesen werden kann. Welche Spalte umbenannt werden muss. Welche Angabe schlicht fehlt und deshalb jedes Mal von Hand ergänzt wird. Dieses Wissen trägt keine Person offiziell – es hängt an bestimmten Menschen. Wenn diese Menschen das Unternehmen verlassen oder ausfallen, zeigt sich, wie viel tägliche Funktionsfähigkeit auf stillschweigender Kenntnis beruhte.

Die Führungsebene sieht diesen Zwischenraum in der Regel nicht – nicht aus Gleichgültigkeit, sondern weil er in keinem Bericht auftaucht. Systeme werden nach ihrer Oberfläche beurteilt: Funktioniert das Programm? Werden Rechnungen verschickt? Läuft die Verwaltung? Die Antwort lautet meistens ja. Was diese Antwort verbirgt, ist der tägliche Aufwand, der dafür sorgt, dass sie ja lautet.

Ein Digitalisierungsprojekt, das diese Stellen nicht kennt, bevor es anfängt, trifft auf sie, nachdem es begonnen hat. Dann heißt es, das neue System sei noch nicht eingespielt oder noch in der Einführungsphase. Manchmal stimmt das. Oft beschreibt es einen Systemwechsel, der das Überbrücken alter Lücken durch das Überbrücken neuer ersetzt hat – ohne dass jemand die Lücken vorher benennen musste.

Exportformate: Die Arbeit, die vor der Arbeit anfängt

Irgendwann kommt der Moment, in dem jemand die alten Daten aus dem bisherigen System herausholen muss. Nicht weil irgendjemand Freude daran hätte, sondern weil das neue System sie braucht, um arbeitsfähig zu sein. Was sich anhört wie ein technischer Schritt am Rand des Projekts, wird für viele Unternehmen zur ersten echten Bewährungsprobe — lange bevor irgendein Mitarbeiter die neue Oberfläche zum ersten Mal sieht.

Das alte System kann exportieren. Das steht im Handbuch und stimmt auch. Nur exportiert es in einem Format, das das neue System nicht ohne Weiteres lesen kann. Oder es exportiert als Tabelle, aber die Spaltenbezeichnungen weichen ab. Oder die Datumsangaben folgen einem anderen Muster. Oder die Umlaute werden falsch übertragen, weil beide Systeme unterschiedlich kodieren — und wer das nicht kennt, sieht es erst, wenn die ersten Einträge in der neuen Oberfläche kaputt aussehen.

Was ein Export tatsächlich enthält

Ein Exportformat entscheidet darüber, wie die Daten ankommen — und ob sie überhaupt verwendbar sind. Das lässt sich nicht im Voraus durch Nachfragen klären, weil die Antwort auf „Was liefert das System?" fast immer „eine Excel-Datei" lautet. Erst wer die Datei öffnet, sieht, was darin wirklich steckt:

Felder, die in einer Spalte zusammengefasst sind, aber im neuen System getrennt geführt werden müssen — Name und Anrede in einer Zelle, Straße und Hausnummer ebenfalls.
Leerspalten, Zwischensummen und Formatierungszeilen, die für eine lesbare Tabelle gedacht waren, nicht für eine strukturierte Datenbank.
Datumsangaben, bei denen manche Zeilen „15.03.2024" schreiben und andere „2024-03-15" oder „March 15" — je nachdem, wer den Datensatz zuletzt angefasst hat.
Beträge mit Tausenderpunkten, die als Text gespeichert wurden, nicht als Zahl, weil jemand irgendwann ein Leerzeichen oder ein Sonderzeichen mitgeschrieben hat.

Das sind keine Einzelfälle. Es sind Muster, die entstehen, wenn mehrere Menschen über Jahre hinweg in dasselbe System eingeben, ohne dass je festgelegt wurde, wie ein Feld auszufüllen ist. Pflichtfelder, die das System nicht erzwingt, bleiben leer. Freitextfelder werden für alles benutzt, wofür kein eigenes Feld da ist. Und niemand bereinigt das, solange das System funktioniert.

Wer diesen Schritt unterschätzt

Der Export wird oft für den letzten Schritt vor dem Start gehalten. In der Realität ist er der erste Schritt, der zeigt, wie konsistent die alten Daten tatsächlich sind. Wer damit rechnet, dass dieser Schritt einen Nachmittag dauert, plant oft zwei Wochen ein — bevor die erste Zeile fehlerfrei übernommen ist. Nicht weil das neue System schwierig wäre, sondern weil die alten Daten so gewachsen sind, wie Daten wachsen, wenn niemand ausdrücklich zuständig ist: organisch, uneinheitlich und schwer zu bereinigen, ohne jeden Datensatz einzeln anzuschauen.

Das ist keine Kritik an den Menschen, die diese Daten gepflegt haben. Es ist eine Beschreibung davon, was passiert, wenn ein System jahrelang als Ablage benutzt wird, nicht als strukturiertes Werkzeug. Dieser Unterschied wird erst sichtbar, wenn die Daten irgendwo anders hinmüssen. Und genau dann — wenn das Projekt eigentlich loslegen soll — fängt die eigentliche Arbeit erst an.

Stammdaten: Worüber niemand spricht, solange alles läuft

Jedes Unternehmen hat Stammdaten. Kundenadressen, Objektdaten, Lieferantennummern, Preislisten. Diese Daten liegen irgendwo, seit Jahren. Niemand hinterfragt sie, solange die Arbeit ihren Gang geht.

Das Problem zeigt sich erst, wenn ein neues System eingeführt wird und diese Daten dorthin übertragen werden sollen. Dann stellt sich heraus: Der selbe Kunde ist dreimal im System — einmal mit Abkürzung, einmal ausgeschrieben, einmal mit einem alten Firmennamen. Die Postleitzahl wurde irgendwann manuell eingetragen und stimmt in einem Viertel der Fälle nicht mehr. Ein Feld, das eigentlich Pflicht sein sollte, ist bei 40 Prozent der Datensätze leer, weil es früher optional war.

Was sauber aussieht und es nicht ist

Stammdaten wachsen über Jahre. Sie entstehen nicht aus einem Guss, sondern durch viele einzelne Eingaben, von vielen verschiedenen Personen, unter wechselnden Anforderungen. Was 2018 als Datensatz angelegt wurde, folgt anderen Regeln als das, was 2023 eingetragen wurde. Niemand hat das damals aufeinander abgestimmt.

Straßennamen teils ausgeschrieben, teils abgekürzt — das System erkennt sie nicht als identisch
Ansprechpartner mehrfach angelegt, weil Kollegen denselben Kontakt unabhängig voneinander erfasst haben
Kategorien und Bezeichnungen, die einmal intern festgelegt wurden und sich seitdem still verändert haben
Felder, die für ein altes System Sinn ergaben und im neuen keinen Platz finden

Diese Inkonsistenzen fallen nicht auf, weil das alte System damit umgehen konnte. Es kannte die Logik hinter den Daten, weil die Menschen, die damit arbeiten, sie kennen. Das neue System kennt diese Logik nicht.

Die Aufgabe, die kein Projekt einplant

Bevor Daten in ein neues System übernommen werden können, müssen sie bereinigt werden. Das bedeutet: Dubletten zusammenführen, fehlende Felder nachtragen, widersprüchliche Einträge klären. Diese Arbeit ist mühsam, sie ist nicht automatisierbar und sie braucht jemanden, der die Daten inhaltlich kennt.

In der Praxis wird dieser Schritt unterschätzt. Nicht weil er vergessen wird, sondern weil er schwer zu benennen ist. Er hat keinen klaren Anfang, keinen klaren Abschluss und kein messbares Ergebnis, bis er fehlt. Dann zeigt sich: Das neue System enthält die alten Fehler in neuer Verpackung.

Eine Hausverwaltung, die ihre Mietermeldungen digitalisiert, merkt beim ersten Massenexport, dass ein Viertel der Mietverträge keiner aktuellen Adresse zugeordnet ist. Ein Maklerbüro, das sein Kontaktsystem wechselt, stellt fest, dass dieselbe Person unter vier verschiedenen E-Mail-Adressen geführt wird. Die Daten waren immer so — sie wurden nur nie auf Vollständigkeit geprüft, weil der Anlass fehlte.

Das ist der Moment, in dem Digitalisierungsprojekte in Erklärungsnot geraten. Nicht weil die Software nicht funktioniert. Sondern weil der Boden, auf dem sie stehen soll, nicht so eben ist, wie es auf den Plänen aussah.

Altdaten in neuen Systemen: Wann die Anpassung aufhört

Wer ein neues System einführt, muss irgendwann entscheiden, was mit den alten Daten passiert. Diese Entscheidung fällt selten in einer Sitzung und selten mit klarem Ergebnis. Sie fällt in kleinen Schritten, über Wochen, und meistens endet sie damit, dass jemand aufhört zu fragen.

Am Anfang ist der Plan noch konkret: Die wichtigsten Kunden werden übertragen, die laufenden Aufträge, die offenen Posten. Was älter ist als zwei Jahre, schaut man sich später an. Was nicht eindeutig zuzuordnen ist, bekommt vorerst eine Sammelkategorie. Was im alten System als Freitext stand, wird irgendwie eingetippt.

Was dann passiert, ist nicht Versagen. Es ist das normale Ende eines Projekts unter Zeitdruck.

Die Lücke, die niemand benennt

In vielen Fällen hat das neue System andere Felder als das alte. Wo früher ein einziges Adressfeld stand, gibt es jetzt vier getrennte. Wo früher eine Kategorie für alle Kunden galt, erwartet das neue System eine Unterteilung nach Typ. Wer alte Datensätze überträgt, trifft an jeder dieser Stellen eine kleine Entscheidung: Soll ich das aufteilen? Wie? Und was mache ich mit den vierhundert Einträgen, bei denen das nicht eindeutig geht?

Die meisten dieser Entscheidungen werden nicht festgehalten. Sie landen im Kopf der Person, die gerade am Bildschirm sitzt. Und wenn diese Person das Projekt abschließt und zu ihrer eigentlichen Arbeit zurückkehrt, ist das Wissen darüber weg.

Wenn „gut genug" ein Dauerzustand wird

Das Ergebnis ist ein System, das funktioniert — aber auf einem Fundament, das niemand genau kennt. Bei einem Teil der alten Kontakte fehlt die Hausnummer, weil das Importformat sie abgeschnitten hat. Bei einem anderen Teil steht die Postleitzahl im Adressfeld, weil das frühere Freitextfeld keine Trennung kannte. Manche Einträge tragen ein Erstellungsdatum, das vom Systemwechsel stammt — nicht vom tatsächlichen ersten Kontakt.

Das fällt nicht sofort auf. Manchmal fällt es gar nicht auf — bis jemand eine Auswertung erstellt, die von vollständigen Angaben ausgeht. Oder bis eine Anfrage zu einem alten Kunden kommt und die hinterlegten Informationen nicht stimmen.

Datensätze mit Platzhaltereinträgen wie „unbekannt" oder einer Null tauchen in Berichten auf und verzerren die Zahlen.
Kontakte, die im alten System unter einem anderen Namen liefen, sind jetzt doppelt vorhanden — einmal als alter Eintrag, einmal manuell neu angelegt.
Felder, die im alten System nicht existierten, sind im neuen leer und bleiben es, weil niemand weiß, wie sie befüllt werden sollen.

Das ist nicht das Ergebnis schlechter Planung. Es ist das Ergebnis des Moments, an dem die Anpassung aufhört — nicht weil sie abgeschlossen ist, sondern weil die Zeit ausläuft oder weil der nächste Schritt zu mühsam ist, um ihn noch zu rechtfertigen.

Was danach kommt

Ein Teil dieser Datensätze wird irgendwann bereinigt — wenn jemand über sie stolpert und gerade die Zeit hat, sie zu korrigieren. Ein anderer Teil bleibt, wie er ist. Er wird im Alltag umgangen: Wer weiß, dass die alten Adressen unzuverlässig sind, prüft sie manuell, bevor er eine Serienmitteilung verschickt. Wer weiß, dass manche Zuordnungen nicht stimmen, zieht bei Auswertungen eine eigene Liste.

Das kostet Zeit. Aber es ist unsichtbare Zeit — verteilt auf viele kleine Momente, über viele Personen, ohne dass sie irgendwo auftaucht und jemand fragt, woher sie kommt.

Wann die Anpassung aufgehört hat, lässt sich im Nachhinein selten genau sagen. Was sich sagen lässt: Sie hört auf, bevor alle Entscheidungen getroffen sind. Was danach kommt, nennt sich nicht mehr Migration — es nennt sich Alltag.

Zuständigkeit ohne Namen: Warum Datenpflege liegen bleibt

Wenn ein neues System eingeführt wird, wird die Frage, wer welche Daten pflegt, selten explizit beantwortet. Meistens löst sie sich durch Gewohnheit: Wer die Daten im alten System eingetragen hat, trägt sie auch im neuen ein — auch wenn das neue System nun einer anderen Abteilung gehört. Das klingt nach einer Lösung, ist aber keine. Es ist ein Aufschub.

Was dann passiert, lässt sich an einem typischen Ablauf beschreiben. Das neue System geht in Betrieb. Die ersten Wochen laufen gut, weil alle noch aufmerksam sind. Nach drei Monaten beginnen die ersten Felder leer zu bleiben — nicht aus Absicht, sondern weil die Kollegin, die das zuletzt gemacht hat, im Urlaub war, und danach hat es niemand mehr aufgegriffen. Nach einem Jahr hat das System Daten, die zum Teil stimmen, zum Teil veraltet sind und zum Teil nie eingegeben wurden. Niemand kann sagen, wann das passiert ist.

Wenn zwei Bereiche dasselbe annehmen

Besonders heikel ist es, wenn zwei Abteilungen ein begründetes Interesse an denselben Daten haben. Kundendaten werden in vielen Betrieben sowohl von der Buchhaltung als auch vom Vertrieb gepflegt — oder von keinem von beiden, weil jeder davon ausgeht, dass der andere es erledigt. Das Ergebnis sind Einträge mit zwei verschiedenen Adressen, veralteten Ansprechpartnern oder fehlenden Angaben, die erst dann auffallen, wenn eine Rechnung nicht zugestellt wird oder ein Rückruf ins Leere geht.

Das ist kein Systemfehler. Die Programme könnten die Daten problemlos tragen. Das Problem ist organisatorisch: Bei der Einführung wurde entschieden, welche Felder es gibt — aber nicht, wer für ihre Aktualität verantwortlich ist. Diese Frage wurde übergangen, weil sie im Eifer des Projektstarts unspektakulär wirkte.

Die stille Übernahme

In kleineren und mittleren Betrieben ist der Kreis der Personen, die wissen, wie Daten korrekt einzutragen sind, oft enger als der Kreis derer, die es regelmäßig tun. Eine Mitarbeiterin, die die Software gut kennt, übernimmt Korrekturen, die eigentlich nicht in ihr Aufgabenfeld fallen — nicht weil es ihr Auftrag wäre, sondern weil sie weiß, dass es sonst liegen bleibt. Solange sie da ist, funktioniert es. Wenn sie das Unternehmen verlässt oder in Elternzeit geht, bricht das informelle System zusammen.

Niemand hat entschieden, dass diese Person zuständig ist — sie hat es übernommen.
Niemand weiß, welche Korrekturen sie vorgenommen hat — sie wurden nicht festgehalten.
Niemand merkt, dass etwas fehlt — bis die Fehler sichtbar genug sind, um aufzufallen.

Was dann folgt, sind keine dramatischen Abstürze, sondern schleichende Unschärfen. Ein Angebot geht an die falsche Adresse. Ein Bericht zeigt Umsätze, die sich nicht mit dem decken, was der Vertrieb meldet. Eine Auswertung ergibt nichts, weil das Feld, nach dem gefiltert wird, bei einem Drittel der Einträge leer ist. Jeder dieser Momente kostet Zeit — für die Klärung, die Korrektur, das Nachfassen. Zusammengenommen kosten sie mehr als die Einführung des Systems selbst.

Der Fehler entsteht meistens nicht am ersten Tag, sondern in den Monaten danach, wenn die Aufmerksamkeit nachlässt und die Verantwortung nirgendwo verankert ist.