Marktmannen wiki Strategie & Organisatie

Executive AI-implementatie (Every Consulting)

Laatst bijgewerkt

TL;DR: Alleen 6% van bedrijven haalt aantoonbare EBIT-impact uit AI; Every Consulting's vijfstappen-playbook — leidinggevende fluency, aangewezen champions, één pijnlijke workflow, bouwen naar 95%, dan pas schalen — bouwt de organisatorische spierkracht die daarvoor nodig is.

Every's consulting-team trainde duizenden mensen bij bedrijven als New York Times, Ripple, Headway en Thumbtack. McKinsey's cijfer: AI-"high performers" (bedrijven met >5% EBIT-impact door AI) zijn bijna 3x zo vaak workflows fundamenteel opnieuw gaan ontwerpen — maar dat is slechts 6% van bijna 2.000 onderzochte organisaties. De bottleneck is verschoven van modelcapaciteit naar organisatorische capaciteit.

Drie golven van AI-adoptie sinds ChatGPT

  1. Licentiegolf (eind 2022 – begin 2024): bedrijven kochten ChatGPT Enterprise/Claude/Copilot-licenties; individuele, ongelijke productiviteitswinst.
  2. Promptgolf (begin 2024 – medio 2025): prompt-trainingen, interne promptbibliotheken, custom GPT's — hielp voorbij individueel prutsen, maar zelden duurzame organisatieverandering (geen eigenaar, geen evaluatie).
  3. Implementatiegolf (medio 2025 – nu): sinds Claude Code (research preview februari 2025) verschuift adoptie van chat-based AI naar agents die langere, multi-stap taken binnen grenzen uitvoeren. Promptbibliotheken worden skills-bibliotheken: herbruikbare workflows met instructies, voorbeelden, referentiemateriaal, scripts, evaluatiecriteria én een naam als eigenaar. Niet-technische mensen bouwen nu zelf geavanceerde automatiseringen (bv. in Claude Cowork).

De vijf stappen

1. Word zelf vloeiend (fluency)

Leidinggevenden hoeven geen dagelijkse bouwers te worden, maar moeten zelf een skill/agent/automatisering bouwen om te begrijpen wat ze van teams vragen: welke data een agent nodig heeft, welke systemen toegankelijk zijn, waar het faalt, hoeveel menselijk toezicht nodig is, wie het onderhoudt. Zonder die ervaring lees je lage adoptie al snel verkeerd als onwil in plaats van een toegangsprobleem (IT/security-beperkingen). Fluency legt ook bloot of je zelf kunt definiëren wat "excellent" werk is — kun je dat niet aan je chief of staff uitleggen, dan lukt het ook niet aan een AI-systeem.

2. Wijs AI-champions aan

Champions dragen een project van idee tot oplevering: experimenteren, itereren, anderen trainen, steun verzamelen. Ze bepalen wat gebouwd, onderhouden, verbeterd of gestopt wordt. Drie eigenschappen: nieuwsgierigheid, mensgerichtheid, en gezag + tijd om het werk te doen. Champions hoeven niet de meest technische mensen te zijn — wél dicht bij de workflow staan (een marketeer die weet waar campagne-analyse vastloopt, een supportlead die ticket-triage kent). Cruciaal en vaak de faalfactor: beschermde tijd (minimaal 2 dagen/maand in Every's ervaring) en een duidelijk mandaat — geen "erbij" naast de dagtaak.

Een champion zou moeten: 1-3 workflows in zijn domein bezitten, de documentatie onderhouden, eval-sets bouwen/beheren, feedback verzamelen, skills bijwerken bij tool/model/proceswijzigingen, rapporteren over tijdwinst/kwaliteit/foutreductie.

3. Kies één pijnlijke workflow

De meestgemaakte fout: beginnen met het grootste, meest zichtbare probleem (bv. het hele board-deck automatiseren, projectmanagement herbouwen). Begin in plaats daarvan met één smalle, pijnlijke "ader" van een workflow — vaak ongeglamoureus (support-tickets categoriseren, leveranciersupdates samenvatten) maar frequent genoeg om een goede testcase te zijn. Scoor kandidaten op: frequentie, pijn, databeschikbaarheid, risico bij fouten, huidig eigenaarschap, evaluatie-duidelijkheid, onderhoudslast.

4. Bouw naar 95%

Van 0 naar een werkende demo (bv. eerste 20 tickets correct) voelt als magie en gaat snel. Van demo naar iets waar het team op kan vertrouwen (60% → 95%) kost veel meer werk: voorbeelden, evaluatie, feedback, menselijk toezicht, onderhoud. Executives stellen de standaard ("wat is goed genoeg, waar hoort menselijke review"); champions bouwen ertegen. "Automatisering is een leugen" — modellen updaten, processen verschuiven, edge cases verschijnen; een skill die vorige maand werkte kan deze maand aanpassing nodig hebben. Per workflow een simpele eval-tabel bijhouden: testvoorbeeld, huidige output, verwachte output, fouten + oorzaak, prompt/skill-aanpassing nodig?, resultaat hertest, menselijke review nodig?, eigenaar, reviewcadans.

5. Schaal wat werkt

Alleen schalen wat bewezen werkt — niet een company-wide mandaat vanaf dag één. Eén zichtbare winst (juiste champion + workflow + standaarden) creëert pull: andere teams gaan vragen wat voor hén kan werken. Schalen betekent niet hetzelfde overal kopiëren — de meeste workflows zijn afdelingsspecifiek. Vraag vóór het schalen: is een echt pijnpunt opgelost, getest tegen echte voorbeelden, is er een naam als eigenaar, een reviewproces, zijn risico's begrepen, kan het team uitleggen wanneer/hoe te gebruiken, is er een feedbackloop, en: shared skill, teamspecifiek, of stoppen?

60-dagenplan

  • Week 1-2: leidinggevenden bouwen zelf, brengen toegang/data/security-beperkingen in kaart (IT/security erbij).
  • Week 3-4: champions aanwijzen per functie, mandaat + beschermde tijd, shortlist pijnlijke workflows.
  • Week 5-7: één startworkflow bouwen tot skill/agent, eval-sets, faalmodi identificeren.
  • Week 8-9: trainen bij succes; show-and-tell voor aangrenzende teams; beslissen: shared skill, teamspecifiek, of naar volgende workflow.

Na 60 dagen heb je zelden het hele bedrijf getransformeerd, maar wel: één betrouwbare workflow, getrainde champions, een team aan boord, en een herhaalbaar proces voor de volgende workflow.

Q&A-aanvulling: 33 vragen van 400 executives (augustus 2026)

Natalia Quintero en Mike Taylor (head of evals bij Every) beantwoordden na een live sessie met 400 executives 33 vragen. Onderstaande punten vullen het vijfstappen-playbook aan.

Strategie en ambitie

  • Verhoog het plafond, niet de vloer. Het is makkelijker om één AI-vloeiend persoon 10 goede skills te laten bouwen dan om 10 mensen elk één skill te laten maken. Geef je meest AI-nieuwsgierige mensen toestemming voor ambitieuze projecten.
  • AI is een tool, geen strategie. Een goede visie past AI toe op de bestaande strategische roadmap en pakt de stukken aan die vroeger onmogelijk waren (voorbeeld: klantenservice — oneindige vraag, te duur om te bemensen, AI maakt snelle bediening mét volledige context betaalbaar).
  • Twee soorten productiviteit: sneller doen wat je al doet, en dingen doen die je anders niet zou doen. Dat tweede is visie. Los eerst het productiviteitsprobleem op; de nieuwe dingen komen daarna vanzelf in beeld.
  • Overtuig sceptici niet. Zet champions in het licht. Als peers laten zien dat ze waarde halen, volgen anderen uit praktische overwegingen. Moedig ook zijprojecten aan: wie thuis experimenteert loopt voor, omdat daar grotere risico's mogen.

AI-fluency en samenwerken

  • Acht adoptieniveaus. De meeste mensen zitten in de eerste twee (chat-gebruik, co-work naast een document). Niveau 3 is agentic — waar kenniswerkers nu naartoe bewegen. Daarboven is het grotendeels experimenteel; niveau ~8 is orchestratie, waarbij een manager-AI andere AI's aanstuurt.
  • Gedeelde skills, voorbeelden en standaarden. Niet 1.000 mensen met 1.000 privé-promptmappen. Zet de beste terugkerende workflows om in herbruikbare skills, en maak die zichtbaar, bewerkbaar, toegewezen aan een eigenaar en toegankelijk.
  • Leer AI nooit abstract aan. Laat mensen in de sessie zelf iets bouwen op echt werk. Het aha-moment komt als ze een artefact zien dat ze herkennen: een briefing, memo, spreadsheet, reviewchecklist, klantantwoord of projectplan.
  • Goede early wins zijn saai en frequent: vergadervoorbereiding, gespreksverslagen, documentreview, eerste marketingdrafts, researchbriefs, inbox-triage, kwaliteitschecklists, rommelige input naar gestructureerde tabellen. Criterium: gebeurt wekelijks, heeft een bekende output, is snel door een mens te reviewen.

Tools en platformkeuze

  • Kies één platform. Switchen is duur (contracten, training) en skills die voor Codex geschreven zijn werken minder goed in Claude Code, en andersom. Zolang het model van Anthropic of OpenAI komt zit je goed; een derde partij met toegang tot beide verlaagt de switchkosten.
  • Voortdurend tool-switchen is niets voor beginners. Een maand of twee achter de frontier lopen is prima — alles wat echt goed is wordt binnen 8-12 weken door de andere labs gekopieerd.
  • Kun je niet bouwen, dan nog steeds customizen. Skills maken en koppelen aan je bestaande software is beter dan wachten tot een vendor AI-features toevoegt; die lopen vaak maanden achter.

Governance, risico en kosten

  • AI geeft méér transparantie, niet minder. Activity logs op enterprise-plannen zijn zelf met AI te analyseren tot rapportages — bruikbaar in gereguleerde omgevingen die uitlegbaarheid eisen.
  • Maak IT design partner, geen afdeling "nee". Business bezit de workflow en de definitie van succes; IT bezit toegangscontrole, architectuur en security review. Niet elke use case is even risicovol: een schrijfassistent is iets anders dan een systeem met databasetoegang.
  • Universele valkuilen (industrie-onafhankelijk): onduidelijk eigenaarschap, zwakke fluency bij executives, versnipperde tools, en workflows die niet opnieuw doordacht worden. Wat per sector verschilt zijn de randvoorwaarden, niet het adoptieprobleem.
  • Token-economie. Nieuw, eenmalig of innovatief werk: altijd het beste model — dat is vaak goedkoper ondanks de prijs per token, omdat het correctietijd en foutrisico bespaart. Pas als een taak echt terugkerend wordt, verplaats je hem naar kleinere modellen met prompt-optimalisatie of hill climbing.
  • Over-engineer datasoevereiniteit niet op dag één. Kies een veilig enterprise-platform, krijg de workflows goed, en houd instructies, skills, evals en datalaag portable. Bouw pas een eigen harnas bij een echte compliance- of dataresidentie-beperking — niet uit esthetische voorkeur.

Meten

  • Geen enkele metriek volstaat. Meet op workflowniveau: doorlooptijd, outputkwaliteit, foutpercentage, herbewerkingsfrequentie, gebruikerstevredenheid, en klassieke kosten-batenanalyse. Meet daarnaast hergebruik: hoeveel mensen een gedeelde skill gebruiken, hoe vaak hij verbeterd wordt, of hij onderdeel van het normale proces wordt.
  • Begin met een nulmeting vóór AI (duur, standaard, kosten, typische fouten) en houd per belangrijke workflow een kleine eval-set van echte voorbeelden bij die je herdraait bij elke prompt-, model- of toolwijziging. Anders vertrouw je op vibes.

Kennis en context

  • Een centrale AI-kennishub werkt volgens Quintero niet. Elk document veroudert vanaf publicatie, er is geen goede manier om te bepalen wat bijgewerkt moet worden, en mensen zitten in verschillende stadia. Een reviewlaag erbovenop is resource-intensief en bevredigt alsnog niemand.
  • AI legt kennisschuld bloot en lost die niet op. Begin niet met een gigantisch kennisbankproject. Start met de 10-20 bronnen die er voor één workflow toe doen, wijs eigenaren aan, voeg versheidsdata toe en snoei agressief. Context is geen magazijn: elk document moet zijn plek verdienen of het schaadt meer dan het helpt.

Wie bezit AI?

  • Zowel centraal als verspreid. Een centraal AI-team zet standaarden, doet security- en vendorbeslissingen, onderhoudt gedeelde infrastructuur en bouwt de eerste voorbeelden. De businessteams bezitten de workflows. Bezit het centrale team alles, dan wordt het een bottleneck; bouwt iedereen alleen, dan krijg je wildgroei.
  • Per workflow vier rollen benoemen: business owner, technical owner, risk owner, human approver. Dat is helderder dan proberen het organogram te hertekenen — AI valt de grenzen in dat organogram aan omdat het werk nooit zo netjes gescheiden was als de tekening suggereerde.
  • Bij 200-500 medewerkers: begin bij de executives (hands-on genoeg om te snappen wat mogelijk is), kies dan 2-3 teams met pijnlijk, repetitief, waardevol werk, map de workflow, bouw één skill of agent, bewijs dat het werkt en gebruik dat als intern voorbeeld. De fout is "AI uitrollen" vóórdat iemand een concrete veranderde workflow kan aanwijzen.
  • Voorkom afhankelijkheid van externe bouwers. Koppel elke externe bouwer aan een interne champion. De oplevering is niet alleen een werkende tool maar ook de skill-bestanden, de evals, het beslislogboek, de bedieningsinstructies én een collega die het kan aanpassen. Anders houd je een mooie demo over en geen organisatorische capaciteit.

Wat een jaar geleden niet duidelijk was

  • NQ: je moet nog steeds heldere instructies en sturing geven. Heldere denkers, sterke schrijvers en vakinhoudelijke experts met oog voor excellentie halen er het meeste uit.
  • MT: de snelheid, en dat die blijft versnellen. Ook: AI werd níét goed in schrijven terwijl code juist wél snel ging — omgekeerd aan de verwachting. En het dominante gebruikspatroon is niet iedereen die veel agents beheert, maar één agent die taken routeert.

Open vragen

  • Hoe vertaalt "2 beschermde dagen per maand" naar een MKB-context (1-250 medewerkers) waar champions vaak ook de enige zijn in hun rol?
  • Waar ligt in dit model het snijvlak met Team Agentic OS — is de champion-rol hetzelfde als de toegangsbeheerder in het 3-tier-model?
  • Spanning met de eigen kennisbank-lijn. Quintero stelt dat een centrale AI-kennishub niet werkt (verouderingsprobleem, geen eigenaar per document). Dat schuurt met Zelfverbeterende Kennisbank en Second Brain Niveaus, die juist wél op een onderhouden hub inzetten. Mogelijke verzoening: haar bezwaar geldt een bedrijfsbrede hub zonder eigenaarschap, terwijl de PKM-lijn een persoonlijke of workflow-gebonden kennisbank mét health-check beschrijft. Waard om expliciet te toetsen bij klant-OS-adviezen.
  • "Kies één platform" versus het modelagnostische uitgangspunt in Overstappen van ChatGPT naar Claude (AI Report) — welke van de twee weegt zwaarder voor een MKB-klant?

Verwante concepten

Bronnen

#organisatie #strategie #kosten

Backlinks