Procesefficiëntie beoordelen met waardestroomtoewijzingen
Wanneer u een waardestroomoverzichtof VSM maakt, kunt u hiermee uw huidige releasecyclusproces analyseren. Het doel van een VSM is om visueel weer te geven waar in het proces een team waarde creëert en waar er verspilling is. Het doel is om een proces te bereiken dat de maximale waarde aan de klant levert met minimale verspilling. Een VSM kan u helpen bij het vaststellen van gebieden die geen waarde bijdragen of die de waarde van het product daadwerkelijk verminderen.
Laten we eens kijken hoe Tailspin presteert.
Mara, die nieuw is voor het team, gaat een VSM maken om haar te helpen het bestaande proces te begrijpen. Met een VSM krijgt ze een idee van waar het team in het DevOps-volwassen model past. Uit onderzoek blijkt dat meer volwassen teams doorgaans sneller releases uitvoeren, met meer vertrouwen en minder bugs, dan minder volwassen teams.
Mara weet dat ze nog niet alles begrijpt, dus ze gaat een snelle VSM maken op het whiteboard in de vergaderruimte. Er zijn enkele hiaten en onbeantwoorde vragen, maar dat is oké. Het is een begin. Als ze zoveel mogelijk heeft gedaan, deelt ze het met het team. De VSM geeft iedereen een gemeenschappelijk uitgangspunt voor het identificeren van de eerste stappen voor het verbeteren van hoe Tailspin zijn websites ontwikkelt en publiceert.
Laten we haar kaart eens bekijken.
Inzicht in het huidige proces
Mara verzamelt het team in de vergaderruimte om haar VSM te presenteren.
Mara: A VSM helpt ons meten waar een proces waarde heeft voor de klant en waar het tijd opeet zonder enige waarde te produceren. Onze kaart begint linksboven met de functionele specificatie voor de software. Laten we slechts één functie volgen om te zien hoe deze zich door onze huidige releasecyclus beweegt.
Sommige mensen rollen hun ogen, maar Mara drukt erop.
Ontwikkelingsprocessen
Het maken van een nieuwe functie begint momenteel met het maken van een label in broncodebeheer 
. We hebben één persoon die labels kan maken, en dat is Andy. We vragen per e-mail een label aan. We gebruiken een gecentraliseerd versiebeheersysteem, dus Andy wacht totdat alle bestaande code is ingecheckt en stabiel is voordat hij het label maakt. Nadat het label is gemaakt, krijgen we een e-mailbericht waarin staat dat we kunnen beginnen met werken. Dit proces duurt maximaal drie dagen en heeft geen waarde voor de klant. Dingen zonder waarde voor de klant moeten zo weinig mogelijk tijd in beslag nemen.
Het coderen van een functie duurt ongeveer vier dagen voor één persoon nadat we toegang hebben tot alle bestanden die we nodig hebben 
. We moeten op het bedrijfsnetwerk zijn om toegang te krijgen tot broncodebeheer. Deze tijd is waardevol voor de klant. Ze willen deze functie.
Testprocessen
Nadat we hebben besloten dat we een stabiele build hebben, werken we een spreadsheet bij zodat Amita weet dat er een build gereed is voor testing en waar 
te vinden is. Het duurt twee dagen voordat ze op de hoogte is.
Amita test de build 
handmatig. Dit proces wordt langer naarmate de codebasis groeit. Laten we nu drie dagen zeggen. Vervolgens stuurt ze Andy een e-mail met foutrapporten. Testen voegt geen waarde toe, maar dit is noodzakelijk.
Andy moet dan tijd nemen om de bugs te classificeren en werk toe te wijzen . Het kan nog drie dagen duren voordat Andy de problemen begrijpt en ze naar de juiste ontwikkelaars brengt.
Bewerkingsprocessen
Als Amita een build goedkeurt, geeft ze het af aan Tim. Tim moet deze build implementeren op de preproductieservers voor meer tests. Vaak zijn de preproductieservers niet gesynchroniseerd met de nieuwste patches en updates die nodig zijn om de website uit te voeren. Het kost Tim ongeveer twee dagen om naar de preproductie te gaan en enkele tests uit te voeren. Hoewel implementatie naar preproductie geen waarde toevoegt, is het toch noodzakelijk 
.
Nadat een build gereed is voor productie, moet het leiderschap de release goedkeuren voordat deze kan worden geïmplementeerd. De goedkeuring vindt plaats in een vergadering. Het duurt vier dagen om de leiding zover te krijgen om bijeen te komen en de release te bespreken.
Uiteindelijk activeert Tim de functie en bereikt deze de klant hier in de rechterbovenhoek van de VSM. Als de configuratie van de productieserver is afgedreven waardoor deze niet meer in lijn is met de preproductie, moet Tim deze eerst bijwerken, wat één dag 
in beslag neemt.
De metrische gegevens van de klantwaarde berekenen
Nu kunnen we kijken naar de belangrijkste metrische prestatiegegevens en kijken hoe we meten.
totale doorlooptijd is de tijd die nodig is om een functie naar de klant te brengen. Hier is de totale tijd 22 dagen. Procestijd is de tijd die wordt besteed aan een functie die waarde heeft voor de klant. Hier bevat de procestijd vier dagen voor codering plus één dag om de functie te implementeren, wat in totaal vijf dagen geeft.
De activiteitsverhouding is procestijd gedeeld door de totale doorlooptijd:
$${Activiteitsratio\ =\ }{\dfrac{Procestijd}{Totale\ doorlooptijd}}$$
Dit is onze efficiëntie. Vermenigvuldig de efficiëntie met 100 om een percentage te verkrijgen. Het resultaat is groter dan 0% en meestal minder dan 100%. Een hoger percentage geeft een grotere efficiëntie aan.
Vervang onze nummers en we krijgen:
$${Activiteitsratio\ =\ }{\dfrac{5\ dagen}{22\ dagen}}{\ =\ .23}$$
Vermenigvuldig het resultaat met 100 en u krijgt 23%.
Zoals u kunt zien, hebben we veel ruimte voor verbetering. En het duurt 22 dagen om een functie te ontwikkelen, is te lang.
Tim: Dus hoe helpt dit ons?
Waar gaan we vandaan?
Mara: Het helpt om te zien waar we nu zijn, zodat we de gebieden kunnen aanwijzen waar zich afval bevindt. We willen de tijd minimaliseren die we besteden zonder waarde voor de klant. Ik geloof dat we onze efficiëntie echt kunnen verbeteren door een DevOps-benadering te gebruiken. Ten eerste kunnen we veel van deze stappen automatiseren, wat de tijd aanzienlijk verkort.
Ik stel niet voor dat we onze huidige processen laten vallen, maar ik denk dat we in kleine stappen kunnen werken aan een efficiënter proces zonder te verstoren wat we momenteel hebben.
Laten we eens kijken naar een aantal gebieden waar we kunnen verbeteren.
Andy: We kunnen ook aan het begin beginnen. Het duurt lang voordat ik een label op de code heb, zodat we de nieuwe functie kunnen starten. Ik moet naar de ontwikkelaars lopen en hen vragen om in te checken wat ze hebben, zodat we kunnen bouwen en testen. Als je erachter kunt komen hoe je dat kunt versnellen, heb je mijn aandacht.
Ik zag ook dat je daar geen tijd hebt voor de build zelf. Dat duurt nu een halve dag. Het zou fijn zijn om te zien dat die tijd verbetert.
Amita: En dev werkt de spreadsheet niet altijd bij om te laten weten dat er een nieuwe build is die moet worden getest. Het zou tijd besparen als er een manier was om ervoor te zorgen dat dat onderdeel wordt uitgevoerd.
Mara: Geweldig! Ik denk dat DevOps ons kan helpen met al deze problemen.
Andy: We hebben geen tijd om het proces nu te wijzigen. Je hebt Irwin gehoord. We zijn hier in crisismodus!
Mara: ik begrijp. Laten we nu doen wat we altijd doen. Maar we kunnen allemaal nadenken over ons deel in het proces en hoe we kunnen verbeteren. We kunnen kleine wijzigingen parallel aanbrengen in onze huidige processen. We kunnen vervolgens zien of DevOps ons helpt zonder te verstoren wat we hebben. Ik bewaar deze kaart en de metrische prestatiegegevens. Als we uiteindelijk azure DevOps-procedures gaan gebruiken, kunnen we de getallen opnieuw bekijken. Misschien kunnen we de VSM op een bepaald moment bijwerken.