Het bewijsstuk

De zeven faaloorzaken in de praktijk

Op de startpagina staat dat geen van de zeven bekende faaloorzaken van AI-projecten technisch is. Dat is geen bevinding uit een rapport. Alle zeven deden zich voor in één onderneming, met eigen geld als inzet — bij het bouwen van VediCore, een AI-native SaaS ERP-platform voor de bouwsector dat vandaag in productie draait.

Wat dit is, en wat niet

Eén case in plaats van tien

Wat je hier krijgt.

Per faaloorzaak: wat er zich concreet voordeed, welke beslissing eruit volgde, en waar de grens van die beslissing ligt. Geen abstracties. Dit is de enige positie waarin je alle zeven tegelijk tegenkomt en niemand anders kunt aanwijzen: opdrachtgever, uitvoerder, architect, ontwikkelaar en eigenaar in dezelfde persoon.

Wat je hier niet krijgt.

Dit is één onderneming, en het is de mijne. Dit is geen portfolio van dertig AI-trajecten — dat heeft niemand, het vak bestaat te kort. Wie een portfolio van referenties zoekt, moet elders zijn. Wie iemand zoekt die deze zeven van dichtbij heeft zien werken en er beslissingen op heeft moeten nemen, leest verder.

Vijftien jaar daarvoor deden dezelfde zeven zich al voor bij ERP-implementaties, e-businessportalen en reorganisaties — alleen heetten ze toen niet zo, en was de technologie een andere. Dat is precies het punt van deze site: alleen de technologie is nieuw.

Faaloorzaak 1

Technologie zoekt probleem

Wat er meestal gebeurt: het project start vanuit een demo in plaats van vanuit een gemeten pijnpunt.

De beslissingHet traject begon niet bij technologie maar bij een strategische mapping van de kernactiviteit — over de financiële, klant-, proces- en capaciteitsperspectieven heen. Die oefening bepaalde wat de operatie moest realiseren, vóór er over systemen werd nagedacht.
De volgorde die eruit volgdePijnpunten expliciet in kaart, aan beide zijden van de keten: bij de opdrachtgever én bij de onderaannemer. Het ontwerp vertrok van die pijnpunten, niet van de data die toevallig beschikbaar was. Processen werden eerst herdacht en pas daarna gedigitaliseerd.
Waarom dat teltWie die volgorde omdraait, digitaliseert zijn bestaande inefficiëntie en bouwt haar vast in een systeem. Dat is duurder dan niets doen.

Faaloorzaak 2

De tool staat naast het werk

Wat er meestal gebeurt: geen integratie in de bestaande workflow, geen geheugen, geen verbetering door gebruik.

De situatieDit is de zin die op deze hele site terugkomt, en hij komt hiervandaan. De administratie was niet ongeorganiseerd: een uitgewerkt Excel-model bevatte nagenoeg alles wat het platform vandaag bevat, en bevatte het accuraat. Wat het niet kon, was verbinden. Het stond los van de mailstroom, los van de foto's, los van de getekende bonnen die meereisden in het voertuig van de uitvoerders en soms onvolledig, soms onleesbaar, soms helemaal niet terugkwamen. De intelligentie was aanwezig. De integratie ontbrak.
Het onderscheid dat alles bepaaltAI inzetten tijdens de bouw versnelt de oplevering, maar verdwijnt met de oplevering — dat is steigermateriaal. AI-native betekent dat de intelligentie een permanente laag is in het draaiende systeem, met eigen context, eigen controles en eigen kostentransparantie. VediCore is op beide manieren gebouwd. De tweede is waar de blijvende waarde zit.
Hoe dat er concreet uitzietInkomende correspondentie wordt automatisch in twaalf intenties gecategoriseerd en aan het juiste dossier gekoppeld, met concept-antwoorden klaar. Ondertekening gebeurt digitaal op het punt van uitvoering, via QR-code of mail — het bewijs van geleverde prestatie verlaat het systeem niet meer.

Faaloorzaak 3

Data niet bruikbaar

Wat er meestal gebeurt: kwaliteit of beschikbaarheid zijn niet op orde — volgens Gartner de stille blokkade nummer één.

In deze case lag het anders, en dat is leerzaamHet probleem lag niet in de datakwaliteit en niet in de structuur. Die waren in orde. Het lag in de verbinding: elke koppeling tussen de eilanden werd manueel gelegd, herhaald, door één persoon. Informatie die verstuurd was, verouderde in de inbox van de ontvanger. Een planning die twee weken vooraf werd doorgegeven, bestond op het moment van uitvoering enkel nog als herinnering.
De ontwerpbeslissingEén dossierstructuur onder alle modules. De werf is de passieve, centrale locatie; het werkelijke werk leeft in de leads en projecten die eraan hangen. Wat gepresteerd, gefactureerd en betaald is, zijn drie standen van één dossier — niet drie administraties die verzoend moeten worden.
Wat dat oplevert in een andere organisatieDe eerste vraag aan een organisatie is dan ook niet de datakwaliteit, maar het aantal plaatsen waar hetzelfde feit apart wordt bijgehouden. Dat cijfer voorspelt meer.

Faaloorzaak 4

Geen eigenaar

Wat er meestal gebeurt: een innovatieteam bouwt iets dat de lijnorganisatie nooit overneemt. Bij McKinsey ziet 48% van de best presterende organisaties eigenaarschap bij de directie, tegenover 16% bij de rest.

De beslissingDe zaakvoerder was zelf de stuurgroep. Het systeem groeide modulair en was in dagelijks gebruik gedurende de volledige opbouw — er was geen moment waarop iets werd "overgedragen", want er was geen kloof om over te dragen.
Waarom dat voordeel niet vanzelf overdraagbaar isEen bedrijf van vijftien mensen heeft een zaakvoerder die beslist, en dat is een voordeel. Een organisatie van vierhonderd heeft dat niet, en doen alsof het hetzelfde is, is precies waarom veel adviestrajecten stukgaan. Daarom staan er op deze site twee aanpakken en niet één.
Wat dit betekent voor een andere organisatieDe vraag is niet of er een eigenaar benoemd is. De vraag is of die eigenaar iets kan schrappen zonder toestemming te vragen. Zo niet, dan is hij geen eigenaar maar een rapporteur.

Faaloorzaak 5

Geen uitgangsmeting

Wat er meestal gebeurt: zonder cijfers van vóór de start is elke besparing een mening — en dan stopt het budget. Dit is de enige van de zeven die niet met een cijfer uit één onderzoek te staven is; het is een praktijkobservatie, en dat hoort erbij vermeld.

Wat er ingebouwd isElke modelaanroep logt tokens en kostprijs. Budgetten gelden per dag en per maand, in euro, met een alarmdrempel en een automatische pauze bij overschrijding. Bulkwerk loopt in batch tegen halve kostprijs. Verbruik is een instelling vooraf, geen verrassing achteraf.
Waarom dat vanaf dag één moestOmdat "wat kost die AI eigenlijk" een vraag is die pas gesteld wordt op het moment dat ze niet meer te beantwoorden is. Wie kostprijs per taak achteraf wil reconstrueren, reconstrueert een schatting.
De harde versie, voor elke organisatieGeen uitgangsmeting, geen proef. Als meten echt niet kan, hoort erbij te staan wat daarmee opgegeven wordt — maar het is geen aanbevolen start.

Faaloorzaak 6

Verandering onderschat

Wat er meestal gebeurt: het zwaartepunt zit bij mensen en processen, maar het budget ging naar licenties. McKinsey rekent voor dat per euro in technologie er drie naar procesherontwerp hoort en vijf naar bekwaamheid en adoptie — en dat de meeste bedrijven die verhouding precies omdraaien.

Waar het onderschat werdDe eigen administratie werkt vandaag volledig papierloos. Aan de rand van de keten tekenen enkele onderaannemers nog altijd op papier. Hun bonnen worden bij binnenkomst digitaal ingelezen en afgestemd, en dat aandeel is in afbouw — maar het is er nog. Dat is geen technisch probleem en is het nooit geweest.
Wat werkteDe portalen. De klant ziet op elk ogenblik het volledige beeld van zijn dossier — getekende bonnen, uren, facturatie, wat openstaat tegenover de goedgekeurde offerte. De onderaannemer ziet hetzelfde principe aan zijn kant. Er is één planning, en iedereen kijkt naar hetzelfde beeld ervan. Adoptie volgt wanneer het nieuwe systeem de gebruiker iets geeft dat hij eerst niet had.
De lesVerandering lukt niet door mensen te overtuigen dat jouw systeem beter is. Ze lukt door hun eigen pijnpunt weg te nemen. Daarom staan die pijnpunten aan beide zijden van de keten in kaart vóór er iets gebouwd wordt.

Faaloorzaak 7

Governance als sluitstuk

Wat er meestal gebeurt: security en legal komen in week twaalf langs en blokkeren de livegang. Bij Deloitte heeft 21% van de organisaties een volwassen governancemodel voor agentic AI, terwijl 74% er tegen 2027 mee wil werken.

Verificatie als ontworpen beslisstapOp elke voorgestelde actie staat een afzonderlijk geconfigureerd controle-model dat het voorstel vergelijkt met de bestaande data, met vier uitkomsten: doorgaan, overslaan, verrijken, of voorleggen aan een mens. Verificatie is geen aanname maar een stap in het ontwerp.
Autonomie is een instelling, geen eigenschapEen automatisatie kan uitsluitend voorstellen doen; autonomie verwerven na een vooraf bepaald aantal goedgekeurde uitvoeringen; of onbewaakt draaien. Die keuze valt per taak, niet per platform.
Eén grens ligt vastGeen enkele automatisatie neemt zelfstandig contact op met een klant. Het opstellen wordt gedelegeerd, het verzenden niet. Operationele meldingen aan onderaannemers vallen wél onder het vertrouwensmodel — de grens ligt bij de klant.
Inspecteerbaar, of het bestaat nietElk AI-aanraakpunt is afzonderlijk gedocumenteerd en kan aan- of uitgezet worden. Elke prompt is zichtbaar, met opbouw en tokenverbruik, en heeft een expliciete eigenaar. Er draait geen agent waarvan de werking niet kan worden nagekeken. Dat is niet omdat de wetgever het vraagt; het is omdat een systeem dat je niet kunt nakijken, een systeem is dat je niet kunt bijsturen.

Mailverwerking behandelt de inhoud van een afzender uitdrukkelijk als data, niet als instructie: een mail kan de regels van het systeem niet naspreken. Wie agentic AI op zijn inbox zet zonder die grens, heeft een lek gebouwd in plaats van een assistent.

Eerlijke grens

Wat dit ontwerp niet ondervangt

De controlelaag onderschept fout-positieven — een dubbele lead, een lege of herhaalde melding. Een gemiste beoordeling blijft mogelijk. De relevante vergelijking is echter niet die met foutloze detectie, maar met de situatie ervoor, waarin die controle helemaal niet bestond. AI vervangt hier geen bestaande controle; ze voegt er een toe waar er geen was.

Dat is meteen de manier waarop in elke organisatie over resultaten gesproken hoort te worden. Wie een cijfer noemt zonder te zeggen wat er precies gemeten is en wat het niet dekt, verkoopt iets.

Hoe de AI-poort in VediCore laag per laag is opgebouwd, lees je in VediCore als architectuur. Waar je zelf begint, staat op Hoe start je met AI in je bedrijf.

Contact

Vragen of reacties op de aanpak

Wie met deze aanpak aan de slag gaat en op een vraag stuit, of het ergens grondig mee oneens is: ik hoor het graag. Een methode wordt beter van tegenspraak.

dodeurs@gmail.com

of bel +32 478 544 682

The evidence

The seven failure causes in practice

The home page argues that none of the seven known causes of AI project failure is technical. That is not a finding from a report. All seven occurred in one company, with own money at stake — building VediCore, an AI-native SaaS ERP platform for the construction sector that is in production today.

What this is, and is not

One case instead of ten

What you get here.

Per failure cause: what actually occurred, the decision that followed, and where the limit of that decision lies. No abstractions. This is the one position in which you meet all seven at once and cannot point at anyone else: client, operator, architect, developer and owner in the same person.

What you do not get.

This is one company, and it is mine. This is not a portfolio of thirty AI engagements — nobody has one, the field is too young. If you are looking for a portfolio of references, look elsewhere. If you are looking for someone who has seen these seven work up close and had to make decisions on them, read on.

Fifteen years before that, the same seven appeared in ERP implementations, e-business platforms and reorganisations — they just were not called that, and the technology was different. Which is the whole point of this site: only the technology is new.

Failure cause 1

Technology looking for a problem

What usually happens: the project starts from a demo rather than a measured pain point.

The decisionThe programme did not start from technology but from a strategic mapping of the company's core activity — across the financial, customer, process and capacity perspectives. That exercise determined what the operation had to achieve, before any system was considered.
The order that followedPain points mapped explicitly on both sides of the chain: at the client and at the subcontractor. The design started from those pain points, not from the data that happened to be available. Processes were redesigned first and digitised second.
Why it mattersReverse that order and you digitise your existing inefficiency, then build it in permanently. That costs more than doing nothing.

Failure cause 2

The tool sits next to the work

What usually happens: no integration into the existing workflow, no memory, no improvement through use.

The situationThis is the sentence that recurs across this site, and this is where it comes from. The administration was not disorganised: a worked-out Excel model held nearly everything the platform holds today, and held it accurately. What it could not do was connect. It sat apart from the mail flow, apart from the photographs, apart from the signed dockets that travelled in the operators' vehicles and came back sometimes incomplete, sometimes illegible, sometimes not at all. The intelligence was there. The integration was missing.
The distinction that decides everythingUsing AI while building speeds up delivery, but disappears with delivery — that is scaffolding. AI-native means the intelligence is a permanent layer in the running system, with its own context, its own controls and its own cost transparency. VediCore was built both ways. The second is where the lasting value sits.
What that looks likeIncoming correspondence is automatically classified into twelve intents and attached to the right file, with draft replies ready. Signing happens digitally at the point of execution, by QR code or email — proof of work delivered no longer leaves the system.

Failure cause 3

Data not usable

What usually happens: quality or availability are not in order — according to Gartner the number one silent blocker.

In this case it was different, and that is instructiveThe problem was not data quality and not structure. Those were fine. It was connection: every link between the islands was made manually, repeatedly, by one person. Information once sent went stale in the recipient's inbox. A schedule shared two weeks ahead existed, at the moment of execution, only as a memory.
The design decisionOne file structure beneath all modules. The site is the passive, central location; the actual work lives in the leads and projects attached to it. What has been delivered, invoiced and paid are three states of one file — not three administrations to be reconciled.
What this means for another organisationThe first question to an organisation is therefore not data quality, but the number of places where the same fact is kept separately. That number predicts more.

Failure cause 4

No owner

What usually happens: an innovation team builds something the line organisation never adopts. In McKinsey's data, 48% of high performers see ownership at senior level, against 16% of the rest.

The decisionThe owner was the steering group. The system grew modularly and was in daily use throughout the entire build — there was no moment of "handover", because there was no gap to hand across.
Why that advantage does not transfer by itselfA company of fifteen people has an owner who decides, and that is an advantage. An organisation of four hundred does not, and pretending otherwise is precisely why consulting fails there. Which is why this site carries two approaches and not one.
What this means for another organisationThe question is not whether an owner has been appointed. The question is whether that owner can cancel something without asking permission. If not, he is not an owner but a reporter.

Failure cause 5

No baseline

What usually happens: without numbers from before the start every saving is an opinion — and then the budget stops. This is the one of the seven that cannot be backed with a figure from a single study; it is a practitioner's observation, and that deserves saying.

What was built inEvery model call logs tokens and cost. Budgets apply per day and per month, in euros, with an alert threshold and an automatic pause on overrun. Bulk work runs in batch at half cost. Consumption is a setting in advance, not a surprise afterwards.
Why that had to be there from day oneBecause "what is this AI actually costing" is a question that gets asked at the moment it can no longer be answered. Reconstruct cost per task afterwards and you reconstruct an estimate.
The hard version, for any organisationNo baseline, no pilot. If measuring genuinely is not possible, what is being given up should be stated — but it is not a recommended start.

Failure cause 6

Change underestimated

What usually happens: the centre of gravity is people and process, but the budget went to licences. McKinsey calculates that for every euro in technology, three belong in process redesign and five in capability and adoption — and that most companies invert the formula entirely.

Where it was underestimatedThe administration is fully paperless today. At the edge of the chain, a few subcontractors still sign on paper. Their dockets are digitised and reconciled on arrival, and that share is shrinking — but it is still there. That was never a technical problem.
What workedThe portals. The client sees the complete picture of his file at any moment — signed dockets, hours, invoicing, what is outstanding against the approved quote. The subcontractor sees the same principle on his side. There is one schedule, and everyone looks at the same view of it. Adoption follows when the new system gives the user something he did not have before.
The lessonChange does not succeed by convincing people your system is better. It succeeds by removing their own pain point. Which is why those pain points are mapped on both sides of the chain before anything is built.

Failure cause 7

Governance as an afterthought

What usually happens: security and legal arrive in week twelve and block the launch. In Deloitte's survey, 21% of organisations have a mature governance model for agentic AI, while 74% intend to deploy it by 2027.

Verification as a designed decision stepEvery proposed action passes a separately configured control model that compares the proposal against existing data, with four outcomes: proceed, skip, enrich, or refer to a human. Verification is not an assumption but a step in the design.
Autonomy is a setting, not a propertyAn automation can propose only; earn autonomy after a set number of approved executions; or run unsupervised. That choice is made per task, not per platform.
One boundary is fixedNo automation contacts a client on its own. Drafting is delegated, sending is not. Operational notifications to subcontractors do fall under the trust model — the boundary sits at the client.
Inspectable, or it does not existEvery AI touchpoint is documented separately and can be switched on or off. Every prompt is visible, with its construction and token consumption, and has an explicit owner. No agent runs whose behaviour cannot be reviewed. Not because the regulator asks for it, but because a system you cannot review is a system you cannot correct.

Mail processing treats a sender's content explicitly as data, not as instruction: an email cannot recite the system's rules back at it. Put agentic AI on your inbox without that boundary and you have built a leak rather than an assistant.

An honest limit

What this design does not catch

The control layer intercepts false positives — a duplicate lead, an empty or repeated notification. A missed judgement remains possible. The relevant comparison, though, is not with flawless detection but with the situation before, in which that control did not exist at all. AI does not replace an existing control here; it adds one where there was none.

That is also how results should be discussed in any organisation. Anyone quoting a number without saying what was measured and what it does not cover is selling something.

How the AI gate in VediCore is built, layer by layer, is set out in VediCore as architecture. Where to start yourself is on How to start with AI in your company.

Contact

Questions or comments on the approach

If you put this approach to work and run into a question — or disagree with something — I would like to hear it. A method gets better through challenge.

dodeurs@gmail.com

or call +32 478 544 682