La decisione arriva di solito come un foglio di calcolo: tre vendor, una stima di sviluppo, i costi di licenza in una colonna e il time-to-launch in un’altra. Qualcuno si è già fatto un’opinione, e la riunione esiste per confermarla.
Cosa sfugge al confronto commerciale
Il foglio di calcolo non è sbagliato; è incompleto in un modo specifico e costoso. Prezzo d’acquisto e costo di sviluppo sono i numeri visibili. Il costo reale di una decisione build/buy/integrate vive in otto domande tecniche che il confronto commerciale raramente pone — e l’opzione più economica sulla slide è regolarmente la più costosa sul patrimonio tre anni dopo.
Il business case confronta costi di acquisizione. Ma una capability di piattaforma non si acquisisce — si opera: si integra, si mette in sicurezza, si aggiorna, si monitora, si presidia e prima o poi se ne esce. Per un prodotto comprato, la licenza è il biglietto d’ingresso; il costo operativo è il lavoro di integrazione, le personalizzazioni che si induriscono in fork non ufficiali, il tapis roulant degli upgrade e i workaround per il 20% di requisiti che il prodotto quasi soddisfa. Per un build, la stima copre la versione uno; il costo operativo è ogni anno di gestione dopo che il team del lancio è passato ad altro.
Nessuno dei due è un argomento per l’altra parte. È un argomento per confrontare il costo operativo totale sulla vita della capability — il che richiede le domande tecniche qui sotto, con risposta prima della decisione, non scoperta dopo.
Il test di differenziazione
La prima domanda filtra tutte le altre: questa capability ci rende diversi, o ci fa funzionare?
Costruite ciò che differenzia — la capability il cui comportamento è il vostro prodotto o il vostro vantaggio, dove controllarne l’evoluzione è il punto. Comprate ciò che è commodity — capability in cui essere esattamente bravi quanto gli altri va bene, e la scala del vendor batte lo sforzo interno. I fallimenti costosi stanno nelle zone di confusione: costruire commodity (uno strumento interno che un prodotto eguaglia funzione per funzione, meno il team di manutenzione) e comprare differenziazione (il vostro vantaggio centrale, ora dipendente dalla roadmap e dalle condizioni commerciali di un vendor).
Il test è onesto proprio dove è scomodo: la maggior parte delle capability è commodity, e un bisogno che sembra unico è spesso più vicino alla commodity di quanto appaia.
Superficie di integrazione e proprietà dei dati
Due domande decidono se "buy" diventa in silenzio "build comunque":
Quanto è ampia la superficie di integrazione? Contate i punti di contatto del prodotto con il vostro patrimonio — identità, flussi di dati, workflow, reporting. Un prodotto con una dozzina di punti di integrazione profondi non è un acquisto a scaffale; è un progetto di sviluppo con una licenza in allegato. L’inventario richiede una giornata e ridisegna regolarmente la decisione.
Chi possiede i dati — in pratica, non per contratto? Il contratto dice che i dati sono vostri. Le domande pratiche: in che forma potete estrarli, con quale completezza, con quale storico, a quale costo? Un sistema che tiene i vostri dati in una forma proprietaria possiede le vostre opzioni di uscita, qualunque cosa dica il contratto.
Lock-in ed estensibilità come proprietà architetturali
Il lock-in non è un peccato del vendor; è una proprietà architetturale che o si gestisce o si subisce. La versione misurabile è il costo di uscita: cosa servirebbe, oggi, per spostare questa capability altrove — migrazione dei dati, integrazioni ricostruite, formazione, esercizio in parallelo? Se la risposta è "realisticamente non ce ne andremmo mai", quel fatto appartiene alla decisione e alla negoziazione, con il suo prezzo.
L’estensibilità è la stessa proprietà rivolta in avanti: quando i vostri requisiti superano l’80% del prodotto, cosa succede? I prodotti con API vere, punti di estensione e un modello di personalizzazione supportato invecchiano bene. I prodotti in cui estendere richiede i professional services del vendor legano la vostra roadmap alla sua capacità di delivery e ai suoi prezzi. Per i build, la domanda speculare è chi lo estende al terzo anno, quando il team originale è altrove.
Superficie di sicurezza e compliance
Ogni opzione porta una postura di sicurezza diversa, e il confronto raramente viene reso esplicito. Comprare importa un vendor dentro il vostro perimetro di fiducia: il suo modello di accesso, la sua cadenza di patch, il suo storico incidenti, i suoi subprocessor — due diligence, non una casella da spuntare. Costruire tiene il perimetro interno ma vi rende responsabili di tutto ciò che contiene, incluse le parti che un vendor avrebbe presidiato. Integrare — comporre la capability da sistemi esistenti già fidati — può ridurre il numero di componenti nuovi, ma i percorsi di integrazione stessi richiedono comunque una revisione di sicurezza esplicita.
Per i patrimoni regolamentati, questa domanda da sola può chiudere la questione prima ancora di parlare di costi.
La scorecard
Otto domande, valutate con evidenze prima della decisione commerciale:
- 1. Differenziazione — questa capability ci rende diversi o ci fa funzionare?
- 2. Costo operativo totale — sulla vita della capability, non sull’acquisizione.
- 3. Superficie di integrazione — quanti punti di contatto, quanto profondi, prezzati come engineering.
- 4. Proprietà dei dati — estraibilità pratica, non rassicurazione contrattuale.
- 5. Lock-in / costo di uscita — cosa servirebbe per andarsene, in numeri.
- 6. Estensibilità — cosa succede quando l’80% finisce.
- 7. Superficie di sicurezza — cosa entra nel perimetro di fiducia, chi lo patcha.
- 8. Time-to-capability — onesto, incluse integrazione e adozione, non time-to-contract.
L’esito frequente non è un verdetto ma una scomposizione: comprare il nucleo commodity, costruire il sottile strato differenziante sopra, integrare il resto attraverso interfacce possedute. La risposta ibrida non compare mai su una slide di vendor, perché nessuno la vende — ed è precisamente il motivo per cui serve una voce ingegneristica nella stanza prima della firma.