Wat een AI Workflow Design per afdeling bevat: de anatomie van een playbook

Wanneer een mkb-bedrijf de weg van het playbook overweegt — een reeds gebouwde AI-adoptiemethode om in de processen te enten, in plaats van een telkens opnieuw opgebouwde consultancy — komt steevast de concrete vraag: maar wat zit er eigenlijk in? Het is de juiste vraag. Het verschil tussen een playbook dat het bedrijf verzet en een map met slides zit helemaal in de structuur, en die structuur is verrassend herkenbaar: de serieuze AI-adoptieplaybooks, die welke gepubliceerd zijn door de organisaties die AI op grote schaal gebruiken, delen dezelfde geraamtes. Wie ze kent, onderscheidt in tien minuten een artefact bedacht om te duren van een bedacht voor de handtekening.

Het loont de moeite de anatomie ervan uit elkaar te halen, want het is ook de eerlijkste manier om te vertellen wat we leveren wanneer we «een AI Workflow Design per afdeling» zeggen. Het is geen marketingterm: het is een format met onderdelen, en elk onderdeel beantwoordt een precieze vraag die een mkb-bedrijf zou moeten eisen opgelost te zien.

Twee assen, vóór elke inhoud

Elk AI-adoptieplaybook organiseert zich, onder de oppervlakteverschillen, langs twee orthogonale assen. Ze herkennen is het eerste instrument om te beoordelen wat men u voorlegt.

• De navigatie-as — hoe u vindt «wat mij aangaat». De twee gangbare keuzes zijn per afdeling/rol (verkoop, marketing, operations, administratie, HR…) of per fase (pilot → schaal → doorlopend beheer). Het zijn geen alternatieven: de beste formats gebruiken de afdeling als ingang en de fase als intern label.
• De diepte-as — of en hoe het playbook u plaatst vóór het u de inhoud toont. Aan het ene uiterste een maturiteitsmodel (meestal vijf niveaus, met een score per capaciteit) dat u zegt waar u staat; aan het andere een vlakke catalogus die u vrij laat doorbladeren. De keuze is geen smaakkwestie: ze verandert wie het playbook weet te bedienen.

Met deze twee assen in gedachten tonen de twee meest leerzame publieke voorbeelden tegengestelde combinaties — en samen dekken ze bijna alles wat een mkb-bedrijf erin zou mogen verwachten te vinden.

Model A — het playbook «per pijlers en fasen» (het voorbeeld van GitHub)

GitHub heeft zijn interne playbook om een door AI versterkte beroepsbevolking op te bouwen openbaar gemaakt. Het is het archetype van het format doorbladerbaar per fase, en het is nuttig omdat het bedacht is om te doen adopteren, niet om te imponeren. Drie onderdelen verdienen aandacht, want het zijn precies die welke een mkb-bedrijf, op verkleinde schaal, in het eigen playbook zou moeten terugvinden.

• Acht fundamentele pijlers. Geen use-cases, maar de voorwaarden opdat de use-cases aanslaan: sponsorship van de directie, één duidelijk verantwoordelijke persoon (een aanspreekpunt, geen comité), geschreven policy en guardrails, opleiding, metrieken, de interne «promotoren» die het gebruik van onderop verspreiden, de juiste tools, de communities of practice. Het is het onderdeel dat een zwak playbook overslaat — en de reden waarom zijn use-cases daarna niet aanslaan.
• Een uitrol in drie fasen, met een horizon bij elke fase. Eerste 30 dagen = fundamenten (sponsor, aangewezen aanspreekpunt, gebruikspolicy in concept, geïnstrumenteerde metrieken). Eerste 90 dagen = vaart (promotorenprogramma, communities of practice, resource-hub, eerste succescases). Daarna, doorlopend = schaal (de opleiders opleiden, rendementsdashboards). Een playbook met een wanneer naast elk «wat» is bedacht om uitgevoerd te worden; een zonder tijdlijnen is bedacht om gelezen te worden.
• Twee herbruikbare mechanieken. Een systeem van getierde tools — gescreend (goedgekeurd) tegenover toegelaten maar nog niet gescreend — zodat de mensen weten wat ze mogen gebruiken zonder het telkens te vragen; en een metriektrechter in drie stadia: eerst de breedte van de adoptie (hoeveel er gebruiken), dan de diepte van het gebruik (hoeveel en hoe), tot slot de correlatie met een businessresultaat. Het laatste stadium meten zonder de eerste twee is de meest voorkomende manier om zichzelf een ROI aan te praten die er niet is.

Model B — het playbook «per maturiteitsniveaus» (het voorbeeld van Microsoft)

Microsoft publiceert een maturiteitsmodel voor de adoptie van agentische AI: zwaarder dan de vrije navigatie, en juist daarom een goede bron voor de onderdelen governance en rolduidelijkheid die een self-service-playbook geneigd is dun te laten. Twee elementen dienen als template.

• Vijf pijlers, elk vijf niveaus. Strategie en cultuur, herontwerp van de processen en realisatie van de waarde, governance en beveiliging, technologie en data, organisatie en mensen — elk gelezen op een maturiteitsschaal. Het niet voor de hand liggende punt: een bedrijf staat tegelijk op verschillende niveaus in verschillende pijlers. Het is al de vorm van AI-readiness — één enkel gemiddelde «we zitten op een 6» verbergt meer dan het onthult.
• De rolverdeling van een Center of Excellence. Het model expliciteert wie wat bezit in vijf functies: verzameling en prioritering van de ideeën; operating model en beslissingsrechten (wat centraal en wat door de afdelingen wordt beheerd); enablement en community; standaarden en hergebruik (schema's, templates, guardrails); signalen van adoptie en waarde. Het is de kant-en-klare template voor het vakje «governancecontroles» dat een goed playbook aan elke workflow vasthaakt.

Het model van Microsoft is afgestemd op de grote onderneming: een heel Center of Excellence is buiten schaal voor een mkb-bedrijf. Maar de vijf functies van verantwoordelijkheid niet — ze blijven allemaal nodig. Het serieuze werk is, voor een kleine onderneming, ze niet te reduceren: het is ze samen te persen in één of twee mensen die ze echt dekken. Het aantal koppen verandert; de lijst van de dingen waarvoor iemand verantwoordelijk moet zijn, niet.

Het skelet dat we een mkb-bedrijf aanraden

Als we de twee modellen samenbrengen en afwegen tegen de realiteit van een kleine onderneming — waar een zwaar Center-of-Excellence-proces de belofte van een slanke adoptie zou tegenspreken — heeft het skelet dat we leveren vijf onderdelen. Hier houdt «AI Workflow Design per afdeling» op een slogan te zijn en wordt het een inhoudsopgave.

• Primaire navigatie per afdeling. Het is de ingang: open uw afdeling — verkoop, marketing, operations, administratie en finance — en u vindt de use-cases die u aangaan, geen generieke catalogus om met de hand te filteren.
• Een fase-label op elke vermelding. Pilot, schaal, doorlopend beheer: zo filtert wie al halverwege het traject is op «wat komt daarna» in plaats van de pilots te herlezen die hij al binnen heeft. Het is de fasemechaniek van Model A, toegepast op de afzonderlijke vermelding.
• Geen maturiteitspoort op de toegang tot de inhoud. Het playbook blijft doorbladerbaar — u wordt het lezen niet ontzegd tot u een niveau «verdient». Maar uw AI-readiness-score verschijnt als niet-blokkerend advies: «open eerst deze afdeling». De maturiteit als aanbevelingssignaal, niet als paywall.
• Een «AI-owner» van één of twee personen, met vijf te dekken functies. De vijf functies van het Center of Excellence — ideeënverzameling, beslissingsrechten, enablement, standaarden en hergebruik, waardesignalen — worden een checklist voor die ene of twee personen. Men houdt de rigueur, men laat de personele aanname vallen die een mkb-bedrijf niet heeft.
• Een governanceblok vastgehaakt aan elke workflow. Risiconiveau, effectbeoordeling, controles, mens in de lus, toezicht: geen formaliteit achteraf maar deel van het ontwerp. Het is de compliance-overlay die we apart beschrijven — en de reden waarom, wanneer we een workflow ontwerpen, de compliance niet achteraf komt.

Er is een laatste onderdeel dat een bruikbaar playbook onderscheidt van een mooi document: het opleveringsformat. De bron van waarheid blijft een gestructureerde tekst — leesbaar, versioneerbaar, bij te werken wanneer de tool verandert — maar om echt gebruikt te worden heeft elke afdelingsvermelding een lichte visuele asset naast de proza nodig. Een playbook dat alleen als PDF leeft, belandt in een map; een bedacht om geadopteerd te worden geeft u ook hoe het aan het team te tonen in handen.

Waar het kennen van de anatomie voor dient

De praktische reden om deze structuur uit elkaar te halen is niet academisch. Of u nu kiest om een playbook in huis te bouwen, er een kant-en-klaar te kopen of u te laten bijstaan, u hebt nu de inhoudsopgave om het voorstel dat u bereikt te beoordelen: heeft het een ingang per afdeling? zet het een fase naast elke use-case? zegt het wie waarvoor verantwoordelijk is? haakt het de governance aan de workflow of stelt het die uit? is het bij te werken, of bevroren in een slide? Het zijn vijf vragen, en een serieus artefact houdt ze alle vijf aan.

Het is ook, om transparant te zijn, de vorm van wat wij enten: een playbook al gebouwd langs dit skelet, aangepast aan uw afdeling en in productie gebracht. De eerste stap komt echter vóór het playbook en is gratis — weten waar te beginnen. Onze AI-readiness-beoordeling geeft u in twee minuten een idee van welke afdeling klaar is en met welke controles eromheen; en wilt u begrijpen hoe u van deze inhoudsopgave naar een draaiende workflow gaat, hier hebben we de drie wegen vergeleken — cursus, consultant, playbook — of we praten erover, vrijblijvend.

Dit artikel is bedoeld ter oriëntatie. De genoemde formats komen uit publieke playbooks en maturiteitsmodellen van GitHub en Microsoft en uit sectoranalyses: het zijn referentietemplates, geen voorschriften die voor elk bedrijf gelden. Structuur, fasen en rollen moeten altijd worden aangepast aan de omvang, de data en de context van het individuele bedrijf.