Il team operativo ha identificato il gap. Il software esistente non lo colmerà. Build o buy? Questa impostazione manca l’unico percorso che chiude il gap in questo trimestre.

TL;DR

Cosa sta chiedendo davvero chi acquista

La domanda “build vs buy” emerge dopo che il responsabile operativo ha identificato un gap specifico: quell’impostazione è sbagliata. Entrambi i percorsi si misurano in trimestri; il gap costa margine a ogni turno. Il framework decisionale necessario ha tre percorsi con criteri concreti per ciascuno.

Il gap era già stato identificato prima che arrivasse la domanda build-vs-buy

Il gap è reale. Un’azienda di climatizzazione non riesce ad aggiornare automaticamente gli ordini di lavoro dai messaggi dei tecnici. Un operatore 3PL non riesce a riconciliare in tempo reale lo stato dei ricambi sul veicolo. Un proprietario di flotta non riesce a collegare i fermi macchina ai dati telematici. L’operatore ha chiesto software all’IT, e l’IT ha chiesto agli acquisti. Gli acquisti hanno chiesto: build o buy?

Perché il binario è l’impostazione sbagliata

Entrambi i percorsi si estendono su trimestri. Il gap costa margine ogni settimana. Un framework decisionale con tre percorsi e criteri chiari per ciascuno è superiore a una tabella pro e contro tra due opzioni. Il binario salta l’unico percorso costruito per il gap tra ciò che il vendor SaaS distribuirà in 24 mesi e ciò che lo sviluppo interno non può finanziare quest’anno.

Cosa offre davvero il Buy nel 2026

Per workflow strutturati e ripetibili, il SaaS maturo distribuisce più velocemente di qualsiasi team interno. I team di field service su un FSM, le flotte veicolari su un FMS di livello telematico, gli impianti su ERP+EAM ne beneficiano tutti. Per il lavoro off-system che determina FTFR, MTTR e margine, la risposta del vendor è sempre “è nella roadmap”, da 18 a 24 mesi, non in questo trimestre.

Dove il SaaS vince senza discussioni

Ciò che il tuo FSM non copre è il 60% off-system della realtà operativa. Pianificazione, dispatch, ordini di lavoro mobile, registro asset, pianificazione percorsi, fatturazione: il SaaS maturo distribuisce queste funzionalità più velocemente e a costo inferiore rispetto ai team interni, e l’FSM funziona. L’FMS funziona. Lo stack ERP+EAM funziona per ciò per cui è stato costruito.

Dove la roadmap del vendor si esaurisce

Per il segnale off-system che influenza FTFR, MTTR, OEE e margine contrattuale, la risposta del vendor arriva sempre uguale: è nella roadmap, da 18 a 24 mesi. Il pricing per seat significa pagare un tetto che il responsabile operativo ha raggiunto da tempo. La ricerca State of Service di Salesforce, basata su oltre 5.500 professionisti del servizio, ha rilevato che i lavoratori mobili perdono più di sette ore a settimana in attività amministrative che il sistema avrebbe dovuto assorbire. Come la telematica delle flotte ha raggiunto il suo tetto è la stessa storia in tutti i settori verticali. I costi di switching si accumulano quanto più a lungo dura il gap nella roadmap.

Cosa costa davvero il Build nel 2026

Team minimo: 1 PM a tempo pieno, 2-3 ingegneri senior, 1 designer, supporto DevOps. Questo equivale a un TCO totale tra $1,5M e $5M per la v1 di un singolo workflow. Da nove a diciotto mesi per la distribuzione. Uno su sei dei progetti IT analizzati ha registrato uno sforamento dei costi del 200% in media e uno sforamento dei tempi di quasi il 70%. Il responsabile operativo che attende lo sviluppo interno compete per la capacità contro le funzionalità che generano ricavi.

Il vero organico e la timeline reale per un singolo workflow

Un workflow non banale (integrazione dispatch, riconciliazione ricambi, manutenzione predittiva) richiede un PM per definire l’ambito, due o tre ingegneri senior, un designer per l’UX e supporto DevOps per la pipeline. Questo corrisponde a un costo totale tra $1,5M e $5M e da nove a diciotto mesi per la v1 in una tech company di medie dimensioni, in linea con la ricerca McKinsey che mostra come i grandi progetti IT consegnino il 56% di valore in meno rispetto alle previsioni.

Il costo nascosto che la maggior parte degli sponsor interni non riconosce

Il vero costo non è il budget. È il gap che continua a funzionare off-system per diciotto mesi. Ogni mese in cui il workflow vive su WhatsApp è un mese di fermo macchina evitabile, obiettivi FTFR mancati, lavoro manuale. Il responsabile operativo compete per la capacità di sviluppo interno contro le funzionalità di ricavo trimestrale. La ricerca McKinsey su oltre 5.400 progetti IT, condotta con la University of Oxford, ha rilevato che i grandi progetti IT sforano il budget del 45% e i tempi del 7% in media, consegnando il 56% di valore in meno rispetto alle previsioni.

Quando il Buy vince ancora

Workflow commodity: tutto ciò che FSM/FMS/ERP/EAM già distribuisce a maturità. Pianificazione, dispatch, ordini di lavoro mobile, pianificazione percorsi, fatturazione, registro asset: acquistalo. I workflow di back-office e HR senza varianti sul campo sono quasi sempre più veloci ed economici come SaaS. Se il requisito è “abbiamo solo bisogno di ciò che hanno tutti gli altri”, il terzo percorso non è adatto a questo ambito.

Quando il Build vince ancora

Un sistema di record greenfield che richiede un modello dati personalizzato fin dal primo giorno esige uno sviluppo interno vero e proprio. Questi progetti richiedono capacità di sviluppo completa e timeline pluriennali. I dati regolamentati o sovrani che non possono uscire dal firewall devono rimanere in-house. Lo stesso vale per i workflow che SONO il vantaggio competitivo. I programmi di trasformazione digitale pluriennali in cui l’intero stack tecnologico viene ricostruito sono adatti agli sviluppi interni. Non lo sono per un gap di singolo workflow che deve essere chiuso in questo trimestre.

Il Terzo Percorso: Software Su Misura, Fatto per Te

Un vendor scrive software funzionante per il gap specifico che lo stack esistente non colma, e si integra con FSM/FMS/ERP/EAM/CMMS. Viene distribuito in settimane. Il cliente paga solo quando il miglioramento operativo si concretizza. Questo colma il gap tra ciò che il vendor SaaS distribuirà in 24 mesi e ciò che il team interno non può finanziare in questo trimestre.

Cos’è e cosa non è

Non è SaaS off-the-shelf, e non è un’app interna personalizzata. Un vendor costruisce software funzionante per il gap specifico che lo stack esistente non colma. Acquisire dati off-system da WhatsApp e radio è la chiave di volta. Questo è esattamente il layer che rappresenta circa il 60% della realtà operativa nei settori field-driven. Esempio: un’azienda di climatizzazione multi-stato il cui FSM gestisce pianificazione e dispatch ma non riesce a catturare i messaggi dei tecnici fuori orario e ad aggiornare automaticamente l’ordine di lavoro. Il layer di software su misura costruisce quel workflow sopra l’FSM esistente, integrandosi tramite acquisizione dati agentiva e raggiungendo il layer che l’FSM non raggiunge.

L’unità di lavoro: un workflow, settimane non trimestri

L’ambito è un singolo gap di workflow. La timeline è di settimane, non trimestri. Workflow operativi attivati dall’AI sopra l’FSM esistente, senza sostituirlo. Si integra con SAP, Maximo e Navis senza rip-and-replace tramite REST e webhook. L’unità di lavoro è delimitata, la timeline è compressa, il rischio è a carico del vendor.

Come gli Acquisti Inquadrano il Terzo Percorso

Statement of work delimitato, milestone di software funzionante, gate di conferma del valore. Si mappa chiaramente sul linguaggio degli acquisti senza l’impegno capex di 9-18 mesi di un build o il lock-in opex per seat di un buy. IP, residenza dei dati e architettura di integrazione vengono definiti in anticipo: il software opera sopra i sistemi esistenti e si integra tramite REST e webhook con ERP/CMMS/FSM, zero rip-and-replace.

Il modello di pricing: non per seat, non capex

Non è opex per seat, e non è capex pluriennale. SOW delimitato, milestone di software funzionante (settimane), gate di conferma del valore (il miglioramento operativo viene misurato prima del pagamento). Il modello commerciale corrisponde al modello di governance: tutto prima in staging, revisione e approvazione IT, poi distribuzione in produzione. Il cliente paga solo quando il miglioramento operativo si concretizza.

Cosa deve sapere l’IT prima di approvare

Ambiente di staging: il software viene costruito in un ambiente di staging controllato. Nulla tocca la produzione finché l’IT non approva. Valutazione automatica del rischio: ogni workflow viene analizzato per problemi di accesso ai dati, vulnerabilità di sicurezza e conformità alla governance prima della revisione IT. Audit trail: controllo versione completo, capacità di rollback, log delle modifiche. La visibilità operativa in tempo reale espone i dati integrati nel dashboard unificato, e l’IT mantiene il controllo.

Come Funziona nelle Operazioni sul Campo: Una Guida Pratica

Il TMS di un operatore 3PL regionale gestisce la pianificazione dei percorsi e l’assegnazione dei carichi, ma non è in grado di riconciliare lo stato dei componenti a bordo dei veicoli, e gli autisti comunicano tramite WhatsApp. Le discrepanze vengono rilevate con un giorno di ritardo e riconciliate manualmente rispetto ai record del WMS di magazzino. Il gap nel flusso di lavoro può costare decine di migliaia di euro al mese in attività di riconciliazione e gestione delle eccezioni per consegne in ritardo.

Settimana 0: sessione di avvio operativa

Il 3PL porta: documentazione del sistema TMS, integrazione WMS, esempi di messaggi WhatsApp degli autisti che causano discrepanze, la definizione di “componenti riconciliati.” Il fornitore porta: un agente di discovery che intervista il team tramite Teams, genera i requisiti, produce mockup e costruisce un business case. La settimana 0 è una sessione di lavoro operativa, non una demo.

Settimane 2-4: software funzionante in staging

La cattura automatica degli aggiornamenti di stato da WhatsApp e radio e la sincronizzazione dello stato riconciliato nel TMS e in una dashboard operativa live trasformano lo stato dei componenti a bordo in dati strutturati. La dashboard evidenzia le discrepanze in tempo reale. Il 3PL vede crescere il vantaggio operativo.

Settimane 4-6: conferma del valore e rilascio in produzione

Il tempo di rilevamento delle discrepanze scende da giorni a minuti. L’operatore 3PL conferma il vantaggio operativo. L’IT esamina l’ambiente di staging, approva l’integrazione, firma la valutazione del rischio e il software passa in produzione. Il cliente paga solo dopo la conferma del vantaggio. I dashboard automatizzati di MTBF e MTTR misurano il miglioramento dei KPI e attivano il gate di pagamento.

Sei Domande per Decidere Quale Percorso Si Adatta alla Tua Situazione

Domanda 1: Il gap è nella roadmap pubblicata dal fornitore entro sei mesi? Acquista e aspetta. Domanda 2: Il flusso di lavoro è il tuo vantaggio competitivo o richiede dati sovrani che non possono uscire dal tuo perimetro? Sviluppa internamente. Domanda 3: Vive interamente dietro il firewall senza chiamate esterne? Sviluppa. Domanda 4: Il gap è prevalentemente un segnale off-system (WhatsApp, radio, foto, voce, carta) che FSM/FMS/ERP/EAM non riesce a ricevere? Considera la terza via. Domanda 5: La capacità di sviluppo interno è a sei o più mesi di distanza per questo flusso di lavoro? Considera la terza via. Domanda 6: Stai per firmare un contratto SaaS a sei cifre per una funzionalità di cui hai bisogno questo trimestre? Considera la terza via. Porta questa checklist alla tua prossima riunione IT.

Opsima è la software factory nativa IA per le operazioni industriali. Costruisce il software CMMS, TMS, TOS, EAM, ERP, di monitoraggio attrezzature e di elaborazione documenti su cui gira la tua operazione, su misura per come ogni operazione lavora davvero.

Due modalità di servizio: (1) personalizzazione sopra il tuo stack esistente (SAP, Maximo, MainPac, Navis, Priority, JDE, AS400) senza nessun rip-and-replace, oppure (2) costruzione da zero quando il sistema legacy ha esaurito il proprio potenziale. Distribuisce in settimane. Si paga solo quando si vede il valore.

PNCT (Port Newark Container Terminal) è il caso di riferimento di Opsima: +5% di disponibilità della flotta di straddle carrier, circa il 15% di riduzione dei guasti non pianificati, e una crescita da circa 1.000 a circa 14.000 cambiamenti di stato delle attrezzature al mese.

Conclusione: Porta il Gap a una Sessione di Lavoro Operativa

La dicotomia build vs buy era la domanda giusta per un’era diversa. Nel 2026, salta l’unico percorso costruito per il gap tra ciò che il fornitore SaaS consegnerà tra due anni e ciò che lo sviluppo interno non può finanziare quest’anno. Il backbone dei dati operativi alimenta software su misura che opera sopra i sistemi esistenti. Se la tua operazione abbraccia porti, mining, logistica e manifattura e il tuo gap di dispatch vive off-system, porta il flusso di lavoro specifico che il tuo fornitore FSM/FMS/ERP/EAM ti ha detto essere in roadmap. Scopri come appare consegnare in settimane. I benchmark di MTTR e disponibilità della flotta mostrano quanto è in gioco. Porta il tuo gap operativo a una sessione di lavoro e scopri come appare la terza via.

Basta eventi operativi persi nei fogli di calcolo.

Circa il 60% dei vostri dati operativi è fuori sistema. Opsima li cattura in software personalizzato, in settimane.

Scopri come funziona →