Waarom digital twin-projecten mislukken en hoe je dat voorkomt

Disclosure: M365.FM host Mirko Peters works at iFAKT GmbH. This page describes the company factually; paid partnerships and links are labelled as advertising.

By Mirko Peters · 2026-11-11

Waarom digital twin-projecten mislukken: geen beslissing om te ondersteunen, slechte data, geen eigenaar en een te brede scope. Lees vijf oplossingen en een uitgewerkt voorbeeld voor fabrieksmanagers.

Automatically translated with AI from the original post. Read the English original

Waarom digital twin-projecten mislukken is vooral een managementvraag en geen softwarevraag. Typische oorzaken zijn: geen beslissing die van de twin afhangt, data waar niemand op vertrouwt, geen eigenaar voor het model en een scope die voor de eerste stap te breed is. Deze gids is bedoeld voor fabrieksmanagers die gevraagd zijn een digital twin te sponsoren, of die er een zien vastlopen. Je leert de vijf meest voorkomende faalpunten kennen, een uitgewerkt voorbeeld met cijfers, een routine om ze te vermijden en de fouten waar je op moet letten.

Belangrijkste punten

• Digital twin-projecten mislukken zelden door de software; ze mislukken omdat geen enkele beslissing van de twin afhangt, de data niet vertrouwd wordt of niemand eigenaar is van het model.
• Benoem voordat je begint de beslissing die de twin gaat veranderen, wie die neemt en wanneer. Kun je dat niet, dan is het project nog niet klaar om te starten.
• Controleer eerst de data: vind voor elk gegeven dat de twin nodig heeft de bron, de eigenaar, het updateritme en of twee systemen dezelfde waarde geven.
• Een twin is een levend model: zonder proces dat hem bijwerkt wanneer de fabriek verandert, loopt hij uit de pas met de werkelijkheid en stoppen mensen met gebruiken.
• Begin met één lijn en één beslissing, bewijs de waarde binnen weken, en breid daarna pas de scope uit.

Waarom digital twin-projecten mislukken: het korte antwoord

Een digital twin is een onderhouden digitale representatie van een fysiek object, die wordt bijgewerkt op basis van observaties, bijvoorbeeld met live data van machines bijna in real time. De belangrijke woorden zijn "onderhouden" en "actueel gehouden". Een digital twin is geen eenmalig model, en ook geen 3D-model of een verzameling CAD-bestanden van de fabriek. Het is een systeem dat trouw moet blijven aan de fabriek, en precies daar lopen projecten vast.

Meerdere bronnen beschrijven hetzelfde patroon. Een paper op de 2023 Winter Simulation Conference van Siyuan Chen en co-auteurs bespreekt de uitdagingen van digital twins in onderhoud in de maakindustrie. Ze delen die in in organisatorische uitdagingen, zoals bedrijfscultuur, hoge initiële kosten en angst voor banenverlies, methodologische uitdagingen, zoals onduidelijke voordelen en onduidelijke bedrijfsdoelstellingen, en technische uitdagingen, zoals het verzamelen van data van oude machines en interoperabiliteit. De studie is klein, met zes geïnterviewden uit de industrie, dus de auteurs stellen dat de bevindingen mogelijk niet voor alle bedrijven gelden.

Ook de softwareleveranciers zien hetzelfde. Simio, een leverancier van simulatiesoftware, stelt in een blogpost dat projecten vaker vastlopen op dataproblemen dan op technologie. Informatica, een leverancier van datamanagement, schrijft in zijn artikel over datafundamenten dat een twin zonder betrouwbare data beperkt is en misleidend kan zijn. Beide verkopen tools voor het dataprobleem, dus lees ze als één standpunt.

Op basis van deze bronnen en de gangbare projectpraktijk groeperen we de mislukkingen in vijf. Deze indeling is onze eigen samenvatting en geen standaard.

Faalpunt 1: geen enkele beslissing hangt af van de twin

De grootste uitdaging is dat niemand kan zeggen waarvoor de digital twin dient. "We willen een Industry 4.0-fabriek worden" is een richting, geen use case. Het Chen-paper noemt onduidelijke bedrijfsdoelstellingen en onduidelijke voordelen als methodologische uitdagingen, en het noemt het identificeren van use cases en het verkrijgen van commitment van het management als barrières.

Een eenvoudige test helpt. Stel de opdrachtgever één directe vraag: welke specifieke beslissing wordt er anders genomen, door wie en op welke datum, omdat deze twin bestaat? Goede antwoorden zijn concreet. "We kiezen in maart tussen een tweede ploeg en een nieuwe machine voor lijn 3." "We stellen de buffergroottes vast voordat de nieuwe indeling wordt gebouwd." Een zwak antwoord is "we krijgen beter zicht".

Als het antwoord vaag is, heeft het project geen stopsignaal. Het loopt door tot het budget op is, en dan kan niemand een resultaat laten zien.

Faalpunt 2: slechte datakwaliteit en een zwakke datafundering

Een digital twin is pas zo goed als zijn data. Simio noemt drie datproblemen, en die komen overeen met wat fabrieken in de praktijk tegenkomen:

• Ontbrekende data. Procestijden, beschikbaarheid van resources of kwaliteitsregistraties hebben gaten. Simio raadt aan te beginnen met op ervaring gebaseerde schattingen voor de kritische parameters, de aannames vast te leggen en na verloop van tijd echte data te verzamelen.
• Kwaliteitsproblemen. De data ziet er compleet uit, maar bevat uitschieters, tijdfouten of waarden die tussen systemen met elkaar in conflict zijn. Simio raadt validatieregels, geautomatiseerde controles op uitschieters en beoordeling door procesexperts aan.
• Integratieproblemen. De data zit in ERP-, MES- en kwaliteitssystemen die niet met elkaar communiceren. Simio raadt aan het werk te faseren, van geplande bestandsexports tot databasekoppelingen en later interfaces.

Informatica voegt master data en een datafundering toe. Zonder een betrouwbaar overzicht van assets, hun locatie, servicehistorie en kritikaliteit heeft een twin wel cijfers, maar weinig context, en werkt elke AI- of voorspellende functie daarop op een zwakke datalaag. Het artikel waarschuwt dat foute data kan leiden tot gemiste onderhoudsmeldingen of verkeerde bestellingen van reserveonderdelen.

Voor een fabriek is de praktische vorm van dit probleem eenvoudig. Registreert het manufacturing execution system dezelfde stilstandredenen als het onderhoudssysteem? Gebruiken beide dezelfde machine-identificatie? Komen de fysieke assets in het onderhoudsbeheersysteem overeen met de lijnen in het MES, en komen de cycletijden in het ERP overeen met wat de lijn daadwerkelijk draait? Als twee systemen het oneens zijn, kiest de digital twin er één, en dan komt men later erachter welke het verkeerd had.

Faalpunt 3: niemand is eigenaar van de data of het model

Een digital twin heeft twee soorten eigenaren, en beide ontbreken vaak. Elk datapunt heeft een eigenaar die kan zeggen of het correct is. Het model heeft een eigenaar nodig die het bijwerkt wanneer de fabriek verandert.

Het Chen-paper is hier duidelijk over. Het stelt dat organisatorische uitdagingen processen vereisen die zorgen voor regelmatige updates, en het beveelt aan het model bij te werken telkens wanneer het fysieke systeem verandert. Geïnterviewden benadrukten ook het belang van menselijke expertise bij het onderhouden, begrijpen en verifiëren van de resultaten van de twin. Een digital twin die niemand onderhoudt, is een momentopname. Na de eerste indelingswijziging of het eerste nieuwe product komt hij niet meer overeen met de fabriek, en de operators die dat opmerken, vertrouwen hem niet meer.

Hetzelfde paper merkt op dat de meeste respondenten digital twins alleen in de fase van digitale schaduw gebruiken. Een volledig verbonden, zichzelf bijwerkende twin is een langetermijndoel, en de eerste bruikbare versie is vaak een eenvoudiger model met een duidelijke eigenaar.

Faalpunt 4: de scope is te breed voor de eerste stap

De volgende valkuil is ambitie. Een digital twin-project dat begint met "de hele fabriek" moet data van elke lijn, elk systeem en elk team op elkaar afstemmen voordat er iets zichtbaar wordt. Het aantal datapunten groeit met elke lijn, en het aantal conflicten ook.

Een smalle scope, een digital twin-pilot op één lijn, brengt het model vroeg in contact met echte gebruikers. Eén lijn, één beslissing en één groep gebruikers zijn genoeg om te ontdekken of de data klopt en of mensen het antwoord gebruiken. Het Chen-paper noemt het verkrijgen van commitment van het management en het opbouwen van vertrouwen als barrières, en een snel, correct eerste resultaat helpt bij beide.

Faalpunt 5: het project wordt behandeld als een IT-project

Als IT of een externe partij het model alleen bouwt, komen de mensen die de fabriek kennen er pas laat bij. Zij ontdekken dan dat het model een handmatige stap, een gedeeld hulpmiddel of een informele regel negeert. Het Chen-artikel noemt bedrijfscultuur, communicatieproblemen en angst voor baanverlies als uitdagingen. Behandel het project als verandermanagement, met een meetbaar businesscase die de fabriek kan controleren, en laat operators, onderhoud en planning meedenken over wat het model laat zien.

Voorbeeld: controleer eerst één lijn voordat je opschaalt

Dit is een illustratieve berekening met aangenomen getallen, geen gemeten case. Een fabriek plant een digital twin voor 12 lijnen. Ze wil eerst beslissen over de buffergroottes voor de eerste lijn, dus vraagt de opdrachtgever om eerst een dataaudit van die lijn. De digital twin heeft per lijn 30 datapunten nodig, zoals cyclustijden, stilstandredenen en -duur, ordermix, bezetting en omsteltijden.

Het auditresultaat voor lijn 1:

• 11 items zijn beschikbaar en betrouwbaar.
• 9 items staan in twee systemen die elkaar tegenspreken, bijvoorbeeld stilstandredenen in het MES en in het onderhoudssysteem.
• 6 items staan alleen op papier of in de hoofden van de ploegleiders.
• 4 items bestaan helemaal niet.

Dus 19 van de 30 items vragen om werk, en slechts 11 van de 30, ongeveer 37 procent, is klaar.

Brede scope. Als de fabriek vergelijkbare getallen aanneemt voor alle 12 lijnen, dan vragen 12 × 19 = 228 items om werk. Neem als eigen planningsgetal aan dat één analist 5 items per week kan oplossen. Dan kost het datawerk 228 ÷ 5 = ongeveer 46 weken, bijna een jaar, voordat er een eerste resultaat is.

Smalle scope. De buffer-beslissing heeft slechts 12 van de 30 items nodig, en de audit laat zien dat 5 van die 12 problemen hebben. Bij 5 items per week is dat 1 week datawerk. Het eerste antwoord komt binnen weken, en het team leert welke dataproblemen het zwaarst wegen.

Jouw getallen zullen anders zijn, maar de audit laat zien in welke situatie je zit.

Hoe je mislukking voorkomt: een digital twin-pilot in zes stappen

1. Benoem de beslissing. Schrijf op welke beslissing de digital twin verandert, wie die neemt en voor welke datum.
2. Audit de data. Zoek voor elk item dat de digital twin nodig heeft de bron, de eigenaar, het updateritme en of twee systemen overeenkomen. Tel de gaten.
3. Wijs eigenaren aan. Eén persoon per datadomein en één persoon voor het model. Zet hun namen in het projectplan.
4. Begin smal. Eén lijn of één processtap, en alleen de datapunten die de beslissing nodig heeft.
5. Plan de updates. Bepaal hoe het model verandert wanneer de fabriek verandert, en wie die verandering activeert. Neem dit op in de uitrol, niet erna, en leg de werkwijze vast.
6. Toets tegen de beslissing. Controleer na enkele weken of de beslissing anders is genomen. Breid de scope alleen uit als het antwoord ja is.

Veelgemaakte fouten

• Het platform kopen voordat je de use case hebt benoemd. De tool vertelt je niet welke beslissing je moet nemen.
• De data vertrouwen omdat ze bestaan. Een waarde in een database is niet hetzelfde als een waarde die correct en actueel is.
• Twee systemen laten tegenspreken. De digital twin kiest er één zonder dat je het weet.
• Geen eigenaar na de go-live. Een digital twin zonder eigenaar is na de eerste wijziging verouderd.
• Beginnen met de hele fabriek. Het datawerk groeit sneller dan het voordeel, en digital twin-initiatieven verliezen hun opdrachtgever.
• De werkvloer buiten beschouwing laten. Als operators en onderhoudsmedewerkers de twin niet vertrouwen, gebruiken ze hem niet.

Hoe software kan helpen

De dataaudit en het model hebben allebei één consistente beschrijving nodig van producten, processtappen en middelen. iFAKT's Polaris Designer is een module van iFAKT Polaris die een product-proces-middelen (PPR) kennisgraaf bouwt als single source of truth voor producten, processtappen en middelen. Zo'n gedeelde beschrijving pakt het probleem van tegenstrijdige data aan, maar ze vervangt de beslissing, de eigenaren of de updateroutine niet. Software helpt zodra die er zijn.

Volgende stap

Kies voor het komende kwartaal één lijn en één beslissing, en vraag je team om de 10 tot 20 datapunten te auditen die die beslissing nodig heeft. Als de audit laat zien dat de meeste items niet klaar zijn, weet je voordat je het budget uitgeeft waarom digital twin-projecten mislukken, en weet je waar je moet beginnen.