De zeven bekende faaloorzaken van AI-projecten zijn alle zeven organisatorisch: geen eigenaar, geen gemeten uitgangspunt, geen procesherontwerp, governance als sluitstuk. Ik werk al vijfentwintig jaar aan precies die zeven — bij ERP-implementaties, e-businessportalen en reorganisaties. Alleen de technologie is nieuw. En die heb ik in mijn eigen bedrijf van nul gebouwd en in productie genomen.
Vrijwel iedereen gebruikt intussen AI. Bijna niemand kan aantonen wat het opbrengt. Toen ik mijn eigen bedrijf doorlichtte, schreef ik één zin op die sindsdien bij elke klant klopt: de intelligentie was aanwezig, de integratie ontbrak. De techniek is zelden het probleem. Wat ontbreekt is het werk eromheen — processen die opnieuw getekend zijn, data waar je op kunt bouwen, iemand die eigenaar is, en iemand die durft te meten.
Ondertussen gebruiken uw medewerkers al AI, alleen niet de uwe. Dat is geen overtreding maar een signaal: er is vraag die uw officiële traject niet invult.
Ik ben Dirk Odeurs, industrieel ingenieur, Prince2 Practitioner sinds 2003. Ik heb mijn loopbaan besteed aan wat vandaag de moeilijkste kant van AI-transformatie blijkt te zijn: organisaties in beweging krijgen.
Concreet: ERP-systemen geïmplementeerd en gemigreerd, e-businessportalen gebouwd met duizenden dagelijkse gebruikers, een volledige supportafdeling herdacht op proces én tooling, een veranderingstraject geleid in een organisatie met meer dan vierhonderd beheerders, een Europese aanbesteding voorbereid voor de federale overheid, en een vastgelopen kennisprogramma opnieuw vlot getrokken door de weerstand serieus te nemen in plaats van eromheen te werken.
Sinds 2016 ben ik daarnaast ondernemer in de bouwsector. En sinds kort heb ik voor dat eigen bedrijf een AI-native platform ontworpen, gebouwd en in productie genomen: agentic workflows in de dagelijkse operatie, verificatie op elke voorgestelde actie, kosten per taak zichtbaar en begrensd. Opgebouwd terwijl het bedrijf gewoon doordraaide.
Die combinatie is het punt. Ik weet niet alleen hoe het hoort — ik weet ook wat er stukgaat als je het zelf moet laten werken, met je eigen geld als inzet.
En wat ik niet ben.
Ik kom niet van een groot adviesbureau en ik heb geen dertig AI-transformaties op de teller — niemand heeft dat, het vak bestaat te kort. Wat ik wel heb: vijfentwintig jaar veranderingswerk van vóór AI, en de technische diepgang van iemand die het systeem zelf gebouwd heeft. Als u iemand zoekt die met een merknaam op de deur binnenkomt, ben ik het niet.
Geen dienstenmenu. Dit is wat er in de praktijk nodig blijkt, in deze volgorde.
Vijf dimensies, gescoord met bewijs in plaats van met goede bedoelingen. Plus een inventaris van wat er al draait — inclusief wat niemand heeft aangemeld. Resultaat: een uitgangspunt waar niemand omheen kan.
Werksessies per domein met de mensen die het werk doen, kandidaten gescoord op waarde en haalbaarheid, en een keuze: weinig initiatieven, diep uitgevoerd. Elk met een eigenaar, een termijn en een meetpunt.
De stap waar de meeste trajecten sneuvelen. Gemeten uitgangspunt, kwaliteitstests, beheer en eigenaarschap geregeld vóór de uitrol — en een go-beslissing die een rekensom is in plaats van een discussie.
Dit is mijn volledige werkwijze, inclusief hoe ik elke stap concreet uitvoer: welke sessies, welke deelnemers, welk gereedschap, hoe ik het vastleg. Ik zet het online omdat de methode het probleem niet is. De uitvoering wel.
De aanpak verschilt wezenlijk naargelang uw schaal — niet alleen in lengte, maar in vorm. Een organisatie van negentig mensen heeft geen beslisorgaan met juridische dienst en security. Ze heeft een zaakvoerder die beslist. Doen alsof dat hetzelfde is, is precies waarom veel adviestrajecten bij kleinere bedrijven mislukken.
Voor organisaties zonder aparte IT-, juridische of HR-afdeling. Dit is de aanpak die ik in mijn eigen bedrijf heb gebruikt, waar ik zelf de stuurgroep was.
Voor organisaties met meerdere afdelingen, een eigen IT-functie en juridische betrokkenheid. Twee sporen lopen parallel: resultaat zonder fundament wordt rommel die niemand meer overziet, fundament zonder resultaat wordt een map die niemand opent.
Deze werkwijze is niet uit het niets ontstaan, en ik doe niet alsof. De diagnosevragen — welke processen zijn herontworpen, en wie is er eigenaar van — komen uit het onderzoek van McKinsey. Het inzicht dat het zwaartepunt bij mensen en processen ligt en niet bij de techniek, is van BCG. Dat proeven zonder eigenaar en zonder nulmeting zelden iets opleveren, is gedocumenteerd door MIT. En de opbouw van het fundamentspoor — eerst zien wat er draait, dan eigenaarschap, dan rechten, dan doorlopende opvolging — volgt de logica die Cegeka beschreef in hun uitrolmodel voor AI-agents.
Wat van mij is: de volgorde waarin ik het uitvoer, de manier waarop elke stap concreet wordt gemaakt — welke sessie, wie erbij zit, wat er op papier komt — en vijfentwintig jaar ervaring met wat er werkelijk in de kamer gebeurt wanneer je een directie om een besluit vraagt.
Ik zet dit erbij omdat ik het van klanten ook vraag. Wie een cijfer of een model gebruikt zonder te zeggen waar het vandaan komt, verkoopt iets.
Hiervoor hebt u mij niet nodig. Als u dit doet en er komt niets verontrustends uit, hebt u waarschijnlijk ook geen consultant nodig. Komt er wél iets uit, dan weet u tenminste wat.
Eén enquête van onder de acht minuten: welke AI-hulpmiddelen gebruikt u voor uw werk, ook privé-accounts. Anoniem, anders krijgt u het antwoord dat u wil horen. Verwacht een hoger cijfer dan u denkt — en behandel dat als vraagsignaal, niet als overtreding.
Een rekenblad met zeven kolommen: naam, type, eigenaar, gebruikers, welke data, wat het kost, status. Vul het met alles wat u vindt. U kunt niets sturen wat u niet ziet. Die lijst is uw halve diagnose.
De klassieke faalwijze is versnippering over tien proeven. Kies de toepassing met het grootste volume en de duidelijkste pijn, en zet de rest expliciet op een niet-nu-lijst. Nee zeggen is een kwaliteitskenmerk.
Twee tot vier weken cijfers verzamelen: hoeveel, hoe lang, hoe vaak fout. Uit de systemen als het kan, anders twintig taken met een chronometer. Zonder dit getal kunt u later nooit aantonen dat het gewerkt heeft.
Welke middelen zijn toegestaan, welke data mag er nooit in, wanneer moet een mens beslissen, en bij wie meldt u een probleem. Twee pagina's die iedereen kent, verslaan een handboek dat niemand leest.
Ik vraag niet of er een beleidslijn bestaat. Ik vraag om ze te zien, en om wie ze kent. Het verschil tussen die twee antwoorden is meestal de hele diagnose.
Wie beleid schrijft vóór hij weet wat er draait, regelt een werkelijkheid die hij nooit gezien heeft. Ik draai die volgorde niet om.
Zonder cijfers van vóór de start is elke besparing een mening. Dat is de belangrijkste reden waarom investeringen stilvallen.
Een lijst zonder afgevoerde ideeën is geen keuze maar een verlanglijst. In de trajecten die ik ken, werd het programma pas geloofwaardig op de dag dat er iets zichtbaars sneuvelde.
Niet als ethische voetnoot maar als ontwerpeis. Wie een systeem bouwt waarvan achteraf niemand kan uitleggen waarom het besliste zoals het besliste, heeft het werk niet af. De wetgever denkt daar intussen hetzelfde over.
Ik gebruik cijfers mét hun beperking. Wie een onderzoekscijfer citeert zonder te zeggen wat er precies gemeten is, verkoopt iets. Dat wil ik niet zijn.
Als u herkent wat hierboven staat — veel losse initiatieven, weinig aantoonbaar resultaat, en niemand die precies weet wat er draait — dan is een eerste gesprek meestal genoeg om te bepalen of er iets zinvols te doen valt. Ook als het antwoord "nog niet" is.
dirk.odeurs@vedinet.beThe seven known reasons AI projects fail are all seven organisational: no owner, no measured starting point, no process redesign, governance bolted on at the end. I have spent twenty-five years on exactly those seven — in ERP implementations, e-business platforms and reorganisations. Only the technology is new. And I built that part myself, from scratch, and put it into production in my own company.
Almost everyone uses AI by now. Almost nobody can show what it returns. When I audited my own company I wrote down one sentence that has held up at every client since: the intelligence was there, the integration was missing. The technology is rarely the problem. What is missing is the work around it — processes redrawn, data you can build on, someone who owns it, and someone willing to measure.
Meanwhile your people are already using AI, just not yours. That is not misconduct, it is a signal: there is demand your official programme is not meeting.
I am Dirk Odeurs, an industrial engineer and Prince2 Practitioner since 2003. I have spent my career on what turns out to be the hard part of AI transformation: getting organisations to actually move.
Concretely: ERP systems implemented and migrated, e-business platforms built with thousands of daily users, an entire support department rethought in both process and tooling, a change programme led in an organisation of more than four hundred case handlers, a European public tender prepared for the federal government, and a stalled knowledge programme brought back to life by taking the resistance seriously rather than working around it.
Since 2016 I have also run my own company in the construction sector. And recently I designed, built and put into production an AI-native platform for it: agentic workflows in daily operations, verification on every proposed action, cost per task visible and capped. Built while the business kept running.
That combination is the point. I do not only know how it should be done — I know what breaks when you have to make it work yourself, with your own money at stake.
And what I am not.
I do not come from a large advisory firm and I do not have thirty AI transformations behind me — nobody does, the field is too young. What I do have is twenty-five years of change work from before AI existed, and the technical depth of someone who built the system himself. If you are looking for someone who arrives with a brand name on the door, I am not that person.
Not a service menu. This is what turns out to be needed in practice, in this order.
Five dimensions, scored on evidence rather than good intentions. Plus an inventory of what is already running — including what nobody declared. The result is a starting point nobody can argue around.
Working sessions per domain with the people who do the work, candidates scored on value and feasibility, and a choice: few initiatives, executed deeply. Each with an owner, a deadline and a measurement point.
The step where most programmes die. Measured baseline, quality tests, ownership and support arranged before rollout — and a go decision that is arithmetic rather than debate.
This is my complete way of working, including how I actually carry out each step: which sessions, which participants, which tools, how I record it. I publish it because the method is not the problem. The execution is.
The approach differs fundamentally with your scale — not just in length, but in shape. An organisation of ninety people does not have a decision body with legal and security on it. It has an owner who decides. Pretending those are the same thing is precisely why so much consulting fails at smaller companies.
For organisations without a separate IT, legal or HR department. This is the approach I used in my own company, where I was the steering group.
For organisations with multiple departments, an in-house IT function and legal involvement. Two tracks run in parallel: results without foundations become a mess nobody can oversee, foundations without results become a folder nobody opens.
This way of working did not appear out of nowhere, and I will not pretend otherwise. The diagnostic questions — which processes have been redesigned, and who owns them — come from McKinsey's research. The insight that the centre of gravity sits with people and process rather than technology is BCG's. That pilots without an owner and without a baseline rarely return anything has been documented by MIT. And the sequence of the foundation track — first see what is running, then ownership, then permissions, then continuous monitoring — follows the logic Cegeka described in their rollout model for AI agents.
What is mine: the order in which I run it, the way each step is made concrete — which session, who is in the room, what ends up on paper — and twenty-five years of knowing what actually happens when you ask a board for a decision.
I state this because I ask the same of clients. Anyone using a figure or a model without saying where it came from is selling something.
You do not need me for this. If you do it and nothing worrying comes out, you probably do not need a consultant either. If something does come out, at least you know what.
One survey under eight minutes: which AI tools do you use for work, personal accounts included. Anonymous, otherwise you get the answer you want to hear. Expect a higher number than you think — and treat it as demand, not misconduct.
A spreadsheet with seven columns: name, type, owner, users, which data, what it costs, status. Fill it with everything you find. You cannot steer what you cannot see. That list is half your diagnosis.
The classic failure mode is spreading across ten pilots. Pick the application with the highest volume and the clearest pain, and put the rest explicitly on a not-now list. Saying no is a mark of quality.
Two to four weeks of numbers: how many, how long, how often wrong. From the systems if you can, otherwise twenty tasks with a stopwatch. Without that number you can never later prove it worked.
Which tools are allowed, which data may never go in, when a human has to decide, and who to report a problem to. Two pages everybody knows beat a manual nobody reads.
I do not ask whether a policy exists. I ask to see it, and who knows it. The gap between those two answers is usually the entire diagnosis.
Write policy before you know what is running and you are regulating a reality you have never seen. I do not reverse that order.
Without numbers from before the start, every saving is an opinion. That is the main reason investment stalls.
A list with nothing rejected is not a choice but a wish list. In the programmes I have seen, credibility arrived on the day something visible was killed.
Not an ethical footnote but a design requirement. If nobody can explain afterwards why a system decided what it decided, the work is not finished. The regulator has come round to the same view.
I use numbers with their limitations attached. Anyone quoting a research figure without saying what was actually measured is selling something. I would rather not be that person.
If you recognise the picture above — many scattered initiatives, little demonstrable result, and nobody who knows exactly what is running — a first conversation is usually enough to establish whether there is anything worth doing. Including when the answer is "not yet".
dirk.odeurs@vedinet.be