Der mutigste Plan in einem unserer Projekte war, das achtzehn Jahre alte ERP an einem einzigen Wochenende abzulösen. Freitagabend das Altsystem aus, übers Wochenende migrieren, Montagfrüh läuft alles neu. Auf der Folie war das ein eleganter Schnitt: ein Stichtag, ein klarer Bruch, danach ist die Altlast Geschichte. Der mutigste Plan war es. Der klügste war es nicht. Denn an diesem Montagmorgen wäre alles gleichzeitig neu gewesen — die Oberfläche, die Daten, die Schnittstellen, die Prozesse, die Rechte. Und wenn irgendetwas davon klemmt, klemmt es nicht an einer Stelle, sondern überall auf einmal, und niemand weiß, wo er anfangen soll.
Wenn im Mittelstand ein altes System weg soll, denken alle an dieses eine Bild: das Neue ersetzt das Alte, an einem Datum, das im Projektplan rot markiert ist. Die Geschäftsführung mag den Stichtag, weil er sauber aussieht und sich kommunizieren lässt. Der Hersteller des Altsystems hat gerade das Support-Ende angekündigt, und plötzlich soll alles sofort neu. Der Head of Operations sitzt daneben und denkt an etwas anderes, weil er nicht die Folie verantwortet, sondern den Betrieb. Er weiß: An dem Wochenende, an dem alles gleichzeitig umgestellt wird, schläft niemand. Und am Montag steht er gerade, nicht die Folie.
Warum der Stichtag das eigentliche Risiko ist
Ein Big-Bang-Austausch konzentriert das gesamte Risiko eines Projekts auf einen einzigen Punkt in der Zeit. Über Monate baut man das neue System, migriert Daten, schreibt Schnittstellen nach — und nichts davon läuft im echten Betrieb, bis der Schalter umgelegt ist. Bis dahin ist jeder Test ein Test gegen Annahmen, nie gegen die Wirklichkeit. Der erste echte Lasttag ist zugleich der Tag, an dem es kein Zurück mehr gibt. Wer schon einmal an einem solchen Montag im Serverraum stand, kennt das Gefühl: Es gibt keinen kleinen Fehler mehr. Jeder Fehler ist ein Produktionsausfall, weil das alte System, das ihn aufgefangen hätte, gestern abgeschaltet wurde.
Das achtzehn Jahre alte ERP ist dabei nicht nur eine Software. Es ist achtzehn Jahre stiller Sonderfälle. Die eine Buchungslogik, die ein Kollege 2011 für genau einen Großkunden eingebaut hat. Das Feld, das offiziell den Lagerort meint und inoffiziell seit Jahren als Vermerk für den Außendienst dient. Die nächtliche Routine, die niemand mehr anfasst, weil keiner mehr genau weiß, was sie tut — nur dass die Buchhaltung anruft, wenn sie ausfällt. Diese achtzehn Jahre stehen in keiner Spezifikation. Sie stehen im laufenden System, und ein Big Bang zwingt einen, sie alle gleichzeitig richtig zu treffen. An einem Wochenende.
Nicht jedes Legacy-System muss sofort ersetzt werden.
Das Projekt, in dem wir den Schalter nicht umgelegt haben
In einem unserer Projekte stand genau diese Entscheidung an. Ein gewachsenes ERP, Kern des Betriebs, rund 4.000 Aufträge im Monat, dazu Lager, Einkauf, Faktura — alles in einem System, das seit achtzehn Jahren lief und das niemand mehr in Gänze erklären konnte. Der Auslöser war banal und drängend zugleich: Der Hersteller hatte das Wartungsende auf das kommende Jahr datiert. Die Geschäftsführung wollte daraufhin den großen Wurf: neues ERP, Stichtag, fertig. Der Head of Operations hat nicht widersprochen. Er hat eine andere Frage gestellt. Welcher Teil dieses Systems macht uns gerade wirklich Schmerzen — und welcher läuft einfach?
Die ehrliche Antwort war ernüchternd für den großen Plan. Der Schmerz saß nicht im ganzen ERP. Er saß an drei Stellen: Die Auftragserfassung war zäh und für neue Mitarbeiter kaum zu lernen. Die Berichte kamen zu spät und in Formaten, die niemand mehr brauchte. Und eine Schnittstelle zum Versand war so brüchig, dass sie jeden Monat einmal von Hand nachgezogen werden musste. Der Rest — Buchungslogik, Lagerverwaltung, Stammdatenkern — lief unspektakulär seit Jahren. Niemand wachte nachts auf, weil die Lagerbuchung nicht funktionierte. Sie funktionierte einfach.