Vraag een teamleider hoe lang een aanvraag duurt, en je krijgt bijna altijd een te optimistisch antwoord. "Dat is zo gepiept, hooguit een uurtje werk." Vraag vervolgens hoe lang het echt duurt voordat de aanvraag de deur uit is, en het antwoord is vaak: twee weken. Dat gat tussen die twee getallen is precies waarom cycle time zo'n nuttig begrip is.

Cycle time is de tijd die nodig is om één stuk werk daadwerkelijk af te ronden, van het moment dat iemand ermee begint tot het moment dat het klaar is. Belangrijk: dit is niet hetzelfde als doorlooptijd (lead time), die ook de wachttijd meerekent voordat iemand er überhaupt aan begint. Cycle time meet alleen de tijd van echt werken.

Het verschil tussen die twee getallen, uurtje werk versus twee weken wachten, is meteen de reden waarom cycle time zo waardevol is. Het legt bloot hoeveel van de doorlooptijd eigenlijk wachttijd is, en dat is bijna altijd meer dan mensen denken.

Waarom we structureel te optimistisch schatten

Daniel Kahneman noemde dit de planning fallacy: mensen schatten de tijd voor een taak stelselmatig te laag in, omdat ze zich vooral het ideale scenario voorstellen. Geen onderbrekingen, geen wachten op een collega, geen tussentijdse vraag van de klant. In de praktijk is dat ideale scenario zeldzaam.

Door cycle time daadwerkelijk te meten, in plaats van te schatten, ontstaat een eerlijk beeld. En dat beeld is meestal ongemakkelijk: niet omdat mensen te langzaam werken, maar omdat het echte werk maar een fractie is van de totale tijd die een taak in het systeem doorbrengt. De rest is wachten op een handtekening, een goedkeuring, of gewoon een volle inbox.

Stappenplan: zo meet je je eigen cycle time

1. Kies één type taak of dossier dat regelmatig terugkomt (bijvoorbeeld een aanvraag, een offerte, een supportticket).

2. Noteer per item het moment waarop iemand er daadwerkelijk mee begint, en het moment waarop het echt klaar is.

3. Meet dit voor minimaal 15 tot 20 items, niet voor één uitschieter: gemiddelden zeggen meer dan een enkel geval.

4. Reken daarnaast de totale doorlooptijd uit: van binnenkomst tot oplevering, inclusief alle wachttijd.

5. Leg beide getallen naast elkaar: is het verschil klein, dan zit je probleem in de uitvoering; is het verschil groot, dan zit het in het wachten.

6. Zoek in dat laatste geval uit welke stap de meeste wachttijd veroorzaakt, en pak die specifieke stap aan, in plaats van iedereen te vragen harder te werken.

Een voorbeeld uit de praktijk

Bij een gemeente waar we de vergunningverlening doorlichtten, gaven medewerkers aan dat een standaardaanvraag "ongeveer twee uur werk" was. Toen we de daadwerkelijke cycle time maten, klopte dat: gemiddeld 1 uur en 50 minuten aan echte beoordelingstijd. Het probleem zat dus niet in de cycle time.

Het zat in het verschil met de doorlooptijd: gemiddeld 23 dagen tussen aanvraag en besluit. Bijna alle tijd ging op aan wachten: op een collega voor een tweede check, op een reactie van de aanvrager, op een vast wekelijks overlegmoment waar dossiers werden besproken. Door dat overlegmoment te vervangen door een doorlopend proces, daalde de doorlooptijd naar 9 dagen, zonder dat er één extra medewerker bij kwam.

De waarde van cycle time zit 'm dus niet alleen in het meten zelf, maar in wat het zichtbaar maakt: het gat tussen wat mensen denken dat een proces kost, en wat het daadwerkelijk kost aan wachten. Dat gat vinden is negen van de tien keer waardevoller dan harder werken aan de taak zelf.

Wil je leren hoe je dit soort tijdverspilling in je eigen processen blootlegt? In de Lean Green Belt opleiding leer je hoe je cycle time en doorlooptijd meet en verbetert.