Teil drei hat die Bereinigung abgeschlossen: Namen vereinheitlicht, Datumsangaben in einem Format, Zahlen, die tatsächlich Zahlen sind, und Bedeutungen, die früher in Zellfarben steckten, in beschriftete Felder überführt. Die Daten sind bereit für den Umzug. Bleibt die Entscheidung, die bestimmt, ob die Umstellung geräuschlos verläuft oder zu wochenlanger Verwirrung wird: Was wird zuerst migriert?

Es wirkt wie ein technisches Detail für denjenigen, der implementiert. Tatsächlich ist es eine betriebliche Entscheidung, und sie liegt bei Ihnen. Ihr Unternehmen wird für die Migration nicht pausieren. Kunden werden bestellen, Rechnungen werden verschickt, Lieferanten werden liefern – und das alles, während die Hälfte Ihrer Daten an einem Ort liegt und die andere Hälfte an einem anderen. Die richtige Reihenfolge macht diese Phase beherrschbar, statt dass alle eine Zeit lang doppelt arbeiten.

Warum der Umstieg auf einen Schlag nicht funktioniert

Der Impuls ist verständlich: alles übers Wochenende umziehen, am Sonntag mit dem neuen System öffnen, fertig. Dieses Szenario scheitert meist aus drei Gründen, die nichts mit der Qualität des Systems zu tun haben.

Erstens werden Sie während des Umzugs mehr entdecken, als Sie erwarten. Jede Migration bringt fehlende Daten ans Licht, die niemandem aufgefallen waren: ein Kunde ohne Steuernummer, ein Artikel ohne Mengeneinheit, eine Rechnung ohne Referenz. Ziehen Sie alles gemeinsam um, treffen all diese Entdeckungen gleichzeitig ein, im denkbar engsten Moment.

Zweitens lernt Ihr Team das System, während es damit arbeitet. Niemand beherrscht ein neues Werkzeug an einem Tag. Ein Umzug in einem Schritt verlangt von allen, alles gleichzeitig zu lernen; wenn dann ein Fehler auftaucht, können Sie nicht erkennen, woher er kommt: Sind die Daten falsch, ist das System falsch konfiguriert, oder hat der Mitarbeiter die Maske einfach noch nicht verstanden?

Drittens bleibt Ihnen kein Weg zurück. Taucht zwei Tage später ein grundlegender Fehler auf, können Sie nur noch durchziehen oder alles zurückdrehen, und beides ist teuer. Ein schrittweiser Umzug hält immer einen Teil des Geschäfts auf stabilem Boden. Das ist eines der Muster, die bei Systemprojekten, die ins Stocken geraten, immer wiederkehren: Schuld ist selten das Werkzeug, meist aber der Versuch, alles am selben Tag zu ändern.

Stammdaten vor Bewegungsdaten: die Regel, auf der die ganze Reihenfolge ruht

Ihre Daten gibt es in zwei Arten. Stammdaten: Kunden, Lieferanten, Artikel oder Dienstleistungen, Mitarbeiter, der Kontenplan. Und Bewegungsdaten: Rechnungen, Aufträge, Bestellungen, Lagerbewegungen, Belege.

Der Unterschied zwischen ihnen liegt nicht in der Wichtigkeit, sondern in der Richtung. Bewegungsdaten verweisen immer auf Stammdaten: Jede Rechnung verweist auf einen Kunden und auf Artikel, jede Bestellung auf einen Lieferanten. Umgekehrt ist das nie der Fall. Die Reihenfolge wird also von der Abhängigkeit bestimmt, nicht von Vorlieben: Migrieren Sie zuerst die Stammdaten, denn Bewegungsdaten können sich nicht auf etwas stützen, das nicht existiert.

Kehren Sie die Reihenfolge um, erhalten Sie den klassischen Fehler: Sie importieren dreitausend Rechnungen, das System legt für jeden darin geschriebenen Namen automatisch einen neuen Kunden an, und am Ende enthält Ihre Kundenliste dasselbe Unternehmen dreimal in drei Schreibweisen. Sie haben dann im System genau das Durcheinander nachgebaut, dessen Bereinigung Teil drei gewidmet war – nur ist die Korrektur jetzt schwieriger.

In der Praxis sieht die Reihenfolge so aus:

  • Erstens: die Kernentitäten. Kunden, Lieferanten, Artikel und Dienstleistungen. Kurze Listen, einmal migriert und per Augenschein geprüft. Das ist die Ebene, auf der alles andere steht.
  • Zweitens: die Eröffnungssalden. Was Ihnen jeder Kunde schuldet und was Sie jedem Lieferanten schulden, die Lagerbestände zum Startzeitpunkt, die Kontensalden. Das ist keine Historie; es ist der Nullpunkt, von dem aus das System startet. Wählen Sie dafür ein bestimmtes Datum und halten Sie daran fest.
  • Drittens: nur die offenen Vorgänge. Was gerade aktiv ist – noch nicht gelieferte Aufträge, noch nicht bezahlte Rechnungen, noch nicht eingegangene Bestellungen. Damit arbeitet das Team täglich, und es ist weit kleiner, als Sie sich vorstellen.
  • Zuletzt, und vielleicht nie: das historische Archiv. Abgeschlossene Rechnungen aus Vorjahren.

Das historische Archiv: die Frage, die Ihnen Wochen spart

Der größte Zeit- und Kostentreiber einer Migration ist das Beharren darauf, die gesamte Unternehmenshistorie ins neue System zu übertragen. Die Frage, die vor dieser Entscheidung stehen muss: Was werden Sie mit dieser Historie tatsächlich tun?

Lautet die Antwort „Wir brauchen sie zum Nachschlagen oder für eine gesetzliche Prüfung“, erfüllt das Archiv diese Funktion bereits, so wie es ist – im Originalformat aufbewahrt, an einem bekannten und durchsuchbaren Ort. Ihre gesetzliche Pflicht besteht darin, Rechnungen und Unterlagen aufzubewahren und sie auf Anforderung vorlegen zu können, wie es die Behörde für Zakat, Steuern und Zoll (ZATCA) festlegt, nicht darin, dass sie alle ausgerechnet im neuen System liegen.

Lautet die Antwort „Wir wollen Berichte, die dieses Jahr mit den Vorjahren vergleichen“, brauchen Sie einen Teil der Historie, nicht alles, und meist auf verdichteter Ebene statt jeder einzelnen Rechnungsposition. Der Unterschied zwischen diesen beiden Migrationen ist groß, beim Aufwand wie bei den Kosten.

Die Arbeitsregel: Migrieren Sie die Historie, auf die Sie eine Entscheidung stützen werden, und behalten Sie den Rest als Archiv. Machen Sie die Archivmigration nicht zur Voraussetzung für den Go-live – sie lässt sich später ohne Druck erledigen, während sich der Go-live nicht unbegrenzt verschieben lässt.

Parallelbetrieb: notwendig, und gefährlich, wenn er offen bleibt

Parallelbetrieb bedeutet, Vorgänge für einen festgelegten Zeitraum gleichzeitig im neuen System und in der alten Datei zu erfassen. Er hat einen ganz bestimmten Zweck: zu bestätigen, dass das System dieselben Ergebnisse liefert, die Sie bereits kennen. Sie vergleichen die Wochenumsätze, die Kundensalden, die Menge von einem oder zwei Artikeln. Stimmen die Zahlen überein, verhält sich das System korrekt; weichen sie ab, wissen Sie es, bevor jemand eine Entscheidung auf eine falsche Zahl stützt.

Doch Parallelbetrieb hat echte Kosten: Ihr Team arbeitet doppelt. Diese Kosten sind für zwei Wochen akzeptabel und über drei Monate zerstörerisch. Die Gefahr liegt nicht nur im Aufwand. Die Doppelerfassung beginnt nach einer Weile zu bröckeln – jemand erfasst an einer Stelle und verschiebt die andere –, sodass die beiden Datenbestände auseinanderlaufen und die Übung ihren Sinn völlig verliert, weil Sie nicht mehr wissen, welcher stimmt.

Daher die einzige Regel, die hier zählt: Parallelbetrieb mit einem Enddatum, das allen vom ersten Tag an mitgeteilt wird. Schreiben Sie das Datum auf, informieren Sie das Team und verlängern Sie nur durch eine ausdrückliche Entscheidung mit schriftlicher Begründung – niemals durch schleichendes Hinauszögern. Ein Zeitraum ohne Ende ist keine Vorsicht; er ist eine aufgeschobene Entscheidung, und er ist der häufigste Grund, warum ein neues System ein ganzes Jahr lang nur halb genutzt wird. Das gehört zur Change-Management-Arbeit, die wir ausführlich in unserem Leitfaden zur schrittweisen Einführung eines Systems behandeln.

Die Sicht von Origami

Wenn wir für ein Unternehmen, das mit Tabellen arbeitet, ein maßgeschneidertes System bauen, behandeln wir den Migrationsplan als Teil des Designs, nicht als Umsetzungsschritt am Projektende. Der Grund: Die Migrationsreihenfolge erzwingt Entscheidungen über die Struktur des Systems selbst – welche Entitäten eigenständig bestehen müssen, welche Felder vorübergehend unvollständig sein dürfen und wo wir wiederholbare Importe brauchen, die keine Datensätze duplizieren.

Außerdem legen wir mit dem Kunden vor dem Start das Datum fest, an dem die alte Datei geschlossen wird, denn erst dieses Datum macht aus dem Projekt statt eines Parallelexperiments eine tatsächliche Umstellung. Es ist derselbe Ansatz, den wir bei schrittweisen Digitalisierungs-Roadmaps verfolgen, und er zieht sich durch unsere Leistungen: Jede Phase liefert etwas, das funktioniert, kein Versprechen, dass am Ende alles funktionieren wird.

Das Signal, das Ihnen zeigt, dass der Umstieg gelungen ist

Ob die Umstellung funktioniert hat, erfahren Sie weder aus einem Abschlussbericht noch aus einem Migrationsprozentsatz. Sie erfahren es aus einem Verhalten, um das niemand gebeten hat: Ein Mitarbeiter hört auf, die alte Datei zu öffnen, ohne dass man es ihm sagt. Wenn das System zu dem wird, was die Leute morgens als Erstes öffnen, weil es der schnellere Weg zu dem ist, was sie brauchen, ist der Umstieg wirklich vollzogen. Wenn sie trotz vollständiger Migration jeden Morgen weiter die Datei öffnen, ist der Umstieg noch nicht passiert, egal, was die Fortschrittszahl sagt.

Achten Sie auf dieses Signal statt auf die Zahlen. Und wenn Sie merken, dass Leute zur alten Datei zurückkehren, ist der Grund meist kein Widerstand – sondern dass das System ihnen etwas nicht liefert, was sie brauchen, oder es langsam liefert oder mit mehr Schritten. Das ist eine behebbare Ursache, aber nur, wenn Sie sie früh erkennen und nachfragen.

In den kommenden Teilen

Die Daten sind in der richtigen Reihenfolge umgezogen, und es taucht eine Frage auf, die es in der Welt der Dateien nicht gab: Wer eine Datei öffnet, sieht alles darin, während ein System entscheidet, wer was sieht. Im nächsten Teil geht es um Berechtigungen – Gehaltsabrechnung, Margen und Kundendaten, und wer was davon sehen darf. Danach widmen wir uns den Berichten, die Sie bisher jeden Monat von Hand erstellt haben, und schließen die Serie mit den ersten dreißig Tagen nach dem Umstieg ab.

Quellen