Die Akte, die in keinem Programm ganz stimmt

Mehrere Programme, mehrere Wahrheiten

In den meisten Büros läuft nicht ein Programm, das alles kann, sondern mehrere, die jeweils einen Teil der Arbeit tragen. Das Angebotsprogramm hier, die Auftragsverwaltung dort, die Buchhaltung an einem dritten Ort. Das ist keine Fehlerentscheidung — es ist oft schlicht so gewachsen. Jedes neue Programm löste ein Problem, das das vorherige nicht lösen konnte.

Was dabei entsteht: dieselbe Akte in drei verschiedenen Zuständen. Ein Kunde, der vor sechs Monaten umgezogen ist, steckt mit seiner alten Adresse im Angebotsprogramm, mit der neuen in der Buchhaltung und mit einem Tippfehler in der dritten Liste. Welche Adresse stimmt? Wer zuletzt nachgeschaut hat, weiß es. Wer heute hinschaut, weiß es nicht.

Das ist kein Ausnahmefall. Es ist die Regel in Unternehmen, die über Jahre gewachsen sind und dabei nie einen Moment hatten, in dem jemand die Zuständigkeit für ein einziges, verlässliches Bild übernommen hätte.

Wenn zwei Programme dasselbe anders nennen

Besonders schwierig wird es dort, wo zwei Programme denselben Vorgang beschreiben — aber nicht mit denselben Feldern. Das Angebotsprogramm kennt eine „Projektnummer". Die Buchhaltung kennt eine „Auftragsnummer". Ob die beiden dasselbe meinen, lässt sich nur durch Nachfragen klären, nicht durch einen Blick auf den Bildschirm.

Was in der Praxis passiert: Jemand sucht einen Auftrag, findet ihn im einen Programm, trägt die Nummer ab — und erfährt drei Tage später, dass die Zahl im anderen Programm eine andere war. Der Unterschied war eine Nachkommastelle, eine führende Null oder ein Buchstabe, den das ältere System automatisch anhängte. Die Akte existiert, sie ist nur in keinem Programm ganz vollständig.

Kundennamen, die in einem System mit der Firma beginnen, im anderen mit dem Nachnamen
Datumsangaben in verschiedenen Formaten — 04.09.2026 hier, 2026-09-04 dort
Statusbezeichnungen, die ähnlich klingen, aber unterschiedlich gesetzt werden: „abgeschlossen" und „erledigt" und „fertig" für denselben Vorgang in drei Programmen
Beträge mit und ohne Mehrwertsteuer, ohne dass das Feld es ausweist

Solange jeder in seinem Programm bleibt, fällt das kaum auf. Erst wenn jemand einen Bericht quer über alle Programme zusammenstellen will — oder wenn ein neues System die Daten aus allen alten Systemen übernehmen soll — zeigt sich, wie weit die Versionen auseinandergegangen sind.

Die stille Abweichung im Alltag

Nicht jede Abweichung führt sofort zu einem sichtbaren Fehler. Manche leben jahrelang unbemerkt in den Programmen. Eine Lieferantenadresse, die nur noch in einem der Systeme auf dem neuesten Stand ist. Ein Ansprechpartner, der das Unternehmen längst verlassen hat und trotzdem in zwei von drei Listen noch auftaucht. Ein Preis, der im Angebot von 2024 stand und seither nie angepasst wurde — weil das Angebotsprogramm kein Feld kennt, das mit der Preisliste des anderen Systems spricht.

Solche Abweichungen bleiben unsichtbar, bis jemand sie braucht. Dann ist die Frage nicht nur, welche Version stimmt — sondern wer überhaupt zuständig ist, das zu klären.

Der Moment, in dem das sichtbar wird, ist selten ein ruhiger. Meistens ist es der Tag, an dem das Projekt bereits gestartet hat und die Daten schon übernommen werden sollen.

Warum der erste Import täuscht

Der Moment, in dem das neue System meldet, dass alle Datensätze übernommen wurden, fühlt sich wie ein Abschluss an. Die Zahl stimmt. Die Tabelle ist voll. Wer die Ausgangsdaten nicht auswendig kennt, hat keinen Grund zu zweifeln.

Das Problem liegt nicht in dem, was fehlt — es liegt darin, dass nichts fehlt. Jedenfalls nicht sichtbar.

Was der Import zählt, und was er nicht zählt

Ein Importvorgang zählt Datensätze. Er prüft nicht, ob ein Datensatz vollständig ist. Wenn eine Akte im Ausgangssystem fünf beschriebene Felder hat und das Ziel nur vier davon kennt, wird trotzdem eine Akte übertragen. Der Zähler steigt um eins. Das fünfte Feld ist weg.

Das passiert nicht, weil jemand nachlässig war. Es passiert, weil zwei Programme unterschiedliche Vorstellungen davon haben, wie eine Akte aussieht. Ein Verwaltungsprogramm kennt ein Freitextfeld für interne Vermerke. Das neue System hat dafür keine Entsprechung — oder hat sie, aber unter einem anderen Namen, in einer anderen Struktur, mit einer anderen Zeichengrenze.

Ein konkretes Beispiel

Eine Hausverwaltung wechselt ihre Software. Alle 412 Mieterakten werden importiert. Die Abschlussmeldung lautet: 412 von 412 erfolgreich. Drei Monate später stellt eine Mitarbeiterin fest, dass sämtliche Notizen zu laufenden Nebenkostenwidersprüchen fehlen. Sie lagen in einem Kommentarfeld, das das alte System erlaubte und das neue nicht kennt. Niemand hat das Feld bei der Vorbereitung aufgelistet, weil es nicht in der offiziellen Feldübersicht stand.

Der Import war technisch korrekt. Die Daten, die ankamen, sind vollständig. Die Daten, die nicht ankamen, haben nie eine Fehlermeldung ausgelöst.

Wann der Fehler auftaucht

Solche Lücken zeigen sich selten sofort. Sie zeigen sich in dem Moment, in dem jemand eine Akte aufruft, die er aus dem alten System kennt — und merkt, dass etwas fehlt, ohne genau benennen zu können, was. Oder in dem Moment, in dem ein Vorgang eskaliert und die Notizen, die den Hintergrund erklären würden, nicht da sind.

Freitextfelder, die keine Entsprechung haben, werden stillschweigend weggelassen
Datumsformate, die das Zielsystem nicht erkennt, werden als leer übertragen oder falsch interpretiert
Verknüpfungen zwischen Datensätzen — etwa zwischen einer Akte und einem zugehörigen Dokument — bestehen im Export als Nummer, die im neuen System nichts bedeutet
Sonderzeichen in Namen oder Adressen werden je nach Zeichensatz des Exportformats entstellt oder abgeschnitten

Keiner dieser Fälle bricht den Import ab. Alle gelten als Erfolg.

Der erste Import täuscht nicht, weil er falsch läuft. Er täuscht, weil er genau das liefert, was man ihm aufgetragen hat — und niemand aufgetragen hat, auf das zu achten, was er nicht mitbringt.

Felder, die nicht zueinander passen

Wer Kundendaten aus einem Programm in ein anderes überträgt, lernt schnell, dass die Felder zwar ähnlich heißen, aber selten dasselbe meinen. Das Maklerprogramm kennt „Ansprechpartner". Die Buchhaltungssoftware kennt „Rechnungsempfänger". Und das Formular auf der Website fragt nach „Kontaktperson". Ob das dieselbe Person ist, entscheidet niemand systematisch — das entscheidet jede Mitarbeiterin und jeder Mitarbeiter für sich, beim nächsten Eintrag, nach eigenem Ermessen.

Ähnliches gilt für Adressen. Ein System erwartet Straße und Hausnummer in einem Feld. Das andere will sie getrennt. Ein drittes verlangt außerdem den Ortsteil, den das erste gar nicht kennt. Wer Daten von einem Programm ins andere überträgt, muss in diesen Momenten entscheiden — und eine Entscheidung, die hundert Mal getroffen wird, wird hundert Mal unterschiedlich getroffen.

Kategorien, die nur auf dem Papier deckungsgleich sind

Besonders sichtbar wird das Problem bei Kategorisierungen. Ein Verwaltungsprogramm unterscheidet zwischen „Eigentumswohnung", „Mietwohnung" und „Teileigentum". Ein zweites, das für die Buchhaltung zuständig ist, kennt nur „Wohneinheit" und „Gewerbeobjekt". Was ist eine Eigentumswohnung, die vermietet wird? Je nach Tag, Person und Kontext landet sie in einer anderen Kategorie — und die Zahlen, die auf dieser Kategorie aufbauen, weichen irgendwann voneinander ab, ohne dass sich der Fehler klar benennen ließe.

Datumsfelder sehen nach einem kleineren Problem aus, als sie sind. Das Einzugsdatum in der Verwaltungssoftware ist ein Pflichtfeld. Im Makler-CRM ist es optional und bleibt oft leer. Ein Exportformat schreibt das Datum als „TT.MM.JJJJ", das nächste als „JJJJ-MM-TT". Wer das nicht bemerkt, bekommt beim nächsten Datenabgleich Meldungen, die keinen erkennbaren Zusammenhang mit dem ursprünglichen Fehler haben.

Pflichtfeld hier, Freitext dort

Manche Felder existieren in einem System als strukturierte Auswahl — feste Optionen, die jemand einmal festgelegt hat. Im zweiten System gibt es dasselbe Konzept als Freitext. Was in System A sauber als „Staffelmiete" klassifiziert ist, steht in System B irgendwo im Bemerkungsfeld, zwischen dem Hinweis auf den Kellerabteil und der Notiz zum Schlüsselübergabe-Termin. Auswertbar ist das nicht. Auffindbar manchmal auch nicht.

Das eigentliche Problem ist nicht, dass Programme unterschiedlich gebaut sind. Das ist normal und lässt sich akzeptieren. Das Problem ist, dass diese Unterschiede unsichtbar bleiben, bis jemand eine Übersicht braucht und dann merkt, dass die Grundlage nicht trägt. Dann beginnt die Suche: Welche Einträge sind falsch? Seit wann? Wer hat sie angelegt? Meistens gibt es keine Antwort — nur die Gewissheit, dass ein Teil der Daten nicht stimmt und niemand sagen kann, wie groß dieser Teil ist.

Zuständigkeit ohne Zuständigen

Wenn Daten in mehreren Programmen gleichzeitig gepflegt werden sollen, entsteht früh eine Frage, die selten jemand laut stellt: Wer ist eigentlich dafür zuständig, dass eine bestimmte Information in allen Programmen stimmt?

Die Antwort ist in den meisten Büros: alle. Was in der Praxis bedeutet: niemand.

Das ist kein Vorwurf an die Beteiligten, sondern eine Beschreibung dessen, was passiert, wenn Zuständigkeiten nicht festgelegt werden. Eine Mitarbeiterin trägt eine neue Adresse in das Verwaltungsprogramm ein. Ein Kollege aktualisiert den Kontakt im E-Mail-Programm. Ob jemand auch das dritte System angepasst hat — das Programm, in dem die Jahresabrechnung erstellt wird — weiß hinterher keiner mehr genau.

Der Moment, in dem es auffällt

Solange nichts ausgedruckt oder verschickt wird, bleibt das Problem unsichtbar. Es wird sichtbar, wenn eine Rechnung an die alte Adresse geht. Wenn der Außendienst mit veralteten Kontaktdaten ins Gespräch geht. Wenn zwei Kolleginnen am selben Objekt arbeiten und nachher nicht mehr sicher sind, welche Fassung die aktuelle ist.

Dann beginnt das Suchen. Wer hat die Akte zuletzt angefasst? In welchem Programm ist die neuere Version? Und warum steht im anderen Programm eine andere Hausnummer?

Keine Übergabe, kein Protokoll

In vielen Büros gibt es für diese Situation kein festgelegtes Vorgehen. Es gibt Gewohnheiten — wer was meistens einträgt, in welchem Programm man zuerst nachschaut. Aber Gewohnheiten sind keine Zuständigkeiten. Wenn jemand krank ist oder das Unternehmen verlässt, trägt die Lücke keine Aufschrift.

Das zeigt sich besonders bei Daten, die sich selten ändern und deren Änderung trotzdem Konsequenzen hat: Bankverbindungen, Fristen, steuerliche Merkmale. Weil diese Felder monatelang unberührt bleiben, fällt niemandem auf, dass sie in einem der Programme seit zwei Jahren nicht mehr stimmen — bis jemand darauf angewiesen ist, dass sie stimmen.

Wer trägt den Fehler?

Wenn ein Fehler entsteht, weil niemand zuständig war, lässt er sich selten einer Entscheidung zuordnen. Er entstand im Laufe der Zeit, zwischen zwei Programmen, zwischen zwei Mitarbeitenden. Das macht ihn schwer zu korrigieren — nicht weil die Korrektur aufwändig wäre, sondern weil zuerst geklärt werden muss, welche Version überhaupt die richtige ist.

Genau diese Frage stellt sich, wenn ein neues Programm eingeführt wird: Welche Daten werden übernommen? Aus welchem System? Und wer prüft das — nicht technisch, sondern inhaltlich? In vielen Projekten bleibt sie unbeantwortet, weil alle davon ausgehen, dass jemand anderes sich darum gekümmert hat. Das neue Programm startet dann mit denselben Unstimmigkeiten wie das alte, nur dass jetzt niemand mehr weiß, woher sie stammen.

Welches System gilt als führend, wenn zwei Programme denselben Datensatz unterschiedlich zeigen?
Wer wird informiert, wenn sich eine Information ändert, die an mehreren Stellen gepflegt wird?
Wie wird sichergestellt, dass eine Änderung nicht nur im geöffneten Programm, sondern überall ankommt?

Diese Fragen haben keine technische Antwort. Sie sind Organisationsfragen — und sie müssen beantwortet sein, bevor irgendein Programm eingerichtet wird. Wer sie erst stellt, wenn der erste Fehler aufgetaucht ist, beantwortet sie unter Druck und mit unvollständigen Informationen.

Was der stille Pflegeaufwand wirklich kostet

In den meisten Büros gibt es eine Person, die weiß, wie es wirklich geht. Sie weiß, dass der Name einer Gesellschaft im alten System anders geschrieben steht als im neuen. Sie weiß, welche Felder manuell übertragen werden müssen, weil der Export sie nicht mitliefert. Sie weiß, wann zuletzt jemand geprüft hat, ob die Zahlen in beiden Programmen übereinstimmen. Diese Person hat das nie ausdrücklich als ihre Aufgabe übernommen — es ist einfach bei ihr geblieben.

Was das kostet, lässt sich schwer beziffern, weil es nie als Posten auftaucht. Es sind Stunden pro Woche, die in keiner Leistungserfassung stehen: Daten abgleichen, Dopplungen entfernen, eine Korrektur nachtragen, die jemand anders vor drei Wochen gemacht hat, ohne es zu erwähnen. Der Aufwand ist real — er zeigt sich nur dort nicht, wo man nach Kosten sucht.

Wenn die Person fehlt

Das Ausmaß wird sichtbar, wenn diese Person krank wird, in Urlaub geht oder das Unternehmen verlässt. Was bis dahin reibungslos wirkte, hängt plötzlich in der Luft. Anfragen landen in einem System, aber nicht im anderen. Statusangaben stimmen nicht mehr. Jemand springt ein und stellt fest, dass es keine schriftliche Beschreibung gibt, wie die Übertragung eigentlich läuft — weil sie nie aufgeschrieben wurde, weil sie nie offiziell war.

Das ist kein Organisationsproblem im klassischen Sinne. Es ist die logische Folge davon, dass zwei Programme verbunden wurden, ohne dass irgendjemand entschieden hätte, wer diese Verbindung dauerhaft trägt.

Was sich im Jahr summiert

Zehn Minuten täglich ergeben in einem Arbeitsjahr über vierzig Stunden. Das klingt abstrakt — bis man nachzählt, was in dieser Zeit hätte entstehen können. Nicht als Vorwurf, sondern als Maßstab: Was wird routinemäßig getan, ohne dass je geprüft wurde, ob es so bleiben muss?

Adressen, die in einem Programm aktualisiert werden und im anderen nicht
Statusfelder, die niemand mehr anpasst, weil die Ansicht ohnehin veraltet ist
Notizen, die nur in einem System stehen und beim nächsten Kontakt fehlen
Auswertungen, die von Hand ergänzt werden, bevor sie weitergehen

Jeder dieser Punkte ist für sich genommen handhabbar. Zusammen beschreiben sie einen Pflegeaufwand, der still neben dem eigentlichen Geschäft läuft. Er wird selten benannt — solange er funktioniert, fällt er nicht auf. Und genau darin liegt das Problem: Der Aufwand, der immer gemacht wird, ist auch der Aufwand, den niemand abbestellt.