Value Stream Mapping is de tool die gebruikt wordt on de flow van processen te verbeteren. Traditionele VSM´s beschrijven een fysische product flow, waarin een product geproduceerd wordt op lineaire wijze. Kantoorprocessen zijn anders. Het ´product´ dat hier geproduceerd wordt is virtueel. Duurt soms maanden in plaats van minuten en om het nog complexer te maken is de flow van kenniswerk non-lineair en multi-directioneel (Morgen & Liker, 2006).
Dit artikel beschrijft het probleem met het gebruik van traditionele VSM´s in projectwerk en hoe de VSM aangepast kan worden om problemen zichtbaar te maken in deze omgeving. Tot slot wordt een voorbeeld project VSM uitgewerkt.
Figuur 1: traditionele Value Stream Map voor productie
Afbeelding 1 laat een voorbeeld van een traditionele value stream map zien. Als basiskennis voor dit artikel raadt ik aan om het basis artikel over value stream mapping eerst te lezen.
Met de hierboven afgebeelde standaard methode, ontstaan er EEN AANTAL PROBLEMEN BIJ VALUE STREAM MAPPING IN PROJECTWERK.
Ten eerste zijn binnen projectwerkzaamheden de meeste mensen een shared resource. Dit betekent dat mensen aan meerdere taken en of projecten tegelijkertijd werken in plaats van 1 keer een taak op te pakken en pas aan een volgende taak te beginnen als de taak afgerond is. Dit leidt daartoe, dat binnen de procesboxen mogelijk meer waste verscholen zit dan tussen de procesboxen (welke door de traditionele VSM zichtbaar gemaakt worden).
Afgezien van de onderbrekingen duren de taken binnen projecten over het algemeen langer dan een paar seconden of minuten. De opgave om bijvoorbeeld klanten feedback te verzamelen om Quality Function Deployment (QFD) te kunnen toepassen kan niet zonder onderbreking worden uitgevoerd. Dit zou kunnen betekenen dat deze taak wordt opgesplitst in 20 proces boxen, maar ook hier is het de vraag of dit ertoe leidt dat de VSM overzichtelijk blijft en of dit helpt het proces beter te begrijpen.
Een derde probleem, is dat kenniswerk niet lineair is. Mensen werken simultaan aan acties, meestal met verschillende beschikbare tijd en met verschillende iteraties. Binnen een team kan 1 persoon 1 uur per dag aan het QDF werken en een tweede persoon 3 uur per dag. Hoe zou je deze complexiteit en overzicht van benodigde manuren kunnen weergeven in de VSM?
Een MOGELIJKE OPLOSSING voor deze problemen wordt beschreven door Morgan & Liker (2006). Zij beschrijven een aangepast vorm van value stream mapping, welke de pluspunten van traditionele VSM met die van een procesmap, een zwembaan diagram en een Gantt chart combineert.
De lead time ladder van de VSM wordt ook in deze VSM gebruikt, een toevoeging is het symbool voor project mijlpalen. De gehele doorlooptijd van het project wordt bijvoorbeeld opgesplitst in 5 stappen van DMAIC, waarin binnen elke fase van het project activiteiten kunnen worden gedefinieerd.
Binnen deze project fasen bevinden zich feedbackloops van activiteiten en uitwisseling van data. Behalve het benoemen van welke activiteiten (procesboxen) er nodig zijn, kunnen de beslissingen die genomen dienen te worden om de mijlpaal te behalen in de VSM worden weergegeven met een apart symbool.
De activiteiten die parallel door verschillende afdelingen, sub-teams of functies worden uitgevoerd, kunnen in de vorm van een zwembaan diagram worden afgebeeld. Hiermee wordt de complexiteit van het project visueel gemaakt en laat zien hoe de hoeveelheid werk zich tussen functiegroepen verschild.
Tot slot kunnen de procestijden gedefinieerd worden en, daaruit volgend, kan de benodigde capaciteit worden berekent. De duur van de taak (PT) vermenigvuldigt met het aantal mensen dat erbij betrokken wordt geeft de inschatting van het aantal man-uren (MH) dat nodig is om elke tak en het totale project uit te voeren.
Figuur 2: voorbeeld value stream map voor 5S project
Figuur 2 laat een voorbeeld VSM zien voor het PROJECT ´5S IMPLEMENTATIE´. Aangezien 5S een basis tool is die in elke afdeling wordt ingevoerd als een van de eerste stappen in een lean transformatie, is het belangrijk visueel te maken wat voor capaciteit nodig is en hoe lang het duurt om de eerste 5S standaarden te definiëren.
Het eerste wat de VSM zichtbaar maakt, door middel van de lead time ladder bovenin, is dat het implementeren van 5S in een productieomgeving in dit voorbeeld een doorlooptijd van 1 maand heeft.
voor elk van de 5 stappen in 5S, (scheiden, schikken, schoonmaken, standaardiseren en standhouden) is een mijlpaal op de tijdlijn weergeven.
Onder de tijdlijn met mijlpalen staan de activiteiten en beslissingen die nodig zijn om de projectfasen af te sluiten. Bijvoorbeeld, om de ´scheiden´-fase af te sluiten moet het team het er over eens zijn wat zij nodig hebben om hun werk goed te kunnen doen en wat niet. En voordat de eerste versie van de lay-out wordt omgezet, moet besloten consensus in de groep zijn over hoe deze er uit zal komen te zien.
Het ontwerpen van de eerste versie van de nieuwe lay-out wordt uitgevoerd door een kern-team, maar gebeurt aan de hand van feedback van het totale team. Ook deze feedback-loop is weergegeven in de VSM.
De belangrijkste wachttijd die zich in het proces bevindt, welke niet afhankelijk is van de beschikbaarheid van medewerkers, is de wachttijd op materialen die nodig zijn om de nieuwe lay-out om te zetten.
Tot slot kan aan de hand van de VSM berekent worden hoeveel man-uren in dit project gepland zijn, in dit voorbeeld zijn dit 114 uren. In deze planning zijn deze man-uren verspreid over 30 dagen doorlooptijd. De totale procestijd laat ons zien, dat wanneer er geen wachttijd op te bestellen materialen is, in principe het hele 5S project in 5 dagen als Kaizen event kan worden omgezet (44 uur min 8 uur voor bestellingen zijn 36 uur procestijd).
Het doel van value stream mapping is om de problemen / vertragingen van de flow zichtbaar te maken in een project team, zodat er acties gedefinieerd kunnen worden om problemen in de voortang van het proces te voorkomen. Wanneer we bovenstaande aanpassingen aan de VSM omzetten, vormt deze voor het project team een belangrijke planning tool én KPI. Voor projecten die langer dan een paar maanden duren, zou de VSM zou als onderdeel van de Obeya dagelijks (wellicht wekelijks) moeten worden besproken, om zeker te stellen dat dat project doelstellingen worden gehaald.
Ga verder naar:
Obeya - Teamboards voor de projectomgeving
BRON:
Morgen, J. M., & Liker, J. K. (2006). The Toyota Product Development System. New York: Productivity Press. (samenvatting / bestel dit boek)
