Waarom lopen WMS-implementaties uit?

De stuurgroep wil weten waarom. Een WMS implementatie uitloop wordt zichtbaar in de testfase, maar daar ontstaat hij niet. Hij ontstaat maanden eerder, in een overleg waarin iemand zei: dat pakken we mee tijdens het testen. Niemand schrok ervan. Het stond niet op de risicolijst. Het was gewoon een zin.

En die start kennen we allemaal. Het ontwerp klopt. De businesscase is rond. Groen licht. Maar groen in een testomgeving betekent dat het systeem het met zichzelf eens is. Niet met de vloer.

Wat ik in de praktijk zie: een implementatie loopt niet uit omdat het werk langer duurt dan geraamd. Hij loopt uit omdat beslissingen die vroeg genomen moesten worden, laat worden genomen. En laat is duurder. Veel duurder.

In de concept- en requirementsfase leg je vast wat de klant echt nodig heeft, en waar dat afwijkt van je standaard. Elke afwijking is een gap. Een gap die je benoemt is een keuze: bouwen, anders inrichten, of niet doen. Een gap die je niet benoemt is geen keuze. Dat is een verrassing met een datum eraan, en die datum valt in de testfase. Vrijwel altijd.

Het Customer Concept Document is de belangrijkste gate van de hele implementatie. Tegelijk is het de gate die het makkelijkst zacht wordt gemaakt.

Je herkent het meteen. Het CCD wordt getekend onder voorbehoud van de laatste detaillering. Er loopt nog een discussie over labels. Twee ordersoorten zijn nog niet uitgewerkt. De facturatieregels komen later. Dat is geen sign-off. Dat is een lijst openstaande beslissingen met een handtekening eroverheen. En dan begint de configuratie, op een fundament dat nog beweegt.

Masterdata is bijna overal het werk dat bij iemand belandt zonder mandaat en zonder tijd. Item-master, klant-master, houdbaarheids- en allocatieregels, labels, SSCC-registratie. Het is veel, het is saai, en het is precies het soort werk dat pas fout blijkt als je erop gaat testen. Test je met onvolledige data, dan test je niet. Dan bevestig je alleen dat het systeem opstart.

Hetzelfde geldt voor het testplan zelf. De meeste plannen bewijzen dat een order netjes door het proces loopt. Prima, dat is dag één. Wat je moet weten is wat er gebeurt bij volume, bij pieken, bij een verkeerde volgorde, een geweigerde pallet, een koppelvlak dat twintig minuten stilvalt. Capaciteits- en sequencingtests horen erbij, en interfacetesten met echte berichtstructuren, niet met een keurig voorbeeldbestand van de leverancier.

FAT bewijst dat het systeem in een gecontroleerde omgeving aan de specificatie voldoet. SIT bewijst dat de interfaces met elkaar praten. UAT bewijst dat gebruikers de afgesproken processen kunnen uitvoeren. Elke fase is nodig. Geen van die fases bewijst automatisch dat het geïnstalleerde systeem overeenkomt met het fysieke magazijn. Dat is wat de SAT, de site acceptance test, hoort bloot te leggen. Een groene UAT is geen bewezen SAT.

Het klassieke voorbeeld: de fysieke rekletiketten sluiten niet schoon aan op de locaties in de WMS-configuratie. Een klein verschil in formattering. De UAT kwam er niet doorheen, want die testte alleen de systeemkant. Het verschil komt pas boven als een echte scanner op go-livemorgen een echt label leest, en een ontbrekende of verkeerd geformatteerde locatieregel is dan geen dataprobleem meer maar een rij pallets bij ontvangst.

Vier dingen moeten op één lijn liggen: het label op het rek, de scanner in de hand, de locatie in het WMS en het werkelijke vak op de vloer. Liggen ze dat niet, dan krijgen orderpickers foutmeldingen, wachten pallets, bouwen supervisors work-arounds en worden consultants teruggehaald. De weken erna heten hypercare, terwijl een deel van dat werk eigenlijk acceptatietesten is die te laat plaatsvindt.

Dit is de stilste oorzaak van uitloop, en de meest structurele. IT, de MHE-leverancier en de operatie werken alle drie hard. Alle drie gaan ze ervan uit dat een ander het koppelvlak trekt. Er hangt geen naam aan. Er hangt een leveranciersnaam aan, en dat is iets anders. Bij NewCold heb ik geleerd dat interface-management een rol is, geen document. Iemand moet IT, MHE en operatie aan tafel houden tot de berichten kloppen. Niet als technisch specialist, wel als degene die het eigenaarschap belegt en niet meer loslaat.

Dezelfde leegte zit aan de acceptatiekant. Een WMS-project heeft een projectmanager, key users en een leverancier. Wat vaak ontbreekt, is één operationele eigenaar die standaardproces, klantbelofte en de realiteit op de vloer bij elkaar brengt, en die de fysieke acceptatie bezit, niet alleen de functionele aftekening.

Vóór go-live is er één vraag die meer waard is dan nog een groen testrapport: wie heeft fysiek bevestigd dat het rekletiket in het gebouw, met de scanner, tegen de echte configuratie, oplost naar de juiste WMS-locatie? Zit er geen naam aan die check, dan heb je geen acceptatie. Dan heb je een aanname.

De go-live-datum ligt meestal vast. Contractueel, commercieel, of gewoon politiek. Als er dan tijd tekort is, wordt de datum niet verzet. Dan wordt er ingeleverd op wat nog samendrukbaar lijkt. Dat is nooit de bouw. Dat zijn testen, training en transitie: precies de drie dingen die bepalen of je operatie op dag één kan draaien. En dus haal je de datum en verlies je het eerste kwartaal. De uitloop verdwijnt niet, hij verhuist. Van het projectplan naar de operatie, waar hij niet langer uitloop heet maar opstartproblemen.

Daar komt een curve bij die de meeste plannen negeren. Ze rekenen met de productiviteit van een ingewerkt team op een ingewerkt systeem, vanaf dag één. Zo werkt het niet. Pickers zoeken. Planners twijfelen aan wat het scherm hun vertelt. Elke uitzondering kost een gesprek in plaats van een handeling. Reken die ramp-up door vóórdat je hem ingaat, en stem je volumeafspraken, bezetting en klantcommunicatie erop af. Doe je dat niet, dan haal je de go-live-datum en mis je vervolgens je serviceafspraken. Voor de klant is dat hetzelfde probleem.

De beste go-lives die ik heb meegemaakt waren niet spannend. Er lag een cutover-runbook. Er hingen namen aan WMS, WCS, besturing, onderhoud, operatie, klant en escalatie naar de integrator. Er was een hypercare-rooster met echte mensen erin, geen mailbox. En er was een dry run gedaan met productieachtige orderprofielen, dus het team had het al een keer gedaan. Heldendom rond een go-live is geen goed teken. Het betekent meestal dat er iets niet af was.

Zit je nu middenin een implementatie en voel je dat het gaat schuiven? Kijk dan niet als eerste naar de planning. Kijk naar je gap-register. Hoeveel punten staan daar nog open die eigenlijk vóór de design freeze beslist hadden moeten zijn? En hoeveel daarvan wachten op een beslissing van iemand die niet eens in de projectstructuur zit? Dat aantal is je echte planning.