Het systeem is ontworpen, maar klopt het met hoe wij werken?
Het ontwerp beschreef wat de software moest doen. Hoe een order van begin tot eind door het bedrijf loopt, stond nergens.
Een Belgische producent stapte over op een nieuw ERPEén systeem dat je kernprocessen zoals voorraad, boekhouding en orders samenbrengt.- en magazijnsysteem. Het ontwerp was klaar, maar niemand had de processen van begin tot eind uitgetekend. Met AI als schrijfhulp brachten we er in vier weken negentien van de vierentwintig in kaart, samen met de mensen die ze elke dag uitvoeren.
Van ontvangst tot expeditie, elk met één eigenaar bij de klant.
Negentien ervan lagen er al na vier weken, getekend en goedgekeurd door de eigenaar zelf, niet door ons.
Processen waar het nieuwe systeem niets aan verandert. Tekenen was daar tijdverlies.
Uit de opname van elke workshop maakte AI een eerste versie van de flow. Onze uren gingen naar luisteren en nakijken, niet naar tekenen. Dat maakt het sneller, en dus goedkoper.
Het project had een functioneel ontwerp en een leverancier die wist wat hij moest bouwen. Wat ontbrak, was een beeld van hoe het werk vandaag echt loopt.
Het ontwerp beschreef wat de software moest doen. Hoe een order van begin tot eind door het bedrijf loopt, stond nergens.
Wie wat wanneer doet, wisten de mensen op de vloer en in de administratie. Op papier stond het niet.
Planning, lotnummers en certificaten werden met de hand bijgehouden en doorgegeven. Wat het nieuwe systeem daarvan zou overnemen, was niet duidelijk.
Geen zwaar model. Wel een vaste werkwijze die de mensen op de vloer meteen herkenden.
We maakten een lijst van alle processen, vierentwintig in totaal, en zochten voor elk proces één eigenaar bij de klant. Die eigenaar keurt de flow achteraf goed, niet wij.
Per proces een workshop met de eigenaar en de mensen die het werk doen. We namen de gesprekken op. AI zette de opname om in een eerste versie van de flow, en wij werkten die uit. Zo ging de tijd naar luisteren en niet naar tekenen.
Elke flow werd uitgeprint en stap voor stap met de eigenaar doorlopen. Wat niet klopte, werd ter plaatse aangeduid en opnieuw getekend, tot de eigenaar zei dat het klopte.
Per proces bepaalden we hoe groot de impact van het nieuwe systeem was. Open punten werden werk voor de leverancier, en de flows kwamen op één centrale plek, waar iedereen ze kan raadplegen.
Een ontwerp beschrijft wat de software moet doen. Een flow toont hoe het werk vandaag loopt. Pas als je de twee naast elkaar legt, zie je waar ze botsen. Een paar voorbeelden:
Een stap stond in de verkeerde volgorde. In het ontwerp werd de voorraad afgeboekt voor de papieren klaar waren. In de praktijk is het andersom: pas als alle documenten in orde zijn, wordt er afgeboekt. Ook de planning van het transport bleek vooraan te horen, niet achteraan.
Een geblokkeerde partij was maar half geblokkeerd. Werd een partij in het ene systeem geblokkeerd, dan gebeurde dat niet automatisch in het andere. In deze branche is dat geen detail.
Een flow die niemand herkende. De manier waarop artikelgegevens tussen de systemen liepen, was verkeerd getekend. Dat zie je pas als de mensen die ermee werken de flow lezen. Hij werd opnieuw getekend.
Nieuwe scope, bewust geparkeerd. Tijdens de workshops dook een registratie op waar het ontwerp geen rekening mee hield. De stuurgroep besliste om die bewust naar later te verschuiven, in plaats van ze ongemerkt mee te nemen.
Wij brachten de werkwijze en het schrijfwerk. De kennis en het laatste woord bleven bij de klant.
De structuur en het schrijfwerk.
De kennis en het laatste woord.
De flows bleven niet in een map zitten. Het systeem is intussen in gebruik, en de flows dienen als basis voor de tests, voor de opleiding van nieuwe mensen en als informatie voor partners en leveranciers.
“Dat kwam uit de flows naar boven. Een collega verwachtte iets dat nooit in de specificaties stond en dus ook nooit gebouwd was. Zo zagen we meteen het verschil tussen wat we gevraagd hadden en wat de werkvloer verwachtte.”
