Perché i progetti di digital twin falliscono e come evitarlo

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

Perché i progetti di digital twin falliscono: nessuna decisione da supportare, dati scadenti, nessun responsabile e ambito troppo ampio. Scopri cinque correttivi e un esempio pratico per i responsabili di stabilimento.

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

Perché i progetti di digital twin falliscono è soprattutto una questione di gestione, non di software. Le cause tipiche sono l'assenza di una decisione che dipenda dal twin, dati di cui nessuno si fida, nessun responsabile del modello e un ambito troppo ampio per il primo passo. Questa guida è pensata per i responsabili di stabilimento a cui è stato chiesto di sponsorizzare un digital twin o che hanno visto un progetto arenarsi. Scoprirai i cinque punti di fallimento più comuni, un esempio pratico con i numeri, una routine per evitarli e gli errori a cui prestare attenzione.

Punti chiave

• I progetti di digital twin raramente falliscono per colpa del software: falliscono perché nessuna decisione dipende dal twin, i dati non sono affidabili o nessuno è responsabile del modello.
• Prima di iniziare, definisci la decisione che il twin dovrà cambiare, chi la prende e entro quando. Se non riesci a farlo, il progetto non è ancora pronto.
• Verifica prima i dati: per ogni elemento di cui il twin ha bisogno, individua la fonte, il responsabile, la frequenza di aggiornamento e se due sistemi concordano tra loro.
• Un twin è un modello vivo: senza un processo che lo aggiorni quando lo stabilimento cambia, si allontana dalla realtà e le persone smettono di usarlo.
• Parti da una sola linea e da una sola decisione, dimostra il valore in poche settimane e solo dopo allarga l'ambito.

Perché i progetti di digital twin falliscono: la risposta breve

Un digital twin è una rappresentazione digitale mantenuta di una risorsa fisica, aggiornata a partire dalle osservazioni, per esempio con dati in tempo quasi reale provenienti dai macchinari. Le parole importanti sono «mantenuta» e «aggiornata». Un digital twin non è un modello una tantum, né un modello 3D o un insieme di file CAD dello stabilimento. È un sistema che deve restare fedele allo stabilimento reale, ed è proprio qui che i progetti si rompono.

Diverse fonti descrivono lo stesso schema. Un articolo della Winter Simulation Conference 2023, firmato da Siyuan Chen e coautori, analizza le sfide dei digital twin nella manutenzione manifatturiera. Le raggruppa in sfide organizzative, come la cultura aziendale, gli elevati costi iniziali e il timore di perdere il lavoro, sfide metodologiche, come benefici e obiettivi di business poco chiari, e sfide tecniche, come l'acquisizione dei dati da macchinari legacy e l'interoperabilità. Lo studio è di dimensioni ridotte, con sei intervistati del settore, quindi gli autori precisano che i risultati potrebbero non rappresentare tutte le aziende.

I fornitori di software dicono la stessa cosa dal loro punto di vista. Simio, un fornitore di soluzioni di simulazione, sostiene in un post del blog che i progetti si bloccano più spesso per problemi di dati che per la tecnologia. Informatica, un fornitore di gestione dei dati, scrive nel suo articolo sulle basi dei dati che un twin privo di dati affidabili è limitato e può portare fuori strada. Entrambi vendono strumenti per il problema dei dati, quindi leggi le loro posizioni come un unico punto di vista.

Partendo da queste fonti e dalla pratica comune nei progetti, raggruppiamo i fallimenti in cinque categorie. Questa classificazione è una nostra sintesi, non uno standard.

Fallimento 1: nessuna decisione dipende dal twin

La sfida più grande è che nessuno sa dire a cosa serva il digital twin. "Vogliamo essere uno stabilimento Industria 4.0" è una direzione, non un caso d'uso. Il paper di Chen elenca obiettivi di business poco chiari e benefici poco definiti tra le sfide metodologiche, e tra le barriere include l'identificazione dei casi d'uso e l'ottenimento dell'impegno della direzione.

Un test semplice aiuta. Fai al promotore una sola domanda diretta: quale decisione specifica verrà presa in modo diverso, da chi e entro quale data, perché questo twin esiste? Le risposte buone sono concrete. "Sceglieremo tra un secondo turno e una nuova macchina per la linea 3 a marzo." "Definiremo le dimensioni dei buffer prima che venga costruito il nuovo layout." Una risposta debole è "avremo una migliore visibilità".

Se la risposta è vaga, il progetto non ha un segnale di arresto. Andrà avanti finché finisce il budget, e a quel punto nessuno saprà mostrare un risultato.

Errore 2: dati di scarsa qualità e una base dati debole

Il digital twin vale quanto i suoi dati. Simio individua tre problemi legati ai dati, che corrispondono a ciò che riscontrano gli stabilimenti:

• Dati mancanti. I tempi di processo, la disponibilità delle risorse o i registri di qualità presentano lacune. Simio suggerisce di iniziare con stime basate sull'esperienza per i parametri critici, registrando le ipotesi e raccogliendo dati reali nel tempo.
• Problemi di qualità. I dati sembrano completi, ma contengono valori anomali, errori di temporizzazione o valori in conflitto tra i vari sistemi. Simio suggerisce regole di validazione, controlli automatici sui valori anomali e la revisione da parte di esperti di processo.
• Problemi di integrazione. I dati si trovano in ERP, MES e sistemi di qualità che non comunicano tra loro. Simio suggerisce di procedere per fasi, dalle esportazioni pianificate di file ai collegamenti ai database, fino alle interfacce successive.

Informatica aggiunge i dati master e una base dati solida. Senza un registro affidabile di asset, della loro ubicazione, dello storico di manutenzione e della criticità, un twin ha numeri ma poco contesto, e qualsiasi funzione di AI o di previsione costruita sopra lavora su un livello di dati debole. L'articolo avverte che dati sbagliati possono causare avvisi di manutenzione mancati o ordini errati di ricambi.

Per uno stabilimento, la forma pratica di questo problema è semplice. Il sistema di esecuzione della produzione registra gli stessi motivi di fermo del sistema di manutenzione? Entrambi usano lo stesso identificativo macchina? Gli asset fisici nel sistema di gestione della manutenzione corrispondono alle linee nel MES, e i tempi ciclo nell'ERP corrispondono a ciò che la linea esegue davvero? Se due sistemi non concordano, il digital twin ne sceglierà uno, e le persone scopriranno più tardi quale dei due era sbagliato.

Errore 3: nessuno è responsabile dei dati o del modello

Un digital twin ha due tipi di responsabili, e spesso mancano entrambi. Ogni dato deve avere un responsabile in grado di dire se è corretto. Il modello deve avere un responsabile che lo aggiorni quando cambia lo stabilimento.

Il paper di Chen è chiaro su questo punto. Afferma che le sfide organizzative richiedono processi che garantiscano aggiornamenti regolari, e raccomanda di aggiornare il modello ogni volta che cambia il sistema fisico. Gli intervistati hanno inoltre sottolineato l'importanza della competenza umana nel mantenere, comprendere e verificare i risultati del twin. Un digital twin che nessuno manutiene è una fotografia del momento. Dopo il primo cambio di layout o il primo nuovo prodotto, non corrisponde più allo stabilimento, e gli operatori che se ne accorgono smettono di fidarsi.

Lo stesso paper osserva che la maggior parte degli intervistati usa i digital twin solo allo stadio di digital shadow. Un twin completamente connesso e auto-aggiornante è un obiettivo di lungo periodo, e la prima versione utile è spesso un modello più semplice con un responsabile chiaro.

Errore 4: il perimetro è troppo ampio per il primo passo

Il successivo scoglio è l'ambizione. Un progetto di digital twin che parte da "l'intero stabilimento" deve riconciliare dati da ogni linea, ogni sistema e ogni team prima di mostrare qualsiasi cosa. Il numero di dati cresce con ogni linea, e così anche il numero di conflitti.

Un perimetro ristretto, un pilota di digital twin su una sola linea, porta il modello davanti a utenti reali fin dall'inizio. Una linea, una decisione e un gruppo di utenti bastano per capire se i dati reggono e se le persone usano la risposta. Il paper di Chen elenca tra le barriere l'ottenimento dell'impegno della direzione e la costruzione della fiducia, e un primo risultato rapido e corretto aiuta in entrambi i casi.

Errore 5: il progetto viene trattato come un progetto IT

Se IT o un team esterno costruisce il modello da solo, le persone che conoscono l'impianto entrano in gioco tardi. Scoprono che il modello ignora un passaggio manuale, uno strumento condiviso o una regola informale. Il paper di Chen elenca tra le sfide la cultura aziendale, i problemi di comunicazione e la paura di perdere il lavoro. Tratta il progetto come un change management, con un business case misurabile che l'impianto possa verificare, e lascia che operatori, manutenzione e pianificazione contribuiscano a definire ciò che il modello mostra.

Esempio: verifica i dati di una linea prima di scalare

Questo è un calcolo illustrativo con numeri ipotetici, non un caso misurato. Un impianto pianifica un gemello digitale per 12 linee. Vuole decidere le dimensioni dei buffer per la prima linea, quindi lo sponsor chiede prima un audit dei dati di quella linea. Il gemello digitale richiede 30 elementi di dati per linea, come tempi ciclo, motivi e durate dei fermi, mix di ordini, personale e tempi di cambio formato.

Il risultato dell'audit per la linea 1:

• 11 elementi sono disponibili e affidabili.
• 9 elementi esistono in due sistemi che non concordano, per esempio i motivi dei fermi nel MES e nel sistema di manutenzione.
• 6 elementi esistono solo su carta o nella testa dei capiturno.
• 4 elementi non esistono affatto.

Quindi 19 elementi su 30 richiedono interventi, e solo 11 su 30, circa il 37 per cento, sono pronti.

Ambito ampio. Se l'impianto ipotizza numeri simili per tutte le 12 linee, 12 × 19 = 228 elementi richiedono interventi. Ipotizziamo, come cifra di pianificazione nostra, che un analista riesca a sistemare 5 elementi a settimana. Il lavoro sui dati richiede quindi 228 ÷ 5 = circa 46 settimane, quasi un anno, prima del primo risultato.

Ambito ristretto. La decisione sui buffer richiede solo 12 dei 30 elementi, e l'audit mostra che 5 di quei 12 presentano problemi. A 5 elementi a settimana, sono 1 settimana di lavoro sui dati. La prima risposta arriva in poche settimane, e il team capisce quali problemi di dati pesano di più.

I tuoi numeri saranno diversi, ma l'audit mostra in quale situazione ti trovi.

Come evitare il fallimento: un pilota di gemello digitale in sei passi

1. Definisci la decisione. Scrivi quale decisione cambia grazie al gemello digitale, chi la prende e entro quale data.
2. Verifica i dati. Per ogni elemento di cui il gemello digitale ha bisogno, individua la fonte, il responsabile, la frequenza di aggiornamento e se due sistemi concordano. Conta le lacune.
3. Assegna i responsabili. Una persona per ogni dominio di dati e una persona per il modello. Inserisci i loro nomi nel piano di progetto.
4. Parti in piccolo. Una linea o una fase di processo, e solo gli elementi di dati che la decisione richiede.
5. Pianifica gli aggiornamenti. Stabilisci come cambia il modello quando cambia l'impianto e chi lo avvia. Includilo nel rilascio, non dopo, e documenta il flusso di lavoro.
6. Verifica rispetto alla decisione. Dopo alcune settimane, controlla se la decisione è stata presa in modo diverso. Amplia l'ambito solo quando la risposta è sì.

Errori comuni

• Acquistare la piattaforma prima di definire il caso d'uso. Lo strumento non ti dice quale decisione prendere.
• Fidarsi dei dati solo perché esistono. Un valore presente in un database non equivale a un valore corretto e aggiornato.
• Lasciare che due sistemi siano in disaccordo. Il gemello digitale ne sceglierà uno senza dirtelo.
• Nessun responsabile dopo il go-live. Un gemello digitale senza responsabile è obsoleto già dopo la prima modifica.
• Iniziare con tutto l'impianto. Il lavoro sui dati cresce più in fretta del beneficio, e le iniziative di gemello digitale perdono il loro sponsor.
• Escludere il reparto produttivo. Se operatori e personale di manutenzione non si fidano del gemello, non lo useranno.

Come può aiutare il software

Sia l'audit dei dati sia il modello hanno bisogno di una descrizione unica e coerente di prodotti, fasi di processo e risorse. Polaris Designer di iFAKT è un modulo di iFAKT Polaris che costruisce un grafo di conoscenza prodotto-processo-risorsa (PPR) come unica fonte di verità per prodotti, fasi di processo e risorse. Una descrizione condivisa come questa risolve il problema dei dati in conflitto, ma non sostituisce la decisione, i responsabili o la routine di aggiornamento. Il software aiuta una volta che questi elementi sono già al loro posto.

Prossimo passo

Scegli una linea e una decisione per il prossimo trimestre, e chiedi al tuo team di verificare i 10-20 elementi di dati che quella decisione richiede. Se l'audit mostra che la maggior parte degli elementi non è pronta, hai scoperto perché i progetti di gemello digitale falliscono prima di spendere il budget, e sai da dove iniziare.