process improvementbusiness process mappingworkflow automationprocess discoveryERPcustom softwareFileMakerdigital transformationoperations management

Hoe het officiële proces te onderscheiden van het werkelijke proces

Jeroen·

Wanneer automatisering de kloof blootlegt tussen schriftelijke procedures en de dagelijkse praktijk, leest u hier hoe u die kunt vinden, in kaart brengen en overbruggen voordat uw project ontspoort.

Uw team heeft een proceshandleiding. Uw medewerkers hebben een compleet andere manier om het werk gedaan te krijgen. Beide bestaan tegelijkertijd, en meestal praat niemand erover — totdat u een automatiserings- of softwareverbeteringsproject start en het verschil plotseling niet meer te negeren is.

Dit artikel laat zien hoe u het echte proces naar boven haalt, begrijpt waarom het is afgeweken van het officiële, en die kennis gebruikt om automatisering te bouwen die ook daadwerkelijk beklijft.

flowchart split into two paths: official procedure vs actual daily workaround steps

Waarom wijken het officiële proces en het echte proces überhaupt van elkaar af?

Processen worden gedocumenteerd op een bepaald moment in de tijd. Het bedrijf blijft zich ontwikkelen. Er komen nieuwe klanten met speciale eisen, softwaresystemen veranderen, personeel verloopt, en de druk neemt toe om deadlines sneller te halen. Al die krachten duwen het gedrag een beetje weg van de geschreven procedure — en omdat elke verschuiving klein en lokaal is, werkt niemand de handleiding formeel bij.

Het resultaat is een langzame, onzichtbare drift. Na twee of drie jaar beschrijft het gedocumenteerde proces een bedrijf dat niet meer helemaal bestaat.

Dit is geen teken van een gebrek aan discipline. Het is het normale gedrag van elke organisatie die groeit en zich aanpast. Het probleem wordt pas acuut wanneer u het gedocumenteerde proces probeert te vertalen naar software — want dan wordt de drift ingevroren in code, en moet elke medewerker kiezen tussen het volgen van het systeem en het daadwerkelijk gedaan krijgen van het werk.

Hoe ziet het verschil er in de praktijk uit?

Het verschil kondigt zich zelden aan. Het verbergt zich op vier veelvoorkomende plekken:

1. De Excel-workaround buiten het hoofdsysteem Een inkooporder wordt geregistreerd in het ERP, maar het inkoopteam houdt een aparte Excel bij om leveringsbeloften van leveranciers te volgen — omdat het ERP geen veld heeft voor "verwachte deelleverdatum." Het Excel-bestand wordt niet geback-upt, is niet zichtbaar voor het management en is nergens aan gekoppeld. Het bestaat omdat iemand het ooit nodig had en het systeem niet kon helpen.

2. De overgeslagen goedkeuringsstap De procedure vereist dat een afdelingshoofd elke klantenkorting boven de 10% goedkeurt. In de praktijk sturen verkopers een WhatsApp-bericht naar de manager, krijgen een duimpje omhoog, en verwerken de order meteen. De formele goedkeuring wordt achteraf geregistreerd — of helemaal niet. Snelheid wint het van compliance, elke keer weer, totdat een audit vragen gaat stellen.

3. De handmatige datacorrectie Een order wordt ingevoerd in FileMaker en vervolgens met de hand overgetypt in Exact Online — elke order, elke dag — omdat de twee systemen nooit zijn geïntegreerd. De medewerker die dit doet heeft een eigen set regels ontwikkeld voor het afhandelen van uitzonderingen (wat te doen als de btw-code ontbreekt, hoe om te gaan met orders in vreemde valuta) die nergens op schrift staat.

4. Het informele proces dat in iemands hoofd leeft Een ervaren logistiek coördinator weet dat een bepaalde vervoerder geen pallets boven 800 kg accepteert zonder voorafgaande melding, dat een klant een specifiek labelformaat vereist, en dat zendingen op vrijdagmiddag vóór het middaguur geboekt moeten worden of anders tot maandag doorschuiven. Niets hiervan is gedocumenteerd. Het werkt perfect — totdat die persoon ziek is, met vakantie gaat, of het bedrijf verlaat.

Hoe vindt u het echte proces?

U vindt het niet door de handleiding te lezen of managers te interviewen. U vindt het door te gaan naar waar het werk daadwerkelijk plaatsvindt. Hier is een praktische aanpak:

Stap 1: Volg het werk, niet het organogram

Vraag om een volledige werkdag naast de persoon te mogen zitten die het proces van begin tot eind uitvoert. Leg niet uit wat u zoekt. Kijk welke tools ze openen, wat ze kopiëren en plakken, wat ze controleren voordat ze naar de volgende stap gaan, en — cruciaal — wat ze doen als iets niet in de standaardstroom past.

Stap 2: Vraag "wat gebeurt er als het misgaat?"

De workarounds zitten in de uitzonderingspaden. Standaardgevallen zien er vaak netjes uit; het zijn de uitzonderingen die het echte proces onthullen. Vraag: "Wat doet u als een klantorder binnenkomt na de cut-off?" of "Wat gebeurt er als het voorraadniveau in het systeem niet overeenkomt met het magazijn?" Elk antwoord is een procesvertakking die uw officiële documentatie waarschijnlijk niet vermeldt.

Stap 3: Verzamel de schaduwtools

Vraag elk teamlid: "Gebruikt u iets buiten het hoofdsysteem om uw werk gedaan te krijgen?" U zult Excel-bestanden vinden, gedeelde inboxen die als takenlijst worden gebruikt, post-its met rekeningnummers, WhatsApp-groepen als goedkeuringskanaal, en persoonlijke agendaherinneringen die dienen als workflowtriggers. Maak er een lijst van. Elk ervan is bewijs van een kloof tussen de mogelijkheden van het systeem en de werkelijke behoefte van het team.

Stap 4: Breng in kaart wat u ziet, niet wat u heeft gehoord

Maak een proceskaart die het waargenomen gedrag weerspiegelt, niet de procedurehandleiding. Gebruik eenvoudige swimlane-diagrammen — één baan per rol, één blok per actie. Markeer elke stap waarbij een tool buiten het officiële systeem wordt gebruikt. Markeer elk beslispunt dat afhankelijk is van persoonlijke kennis. Markeer elke stap die een gedocumenteerde controle overslaat. U heeft nu een kaart van de werkelijkheid.

Stap 5: Vergelijk met het officiële proces en benoem de verschillen

Leg de echte kaart naast de officiële procedure. Beantwoord voor elk verschil drie vragen:

  • Waarom is dit verschil ontstaan? (Ontbrekende systeemfunctionaliteit? Tijdsdruk? Onduidelijk eigenaarschap?)
  • Lost de workaround een echte bedrijfsbehoefte op, of is het gewoon een slechte gewoonte?
  • Wat gebeurt er als we het officiële proces automatiseren en dit verschil negeren?

Die laatste vraag is de belangrijkste. Het automatiseren van het verkeerde proces is erger dan helemaal niet automatiseren — het bevriest inefficiëntie in code.

side-by-side swim-lane diagram comparing documented procedure with observed real-world steps

Wat doet u met de gevonden verschillen?

Niet elk verschil hoeft te worden weggewerkt. Sommige workarounds zijn oprecht beter dan het officiële proces en zouden de nieuwe standaard moeten worden. Andere zijn riskant en moeten worden vervangen. Een aantal zijn simpelweg gewoonten zonder goede reden.

Sorteer elk verschil in één van drie categorieën:

Type verschil Wat het betekent Wat u doet
Noodzakelijke workaround Het echte proces vult een gat dat het systeem niet kan opvangen Verwerk het echte proces in het nieuwe systeem
Risicovolle workaround Het echte proces omzeilt een controle die er om een reden is Herontwerp de controle zodat deze mensen niet vertraagt
Verouderde gewoonte De workaround had jaren geleden zin maar dient geen doel meer Schrap hem — maar leg het team uit waarom

Welke fouten maken bedrijven in deze fase?

De documentatie vertrouwen zonder verificatie. Veel automatiseringsprojecten starten met een procesdocument dat door een manager wordt aangeleverd. Dat document beschrijft de bedoeling, niet het gedrag. Verifieer altijd.

Alleen managers interviewen. Managers beschrijven het proces zoals het zou moeten werken. De mensen die het werk uitvoeren beschrijven het zoals het werkt. Beide perspectieven zijn belangrijk, maar de operationele realiteit leeft op de werkvloer, niet in de vergaderzaal.

Workarounds behandelen als mislukkingen. Een workaround is een signaal dat het officiële systeem of proces een gat heeft. De workaround bekritiseren zonder het gat aan te pakken is hoe u het vertrouwen verliest van de mensen wier medewerking u nodig heeft.

Het proces één keer in kaart brengen en verder gaan. Processen blijven zich ontwikkelen nadat u ze heeft vastgelegd. Bouw een reviewcyclus in — zeker na de livegang, want dan beginnen er vrijwel meteen nieuwe workarounds te ontstaan rondom het nieuwe systeem.

Checklist: signalen dat uw officiële en echte processen van elkaar zijn afgeweken

  • Medewerkers houden persoonlijke Excel-bestanden of gedeelde mappen bij naast het hoofdsysteem
  • Goedkeuringsstappen worden routinematig achteraf afgerond in plaats van vooraf
  • Gegevens in het systeem moeten regelmatig handmatig worden gecorrigeerd door een specifieke persoon
  • Het inwerken van een nieuwe medewerker duurt maanden omdat zoveel kennis ongeschreven is
  • Medewerkers zeggen dat het systeem "niet aansluit bij hoe we eigenlijk werken"
  • Er zijn WhatsApp-groepen, gedeelde inboxen of agendaherinneringen die dienen als workflowtools
  • Verschillende teamleden gaan met dezelfde situatie op een andere manier om
  • Audittrails in het systeem weerspiegelen niet wanneer beslissingen daadwerkelijk zijn genomen

Als u drie of meer van deze punten heeft aangevinkt, is het verschil tussen uw officiële en echte proces groot genoeg om een automatiseringsproject dat er geen rekening mee houdt te laten mislukken.

FAQ

Hoe lang duurt dit soort procesontdekking? Voor één afdeling met een duidelijk end-to-end proces duurt een grondige ontdekking twee tot vijf werkdagen — inclusief observatiesessies, interviews, verzamelen van schaduwtools en het opstellen van de kaart. Complexe, afdelingsoverschrijdende processen kosten meer tijd. Er tijdwinst op boeken levert betrouwbaar meer tijdverlies op later.

Moeten we het proces herstellen vóór of na het bouwen van het nieuwe systeem? Beide gebeuren tegelijk. U kunt een systeem niet volledig ontwerpen zonder het echte proces te begrijpen, en u kunt het echte proces niet definitief vaststellen zonder te weten wat het systeem zal kunnen verwerken. Verwacht dat de kaart meerdere keren wordt herzien tijdens de ontwerpfase — dat is normaal en gezond.

Wat als medewerkers terughoudend zijn om hun workarounds te onthullen? Ze zijn meestal terughoudend omdat ze bang zijn de schuld te krijgen, of omdat ze vrezen dat de workaround wordt weggenomen zonder dat er een vervanging komt. Maak het vanaf het begin expliciet: u bent er niet om workarounds te elimineren, maar om te begrijpen wat het bedrijf werkelijk nodig heeft zodat het nieuwe systeem dat kan ondersteunen. Die formulering opent het gesprek doorgaans.

Is dit alleen relevant voor grote bedrijven? Nee. Bedrijven met tien medewerkers hebben informele processen die niemand ooit heeft opgeschreven. In kleine teams is het verschil tussen officieel en echt vaak nog groter, omdat er van meet af aan minder is geformaliseerd.

Welke tools moeten we gebruiken om het echte proces in kaart te brengen? In deze fase werkt low-tech goed: een whiteboard, post-its en een camera om het resultaat te fotograferen. Digitale tools zoals Miro, Lucidchart of zelfs een gestructureerd Word-document werken voor de documentatie. Het tool doet er veel minder toe dan de discipline om vast te leggen wat u observeert in plaats van wat u heeft gehoord.


Het onderscheid maken tussen het officiële proces en het echte is geen vrijblijvende voorbereiding — het is het fundament dat bepaalt of een automatiseringsproject waarde oplevert of alleen disfunctie digitaliseert. Bij Loggix is dit soort procesontdekking altijd de eerste stap voordat er aan maatwerksoftware, API-integratie of workflowautomatisering wordt begonnen. Als uw team zich voorbereidt op een softwareverbeteringsproject en u een gestructureerde manier wilt om in kaart te brengen wat er daadwerkelijk op de werkvloer gebeurt — voordat er één regel code wordt geschreven — dan is dat precies het soort gesprek waarvoor we klaarstaan.