Prima o poi ogni imprenditore si trova davanti alla stessa domanda, in una riunione di budget: lo costruiamo o lo compriamo? Sembra un confronto di costi. Non lo è quasi mai. Il foglio di calcolo che mette il canone di una licenza accanto a una stima di realizzazione confronta due oggetti di natura diversa - un costo e un bene patrimoniale - come se fossero la stessa cosa.
Il confronto fallisce in entrambe le direzioni. Sottostima il costo di comprare, perché la licenza è l'unica voce che entra nel foglio di calcolo: le soluzioni tampone, la colla delle integrazioni e i compromessi sui flussi di lavoro non ci entrano mai. E sottostima il valore di costruire, perché un bene che migliora ogni trimestre non sta in una cella pensata per contenere il prezzo di un abbonamento. Due numeri, entrambi sbagliati, discussi in una riunione dove vince la voce più forte.
Ecco il criterio che usiamo con i nostri clienti, e con le aziende in cui è in gioco la nostra equity: non si chieda che cosa costa meno. Si chieda che cosa si capitalizza.
Il software affittato si svaluta dal giorno della firma
Un abbonamento SaaS risolve la versione di oggi del suo problema con la versione di oggi del prodotto altrui. Spesso è esattamente la scelta giusta - paghe, email, CRM per un processo di vendita standard. Sono problemi commodity, e i problemi commodity meritano soluzioni commodity. Comprarle non è un compromesso: è disciplina.
Vale però la pena notare che cosa si stia affittando davvero: un flusso di lavoro progettato sulla media di tutti i clienti del fornitore. A ogni trimestre in cui la sua operatività si allontana da quella media - una regola di prezzo qui, un processo di eccezione lì - si paga una seconda tariffa, invisibile: lo strato dei fogli di calcolo. Esportazioni, reinserimenti a mano, soluzioni tampone, «il file che tiene Sanja». Nessuno lo mette a budget, e cresce in proporzione esatta a quanto è differenziata l'azienda.
L'affitto ha clausole nascoste
Il canone di licenza è la parte visibile del prezzo. Le parti invisibili meritano di essere nominate, perché sono quelle che fanno male esattamente nei momenti in cui ci si può permettere meno di sentirle. Il prezzo per utente è una tassa sulla crescita - lo strumento costa di più proprio nel trimestre in cui si assume di più. Gli aumenti seguono il lock-in - i preventivi di rinnovo hanno l'abitudine di raddoppiare una volta che i suoi dati, le sue integrazioni e le abitudini del suo team vivono dentro il prodotto. La roadmap non è sua - la funzionalità da cui dipende la sua operatività può essere dismessa, spostata in un piano più caro o semplicemente mai realizzata, e l'unico rimedio a disposizione è un ticket di assistenza.
Poi c'è la gravità dei dati. Dopo tre anni, il costo di cambiare uno strumento SaaS profondamente radicato è spesso più alto del costo che avrebbe avuto costruire quella capacità fin dall'inizio - non perché il software sia buono, ma perché uscirne significa un'esportazione, una migrazione, una riformazione delle persone e un trimestre di rischio operativo. Il lock-in non è un complotto: è il modello di business. Merita soltanto una riga nel foglio di calcolo del confronto, e quella riga non gli viene mai concessa.
Il software di proprietà si capitalizza - se si costruiscono le cose giuste
Il software su misura si comporta in modo diverso, in bilancio e nell'operatività. Ogni flusso di lavoro che assorbe, ogni integrazione che acquisisce, ogni eccezione che impara a gestire rende più economico il miglioramento successivo. È l'effetto dell'interesse composto - lo stesso meccanismo degli utili reinvestiti, applicato alla conoscenza dei processi.
Il circolo è concreto. Il sistema raccoglie i suoi dati nella sua forma, e questo trasforma l'integrazione successiva in una settimana invece che in un mese. L'integrazione porta un altro flusso di lavoro sotto lo stesso tetto, e questo fa emergere il candidato successivo all'automazione. Ogni incremento si posa sopra il precedente, non accanto. Dopo cinque anni la differenza tra uno stack affittato e una piattaforma di proprietà non è un elenco di funzionalità: è che una delle due ha accumulato per tutto il tempo la conoscenza operativa dell'azienda, e l'altra ha accumulato la roadmap di qualcun altro.
Gli effetti di secondo ordine sono sottovalutati. Le nuove persone fanno onboarding sul processo reale dell'azienda, non su uno strumento generico più una cartella di documenti che spiegano come aggirarlo. La due diligence in una cessione o in un round va più veloce quando l'operatività è leggibile in un solo sistema: gli acquirenti pagano per operazioni che riescono a leggere. E il software stesso è un bene con un valore, cosa che non si può dire di una pila di abbonamenti.
Costruire solo dove il proprio processo è il prodotto. Comprare ovunque il processo sia uguale a quello di tutti gli altri.
Il test è una sola domanda: se questo flusso di lavoro fosse due volte migliore dello standard di settore, i clienti se ne accorgerebbero? Se sì - la velocità di preventivo in un'azienda di trasporti, i tempi di liquidazione dei sinistri in un'assicurazione, l'esperienza di accettazione in un gruppo di cliniche - quel flusso di lavoro è un bene che si capitalizza e merita software di proprietà. Se no: si compri la commodity e si passi oltre.
Due dei quadranti meritano una nota. «Comprare, poi adattare» è il quadrante in cui la maggior parte delle aziende di media dimensione dovrebbe vivere più spesso di quanto faccia: tenere il nucleo commodity e costruire solo lo strato sottile che codifica ciò che le rende diverse - il motore di prezzo sopra il CRM standard, la gestione delle eccezioni sopra l'ERP standard. E «comprare il migliore» va preso alla lettera: per i flussi di lavoro commodity, lo strumento premium è quasi sempre più economico dello strumento economico più l'attrito che genera.
Il calcolo che decide davvero
Quando il flusso di lavoro supera il test, la decisione di costruire diventa una questione di rientro, e va calcolata onestamente: costo di realizzazione più costo di esercizio, contro ore eliminate, errori evitati e ricavi sbloccati. Nelle nostre stime vale una regola: se quel rientro supera i dodici mesi sconsigliamo di costruire - e mettiamo la raccomandazione per iscritto.
Faccia il conto con numeri reali, non con speranze. Sul lato dei costi: la stima di realizzazione, poi la manutenzione - una cifra di pianificazione sensata è il 15-20% del costo di realizzazione all'anno - più l'hosting e il tempo interno necessario a presidiarlo. Sul lato dei ritorni: le ore pienamente caricate che il flusso di lavoro consuma oggi, il costo degli errori che produce e i ricavi che tempi di ciclo più rapidi sbloccano. Se il lato dei ritorni è dominato da una voce morbida di «valore strategico» e i numeri duri non la reggono, è il conto che sta dicendo di comprare.
Tre modi di sbagliare, da evitare. Costruire software commodity per orgoglio - «noi siamo speciali» non è vero per le paghe, e la realizzazione finirà per competere con prodotti che hanno mille persone di vantaggio. Comprare software differenziante per impazienza - l'abbonamento parte veloce, poi lo strato dei fogli di calcolo cresce intorno finché il vantaggio di velocità è sparito. E costruire la cosa giusta con il perimetro sbagliato - una prima versione che prova a coprire tutto arriva tardi e atterra su un'operatività che ha già smesso di crederci. La prima versione dovrebbe essere imbarazzantemente stretta e davvero usata.
Le obiezioni ricorrenti, con risposte oneste
«Non siamo un'azienda di software.» Non serve esserlo. Serve un responsabile dalla sua parte del tavolo e un partner che risponda di tutto il resto - allo stesso modo in cui si possiede un immobile senza essere un'impresa di costruzioni. Quello che non va fatto è costruire senza mettere per iscritto la questione della manutenzione.
«Il software su misura diventa legacy.» Il software su misura fatto male sì. E lo diventa anche ogni strumento SaaS che si supera - solo che un fornitore non si può rifattorizzare. Il software costruito su tecnologia noiosa e mainstream, documentato e coperto da test, resta manutenibile per un decennio. È un criterio di scelta del fornitore, non un argomento contro la proprietà.
«E se il fornitore rilascia la nostra funzionalità l'anno prossimo?» Allora lo strumento affittato migliora - per lei e per ogni concorrente che lo affitta lo stesso pomeriggio. Le funzionalità che un fornitore rilascia sono, per definizione, quelle che non la differenziano. La capacità per cui i clienti scelgono lei è esattamente quella che non può aspettare.
Come invecchia la decisione
Costruire o comprare non è una decisione che si prende una volta: è un portafoglio da riequilibrare. Un flusso di lavoro che tre anni fa era commodity può essere diventato il terreno su cui oggi si compete - l'onboarding dei clienti fa spesso questo percorso - e una capacità costruita nel 2019 può nel frattempo essere diventata una commodity che tre fornitori vendono meglio. Metta il portafoglio su una cadenza annuale: per ogni sistema di proprietà, si chieda se supera ancora il test della capitalizzazione; per ogni abbonamento rilevante, si chieda quanto costa ormai lo strato di fogli di calcolo che gli è cresciuto intorno.
Sia disposto a dismettere il software di proprietà quanto lo è a costruirlo. Spegnere uno strumento su misura il cui flusso di lavoro è diventato commodity non è un'ammissione di fallimento: è il portafoglio che funziona. Il vero errore è l'inerzia, in entrambe le direzioni: affittare ciò che la differenzia perché costruire sembra rischioso, oppure mantenere il legacy perché una volta è costato caro. Al bilancio non interessa quanto è costato imparare qualcosa; gli interessa che cosa si capitalizza da qui in avanti.
Da dove iniziare
Faccia l'inventario del suo strato di fogli di calcolo. Ogni soluzione tampone è un voto: l'operatività che indica dove ha già superato gli strumenti affittati. Metta un prezzo onesto a quelle ore, applichi il test della capitalizzazione, e la decisione tra costruire e comprare di solito si prende da sola. L'elenco sarà più lungo del suo appetito, ed è lo stato sano delle cose: ordini per rientro, costruisca dall'alto, e lasci che il ritorno misurato di ogni progetto finanzi la volontà di fare il successivo.
E quando una realizzazione supera davvero l'asticella, la tenga allo standard che le ha dato ragione: una metrica di business dichiarata prima della prima riga di codice, software funzionante in settimane e non in trimestri, e un perimetro abbastanza stretto da essere imbarazzante. Il software di proprietà si capitalizza solo se viene consegnato, viene usato e continua ad assorbire l'operatività che ha intorno. Quella parte non è una questione di strategia. È una questione di esecuzione.