Rework loop

Wat is een rework loop?

Een rework loop is het patroon waarbij dezelfde activiteit binnen één case herhaald wordt. Een factuur wordt aangemaakt, afgekeurd, aangepast en opnieuw aangemaakt. Een aanvraag gaat naar goedkeuring, komt terug met opmerkingen, wordt herwerkt en moet opnieuw door dezelfde goedkeuring.

In lean en Six Sigma is rework al decennia een klassieke vorm van verspilling: werk dat opnieuw gedaan wordt om een fout recht te zetten. In process mining krijgt dat patroon een visuele vorm: in de proceskaart verschijnen herhalingen als pijlen die terugkeren naar een vorige activiteit. Dat zijn de rework loops.

Hoe herken je het in je event log?

Als je event log op orde is, is rework niet moeilijk te detecteren. Je hebt een case ID, een activiteit en een tijdstip nodig. Binnen één case ID tel je hoe vaak dezelfde activiteit-naam voorkomt. Staat die teller boven één, dan heb je per definitie rework op die stap.

Process-miningtools maken dat visueel. Je ziet een pijl die van een activiteit naar zichzelf loopt (een self-loop), of een pijl die teruggaat naar een vorige activiteit. Variantanalyse scheidt de zware gevallen van de lichte: de gelukkige cases doorlopen het proces één keer, de ongelukkige zitten in een variant die meerdere keren door dezelfde goedkeuring gaat.

De kost van rework

Rework kost op drie niveaus. Eerst is er de directe kost per herhaling: elke extra goedkeuring of correctie vraagt tijd van iemand. Vijftien minuten per extra lus, over duizenden cases per jaar, is een serieuze hap uit een teamcapaciteit.

Dan is er de klantkant: een langere doorlooptijd. De klant wacht langer op zijn factuur of zijn antwoord, en dat voelt hij.

En er is first-time-right: het aandeel cases dat in één keer juist afgehandeld wordt. Hoe lager die ratio, hoe vaker je team brandjes blust in plaats van nieuw werk op te leveren. Rework is werk dat de klant niet herkent en niet betaalt: de kost zit bij jou.

Typische oorzaken

• Onvolledige intake: op het moment dat de case start, ontbreken velden die later wel nodig blijken. De case moet dan terug om die info alsnog op te halen.

• Onduidelijke regels: goedkeurders passen verschillende criteria toe. Wat de ene laat passeren, stuurt de andere terug.

• Slechte master data: verouderde klantgegevens, foute BTW-codes, inactieve artikelen. Het proces draait correct op foute input.

• Hand-offs tussen teams: wat voor sales volledig is, is voor finance nog niet af.

Voorbeeld: facturatie met BTW-correcties

Stel een klassieke facturatieflow in een KMO. In de ideale variant wordt een factuur aangemaakt op basis van een order, goedgekeurd en verstuurd.

De event log toont iets anders. Bij een deel van de cases zie je: factuur aangemaakt, goedgekeurd, verstuurd, gecrediteerd, opnieuw aangemaakt, opnieuw goedgekeurd, opnieuw verstuurd. De oorzaak zit in een verkeerde BTW-code op een artikel die pas bij de boekhoudkundige controle opvalt. Elke rework loop kost drie extra activiteiten en twee werkdagen doorlooptijd. Process mining toont dat het probleem in je master data begint, niet bij de facturatiemedewerker. Je kan dus de BTW-codes opkuisen in plaats van extra controles te leggen.

Rework versus retry

Rework gebeurt op proces-niveau. Een mens of een team stelt vast dat een resultaat niet voldoet en herhaalt een of meer bedrijfsactiviteiten. De lus is zichtbaar in de event log als herhaalde activiteiten binnen dezelfde case.

Retry is technisch: een API-call mislukt, een batchjob valt uit, een integratie krijgt een timeout, en het systeem probeert automatisch opnieuw. Die retries horen in je infrastructuurlogs, niet in je bedrijfs-event-log. Sijpelen ze wel binnen, dan lijkt er meer rework dan er werkelijk is.