[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fXfvQXyzC7Qoil8Q_E7ag2ClrIfVjMqDK4NgLIPDpk9Y":3},{"item":4},{"id":5,"idKnowledge":6,"idDomain":7,"idCluster":8,"kindOverride":9,"slug":10,"title":11,"description":12,"bodyMarkdown":13,"bodyHtml":14,"author":15,"date":16,"createdAt":17,"topics":18,"image":31,"hasDownload":32,"fileName":9,"youtubeId":31,"domainCrumb":33,"clusterCrumb":36},"154","84269ACF-1B9D-5D4B-8D25-42515D7DCF44","B5C0C140-5201-C54B-9B13-F29BA94F42E7","C92B8C4B-2D51-5743-A1D1-0B229521D4E6","","how-to-identify-handovers-delays-and-rework","Hoe handovers, vertragingen en herwerk te identificeren","De meeste procesverspilling zit verborgen in de ruimte tussen teams en systemen. Zo brengt u overdrachten, vertragingen en herwerk in kaart voordat u iets automatiseert.","Uw proces ziet er overzichtelijk uit op het whiteboard. Orders komen binnen, worden gepickt, gefactureerd, verzonden. Eenvoudig. Maar ergens tussen het sluiten van de deal door de salesmedewerker en het ontvangen van de goederen door de klant, voert één persoon dezelfde gegevens opnieuw in, valt één e-mail twee dagen tussen wal en schip, en pikt het magazijn een order opnieuw omdat de originele picklijst een verkeerde hoeveelheid vermeldde. Niemand heeft dat verspilling ontworpen — het is er gewoon ingeslopen. Dit artikel laat u precies zien hoe u het vindt: de overdrachten die niemand heeft gedocumenteerd, de vertragingen die iedereen als normaal is gaan beschouwen, en het nawerk dat niemand meet.\n\n## Waarom blijft verborgen verspilling jarenlang onopgemerkt?\n\nDe meeste bedrijven meten uitkomsten — omzet, percentage tijdige leveringen, factuurfouten. Wat ze zelden meten is het *proces tussen* de uitkomsten. De periode tussen \"order ontvangen\" en \"factuur verzonden\" is voor de meeste organisaties een black box. Daarbinnen heeft elk team zijn eigen deel van het werk geoptimaliseerd, en niemand is eigenaar van de verbindingen.\n\nOverdrachten zijn de gevaarlijkste verbindingen. Een overdracht is elk moment waarop werk van de ene persoon, afdeling of het ene systeem naar het andere gaat. Elke overdracht is een potentieel breekpunt: informatie gaat verloren, context wordt niet meegenomen, en de volgende persoon begint met onvolledige input. In een gemiddeld productiebedrijf kan een verkooporder vijf of zes overdrachten doorlopen voordat het een verzonden product is — sales naar planning, planning naar inkoop, inkoop naar magazijn, magazijn naar productie, productie naar expeditie, expeditie naar facturering. Elke overgang is een risico.\n\nVertragingen zijn overdrachten die vast zijn komen te zitten. De inkooporder ligt in een inbox te wachten op goedkeuring. Het ontwerpbestand wacht op akkoord van de klant, dat niemand heeft nagevraagd. Het verzendlabel wacht omdat het ERP nog niet is bijgewerkt. Deze vertragingen zijn op papier onzichtbaar, omdat de procesbeschrijving aangeeft dat de stap *bestaat* — maar niet hoe lang die in werkelijkheid duurt.\n\nNawerk is wat er gebeurt na een fout die niemand als fout heeft geregistreerd. De factuur gaat eruit met de verkeerde prijs, en iemand corrigeert die stilletjes. De picklijst klopt niet, en het magazijnteam pickt opnieuw zonder iemand te informeren. Nawerk is de ijsberg: u ziet de gecorrigeerde output, niet de dubbele inspanning daaronder.\n\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F94?w=700&f=webp\" alt=\"process flow diagram showing handovers between five teams with delay gaps highlighted\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-left sm:mr-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n## Hoe vindt u overdrachten, vertragingen en nawerk in de praktijk?\n\nDe verreweg meest effectieve methode is verrassend eenvoudig: **volg één echte transactie van begin tot eind, samen met de mensen die het werk daadwerkelijk uitvoeren.** Niet de proceseigenaar. Niet de manager. De mensen wier handen er dagelijks aan zitten.\n\nZo voert u die trace in de praktijk uit:\n\n### Stap 1 — Kies een representatieve transactie\n\nKies een recente order, project of dossier dat typisch is — niet de nachtmerrie-uitzondering, niet de vlekkeloze topklant. In de productie: kies een standaard productieorder die vorige maand de volledige cyclus heeft doorlopen. In groothandel\u002Fdistributie: kies een order met minstens twee orderregels waarvoor een aankoop bij een leverancier nodig was. In professionele dienstverlening: kies een project waarbij meer dan één intern team betrokken was.\n\nVermijd het kiezen van een transactie waarvan het team weet dat u die gaat onderzoeken — u wilt normaal gedrag zien, geen ingestudeerde demonstratie.\n\n### Stap 2 — Volg de transactie, niet de procesbeschrijving\n\nVraag elke betrokken persoon u precies te laten zien wat hij of zij heeft gedaan, in het systeem of de tool die hij of zij heeft gebruikt, in de volgorde waarin het daadwerkelijk is uitgevoerd. Begin niet bij de procesbeschrijving — begin bij het transactie-ID en volg het chronologisch.\n\nStel bij elke stap de volgende vragen:\n- Waar kwam deze informatie vandaan?\n- Wat moest u opzoeken, kopiëren of opnieuw invoeren?\n- Was er iets dat u vertraagde of liet wachten?\n- Moest u iets corrigeren of opnieuw doen voordat u verder kon?\n- Aan wie draagt u dit over, en op welke manier?\n\nLeg de *werkelijke* tijdstempels vast waar mogelijk: e-mailheaders, systeemlogboeken, wijzigingsdatums van bestanden. Tijdstempels maken vertragingen zichtbaar die niemand vrijwillig zal benoemen — niet omdat ze iets verbergen, maar omdat ze die als normaal zijn gaan beschouwen.\n\n### Stap 3 — Breng elke overdracht expliciet in kaart\n\nMaak terwijl u de transactie volgt een overdrachtenkaart — geen stroomdiagram van stappen, maar een kaart van *overgangen*. Noteer bij elke overdracht:\n\n- **Wie draagt over** (persoon of systeem)\n- **Wie ontvangt** (persoon of systeem)\n- **Via welk medium** (e-mail, telefoongesprek, systeemtrigger, gedeelde map, mondeling)\n- **Welke informatie meegaat** met de overdracht\n- **Welke informatie ontbreekt** of opnieuw opgezocht moet worden door de ontvanger\n\nBij een gemiddelde groothandel zult u ontdekken dat een door de accountmanager bevestigde verkooporder een handmatige e-mail naar de inkoopafdeling triggert, die vervolgens de leverancierscode en hoeveelheid handmatig opnieuw invoert in het ERP — terwijl beide gegevens al in het CRM aanwezig zijn. Dat is één overdracht, één vertraging en één datainvoerrisico, allemaal in dezelfde naad.\n\n### Stap 4 — Meet de tijdsverschillen, niet alleen de stappen\n\nHier gaat de meeste procesanalyse mis. Men brengt de stappen in kaart en beschouwt het proces als gedocumenteerd. Maar de verspilling zit zelden *in* een stap — ze zit *tussen* stappen.\n\nZoek voor elke in stap 3 geïdentificeerde overdracht de werkelijke verstreken tijd op tussen het moment waarop de ene persoon of het ene systeem klaar was en het moment waarop de volgende persoon of het volgende systeem begon. Bij professionele dienstverleners is het gebruikelijk dat een afgeronde deliverable 48 uur in een gedeelde inbox blijft liggen voordat een volgend teamlid die opent — niet omdat iemand lui is, maar omdat er geen trigger is, geen melding, en geen eigenaarschap over de wachtrij.\n\nMaak een eenvoudige tijdsverschillentabel:\n\n| Overdracht | Van | Naar | Verwachte tijd | Werkelijke tijd (laatste 5 gevallen) | Verschil |\n|---|---|---|---|---|---|\n| Sales → Planning | CRM bevestigd | Planning geïnformeerd | 2 uur | Gemiddeld 1,5 dag | 1 dag |\n| Planning → Magazijn | Picklijst aangemaakt | Pick gestart | 30 min | 4 uur | 3,5 uur |\n\nZodra u cijfers heeft, verandert het gesprek. Niemand betwist een kolom die \"gemiddeld 1,5 dag\" aangeeft wanneer de verwachting 2 uur was.\n\n### Stap 5 — Vind het nawerk door te vragen naar correcties\n\nNawerk is de moeilijkst zichtbaar te maken verspilling, omdat het *na* het officiële proces plaatsvindt. De beste vraag om te stellen is: **\"Moest u, voordat u uw deel kon uitvoeren, ooit iets herstellen of aanvullen dat eigenlijk al eerder gedaan had moeten zijn?\"**\n\nIn de productie zal de productieplanner die stilletjes de stuklijst corrigeert voordat hij een werkorder vrijgeeft, dat niet als een stap benoemen — het is voor iedereen onzichtbaar behalve voor hemzelf. In professionele dienstverlening zal de projectmanager die het scopedocument herschrijft omdat de accountmanager het onjuist heeft opgesteld, die twee uur nergens registreren. Vraag expliciet naar correcties, herstelwerkzaamheden en \"voor de zekerheid\"-dubbelchecks.\n\nKijk ook naar:\n- Rijen in uw ERP met wijzigingstijdstempels die aanzienlijk later zijn dan de aanmaakdatum\n- E-mailthreads met onderwerpregels als \"RE: RE: RE: correctie\" of \"bijgewerkte versie\"\n- Dubbele records in welk systeem dan ook\n- Leeg gelaten velden die later verplicht zijn (waardoor iemand stroomafwaarts ze alsnog moet invullen)\n\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F93?w=700&f=webp\" alt=\"table comparing expected vs actual time for each handover in a wholesale order process\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-right sm:ml-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n## Welke patronen zult u het vaakst tegenkomen?\n\nIn productie, groothandel en professionele dienstverlening komen steeds dezelfde patronen terug:\n\n**De stille herinvoerlus:** Een order wordt bevestigd in het CRM, waarna iemand die handmatig opnieuw invoert in het ERP of het boekhoudpakket — elke order, elke dag. De persoon die dit doet, is het allang niet meer opgevallen, want het is al drie jaar zijn of haar taak.\n\n**Het goedkeuringsblokkade:** Eén persoon keurt elke inkooporder goed, elke factuur boven een drempelwaarde, of elke scopewijziging. Wanneer die persoon afwezig is, groeit de wachtrij. Bij terugkomst worden goedkeuringen in bulk verleend zonder inhoudelijke beoordeling. De controle die risico's moest beperken, is een vertraging geworden die risico's vergroot.\n\n**De \"even overleggen met\"-stap:** Het magazijn overlegt met sales voordat het een order boven een bepaalde waarde pickt. Sales overlegt met de klant voordat het een leverdatum bevestigt. De projectleider overlegt met de directeur voordat het een offerte verstuurt. Deze informele verificatiestappen zijn vaak legitiem — maar ze zijn zelden gedocumenteerd, vaak dubbel uitgevoerd, en vrijwel altijd trager dan iemand erkent.\n\n**De versieconflict-overdracht:** In professionele dienstverlening in het bijzonder wordt een document, tekening of specificatie per e-mail overgedragen. De ontvanger bewerkt het en stuurt het terug. De afzender bewerkt het origineel. Er bestaan nu twee versies. Iemand moet ze samenvoegen. Elk uur dat aan samenvoegen wordt besteed, is nawerk dat door een beter ontwerp voorkomen had kunnen worden.\n\n**De formaatvertaling:** Een leverancier stuurt een PDF-bevestiging. Iemand typt de hoeveelheden over in het ERP. Het ERP exporteert naar Excel. Iemand plakt het Excel-bestand in een rapport. Vier formaatvertalingen voor één stuk informatie — elk is een vertraging, elk is een potentiële fout.\n\n## Hoe onderscheidt u een echte overdracht van normale samenwerking?\n\nNiet elke overdracht is verspilling. Een overdracht wordt een probleem wanneer deze aan één of meer van de volgende criteria voldoet:\n\n- Informatie moet opnieuw worden ingevoerd in plaats van overgedragen\n- De ontvangende partij moet verduidelijkende vragen stellen voordat ze kan beginnen\n- Er is geen gedefinieerde trigger — de ontvanger weet pas dat hij kan beginnen wanneer hij toevallig gaat kijken\n- De overdracht kan alleen correct worden uitgevoerd dankzij de kennis van één specifieke persoon\n- De vertraging die de overdracht introduceert, is langer dan de stap zelf\n\nAls een overdracht aan geen van deze criteria voldoet — de informatie komt volledig aan, de trigger is automatisch, elk teamlid kan de overdracht ontvangen — is die waarschijnlijk prima zoals ze is.\n\n## Checklist: bent u klaar om overdrachten, vertragingen en nawerk in kaart te brengen?\n\nZorg ervoor dat u het volgende op orde heeft voordat u een procestrace uitvoert:\n\n- [ ] Een specifieke, echte transactie geselecteerd (geen hypothetische stroom)\n- [ ] Toegang tot de mensen die elke stap daadwerkelijk uitvoeren (niet alleen managers)\n- [ ] Toestemming om systeemlogboeken, e-mailtijdstempels en wijzigingshistorieken in te zien\n- [ ] Een neutrale gespreksleider die niet de proceseigenaar is\n- [ ] Een eenvoudig vastleggingsformaat — een spreadsheet of gedeeld document is voldoende\n- [ ] Per persoon gereserveerde tijd: 30–60 minuten ononderbroken doorloop\n- [ ] Overeenstemming dat u het werkelijke proces in kaart brengt, niet het beoogde\n\n## Veelgestelde vragen\n\n**Heb ik process mining-software nodig om dit te doen?**\nNee. Process mining-tools (zoals Celonis of Minit) zijn krachtig voor grote datasets, maar voor de meeste mkb-bedrijven komen de waardevolste inzichten voort uit een gestructureerd gesprek en een tijdsverschillentabel die u in een spreadsheet opbouwt. Begin met de handmatige trace — investeer pas in tooling wanneer u weet welke vragen u op schaal wilt beantwoorden.\n\n**Wat als mensen terughoudend zijn om het werkelijke proces te laten zien, omdat het hen slecht doet uitkomen?**\nFormuleer de sessie expliciet als een systeembeoordeling, niet als een prestatiebeoordeling. U zoekt naar procesfouten, niet naar menselijke fouten. De persoon die elke ochtend nawerk verricht, is niet het probleem — het proces dat dat nawerk vereist, is het probleem. Maak dit duidelijk vóór de sessie en benadruk het tijdens de sessie.\n\n**Hoeveel transacties moet ik tracen?**\nBegin met drie tot vijf transacties van hetzelfde type. Eén trace laat u zien wat *kan* gebeuren. Vijf traces laten u zien wat *gewoonlijk* gebeurt — en waar de variatie zit. Variatie is vaak belangrijker dan het gemiddelde: een overdracht die soms 2 uur duurt en soms 3 dagen is een urgenter probleem dan een overdracht die altijd 4 uur duurt.\n\n**Moet ik het huidige proces in kaart brengen vóór of ná het interviewen van medewerkers?**\nErna — altijd erna. Beginnen met de officiële procesbeschrijving beïnvloedt het gesprek in de richting van hoe het proces zou moeten werken. Beginnen met de echte transactie en mensen vragen hun werkelijke handelingen te laten zien, brengt de hiaten aan het licht. Zodra u het werkelijke beeld heeft, kunt u dat vergelijken met de officiële beschrijving — de verschillen zijn waar uw problemen zitten.\n\n**Op welk moment moet ik een ontwikkelaar of automatiseringsspecialist inschakelen?**\nPas nadat u een helder beeld heeft van alle overdrachten, vertragingen en nawerk in het huidige proces. Het automatiseren van een ongedocumenteerd of gebrekkig proces verankert de verspilling in de software. De kaart komt eerst — dan de oplossing.\n\n**Hoe bepaal ik welke problemen ik als eerste aanpak?**\nBeoordeel elk geïdentificeerd probleem op twee dimensies: frequentie (hoe vaak komt dit per week of maand voor?) en impact (hoeveel tijd, kosten of foutenrisico introduceert het per keer?). Los eerst problemen aan met een hoge frequentie én een hoge impact. Dagelijkse herinvoer van ordergegevens heeft prioriteit boven een maandelijkse omweg, ook al voelt die maandelijkse omweg dramatischer.\n\n---\n\nZodra u een helder beeld heeft van waar werk stagneert, wie informatie in zijn hoofd meedraagt, en waar nawerk wekelijks ongemerkt uren opslokt, staat u veel sterker om te beslissen wat u wilt aanpakken en hoe. Sommige problemen worden opgelost met een duidelijkere procesafspraak. Andere vereisen een systeemwijziging — het koppelen van twee platformen die momenteel handmatig gegevens uitwisselen, het bouwen van een workflow die de volgende stap automatisch triggert, of het toevoegen van een validatielaag die fouten onderschept voordat ze stroomafwaarts doorgaan. Als u op het punt bent waarop de kaart helder is maar de oplossing nog niet, is dat precies waar Loggix samenwerkt met bedrijven in productie, groothandel en professionele dienstverlening: in kaart brengen wat er daadwerkelijk gebeurt, ontwerpen wat er in plaats daarvan zou moeten gebeuren, en de maatwerksoftware of integraties bouwen die het betere proces duurzaam verankeren.","\u003Cp>Uw proces ziet er overzichtelijk uit op het whiteboard. Orders komen binnen, worden gepickt, gefactureerd, verzonden. Eenvoudig. Maar ergens tussen het sluiten van de deal door de salesmedewerker en het ontvangen van de goederen door de klant, voert één persoon dezelfde gegevens opnieuw in, valt één e-mail twee dagen tussen wal en schip, en pikt het magazijn een order opnieuw omdat de originele picklijst een verkeerde hoeveelheid vermeldde. Niemand heeft dat verspilling ontworpen — het is er gewoon ingeslopen. Dit artikel laat u precies zien hoe u het vindt: de overdrachten die niemand heeft gedocumenteerd, de vertragingen die iedereen als normaal is gaan beschouwen, en het nawerk dat niemand meet.\u003C\u002Fp>\n\u003Ch2>Waarom blijft verborgen verspilling jarenlang onopgemerkt?\u003C\u002Fh2>\n\u003Cp>De meeste bedrijven meten uitkomsten — omzet, percentage tijdige leveringen, factuurfouten. Wat ze zelden meten is het \u003Cem>proces tussen\u003C\u002Fem> de uitkomsten. De periode tussen "order ontvangen" en "factuur verzonden" is voor de meeste organisaties een black box. Daarbinnen heeft elk team zijn eigen deel van het werk geoptimaliseerd, en niemand is eigenaar van de verbindingen.\u003C\u002Fp>\n\u003Cp>Overdrachten zijn de gevaarlijkste verbindingen. Een overdracht is elk moment waarop werk van de ene persoon, afdeling of het ene systeem naar het andere gaat. Elke overdracht is een potentieel breekpunt: informatie gaat verloren, context wordt niet meegenomen, en de volgende persoon begint met onvolledige input. In een gemiddeld productiebedrijf kan een verkooporder vijf of zes overdrachten doorlopen voordat het een verzonden product is — sales naar planning, planning naar inkoop, inkoop naar magazijn, magazijn naar productie, productie naar expeditie, expeditie naar facturering. Elke overgang is een risico.\u003C\u002Fp>\n\u003Cp>Vertragingen zijn overdrachten die vast zijn komen te zitten. De inkooporder ligt in een inbox te wachten op goedkeuring. Het ontwerpbestand wacht op akkoord van de klant, dat niemand heeft nagevraagd. Het verzendlabel wacht omdat het ERP nog niet is bijgewerkt. Deze vertragingen zijn op papier onzichtbaar, omdat de procesbeschrijving aangeeft dat de stap \u003Cem>bestaat\u003C\u002Fem> — maar niet hoe lang die in werkelijkheid duurt.\u003C\u002Fp>\n\u003Cp>Nawerk is wat er gebeurt na een fout die niemand als fout heeft geregistreerd. De factuur gaat eruit met de verkeerde prijs, en iemand corrigeert die stilletjes. De picklijst klopt niet, en het magazijnteam pickt opnieuw zonder iemand te informeren. Nawerk is de ijsberg: u ziet de gecorrigeerde output, niet de dubbele inspanning daaronder.\u003C\u002Fp>\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F94?w=700&f=webp\" alt=\"process flow diagram showing handovers between five teams with delay gaps highlighted\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-left sm:mr-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n\u003Ch2>Hoe vindt u overdrachten, vertragingen en nawerk in de praktijk?\u003C\u002Fh2>\n\u003Cp>De verreweg meest effectieve methode is verrassend eenvoudig: \u003Cstrong>volg één echte transactie van begin tot eind, samen met de mensen die het werk daadwerkelijk uitvoeren.\u003C\u002Fstrong> Niet de proceseigenaar. Niet de manager. De mensen wier handen er dagelijks aan zitten.\u003C\u002Fp>\n\u003Cp>Zo voert u die trace in de praktijk uit:\u003C\u002Fp>\n\u003Ch3>Stap 1 — Kies een representatieve transactie\u003C\u002Fh3>\n\u003Cp>Kies een recente order, project of dossier dat typisch is — niet de nachtmerrie-uitzondering, niet de vlekkeloze topklant. In de productie: kies een standaard productieorder die vorige maand de volledige cyclus heeft doorlopen. In groothandel\u002Fdistributie: kies een order met minstens twee orderregels waarvoor een aankoop bij een leverancier nodig was. In professionele dienstverlening: kies een project waarbij meer dan één intern team betrokken was.\u003C\u002Fp>\n\u003Cp>Vermijd het kiezen van een transactie waarvan het team weet dat u die gaat onderzoeken — u wilt normaal gedrag zien, geen ingestudeerde demonstratie.\u003C\u002Fp>\n\u003Ch3>Stap 2 — Volg de transactie, niet de procesbeschrijving\u003C\u002Fh3>\n\u003Cp>Vraag elke betrokken persoon u precies te laten zien wat hij of zij heeft gedaan, in het systeem of de tool die hij of zij heeft gebruikt, in de volgorde waarin het daadwerkelijk is uitgevoerd. Begin niet bij de procesbeschrijving — begin bij het transactie-ID en volg het chronologisch.\u003C\u002Fp>\n\u003Cp>Stel bij elke stap de volgende vragen:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Waar kwam deze informatie vandaan?\u003C\u002Fli>\n\u003Cli>Wat moest u opzoeken, kopiëren of opnieuw invoeren?\u003C\u002Fli>\n\u003Cli>Was er iets dat u vertraagde of liet wachten?\u003C\u002Fli>\n\u003Cli>Moest u iets corrigeren of opnieuw doen voordat u verder kon?\u003C\u002Fli>\n\u003Cli>Aan wie draagt u dit over, en op welke manier?\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Leg de \u003Cem>werkelijke\u003C\u002Fem> tijdstempels vast waar mogelijk: e-mailheaders, systeemlogboeken, wijzigingsdatums van bestanden. Tijdstempels maken vertragingen zichtbaar die niemand vrijwillig zal benoemen — niet omdat ze iets verbergen, maar omdat ze die als normaal zijn gaan beschouwen.\u003C\u002Fp>\n\u003Ch3>Stap 3 — Breng elke overdracht expliciet in kaart\u003C\u002Fh3>\n\u003Cp>Maak terwijl u de transactie volgt een overdrachtenkaart — geen stroomdiagram van stappen, maar een kaart van \u003Cem>overgangen\u003C\u002Fem>. Noteer bij elke overdracht:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Wie draagt over\u003C\u002Fstrong> (persoon of systeem)\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Wie ontvangt\u003C\u002Fstrong> (persoon of systeem)\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Via welk medium\u003C\u002Fstrong> (e-mail, telefoongesprek, systeemtrigger, gedeelde map, mondeling)\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Welke informatie meegaat\u003C\u002Fstrong> met de overdracht\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Welke informatie ontbreekt\u003C\u002Fstrong> of opnieuw opgezocht moet worden door de ontvanger\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Bij een gemiddelde groothandel zult u ontdekken dat een door de accountmanager bevestigde verkooporder een handmatige e-mail naar de inkoopafdeling triggert, die vervolgens de leverancierscode en hoeveelheid handmatig opnieuw invoert in het ERP — terwijl beide gegevens al in het CRM aanwezig zijn. Dat is één overdracht, één vertraging en één datainvoerrisico, allemaal in dezelfde naad.\u003C\u002Fp>\n\u003Ch3>Stap 4 — Meet de tijdsverschillen, niet alleen de stappen\u003C\u002Fh3>\n\u003Cp>Hier gaat de meeste procesanalyse mis. Men brengt de stappen in kaart en beschouwt het proces als gedocumenteerd. Maar de verspilling zit zelden \u003Cem>in\u003C\u002Fem> een stap — ze zit \u003Cem>tussen\u003C\u002Fem> stappen.\u003C\u002Fp>\n\u003Cp>Zoek voor elke in stap 3 geïdentificeerde overdracht de werkelijke verstreken tijd op tussen het moment waarop de ene persoon of het ene systeem klaar was en het moment waarop de volgende persoon of het volgende systeem begon. Bij professionele dienstverleners is het gebruikelijk dat een afgeronde deliverable 48 uur in een gedeelde inbox blijft liggen voordat een volgend teamlid die opent — niet omdat iemand lui is, maar omdat er geen trigger is, geen melding, en geen eigenaarschap over de wachtrij.\u003C\u002Fp>\n\u003Cp>Maak een eenvoudige tijdsverschillentabel:\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Overdracht\u003C\u002Fth>\n\u003Cth>Van\u003C\u002Fth>\n\u003Cth>Naar\u003C\u002Fth>\n\u003Cth>Verwachte tijd\u003C\u002Fth>\n\u003Cth>Werkelijke tijd (laatste 5 gevallen)\u003C\u002Fth>\n\u003Cth>Verschil\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>Sales → Planning\u003C\u002Ftd>\n\u003Ctd>CRM bevestigd\u003C\u002Ftd>\n\u003Ctd>Planning geïnformeerd\u003C\u002Ftd>\n\u003Ctd>2 uur\u003C\u002Ftd>\n\u003Ctd>Gemiddeld 1,5 dag\u003C\u002Ftd>\n\u003Ctd>1 dag\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Planning → Magazijn\u003C\u002Ftd>\n\u003Ctd>Picklijst aangemaakt\u003C\u002Ftd>\n\u003Ctd>Pick gestart\u003C\u002Ftd>\n\u003Ctd>30 min\u003C\u002Ftd>\n\u003Ctd>4 uur\u003C\u002Ftd>\n\u003Ctd>3,5 uur\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Cp>Zodra u cijfers heeft, verandert het gesprek. Niemand betwist een kolom die "gemiddeld 1,5 dag" aangeeft wanneer de verwachting 2 uur was.\u003C\u002Fp>\n\u003Ch3>Stap 5 — Vind het nawerk door te vragen naar correcties\u003C\u002Fh3>\n\u003Cp>Nawerk is de moeilijkst zichtbaar te maken verspilling, omdat het \u003Cem>na\u003C\u002Fem> het officiële proces plaatsvindt. De beste vraag om te stellen is: \u003Cstrong>"Moest u, voordat u uw deel kon uitvoeren, ooit iets herstellen of aanvullen dat eigenlijk al eerder gedaan had moeten zijn?"\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>In de productie zal de productieplanner die stilletjes de stuklijst corrigeert voordat hij een werkorder vrijgeeft, dat niet als een stap benoemen — het is voor iedereen onzichtbaar behalve voor hemzelf. In professionele dienstverlening zal de projectmanager die het scopedocument herschrijft omdat de accountmanager het onjuist heeft opgesteld, die twee uur nergens registreren. Vraag expliciet naar correcties, herstelwerkzaamheden en "voor de zekerheid"-dubbelchecks.\u003C\u002Fp>\n\u003Cp>Kijk ook naar:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Rijen in uw ERP met wijzigingstijdstempels die aanzienlijk later zijn dan de aanmaakdatum\u003C\u002Fli>\n\u003Cli>E-mailthreads met onderwerpregels als "RE: RE: RE: correctie" of "bijgewerkte versie"\u003C\u002Fli>\n\u003Cli>Dubbele records in welk systeem dan ook\u003C\u002Fli>\n\u003Cli>Leeg gelaten velden die later verplicht zijn (waardoor iemand stroomafwaarts ze alsnog moet invullen)\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F93?w=700&f=webp\" alt=\"table comparing expected vs actual time for each handover in a wholesale order process\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-right sm:ml-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n\u003Ch2>Welke patronen zult u het vaakst tegenkomen?\u003C\u002Fh2>\n\u003Cp>In productie, groothandel en professionele dienstverlening komen steeds dezelfde patronen terug:\u003C\u002Fp>\n\u003Cp>\u003Cstrong>De stille herinvoerlus:\u003C\u002Fstrong> Een order wordt bevestigd in het CRM, waarna iemand die handmatig opnieuw invoert in het ERP of het boekhoudpakket — elke order, elke dag. De persoon die dit doet, is het allang niet meer opgevallen, want het is al drie jaar zijn of haar taak.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Het goedkeuringsblokkade:\u003C\u002Fstrong> Eén persoon keurt elke inkooporder goed, elke factuur boven een drempelwaarde, of elke scopewijziging. Wanneer die persoon afwezig is, groeit de wachtrij. Bij terugkomst worden goedkeuringen in bulk verleend zonder inhoudelijke beoordeling. De controle die risico's moest beperken, is een vertraging geworden die risico's vergroot.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>De "even overleggen met"-stap:\u003C\u002Fstrong> Het magazijn overlegt met sales voordat het een order boven een bepaalde waarde pickt. Sales overlegt met de klant voordat het een leverdatum bevestigt. De projectleider overlegt met de directeur voordat het een offerte verstuurt. Deze informele verificatiestappen zijn vaak legitiem — maar ze zijn zelden gedocumenteerd, vaak dubbel uitgevoerd, en vrijwel altijd trager dan iemand erkent.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>De versieconflict-overdracht:\u003C\u002Fstrong> In professionele dienstverlening in het bijzonder wordt een document, tekening of specificatie per e-mail overgedragen. De ontvanger bewerkt het en stuurt het terug. De afzender bewerkt het origineel. Er bestaan nu twee versies. Iemand moet ze samenvoegen. Elk uur dat aan samenvoegen wordt besteed, is nawerk dat door een beter ontwerp voorkomen had kunnen worden.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>De formaatvertaling:\u003C\u002Fstrong> Een leverancier stuurt een PDF-bevestiging. Iemand typt de hoeveelheden over in het ERP. Het ERP exporteert naar Excel. Iemand plakt het Excel-bestand in een rapport. Vier formaatvertalingen voor één stuk informatie — elk is een vertraging, elk is een potentiële fout.\u003C\u002Fp>\n\u003Ch2>Hoe onderscheidt u een echte overdracht van normale samenwerking?\u003C\u002Fh2>\n\u003Cp>Niet elke overdracht is verspilling. Een overdracht wordt een probleem wanneer deze aan één of meer van de volgende criteria voldoet:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Informatie moet opnieuw worden ingevoerd in plaats van overgedragen\u003C\u002Fli>\n\u003Cli>De ontvangende partij moet verduidelijkende vragen stellen voordat ze kan beginnen\u003C\u002Fli>\n\u003Cli>Er is geen gedefinieerde trigger — de ontvanger weet pas dat hij kan beginnen wanneer hij toevallig gaat kijken\u003C\u002Fli>\n\u003Cli>De overdracht kan alleen correct worden uitgevoerd dankzij de kennis van één specifieke persoon\u003C\u002Fli>\n\u003Cli>De vertraging die de overdracht introduceert, is langer dan de stap zelf\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Als een overdracht aan geen van deze criteria voldoet — de informatie komt volledig aan, de trigger is automatisch, elk teamlid kan de overdracht ontvangen — is die waarschijnlijk prima zoals ze is.\u003C\u002Fp>\n\u003Ch2>Checklist: bent u klaar om overdrachten, vertragingen en nawerk in kaart te brengen?\u003C\u002Fh2>\n\u003Cp>Zorg ervoor dat u het volgende op orde heeft voordat u een procestrace uitvoert:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Een specifieke, echte transactie geselecteerd (geen hypothetische stroom)\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Toegang tot de mensen die elke stap daadwerkelijk uitvoeren (niet alleen managers)\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Toestemming om systeemlogboeken, e-mailtijdstempels en wijzigingshistorieken in te zien\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Een neutrale gespreksleider die niet de proceseigenaar is\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Een eenvoudig vastleggingsformaat — een spreadsheet of gedeeld document is voldoende\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Per persoon gereserveerde tijd: 30–60 minuten ononderbroken doorloop\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Overeenstemming dat u het werkelijke proces in kaart brengt, niet het beoogde\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Veelgestelde vragen\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Heb ik process mining-software nodig om dit te doen?\u003C\u002Fstrong>\nNee. Process mining-tools (zoals Celonis of Minit) zijn krachtig voor grote datasets, maar voor de meeste mkb-bedrijven komen de waardevolste inzichten voort uit een gestructureerd gesprek en een tijdsverschillentabel die u in een spreadsheet opbouwt. Begin met de handmatige trace — investeer pas in tooling wanneer u weet welke vragen u op schaal wilt beantwoorden.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Wat als mensen terughoudend zijn om het werkelijke proces te laten zien, omdat het hen slecht doet uitkomen?\u003C\u002Fstrong>\nFormuleer de sessie expliciet als een systeembeoordeling, niet als een prestatiebeoordeling. U zoekt naar procesfouten, niet naar menselijke fouten. De persoon die elke ochtend nawerk verricht, is niet het probleem — het proces dat dat nawerk vereist, is het probleem. Maak dit duidelijk vóór de sessie en benadruk het tijdens de sessie.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Hoeveel transacties moet ik tracen?\u003C\u002Fstrong>\nBegin met drie tot vijf transacties van hetzelfde type. Eén trace laat u zien wat \u003Cem>kan\u003C\u002Fem> gebeuren. Vijf traces laten u zien wat \u003Cem>gewoonlijk\u003C\u002Fem> gebeurt — en waar de variatie zit. Variatie is vaak belangrijker dan het gemiddelde: een overdracht die soms 2 uur duurt en soms 3 dagen is een urgenter probleem dan een overdracht die altijd 4 uur duurt.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Moet ik het huidige proces in kaart brengen vóór of ná het interviewen van medewerkers?\u003C\u002Fstrong>\nErna — altijd erna. Beginnen met de officiële procesbeschrijving beïnvloedt het gesprek in de richting van hoe het proces zou moeten werken. Beginnen met de echte transactie en mensen vragen hun werkelijke handelingen te laten zien, brengt de hiaten aan het licht. Zodra u het werkelijke beeld heeft, kunt u dat vergelijken met de officiële beschrijving — de verschillen zijn waar uw problemen zitten.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Op welk moment moet ik een ontwikkelaar of automatiseringsspecialist inschakelen?\u003C\u002Fstrong>\nPas nadat u een helder beeld heeft van alle overdrachten, vertragingen en nawerk in het huidige proces. Het automatiseren van een ongedocumenteerd of gebrekkig proces verankert de verspilling in de software. De kaart komt eerst — dan de oplossing.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Hoe bepaal ik welke problemen ik als eerste aanpak?\u003C\u002Fstrong>\nBeoordeel elk geïdentificeerd probleem op twee dimensies: frequentie (hoe vaak komt dit per week of maand voor?) en impact (hoeveel tijd, kosten of foutenrisico introduceert het per keer?). Los eerst problemen aan met een hoge frequentie én een hoge impact. Dagelijkse herinvoer van ordergegevens heeft prioriteit boven een maandelijkse omweg, ook al voelt die maandelijkse omweg dramatischer.\u003C\u002Fp>\n\u003Chr>\n\u003Cp>Zodra u een helder beeld heeft van waar werk stagneert, wie informatie in zijn hoofd meedraagt, en waar nawerk wekelijks ongemerkt uren opslokt, staat u veel sterker om te beslissen wat u wilt aanpakken en hoe. Sommige problemen worden opgelost met een duidelijkere procesafspraak. Andere vereisen een systeemwijziging — het koppelen van twee platformen die momenteel handmatig gegevens uitwisselen, het bouwen van een workflow die de volgende stap automatisch triggert, of het toevoegen van een validatielaag die fouten onderschept voordat ze stroomafwaarts doorgaan. Als u op het punt bent waarop de kaart helder is maar de oplossing nog niet, is dat precies waar Loggix samenwerkt met bedrijven in productie, groothandel en professionele dienstverlening: in kaart brengen wat er daadwerkelijk gebeurt, ontwerpen wat er in plaats daarvan zou moeten gebeuren, en de maatwerksoftware of integraties bouwen die het betere proces duurzaam verankeren.\u003C\u002Fp>\n","Jeroen","2026-07-24",1784901660000,[19,20,21,22,23,24,25,26,27,28,29,30],"process improvement","business process mapping","handovers","delays","rework","workflow analysis","process automation","manufacturing","wholesale","professional services","ERP","FileMaker",null,false,{"title":34,"slug":35},"Procesverbetering","process-improvement",{"title":37,"slug":38},"Hoe je een bedrijfsproces in kaart brengt vóór automatisering","how-to-map-a-business-process-before-automating-it"]