Doorlooptijd, cyclustijd en wachttijd

Wat zijn doorlooptijd, cyclustijd en wachttijd?

Het zijn vier verschillende klokken op hetzelfde stuk werk. De meeste discussies erover ontstaan omdat twee mensen elk naar een andere klok kijken zonder dat te beseffen.

Doorlooptijd is de klok van de klant. Ze start op het moment dat de klant iets vraagt (een bestelling, een offerte, een herstelling, een verlofaanvraag) en stopt wanneer hij het heeft. Alle wachttijd onderweg telt mee. In het Engels heet dit lead time.

Cyclustijd is de klok van wie het werk doet. Ze meet hoelang één item nodig heeft om door één stap te gaan, of door het hele proces, afhankelijk van de school die je volgt. Precies dat is het probleem met het woord, en daar gaat de volgende sectie over.

Wachttijd is het gat tussen twee stappen: het dossier ligt in een inbox, de bestelling wacht op een plek in de planning, de factuur wacht op een handtekening. In kantoorprocessen is dat bijna altijd het grootste stuk van de doorlooptijd.

Bewerkingstijd is het stuk waarin iemand effectief aan het item werkt. In het Engels zeggen ze touch time, processing time of service time. Doorlooptijd is bewerkingstijd plus wachttijd, en die twee lijken zelden op elkaar. Een offerte die vijf werkdagen nodig heeft om bij de klant te geraken, bevat vaak zo'n veertig minuten echt werk: 40 uur op de klok van de klant voor 40 minuten bewerking, minder dan twee procent.

Twee woorden horen nog bij de familie. Throughput is een tempo, geen duur: afgewerkte items per dag of per week. Work in progress (WIP) is het aantal items dat gestart is maar nog niet klaar. Little's law verbindt die drie, verderop.

Het lemma doorlooptijd legt uit hoe je de volledige klok per case uit een event log haalt. Dit lemma gaat over de familie: welk woord wat betekent, waar ze botsen, en welk getal je eerst aanpakt.

Drie vocabularia, één vertaaltabel

Lean, process mining en softwareteams gebruiken deze woorden elk op hun eigen manier. Elk vakgebied heeft ze gedefinieerd voor zijn eigen doel, en niemand heeft die definities ooit op elkaar afgestemd.

Lean komt van de fabrieksvloer. Het Lean Enterprise Institute definieert cycle time als de tijd die nodig is om één stuk te maken of één processtap af te ronden, gemeten met de chronometer; in value stream mapping is het de tijd die een operator nodig heeft om al zijn handelingen één keer te doorlopen voor hij herbegint. In lean is cyclustijd dus tijd per stuk aan één werkpost. Lead time is in datzelfde lexicon de tijd die één stuk nodig heeft om van begin tot einde door een proces of value stream te gaan.

Process mining leest timestamps uit systemen. De volledige klok per case heet daar meestal throughput time (Microsoft definieert het in Power Automate Process Mining als de tijd tussen het eerste en het laatste event van een case), of lead time en flow time in de academische literatuur. Wachttijd is de tijd dat een case wacht tot een resource vrijkomt; service time is de tijd dat er aan de case gewerkt wordt. Zie je op een process mining dashboard het woord cycle time staan, kijk dan na wat de leverancier bedoelt. Vaak staat het daar voor de volledige klok van begin tot einde, het omgekeerde van de lean-betekenis.

Softwareteams meten werkitems. De Kanban Guide definieert cycle time als de tijd tussen het moment dat een werkitem gestart is en het moment dat het af is, en throughput als het aantal afgewerkte werkitems per tijdseenheid. De vier DORA-metrics gebruiken lead time for changes: de tijd van een commit in versiebeheer tot die wijziging in productie draait. Beide starten de klok wanneer het werk start, niet wanneer de klant iets vroeg.

Onze huisdefinities, en hoe ze zich vertalen:

• Doorlooptijd: van vraag tot levering, alle wachttijd inbegrepen. Lean zegt lead time of production lead time. Process mining zegt throughput time, case duration of flow time. Softwareteams hebben geen exact equivalent; de lead time for changes van DORA dekt alleen het staartstuk van commit tot productie.

• Cyclustijd: de werkklok op één item. We zeggen er altijd bij welke scope we bedoelen: één stap (de lean-betekenis) of het hele proces van gestart tot af (de Kanban-betekenis). Staat er niets bij, ga dan uit van één stap.

• Wachttijd: het gat tussen het einde van een stap en het begin van de volgende. Lean rekent het tot verspilling, nooit tot waardetoevoegende tijd. Process mining zegt waiting time. Softwareteams zien het als de tijd dat een item in een kolom To Do of Wachten staat.

• Bewerkingstijd: het effectieve werk aan het item. Lean zegt processing time of value-creating time. Process mining zegt service time of activity duration.

• Throughput: items per periode. Niet te verwarren met throughput time, dat is een duur.

Voor je een kolom uit het dashboard van iemand anders naast de jouwe legt, vraag je welke van deze vijf ze bedoelt. Twee afdelingen die een lean-cyclustijd met een Kanban-cyclustijd vergelijken, discussiëren een uur en hebben allebei gelijk.

Doorlooptijd tegenover cyclustijd: wiens klok loopt er?

Doorlooptijd loopt op de klok van de klant. Die klant heeft er geen boodschap aan dat de bestelling een week in een wachtrij lag voor iemand ze opende. Hij heeft maandag iets gevraagd en wil weten wanneer het er is. Doorlooptijd start dus bij de vraag, en het is het getal dat opduikt in klachten, in service level agreements en in de reden waarom een klant naar een concurrent stapt.

Cyclustijd loopt op de klok van wie het werk doet. Ze start wanneer iemand het item oppakt. Ze vertelt je hoe snel je mensen of je machine het werk afhandelen eens ze eraan beginnen. Dat is het getal dat je nodig hebt voor capaciteitsplanning en om te zien welke stap traag geworden is.

Een korte doorlooptijd heeft beide nodig: een lage cyclustijd en korte wachtrijen voor elke stap. Een team kan elke bestelling in twintig minuten afhandelen en toch pas na drie weken leveren, omdat die twintig minuten aan het einde van een lange wachtrij vallen. Zo rapporteert een verbeterproject dat alleen cyclustijd meet, succes terwijl de klant niets merkt.

Hoe meet je ze uit een event log?

Alle vier de klokken komen uit dezelfde grondstof: timestamps per activiteit per case, de rijen van een event log. Wat je kan berekenen, hangt af van hoeveel timestamps elke activiteit heeft.

Met één timestamp per activiteit, en dat is wat de meeste ERP-, CRM- en ticketingsystemen je geven, weet je wanneer elke stap gebeurd is, maar niet hoelang ze duurde. Je kan de doorlooptijd berekenen (laatste timestamp min eerste) en de tijd tussen opeenvolgende activiteiten. Bewerkingstijd en wachttijd kan je niet uit elkaar halen, want het gat tussen 'order ingevoerd' en 'order gecontroleerd' bevat zowel het wachten als de controle. Microsoft maakt dat onderscheid expliciet in de documentatie van Power Automate Process Mining: een event log heeft één timestamp per event, een activity log heeft een start- en een eindtimestamp per activiteit.

Met een start- en een complete-timestamp per activiteit heb je het volledige beeld. De XES-standaard voor event logs heeft daar een lifecycle-extensie voor, met transities als schedule, start, suspend, resume en complete. Complete min start is bewerkingstijd. Start van de volgende activiteit min complete van de vorige is wachttijd. Tel de wachttijden op en je hebt het beeld van de wachtrijen per stap, en daar leeft bottleneck analysis van.

Met maar één timestamp blijft het gat tussen twee opeenvolgende activiteiten een bruikbare benadering van de wachttijd, zolang de bewerkingstijd klein is tegenover het gat, en in kantoorprocessen is dat de normale situatie. Veertig minuten werk in een gat van negen dagen verandert de rangorde van je wachtrijen niet.

Rekenvoorbeeld: van order tot factuur bij een machinebouwer

Een machinebouwer verkoopt wisselstukken uit voorraad aan klanten die zijn machines hebben. Van order tot factuur zijn er vijf stappen: orderinvoer, technische controle door engineering (juist onderdeel voor die machineversie), prijs- en kredietgoedkeuring door de salesmanager, picken-verpakken-verzenden, en factureren. De event log geeft voor een typisch order deze cijfers, in werkdagen van acht uur:

• Orderinvoer: 30 minuten werk, daarna 4 dagen wachten op engineering.

• Technische controle: 90 minuten werk, daarna 9 dagen wachten op de goedkeuring van de salesmanager.

• Goedkeuring: 30 minuten werk, het magazijn pikt het dezelfde dag op.

• Picken, verpakken en verzenden: 2 uur werk, daarna 7 dagen wachten op de maandelijkse factuurrun.

• Factureren: 90 minuten werk.

Doorlooptijd: 22 werkdagen, of 176 uur. Bewerkingstijd: 30 + 90 + 30 + 120 + 90 minuten, dus 6 uur. De drie genoemde wachtrijen zijn samen 20 dagen; de overige 10 uur of zo zijn kleine gaten tussen de overdrachten. Bewerkingstijd is ongeveer 3,4 procent van de doorlooptijd. Wat je ook doet met die 6 uur, de 22 dagen bewegen niet.

Welke wachtrij pak je eerst aan? De wachtrij van 9 dagen voor goedkeuring zit vóór de levering, dus elke dag die je daar wint, voelt de klant. De wachtrij van 7 dagen voor facturatie zit na de levering. De klant merkt er niets van, maar het bedrijf wel: het geld komt een week later binnen dan nodig, en de oplossing is een beleidskeuze (factureren bij verzending in plaats van in een maandelijkse run) die niets kost. Dus: eerst de wachtrij van 9 dagen, want dat is de klok van de klant, en dezelfde week de facturatieregel aanpassen, want dat is gratis. De wachtrij van 4 dagen bij engineering komt op de derde plaats, en een vaste regel dat gekende onderdeelnummers de technische controle overslaan, maakt ze misschien helemaal leeg.

Merk op dat de lean-reflex, de technische controle van 90 minuten versnellen, de slechtste investering van de lijst is. Halveer ze en je wint 45 minuten op een doorlooptijd van 22 dagen.

Little's law op dezelfde cijfers

Little's law zegt dat het gemiddelde aantal items in een systeem gelijk is aan het aankomsttempo maal de gemiddelde tijd die elk item in het systeem doorbrengt. John Little van MIT gaf er in 1961 het eerste bewijs van, en de wet geldt of de wachtrij nu op volgorde van aankomst, op prioriteit of willekeurig wordt afgewerkt. In operationele taal: work in progress = throughput x doorlooptijd.

De machinebouwer werkt ongeveer 3 wisselstukorders per werkdag af. Met een doorlooptijd van 22 dagen betekent dat 3 x 22 = 66 open orders op elk moment. Breng de goedkeuringswachtrij van 9 dagen terug naar 1 en de doorlooptijd zakt naar 14 dagen, dus de stapel open orders krimpt naar 3 x 14 = 42, met dezelfde mensen die hetzelfde werk doen.

De wet werkt ook in de andere richting. Tel op een maandag 66 open orders, weet dat je er 3 per dag afsluit, en de gemiddelde doorlooptijd is 66 / 3 = 22 dagen. Eén telling en één tempo geven je de klok van de klant nog voor je een event log hebt.

Wat AI-agents veranderen

Een AI-agent die het binnenkomende order leest, de machineversie opzoekt, de technische controle voorbereidt en een prijs voorstelt, doet de 6 uur bewerkingstijd in een paar minuten. Dat lijkt de grote winst, tot je het op de tijdlijn legt: die bewerkingstijd was 3,4 procent van de doorlooptijd. Blijven de wachtrijen staan, dan ziet de klant 22 dagen veranderen in 21 dagen en 18 uur.

Wat agents echt doen, is het wachten zichtbaar maken. Als het werk seconden duurt, kan niemand nog beweren dat het order traag was omdat de controle moeilijk was. Die 9 dagen waren altijd al de goedkeuringswachtrij, en nu is dat het enige wat nog op de grafiek staat.

Vervolgens verschuift de wachtrij. Het voorstel van de agent moet nog altijd door een mens vrijgegeven worden, dus de goedkeuringsinbox wordt de nieuwe wachttijd. En die kan groter worden: een manager die vroeger 3 orders per dag goedkeurde, krijgt nu 30 voorstellen per dag. Bewerkingstijd versnellen zonder de goedkeuringsstap te herdenken, bouwt een grotere wachtrij voor dezelfde persoon. De oplossing is dezelfde als voor er agents bestonden: drempels waaronder geen goedkeuring nodig is, goedkeuring in bulk met de uitzonderingen apart gemarkeerd, en een tweede goedkeurder. Alleen leveren de cijfers nu zelf het argument.

Wat meet je eerst in een KMO?

Je hebt geen process mining platform nodig om te beginnen. Je hebt één proces en drie timestamps nodig.

1. Kies één proces waarover klanten klagen of dat geld vastzet: offertes, order tot factuur, aankoopgoedkeuringen, herstellingen.

2. Zet een timestamp op drie overdrachten. Ontvangen van de klant, eerste keer opgepakt door je team, en geleverd. Verandert er al een statusveld op die momenten, exporteer dan de wijzigingshistoriek. Zo niet, voeg een datumkolom toe en laat je mensen ze een maand lang invullen.

3. Bereken de drie getallen per case en neem de mediaan: doorlooptijd (geleverd min ontvangen), wachttijd voor de eerste aanraking (opgepakt min ontvangen), en de rest. Beschouw de tijd van oppakken tot leveren de eerste maand als een mengeling van bewerking en wachten; splitsen kan later met meer timestamps.

4. Publiceer ze wekelijks, altijd op dezelfde plek, naast throughput (cases afgesloten die week) en WIP (cases open op vrijdag). Samen vertellen ze je of een verbetering echt is: daalt de doorlooptijd maar stijgt de WIP, dan heb je een wachtrij verplaatst, niet weggewerkt.

De cijfers van de eerste week zullen ruw zijn. Een gemeten mediaan is meer waard dan een gemiddelde dat iedereen gokt, en zodra de wachttijd op een scherm naast de bewerkingstijd staat, verandert de maandagvergadering vanzelf.