Make or Buy, la posizione dei CIO nell’eterno dilemma dell’IT

Il dilemma “Make or Buy” sugli applicativi aziendali è un classico per i CIO. Ma oggi assume un significato diverso, perché l’IT non è veramente solo Information Technology, ma genera valore per il business. Per i CIO italiani la decisione se costruire una piattaforma internamente, farla sviluppare da terzi o comprare un prodotto standard, magari poi personalizzandolo, davvero dipende da numerosi fattori: la presenza di adeguate competenze interne di sviluppo, il budget a disposizione, il rapporto con i fornitori, le esigenze aziendali. Se, in generale, la tendenza ad acquistare è prevalente sul “Make” (o “Build”), la realtà è che per i manager dell’IT italiani la creatività vince su tutto e porta, spesso, a mescolare gli approcci.

Un altro aspetto è che, anche laddove l’IT è un “full outsourcing”, ovvero gestito da terzi con prodotti quasi tutti acquistati, e i team interni sono piccoli, i CIO cercano di non impoverirsi di competenze interne. Uno zoccolo duro di know-how è quanto mai indispensabile, soprattutto nel disegno dei processi e nelle tecnologie emergenti, come l’intelligenza artificiale, perché permette di avere sempre il controllo dei progetti e del lavoro dei partner o fornitori. È un aspetto così importante che alcuni CIO sono arrivati a valutare la parziale internalizzazione di alcune attività.

“La domanda Make or Buy si presenterà sempre al CIO e può essere articolata su due macro-livelli: in un caso si possono comprare prodotti standard e usare principalmente quelli, nell’altro si apre la strategia alla scrittura di software, anche solo limitatamente ad alcuni aspetti applicativi su specifiche proprie di un’azienda e sulla base della propria modalità operativa”, commenta Andrea Magnoleretto, CIO e International Project Manager con lunga esperienza in aziende internazionali. “All’interno del primo caso ci si può ulteriormente differenziare fra soluzioni da uno stesso vendor su cloud pubblico, su cloud privato oppure on-premises, mescolando anche tutti questi aspetti. In un caso il CIO comprerà uno o più prodotti standardizzati, magari con pochi spazi di personalizzazione, ma con costi ridotti, mentre nel secondopotrà chiedere o fare sviluppi ad hoc, ma ad un prezzo”.

La scelta migliore, in assoluto, non c’è: dipende dalla strategia dall’azienda, dalla dimensione e dall’organizzazione esistente, dalle risorse disponibili, sia umane che finanziarie e – non meno importante – dal tempo a disposizione.

“Il punto è capire che cosa serve al business aziendale e quale opzione permette di gestire meglio l’evoluzione dell’azienda (e quindi le soluzioni applicative) e il rischio che ciascuna comporta”, sottolinea Magnoleretto. 

E questo è un punto su cui tutti i CIO sono concordi.

Buy: il vantaggio dei prodotti standard

“Per un’azienda mediamente complessa, in logica industriale, il Buy è praticamente un obbligo”, osserva Lucio D’Accolti, CIO di AMA Roma (la in-house di Roma Capitale che si occupa di raccolta, trasporto, trattamento, riciclaggio e smaltimento dei rifiuti). Per sviluppare internamente, prosegue D’Accolti “Ci sarebbe la necessità di un elevato numero di competenze diversificate, con maggiori costi dal punto di vista HR. Il Make, a mio avviso, esiste ed esisterà sempre, ma rimane, per noi, intorno al 5% degli sviluppi totali. Invece, a livello di gestione, la percentuale del Make aumenta”.

In alcuni settori regolati, come la sanità, i CIO tendono a comprare soluzioni verticali dei vendor che ritengono “best in class”, perché sono comprovate e tengono conto degli obblighi normativi. Poi, se necessario, vengono richieste al fornitore delle personalizzazioni in base a specifici processi. Ciò richiede una forte collaborazione col fornitore, che diventa un vero e proprio partner. 

Anche per Alessandro Di Maio, CIO di Farvima Medicinali (distribuzione farmaci), la preferenza si indirizza sul Buy.

“Per noi vedo più svantaggi che vantaggi nel produrre in casa”, sottolinea Di Maio. “Più il prodotto da sviluppare è complesso più servono competenze e, se non si è una software house, di solito queste competenze interne sono carenti e occorrerà rivolgersi a consulenti a esterni. Perciò preferisco comprare”.

Il Buy, sottolinea Di Maio, permette di accedere a un prodotto con una tecnologia usata da altre aziende, che ha già superato le fasi di test e le problematiche del primo utilizzo. Questo permette di risparmiarsi il “gap tecnologico” che si ha partendo da zero. Inoltre, si è tutelati sul lato compliance.

Poi c’è la questione della manutenibilità: un prodotto software richiede miglioramenti, fix e aggiornamenti continui. Anche l’infrastruttura sottostante, come il database, richiede manutenzione.

Ancora, è essenziale poter fare riferimento alle persone che hanno sviluppato il prodotto: per questo Di Maio preferisce rivolgersi non solo a fornitori esterni, ma anche a fornitori grandi.

“La scelta del Make è spesso dettata dal desiderio di risparmiare sulle licenze, ma il risparmio è azzerato dai costi della manutenzione e della perdita di know-how dovuta al turnover del personale”, dichiara Di Maio. “Tutto questo crea problematiche che rallentano l’IT e fanno perdere soldi all’azienda, visto che non soddisfa l’obiettivo della tecnologia, che è di servire meglio il business”. 

Questo approccio non esclude ideologicamente lo sviluppo interno, anzi. A Di Maio può capitare di scegliere il Make, ma solo per tecnologie sperimentali di cui il CIO vuole testare la reale utilità per il business prima di decidere l’implementazione. Per esempio, il manager sta sviluppando in house un software per la gestione del cash flow che serve sia all’AD che alla tesoreria.

“I software che si comprano sul mercato richiedono l’assunzione di operatori interni alla contabilità per configurare costantemente il prodotto, perché non c’è una forte componente di automazione, né ci sono vincoli normativi. Allora, in questo caso, lo sviluppo interno per me ha senso”, spiega il CIO. “Inoltre, noi siamo un’azienda con personale giovane e molto votato alla tecnologia. Ma lo sviluppo interno lo riserviamo a prodotti che non fanno parte del core business e non impattano sulla business continuity”.

Make and Buy, approccio misto per portarsi le competenze in casa

Per Davide Alberici, CIO e COO di Desktoo Italia (gruppo PBS Holding AG, distribuzione di prodotti per ufficio), la scelta tra Make o Buy dipende anche dall’investimento che si può fare e dai costi che si possono sostenere.

“Comprare da un grande vendor va bene se mi offre il prodotto di cui ho bisogno e se il costo rientra nel mio budget. Ci sono aziende che non possono permettersi l’investimento e, in questo caso, può convenire appoggiarsi a software house più piccole affiancate da qualche sviluppatore interno. In passato mi sono mosso così: a volte una piattaforma più piccola è esattamente ciò che serve”, Alberici.

Tuttavia, in generale, nemmeno Alberici promuove a pieni voti lo sviluppo interno, perché comporta costi e rischi. Si può, invece, investire in una piattaforma standard e poi portarsi a casa il know-how.

“È così che facciamo noi: io ho nel team alcuni sviluppatori per il nostro sito e-commerce e ho contratti con società esterne per fare sviluppo su specifici prodotti. È in pratica un approccio misto tra acquisto e personalizzazioni, tra competenze interne e consulenze”, tiene a precisare Alberici. “Fare tutto in-house non è sostenibile, c’è sempre un limite a quante competenze si possono possedere, per cui preferisco tenere in casa la parte core e poi avere un mix di persone interne (spesso solo per il project management) e di persone esterne per lo sviluppo delle personalizzazioni. Ritengo questo approccio più flessibile e adatto a un’azienda come Desktoo”.

Make: per alcuni CIO è strategico

Anche per Andrea Pernici, CTO di 3BMeteo (portale italiano di previsioni meteorologiche e società del gruppo Meteosolutions), la scelta tra Make o Buy “dipende” dai casi d’uso e dalle aziende, ma la sua scelta in 3BMeteo è spostata verso il Make.

“Tendenzialmente, il mio approccio sugli asset strategici è Make (e sempre, se possibile, in-house), mentre laddove serve accelerare o velocizzare l’adozione di alcune tecnologie per poi comprenderne l’impatto strategico posso indirizzarmi verso il Buy o Use. Questo ci permette di capire l’effettiva necessità o utilità per poi decidere l’adozione”, rileva Pernici. 

Pernici sottolinea che 3BMeteo preferisce sviluppare con il team interno anche perché questo rappresenta un asset strategico per l’azienda, che svolge molta attività di ricerca e sviluppo. Di conseguenza, i software di gestione contabile e amministrativa vengono acquistati sul mercato, ma gli applicativi legati allo sviluppo del prodotto e al miglioramento della qualità previsionale, oppure le app native, il sito, gli strumenti redazionali e altri software ancora vengono costruiti in casa. 

L’alternativa dello share

Massimo Carboni, vicedirettore e Chief Technical Officer del GARR, la rete italiana dell’istruzione e della ricerca, fornisce un ulteriore punto di vista.

“Nel panorama della trasformazione digitale, la scelta tra costruire o acquistare strumenti e tecnologie digitali assume un ruolo cruciale. Quando questa scelta riguarda le infrastrutture digitali le implicazioni diventano ancora più strategiche. Nel mio caso, come Direttore IT di GARR, devo sottolineare che la nostra capacità di innovare e il ruolo del settore accademico e della ricerca dipendono sempre più dalla nostra capacità di controllare le nostre infrastrutture digitali”, nota Carboni.

“La transizione digitale rappresenta una delle trasformazioni più complesse e rapide della nostra era. I tentativi di regolamentare questo cambiamento richiedono tempo e intanto l’innovazione è diventata per lo più gestita dai giganti del tech e le regole vengono generate ex-post (si pensi al GDPR e al Cloud Act). Spesso il risultato è quello di ostacolare la capacità di innovare in maniera indipendente di altre organizzazioni, come il settore accademico e della ricerca, con regole rigide che incoraggiano l’acquisizione di soluzioni proprietarie. In questo contesto è evidente che riuscire ad adottare soluzioni aperte (open source) diventa quanto mai strategico per poter mantenere l’autonomia decisionale da parte del mondo della ricerca e recuperare la flessibilità che è necessaria per poter innovare”, prosegue il dirigente.

Ma come superare gli ostacoli del Make, che richiede competenze, tempo e denaro? Per Carboni si può considerare una terza opzione, ossia la condivisione (share): mettere a fattor comune le risorse nel settore accademico e della ricerca per avere delle infrastrutture digitali condivise e tecnologicamente indipendenti dal mercato. Ed è questo l’approccio adottato da GARR. La rete, nella sua ultima evoluzione GARR-T (GARR-Terabit, la nuova infrastruttura di rete nazionale per l’università e la ricerca), è stata notevolmente ampliata grazie a fondi dedicati (del PNRR) attraverso un nuovo approccio, preso in prestito dai data center, che ne ha aumentato le prestazioni ma, contestualmente, anche il livello di complessità. GARR ha scelto di investire sia sulle infrastrutture fisiche, con strumenti prevalentemente open source, sia su quelle virtuali e, in particolare, sul capitale umano.

“In questo senso, GARR ha puntato molto sulla condivisione delle conoscenze, acquisendo nuovi talenti (attraverso la GARR DevOps Academy) e assicurando un meccanismo di apprendimento continuo sia all’interno dell’organizzazione sia nei confronti dei tecnici che operano negli enti connessi alla rete”, dice Carboni. “Attraverso lo stesso meccanismo, un lavoro di condivisione delle conoscenze e delle risorse in ambito accademico potrà diventare lo strumento cardine per conservare o riacquisire autonomia decisionale sulle proprie infrastrutture digitali e rimanere determinanti nel poter generare nuova conoscenza in un modo sostenibile da un punto di vista economico, sociale ed ambientale”.

Make or Buy? Questione di risk management

Il mondo della ricerca rappresentato da GARR ha sicuramente delle specificità, ma, in generale, per le imprese, la scelta tra Make or Buy resta un calcolo di costi-benefici o un’operazione di risk management. Lo scopo dell’IT è dare un valore aggiunto al business e questo obiettivo deve guidare la decisione aziendale.

“Nel Make il grande vantaggio è di disegnare un prodotto su misura per la propria azienda: ho esattamente quello che mi serve, la soluzione è centrata sull’operatività del mio business. Se la mia organizzazione è molto specifica, funziona bene e rappresenta il mio valore aggiunto che genera ricavi, la scelta del Make è appropriata”, dichiara Magnoleretto. “D’altro lato, va ricordato che questa è una soluzione esclusiva che va comunque mantenuta e aggiornata e che dipende dalle persone che l’hanno progettata e sviluppata”.

Nel Make occorre garantire la qualità dello sviluppo del software, contrastando il rischio di sacrificarla alla velocità di rilascio, e gestire il rischio di uscita o perdita di competenze sia interne che esterne, documentando attentamente ogni aspetto del prodotto, perché altri potrebbero doverlo far funzionare e modificare in futuro.

Un altro rischio da tenere in conto è la crescita e l’evoluzione dell’impresa: occorre chiedersi quanto velocemente si potrà far evolvere il software fatto in casa e se questo continuerà ad essere funzionale nel momento in cui l’azienda si allarga e presenta esigenze diverse.

D’altro lato, sul fronte del Buy, “si ha la sicurezza di una soluzione standard, che copre molte esigenze, provata da molti, con molti moduli disponibili e fornitori tra cui scegliere”, prosegue Magnoleretto. “I prodotti dei vendor sono anche testati per funzionare nelle diverse regioni del mondo e nativamente supportano più lingue e normative. Se il business è internazionale di solito il Buy è obbligato e risolve molti problemi. E garantisce di avere una soluzione sempre aggiornata anche da un punto di vista fiscale e legale, perché ci pensa il fornitore”.

Ma, avverte il manager, occorre avere una strategia di aggiornamento del prodotto efficace, “cosa che non è sempre una priorità per molte organizzazioni”. Inoltre, “soprattutto nei casi di public cloud, il prodotto è meno personalizzabile, anche se esaustivo e completo. In tanti casi le funzionalità sono così numerose da creare confusione o comunque il rischio di avere moduli che fanno molte cose che non servono al proprio business”.

Un approccio importante da valutare, nel caso si opti per il Buy o un misto Buy/Make, è quello di costruire moduli “esterni” che non vadano a modificare pesantemente dall’interno il software, perché in questo modo si potranno gestire gli aggiornamenti in modo più semplice ed efficace.

In conclusione, non è c’è una scelta migliore, ma c’è un motivo di business che giustifica la scelta. Se il prodotto sviluppato in casa è ciò che fa la differenza e dà competitività all’azienda si procede con il Make (magari non per il 100% delle applicazioni, ci sono aspetti come l’amministrazione che sono abbastanza standardizzati da poter essere coperti adeguatamente da soluzioni standard). Altrimenti è Buy: un prodotto “senza pensieri” sul fronte della manutenzione e degli aggiornamenti, anche se apre il grande capitolo della relazione con i vendor, che non sempre sono disponibili alle personalizzazioni e, nel caso di player molto forti, impongono un prezzo difficilmente negoziabile.