Resources/Documentgoedkeuring in Microsoft 365

    Documentgoedkeuring in Microsoft 365: van rondmailen naar een vastgelegde route

    In vrijwel elke organisatie begint documentgoedkeuring hetzelfde: een concept per mail naar een leidinggevende, akkoord in een reply, en achteraf niemand die kan aanwijzen welke versie nu precies is goedgekeurd. Dit artikel behandelt wat een goedkeuring moet vastleggen, welke bouwstenen Microsoft 365 daarvoor biedt, hoe je de route ontwerpt en welke vijf valkuilen het proces in de praktijk laten vastlopen.

    Het startpunt: akkoord in een mailbox

    De mailroute is niet ontstaan uit slordigheid maar uit gemak: hij werkt onmiddellijk, vraagt geen inrichting en iedereen begrijpt hem. Het probleem openbaart zich pas maanden later, wanneer iemand moet vaststellen of het stuk dat naar buiten ging daadwerkelijk het goedgekeurde stuk was.

    Dan blijkt: de bijlage in de mail is inmiddels drie keer gewijzigd, de reply verwijst naar "de laatste versie", de goedkeurder is uit dienst en zijn mailbox is opgeschoond. Er is dus geen goedkeuring meer, alleen de herinnering dat iemand ooit ja heeft gezegd. Voor interne notities is dat acceptabel; voor documenten met een externe werking of een bewaarplicht niet.

    Wat een goedkeuring moet vastleggen

    Vijf elementen. Ontbreekt er één, dan heb je geen goedkeuring maar een mening.

    • Welk document. Aanwijsbaar via een kenmerk dat niet verandert als iemand het bestand hernoemt of verplaatst.
    • Welke versie. Een versienummer, niet "de laatste". Zonder versie is de goedkeuring niet te koppelen aan een concrete inhoud.
    • Wie. Een persoon met een rol, niet een afdeling.
    • Wanneer. Een tijdstip dat automatisch is vastgelegd en niet achteraf is ingevuld.
    • Op welke grond. Beoordeeld op inhoud, op vorm, op prijs, op juridische houdbaarheid? Een goedkeuring zonder grondslag is achteraf niet te wegen.

    Deze vijf punten zijn het toetsingskader voor elk ontwerp dat je maakt. Kan een route ze niet alle vijf leveren, dan is de route niet af — hoe geavanceerd de workflow er verder ook uitziet.

    De bouwstenen in Microsoft 365

    Inhoudsgoedkeuring op de documentbibliotheek. In de bibliotheekinstellingen zet je goedkeuring van items aan. Een nieuw of gewijzigd document krijgt de status In behandeling en is voor anderen niet zichtbaar tot de goedkeurder het vrijgeeft. Sterk punt: het zit direct op de opslaglocatie, is eenvoudig uit te leggen en levert een betrouwbare status. Beperking: het kent één stap en geen route.

    Hoofd- en subversies. Met versiebeheer op hoofd- en subversies wordt elke tussentijdse opslag een subversie (0.1, 0.2) en publicatie een hoofdversie (1.0). Sterk punt: het maakt "concept" en "definitief" een eigenschap van het document in plaats van een afspraak. Beperking: het werkt alleen als de bibliotheek er ook echt op is ingericht en gebruikers begrijpen wat publiceren betekent. De inrichting daarvan staat in versiebeheer in Microsoft 365.

    Uitchecken. Een document uitchecken voorkomt dat twee mensen tegelijk aan een definitieve versie werken. Sterk punt: het is ondubbelzinnig. Beperking: uitgecheckte documenten die iemand vergeet in te checken, blokkeren het proces — dat vraagt om periodiek toezicht.

    Workflows via Power Automate. Hiermee bouw je meerdere stappen, voorwaarden, herinneringen en escalaties. Sterk punt: het kan de route bevatten die je organisatie daadwerkelijk kent. Beperking: het is software die onderhouden moet worden, met een eigenaar, en die stil kan vallen. Een workflow zonder eigenaar is een tijdbom. Een uitgewerkt voorbeeld staat in document approval workflows in Microsoft 365.

    Metadata. Status, eigenaar, documentsoort en goedkeuringsdatum als kolommen op de bibliotheek maken de goedkeuring vindbaar en rapporteerbaar. Zonder metadata heb je wel goedkeuringen maar geen overzicht. Zie SharePoint metadata.

    Het ontwerp van de route

    Begin niet bij de techniek maar bij vijf ontwerpvragen.

    Hoeveel stappen? De belangrijkste ontwerpregel luidt: elke extra goedkeurder verlaagt de aandacht per goedkeurder. Bij vier goedkeurders gaat iedereen ervan uit dat de anderen er wel goed naar kijken en kijkt niemand echt. Twee inhoudelijke stappen is voor de meeste stromen het maximum dat nog waarde toevoegt.

    Sequentieel of parallel? Sequentieel als de tweede goedkeurder het oordeel van de eerste nodig heeft. Parallel als de beoordelingen los van elkaar staan — dan wint de doorlooptijd aanzienlijk. Combineren kan: eerst parallel meelezen, dan één sequentiële eindgoedkeuring.

    Wie vervangt bij afwezigheid? Deze vraag wordt bijna altijd overgeslagen en is de meest voorkomende reden dat een route in de praktijk wordt omzeild. Wijs per rol een plaatsvervanger aan en leg vast na hoeveel tijd de vervanger in beeld komt.

    Wat gebeurt er bij afkeuring? Gaat het document terug naar de auteur met een verplichte toelichting, of naar een tussenstap? En begint de route daarna opnieuw of vanaf het punt van afkeuring? Beantwoord dit vooraf; anders wordt afkeuring in de praktijk vermeden en verliest de route zijn functie.

    Waar in het proces zit de goedkeuring? Te vroeg en er wordt een concept goedgekeurd dat daarna nog verandert. Te laat en de goedkeuring is een formaliteit omdat het stuk al bij de klant ligt.

    Sjabloongoedkeuring versus documentgoedkeuring

    Hier ligt de grootste winst, en hij wordt zelden benut. Het merendeel van de tekst in een zakelijk document vraagt geen individuele beoordeling: het is standaardtekst die al eerder is goedgekeurd en die per document alleen wordt herhaald. Toch beoordeelt de goedkeurder in de praktijk het hele stuk, en dus niets goed.

    Keur die standaardtekst één keer goed op sjabloonniveau — de algemene voorwaarden, de aansprakelijkheidsbepaling, het ondertekenblok, de vaste toelichtingen — en zorg dat die tekst in elk document identiek uit de goedgekeurde bron komt. Wat er dan per document overblijft om te beoordelen, is de casusspecifieke inhoud: het bedrag, de scope, de bijzondere bepaling. Die beoordeling is aanzienlijk korter en inhoudelijk sterker, omdat de aandacht naar de delen gaat die per document daadwerkelijk verschillen.

    Voorwaarde is wel dat de goedgekeurde tekst ook echt vaststaat en niet per document wordt herschreven. Dat is een sjabloonvraagstuk, geen workflowvraagstuk.

    Versiebeheer als fundament

    Goedkeuring zonder een helder onderscheid tussen concept en definitief is betekenisloos. Als elke opslag een gelijkwaardige versie oplevert, verwijst "goedgekeurd op 9 september" naar niets: er zijn die dag zes versies opgeslagen. Met hoofd- en subversies is de goedkeuring te koppelen aan versie 2.0 en is elke latere wijziging herkenbaar als 2.1 — dus als iets dat opnieuw beoordeeld moet worden.

    Zet daarom versiebeheer op de betrokken bibliotheken goed vóórdat je aan workflows begint. Een geavanceerde route bovenop onduidelijk versiebeheer levert een nette registratie op van iets wat je niet kunt terugvinden.

    Vastlegging en audit trail

    Bewaar de goedkeuring bij het document, niet in een parallel systeem. Het praktische anker daarvoor is het documentkenmerk: een uniek nummer dat bij het aanmaken wordt uitgegeven, als eigenschap wordt vastgelegd en niet verandert als het bestand wordt hernoemd, gekopieerd of verplaatst. Koppel de goedkeuringsregistratie aan dat kenmerk en de vindbaarheid blijft intact, ook na een migratie of een reorganisatie van de mappenstructuur. Hoe je zo'n kenmerk opzet staat in documentnummering.

    Leg per goedkeuring vast: kenmerk, versie, goedkeurder, tijdstip, grondslag en eventuele opmerkingen. Zorg dat die registratie leesbaar is zonder speciale tooling — een auditor wil kunnen kijken zonder dat iemand een export voor hem draait. En houd er rekening mee dat een goedkeuring die uitsluitend in een mailbox bestaat, bij een controle niet meetelt: mailboxen zijn persoonlijk, worden opgeschoond en vallen buiten het documentdossier. Hoe dit samenhangt met de bredere inrichting staat in documentbeheer in Microsoft 365.

    Vijf valkuilen

    • Te veel stappen. Iedere extra schakel verdunt de verantwoordelijkheid en verlengt de doorlooptijd. Snoei tot wat aantoonbaar waarde toevoegt.
    • Goedkeuring op de verkeerde plek. Te vroeg is zinloos, te laat is een formaliteit. Zet hem op het moment waarop wijzigen nog kan én de inhoud al vaststaat.
    • Geen vervanger. Eén vakantie legt de stroom stil, waarna mensen om het proces heen gaan werken en niet meer terugkomen.
    • Workflows die stilvallen zonder dat iemand het merkt. Een gewijzigde connector, een vertrokken eigenaar, een aangepaste bibliotheek — en de route draait niet meer. Zet een periodieke controle op de doorloop en wijs een eigenaar aan.
    • Documenten goedkeuren die standaardtekst hadden moeten zijn. Als je dezelfde alinea voor de vijftigste keer beoordeelt, is dat geen goedkeuringsprobleem maar een sjabloonprobleem.

    Invoeringsvolgorde

    Begin bij één documentstroom met een duidelijke eigenaar en een overzichtelijk volume — bijvoorbeeld offertes of engagement letters. Richt daar versiebeheer, inhoudsgoedkeuring en de metadata goed in, laat het een kwartaal draaien en meet waar hij hapert. Pas daarna verbreed je naar de volgende stroom.

    Wat je moet vermijden is een organisatiebrede uitrol van een generieke workflow. Die past nergens precies, iedereen ervaart hem als opgelegd, en de eerste uitzondering wordt het precedent voor alle volgende. Eén stroom die aantoonbaar werkt, overtuigt beter dan een projectplan.

    Frequently Asked Questions

    Goedgekeurde sjablonen als bron, een vast kenmerk als anker

    dStyle365 houdt sjablonen en goedgekeurde tekstblokken centraal in Microsoft 365, zodat goedkeuring zich richt op wat per document echt verschilt. DocID kent bij het aanmaken via één uitgiftepunt een documentkenmerk toe dat als eigenschap in SharePoint wordt vastgelegd — het anker onder je vastlegging.

    We value your privacy

    We use cookies to enhance your browsing experience, analyze site traffic, and personalize content. By clicking "Accept All", you consent to our use of cookies. Privacy Policy