blog

Een goed begin is het halve werk

Warehousing

Een goed begin is het halve werk. Een oud gezegde dat zeker van toepassing is op de implementatie van WMS-systemen. In het begin moeten de gebruikers aangeven wat ze willen. En daar begint vaak het probleem. Want, hoe doe je dat nu eigenlijk?

De implementatie van een nieuw systeem beïnvloedt direct de werkzaamheden van de magazijnmedewerkers. Daarom moeten deze gebruikers vroegtijdig worden betrokken bij de functionele specificatie. De gebruikers moeten aangeven wat ze willen. Daarom mogen ze ‘even tussendoor’ aangeven wat ze nu doen en wat de wensen zijn; dit gebeurt vaak redelijk vrijblijvend. “Het huidige logistieke proces moet goed ondersteund worden en de knelpunten die er nu zijn, moeten door het WMS worden opgelost!”

 

Historisch

De gebruikers van het systeem denken vanuit de huidige manier van werken. Dit is vaak een historisch gegroeide methode, waarbij praktische oplossingen zijn gevonden voor veel uitzonderingssituaties. 

De gebruikers die worden betrokken bij de implementatie, zijn vaak de betere medewerkers, die het proces goed kennen. Dit zijn ook de medewerkers die de uitzonderingen en knelpunten vaak moeten oplossen.

Hierdoor worden alle uitzonderingssituaties benoemd; zij krijgen relatief veel aandacht.

 

Rode vlekken

De implementatiepartner van het systeem begint dan vaak de eerste rode vlekken te krijgen. Hoe moeten al die uitzonderingssistuaties in het systeem worden ingevoerd? En waarom wordt niet de basisstructuur van het systeem gevolgd? Ieder magazijn werkt toch volgens dezelfde basisprincipes?

De implementatiepartner begint aan te geven dat niet alle gebruikerswensen ingevuld kunnen worden. Zeker basisprocessen moeten volgens de structuur van het pakket worden geïmplementeerd; de uitzonderingssituaties gaan veel maatwerk kosten.

 

Gebruikers ageren

De gebruikers gaan ageren. Deze snappen niet waarom het nieuwe pakket niet gewoon doet wat ze vragen. Het huidige, verouderde systeem doet dat toch ook? De tegenstellingen nemen toe. De implementatiepartner maakt een budget voor alle systeemaanpassingen, waarvan er vervolgens een aantal worden weggestreept omdat deze te veel kosten.

De tegenstellingen groeien verder en de sfeer is gezet. Het vertrouwen daalt en de medewerking wordt minder. Vasthouden aan de eisen, want anders wordt er een systeem geleverd waar niet mee valt te werken!

 

Testen inkorten

Het systeem wordt vervolgens geïmplementeerd, met de vele aanpassingen die toch nog zijn goedgekeurd. Het testen begint. Daar is wederom veel tijd voor nodig. Het moet trouwens in een kort tijdsbestek, want door al het gesteggel en de vele aanpassingen is het project uitgelopen, terwijl de opleverdatum is blijven staan. De testtijd moet maar wat worden ingekort. Terwijl er juist meer testtijd nodig is door de vele aanpassingen.

Onder druk gaat men live. En het systeem doet niet wat men wil. Door bepaalde systeemaanpassingen blijken standaardfunctionaliteiten niet meer beschikbaar te zijn of werken niet meer zoals het hoort. Er ontstaan problemen doordat niet alles goed is getest. En zo gaat men verder. De opstart verloopt moeizaam, tot een stabiele omgeving is ontstaan, die men maar voor lief neemt. Men is echter niet tevreden over het systeem.

 

Intensiever

Helaas komt deze situatie nog te vaak voor. Opvallend genoeg komt dit vaker voor bij de implementatie van de WMS-modules van ERP-systemen, dan bij dedicated WMS-systemen.

De gebruikers kunnen ook op een andere manier bij de opstelling van de functionele specificaties worden betrokken. Zij moeten intensiever worden betrokken bij de implementatie. Zij moeten aangeven wat er nodig is. Maar dat moet wel goed worden voorbereid. Ze moeten niet gedurende enkele uren ‘even worden geïnterviewd’.

Ten eerste gaat het er niet om wat men nu precies doet en welke WMS-ondersteuning daarvoor nodig is. Men moet eerst een stapje terugzetten en nagaan hoe het basisproces zo goed mogelijk opnieuw gestructureerd kan worden. Het logistieke proces moet in basis effectief en efficiënt worden ingericht. De vele uitzonderingssituaties moet men trachten te groeperen tot een aantal basisoplossingsmethodes. 

 

Pakketstructuur

Daarnaast moet men goed op de hoogte worden gebracht van de structuur van het pakket. Hiervoor is een uitgebreide, inhoudelijke presentatie van het pakket nodig, waarbij de structuur grondig wordt toegelicht. Dit moet geen powerpointpresentatie zijn; de schermen en parameters moeten een voor een worden doorlopen. Tevens moet de impact van de beschikbare parameters op het proces zichtbaar worden gemaakt. Dit moet wel gebeuren door de echte systeemspecialisten. 

Vervolgens moeten de toekomstige gebruikers worden gemotiveerd om mee te gaan denken in de structuur van het nieuwe pakket en daarin moeten zij aangeven hoe hun proces goed kan worden verwerkt. Zij moeten samen met de implementatiepartner de gewenste basisstructuur vorm gegeven.

Hierdoor neemt de kwaliteit van de implementatie toe en wordt het meer ‘hun kindje’ waar ze trots op zijn. Dan neemt de acceptatie vanzelf toe. 

 

Veel aandacht en doorlooptijd

Dit kost echter met name veel aandacht en doorlooptijd. Geef deze aandacht en zorg voor voldoende doorlooptijd. Men moet wennen aan het nieuwe systeem, voordat de functionele specificaties worden gemaakt. En dat valt niet mee.  

Help ze daar mee, en geef voldoende doorlooptijd. Dat doe je er niet even tussendoor.

Reageer op dit artikel