Wenn altes und neues System gleichzeitig laufen müssen

Montag morgen. Jemand sucht einen Kundeneintrag. Der liegt im alten Programm, das eigentlich abgelöst sein sollte. Im neuen findet er ihn auch — aber die Adresse ist eine andere. Welche stimmt?

Die meisten Betriebe, die ein neues Programm einführen, stellen sich die Sache geradlinig vor: Entscheidung, Einführung, Umstieg. Was zwischen Einführung und echtem Umstieg liegt, hat in vielen Unternehmen keinen Namen im Projektplan — und dauert in der Praxis länger als alles, was davor kam.

Die Phase, die kein Zeitplan abbildet

Es gibt einen Stichtag. Ab dann, so die Planung, soll mit dem neuen Programm gearbeitet werden. In der Praxis verschiebt sich dieser Stichtag — nicht weil die Software schlecht ist, sondern weil der Betrieb weiterläuft, während das Neue eingeführt wird.

Offene Aufträge aus dem vergangenen Quartal sind noch im alten System erfasst. Eine Mitarbeiterin kennt die neue Oberfläche noch nicht gut genug für komplexere Fälle. Ein Stammkunde hat eine Anfrage gestellt, die vor Wochen begann und noch nicht abgeschlossen ist. Also bleibt das alte Programm aktiv. Und plötzlich wird in beiden gleichzeitig gearbeitet.

Diese Phase hat einen schleichenden Charakter. Sie beginnt damit, dass Ausnahmen gemacht werden. Sie endet damit, dass beide Programme zur Routine geworden sind — und niemand mehr genau weiß, was wo steht.

Wessen Daten gelten gerade?

Sobald beide Systeme gleichzeitig genutzt werden, entsteht eine Frage, die selten laut ausgesprochen wird: Welche Version eines Eintrags ist die richtige?

Im alten Programm wurde letzte Woche eine Kundenadresse korrigiert. Im neuen steht noch die alte Adresse, weil der Import vor drei Monaten stattfand. Wer jetzt einen Brief ausdruckt, druckt ihn an welche Adresse?

Solche Situationen entstehen still. Niemand hat beschlossen, dass zwei Versionen desselben Eintrags existieren sollen. Es ergibt sich — weil verschiedene Personen in verschiedenen Programmen arbeiten und weil keine direkte Verbindung zwischen beiden besteht, die Änderungen überträgt. Daten, die an zwei Orten gepflegt werden, driften auseinander. Das ist ihr Normalzustand, keine Ausnahme.

Wenn Exportformate nicht zusammenpassen

Wenn Daten vom alten in das neue Programm übertragen werden sollen, wird oft mit Exporten gearbeitet: Das alte System gibt eine Datei aus, das neue liest sie ein. Klingt einfach.

In der Praxis sieht das meistens anders aus. Typische Probleme beim Datenumzug:

Das alte Programm exportiert Kundennummern sechsstellig ohne Präfix. Das neue erwartet sie achtstellig mit einem Buchstaben voran.
Telefonnummern stehen im alten System mit Leerzeichen, im neuen ohne — oder in einem Format, das nicht erkannt wird.
Straße und Hausnummer sind bei manchen Einträgen in einem Feld zusammengefasst, bei anderen getrennt — je nachdem, wer den Eintrag damals angelegt hat.
Kategorien, die das alte Programm kannte, gibt es im neuen nicht in dieser Form. Was passiert mit den Einträgen, die dieser Kategorie zugeordnet waren?
Einige Felder wurden im alten System nie konsequent gepflegt. Was leer ist, kann nicht übertragen werden — aber leer bedeutet in der Praxis oft: fehlend.

Jemand muss diese Datei vor dem Import durchgehen und bereinigen. Das ist keine Aufgabe, die eine Stunde dauert. Wer zweitausend oder dreitausend Einträge hat und jeden zweiten manuell prüfen muss, sitzt daran Tage. Diese Zeit taucht in keinem Angebot auf, weil sie nicht in den Händen des Anbieters liegt — sondern in denen des Betriebs.

Die Tabelle, die niemand beschlossen hat

In vielen Betrieben entsteht in dieser Phase ein drittes System — nicht gekauft, nicht beschlossen, sondern entstanden: eine Tabelle, die jemand pflegt.

Sie enthält die Fälle, die weder im alten noch im neuen Programm vollständig abgebildet sind. Vermerke wie „noch klären“ oder „Adresse stimmt nicht überein“. Spalten, die irgendwann hinzugefügt wurden, weil sie sonst nirgends Platz hatten. Diese Tabelle ist das inoffizielle Bindeglied, das Lücken füllt, die niemand geplant hatte.

Das Problem ist nicht, dass sie existiert. Das Problem ist, was passiert, wenn die Person, die sie führt, fehlt. Krankheit, Urlaub, ein Wechsel im Team — und niemand weiß mehr, was in der Tabelle steht, warum ein Eintrag so aussieht wie er aussieht, welche Fälle noch offen sind. Was als vorübergehende Brücke gedacht war, ist zu einem System geworden, das von einer einzelnen Person abhängt.

Zuständigkeiten, die kein Organigramm abdeckt

Ein weiteres Muster, das in dieser Phase entsteht: Wer entscheidet, was gilt, wenn beide Systeme sich widersprechen?

Wenn ein Auftrag im alten Programm als erledigt gilt, im neuen aber noch offen ist — was ist richtig? Wenn eine Rechnung im alten System ausgestellt wurde, das neue aber nichts davon weiß — wer klärt das, und wo hält er das Ergebnis fest?

Diese Fragen landen erfahrungsgemäß bei denjenigen, die am häufigsten mit dem jeweiligen Programm arbeiten. Also werden sie zwischen zwei Aufgaben entschieden, ohne Protokoll, ohne Rückmeldung. Drei Wochen später hat jemand anderes dieselbe Frage anders entschieden — in gutem Glauben, denn es gab keine Regel dafür. Beide Entscheidungen sind irgendwo dokumentiert. In verschiedenen Systemen, ohne Bezug zueinander.

Die Zuständigkeit für das, was zwischen zwei Programmen liegt, ist eine organisatorische Frage. Kein System — alt oder neu — kann entscheiden, wessen Version gilt. Das muss ein Mensch entscheiden. Und dafür braucht es eine Vereinbarung, die meistens fehlt.

Was Jahresauswertungen offenlegen

Besonders sichtbar wird das Dilemma am Jahresende oder wenn jemand Zahlen braucht. Wer wissen will, wie viele Aufträge in diesem Jahr bearbeitet wurden, welche Kunden wie oft nachgefragt haben oder wie sich die Auslastung entwickelt hat, muss in beiden Programmen nachschauen. Und dann die Zahlen irgendwie zusammenführen.

Das ist möglich, wenn man Zeit hat und weiß, was man sucht. Es scheitert still, wenn ein Vorgang im alten Programm anders kategorisiert ist als im neuen. Wenn jemand im Januar noch im alten und im Februar schon im neuen System erfasst hat. Wenn Zeiträume nicht exakt übereinstimmen.

Die Auswertung, die am Ende herauskommt, ist rechnerisch korrekt — aber sie bildet nicht vollständig ab, was wirklich passiert ist. Sie bildet ab, was in den Systemen steht. Das ist nicht immer dasselbe.

Was Altsysteme wirklich enthalten

Altsysteme gelten manchmal als das Veraltete: langsam, unmodern, irgendwann abzulösen. Aber in vielen Betrieben steckt in ihnen die gesamte Geschichte eines Unternehmens. Alle Aufträge der letzten zehn Jahre. Alle Kundenkontakte. Preisvereinbarungen. Sonderabsprachen, die irgendwann in ein Freitextfeld eingetragen wurden, weil es dafür kein eigenes Feld gab.

Diese Daten lassen sich nicht einfach verschieben. Sie wurden in einem Format erfasst, das das alte System verstand. Kategorien, die so nur intern existierten. Einträge, bei denen heute niemand mehr sagen kann, was sie bedeuten — außer der Person, die sie damals angelegt hat, und die vielleicht nicht mehr im Betrieb ist.

Wer diesen Aufwand unterschätzt, riskiert, dass das neue Programm gut funktioniert — aber nur für neue Vorgänge. Alles, was davor war, bleibt im alten System: irgendwann nicht mehr gepflegt, irgendwann nicht mehr zu öffnen, weil kein Rechner im Büro die nötige Software noch installiert hat.

Was am Ende des Parallelbetriebs zählt

Irgendwann endet der Parallelbetrieb. Entweder weil jemand die Entscheidung trifft, oder weil das alte Programm aus technischen Gründen nicht mehr funktioniert: Der Wartungsvertrag läuft aus, ein Betriebssystem-Update macht es inkompatibel, der Anbieter stellt den Support ein.

Was dann zählt, ist nicht, wie überzeugend das neue System in der Erstpräsentation wirkte. Es zählt:

Wie vollständig die Daten sind, die am Ende im neuen Programm stehen.
Ob offene Vorgänge aus dem alten System irgendwo nachvollzogen werden können.
Ob Kolleginnen und Kollegen wissen, wo sie was finden — oder ob sie sich im Zweifel noch immer im alten System orientieren.
Ob die Tabelle, die als inoffizielle Brücke entstanden ist, jemals konsolidiert wurde — oder ob sie still verschwunden ist, mitsamt den offenen Punkten, die darin standen.

Das ist der Teil des Systemwechsels, über den in Angeboten und Erstgesprächen wenig gesprochen wird. Nicht weil er unwichtig wäre, sondern weil er schwerer zu zeigen ist als eine neue Oberfläche. Eine Demo kann zeigen, wie das neue Programm aussieht. Sie kann nicht zeigen, wie viel Arbeit es bedeutet, acht Jahre Kundendaten in ein Format zu überführen, das das neue System versteht.

Die eigentliche Frage lautet nicht: Ist das neue Programm gut? Die Frage lautet: Was ist in den Wochen und Monaten des Übergangs mit den Daten passiert — und weiß das jemand genau?