Wat moet een AI-consultant in de eerste 30 dagen opleveren?

Een bruikbare indeling van 30 dagen

Het tempo hangt af van toegang en complexiteit, maar de opdracht moet snel van begrijpen naar aantonen bewegen.

• Dag 1-5: gesprekken, nulmeting, systemen en beperkingen.
• Dag 6-10: kansen wegen en één workflow kiezen.
• Dag 11-20: prototype of technische validatie met gebruikers.
• Dag 21-25: uitzonderingen, beveiliging en beheer testen.
• Dag 26-30: advies, scope, eigenaarschap en plan voor de volgende release.

Wat je niet moet verwachten

Een complex productiesysteem is niet altijd verantwoord binnen een maand af. De consultant moet onzekerheid verkleinen, afhankelijkheden zichtbaar maken en een demo niet verkopen als een ingevoerd bedrijfsproces.

De eerste maand moet onzekerheid zichtbaar verkleinen

Na dertig dagen hoeft een complexe AI-oplossing niet volledig live te staan. Er moet wel een gedeeld beeld zijn van het proces, de nulmeting, data, risico's en de meest kansrijke eerste toepassing. Daarnaast hoort er tastbaar bewijs te liggen: een geteste prototypeflow, technische validatie of een onderbouwd besluit om juist niet te bouwen.

• Week 1: doelen, gebruikers, proces, systemen en nulmeting.
• Week 2: use cases, data-analyse, risico's en prioritering.
• Week 3: prototype of technische validatie met echte voorbeelden.
• Week 4: gebruikerstest, businesscase en besluit over de volgende fase.

Een geloofwaardig resultaat na dertig dagen

Bij een logistiek bedrijf kiest de consultant niet direct voor volledige orderautomatisering. Eerst worden vijfhonderd historische e-mails geanalyseerd, categorieën en uitzonderingen vastgesteld en een conceptflow getest. Medewerkers beoordelen de uitkomsten. Aan het einde van de maand is bekend welk percentage betrouwbaar kan worden verwerkt, welke ERP-koppeling nodig is en waar menselijke goedkeuring blijft. Daarmee kan het management verantwoord investeren.

Organiseer een strak werkritme

Korte feedbackcycli voorkomen dat analyse en bouw uit elkaar lopen. Plan vanaf het begin vaste momenten met gebruikers en beslissers.

• Start met één opdrachtgever en een duidelijke beslisvraag.
• Plan interviews en toegang tot systemen in de eerste week.
• Werk met een gedeelde lijst van aannames, risico's en besluiten.
• Demo wekelijks op echte scenario's, inclusief fouten.
• Sluit af met resultaat, open punten, budget en verantwoordelijke voor fase twee.

Beoordeel de maand op bewijs

Een goed traject laat niet alleen zien wat mogelijk is, maar ook wat nog niet betrouwbaar werkt. Dat voorkomt een optimistische businesscase.

• Volledigheid van nulmeting en procesbeeld.
• Aantal kritieke aannames dat met data of gebruikers is getest.
• Kwaliteit en foutpercentage van de prototypeflow.
• Duidelijkheid over waarde, risico, scope en volgende investering.

Wat je na dertig dagen niet moet accepteren

Alleen een generieke presentatie, een demo zonder eigen data of een roadmap zonder eigenaar is onvoldoende. Andersom is een productiebelofte ook verdacht als toegang, security en uitzonderingen nog niet zijn onderzocht. De eerste maand is geslaagd wanneer de organisatie beter kan beslissen en een beperkt, realistisch pad naar waarde heeft.

Leg op dag één vast wat op dag dertig aantoonbaar moet zijn

Een eerste maand werkt alleen met concrete acceptatiecriteria. Beschrijf welk proces wordt onderzocht, welke gebruikers meedoen, welke data beschikbaar komt en welke beslissing het management daarna wil nemen. Maak onderscheid tussen een prototype, een productieklare functie en een adviesdocument; die resultaten vragen een andere inspanning. Spreek ook af welke blokkades de opdrachtgever tijdig moet oplossen. Daarmee wordt voortgang objectief en kan scope niet ongemerkt verschuiven.

• Een gevalideerd procesbeeld met volumes, uitzonderingen en huidige nulmeting.
• Een geteste oplossing of technische proef op representatieve voorbeelden.
• Een besluitstuk met waarde, risico's, architectuur, budget en fase-twee-scope.

Verwacht iedere week een ander soort bewijs

In week één hoort de consultant vooral te luisteren en meten. Week twee brengt prioriteiten, data en risico's samen. In week drie moet het team iets kunnen testen; in week vier worden uitkomsten vertaald naar een zakelijk besluit. Wekelijkse demo's voorkomen dat een glanzende eindpresentatie weken van misverstanden verbergt. Demonstreer ook foutgevallen en handmatige escalatie, want juist daar wordt zichtbaar of een oplossing in dagelijks gebruik kan overleven.

• Week 1: proceskaart, gebruikersbehoeften, nulmeting en toegangsplan.
• Week 2: use-casekeuze, datakwaliteit, risico's en oplossingsopties.
• Week 3: prototype, testset, eerste metingen en technische beperkingen.
• Week 4: gebruikerstest, businesscase, roadmap en investeringsbesluit.

Gebruik een formele poort voor de volgende fase

Sluit de maand af met een korte go, adjust of stop-beslissing. Doorgaan vereist een eigenaar, voldoende bewijs, beheersbare risico's en een begroting die past bij de verwachte waarde. Bijsturen is logisch wanneer de kans goed is maar data, proces of scope eerst moet worden verbeterd. Stoppen kan een uitstekend resultaat zijn als de hypothese niet klopt. Documenteer die keuze, zodat dezelfde discussie niet enkele maanden later opnieuw begint.

• Go: bewijs is sterk genoeg voor een afgebakende productie-implementatie.
• Adjust: eerst data, proces, compliance of gebruikersontwerp verbeteren.
• Stop: waarde, haalbaarheid of risicoprofiel rechtvaardigt geen vervolg.

Verwacht een overdracht die een ander kan voortzetten

Aan het einde van de maand moeten resultaten buiten de laptop en het hoofd van de consultant bestaan. Verzamel beslislog, proceskaart, testset, meetresultaten, architectuurkeuzes en open risico's op een plek die het bedrijf beheert. Laat een interne medewerker de uitleg teruggeven en een eenvoudige wijziging doorlopen. Dat is een praktische toets op documentatie en voorkomt dat fase twee alleen door dezelfde persoon kan worden uitgevoerd.

• Repository en documentatie zijn toegankelijk via accounts van de opdrachtgever.
• Aannames, beperkingen en niet-opgeloste fouten zijn expliciet beschreven.
• De interne eigenaar kan de volgende beslissing en belangrijkste risico's uitleggen.