De efficiëntie van processen beoordelen met behulp van waardestroomanalyse
Wanneer u een waardestroomtoewijzing of VSM maakt, kunt u hiermee uw huidige releasecyclusproces analyseren. Het doel van een VSM is visueel weer te geven waar in het proces een team waarde creëert, en waar verspilling optreedt. 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 het doet.
Mara, die nieuw is in 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. Het blijkt dat volwassen teams releases doorgaans sneller, met meer zelfvertrouwen en met minder bugs vrijgeven 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 naar haar analyse kijken.
Het huidige proces begrijpen
Mara verzamelt het team in de vergaderruimte om haar VSM te presenteren.
Mara: Een VSM helpt ons te 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 door onze huidige releasecyclus wordt verplaatst.
Een paar mensen rollen met hun ogen, maar Mara gaat door.
Ontwikkelingsprocessen
Het maken van een nieuwe functie begint momenteel met het maken van een label in broncodebeheer 
. Er is éé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 dat we kunnen gaan werken. Dit proces kan wel drie dagen duren, en heeft geen waarde voor de klant. Dingen zonder waarde voor de klant moeten zo min 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 werken om toegang te krijgen tot het bronbeheer. Deze tijd heeft een waarde voor de klant. Die wil deze functie hebben.
Testprocessen
Nadat we hebben besloten dat we een stabiele build hebben, werken we een spreadsheet bij om Amita te vertellen dat er een build gereed is voor testen en waar deze te vinden 
is. Het duurt twee dagen voordat ze op de hoogte is.
Amita test de build 
handmatig. Dit proces duurt langer naarmate de codebasis groeit. Voorlopig houden we het op drie dagen. Ze e-mailt vervolgens Andy met bugrapporten. Testen voegt geen waarde toe, maar het 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 aan de juiste ontwikkelaars toewijst.
Operationele processen
Wanneer Amita een build goedkeurt, stuurt ze die door naar 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 duurt ongeveer twee dagen om Tim te implementeren voor preproductie en enkele tests uit te voeren. Nogmaals, wanneer de implementatie naar preproductie geen waarde toevoegt, is het 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 bijeen te krijgen om de release te bespreken.
Uiteindelijk implementeert Tim de functie en de functie maakt deze hier aan de klant in de rechterbovenhoek van de VSM. Als de configuratie van de productieserver is afgelopen zodat deze niet synchroon is met preproductie, moet Tim deze eerst bijwerken, wat één dag 
duurt.
De metrische gegevens voor klantwaarde berekenen
Nu kunnen we kijken naar de belangrijkste metrische prestatiegegevens en kijken hoe we meten.
De totale doorlooptijd is de tijd die het kost voordat een functie bij de klant terechtkomt. 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:
$${Activity\ ratio\ =\ }{\dfrac{Process\ time}{Total\ lead\ time}}$$
Dit is onze efficiëntie. Vermenigvuldig de efficiëntie met 100 om een percentage te krijgen. Het resultaat is groter dan 0%, en meestal minder dan 100%. Een hoger percentage geeft een grotere efficiëntie aan.
Vul onze eigen cijfers in, en we krijgen:
$${Activity\ ratio\ =\ }{\dfrac{5\ days}{22\ days}}{\ =\ .23}$$
Vermenigvuldig het resultaat met 100 en u krijgt 23%.
Zoals u ziet, is er veel ruimte voor verbetering. En 22 dagen voor het ontwikkelen van een functie is te lang.
Tim: Hoe helpt dit ons?
Wat doen we nu?
Mara: Het helpt om te zien waar we nu zijn, zodat we de gebieden kunnen aanwijzen waar zich afval bevindt. We willen zo min mogelijk tijd besteden aan dingen die geen waarde opleveren voor de klant. Ik denk dat we onze efficiëntie aanzienlijk kunnen verbeteren door een DevOps-benadering te gebruiken. Voor één ding kunnen we veel van deze stappen automatiseren, wat zeker op tijd afsnijdt.
Ik zeg niet dat we onze huidige processen moeten afschaffen, maar ik denk dat we in kleine stappen toe kunnen werken naar een efficiënter proces, zonder te verstoren wat we momenteel hebben.
Laten we eens kijken naar een paar gebieden waar we iets kunnen verbeteren.
Andy: We kunnen net zo goed beginnen aan het begin. Het kost me veel tijd om een label op de code te krijgen 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.
En ik heb ook gezien dat je geen tijd hebt opgenomen voor het bouwen zelf. Dat duurt momenteel een halve dag. Het zou mooi zijn als dat sneller kon.
Amita: En dev werkt het spreadsheet niet altijd bij om me 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 die punten.
Andy: We hebben geen tijd om het proces nu te wijzigen. Jullie hebben Irwin gehoord. We zitten in een crisistoestand!
Mara: Ik begrijp het. Laten we voorlopig hetzelfde doen als altijd. Maar we kunnen allemaal nadenken over onze rol in het proces, en hoe we het kunnen verbeteren. We kunnen beginnen kleine wijzigingen aan te brengen, parallel aan 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 gegeven moment bijwerken.