Harsh Joshi
Co-founder & Technical Director
Confronta lo sviluppo interno, l’acquisto e l’esternalizzazione del software aziendale utilizzando un modello decisionale pratico che tenga conto dei costi, del controllo, dei tempi e dei rischi a lungo termine.
Un CTO che si trova di fronte a uno strumento interno non funzionante ha tre possibili vie d’uscita: sospendere la roadmap e incaricare il team interno di sviluppare un sostituto, acquistare un prodotto commerciale e adattare l’attività a esso, oppure coinvolgere un team di ingegneri esterno per sviluppare una soluzione su misura. Ciascuna di queste opzioni risolve lo stesso problema in modo diverso e, a distanza di diciotto mesi, comporta una serie di conseguenze diverse.
Sviluppo interno, acquisto e outsourcing sono le tre strade pratiche per dotarsi di software aziendale, e la scelta non riguarda tanto quale opzione sia oggi la più economica, quanto piuttosto quale si adatti meglio al livello di specializzazione richiesto dal software, alla rapidità con cui l’azienda ne ha bisogno e al grado di controllo tecnico che l’azienda intende effettivamente mantenere nel lungo periodo. Questa guida illustra in dettaglio cosa comporta ciascuna opzione, fornisce un metodo pratico per valutarle in base alla vostra situazione specifica e affronta le questioni relative al costo totale di proprietà che spesso vengono trascurate quando occorre prendere una decisione in tempi rapidi. Per i team che finiscono per propendere per l’esternalizzazione, i servizi di ingegneria digitale di Monarch Innovation coprono lo sviluppo di software personalizzato, il cloud e l’ingegneria dei dati proprio in questo preciso momento decisionale.
Acquistate il software quando le esigenze sono standardizzate, sviluppatelo internamente quando è strategicamente importante e il vostro team ne ha le capacità, e affidatevi a terzi quando avete bisogno di un software personalizzato ma non disponete delle risorse interne o delle competenze specialistiche necessarie per realizzarlo nei tempi richiesti.
Realizzare, acquistare o esternalizzare: risposta rapida
| Opzione | La taglia più adatta | Vantaggio principale | Principale compromesso |
|---|---|---|---|
| Costruire | Software strategico e differenziato, supportato da competenze e risorse interne | Massimo controllo e autonomia | Maggiore impegno interno in ambito ingegneristico |
| Acquista | Funzioni aziendali standardizzate o di base | Implementazione più rapida e manutenzione gestita dal fornitore | Minore flessibilità e potenziale dipendenza da un unico fornitore |
| Esternalizzare | Esigenze di software personalizzato in presenza di capacità interne limitate o competenze specialistiche | Sviluppo personalizzato senza assunzioni immediate | Dipendenza dalla qualità del partner e dal trasferimento di conoscenze |
Cosa significano realmente i termini “costruire”, “acquistare” e “esternalizzare”
Lo sviluppo interno significa che il proprio team di ingegneri progetta, sviluppa e gestisce il software avvalendosi di personale e infrastrutture interne. L’acquisto consiste invece nell’ottenere una licenza per un prodotto commerciale o SaaS e nell’adattare i propri processi alle sue funzionalità. L'esternalizzazione consiste nell'assumere un team di ingegneri esterno, sia per un progetto ben definito sia come team dedicato a lungo termine, al fine di realizzare software personalizzato che il personale interno non ha il tempo o le competenze specialistiche per sviluppare autonomamente.
Non si tratta della stessa decisione presentata in tre modi diversi. Lo sviluppo interno garantisce il pieno controllo, ma comporta costi di ingegneria permanenti. L’acquisto consente di essere operativi rapidamente, ma vincola alla roadmap di prodotto di qualcun altro. L’outsourcing offre un software personalizzato senza aumentare l’organico, ma dipende interamente dalla scelta del partner giusto. Monarch Innovation collabora con i responsabili tecnici in tutti e tre gli scenari, intervenendo soprattutto nei casi in cui un team abbia deciso che lo sviluppo personalizzato è la scelta giusta, ma non disponga delle risorse interne per realizzarlo.
Perché questa decisione merita qualcosa di più di un semplice confronto dei costi
La maggior parte dei confronti tra "sviluppare in proprio" e "acquistare" si limita a mettere a confronto i costi delle licenze con gli stipendi degli sviluppatori. Questo confronto tralascia la vera questione, ovvero se il software rappresenti una fonte di vantaggio competitivo o una funzionalità di base di cui hanno bisogno anche un centinaio di altre aziende.
Raramente vale la pena sviluppare da zero uno strumento di pianificazione, un sistema di gestione delle spese o un CRM standard, poiché i fornitori hanno già risolto quel problema su una scala che nessuna singola azienda può eguagliare. Un motore di determinazione dei prezzi legato a un modello di business proprietario, un sistema di esecuzione della produzione costruito attorno a un processo produttivo specifico o una piattaforma interna che influenza direttamente il modo in cui i clienti vivono il prodotto sono tutta un’altra storia. Quando il software definisce il modo in cui l’azienda opera o compete effettivamente, acquistare un prodotto generico significa rimodellare l’azienda per adattarla alle ipotesi di qualcun altro.
Questa distinzione, ovvero se il sistema rappresenti un elemento di differenziazione o un prodotto di massa, costituisce il primo filtro che dovrebbe restringere il campo delle opzioni prima ancora che si parli di costi.
Opzione 1: Realizzazione interna
Lo sviluppo interno garantisce all’azienda il pieno controllo sulla roadmap, sull’architettura e sul modo in cui il software si evolve di pari passo con l’attività aziendale. Non vi è alcun contratto con un fornitore che si frapponga tra una nuova esigenza e una funzionalità rilasciata, e il team che sviluppa il sistema ne ha una comprensione così approfondita da poterlo estendere in un secondo momento.
Il compromesso riguarda capacità e tempo. Gli sviluppi interni competono per le stesse ore di ingegneria di ogni altra voce della roadmap, e assumere competenze specializzate per un singolo progetto – che si tratti di una particolare piattaforma cloud, di una disciplina di ingegneria dei dati o di un ambito con elevati requisiti di conformità – richiede mesi, tempo che un’iniziativa in rapida evoluzione spesso non ha a disposizione. Lo sviluppo interno comporta inoltre l’intero onere della manutenzione a lungo termine: patch di sicurezza, aggiornamenti dell’infrastruttura e il costo finale di un software che sopravvive agli stessi ingegneri che lo hanno scritto.
Lo sviluppo interno risulta la scelta più sensata quando il software è fondamentale per il prodotto stesso, quando il team dispone già delle competenze necessarie al proprio interno e quando l’azienda è pronta a gestire quel sistema per anni, non solo a lanciarlo una volta sola.
Opzione 2: Acquisto di una soluzione pronta all’uso o SaaS
L'acquisto consente di disporre di un sistema funzionante nel minor tempo possibile, spesso nel giro di pochi giorni o settimane anziché mesi. Affida al fornitore la manutenzione, l'applicazione delle patch di sicurezza e la gestione dell'infrastruttura, e offre un servizio di assistenza che ha già risolto la maggior parte dei problemi più comuni che si presenterebbero in caso di una prima implementazione.
Il compromesso si manifesta nel corso del tempo piuttosto che fin dal primo giorno. Il software commerciale è progettato per un mercato ampio, quindi raramente si adatta perfettamente a un flusso di lavoro specifico, e il divario viene colmato con soluzioni manuali o costose personalizzazioni. I costi di licenza aumentano in base all’utilizzo, in modi che alla fine possono superare quanto sarebbe costata una soluzione su misura. La dipendenza dal fornitore diventa una realtà nel momento in cui i dati, le integrazioni e i processi interni di un’azienda sono strutturati attorno a un prodotto che non controlla, e cambiare fornitore in un secondo momento può rivelarsi un progetto più impegnativo rispetto all’implementazione iniziale.
L'acquisto risulta la scelta più sensata nel caso di funzioni ben definite e di natura standardizzata, in cui esiste un mercato maturo di fornitori e la differenziazione dell'azienda risiede in un ambito completamente diverso.
Opzione 3: Esternalizzazione dello sviluppo personalizzato
L'outsourcing si colloca a metà strada tra le altre due opzioni. Offre software personalizzato sviluppato appositamente per l'azienda, senza che questa debba assumere, formare e mantenere un team interno completo a tale scopo. Un partner tecnico esterno apporta le competenze già acquisite nello stack tecnologico di riferimento, si fa carico dei costi di assunzione e gestione e, in genere, è in grado di avviare il progetto più rapidamente di quanto consentirebbe un processo di reclutamento interno.
L’outsourcing non è un modello unico. Un impegno basato su progetto si adatta a un risultato dall’ambito chiaramente definito, con un inizio e una fine precisi, come la sostituzione di un sistema legacy o la realizzazione di un’integrazione specifica. Un team di ingegneri dedicato, ingaggiato su base continuativa, funziona più come un’estensione del team interno ed è adatto a un’azienda con un flusso continuo di attività di sviluppo personalizzate. L’ampliamento del personale prevede l’aggiunta di singoli ingegneri a un team interno già esistente e funziona al meglio quando l’azienda dispone già di una solida leadership tecnica e necessita semplicemente di ulteriori risorse con competenze specifiche. La precedente guida di Monarch Innovation sulla scelta tra questi modelli di collaborazione approfondisce come abbinare il modello al carico di lavoro.
Il compromesso dell’outsourcing è che i risultati dipendono fortemente dalla scelta del partner. Un partner debole può comportare lo stesso rischio di lock-in di un acquisto SaaS sbagliato, ma con meno documentazione e un codice che solo lui è in grado di comprendere. Un partner forte, al contrario, può offrire un livello di controllo simile a quello di uno sviluppo interno, con un onere di assunzione molto minore. La guida sui costi dell’outsourcing dell’ingegneria di prodotto illustra un’analisi simile dei costi per le attività di ingegneria hardware e di prodotto, e molte delle stesse questioni relative ai modelli di prezzo (tempo e materiali, prezzo fisso, team dedicato) valgono anche per i progetti software.
Modello decisionale: "Realizzare", "Acquistare" o "Esternalizzare"
Una volta chiarita la questione “prodotto di massa contro elemento di differenziazione”, sono proprio questi fattori a determinare in gran parte la scelta del percorso da seguire.
| Fattore | Creazione di bomboniere | Acquista bomboniere | Esternalizzazione dei servizi |
|---|---|---|---|
| Differenziazione strategica | Elevato, elemento fondamentale per il vantaggio competitivo | Funzione di base, di tipo generico | Elevata, ma la capacità interna è limitata |
| È ora di partire | Flessibile, accettabili anche periodi di durata mensile | Da richiedere entro giorni o settimane | Occorrente entro poche settimane, più rapidamente di quanto consenta il processo di assunzione |
| Competenze interne | Già disponibile per il personale | Non richiesto | Disponibile esternamente, non internamente |
| Propensione all'investimento a lungo termine | È un record altissimo, la squadra lo manterrà per anni | Basso, la manutenzione è a carico del fornitore | Medio, dipende dal modello di coinvolgimento scelto |
| Complessità dell'integrazione | Elevato livello di controllo sulle API e sui sistemi interni | Funziona al meglio quando le integrazioni sono standard | Utile quando sono necessarie integrazioni personalizzate o la migrazione dei dati |
| Durata di vita prevista | Piattaforma strategica a lungo termine | Funzione a breve termine o sostituibile | Sistema personalizzato a lungo termine con supporto esterno per le consegne |
Nessuna singola riga è di per sé determinante per l’esito finale. Un sistema altamente differenziato ma che deve essere pronto entro tre settimane, ad esempio, di solito fa propendere per l’outsourcing piuttosto che per uno sviluppo interno, che non può procedere con sufficiente rapidità, o per un prodotto commerciale, che non può essere personalizzato a sufficienza.
Un semplice albero decisionale per scegliere tra "realizzare internamente", "acquistare" e "esternalizzare"
- Il software è una funzione standardizzata o di uso comune?
- Sì: inizia valutando prodotti commerciali già affermati o soluzioni SaaS.
- No: Il software riveste un’importanza strategica per l’azienda?
- Sì: disponete delle competenze interne e delle risorse ingegneristiche necessarie per realizzarlo e mantenerlo?
- Sì: lo sviluppo interno potrebbe rientrare nella roadmap.
- No: affidare lo sviluppo personalizzato a terzi potrebbe essere la soluzione più adatta.
- No: Valutare nuovamente se l'acquisto di un prodotto già esistente possa soddisfare le esigenze aziendali senza richiedere un'eccessiva personalizzazione.
Costo totale di proprietà: oltre il primo anno
L'errore più comune in questa decisione consiste nel confrontare una stima dello stipendio interno, il preventivo per la licenza di un fornitore e la tariffa oraria di un partner di outsourcing come se fossero valori dello stesso tipo. Non lo sono, e un confronto equo deve considerare un orizzonte temporale da tre a cinque anni, non limitarsi alla prima fattura.
Una soluzione sviluppata internamente comporta costi salariali e previdenziali ricorrenti, indipendentemente dal fatto che la roadmap preveda attività effettive per quel team ogni trimestre, oltre ai costi di infrastruttura, sicurezza ed eventuale riscrittura che derivano da qualsiasi sistema abbastanza vecchio da essere considerato obsoleto. Una soluzione acquistata comporta costi ricorrenti di licenza che in genere variano in base all’utilizzo o al numero di postazioni, oltre al costo delle soluzioni alternative interne per qualsiasi funzionalità che il prodotto non offra nativamente e un costo reale, spesso sottovalutato, legato alla successiva migrazione da tale soluzione. Una soluzione in outsourcing comporta il costo dell’incarico stesso, oltre a qualsiasi competenza interna necessaria per gestire il rapporto e, eventualmente, mantenere o estendere il sistema fornito; ecco perché la chiarezza sulla documentazione e sul passaggio di consegne deve essere sancita nel contratto fin dal primo giorno.
Nessuna di queste soluzioni è intrinsecamente più economica. Il confronto corretto consiste nel chiedersi cosa il sistema debba essere in grado di fare nel terzo anno, non solo quanto costi metterlo in funzione nel primo mese.
Quando ogni percorso ha un senso
Alcuni scenari realistici rendono il modello più facile da applicare rispetto al solo quadro di riferimento:
- Uno strumento standard di CRM o di gestione delle spese. Acquistarlo. Il mercato è maturo, questa funzionalità non rappresenta un elemento di differenziazione e svilupparla internamente significherebbe risolvere nuovamente un problema che i fornitori hanno già risolto in modo ottimale.
- Un motore di determinazione dei prezzi o di preventivazione legato a un modello di business proprietario. Da sviluppare internamente o affidare a terzi, a seconda delle capacità interne. Si tratta proprio del tipo di sistema che determina il vantaggio competitivo, pertanto un prodotto generico non sarebbe adeguato senza dover scendere a pesanti compromessi.
- Un sistema di esecuzione della produzione obsoleto che deve essere sostituito entro una scadenza molto ravvicinata. Affidare il lavoro a terzi. Il sistema è talmente specifico da richiedere uno sviluppo su misura, ma assumere e formare un team interno in tempi sufficientemente rapidi da rispettare la scadenza è raramente realistico.
- Una piattaforma interna che il vostro team di prodotto gestirà e svilupperà nel corso del prossimo decennio. Realizzatela solo quando il team avrà acquisito le competenze necessarie, poiché in questo caso la gestione a lungo termine e la profonda conoscenza del contesto interno contano più della rapidità di lancio.
Errori comuni nella scelta tra "sviluppare internamente", "acquistare" e "esternalizzare"
Quando questa decisione si rivela sbagliata, si riscontrano ripetutamente alcuni schemi ricorrenti. Considerarla una scelta una tantum è l’errore più comune: le esigenze aziendali cambiano e un sistema acquistato come soluzione standard due anni fa può diventare un collo di bottiglia strategico una volta che l’azienda ha sviluppato una propria differenziazione competitiva attorno ad esso. Un altro errore è quello di confrontare solo i costi del primo anno, poiché i costi delle licenze, gli stipendi e le tariffe di outsourcing si comportano in modo diverso su un orizzonte temporale da tre a cinque anni. Anche sottovalutare lo sforzo di integrazione e migrazione causa danni concreti, in particolare con software acquistato che deve connettersi ad altri cinque sistemi interni fin dal primo giorno. Scegliere un partner di outsourcing basandosi esclusivamente sulla tariffa, senza verificare le pratiche di documentazione, la frequenza delle comunicazioni o cosa ne sarà del codice sorgente una volta terminato il contratto, tende a generare proprio quel problema di vincolo che l’outsourcing avrebbe dovuto evitare. Infine, tralasciare una valutazione reale delle capacità interne, partendo dal presupposto che un team già sovraccarico possa assorbire un progetto di sviluppo oltre alla propria roadmap esistente, è un modo comune in cui i progetti interni si arenano silenziosamente per un anno.
Valutare un partner di outsourcing prima di impegnarsi
Se l’outsourcing è la strada giusta da seguire, la scelta del partner è importante tanto quanto la decisione stessa. Vale la pena porre alcune domande prima di firmare qualsiasi accordo: quali ingegneri specifici lavoreranno al progetto e rimarranno assegnati per tutta la durata dell’incarico? Quali documenti, codice sorgente e decisioni relative all’architettura verranno consegnati al completamento del progetto e in quale formato? Come gestisce il partner un cambiamento dei requisiti a progetto in corso e quali sono le ripercussioni sui costi e sulle tempistiche? Cosa ne sarà del know-how aziendale se il rapporto dovesse terminare o se il personale chiave dovesse cambiare? Un partner che risponde a queste domande in modo concreto, anziché con rassicurazioni generiche, rappresenta solitamente la scelta più sicura, e la stessa logica di valutazione si applica sia che si tratti di un incarico basato su un progetto, di un team dedicato o di un potenziamento del personale.
Scegliere un percorso in linea con la propria strategia
"Sviluppare", "acquistare" e "esternalizzare" non sono filosofie in competizione tra loro. Sono tre strumenti adatti a situazioni diverse, e la scelta giusta per un sistema nella vostra roadmap può rivelarsi sbagliata per quello successivo. Le domande che vale la pena porsi prima di prendere una decisione sono: quanto è realmente differenziato il sistema, quanta capacità interna esiste per gestirlo e quale sarà il costo totale tra tre anni, piuttosto che quello indicato sulla prima fattura.
Monarch Innovation collabora con i principali esperti di ingegneria nei settori del software personalizzato, del cloud e dell’ingegneria dei dati, intervenendo spesso proprio in questo momento cruciale in cui è necessario realizzare un sistema su misura, ma il team interno non è in grado di affrontare un altro progetto di lunga durata. Se state valutando se sviluppare internamente, acquistare o affidarvi a un team di ingegneri in outsourcing per un sistema di prossima realizzazione, contattate Monarch Innovation per discutere i pro e i contro specifici relativi alla vostra roadmap.
Discuti la tua strategia di sviluppo software
Stai valutando se sviluppare internamente, acquistare un prodotto commerciale o affidarti a un team di ingegneri esterni? Contatta Monarch Innovation per discutere con il nostro team di ingegneri dei requisiti del tuo sistema, delle tempistiche e delle esigenze a lungo termine relative alla gestione del sistema.
Domande frequenti su “Sviluppare in proprio”, “Acquistare” e “Esternalizzare”
Qual è la differenza tra lo sviluppo software "in-house", "acquisito" e "esternalizzato"?
"Sviluppo interno" significa che il vostro team interno progetta, sviluppa e gestisce il software. "Acquisto" significa che ottenete una licenza per un prodotto commerciale o SaaS e adattate i vostri processi aziendali a tale prodotto. "Esternalizzazione" significa che un partner tecnico esterno realizza software personalizzato per la vostra organizzazione, in genere attraverso un progetto, un team dedicato o il potenziamento del personale.
È meglio sviluppare un software su misura o acquistare un servizio SaaS?
Dipende dal fatto che l’esigenza sia standardizzata o strategicamente differenziata, dal livello di personalizzazione e integrazione richiesto, dalla rapidità con cui è necessario disporre del sistema e dal fatto che il vostro team interno disponga delle capacità e delle competenze necessarie per gestire il software per tutto il suo ciclo di vita, non solo al momento del lancio.
Come posso decidere se sviluppare, acquistare o esternalizzare la realizzazione di un software aziendale?
Inizia chiedendoti se il sistema rappresenti un elemento di differenziazione competitiva o una funzione di base. Le esigenze di base di solito favoriscono l’acquisto. I sistemi differenziati favoriscono lo sviluppo interno o l’outsourcing, e la scelta tra queste due opzioni dipende spesso dal fatto che il tuo team interno disponga delle capacità e delle competenze specialistiche necessarie per realizzarlo in tempo.
L'esternalizzazione dello sviluppo software è più conveniente rispetto alla realizzazione interna?
Non sempre, e limitarsi a confrontare le tariffe orarie con gli stipendi è fuorviante. L’outsourcing consente di evitare i costi fissi legati all’assunzione di nuovo personale a tempo pieno e il processo di selezione che richiede mesi, ma il costo totale dipende comunque dalla portata del progetto, dal numero di iterazioni e da come viene gestito il rapporto di collaborazione nel tempo.
Qual è il rischio maggiore nell'acquistare un software commerciale invece di svilupparlo autonomamente?
Il rischio principale è il “vendor lock-in”. Una volta che i processi interni, i dati e le integrazioni sono stati sviluppati attorno a un prodotto acquistato, passare a un altro fornitore o sviluppare in seguito una soluzione sostitutiva può trasformarsi in un progetto più ampio e costoso rispetto a quanto lo sia mai stata l’implementazione originale.
In quali casi è più opportuno ricorrere all’outsourcing piuttosto che sviluppare internamente?
L'outsourcing risulta la soluzione più indicata quando il software deve essere sviluppato su misura, ma il team interno non dispone delle competenze specialistiche o della capacità operativa necessarie per realizzarlo entro i tempi richiesti, poiché un partner è in genere in grado di avviare il progetto più rapidamente rispetto a quanto consentito da un ciclo di assunzione completo.
Cosa dovrei chiedere prima di scegliere un partner per l'outsourcing informatico?
Chiedete quali ingegneri specifici lavoreranno al progetto, quale documentazione e codice sorgente riceverete al termine dei lavori, come vengono gestite le modifiche ai requisiti nel corso del progetto e cosa ne sarà del know-how aziendale qualora il rapporto di collaborazione dovesse terminare. Le risposte concrete sono un segnale più forte delle rassicurazioni generiche.
Il costo totale di proprietà è più importante del prezzo iniziale?
Sì, nella maggior parte dei casi. Lo sviluppo interno, l’acquisto e l’esternalizzazione comportano modelli di costo diversi nell’arco di tre-cinque anni, che includono i costi di manutenzione, l’aumento dei costi delle licenze e quelli di migrazione; limitarsi a confrontare solo la prima fattura tende a portare a una decisione che, nel giro di uno o due anni, si rivela sbagliata.
La decisione tra "sviluppare internamente", "acquistare" e "esternalizzare" può cambiare nel tempo?
Può succedere, e spesso succede. Un sistema acquistato come soluzione standard può trasformarsi in un collo di bottiglia strategico nel momento in cui l'azienda inizia a differenziarsi proprio grazie ad esso; ecco perché vale la pena riesaminare periodicamente questa decisione man mano che l'azienda evolve, anziché considerarla definitiva.
