Quando conviene l’outsourcing

Decisiva per il successo dei progetti It è, spesso, la scelta tra internalizzare ed esternalizzare. L’argomento make or buy ne tocca, poi, numerosi altri, come la redazione del budget It, l’individuazione dei fornitori, le priorità tecnologiche, che saranno esaminati nelle prossime puntate.

Make, buy or rent: la teoria…
In un mondo perfetto, la scelta tra svolgere all’interno determinate attività o farle effettuare da terzi dovrebbe essere presa secondo criteri di efficienza misurabili e verificabili. Il business case (basato su tutti i criteri che giustificano una certa decisione, non solo economici) ha il compito di dire se un progetto conviene o meno, ma anche quale grado di impegno è necessario a realizzarlo in confronto ai benefici attesi. Potrebbe, infatti, emergere che economicamente l’iniziativa è sostenibile, ma richiede un tempo di realizzazione non compatibile con gli obiettivi di business dell’azienda.

Anche se l’utilizzo di una qualche forma di supporto razionale alle decisioni si va diffondendo, manca ancora in molti casi una visione di insieme dei sistemi informativi e di conseguenza la definizione di criteri di scelta specifici e condivisi all’interno dell’organizzazione. Da qui si originano situazioni in cui, ex post, risulta che, pur avendo utilizzato strumenti assolutamente razionali, i benefici derivanti dai progetti sono ben inferiori a quanto atteso.

La situazione è ulteriormente complicata dal fatto che internalizzare non significa fare “tutto” in casa, ma bilanciare in misura la gestione del progetto e le attività di realizzazione tra azienda e fornitori esterni. L’outsourcing, poi, deve essere considerato rispetto a diversi aspetti, in primis l’importanza dei processi: quelli non core sono i candidati naturali a essere esternalizzati, per motivi sia di carattere economico (possono essere gestiti in modo più efficiente da società specializzate) sia organizzativo (per non perdere competenze fondamentali).

Vanno anche tenute in considerazione valutazioni di lungo periodo, se esistano i presupposti affinché la scelta effettuata possa generare benefici in maniera sostenibile nel tempo, e considerata la reversibilità della decisione, vale a dire se i costi da sostenere per rientrare nel controllo diretto del processo non superano i vantaggi ottenuti fino a quel momento.

…e la pratica
Nella pratica, le cose vanno diversamente, e le esperienze vissute sul campo ne sono testimonianza.
Ad esempio è stato interessante l’approccio seguito da un’importate azienda italiana nella realizzazione di una piattaforma per la gestione incassi e credito.

L’opzione fra sviluppare internamente o acquistare un pacchetto ha seguito un criterio molto semplice, in apparenza: l’estensione della copertura funzionale del sistema. I sistemi legacy (tutti di tipo custom) erano, infatti, indicati come inadeguati e da sostituire in toto. L’opzione big bang era, quindi, ideale per effettuare una scelta estranea alle logiche del passato e allo stesso tempo permetteva di avere le mani libere riguardo ai fornitori.

Il processo decisionale è stato articolato in vari step operativi:

• conduzione di uno screening dei diversi prodotti disponibili sul mercato;
• redazione di una mappa di copertura dei prodotti selezionati;
• organizzazione di demo e interviste con i referenti dei prodotti “finalisti”;
• scelta del prodotto “vincitore”.

Non è stata presa in considerazione la scelta make or buy, ma data per scontata la seconda opzione. Nella realtà, però, l’opzione make è rientrata dalla finestra allorché al termine del processo di valutazione è emerso chiaramente che nessun prodotto sul mercato garantiva una copertura funzionale in linea con le esigenze dell’azienda.

Nel complesso, quindi, il processo decisionale è durato alcuni mesi, durante i quali le attività di implementazione sono rimaste in stand-by, il che ha portato a uno slittamento in avanti del delivery del nuovo sistema agli utenti. Inoltre, la scelta finale si è basata più su considerazioni funzionali che su aspetti architetturali ed economici di lungo periodo.

È, quindi, opportuno stabilire in partenza una soglia minima accettabile di copertura funzionale, da confrontare con costi e benefici di ciascuna opzione, e definire e comunicare internamente, fin dal principio, procedure e tempi del processo di valutazione secondo un criterio di trasparenza, su cui recepire eventuali feedback e osservazioni da parte delle unità organizzative coinvolte.

Cosa dare in outsourcing?

Numerose aziende, invece, hanno deciso di esternalizzare alcune fasi dello sviluppo software o addirittura l’intero processo, in base all’approccio che vede l’It nell’ottica cliente-fornitore, cioè come un fornitore di servizi all’organizzazione sulla base di un input (i requisiti) prodotti dal cliente.

Una logica conclusione del ragionamento ha portato alcune organizzazioni ad affidare non singole applicazioni all’esterno e neppure determinate fasi di realizzazione (ad esempio lo sviluppo e i test), bensì l’intero processo e la relativa struttura organizzativa. In un’importante società, in cui il peso dell’It è determinante per il raggiungimento dei suoi obiettivi di business, ad esempio, la scelta di esternalizzare è stata presa sulla base di ponderate valutazioni di tipo tecnico, economico e di competenza.

Le considerazioni effettuate si sono legate alla frammentazione dei fornitori, ognuno dei quali richiede sforzi non indifferenti da parte dell’azienda sia dal punto di vista amministrativo che tecnico (si pensi alle valutazioni su affidabilità, rispetto delle scadenze, tempestività nella risoluzione dei problemi e così via), la molteplicità delle applicazioni, la complessità dei sistemi e altro ancora.
L’obiettivo principale della decisione è stato, quindi, quello di ridurre la complessità e abbassare i costi.

A distanza di qualche tempo, si è visto che entrambi gli obiettivi erano stati raggiunti solo parzialmente. La limitazione dei costi è stata inferiore alle attese in quanto, se il numero dei fornitori era effettivamente inferiore, gli effort medi di realizzazione delle iniziative (cioè quanto viene speso per implementare i requisiti) non si erano abbassati nella misura sperata.

La riduzione di complessità, poi, si è verificata dal punto di vista tecnico, ma non da quello dell’organizzazione nel suo complesso, dal momento che l’It (a ranghi ridotti in conseguenza dell’esternalizzazione) ha dovuto fronteggiare vari problemi, tra cui il mancato rispetto dei tempi, la non rispondenza delle applicazioni ai requisiti. La complessità si è “spostata” cioè dall’aspetto tecnico a quello del program & project management.

Ma esistono anche casi in cui una vera e propria scelta non viene effettuata, per lo meno in senso “binario”. Un operatore di telefonia ha, ad esempio, scelto di tenere in casa tutta la struttura It, mettendo in atto una strategia in apparenza di puro make. Ciò non significa, tuttavia, che le attività It vengono interamente svolte all’interno dell’organizzazione e nemmeno che siano eseguite da membri dell’organizzazione. Quello che avviene in azienda è la pianificazione dei progetti, la valutazione degli impatti e lo studio di fattibilità delle nuove iniziative (in parte) e il project management.

Le attività operative, sia di analisi funzionale e tecnica, sia di sviluppo e test, sono affidate a entità esterne. In questo contesto, la scelta make or buy è stata compiuta a livello strategico secondo linee orizzontali (la tipologia di attività) anziché verticali (il progetto It), sulla base di un business case “tipo” secondo il quale le attività di più alto livello devono essere svolte all’interno, mentre è più conveniente esternalizzare quelle “operative”.

Un approccio che si è rivelato stabile nel tempo (non ha richiesto particolari ripensamenti), niente affatto controcorrente ma, anzi, piuttosto comune nelle aziende in cui l’It rappresenta una grossa componente del valore aggiunto “interno”, e in cui il rapporto con il resto dell’organizzazione è rigidamente di tipo cliente-fornitore.

Conclusioni
Di seguito, alcune linee guide che possono essere utili nel valutare le attività da fare internamente o da esternalizzare:

• Effettuare scelte di lungo periodo: è inutile valutare il make or buy per ogni singola iniziativa. La decisione deve essere presa in chiave strategica e, poi, applicata alle diverse situazioni. Se ad esempio si è scelto di acquistare uno o più prodotti per la gestione di un processo, è un controsenso sviluppare in casa un software che supporta lo stesso processo;
• Rivedere con cadenza prefissata i criteri di scelta per verificare la loro validità;
• Se si sceglie l’opzione make, fare un assessment dettagliato delle competenze presenti all’interno, capire come procurarsi quelle mancanti di tipo tecnico e di project and program management;
• Nelle scelte di outsourcing, selezionare in primo luogo i processi da esternalizzare piuttosto che i sistemi. Considerare nella valutazione dei risultati del business case tutti i possibili costi e benefici, come il costo derivante dalla perdita di competenze interne e/o di capacità formative verso i membri dell’organizzazione;
• Rafforzare le competenze interne di project and program management per far fronte all’esternalizzazione delle attività e alle complessità gestionali che derivano dall’outsourcing

• Outsourcing? Il segreto è rinegoziare
• Outsourcing, consigli per l’uso
• Le domande da porsi per un corretto outsourcing