Modernisierung eines 12 Jahre alten Lagersystems, ohne die Lkw zu stoppen

Die gefährlichste Software in einem kleinen Unternehmen ist die Software, die funktioniert. Nicht das fehlerhafte Werkzeug, über das sich alle beschweren – das wird irgendwann ersetzt. Gefährlich ist das zwölf Jahre alte System, das niemand liebt, aber von dem alle abhängen: das System, das von einem beigefarbenen Tower in der Ecke startet und das Lager schon steuerte, bevor die Hälfte des Teams eingestellt wurde. Es funktioniert. Bis zu dem Tag, an dem es das fast nicht mehr tut, und allen auf einmal klar wird, dass das gesamte Geschäft darauf balanciert.

Das ist die Geschichte eines solchen Systems und wie wir es ersetzt haben. Der Kunde ist ein regionaler Distributor – einige Tausend Artikellinien, ein einziges Lager, rund dreißig Mitarbeitende in der Halle und im Büro. Wir haben sie anonymisiert und die Zahlen gerundet, aber der Verlauf des Projekts ist genau so geschehen. Wenn Sie auf einem alternden System sitzen, das Sie nicht anzufassen wagen, dann sieht eine vernünftige Modernisierung von innen ungefähr so aus.

In dieser Geschichte gibt es keine heroische Neuentwicklung, kein Wochenende, an dem wir einen Schalter umlegten und alles neu war. Der entscheidende Punkt – das, was es funktionieren ließ – ist, dass nichts Dramatisches passiert ist. Die Lkw wurden weiter beladen. Das Lager bemerkte kaum, dass sich der Boden unter ihm verschob. Genau das ist das Ziel bei Legacy-Arbeit, und es lohnt sich zu verstehen, warum.

Die Ausgangslage: ein System, zusammengehalten vom Gedächtnis einer einzigen Person

Das Lager lief auf einem maßgeschneiderten System, das um 2013 von einem Entwickler gebaut wurde, der längst weitergezogen war. Es erfüllte die Kernaufgabe – Bestände verfolgen, Kommissionierlisten drucken, Aufträge hinausschicken – und an einem normalen Tag tat es das einwandfrei. Das Problem war nicht wirklich die Software. Das Problem war alles, was rund um die Software gewachsen war, um sie nutzbar zu halten.

Über ein Jahrzehnt hatte das Team still ein Schattensystem aus Klebeband zusammengebaut: eine Tabelle für die Bestandszählungen, die die Software falsch erfasste, eine zweite Tabelle, die die erste mit der Realität abglich, eine WhatsApp-Gruppe, in der der Lagerleiter Artikel meldete, die das System nicht abbilden konnte, und ein gedruckter Ordner mit Behelfslösungen, die neue Mitarbeitende auswendig lernen mussten. Nichts davon war an einer Stelle dokumentiert. Es lebte im Kopf der Betriebsleiterin, einer ruhigen Frau Mitte fünfzig, die seit vierzehn Jahren dort war und faktisch die Dokumentation darstellte.

Als der Inhaber uns zuerst anrief, lag es nicht an einem Absturz. Es lag daran, dass sie angekündigt hatte, in zwei Jahren in Rente gehen zu wollen, und er sich ausgerechnet hatte, dass an dem Tag, an dem sie ginge, ein erheblicher Teil davon, wie das Lager tatsächlich funktionierte, mit ihr aus der Tür gehen würde. Das ist ein häufigerer Auslöser für Modernisierung als jeder technische Defekt: nicht das System, das kaputtgeht, sondern die Erkenntnis, dass die Menschen, die es flicken, nicht ewig da sein werden.

Die Symptome, die alle nicht mehr wahrnahmen

Als wir unsere ersten zwei Tage einfach damit verbrachten, dem Lager bei der Arbeit zuzusehen, waren die Kosten des alten Systems überall sichtbar – aber sie waren so normal geworden, dass niemand sie noch als Probleme benannte. Den Bestandszahlen vertraute man so weit, dass sie um eine vorhersehbare Spanne falsch waren, weshalb jeder große Auftrag „sicherheitshalber“ manuell physisch geprüft wurde. Neue Mitarbeitende brauchten Wochen, um nützlich zu werden, weil so viel an der Arbeit ungeschriebenes Erfahrungswissen war. Und das System lief auf einem Betriebssystem, das so alt war, dass es nicht mehr gepatcht werden konnte – in einem Netzwerk, von dem der Inhaber insgeheim wusste, dass es ein Sicherheitsvorfall im Wartezustand war.

• Die Bestandsgenauigkeit lag bei rund 80 %, also prüften die Mitarbeitenden bei allem Wichtigen die Zählungen still von Hand nach – täglich Stunden.
• Die Logik der Kommissionierliste kam mit dem aktuellen Lagerlayout nicht zurecht, also liefen die Kommissionierer die Route, die der Ordner vorgab, nicht der Bildschirm.
• Die Bestandsabstimmung zum Monatsende beschäftigte zwei Personen den besseren Teil von drei Tagen.
• Nur ein einziger Rechner konnte die Administrationsseite der Software ausführen, und wenn er ausfiel, hatte niemand einen klaren Plan.
• Nichts war an den Online-Bestellkanal angebunden, den das Unternehmen 2019 hinzugefügt hatte – diese Bestellungen wurden von Hand neu eingetippt.

Was wir bewusst nicht getan haben

Der naheliegende Schritt – den viele Anbieter vorgeschlagen hätten – ist, eine große Lagerverwaltungsplattform von der Stange zu kaufen, an einem Wochenende alles zu migrieren und das alte System am Montagmorgen abzuschalten. Wir haben diesen Ansatz oft genug schiefgehen sehen, dass wir ihn für ein Unternehmen wie dieses nicht vorschlagen würden. Eine Big-Bang-Umstellung setzt voraus, dass man das alte System vollständig versteht. Mit einem Jahrzehnt undokumentierter Behelfslösungen tat das niemand – nicht einmal die Leute, die es betrieben.

Der zweite verlockende Schritt ist eine vollständige Neuentwicklung von Grund auf: alles nehmen, was das alte System tut, es sauber neu bauen und das Neue ausliefern. Das klingt verantwortungsvoll und ist eine klassische Art, ein Jahr und ein großes Budget zu verbrennen, während das Unternehmen eingefroren auf einen Ersatz wartet, der sich immer weiter verzögert. Das Problem ist, dass eine Neuentwicklung jede Eigenheit reproduzieren muss, bevor sie starten kann – einschließlich der Eigenheiten, von denen niemand mehr weiß, dass sie tragend sind, bis sie fehlen.

Also taten wir keines von beidem. Wir behandelten das alte System nicht als etwas, das man abreißt, sondern als etwas, das man umgibt und langsam ersetzt – eine Fähigkeit nach der anderen, mit dem alten System, das die ganze Zeit als Sicherheitsnetz darunter weiterlief. Unglamourös. Und zugleich die einzige Variante davon, die zuverlässig funktioniert.

Der Ansatz: das alte System umranken, nicht sprengen

Unter Entwicklern gibt es für dieses Muster einen eingebürgerten Namen – den „Strangler“-Ansatz, benannt nach einer Würgepflanze, die einen Baum umwächst, bis sie allein stehen kann und das Original still verschwindet. Man ersetzt das alte System nicht in einem Zug. Man baut neue Teile darum herum, leitet echte Arbeit Stück für Stück darauf um und lässt das alte System schrumpfen, bis das Verbliebene klein genug ist, um es abzuschalten, ohne dass jemand den Atem anhält.

Für dieses Lager hieß das, vorab eine Reihenfolge zu vereinbaren: welche Fähigkeit wir zuerst ablösen, welche wir uns für zuletzt aufheben und – entscheidend – die Regel, dass wir in jeder Phase, falls sich das neue Teil daneben benahm, noch am selben Tag direkt auf den alten Weg zurückfallen konnten. Kein Schritt durfte bis ganz zum Ende ein Punkt ohne Wiederkehr sein. Genau diese eine Regel ließ den Inhaber schlafen und ließ die Lagermitarbeitenden dem Projekt vertrauen, statt sich dagegen zu stemmen.

1. 1
   Abbilden, was das System wirklich tut

   Drei Wochen, in denen wir Halle und Büro begleiteten, um den echten Arbeitsablauf zu dokumentieren – einschließlich jeder Tabellen- und Ordner-Behelfslösung. Wir schrieben das System auf, das existierte, nicht das, das die ursprüngliche Spezifikation beschrieb.
2. 2
   Die Daten vor dem Umzug bereinigen

   Wir führten eine vollständige physische Bestandszählung durch und bereinigten die Produktdatenbank dagegen. Schmutzige Daten in ein neues System zu migrieren liefert nur schneller die falsche Antwort – deshalb kam das, bevor neue Software die Daten überhaupt berührte.
3. 3
   Das schmerzhafteste Stück zuerst ersetzen

   Wir bauten das neue Modul für Bestandsführung und -zählung, ließen es parallel zum alten laufen und vertrauten ihm erst, als die Zahlen einen ganzen Monat lang mit der Realität übereinstimmten.
4. 4
   Die Kanäle anbinden, die das alte System ignorierte

   Als Nächstes verdrahteten wir den Online-Bestellkanal direkt mit den neuen Bestandsdaten und beendeten das manuelle Neueintippen, das seit 2019 still bestanden hatte.
5. 5
   Den Rest ablösen, dann den alten Kern ausmustern

   Kommissionierung, Reporting und Abstimmung zogen eines nach dem anderen um. Als auf dem alten System fast nichts Echtes mehr lief, schalteten wir es schließlich ab – bis dahin ein Nicht-Ereignis.

Die Teile, die wirklich schwer waren

Es wäre unredlich, das als reibungslos darzustellen. Die technische Arbeit war der einfache Teil. Die schweren Teile waren menschlich und prozessual – und es sind dieselben schweren Teile in fast jedem Legacy-Projekt.

Die undokumentierte Regel, die eine Funktion brach

Zwei Wochen nachdem das neue Bestandsmodul parallel lief, drifteten die Zahlen für eine Produktkategorie auseinander, und wir konnten nicht erkennen, warum. Nach einem Tag des Grabens erwähnte die Betriebsleiterin fast beiläufig, dass bestimmte Großgebinde nach Palette gezählt würden, nicht nach Stück, und dass das alte System eine versteckte Umrechnung eingebaut hatte, die in einem Jahrzehnt niemand dokumentiert hatte. Sie stand in keiner Spezifikation. Sie lebte nur in ihrem Kopf und im Ordner. Aus dem Code allein hätten wir sie nie gefunden – nur dadurch, dass wir beide Systeme nebeneinander laufen ließen und fragten, warum sie sich widersprachen. Das ist das gesamte Argument für den Parallelbetrieb in einer Anekdote.

Die Halle überzeugen

Die Lagermitarbeitenden hatten mehr als eine gut gemeinte „Verbesserung“ überstanden, die ihren Arbeitstag verschlechterte, also begegneten sie dem Projekt mit berechtigtem Argwohn. Wir bekämpften das nicht mit einer Präsentation. Wir suchten den Kommissionierer aus, der am lautesten klagte, setzten uns einen Vormittag lang zu ihm und bauten den Kommissionierbildschirm um die Art herum neu, wie er tatsächlich durch die Halle lief. Sobald er das neue System im Pausenraum verteidigte, folgte der Rest. In Legacy-Projekten wird der härteste Kritiker, einmal gewonnen, zu Ihrem besten Fürsprecher – und das kann man mit keinem Rundschreiben kaufen.

Die Ergebnisse, ein Jahr später

Wir sind vorsichtig mit glänzenden Vorher-Nachher-Zahlen, denn jedes Unternehmen misst anders, und bei Ihnen wird es abweichen. Behandeln Sie diese also als ehrliche, gerundete Zahlen aus einem Projekt, gedacht, um die Form des Ertrags zu zeigen statt ein Versprechen. Die Schlagzeile dreht sich weniger um eine einzelne Kennzahl als darum, was aufhörte, beängstigend zu sein.

Die Zahl, die dem Inhaber am wichtigsten war, stand auf keinem Diagramm. Sie bestand darin, dass das Lager, als die Betriebsleiterin tatsächlich in Rente ging – wie sich herausstellte, einige Monate früher als geplant –, nicht einmal wankte. Das Wissen, das früher in ihrem Kopf lebte, lebte nun in einem System, auf das jeder in Tagen eingelernt werden konnte. Der ursprüngliche Grund für das ganze Projekt war still und vollständig gelöst.

Wenn Sie auf einem solchen System sitzen

Die meisten Inhaber mit einem alternden Kernsystem fühlen zwei Dinge gleichzeitig: Es ist riskant, es zu behalten, und es ist beängstigend, es zu ersetzen. Beides stimmt. Der Fehler ist, die zweite Furcht gewinnen zu lassen, denn das Risiko des alten Systems bleibt nicht stabil – es wächst still mit jedem Jahr, während die Menschen, die es verstehen, dem Ausscheiden näherkommen und die Plattform, auf der es läuft, immer weiter aus dem Support driftet.

Sie müssen sich nicht zwischen „in Ruhe lassen und beten“ und „die Firma auf eine große Neuentwicklung verwetten“ entscheiden. Der mittlere Weg – es umgeben, Stück für Stück ersetzen, das alte als Netz behalten, bis sich das neue Vertrauen verdient hat – ist langsamer und weit weniger heroisch. Es ist auch die Variante, die die Lkw nicht stoppt. Wenn Sie aus dieser ganzen Geschichte eines mitnehmen, dann das.

Häufige Fragen