Make or buy, industrial AI edition
Il tavolo delle decisioni
Nel percorso di digitalizzazione di ogni azienda tutti si sono trovati almeno una volta a decidere come gestire un progetto di innovazione. E immancabilmente si sarà presentata la domanda fatidica: make or buy?
Il CEO dice che l’importante è che il PBT sia sotto i 2 anni. Il CFO sottolinea che a budget si possono mettere al massimo 150k€ per l’anno, quindi di farseli bastare. L’IT manager dice che il suo team è già pieno e che non c’è modo di investire tempo interno in un progetto di quel genere. Il CIO dice che il panorama delle startup è in fermento e che ha conosciuto almeno 3 founder all’ultima fiera che potrebbero proporre una soluzione specifica per il loro problema. Il responsabile di produzione dice che va bene qualsiasi cosa, basta che si risolvano i problemi di produttività che sta registrando negli ultimi mesi.
Qual è la strada giusta?
Il Total Cost of Ownership
Nei framework tradizionali di make or buy l’indicatore che può supportare una scelta basata sui numeri è il Total Cost of Ownership (TCO), ovvero il costo totale di possesso.
Quando un responsabile IT o un CEO valuta una soluzione di analitica avanzata, la tentazione è quella di guardare il prezzo della licenza o il preventivo del progetto e basare la scelta principalmente su quel numero. Dopotutto licenza o costo di progetto rappresentano il costo visibile, quello che finisce effettivamente nel budget. Il problema è che rappresenta solo una parte minoritaria di quanto l’azienda spenderà realmente. Secondo Gartner, l’80% dei costi IT totali si accumula dopo l’acquisto iniziale.
Il TCO è lo strumento che permette di vedere il quadro completo. Non si tratta solo del prezzo di acquisto, ma di tutto ciò che una tecnologia costa nel corso del suo ciclo di vita: l’integrazione con i sistemi esistenti (MES, SCADA, ERP), la formazione del personale, la manutenzione nel tempo, i costi infrastrutturali, e i costi di uscita quando si decide di cambiare soluzione. Un’analisi TCO ben fatta aiuta a distinguere i costi a breve termine da quelli a lungo termine e a fare scelte più informate tra alternative diverse.
Strutturare un TCO per i progetti IT
Il modello canonico divide i costi in CapEx (acquisizione) e OpEx (operatività), più manutenzione, fine vita e fattori di rischio. Per i progetti IT, Gartner include anche le spese indirette degli utenti finali – ad esempio formazione, errori dovuti all’utilizzo errato della soluzione – e il mancato guadagno o produttività legati al downtime di linea – ad esempio per interventi di installazione sensori, oppure per problemi di monitoraggio e allarmistica.
Applicato all’AI industriale, il TCO classico ha però un limite strutturale: non cattura alcune voci di costo che sono specifiche dei modelli predittivi. Un modello non è un software statico, degrada nel tempo quando le condizioni del processo cambiano, e richiede retraining periodico. I dati industriali reali spesso arrivano rumorosi, incompleti, mal etichettati: la loro pulizia e preparazione ha un costo che raramente compare nei preventivi. E quando la soluzione è un SaaS di un fornitore esterno, il costo del lock-in – cioè il prezzo implicito di dipendere da un unico attore per un processo critico – è quasi sempre ignorato, anche se può diventare determinante dopo due o tre anni di utilizzo.
| Categoria | Voci tipiche | Timeline |
|---|---|---|
| CapEx – Acquisizione | Licenza / sviluppo, hardware, integrazione con sistemi esistenti, installazione | Anno 0 |
| CapEx – Avvio | Migrazione dati, formazione iniziale, consulenza di implementazione, project management | Anno 0–1 |
| OpEx – Operatività | Licenze ricorrenti (SaaS), infrastruttura cloud/edge, energia, personale dedicato | Ogni anno |
| OpEx – Manutenzione | Supporto tecnico, aggiornamenti, patch, upgrade | Ogni anno |
| OpEx – Retraining e monitoraggio | Riaddestramento del modello, manutenzione periodica, monitoraggio e MLops | Ogni anno |
| Costi indiretti | Downtime durante deployment, produttività persa durante l’adozione, copertura dei ruoli distolti dal progetto, errori e rilavorazioni | Anno 0–1 |
| Costi di compliance | Adeguamento normativo, audit, documentazione | Ricorrente |
| Costi di uscita | Migrazione dati a nuova piattaforma, decommissioning del sistema legacy, riqualificazione del personale | Fine ciclo di vita |
| Costo del dato | Preparazione dei dati (pulizia, etichettatura, strutturazione) – in ambito industriale è particolarmente rilevante perché i dati di processo arrivano da sistemi eterogenei (PLC, SCADA, MES) con formati e qualità molto diversi. | Anno 0–1 |
| Costo del lock-in | Dipendenza da un unico fornitore (vulnerabilità, disponibilità futura degli aggiornamenti). Nell’AI industriale questo rischio è amplificato: se il fornitore cambia modello di pricing o viene acquisito, non hai le competenze interne per sostituirlo rapidamente. | Ogni anno |
Queste voci sono da calcolare per ognuno degli scenari ipotizzati, cercando di quantificare i costi collegati in modo razionale. Anche perché se il framework classico è binario, la realtà è molto più sfaccettata. Nelle soluzioni IT e soprattutto nelle soluzioni di modellazione industriale e AI l’outsourcing è infatti un’opzione molto battuta.
Make, buy and…
La matrice decisionale diventa quindi a tre colonne, non due. E si aggiunge una variabile critica: chi mantiene la conoscenza nel tempo?
| Aspetto | Make | Outsource | Buy |
|---|---|---|---|
| Personalizzazione | Massima | Alta | Bassa/media |
| Time-to-value | Lento | Medio | Rapido |
| Costo iniziale | Alto (team) | Medio-alto (progetto) | Basso-medio (licenza) |
| Competenza residua interna | Alta | Dipende dalla tipologia del contratto | Quasi nulla |
| Rischio lock-in | Basso | Alto (fornitore unico) | Alto (piattaforma) |
| Proprietà del modello | Tua | Tua (se contratto corretto) | Del fornitore |
L’outsourcing è molto delicato. Se gestito male, il rischio che le competenze residue interne siano molto limitate è importante. Meno competenze significa meno capacità di manutenere modelli e le soluzioni e quindi più costi per garantire il funzionamento e l’affidabilità
Nello scenario dell’outsourcing, le competenze possono però essere internalizzate tramite contratti di outsource con trasferimento di competenze, cioè un progetti esterni pensati esplicitamente per insegnare all’interno mentre si costruisce. È più costoso a breve termine ma è un modo per uscire dalla dipendenza strutturale, imparando cosa fare quando il modello perde precisione o i dati cambiano forma.
Costruire i costi
Con tre opzioni aumenta la flessibilità ma potenzialmente anche la complessità di decisione. Il rischio reale è scegliere in base al budget disponibile o all’entusiasmo del fornitore di turno, invece che sulla base di una valutazione strutturata. Per orientarsi però non serve un framework per forza complicato, basta mappare le domande giuste nell’ordine giusto.
Passo 1: Verifica le condizioni abilitanti. Prima di confrontare costi, chiediti se hai i prerequisiti minimi per ciascuna opzione.
- Il Make richiede dati storici di processo sufficienti, almeno una figura interna con competenze analitiche di base e un orizzonte temporale di almeno 12-18 mesi prima di vedere risultati.
- Il Buy richiede che il tuo caso d’uso sia sufficientemente standard da essere coperto da una soluzione esistente.
- L’Outsource richiede la capacità di scrivere un capitolato tecnico e di validare il lavoro consegnato, il che implica una minima competenza interna anche se non costruisci tu. Se mancano le condizioni abilitanti, quella strada è bloccata a prescindere.
Passo 2: Costruisci il TCO comparativo su 5 anni. Compila ogni voce mappata per stimare i costi di ogni scenario percorribile.
Tre avvertenze pratiche:
- includi sempre il costo del dato (spesso sottostimato del 40-60% nei progetti AI industriali)
- non dimenticare il costo opportunità del downtime durante il deployment
- nel Buy, aggiungi esplicitamente una voce di rischio lock-in pari almeno al 15-20% della licenza annua a partire dal terzo anno, quando la sostituzione diventa strutturalmente costosa.
Passo 3: Applica i moltiplicatori strategici. Il TCO da solo non basta perché non cattura il valore di ciò che impari. Se il processo su cui stai applicando l’AI è differenziante per il tuo vantaggio competitivo, la competenza residua interna vale più del risparmio a breve termine. Se invece è un processo standard di settore, come baseline energetiche o anomaly detection su linee convenzionali, il Make è quasi sempre inefficiente rispetto a soluzioni verticali già mature.
Ma come procedere nel concreto?
Caso A – PMI metalmeccanica, predictive maintenance su un impianto di pressofusione
Il caso d’uso è standard, il fornitore verticale dispone di modelli pre-addestrati su asset simili e il budget è compatibile. L’unica cautela contrattuale: verificare che il contratto includa l’accesso ai propri dati di processo in formato esportabile, per non trovarsi in lock-in totale al momento del rinnovo.
Buy senza esitazione. Il caso d’uso è standard, il fornitore verticale ha già modelli pre-addestrati su asset simili, il budget è compatibile. L’unica cautela: verificare che il contratto includa l’accesso ai propri dati di processo in formato esportabile, per non trovarsi in lock-in totale al momento del rinnovo.
Caso B – Produttore di componenti automotive, controllo qualità visivo su linea di assemblaggio
Il differenziale di costo rispetto al Buy (3.000€ sul triennio) è trascurabile: la vera differenza è che al termine del progetto il modello appartiene all’azienda e il team interno sa gestire il retraining autonomamente. Condizione necessaria: il contratto deve includere esplicitamente trasferimento di competenze, documentazione del modello e accesso ai dati di training. Senza queste clausole, il Buy diventa preferibile.
La conclusione per questo caso è outsource, ma solo con un contratto ben strutturato che includa esplicitamente il trasferimento di competenze, la documentazione del modello e l’accesso ai dati di training. Il differenziale di costo rispetto al Buy (27.000€ sul triennio) è compensato dalla competenza residua e dall’eliminazione del rischio lock-in su un processo critico per la soddisfazione del cliente automotive. Se il contratto non garantisce il trasferimento di competenze, il Buy diventa preferibile.
Caso C – Gruppo industriale mid-size, ottimizzazione energetica su più stabilimenti
Il Buy puro è la soluzione più economica a breve, ma produce raccomandazioni generiche che richiedono comunque competenze interne per diventare azioni concrete. Il differenziale di costo dell’ibrido (53.000€ sul triennio) compra un patrimonio di modelli proprietari e un data scientist che cresce con l’azienda. Condizione: il data scientist interno deve diventare il punto di connessione tra piattaforma acquistata e modelli sviluppati — altrimenti si paga due volte senza integrare nulla.
In questo caso l’opzione migliore prevede un approccio ibrido strutturato. Buy per il monitoraggio e il reporting (commodity, già risolta dal mercato), Make per i modelli di ottimizzazione sui processi specifici dove il dato proprietario fa la differenza. Il data scientist interno diventa il punto di connessione tra la piattaforma acquistata e i modelli sviluppati internamente. Il TCO dell’ibrido si attesta intorno a 290.000€ sul triennio — più costoso del Buy puro nel breve periodo, ma con un patrimonio di competenze e modelli che appartiene all’azienda e cresce nel tempo.
Ridurre il rischio spiando nel futuro
La brutta abitudine dei progetti di AI in industria è che non sono sempre deterministici, anzi. I dati non sono della qualità attesa, i modelli non raggiungono la precisione desiderata, gli allarmi sono meno spiegabili di quanto si pensasse, la soluzione sembrava allineata ma poi necessita di personalizzazioni… Come si fa a ridurre il rischio delle assunzioni in anticipo?
PoC, MVP e altre sigle utili
Il Proof of Concept (PoC) e il Minimum Viable Product (MVP) non sono voci del TCO, ma rappresentano fasi preliminari che riducono il rischio del TCO stesso.
Senza questi, il TCO che costruisci è pieno di assunzioni non verificate: il modello raggiungerà quella precisione, i dati sono sufficienti, l’integrazione è fattibile nei tempi stimati. Ognuna di queste assunzioni può far esplodere i costi reali rispetto a quelli stimati.
Con un PoC ben strutturato, il TCO diventa più affidabile perché le incognite tecniche principali vengono eliminate prima di impegnare il budget pieno e scegliere una strategia per i successivi 5 anni. Una struttura sensata è questa:
- PoC (4-8 settimane, budget separato e limitato): verifica la fattibilità tecnica. Output: go/no-go sulla direzione, prima stima calibrata del TCO reale.
- MVP (3-6 mesi): verifica la fattibilità operativa su scala ridotta. Output: dati reali su costi di integrazione, adoption rate, accuratezza in produzione. A questo punto il TCO può essere ricalcolato con un margine di errore molto inferiore.
- Scelta strutturale: solo qui ha senso fare il confronto make/buy/outsource con numeri credibili.
Se il PoC è eseguito da un fornitore esterno, assicurati che dati e risultati rimangano patrimonio dell’azienda — indipendentemente dalla scelta successiva.
Chi impara dal PoC?
Il PoC introduce una variabile che nel framework classico non esiste: chi lo fa e a che condizioni. Quando fai un PoC, inevitabilmente qualcuno impara tre cose preziose: come sono fatti i tuoi dati realmente, dove sono i colli di bottiglia del tuo processo, e quali approcci tecnici funzionano e quali no su quel problema specifico.
Se lo fa un tuo tecnico interno, quella conoscenza resta in azienda e diventa un asset. Quando poi vai a fare la scelta strutturale, sei un acquirente informato: sai cosa chiedere, sai valutare le proposte, sai riconoscere le promesse irrealistiche.
Se lo fa un fornitore esterno, quella conoscenza va a lui. Non necessariamente in malafede, semplicemente è così che funziona: chi lavora sul problema lo capisce meglio di chi lo commissiona. Il rischio concreto è che si arrivi alla scelta strutturale con un fornitore che conosce il tuo problema meglio di te, e che ha già un prototipo funzionante. La trattativa è asimmetrica. Non è sempre sbagliato – un fornitore verticale specializzato porta competenza che non hai – ma devi essere consapevole che il PoC fatto dal fornitore contiene un bias verso la propria soluzione.
In entrambi i casi vale comunque una regola d’oro: il PoC dovrebbe essere pagato e controllato dall’azienda, anche se eseguito da un fornitore. Questo garantisce che i dati, i risultati e le lezioni apprese rimangano patrimonio interno, indipendentemente dalla scelta successiva.
Risposte giuste a domande sbagliate
Costruire o comprare è la domanda sbagliata con cui iniziare. La domanda giusta è: cosa so davvero del mio problema, dei miei dati e delle mie capacità interne? Questo post serve a stimolare le domande nell’ordine giusto.
Nel percorso di decisione ecco i cinque aspetti da non dimenticare:
- Il prezzo non è il costo. La licenza o il preventivo del progetto rappresentano mediamente il 20% di quanto spenderai realmente. Prima di approvare qualsiasi budget AI, costruisci almeno una stima di TCO a tre anni che includa integrazione, formazione, manutenzione del modello e costi di uscita. Se non riesci a farlo, è un segnale che non hai ancora abbastanza informazioni per decidere.
- Le opzioni non sono due, sono tre. Make, Buy e Outsource hanno profili di rischio completamente diversi. L’outsourcing non è la via di mezzo sicura che sembra: senza clausole esplicite su proprietà del modello, accesso ai dati e trasferimento di competenze, stai pagando qualcuno per imparare il tuo processo meglio di quanto tu impari l’AI.
- Il PoC è quasi sempre un prerequisito. Un TCO costruito senza aver verificato la fattibilità tecnica sul tuo dato reale è pieno di assunzioni non verificate. Quattro-otto settimane e 15.000-30.000€ di PoC possono salvare 200.000€ di progetto sbagliato. Mi raccomando però, se il PoC lo fa un fornitore esterno, assicurati che i risultati restino tuoi.
- La competenza interna è un asset, non una voce di costo. Ogni progetto AI che lascia tutta la conoscenza fuori dall’azienda crea dipendenza strutturale. Nel breve termine sembra più economico. Nel medio termine è la ragione per cui molte aziende pagano rinnovi che non possono permettersi di non fare.
- Il caso d’uso standard non merita un progetto custom. Se esistono già soluzioni verticali mature che funzionano, ha senso usarle. Meglio riservare il Make o l’outsourcing con trasferimento di competenze ai processi dove il dato proprietario è davvero differenziante e internalizzare la competenza è centrale.
