Value Stream Mapping voorbeeld: een storingsproces analyseren

Een Value Stream Map laat niet alleen zien welke stappen een proces bevat, maar vooral waar tijd verloren gaat tussen die stappen. In Value Stream Mapping voorbeeld gebruiken we Value Stream Mapping om een storingsproces te analyseren: vanaf het moment dat een klant een storing meldt totdat een monteur het probleem heeft opgelost.

De casus laat zien hoe bewerkingstijd, wachttijd, overdrachten en mogelijke verspillingen zichtbaar worden. Daarbij is één principe belangrijk: een VSM maakt problemen zichtbaar, maar bewijst nog niet automatisch wat de oorzaak of beste oplossing is.

Wil je eerst weten wat Value Stream Mapping precies is en hoe je zelf een volledige VSM opstelt? Lees dan de centrale uitleg over Value Stream Mapping (VSM).

De praktijksituatie van Value Stream Mapping voorbeeld: een klant meldt een storing

Stel dat een organisatie technische storingen bij klanten oplost. De klant heeft een contract waarin is afgesproken dat een storing binnen een bepaalde tijd wordt verholpen.

Voor de klant zit de waarde uiteindelijk niet in telefoongesprekken, planningen of administratieve handelingen. De klant wil vooral dat de storing goed en binnen de afgesproken termijn wordt opgelost.

De waardestroom begint in het Value Stream Mapping voorbeeld bij de melding van de storing en eindigt wanneer het probleem bij de klant is verholpen.

Het proces verloopt globaal als volgt:

1. De klant meldt de storing bij klantcontact.

2. Klantcontact verzamelt de benodigde gegevens en registreert de aard van de storing.

3. De melding gaat naar de backoffice.

4. De backoffice stemt de melding af met de planner.

5. De planner probeert een beschikbare monteur in te zetten.

6. De monteur reist naar de klant.

7. De monteur onderzoekt en verhelpt de storing.

Alle afzonderlijke stappen kunnen op zichzelf logisch lijken. De vraag is echter wat er tussen de stappen gebeurt.

Juist daar ontstaan vaak wachttijden, overdrachten en andere vormen van verspilling. En dit is de kern van dit Value Stream Mapping voorbeeld.

Stap 1 – Bepaal eerst wat waarde is voor de klant

Voordat je een Value Stream Map maakt, moet je weten wat de klant als waarde beschouwt.

Een veelgebruikte Lean-vraag is:

Waarvoor is de klant daadwerkelijk bereid te betalen?

In deze casus betaalt de klant uiteindelijk voor een goed functionerende installatie en het tijdig oplossen van een storing.

Dat betekent niet automatisch dat iedere andere activiteit moet verdwijnen. Sommige niet-waardetoevoegende activiteiten kunnen noodzakelijk zijn, bijvoorbeeld vanwege veiligheid, administratie of regelgeving.

Het onderscheid tussen waarde en verspilling helpt je vooral om kritischer naar het proces te kijken.

Meer over de achterliggende Lean-principes voor dit Value Stream Mapping voorbeeld lees je in Wat is Lean of Lean Management?.

Stap 2 – Breng de huidige processtroom in kaart

Vervolgens leg je de current state vast: hoe verloopt het proces vandaag werkelijk?

Het is daarbij belangrijk om niet alleen te beschrijven hoe het proces volgens procedures zou moeten lopen. Een goede VSM laat zien wat in de praktijk gebeurt.

Je kunt bijvoorbeeld beginnen bij de klant en het proces stap voor stap volgen:

Klant → Klantcontact → Backoffice → Planner → Monteur → Klant

Bij iedere overgang stel je vragen:

• Wat gebeurt hier precies?

• Wie ontvangt welke informatie?

• Hoe wordt die informatie doorgegeven?

• Hoe lang duurt de activiteit?

• Hoe lang ligt het werk te wachten?

• Ontstaan er wachtrijen of voorraden?

• Waar worden gegevens opnieuw ingevoerd?

• Waar ontstaan fouten of herstelwerk?

• Wie bepaalt wanneer de volgende stap begint?

Door deze vragen te beantwoorden ontstaat een veel realistischer beeld dan wanneer je alleen een traditioneel processchema tekent.

Stap 3 – Meet bewerkingstijd, wachttijd en doorlooptijd

Een belangrijk onderdeel van Value Stream Mapping is het toevoegen van tijdgegevens.

Daarbij moet je ten minste onderscheid maken tussen bewerkingstijd, wachttijd en doorlooptijd.

Wat is bewerkingstijd?

De bewerkingstijd is de tijd waarin daadwerkelijk aan een processtap wordt gewerkt.

In deze casus duurt het gesprek tussen de klant en klantcontact bijvoorbeeld ongeveer 5 tot 10 minuten. In die tijd wordt de storing beschreven en worden de benodigde klantgegevens opgezocht of geregistreerd.

Ook andere activiteiten hebben een bewerkingstijd, bijvoorbeeld:

• de melding beoordelen;

• gegevens doorgeven;

• een monteur inplannen;

• de storing onderzoeken;

• de storing daadwerkelijk oplossen.

Bewerkingstijd zegt dus iets over de tijd waarin een activiteit wordt uitgevoerd.

Wat is wachttijd?

Wachttijd is de periode waarin de melding, informatie, klant of medewerker wacht voordat de volgende activiteit kan beginnen.

Een klant kan bijvoorbeeld tot 15 minuten wachten voordat klantcontact beschikbaar is.

Een andere wachttijd uit deze casus ontstaat wanneer de planner probeert een monteur te bereiken. In het oorspronkelijke procesvoorbeeld kan daar ongeveer 30 tot 90 minuten tussen zitten.

Tijdens die periode wordt de storing niet opgelost.

Wachttijd is daarom een belangrijk aandachtspunt binnen Lean. Maar een lange wachttijd vertelt nog niet automatisch waarom die ontstaat.

Wat is doorlooptijd?

De doorlooptijd is de totale tijd die verstrijkt vanaf het begin tot het einde van het proces.

In deze casus begint die bijvoorbeeld wanneer de klant een storing meldt en eindigt de doorlooptijd wanneer de storing is opgelost.

De doorlooptijd bestaat dus niet alleen uit de tijd waarin daadwerkelijk wordt gewerkt. Ook alle tussenliggende wachttijd telt mee.

In veel processen blijkt uiteindelijk dat de totale wachttijd veel groter is dan de totale bewerkingstijd.

Dat inzicht is vaak een van de belangrijkste opbrengsten van een Value Stream Map.

Stap 4 – Zoek waar verspilling ontstaat

Wanneer processtappen en tijden zichtbaar zijn, kun je onderzoeken waar mogelijk verspilling ontstaat.

In deze storingscasus kunnen bijvoorbeeld de volgende vragen ontstaan:

• Waarom moet de melding via zowel klantcontact als backoffice als planning?

• Welke informatie wordt bij iedere overdracht opnieuw verwerkt?

• Waarom moet een planner soms lang wachten voordat een monteur beschikbaar is?

• Ontstaan meldingen die wachten op behandeling?

• Worden bepaalde gegevens meerdere keren ingevoerd?

• Ontbreekt informatie waardoor medewerkers opnieuw contact moeten opnemen?

• Zijn prioriteiten voor storingen voldoende duidelijk?

• Is het aanbod van storingen in balans met de beschikbare capaciteit?

Een Value Stream Map helpt deze vragen zichtbaar te maken.

Voor een uitgebreid overzicht van verspilling binnen Lean kun je ook onze uitleg over de 7 verspillingen van Lean gebruiken.

Stap 5 – Een lange wachttijd is nog geen bewezen bottleneck

Een veelgemaakte fout bij het interpreteren van een VSM is dat een opvallend lange wachttijd direct als oorzaak wordt aangewezen.

Stel dat de planner 30 tot 90 minuten moet wachten voordat een monteur beschikbaar is.

Het is verleidelijk om te concluderen in dit Value Stream Mapping voorbeeld:

“We hebben te weinig monteurs.”

Misschien klopt dat.

Maar uit de wachttijd alleen kun je dat nog niet bewijzen.

Andere mogelijke verklaringen zijn bijvoorbeeld:

• storingen worden niet goed geprioriteerd;

• monteurs zijn geografisch ongunstig ingepland;

• sommige storingen duren veel langer dan verwacht;

• de planning heeft onvoldoende inzicht in actuele beschikbaarheid;

• informatie bereikt de monteur te laat;

• er zijn grote pieken in de klantvraag;

• een eerdere processtap veroorzaakt onnodige vertraging;

• werkzaamheden worden in grote batches gepland.

Een VSM geeft dus aanleiding tot onderzoeksvragen en hypotheses.

De volgende stap is onderzoeken welke verklaring door data en waarnemingen wordt ondersteund.

Dat onderscheid is belangrijk binnen zowel Lean als Lean Six Sigma: een aannemelijke oorzaak is nog geen bewezen grondoorzaak.

Wil je meer lezen over het aantonen van oorzaken? Bekijk dan ook de Analyze-fase van DMAIC.

Is een extra monteur dan geen goede oplossing in dit Value Stream Mapping voorbeeld?

Dat kan zeker een goede oplossing zijn in dit Value Stream Mapping voorbeeld.

Maar alleen wanneer uit de analyse blijkt dat onvoldoende capaciteit daadwerkelijk de beperkende factor is.

Stel bijvoorbeeld dat monteurs vrijwel continu volledig bezet zijn, de vraag structureel groter is dan de beschikbare capaciteit en andere procesverbeteringen onvoldoende ruimte opleveren. Dan kan capaciteitsuitbreiding logisch zijn.

Maar wanneer de werkelijke oorzaak een slechte planning, ontbrekende informatie of grote variatie in werkzaamheden is, kan een extra monteur vooral extra kosten veroorzaken zonder het onderliggende probleem op te lossen.

Daarom is de juiste volgorde:

waarnemen → meten → analyseren → hypothese toetsen → oplossing ontwerpen → resultaat verifiëren

In plaats van:

probleem zien → oplossing bedenken → direct implementeren

Bottlenecks herkennen in een waardestroom

Een bottleneck is een processtap die de capaciteit of het tempo van de totale waardestroom beperkt.

Het is daarom belangrijk om niet iedere wachtrij automatisch een bottleneck te noemen.

Een wachtrij kan een aanwijzing zijn dat ergens in het proces capaciteit, variatie of afstemming een probleem vormt. Maar je moet onderzoeken welke processtap daadwerkelijk bepalend is voor de prestaties van het totale systeem.

Een bekende methode om naar een beperkende schakel in een proces te kijken is de Theory of Constraints. Binnen die benadering wordt onder andere gebruikgemaakt van Drum-Buffer-Rope.

De kern blijft hetzelfde: optimaliseer niet alleen afzonderlijke processtappen, maar kijk naar de prestaties van het gehele proces.

Stap 6 – Onderzoek ook de overdrachten

In veel dienstverlenende processen zit verspilling niet alleen in de afzonderlijke activiteiten, maar vooral in de overdrachten ertussen.

In ons voorbeeld loopt de melding via:

klantcontact → backoffice → planner → monteur

Daarmee ontstaan automatisch vragen:

• Welke unieke waarde voegt iedere overdracht toe?

• Welke informatie wordt toegevoegd?

• Welke informatie gaat verloren?

• Moet iemand wachten voordat de volgende stap begint?

• Is goedkeuring noodzakelijk?

• Worden gegevens dubbel ingevoerd?

• Kan informatie rechtstreeks worden doorgegeven?

Misschien blijkt uiteindelijk dat een processtap kan verdwijnen.

Maar ook hier geldt: verwijder een stap niet uitsluitend omdat hij geen directe klantwaarde lijkt toe te voegen. Onderzoek eerst welke functie de stap vervult en wat de gevolgen zijn als je hem verandert.

Stap 7 – Ontwerp de future state

De huidige Value Stream Map noemen we de current state.

Nadat duidelijk is hoe het proces werkelijk functioneert en welke problemen het belangrijkst zijn, kun je een gewenste toekomstige situatie ontwerpen: de future state.

In deze future state probeer je bijvoorbeeld:

• onnodige overdrachten te verminderen;

• wachttijd te verkorten;

• informatiestromen te vereenvoudigen;

• werk beter te verdelen;

• fouten eerder te voorkomen;

• voorraden en wachtrijen te verkleinen;

• werk beter op de klantvraag af te stemmen.

De future state is geen fantasie van een perfect proces.

Het is een onderbouwd ontwerp van een betere waardestroom, gebaseerd op wat je in de huidige situatie hebt waargenomen en onderzocht.

Van current state naar verbeteracties

Tussen een current state en een future state zit meestal een reeks verbeteracties.

Niet iedere verbetering hoeft tegelijkertijd te worden uitgevoerd.

Bepaal daarom:

1. welk probleem de grootste invloed heeft op klantwaarde of procesprestaties;

2. welke oorzaak voldoende is onderbouwd;

3. welke verandering waarschijnlijk effect heeft;

4. hoe je die verandering kunt testen;

5. welke maatstaf laat zien of de verbetering werkelijk werkt.

Op die manier wordt een Value Stream Map geen mooie tekening aan de muur, maar een hulpmiddel voor gericht procesverbeteren.

Wat leert dit Value Stream Mapping voorbeeld?

Deze storingscasus laat een paar belangrijke lessen zien.

1. Kijk naar de volledige waardestroom.
Een afzonderlijke afdeling kan efficiënt lijken terwijl het totale proces toch langzaam verloopt.

2. Meet zowel bewerkingstijd als wachttijd.
Juist de tijd tussen processtappen vormt vaak een groot deel van de totale doorlooptijd.

3. Overdrachten verdienen extra aandacht.
Iedere overdracht kan nieuwe wachttijd, fouten of informatieverlies veroorzaken.

4. Een waarneming is nog geen oorzaak.
Een lange wachttijd betekent niet automatisch dat er onvoldoende capaciteit is.

5. Een VSM is het begin van de analyse, niet het einde.
De kaart helpt bepalen waar verder onderzoek en verbetering nodig zijn.

Zelf een Value Stream Map maken

Wil je na dit voorbeeld zelf een proces analyseren?

Begin dan met:

1. het bepalen van klantwaarde;

2. het afbakenen van de waardestroom;

3. het volgen van het werkelijke proces;

4. het verzamelen van proces- en tijdgegevens;

5. het tekenen van de current state;

6. het herkennen van verspilling en knelpunten;

7. het onderzoeken van oorzaken;

8. het ontwerpen van een future state;

9. het testen en uitvoeren van verbeteracties.

In onze uitgebreide gids Value Stream Mapping (VSM): zo breng je de waardestroom in kaart leggen we deze aanpak stap voor stap verder uit.

Value Stream Mapping leren toepassen in de praktijk

Value Stream Mapping is vooral waardevol wanneer je de methode niet alleen kunt tekenen, maar ook kunt gebruiken om goede verbeterbeslissingen te nemen.

Daarbij horen vragen zoals:

• Wat is werkelijk waarde voor de klant?

• Waar ontstaat doorlooptijd?

• Wat is verspilling en wat is noodzakelijk?

• Welke processtap bepaalt de prestaties van het geheel?

• Welke oorzaak is aantoonbaar?

• Welke oplossing verbetert daadwerkelijk de totale waardestroom?

Binnen de Lean- en Lean Six Sigma-opleidingen van 5ST3PS leer je deze technieken toepassen op echte processen.

Voor professionals die zelfstandig processen willen analyseren en verbeteren is de Lean Six Sigma Green Belt een logische vervolgstap.

Conclusie Value Stream Mapping voorbeeld

Een Value Stream Map maakt zichtbaar hoe werk, informatie en tijd door een proces stromen. In het voorbeeld van een storingsproces zien we dat vooral wachttijden en overdrachten belangrijke aanknopingspunten voor verbetering kunnen opleveren.

Maar de belangrijkste les is misschien juist wat een VSM niet doet.

Een VSM vertelt je niet automatisch waarom een probleem ontstaat en schrijft ook niet voor welke oplossing je moet kiezen.

De kracht zit in het zichtbaar maken van de totale waardestroom. Daarmee kun je gerichter onderzoeken waar verspilling ontstaat, welke oorzaken werkelijk een rol spelen en welke verbeteringen het gehele proces beter maken.