Standaardwerkwijze (SOP) en as-is / to-be proces

Wat is een standaardwerkwijze (SOP), en wat bedoelen we met as-is en to-be?

Een standaardwerkwijze, in het Engels standard operating procedure of kortweg SOP, is de uitgeschreven beschrijving van hoe een taak bij jou in het bedrijf gebeurt. Niet hoe het in het algemeen hoort, maar hier: wie neemt ze op, in welk systeem, in welke volgorde, welke controles zitten er tussen en wat doe je als iets niet past. De lat ligt duidelijk. Een nieuwe collega met wat basiskennis moet ze kunnen volgen zonder dat er iemand naast zit. Het Amerikaanse milieuagentschap EPA omschrijft een SOP in zijn richtlijn voor het opstellen van SOP's als "a set of written instructions that document a routine or repetitive activity followed by an organization".

Het as-is proces is de taak zoals ze vandaag echt loopt, met de omwegen, de mailketens en de Excel die officieel van niemand is. Het to-be proces is de herwerkte versie waar je naartoe wil. De meeste SOP's die in omloop zijn, beschrijven geen van beide. Ze beschrijven het proces zoals iemand het zich herinnert, of zoals het drie jaar geleden bedacht is.

Zie de SOP als het recept, de as-is als een video van wat er echt in de keuken gebeurt, en de to-be als het recept dat je schrijft nadat je die video bekeken hebt.

Een SOP weegt vandaag zwaarder dan vijf jaar geleden

Lange tijd schreef je een SOP voor de ISO 9001-audit en daarna keek niemand er nog naar. De clausule over gedocumenteerde informatie in die norm vraagt dat je zelf bepaalt welke procedures je nodig hebt, dat ze herkenbaar, goedgekeurd en beschikbaar zijn op de werkvloer, en dat oude versies uit omloop verdwijnen. Dat blijft zo in de herziening die ISO voor 2026 gepland heeft, met een overgangsperiode van drie jaar voor gecertificeerde bedrijven.

Wat veranderd is, is wie de SOP leest. Een AI-agent, een coding agent of een workflowtool kan enkel automatiseren wat op papier staat. Vraag je een agent om de intake van nieuwe klanten te doen, dan is de SOP de specificatie waar hij van vertrekt: de trigger, de stappen, de beslisregels, de uitzonderingen en het punt waar een mens moet meekijken. Ontbreekt de SOP, dan verzint de agent het proces zelf, of kopieert hij wat de collega die hem getraind heeft die dag toevallig deed. Schrijf eerst een degelijke SOP en de helft van het automatiseringswerk is gedaan. De andere helft kan je dan testen, want er ligt een document om tegen te toetsen.

Voor mensen geldt hetzelfde. Een werkwijze die enkel in het hoofd van één ervaren collega zit, valt stil zodra die collega met verlof is of vertrekt.

Wat staat er in een bruikbare SOP?

Een bruikbare SOP past op één of twee bladzijden voor een taak van enkele minuten en beantwoordt deze vragen, in deze volgorde:

1. Trigger. Wat zet de taak in gang? Een mail in de gedeelde inbox, een ingevuld formulier, een statuswijziging in het ERP, de eerste werkdag van de maand.

2. Stappen. Genummerd, in de volgorde waarin ze gebeuren, één handeling per stap, met het systeem erbij. "Open de klantfiche in Exact Online en controleer of het btw-nummer ingevuld is" is een stap. "Verwerk de klant" is er geen.

3. Beslispunten. Waar het pad splitst, en op basis van welke regel. "Als het ondernemingsnummer niet in de KBO staat, stop en mail de klant" is een regel die een mens en een agent allebei kunnen volgen.

4. Uitzonderingen. De vijf of zes dingen die het vaakst mislopen, en wat je dan doet. Dit is meestal het nuttigste stuk van het document, en het stuk dat het vaakst ontbreekt.

5. Systemen en toegang. Welke tools, welke mappen, welke gedeelde mailbox, en welke rechten je nodig hebt voor je begint.

6. Eigenaar en datum van de laatste review. Eén naam, één datum. De EPA-richtlijn raadt aan om elke SOP om de één à twee jaar systematisch na te kijken, en om een SOP in te trekken als ze een proces beschrijft dat niemand nog volgt.

Een SOP wordt op drie voorspelbare manieren onbruikbaar. Ze is geschreven door iemand die de job nooit gedaan heeft, dus ze beschrijft de happy path en niets anders. Ze is nooit bijgewerkt, dus de schermafbeeldingen tonen een systeem dat je al vervangen hebt. Of ze telt twintig bladzijden voor een taak van vijf minuten, dus niemand opent ze en de echte werkwijze leeft in een Teams-chat. De EPA-richtlijn zegt hetzelfde in minder woorden: laat ze schrijven door de mensen die het werk echt doen, hou het kort en eenvoudig, en gebruik de actieve vorm.

SOP versus procesmodel

Het verschil zit in wie het leest. Een SOP wordt gelezen door de persoon die het werk doet, of door een agent die zijn plaats inneemt, en zegt wat je doet in welk systeem. Een procesmodel, getekend in BPMN of ontdekt uit een event log, wordt gelezen door een analist of uitgevoerd door een workflow engine, en toont de vorm van het proces: activiteiten, volgorde, gateways, lanes. Het procesmodel zegt dat "identiteit controleren" tussen "documenten ontvangen" en "klant aanmaken" zit. De SOP zegt welk document je opent, waarmee je het vergelijkt, en wat je doet als het adres op de identiteitskaart niet overeenkomt met dat op het formulier. Je hebt beide nodig, en ze moeten met elkaar kloppen.

De as-is eerlijk in kaart brengen

Bij de as-is loopt het meeste proceswerk mis, omdat mensen opschrijven wat hoort te gebeuren in plaats van wat gebeurt. Vier gewoontes helpen.

Ga naar de werkvloer. Ga naast de persoon zitten die de taak doet en volg een echt dossier van begin tot einde. Tel hoeveel systemen die opent en hoe vaak die teruggaat naar een mail om iets na te kijken. Vraag om luidop te denken.

Gebruik de data die je systemen al hebben. Process mining reconstrueert het echte pad uit de tijdstempels in je ERP, CRM of ticketingtool en toont je de varianten en de wachttijden. Task mining doet hetzelfde voor het bureauwerk tussen de systemen: het kopiëren van Excel naar het portaal, het zoeken in de inbox. Samen geven ze je de stukken van de as-is die niemand in een workshop zou vermelden. Celonis omschrijft conformance checking in zijn process mining tool als het vergelijken van "your as-is process to your desired to-be process model", en dat verschil is precies wat je wil zien.

Vraag naar de uitzonderingen, niet naar de happy path. Iedereen kan het dossier beschrijven dat goed loopt. Vraag liever: wat gebeurde er de laatste keer dat het niet lukte? Wat doe je als de klant een foto van zijn identiteitskaart stuurt in plaats van een scan? Wie bel je als het portaal plat ligt? De antwoorden zijn de echte SOP.

Doe een nulmeting. Noteer voor je iets verandert hoeveel dossiers per maand, hoeveel stappen, hoeveel systemen, hoelang van trigger tot afgewerkt, en hoeveel dossiers herwerkt moesten worden. Zonder die nulmeting kan je later niet tonen dat de to-be gewerkt heeft, en kan je er geen KPI op zetten.

De to-be ontwerpen

De to-be is niet de as-is met een tool erop geplakt. Werk ze in deze volgorde uit.

Schrap stappen voor je iets automatiseert. Elke stap die bestaat door een beperking van vroeger (een tweede invoer omdat twee systemen niet met elkaar praten, een controle die na één incident jaren geleden toegevoegd is) komt in aanmerking om te verdwijnen. Een overbodige stap automatiseren maakt ze sneller en houdt ze overbodig.

Beslis wat een model doet en wat een mens controleert. Een taalmodel kan een document lezen, een fiche vooraf invullen, een aanvraag classificeren en een mail opstellen. Een mens moet blijven goedkeuren wat een verbintenis schept, geld verplaatst of met de naam van het bedrijf naar een klant vertrekt. Schrijf die verdeling als expliciete stappen in de to-be SOP: "model vult velden A tot F vooraf in, medewerker controleert velden B en D tegen het brondocument".

Leg de KPI vast. Eén of twee cijfers die je tegen de nulmeting legt: dossiers per week, dagen van trigger tot afgewerkt, aandeel dossiers dat herwerkt moest worden. Kies cijfers waarvan de mensen die het werk doen vinden dat ze eerlijk zijn.

Schrijf de to-be SOP voor je bouwt. Ze wordt de acceptatietest voor de automatisering. Kan de agent de SOP niet volgen, dan is ofwel de SOP onduidelijk, ofwel de agent nog niet klaar, en allebei wil je weten voor je live gaat.

Een uitgewerkt voorbeeld: klantonboarding bij een boekhoudkantoor

Een boekhoudkantoor met twaalf mensen neemt een nieuwe klant aan. De as-is, opgetekend door bij de medewerker te gaan zitten voor twee echte dossiers en de mailbox erop na te lezen, telt veertien stappen:

1. De prospect mailt de vennoot dat het in orde is.

2. De vennoot antwoordt met een lijst van documenten die nodig zijn.

3. De klant mailt de documenten in drie of vier aparte mails, gespreid over een week.

4. De medewerker slaat de bijlagen op op de gedeelde schijf.

5. De medewerker typt naam, ondernemingsnummer, adres en contactpersoon over in de Excel-klantenlijst.

6. De medewerker maakt de klant aan in het boekhoudpakket.

7. De medewerker maakt dezelfde klant nog eens aan in het klantenportaal.

8. De medewerker zoekt het ondernemingsnummer op in de KBO om de gegevens na te kijken.

9. De medewerker vult de antiwitwaschecklist met de hand in op basis van de identiteitskaart en het KBO-uittreksel.

10. De medewerker maakt de opdrachtbrief op vanuit een Word-sjabloon en mailt ze.

11. De medewerker herinnert de klant aan de ondertekende brief, soms twee keer.

12. De vennoot kijkt de fiche, de checklist en de brief na.

13. Correcties gaan heen en weer per mail.

14. De medewerker stuurt de welkomstmail met de login voor het portaal.

De Excel-lijst, het boekhoudpakket en het portaal bevatten alle drie dezelfde klantgegevens, drie keer apart ingetypt. De to-be telt acht stappen:

1. De klant vult een intakeformulier in op het portaal en laadt daar zijn identiteitskaart en het KBO-uittreksel op.

2. Een model leest de uploads, vult de klantfiche en de antiwitwaschecklist vooraf in, en markeert alles wat het niet kon lezen of wat niet overeenkomt.

3. De klantfiche wordt automatisch aangemaakt in het boekhoudpakket en het portaal, vanuit dat ene formulier.

4. De opdrachtbrief wordt uit de fiche gegenereerd en ter elektronische ondertekening verstuurd.

5. De ondertekende brief wordt vanzelf bij de klant geklasseerd.

6. De medewerker behandelt enkel de gemarkeerde punten.

7. De vennoot doet één review van de vooraf ingevulde fiche en de checklist.

8. De welkomstmail met de login vertrekt zodra de vennoot goedkeurt.

De gap-analyse tussen beide, één lijn per dimensie:

• Stappen: veertien in de as-is, acht in de to-be, en de stappen die wegvallen zijn overtypen, bijlagen met de hand opslaan en mails achternalopen.

• Gegevensinvoer: drie keer dezelfde gegevens met de hand invoeren wordt één invoer door de klant, waarna het model en de koppelingen ze verder kopiëren.

• Wachten: de as-is wacht op mail in stappen 2, 3, 11 en 13; de to-be wacht enkel tot de klant het formulier invult en tekent.

• Controles: de as-is heeft één review op het einde, nadat alles met de hand ingetypt is; de to-be houdt die review, maar richt ze op de gemarkeerde punten en een vooraf ingevulde fiche.

• Wie doet wat: de medewerker gaat van overtyper naar behandelaar van uitzonderingen; de vennoot houdt de goedkeuring.

• KPI: dagen van "ja" tot welkomstmail, en aandeel onboardings dat een correctieronde nodig had, allebei gemeten tegen de nulmeting uit de as-is.

Let op wat de to-be SOP niet doet: ze laat het model de opdrachtbrief niet zelf versturen en de checklist niet zelf goedkeuren. Dat blijft bij een mens, uitgeschreven als stappen 6 en 7.

Waar moet je op letten bij SOP's en as-is / to-be werk?

Sla de as-is niet over omdat je het antwoord al kent. De stappen die het meeste tijd kosten, zijn meestal die die niemand in de vergadering vermeldt, omdat ze aanvoelen als gewoon werk. Je vindt ze enkel door te kijken of door de logs te minen.

Schrijf de to-be niet enkel voor de happy path. Een agent die negentig procent van de dossiers afhandelt en geen uitzonderingsroute heeft voor de andere tien, zorgt voor meer werk dan de as-is, want nu moet iemand uitzoeken wat hij gedaan heeft.

Geef elke SOP een eigenaar en een reviewdatum, en hou je eraan. Een SOP met een reviewdatum van twee jaar geleden is slechter dan geen SOP, omdat mensen erop vertrouwen. Koppel de review aan iets dat toch al gebeurt, zoals de jaarafsluiting of het moment waarop je een systeem upgradet.

Versiebeheer zoals bij code. Draait een agent op de SOP, dan is een wijziging aan de SOP een wijziging aan productie. Bewaar de vorige versie, noteer wat er veranderd is en waarom, en test de agent tegen de nieuwe versie voor je omschakelt.