Integrazione o DIS-integrazione?

Integrazione e TCO sono veramente due facce della stessa medaglia?

Una delle viste più classiche dei sistemi a supporto dell’area finance di un’azienda è come quella che vedete qui sotto, sviluppata su tre livelli.

Spesso e volentieri, andando ad analizzare i singoli layer troviamo una eterogeneità di vendor legata a politiche decisionali non sempre coerenti con la minimizzazione del Total Cost of Ownership (TCO) e con la massimizzazione dei benefici per gli utilizzatori delle varie applicazioni.

Le stesse filosofie IT o di business che negli anni possono variare, anche per cambiamenti nelle figure apicali, non aiutano a compiere queste scelte con spirito di efficienza.

Senza considerare le pluralità di sistemi che i gruppi di aziende si trovano a gestire a seguito di acquisizioni che si sono succedute nel tempo.

Integrazione o Best of Breed?

Volendo in prima battuta semplificare, potremmo schematizzare queste filosofie di scelta con due estremi opposti sulla carta:

• Best of breed
• Integrazione

Nel primo caso si tende a scegliere la soluzione che, di volta in volta, sul mercato meglio si adatta alle esigenze del business, mentre nel secondo, vi è un cambiamento di visione nell’effettuare la scelta del software e si tende a coprire più processi possibili con quanto il vendor offre.

Non penso esista una filosofia migliore. Ritengo che ogni situazione abbia peculiarità da analizzare nel contesto di business specifico.

Ho visto negli anni progetti di integrazione naufragati a seguito anche di continui cambiamenti nelle società di consulenza che avevano in carico la delivery progettuale e progetti “verticali” causare costi di manutenzione così alti da dover valutare una rivisitazione dell’intera mappa applicativa per risolvere l’ingestibilità dell’insieme.

Sono convinto che scelte di questo tipo non possano essere fatte esclusivamente seguendo dinamiche applicative (road map di prodotto, integrazione tecnologica, …) perché l’analisi delle caratteristiche dei processi che queste applicazioni devono supportare deve rimanere prioritaria.

Un software a supporto del processo: non viceversa

Non è possibile fare scelte applicative trascurando totalmente l’anima del processo che queste applicazioni devono supportare.
Perché è il processo che deve essere supportato dal software, non viceversa. (Qui un piccolo approfondimento in merito!)

Quasi mai è corretto stravolgere i processi aziendali per adattarli a quanto il software è in grado di offrire. Sicuramente nel corso degli anni i processi aziendali meritano una rivisitazione sia in termini di governance che di flusso di attività. 

Questo non significa che possano essere violentati semplicemente perché la scelta di un’azienda è di prendere quel software che su quel processo specifico ha poco o niente da offrire.

Ciò non si muove nella direzione della minimizzazione del TCO e nella massimizzazione dei benefici degli utilizzatori.

Più di una volta ho visto aziende fare scelte passandole sotto il cappello dell’integrazione per poi customizzare vaste aree di processi finance solo perché il vendor specifico aveva poco da offrire in quei contesti ma almeno si manteneva il rapporto con un solo vendor perseguendo il “falso mito dell’integrazione”.
Perché in questi casi, oltre ai costi legati alle varie customizzazioni (sia di prima delivery ma, soprattutto, di maintenance), si devono sostenere anche quelli legati alla probabile inesperienza del vendor (perché se ha poco da offrire su un processo specifico è probabile che il riflesso si trovi anche sull’esperienza che questo possa portare sul campo).
Senza contare gli effetti sui processi di business che questo software deve supportare e sulla relativa soddisfazione degli utenti.

E’ chiaro che in un contesto di non semplice lettura anche la scelta di operare di default con il best of breed può portare solo ad una eccessiva frammentazione delle applicazioni perdendo il beneficio dell’integrazione che rimane, comunque, uno degli elementi di attenzione massima nell’ottica della minimizzazione del TCO.

Certo non può e non deve essere considerata un fattore d’integrazione la scelta di un unico vendor su tutte le aree ERP, CPM e BI. 

Semplicemente perché è falso.

I vendor, pur rimanendo sotto il solito nome, propongono software differenti a copertura delle differenti aree che quasi mai sono integrati e che neanche hanno road map di prodotto compatibili.

Ciò è tanto più vero quando maggiore è la ricerca di una integrazione verticale (cross tra i 3 layer prima elencati) piuttosto che una orizzontale (all’interno dello stesso layer).

Integrazione orizzontale e verticale

La mia personale esperienza ventennale nel campo delle applicazioni a supporto del mondo finance mi consente di riconoscere quando la leva dell’unificazione sotto un unico vendor è più una chiave commerciale che, non, di effettiva ricerca di benefici duraturi per l’intero ecosistema azienda.

Come già scritto prima ritengo, allo stesso tempo, impossibile identificare una visione che sia corretta in tutti i contesti.

Sono, però, convinto che non esista un unico vendor sul mercato capace di coprire tutti i layer, di cui in precedenza, nell’ottica della massimizzazione dei benefici complessivi. E, se l’integrazione deve essere ricercata (e va fatto), deve essere di tipo orizzontale, non verticale, essendo presenti sul mercato software capaci di coprire egregiamente i layer presi singolarmente ma non tutti assieme.

Anche perché pur scegliendo il medesimo vendor a copertura dei 3 layer, i prodotti forniti sono differenti e ad oggi non esiste integrazione tra questi nel senso pieno del termine.

La scelta di una società capace di indirizzare le scelte penso che sia di fondamentale importanza nella rivisitazione del landscape applicativo. Anche qui, però, attenzione massima ai partner di riferimento perché spesso e volentieri si cade nella rete del guardiacaccia che diventa bracconiere proponendo ciò che è più conveniente per le proprie tasche invece che per quelle dell’azienda che dovrebbe consigliare.

Ma questa è un’altra storia…