Een 12 jaar oud magazijnsysteem moderniseren zonder de vrachtwagens stil te leggen

De gevaarlijkste software in een klein bedrijf is de software die werkt. Niet de gammele tool waar iedereen over klaagt — die wordt uiteindelijk wel vervangen. De gevaarlijke is het twaalf jaar oude systeem dat niemand mooi vindt maar waar iedereen van afhankelijk is, dat opstart vanaf een beige toren in de hoek en het magazijn al draaiende houdt sinds voor de helft van het team werd aangenomen. Het werkt. Tot de dag dat het bijna niet meer werkt, en iedereen tegelijk beseft dat het hele bedrijf erop balanceert.

Dit is het verhaal van zo'n systeem, en hoe we het vervingen. De klant is een regionale distributeur — een paar duizend productlijnen, één magazijn, zo'n dertig mensen op de vloer en op kantoor. We hebben hen geanonimiseerd en de cijfers afgerond, maar de vorm van het project is precies zoals het ging. Zit u op een verouderend systeem dat u niet durft aan te raken, dan ziet een verstandige modernisering er van binnenuit ongeveer zo uit.

Er zit geen heroïsche herschrijving in dit verhaal, geen weekend waarin we een knop omzetten en alles nieuw was. Het hele punt — juist datgene wat het deed werken — is dat er niets dramatisch gebeurde. De vrachtwagens bleven laden. Het magazijn merkte amper dat de vloer onder hen verschoof. Dat is het doel bij legacy-werk, en het is de moeite waard te begrijpen waarom.

De situatie: een systeem dat draait op het geheugen van één persoon

Het magazijn draaide op een maatwerksysteem dat rond 2013 was gebouwd door een ontwikkelaar die allang weg was. Het deed het kernwerk — voorraad bijhouden, piklijsten printen, orders de deur uit krijgen — en op een normale dag deed het dat prima. Het probleem was eigenlijk niet de software. Het probleem was alles wat er omheen was gegroeid om het bruikbaar te houden.

In ruim tien jaar had het team stilletjes een schaduwsysteem van plakband opgebouwd: een spreadsheet voor de voorraadtellingen die de software fout had, een tweede spreadsheet die de eerste afstemde op de werkelijkheid, een WhatsApp-groep waarin de magazijnchef items aanmerkte die het systeem niet kon weergeven, en een geprinte map met workarounds die nieuwe medewerkers uit het hoofd moesten leren. Niets daarvan stond op één plek beschreven. Het zat in het hoofd van de operationeel manager, een kalme vrouw van in de vijftig die er veertien jaar werkte en, functioneel gezien, de documentatie wás.

Toen de eigenaar ons voor het eerst belde, was het niet vanwege een crash. Het was omdat ze had aangekondigd over twee jaar met pensioen te willen, en hij had de rekensom gemaakt en besefte dat de dag dat zij vertrok, een flink stuk van hoe het magazijn werkelijk functioneerde met haar mee de deur uit zou lopen. Dat is een vaker voorkomende aanleiding voor modernisering dan welke technische storing ook: niet dat het systeem stukgaat, maar het besef dat de mensen die het oplappen er niet eeuwig zullen zijn.

De symptomen die iedereen niet meer opmerkte

Toen we onze eerste twee dagen alleen maar naar het magazijn keken, waren de kosten van het oude systeem overal zichtbaar — maar zo normaal geworden dat niemand ze nog als probleem aanmerkte. Van voorraadcijfers nam men aan dat ze met een voorspelbare marge fout waren, dus elke grote order kreeg 'voor de zekerheid' een handmatige fysieke controle. Nieuw personeel had weken nodig om bruikbaar te worden omdat zoveel van het werk ongeschreven overlevering was. En het systeem draaide op een besturingssysteem dat zo oud was dat het niet meer van patches kon worden voorzien, op een netwerk waarvan de eigenaar stilletjes wist dat het een beveiligingsincident in wording was.

• De voorraadnauwkeurigheid schommelde rond de 80%, dus medewerkers controleerden tellingen van alles wat belangrijk was met de hand — dagelijks uren, in stilte.
• De logica van de piklijst kon de huidige magazijnindeling niet aan, dus pikkers liepen de route die de map voorschreef, niet het scherm.
• De maandelijkse voorraadafstemming kostte twee mensen het grootste deel van drie dagen.
• Slechts één machine kon de beheerkant van de software draaien, en als die ermee ophield, had niemand een duidelijk plan.
• Niets was gekoppeld aan het online verkoopkanaal dat het bedrijf in 2019 had toegevoegd — die orders werden met de hand overgetypt.

Wat we bewust niet deden

De voor de hand liggende zet — die veel leveranciers zouden hebben gepitcht — is een groot magazijnbeheerplatform van de plank kopen, in één weekend alles overzetten en maandagochtend het oude systeem uitschakelen. We hebben die aanpak vaak genoeg fout zien gaan om hem voor zo'n bedrijf niet voor te stellen. Een big-bang-overgang gaat ervan uit dat u het oude systeem volledig begrijpt. Met tien jaar ongedocumenteerde workarounds deed niemand dat — zelfs de mensen die het draaiende hielden niet.

De tweede verleidelijke zet is een volledige herschrijving op maat vanaf nul: neem alles wat het oude systeem doet, bouw het schoon opnieuw, lever het nieuwe op. Dat klinkt verantwoord en het is een klassieke manier om een jaar en een fors budget op te branden terwijl het bedrijf bevroren wacht op een vervanging die steeds uitloopt. Het probleem is dat een herschrijving elke eigenaardigheid moet reproduceren voordat hij kan starten — inclusief de eigenaardigheden waarvan niemand zich herinnert dat ze dragend zijn, totdat ze ontbreken.

Dus deden we geen van beide. We behandelden het oude systeem niet als iets om af te breken, maar als iets om te omsingelen en langzaam te vervangen — één capaciteit per keer, met het oude systeem dat de hele weg eronder bleef draaien als vangnet. Onglamoureus. Ook de enige versie hiervan die betrouwbaar werkt.

De aanpak: wurg het oude systeem, blaas het niet op

Onder ontwikkelaars heeft dit patroon een ingeburgerde naam — de 'strangler'-aanpak, genoemd naar een liaan die rond een boom groeit tot hij op eigen benen kan staan en het origineel stilletjes verdwijnt. U vervangt het oude systeem niet in één zet. U bouwt nieuwe onderdelen eromheen, leidt echt werk er één voor één naartoe, en laat het oude systeem krimpen tot wat overblijft klein genoeg is om uit te zetten zonder dat iemand zijn adem inhoudt.

Voor dit magazijn betekende dat vooraf een volgorde afspreken: welke capaciteit we eerst zouden afpellen, welke we voor het laatst bewaarden, en — cruciaal — een regel dat we bij elke stap, als het nieuwe onderdeel zich misdroeg, diezelfde dag terug konden vallen op de oude manier. Geen enkele stap mocht een punt van geen terugkeer zijn tot helemaal aan het eind. Juist die regel liet de eigenaar slapen, en liet het magazijnpersoneel het project vertrouwen in plaats van zich ertegen schrap te zetten.

1. 1
   Breng in kaart wat het systeem werkelijk doet

   Drie weken meelopen op de vloer en kantoor om de echte workflow te documenteren — inclusief elke spreadsheet- en map-workaround. We schreven het systeem op dat bestond, niet het systeem dat de oorspronkelijke specificatie beschreef.
2. 2
   Maak de data schoon voordat u die verplaatst

   We hielden een volledige fysieke voorraadtelling en schoonden de productdatabase daartegen. Vuile data naar een nieuw systeem migreren geeft u alleen sneller een fout antwoord — dus dit kwam vóór enige nieuwe software de data raakte.
3. 3
   Vervang het pijnlijkste onderdeel eerst

   We bouwden de nieuwe module voor voorraadregistratie en -telling, draaiden die parallel aan de oude, en vertrouwden hem pas toen de cijfers een volle maand met de werkelijkheid overeenkwamen.
4. 4
   Verbind de kanalen die het oude systeem negeerde

   Vervolgens koppelden we het online verkoopkanaal rechtstreeks aan de nieuwe voorraaddata, waarmee het handmatige overtypen verdween dat stilletjes sinds 2019 bestond.
5. 5
   Pel de rest af en stoot dan de oude kern af

   Picken, rapportage en afstemming gingen één voor één over. Toen er bijna niets echts meer op het oude systeem draaide, zetten we het eindelijk uit — toen al een non-event.

De delen die echt lastig waren

Het zou oneerlijk zijn dit als soepel voor te stellen. Het technische werk was het makkelijke deel. De lastige delen waren menselijk en procedureel, en het zijn dezelfde lastige delen bij vrijwel elk legacy-project.

De ongedocumenteerde regel die een functie brak

Twee weken nadat de nieuwe voorraadmodule parallel draaide, liepen de cijfers voor één productcategorie uiteen en we zagen niet waarom. Na een dag spitten merkte de operationeel manager bijna terloops op dat bepaalde bulkartikelen per pallet werden geteld, niet per stuk, en dat het oude systeem een verborgen omrekening had ingebakken die in tien jaar nooit iemand had gedocumenteerd. Het stond in geen enkele specificatie. Het zat alleen in haar hoofd en in de map. We hadden het nooit uit de code alleen gevonden — alleen door beide systemen naast elkaar te draaien en te vragen waarom ze van elkaar verschilden. Dat is het hele argument voor parallel draaien in één anekdote.

De vloer voor je winnen

Het magazijnpersoneel had meer dan één goedbedoelde 'verbetering' overleefd die hun dag erger maakte, dus zij ontvingen het project met begrijpelijke argwaan. We bestreden dat niet met een presentatie. We kozen de pikker die het hardst klaagde, gingen een ochtend bij hem zitten en herbouwden het pikscherm rond hoe hij de vloer werkelijk afliep. Toen hij het nieuwe systeem in de kantine begon te verdedigen, volgde de rest. Bij legacy-projecten wordt de moeilijkste criticus, eenmaal gewonnen, uw beste pleitbezorger — en dat koopt u niet met een memo.

De resultaten, een jaar later

We zijn op onze hoede voor glanzende voor-en-na-cijfers, want elk bedrijf meet anders en bij u zullen ze afwijken. Beschouw deze dus als eerlijke, afgeronde cijfers uit één project, bedoeld om de vorm van het rendement te tonen, niet als belofte. De kern gaat minder over een enkele meetwaarde en meer over wat ophield eng te zijn.

Het cijfer waar de eigenaar het meest om gaf, stond op geen enkele grafiek. Het was dat toen de operationeel manager daadwerkelijk met pensioen ging — een paar maanden eerder dan gepland, zo bleek — het magazijn niet eens wankelde. De kennis die vroeger in haar hoofd zat, zat nu in een systeem waarin iedereen in een paar dagen kon worden ingewerkt. De oorspronkelijke reden voor het hele project was stilletjes, volledig opgelost.

Als u op zo'n systeem zit

De meeste ondernemers met een verouderend kernsysteem voelen twee dingen tegelijk: het is riskant om te houden, en het is angstaanjagend om te vervangen. Beide zijn waar. De fout is de tweede angst te laten winnen, want het risico van het oude systeem blijft niet stabiel — het groeit elk jaar stilletjes, naarmate de mensen die het begrijpen dichter bij hun vertrek komen en het platform waarop het draait verder uit de ondersteuning drijft.

U hoeft niet te kiezen tussen 'laat het met rust en bid' en 'zet het bedrijf in op een grote herschrijving'. De middenweg — omsingel het, vervang het stuk voor stuk, houd het oude als vangnet tot het nieuwe vertrouwen heeft verdiend — is trager en veel minder heroïsch. Het is ook de versie die de vrachtwagens niet stillegt. Als er één ding uit dit hele verhaal te halen valt, is het dat.

Veelgestelde vragen