Je weet wat het probleem is en waarom het ontstaat. Nu ontwerp je de oplossing: eerst het huidige proces echt begrijpen, dan het gewenste proces ontwerpen, en alles vertalen naar acties die je team kan uitvoeren.
zo versnelt AI deze stap
AI stelt in een handomdraai mogelijke oplossingen en acties voor. Jouw werk in deze module: kiezen wat haalbaar is en past bij je team. De brainstorm gaat sneller, maar de selectie blijft mensenwerk.
de methode
Eén terugkerend probleem uit je eigen werk is de rode draad door deze training. Elke module voegt een bouwsteen toe aan je business case; na module 5 is hij compleet.
na deze module
theorie · 20 min
De grootste valkuil in deze fase: meteen een oplossing kiezen en die over het bestaande proces heen leggen. Veel problemen bestaan juist doordat niemand precies weet hoe het proces werkelijk loopt. Iedereen kent zijn eigen stukje; het geheel kent niemand. Wie dan gaat verbouwen, verbouwt blind.
Voordat je iets verandert, leg je vast hoe het nú werkt. Niet hoe het op papier zou moeten werken, maar hoe het in de praktijk gaat. Een snel en krachtig hulpmiddel daarvoor is de SIPOC: per processtap benoem je Suppliers (wie levert input), Inputs (wat komt binnen), Process (de stap zelf), Outputs (wat komt eruit) en Customers (wie ontvangt het).
De SIPOC dwingt je om het proces van begin tot eind te bekijken, inclusief de overdrachtsmomenten. En juist op die overdrachten, waar werk van de één naar de ander gaat, zitten de meeste knelpunten.
Met de as-is op tafel en de grondoorzaak uit module 2 in de hand, ontwerp je het to-be proces. De ontwerpvraag is simpel: hoe ziet het proces eruit als de grondoorzaak niet meer kan optreden?
Drie ontwerpprincipes helpen daarbij. Voorkom in plaats van herstel: een verplichte scanstap is beter dan een wekelijkse opruimronde. Maak het goede pad het makkelijke pad: als de juiste werkwijze meer moeite kost dan de sluiproute, wint de sluiproute bij drukte altijd. Beleg eigenaarschap: elk proces heeft iemand nodig die mag en moet ingrijpen als het afwijkt.
Een to-be proces op papier verandert nog niets. De vertaling naar de praktijk gaat via een Agile opbouw in drie lagen:
Waarom deze opbouw? Grote veranderingen mislukken zelden door gebrek aan ambitie, maar door gebrek aan behapbaarheid. Door de oplossing op te knippen weet iedereen wat er van hem of haar verwacht wordt, zie je voortgang per week in plaats van per kwartaal, en kun je bijsturen voordat iets groots de verkeerde kant op is gegroeid.
Heb je meerdere features of oplossingsrichtingen, weeg ze dan op twee assen: impact (hoeveel draagt dit bij aan het wegnemen van de grondoorzaak?) en haalbaarheid (hoeveel tijd, geld en medewerking kost het?). Start met hoge impact en hoge haalbaarheid. Laag-impact acties die toevallig makkelijk zijn, voelen lekker maar lossen niets op.
In module 1 heb je becijferd wat het probleem kost. Nu de andere kant: wat kost de oplossing, en wat levert hij op? Pas met die twee getallen naast elkaar heb je een business case waar een beslisser ja tegen kan zeggen.
Houd het simpel. Kosten: uren van betrokkenen, eventuele aanpassingen aan systemen, materiaal, eenmalige acties. Baten: het jaarbedrag uit module 1 dat (deels) verdwijnt, plus wat moeilijker telbaar is zoals klanttevredenheid en werkplezier. Deel de kosten door de baten per maand en je hebt de terugverdientijd: vaak het enige getal dat een beslisser onthoudt.
Kosten: scanveld verplicht zetten (2 uur applicatiebeheer), bufferzone inrichten (1 dag), instructie en inwerkprogramma aanpassen (1 dag), eenmalig achterstand wegwerken (2 dagen). Totaal ruwweg €2.000.
Baten: €29.000 per jaar aan zoektijd, plus minder gemiste deadlines en klachten.
Terugverdientijd: minder dan één maand.
Let op de valkuil: reken jezelf niet rijk. Neem alleen baten mee die je in module 1 hebt onderbouwd, en wees ruim in je kostenschatting. Een business case die te mooi oogt, roept wantrouwen op; eentje die voorzichtig rekent en alsnog overtuigt, is onverslaanbaar.
oefencase · 20 min
De grondoorzaak uit module 2: het inslagproces heeft geen verplichte locatieregistratie en geen proceseigenaar. Kijk hoe het team dat vertaalt naar een oplossing en een uitvoerbaar plan.
Het team maakt een SIPOC van het inslagproces en ziet: tussen "goederen ontvangen" en "locatie registreren" zit geen verplichte koppeling. Het to-be proces sluit dat gat.
Epic: locatieregistratie in het inslagproces sluitend maken, zodat zoektijd bij orderpicken structureel verdwijnt.
Feature 1 heeft de hoogste impact én is binnen een week haalbaar: die start direct. De eenmalige opruimactie staat bewust in feature 3, ná de systeemaanpassing. Eerst opruimen zonder de oorzaak te repareren zou binnen een maand weer ongedaan zijn gemaakt.
jouw opdracht · 35 min
Pak je grondoorzaak uit module 2 erbij. Breng eerst je huidige proces in kaart (gebruik daarvoor de SIPOC Modeller hieronder), ontwerp dan je to-be en werk het plan uit in het werkblad.
Je antwoorden blijven op je eigen apparaat. Werk van boven naar beneden: eerst het ontwerp, dan het plan.
Dit is de kern van je business case: probleem (module 1), oorzaak (module 2) en plan (module 3). In module 4 maak je het meetbaar.
Een goed verbeterplan doorstaat deze vier vragen:
kennischeck · 5 min
Drie vragen over deze module. Kies een antwoord en je ziet direct of het klopt, en vooral: waarom.
1. Waarom breng je eerst het huidige proces (as-is) in kaart?
2. Welke formulering is een goede epic?
3. Je hebt vier mogelijke acties. Waar begin je?
klaar met module 3
Probleem, oorzaak en plan: de kern van je business case staat. Maar hoe weet je straks of de verbetering echt het verschil maakt? Daarover gaat module 4: de juiste dingen meten, zonder te verdrinken in KPI's.
Terug naar module 2: Oorzaak of het module-overzicht.