Inleiding

Enkele maanden geleden liet een CIO mij zijn Claude Enterprise-dashboard zien. Tweeduizend gebruikerslicenties, geïmplementeerd in zes weken, single sign-on via de identiteitsprovider van het bedrijf, een gebruiksbeleid dat door de juridische afdeling was goedgekeurd en door elke medewerker bij de eerste aanmelding was bevestigd. Vervolgens scrolde hij naar het tweede tabblad. Wekelijkse actieve gebruikers: 14%.

De meest voorkomende opdracht: “Vat deze e-mail samen.” De op één na meest voorkomende: “Herschrijf dit in een professionelere stijl.” Geen enkele koppeling met het ERP-systeem, het data-magazijn of de documentarchieven. Er was geen enkele medewerker in de productie. Drie verdiepingen onder ons was het team van de crediteurenadministratie bezig de PDF-bestanden van leveranciers één voor één te openen, het factuurnummer, het bedrag en de kostenplaats af te lezen en deze met de hand in het financiële systeem in te voeren — ongeveer een honderd facturen per maand, wat neerkomt op ongeveer anderhalve dag werk voor iemand.

Ik vind dit inmiddels niet meer verrassend. Ik ben nu van mening dat dit het gebruikelijke resultaat is van de manier waarop bedrijven AI aanschaffen, en ik wil heel duidelijk aangeven waarom.

Wij hebben gezamenlijk besloten om frontier-modellen op dezelfde manier te behandelen als software: de licentie aanschaffen, de gebruikersaccounts toewijzen, een webinar organiseren en verdergaan. Dat werkte voor e-mail en voor CRM, omdat de waarde van die tools in de tool zelf lag — de inbox was het product, het overzicht van de pijplijn was het product. De waarde van een frontier-model ligt niet in het model zelf. Deze ligt in de afstand tussen het model en de data, bevoegdheden, werkwijzen en processen van een specifiek bedrijf: of het model de omzetcijfers van het afgelopen kwartaal per SKU kan weergeven, of het weet dat de “netto-omzet” bij dit bedrijf exclusief handelsuitgaven is, en of een verkoopdirecteur het ooit ook maar één keer heeft gebruikt bij een vraag die zij die week daadwerkelijk moest beantwoorden.

Er is niemand binnen de organisatie die wordt betaald om die kloof te overbruggen. De IT-afdeling is verantwoordelijk voor de tenant en meet de uptime. De bedrijfsafdeling is verantwoordelijk voor de use cases en meet niets. De leverancier is verantwoordelijk voor de roadmap en meet het aantal licenties. De ruimte daartussen behoort aan niemand toe, en in die ruimte schuilt de waarde.

Na een jaar lang op het 14%-moment bij bedrijven binnen te zijn gestapt, ben ik ervan overtuigd dat deze discipline vormt een vakgebied op zich. Het gaat niet om verandermanagement met betere presentaties, en het gaat ook niet om systeemintegratie met een nieuwe API. Het betreft engineering, data, beveiliging en implementatie, die gezamenlijk worden uitgevoerd binnen de organisatie van de klant, door mensen die tevens deel uitmaken van de roadmap van het lab en die verantwoording afleggen voor een resultaat in plaats van voor een oplevering. Ik noem dit de implementatielaag, en in dit artikel leg ik uit waarom deze belangrijker is dan de volgende modelrelease.

Waarom de implementatie van AI binnen bedrijven tot stilstand komt nadat de licentieovereenkomst is ondertekend

Dit patroon doet zich voor in het bankwezen, de consumptiegoederensector, de vastgoedsector en de telecommunicatiesector, en verloopt volgens een herkenbare volgorde. Een proefproject slaagt: een klein team binnen marketing of klantenservice, een begripvolle sponsor, een duidelijk gebruiksscenario, een demonstratie die de raad van bestuur doet opleven. Een tweede proefproject slaagt in een andere afdeling. Het management keurt een bedrijfsbrede uitrol goed, vaak met een doelstelling als “AI voor iedereen tegen het tweede kwartaal”. De uitrol vindt plaats. Het gebruik neemt gedurende drie weken toe vanwege de nieuwigheid, waarna het afvlakt op het niveau van een betere zoekmachine, en de agenten die de uitrol hadden moeten begeleiden, staan nog steeds op een dia met de titel “Fase 2”.”

De gebruikelijke verklaringen kloppen niet.

  • Het is niet zo dat werknemers zich tegen verandering verzetten; De mensen die ik ontmoet, willen dolgraag dat de tool hen helpt bij hun eigenlijke werk en zijn gefrustreerd omdat deze de spreadsheet die zij op dat moment bekijken, niet kan herkennen.
  • Het is niet zo dat de modellen onvolwassen zijn; Twee generaties geleden waren zij al tot het grootste deel hiervan in staat, en de kloof tussen wat Claude of GPT kunnen en wat de organisatie van hen verlangt, is sindsdien alleen maar groter geworden.
  • En het is niet zo dat er een gebrek aan praktijkvoorbeelden is. Tijdens elke workshop die ik heb gegeven, komen er in de loop van een ochtend tachtig van dit soort opmerkingen, waarvan de helft variaties zijn op “laat mij dit niet steeds opnieuw invoeren”.”

Het proces loopt vast omdat er drie vragen zijn zonder eigenaar:

  • Wat weet het model over ons? Welke systemen kan het inzien — het magazijn, de documentarchieven, het ticketingsysteem, het HR-platform? Op basis van wiens toegangsrechten kan het deze inzien: die van het serviceaccount of die van de persoon die erom vraagt? En wanneer het een nummer verstrekt, kan iemand dan terugvinden uit welke tabel of welk document dit afkomstig is?
  • Wie is binnen elke afdeling verantwoordelijk voor de implementatie? Niet om het aantal licenties te tellen — maar vanwege de gewoonte om de tool op maandagochtend in te zetten voor concreet werk binnen Verkoop, Financiën, Juridische Zaken en Bedrijfsvoering, waarbij elke afdeling zijn eigen data, eigen terminologie en een eigen definitie van “nuttig” hanteert.”
  • Wie ontwikkelt de agents, en wie zorgt voor het onderhoud ervan wanneer de consultants vertrekken? Een IT-achterstand die al achttien maanden oploopt, een externe leverancier met een tijd-en-materiaalcontract, of medewerkers binnen de organisatie die het proces dat zij automatiseren goed begrijpen?

Ik heb nog nooit een programma gezien dat succesvol was waarbij deze vragen door een stuurgroep werden beantwoord. Ze worden beantwoord door de mensen die het werk uitvoeren, in het gebouw, en die beslissingsbevoegdheid hebben.

De implementatielaag: de capaciteit waarvoor niemand middelen reserveert

Tussen het model en de bedrijfsvoering bevindt zich een werkgebied dat noch puur IT, noch puur verandermanagement is. Ik deel dit op in vier onderdelen, en over elk daarvan heb ik een uitgesproken mening.

Implementeer. Het platform zelf — Claude Enterprise, Claude Code en Cowork, of ChatGPT Enterprise en Codex — is naar behoren geïmplementeerd. In de praktijk betekent dit een licentiemodel waarbij licenties worden toegewezen op basis van functie, afdeling en anciënniteit, in plaats van volgens het principe ‘wie het eerst komt, het eerst maalt’; identiteitsbeheer via de bedrijfs-SSO met groepsgebaseerde toegang; een gebruiksbeleid dat in duidelijke taal aangeeft wat wel en niet mag worden ingevoerd, en een gids met best practices die beschrijft hoe goed gebruik eruitziet; en kostenbeheer dat per afdeling laat zien wie wat gebruikt, vanaf de eerste week. Dit is het onderdeel waar de meeste organisaties redelijk goed in zijn, en op zichzelf is het het minst waardevolle onderdeel. Een volledig ingerichte tenant waaraan niets is gekoppeld, is een zeer kostbaar chatvenster.

Grond. De contextlaag die ervoor zorgt dat het model antwoorden geeft die in overeenstemming zijn met de eigen waarheid van het bedrijf. Concreet: een één MCP-server, dat draait in de eigen cloud-tenant van de klant en dat de gestructureerde data (de verkooptabellen in Fabric of Snowflake, de budgetten, de KPI-marts) en de ongestructureerde opslagplaatsen (contracten, beleidsdocumenten, presentaties voor de raad van bestuur en procedures in SharePoint of Drive) via één gecontroleerd toegangspunt. Daarbovenop komt een laag met bedrijfskennis: de officiële woordenlijst, de KPI-definities zoals deze door de financiële afdeling zijn opgesteld, de bedrijfsregels (“een kwartaal wordt op de 25e afgesloten”, “sluit intercompany-transacties uit van de netto-omzet”), en een semantische beschrijving van elk document, zodat het model het juiste bestand kan vinden en dit volledig kan lezen in plaats van te moeten gissen op basis van een fragment. De toegang weerspiegelt de bestaande machtigingen van elke medewerker, zodat het model voor u alleen datgene toont wat u zelf al zou kunnen openen. En elk antwoord bevat een bronvermelding: de tabel, het rijfilter, het document, de pagina. Ik ben van mening dat dit het punt is waarop het succes van bedrijfs-AI staat of valt, en het is het onderdeel dat bijna iedereen overslaat omdat het op loodgieterswerk lijkt. Zonder dit onderdeel is het model een briljante vreemdeling. Met dit onderdeel is het een collega die alles heeft gelezen en dat ook kan aantonen.

Adopteer. Opleiding, afdeling voor afdeling, op het live-bedrijf data. Ik ben allergisch geworden voor de standaard “masterclass in het stellen van vragen” met zijn voorbeeld-e-mails en zijn fictieve bedrijf: die zorgt voor een week van nieuwsgierigheid en daarna stilte. De sessies die wel werken, zien er anders uit. De verkoopafdeling besteedt tweeënhalf uur aan één concrete vraag over het afgelopen kwartaal. De financiële afdeling voert een echte maandafsluiting uit. HR stelt een echt verzuimrapport op. De juridische afdeling toetst een echte geheimhoudingsovereenkomst aan het eigen handboek van het bedrijf. Elke deelnemer vertrekt met een ‘Claude-project’ dat de regels van zijn of haar afdeling bevat, en een bruikbaar document dat hij of zij maandag weer zal openen. Het verschil zit niet in de pedagogiek. Het gaat erom of het model al goed was uitgewerkt voordat er mensen in werden opgeleid.

Bouwen. Productieagenten, ontwikkeld in korte sprints door ingenieurs die samen met het team van de klant werken, op basis van een framework dat door de klant wordt beheerd. Het onopvallende werk — het invoeren van leveranciersfacturen in een schema en het markeren van niet-overeenkomende regels, het opstellen van notulen en actiepunten op basis van een Teams-transcript, het toetsen van een geheimhoudingsovereenkomst aan de interne richtlijnen en het samenvatten van de aansprakelijkheids- en beëindigingsclausules, het extraheren van de cijfers uit een stapel PDF’s naar het acceptatiesjabloon — is waar de uren in zitten, en dat is precies waar de meeste agentprogramma’s nooit komen, omdat ze beginnen met iets indrukwekkends in plaats van iets nuttigs.

Deze vier vormen een systeem, geen menu, en ik zou zelfs nog verder willen gaan: Als men één daarvan doet zonder de andere, is dat vaak erger dan helemaal niets doen. Training zonder basisleer leert mensen dat het systeem onjuiste signalen afgeeft, en zij hebben gelijk. Basisleer zonder training leidt tot de bouw van een kathedraal waar niemand binnenkomt. Agents zonder platform leveren een tiental losstaande automatiseringen op zonder gezamenlijk beheer, en het beveiligingsteam schakelt deze uiteindelijk, terecht, uit.

De rekensom waar ik steeds weer op terugkom, is eenvoudig:

Waarde = Model × Implementatielaag.

Het getal is zeer groot. Vermenigvuldig het met nul en u krijgt nul. Elke nieuwe versie die uit de laboratoria komt, zorgt ervoor dat de eerste factor groter wordt en de tweede factor doorslaggevender wordt.

En hier komt het ongemakkelijke deel voor iedereen die hoopt zich hieruit te kunnen kopen: de implementatielaag kan niet als software worden aangeschaft. De laboratoria verkopen het model en het platform, en zij doen er goed aan het daarbij te laten. De context, de machtigingen, de werkwijzen op afdelingsniveau en de eerste gebruikers zijn specifiek voor de data en de interne politiek van elk bedrijf – welk systeem geldt als de bron van waarheid voor een klant, wie mag de marge per product inzien, en hoe het financiële team de maand daadwerkelijk afsluit. Ze moeten in het gebouw worden ingebouwd, door mensen die zowel de roadmap van het model als de systemen van de klant begrijpen. Er bestaat geen snelle oplossing, en ik sta wantrouwig tegenover iedereen die er een aanbiedt.

Voorbeeld — Wie beantwoordt de vraag over de verkoop?

Neem eens een eenvoudige vraag die een commercieel directeur op een maandagochtend zou kunnen stellen: “Hoe heeft Skala het afgelopen kwartaal gepresteerd ten opzichte van dezelfde periode vorig jaar, en waar hebben wij marktaandeel verloren?”

Op Bora Brasil, de haarverzorgingsgroep die is ontstaan uit Skala Brasil en Lola From Rio, ging die vraag vroeger een hele weg afleggen. Van de directeur naar een analist, van de analist naar een BI-rapport, van het rapport naar een spreadsheet, van de spreadsheet naar een presentatie, en drie dagen later weer terug naar de directeur, waarbij de vervolgvraag inmiddels was veranderd. Ondertussen maakten vijftien early adopters al informeel gebruik van Claude, gekoppeld aan hun e-mail, agenda, Teams en bestanden. Zij kregen plausibele antwoorden waarvan niemand de bron kon achterhalen en waarin soms een definitie van “delen” werd gehanteerd die niemand bij Financiën herkende.

De drie vereisten voor leiderschap waren precies de drie bovenstaande vragen: oplossingen die zijn gebaseerd op de eigen data van de groep, toegang waarbij bestaande machtigingen worden gerespecteerd, en een gereguleerde omgeving zodat gevoelige bedrijfsinformatie niet langer in ongeautoriseerde tools terechtkwam. Dat is het 14%-moment, gezien vanuit het bedrijf zelf.

Wat er in de loop van negen weken veranderde, was niet het model. Er liepen drie trajecten parallel: een bottom-up-traject voor de implementatie, een top-down-traject voor de routekaart en een traject op het gebied van governance.

  • De uitgevoerde ingenieurswerkzaamheden een contextplatform op Azure, goedgekeurd door de eigen technische leiding van de groep, waarmee Microsoft Fabric (verkoopcijfers, KPI’s, budgetten) en SharePoint (contracten, beleidsregels, presentaties) via één enkele MCP-server toegankelijk worden gemaakt.
  • Een bedrijfsinformatielaag bevat de woordenlijst, de definities van de KPI’s en de bedrijfsregels, met een semantische beschrijving van elk document, zodat Claude het volledige bestand kan vinden en lezen.
  • Access weerspiegelt de bestaande machtigingen van elke medewerker, en bij elke figuur wordt de bron (tabel of document) vermeld.

Tegelijkertijd leverden gesprekken met de directeuren van de afdelingen Commercie, Marketing, Innovatie en R&D, Operations, Financiën en HR 83 mogelijkheden op, die werden beoordeeld op zakelijke waarde en technische complexiteit; dit aantal werd teruggebracht tot 24 en vervolgens, tijdens een workshop voor leidinggevenden, tot vijf voor de roadmap van het eerste jaar.

Pas daarna — en alleen dan — volgde de training, specifiek gericht op die verkoopvraag. Tijdens een sessie van 150 minuten zette elke deelnemer een Claude-project op met de bedrijfsregels, haalde de KPI-definities uit SharePoint, plande de query voordat deze in Fabric werd uitgevoerd, bouwde een interactief verkoopdashboard als een deelbaar artefact en controleerde de bron van elk cijfer. De snelste deelnemers maakten van het dashboard nog vóór het einde van de sessie een wekelijks terugkerende routine in Cowork. De handleiding voor de facilitator, zelf opgesteld met Claude, volgde de voortgang van elke deelnemer stap voor stap.

Er zijn vandaag 62 medewerkers actief; dit aantal zal worden uitgebreid tot 150, waarbij licenties worden toegewezen op basis van functie en afdeling, met een AI-bureau als centraal knooppunt en een ‘Champion’ in elke bedrijfsafdeling. De eerste dertig licentiehouders brengen verslag uit gemiddeld ten minste vier uur tijdwinst per week; zeven op de tien besparen drie uur of meer. Eén conversie van de HR-salarisadministratie van 1TP naar 40T het duurde 90 minuten in plaats van de 40 adviesuren die extern waren geraamd. Een rapport over de werktijdregistratie, dat vroeger acht uur handmatig controleren in beslag nam, wordt nu volgens een vast schema uitgevoerd.

Ik vertel dit verhaal niet omdat de cijfers zo hoog zijn — het gaat om voorlopige cijfers die door de betrokkenen zelf zijn opgegeven — maar omdat de volgorde vormt de les. Zorg eerst voor een stevige basis. Oefen op wat al stevig staat. Geef die gewoonte door aan iemand die blijft. Keer de volgorde om en u krijgt een webinar.

Het operatiemodel voor inzet op de frontlinie

Indien de implementatielaag door mensen wordt opgebouwd in plaats van als product te worden aangeschaft, rijst de vraag welke mensen dit doen en hoe zij zijn georganiseerd. Mijn antwoord is bewust geïnspireerd op de manier waarop de labs zelf met hun grootste klanten samenwerken, en het is een antwoord dat de meeste adviesbureaus – waaronder tot voor kort ook het mijne – structureel niet konden geven: kleine teams, geïntegreerd, verantwoordelijk voor een resultaat in plaats van een eindproduct. Er zijn drie werkwoorden die dit beschrijven.

Insluiten

Koppel een een strateeg in de frontlinie samen met een ingenieur in de frontlinie en beide voor de duur van het project bij de klant onderbrengen, indien mogelijk fysiek. De strateeg is verantwoordelijk voor het bedrijfsresultaat en het bedrijfsmodel: welke processen, welke afdelingen krijgen voorrang, welke van de tachtig use cases worden opgenomen in de roadmap voor het eerste jaar, hoe het AI-bureau wordt bemand, hoe de toegevoegde waarde wordt gemeten en aan het uitvoerend comité wordt gerapporteerd. De ingenieur is verantwoordelijk voor het platform, de contextlaag en de agents: de MCP-server en de bijbehorende connectoren, het machtigingsmodel, het agent-framework en de integratie met de systemen die de klant reeds in gebruik heeft. Tijdens een typische week is de strateeg ’s ochtends aanwezig in het kantoor van de financieel directeur en werkt de ingenieur ’s middags samen met het data-team van de klant, waarbij beiden deelnemen aan dezelfde stand-up. Geen van beiden werkt aan de hand van een presentatie, en geen van beiden mag een aanbeveling achterlaten als eindproduct. Het eindproduct is het werkende resultaat.

Ik ben ervan overtuigd dat de combinatie belangrijker is dan de anciënniteit. Een strateeg alleen stelt een stappenplan op dat op de IT-afdeling moet wachten. Een ingenieur alleen ontwikkelt een platform dat op de bedrijfsafdeling moet wachten. Samen zorgen zij voor een vaste gewoonte op maandagochtend.

Trein

De implementatie verloopt afdeling voor afdeling, in de live-omgeving van data, en er vindt een overdracht plaats in plaats van een oplevering. Drie functies zorgen ervoor dat het proces succesvol verloopt.

  • AI-kampioenen in elke bedrijfsafdeling, gekozen op basis van nieuwsgierigheid in plaats van functie, die wekelijks spreekuren houden, de vragen verzamelen waarop mensen met de tool geen antwoord konden krijgen, en de volgende gebruiksscenario’s terugkoppelen aan het team.
  • Een AI-kantoor met in het middelpunt vier functies: leiderschap en bestuur, dat verantwoordelijk is voor de portefeuille en de licenties; een use-case-team dat de use-cases ontwikkelt; een platformteam dat de contextlaag, de beveiliging en de kerntools beheert; en een implementatiefunctie, die samenwerkt met HR en verantwoordelijk is voor opleiding en veranderingsmanagement.
  • En voor technische teams, implementatie op Claude Code en Codex — hackathons, spreekuren, een werkgroep inzake governance voor toegang en kosten — gemeten in dagelijkse sessies per ontwikkelaar in plaats van in werkplekken.

De toets die ik hanteer is eenvoudig: als het ter plaatse ingezette team morgen zou verdwijnen, zou het gebruik dan blijven stijgen? Zo niet, dan is er nog niets ingeburgerd.

Bouwen

De agenten komen aan sprints van twee weken. Dag één bestaat uit een praktische workshop met als thema “hoe bouwt u een agent?”, samen met degenen die verantwoordelijk zijn voor het proces, zodat de medewerker van de crediteurenadministratie tegen lunchtijd heeft gezien hoe een factuur wordt omgezet in gestructureerde velden en weet wat de agent wel en niet zal doen. De rest van de sprint bestaat uit het bouwen, testen en herhalen aan de hand van echte documenten, met op de laatste dag een demonstratie voor de organisatie.

Elke agent vertrekt met een herbruikbaar raamwerk — in een Microsoft-omgeving, doorgaans Power Automate-workflows die de documenten verwerken en de Claude-API aanroepen met het schema en het referentiemateriaal, waarna een gestructureerd dossier wordt gegenereerd voor beoordeling door een medewerker — plus sjablonen voor promptteksten, korte video’s, een aangewezen verantwoordelijke, een testgebruiker en een beheerder die het ontwikkelingsproces heeft gevolgd.

Het succes wordt niet afgemeten aan de vier agenten die wij verzenden. Het is de twintigste die de klant daarna zonder ons bouwt. Als dat getal nul is, hebben wij een afhankelijkheid gecreëerd, geen capaciteit.

Een rode draad door alle drie is de relatie met de labs. Ik ben van mening dat de implementatielaag alleen functioneert wanneer de mensen die deze opbouwen de roadmap voor de komende zes maanden kunnen overzien, rechtstreeks kunnen escaleren naar het oplossingen-team van het lab wanneer een connector niet naar behoren functioneert, en de ingenieurs van het lab in dezelfde ruimte kunnen brengen als de leidinggevenden en ontwikkelaars van de klant. Die nabijheid is geen commerciële beleefdheid. Het is juist wat ervoor zorgt dat een implementatie MCP, Skills, Cowork of Codex al in de maand van hun lancering kan integreren, in plaats van pas een jaar later.

Wat zou er zonder dit mis kunnen gaan?

Stelt u zich eens voor dat dezelfde CIO over achttien maanden de licenties heeft vernieuwd en de implementatielaag heeft overgeslagen. Het aantal licenties is gestegen tot drieduizend; het percentage actieve gebruikers is niet veranderd. De medewerkers die meer wilden, hebben hun daadwerkelijke werkzaamheden stilletjes verplaatst naar persoonlijke accounts, waar de conceptcontracten, klantenlijsten en prognoses voor volgend jaar van het bedrijf nu zijn opgeslagen in chatgeschiedenissen waar niemand toezicht op houdt en die niemand kan verwijderen. Drie afdelingen hebben elk een afzonderlijke oplossing aangeschaft met een eigen ingebouwd model, eigen koppelingen en eigen toegangsrechten – één voor contractbeoordeling, één voor klantenservice en één voor inkoop – die onderling niet overeenstemmen over wat een klant of een marge precies is, en die nu elk een eigen beveiligingsbeoordeling vereisen.

Een handvol enthousiastelingen heeft in een weekend zelf agents gebouwd met behulp van een ‘no-code’-tool. Sommige zijn goed. Geen enkele heeft een eigenaar, een testgebruiker of een logboek, en één ervan verstuurt betalingsherinneringen aan leveranciers met de bankgegevens van vorig jaar. Het beveiligingsteam, dat te laat werd ingeschakeld en geconfronteerd werd met een omgeving die het niet zelf had ontworpen, reageert op de enige manier die het kan: door alles af te sluiten, waardoor de enthousiastelingen terugkeren naar hun persoonlijke accounts en de organisatie weer bij af is.

Het accountteam van het lab ziet een klant met een stabiel verbruik, zonder referentieproject en zonder technische contactpersoon om mee te overleggen, en wijst zijn schaarse oplossingsingenieurs toe aan iemand anders. De organisatie heeft de Frontier betaald en heeft daarvoor een chatbot ontvangen.

Ik wil hier duidelijk zijn over de vraag wie de schuld draagt, omdat deze meestal ten onrechte wordt toegewezen. Dit alles is geenszins te wijten aan een tekortkoming van de technologie, en slechts in zeer beperkte mate aan een tekortkoming van de medewerkers. Dit is het te verwachten gevolg van het feit dat een vaardigheid als een aankoop wordt beschouwd en dat niemand verantwoordelijk is voor de kloof tussen een vergunning en een gewoonte.

Wat wij hebben besloten hieraan te doen

Ik wil afsluiten met wat deze overtuiging in de praktijk heeft betekend, want een mening die geen invloed heeft op de manier waarop u de organisatie inricht, is slechts een opmerking.

Bij Artefact beschouwen wij implementatie niet langer als een fase aan het einde van een strategisch traject, maar hebben wij er een apart vakgebied van gemaakt met een eigen team. Wij noemen dit DeployCo: ter plaatse ingezette ingenieurs en strategen wier enige taak de implementatielaag betreft, die samenwerken met Anthropic en OpenAI, georganiseerd per laboratorium en per regio in Europa, het Midden-Oosten en Afrika, waarbij elke regio beschikt over een bedrijfsverantwoordelijke en een technisch verantwoordelijke voor elk laboratorium. Wij streven ernaar om in 2027 met honderd te zijn. Dat is een stelling, en ik durf die gerust in het openbaar te verkondigen, omdat ik denk dat het alternatief — het verkopen van de strategie en het overlaten van de technische uitvoering aan iemand anders — de reden is waarom de sector in de situatie 14% is beland.

Deze weddenschap berust op een aantal standpunten die ik vastberaden verdedig:

  • Dat Een stevige basis is belangrijker dan training, altijd, en dat een trainingssessie waarin de eigen data van de cliënt ontbreekt, slechts schijn is.
  • Dat een agent zonder genoemde eigenaar en een onderhoudsprogramma vormt een last, geen aanwinst, hoe slim het ook is.
  • Dat de Het team van de klant moet binnen één kwartaal beter presteren dan het onze, of anders hebben wij gefaald.
  • En dat de mensen die dit werk doen dicht genoeg bij de laboratoria moeten zitten om te zien wat er op komst is; daarom brengen wij onze tijd met hen door in vergaderruimtes — alleen al in oktober in München, Zürich en Casablanca, met leidinggevenden van klanten en hun ontwikkelaars aan de ene kant van de tafel en de teams van Anthropic en OpenAI aan de andere kant, waarbij we concrete implementaties doornemen in plaats van naar keynote-presentaties te luisteren.

Chancerygate, een Londense vastgoedontwikkelaar en vermogensbeheerder met ongeveer 700 huurders en enkele 1,2 miljard pond aan beheerd vermogen, is het duidelijkste bewijs dat ik heb dat het derde standpunt klopt. Tijdens een workshop in het voorjaar kwam de gebruikelijke administratieve rompslomp aan het licht: honderd leveranciersfacturen per maand die met de hand opnieuw moesten worden ingevoerd, anderhalf uur om de notulen van elke grote vergadering te valideren, NDA-beoordelingen waarbij de risicoclausules niet consistent werden behandeld, en acceptatiemodellen die werden opgesteld door cijfers uit PDF’s over te nemen.

In een sprint van twee weken binnen hun Microsoft-omgeving heeft één gezamenlijk team vier Door Claude aangestuurde agenten tegen juist die vier problemen:

  • crediteuren (80% minder tijd per factuur, waarbij meer dan 90% aan factuurregels automatisch zijn gekoppeld),
  • Beoordeling van de NDA (van drie dagen tot minder dan twee uur),
  • het opstarten van de acceptatieprocedure (25 uur tot minder dan drie)
  • en notulen van de vergadering (anderhalf uur tot dertig minuten).

Elk project kreeg een eigenaar, een testgebruiker en een beheerder toegewezen. Sindsdien hebben hun eigen medewerkers — ongeveer 25 opgeleide medewerkers, waarvan er zo’n tien de agents dagelijks gebruiken — meer dan twintig extra agents ontwikkeld, elk in minder dan een halve dag, en zijn zij nu bezig de AP-agent rechtstreeks in NetSuite te integreren en de NDA-agent in DocuSign.

“Het Artefact-team was fantastisch”, aldus Phil Price, hun hoofd FP&A, “en heeft ons in een goede uitgangspositie achtergelaten om zelf verder te bouwen en uit te breiden.” De eerste helft van die zin is vriendelijk. De tweede helft is waar het om draait.

De grens is niet langer het model. Het is de afstand tussen het model en uw maandagochtend. Indien u over Claude- of ChatGPT-licenties beschikt en de drie vragen in dit artikel nog niet kunt beantwoorden — wat het model over u weet, wie binnen elke afdeling verantwoordelijk is voor de implementatie, en wie uw agents ontwikkelt en onderhoudt — dan beschikt u nog niet over AI-capaciteit. U hebt een abonnement. Het goede nieuws is dat deze kloof binnen enkele weken, en niet pas na jaren, kan worden gedicht door mensen die hebben besloten dat het hun taak is om deze kloof te dichten.

Ik zou graag vernemen op welke punten u het niet met mij eens bent: remi.sabonnadiere@artefact.com