Interoperabilità dei sistemi informativi aziendali Considerazioni generali sugli aspetti legati alle possibilità di integrazione e interoperabilità tra sistemi informativi aziendali

Questo articolo, inizialmente scritto come parte di una serie di approfondimenti dedicati all'architettura dei calcolatori, è dedicato al tema dell'interoperabilità tra sistemi informativi aziendali, ovvero alla possibilità di mettere in comunicazione sistemi diversi.

L'obiettivo è quello di mettere a fuoco l'insieme di problematiche connesse ai principali progetti di system integration e le loro possibili soluzioni, nonché di evidenziare l'insieme di vantaggi che questo tipo di soluzioni possono portare in termini economici e operativi qualora si riesca a tenere sotto controllo l'inevitabile aumento del livello di complessità.

Definizione

Come sempre quando si affronta un argomento complesso è bene partire dalle definizioni: partendo da una prospettiva economico/aziendale è ragionevole affermare che il termine interoperabilità esprime il concetto di permettere l'interscambio e l'interazione di dati, informazioni e output di processo tra sistemi diversi attraverso un set standardizzato di interfacce comuni.

Se invece vogliamo partire dal punto di vista dell'utente, potremmo definire l'interoperabilità come la capacità di un sistema o prodotto di operare con altri in modo trasparente, ovvero senza che questo richieda sforzi particolari da parte di chi usufruisce del servizio. Questa seconda definizione è più facile da comprendere in quanto è direttamente osservabile nel mondo che ci circonda, a partire dalla nostra stessa vita quotidiana: nel momento in cui utilizziamo il nostro bancomat in una banca diversa dalla nostra stiamo sfruttando l'interoperabilità del sistema bancario, ovvero la capacità del sistema informativo della nostra banca di interfacciarsi efficacemente con quello della banca con cui stiamo operando; quando facciamo un viaggio all'estero e utilizziamo il nostro smartphone per chiamare in Italia stiamo sfruttando l'interoperabilità dei servizi di telefonia a livello mondiale, ovvero la capacità del nostro operatore telefonico di interfacciare la propria rete con quella dell'operatore presente nel paese di destinazione; e così via.

Partendo dalle due definizioni appena formulate e assumendo un punto di vista più generale potremmo dire che l’interoperabilità si presenta come uno strumento per gestire il coordinamento tra processi produttivi condotti tra diversi soggetti: una governance che, inevitabilmente, tende ad aumentare di complessità a seguito del sussistere (o del verificarsi) dei seguenti fattori-chiave:

• l'aumento del numero dei sistemi coinvolti
• la diminuzione del tempo di svolgimento dei singoli processi da integrare, ovvero l'ottimizzazione (e, più in generale, l'evoluzione) degli stessi.

Come si può facilmente notare, entrambi i fattori saranno in parte noti a priori ma, al tempo stesso, potranno essere soggetti a cambiamenti nel corso del tempo. Questi cambiamenti, per forza di cose, non saranno sempre prevedibili al momento della progettazione della soluzione di interoperabilità e alla sua scomposizione operativa in system integration task, specialmente se i sistemi coinvolti operano nell'ambito dell'information technology o in altri settori ad alto tasso di innovazione.

Un approccio "Agile"

Per questo motivo, nella pianificazione strategica di questi progetti, è fondamentale adottare un approccio metodologico che preveda la possibilità di gestire il cambiamento durante lo sviluppo delle system integration task: questa esigenza è del resto ampiamente nota già da molti anni, come dimostra la crescita esponenziale dell'adozione delle metodologie Agile (per la scomposizione degli item di lavoro in task), DevOps (per la gestione efficiente del ciclo di vita della soluzione e della sua manutenzione evolutiva, ottenuta mediante l'adozione di processi strutturati di continuous integration e/o continuous deployment), LEAN (per l'ottimizzazione dei tempi e la riduzione degli sprechi durante le attività di sviluppo) e altri approcci similari da parte dei CTO e Project Manager più capaci ed aggiornati.

Opportunità o necessità?

Uno dei temi che vengono più frequentemente sollevati quando si discute di interoperabilità tra sistemi è quello relativo all'opportunità, per una azienda, di intraprendere un percorso di questo tipo. Si tratta di un tema solitamente molto caro al risk management, che non di rado tende a inquadrare il discorso adottando una prospettiva che concentra l'attenzione sui potenziali utili che questo tipo di operazioni può comportare: non necessariamente da intendere in senso economico, ma anche di posizionamento, visibilità aziendale, opportunità di mercato, e tutti gli altri vantaggi che l'interoperabilità tra sistemi può ragionevolmente comportare.

Al tempo stesso, è bene sottolineare come sempre più spesso la gestione ed il governo dei processi economici delle aziende private e pubbliche richiedano la cooperazione tra aziende e la condivisione di informazioni, in relazione all’organizzazione dei processi produttivi non interamente gestiti all’interno di una unica azienda ma entro reti di aziende. Non di rado, infatti, questi "processi condivisi" devono sottostare a un set di regole e/o normative comuni dettate dal potere legislativo nazionale o transnazionale. Per fare un esempio di facile comprensione si pensi al GDPR e alle relative modifiche della normativa privacy nei vari paesi UE, che prevedono modalità di trattamento dei dati che non possono prescindere da una stretta collaborazione tra il titolare e il responsabile del trattamento. Appare evidente come, in ottica di contenimento dei costi e degli oneri di servizio, queste modalità necessitino di un sistema di interfacce di comunicazione standardizzate e adottate da tutti gli attori che compongono il sistema: in tutti questi casi la system integration cessa di essere "soltanto" un'opportunità, diventando a tutti gli effetti una necessità di cui l'azienda non può più permettersi di fare a meno.

Assessment, Audit e Due Diligence

La necessità di intraprendere un percorso di interoperabilità dei sistemi diventa particolarmente impellente quando il sistema è sottoposto al controllo e/o al coordinamento di un definito soggetto che, per ruolo giuridico o per posizione economica, ha la possibilità di indurre o addirittura imporre procedure, sistemi informativi e requisiti funzionali che rendano indispensabile l'ottenimento di un certo livello di interoperabilità tra i singoli attori. E' il caso dei sempre più frequenti controlli che le multinazionali sono tenute a svolgere nei confronti dei loro fornitori locali, che solitamente assumono la forma di Security Assessment, Compliance Assessment, Quality Assessment e così via, quando non di rilevazioni (Audit) o vere e proprie attività di investigazione da compiere on-site (Due Diligence).

Negli ultimi anni chiunque lavori a stretto contatto con clienti enterprise ha certamente notato un incremento esponenziale di questi controlli, che non di rado mettono a dura prova le realtà aziendali medio-piccole in quanto prevedono, per essere completati con successo, la produzione di una serie di evidence non banali che certifichino la capacità del fornitore di poter operare nel rispetto di standard di processo molto rigorosi: si tratta di un problema che in Italia è particolarmente sentito, stante la presenza di moltissime piccole aziende (si pensi alle PMI, che costituiscono oltre il 92% del settore industriale italiano) che operano in ambito locale come contractor di company di tipo Enterprise offrendo tariffe estremamente competitive proprio in quanto dotate di una struttura operativa più leggera e che pone molta meno enfasi sul controllo e sulla standardizzazione dei processi.

Dall'Interoperability all'Intercooperability

Questa sinergia tra big company e small company, che ha consentito alle prime di risparmiare moltissimi soldi affidando in outsourcing alle seconde la maggior parte delle proprie attività, rischia di venire meno nei prossimi anni, stante l'impossibilità da parte di qualsiasi piccola azienda di dotarsi di meccanismi di governance enterprise e di tutte le risorse (in primis di personale) che questo "cambio di paradigma" andrebbe inevitabilmente a comportare. In questo senso una strategia basata su una forte interoperabilità tra sistemi potrebbe essere una via d'uscita, poiché consentirebbe di rimettere in carico al "committente" tutti gli aspetti più critici connessi alla gestione dei dati: ad esempio, implementare l'interoperabilità dei servizi web attraverso un sistema di API REST potrebbe consentire al fornitore di recuperare i dati in tempo reale anziché memorizzarli internamente, facendo venire meno i trattamenti legati alla conservazione dei dati e, di conseguenza, la necessità di applicare algoritmi di Data Encryption In-Transit sui propri database locali; oppure, realizzare un progetto di system integration con il sistema di autenticazione utente in esercizio presso il committente potrebbe sollevare il fornitore degli oneri legati alla gestione degli account e degli accessi dei propri operatori, evitando costosi adeguamenti sia funzionali (password expiration, password failure count, 2-factor authentication, etc.) che operativi (decommissioning, access list, etc.); e così via. Più in generale, si tratta di implementare soluzioni di interoperabilità volte a limitare al massimo non soltanto l'intervento umano e le possibilità di errore, ma anche e soprattutto il sostrato di accountability legato alla necessità di dotarsi di sistemi gestionali, tecnologici e informativi autonomi, nonché di sviluppare le soluzioni e le procedure connesse - e sostenerne i relativi costi.

Si tratta però di soluzioni che non possono prescindere da un profondo ripensamento del rapporto tra le parti, le quali dovranno necessariamente superare la mentalità del committente/fornitore e adottare un paradigma di azione comune, ragionando in modo sinergico su tutti gli aspetti legati al cambiamento: economici ("chi paga i costi di queste implementazioni?"), ma anche amministrativi ("che tipo di garanzie contrattuali predisporre a tutela delle parti?"). Si va quindi necessariamente verso un contratto-quadro, che in taluni casi potrebbe persino porre le basi per una acquisizione prossima ventura: è infatti assolutamente indubbio che il committente dovrà farsi carico del percorso di evoluzione del fornitore.

Nei casi come quello appena descritto, parlare di interoperabilità dei sistemi, o dei processi, appare quantomai riduttivo, oltre che sostanzialmente inefficace: il percorso completo non può prescindere da una interoperabilità di scopo, da intendersi come una condivisione degli obiettivi di medio e lungo periodo (e di conseguenza degli utili, ovviamente con le debite proporzioni). La interoperability lascia dunque spazio a un concetto nuovo e ulteriore, che per semplicità chiameremo intercooperability, basata sul consenso (e sull’interesse) reciproco e non sulle necessità (o sulla supremazia) di un'azienda sull'altra: una sfida di gran lunga più difficile e ambiziosa di qualsiasi attività di system integration, ma che alla luce del periodo attuale potrebbe essere necessario vincere per garantire la sopravvivenza di un ecosistema che rischia l'estinzione.

Interoperabilità: caratteristiche strutturali

Dopo aver messo a fuoco gli obiettivi di massima che una interoperabilità "ecologica" dovrebbe avere e le difficoltà intrinseche questo tipo di approccio in settori industriali caratterizzati da un rapporto di forze particolarmente sbilanciato come nei casi di delocalizzazione (e deregolamentazione) più marcati, proviamo a stilare un piano d'azione. Al fine di poter effettuare un'analisi economico-aziendale delle soluzioni che permettano la intercooperabilità teorizzata nel paragrafo precedente può essere utile provare a stilare una mappa concettuale che metta a fuoco tutti i principali componenti del sistema:

• Ampiezza dell'applicazione a livello intra-organizzativo e inter-organizzativo: in altre parole, i soggetti coinvolti  e le loro caratteristiche.
• Tipologie di interoperabilità: tecnologica, organizzativa, semantica.
• Linea di sviluppo: orizzontale o verticale.
• Filosofia di sviluppo: aperta o chiusa.
• Fonte di regolazione: normativo (imposto dall'alto / necessità) o volontario (deciso dal soggetto / opportunità).
• Soggetto guida: pubblico o privato.
• Governance: pubblica o privata (e, se privata, guidata da un leader o cooperativa).
• Orientamento: seller oriented, buyer oriented, third-party oriented (profit o non-profit).

Questi punti costituiscono il set minimo di aspetti da analizzare al momento di effettuare l'analisi di fattibilità alla base del percorso di interoperabilità che si è scelto di (o si è stati obbligati a) intraprendere; non prenderli in considerazione o non valutarli correttamente aumenta a dismisura i rischi connessi all'intera attività e potrebbe comportare conseguenze gravi, tra cui il fallimento del progetto ovvero il suo completamento con effetti molto diversi da quelli auspicati.

Interoperabilità intra-organizzativa: il caso italiano

Come recita un famoso proverbio tedesco, l'orbo ci vede più in casa sua che non Argo in casa d'altri. Questa breve massima aiuta a comprendere un concetto già di per sé piuttosto ovvio: la pianificazione strategica di un progetto di interoperabilità tra molteplici aziende diverse è enormemente più complessa di un piano di integrazione dei processi interni, ovvero da realizzare internamente a una singola azienda: specialmente se si tratta della propria. Partendo da questo assunto, è ragionevole affermare anche che chiunque non sia in grado di portare a termine un progetto di integrazione interno non dovrebbe essere incaricato di gestire progetti che coinvolgano una pluralità di attori.

D'altronde, chi pensa che la razionalizzazione e standardizzazione di processi intra-organizzativi sia un compito semplice rischia di andare incontro a grosse delusioni: per comprendere meglio questo concetto, è utile prendere ancora una volta a modello un settore industriale culturalmente "in via di sviluppo" come quello delle PMI italiane.

I sistemi informativi aziendali delle imprese tendono ad essere sviluppati in modo incrementale, ovvero per aggregazioni successive di componenti applicativi differenti che vengono sviluppati (o acquistati) in momenti temporali diversi, quasi sempre al fine di soddisfare specifiche esigenze o necessità (efficientamento della produttività, risoluzione di problemi, etc.). Questi componenti, fortemente caratterizzati dal punto di vista funzionale, formano dei veri e propri "sottosistemi operativi": logistica e servizi generali, contabilità, acquisti, risorse umane, gestione magazzino, e così via: un vero e proprio "arcipelago" di prodotti diversi, che non di rado, benché utilizzati internamente dalla medesima azienda, non prevedono alcuna modalità di system integration per una serie di motivi apparentemente validi: vengono utilizzati da operatori diversi, all'interno di reparti o uffici operativamente "isolati" rispetto al resto dell'azienda, e così via.

L'approccio "atomico" all'organizzazione aziendale, e di conseguenza al sistema informatico aziendale, è una caratteristica sorprendentemente comune nelle PMI, in quanto si tratta di realtà che adottano di frequente al loro interno una struttura organizzativa altamente verticistica e piramidale: un management che prende le decisioni, un pugno di funzionari che si occupa di tenere alta la produttività e una schiera di operativi che svolge la quasi totalità del lavoro.

In un quadro del genere, stante l'assenza di figure che si occupino di curare le relazioni umane, definire modelli di team building inter-aziendale o anche solo coordinare i processi e i sistemi, è facile immaginare come la comunicazione tenda a svilupparsi in senso verticale. A questo si aggiunge il fatto che, tra le poche decisioni che i funzionari sono autorizzati a prendere, vi è quella del software da utilizzare per organizzare il lavoro del proprio team: per esercitare quella (limitatissima) autorità è sufficiente ottenere l'approvazione dall'alto, senza alcun apparente bisogno di consultarsi o coordinarsi con gli altri reparti. L'esigenza di standardizzare i processi, o quantomeno il software, non è del resto quasi mai sentita neanche dal management, che tende a concentrarsi sulla produttività a corto raggio (non di rado in ottica di bonus/dividendi da ottenere).

Il triste risultato di questo modus operandi (o modus regendi, visto che si parla di responsabilità del management) è che ad oggi l'organizzazione aziendale del nostro paese risulta quasi sempre priva, perlomeno in ambito PMI, della maggior parte delle figure-chiave per gestire in modo corretto un progetto di system integration inter-aziendale:

• Il Chief Technical Officer (CTO), figura quasi sempre assente o ridotta al ruolo di "responsabile IT", rigorosamente posta al di fuori del CDA e quindi privata di tutti gli aspetti strategico/decisionali.
• Il Chief Information Officer (CIO), quasi sempre assente o "spezzettato" nelle sue mansioni più banali tra responsabile IT, responsabile privacy e amministratori di sistema.
• Il Chief Innovation Officer (CInO), quasi sempre "sostituito" dall'amministratore delegato e/o dal CDA, che però raramente possiedono gli strumenti necessari per svolgere un lavoro così specifico e delicato come la gestione dei processi di innovazione tecnologica e digitale.
• Il Chief Operating Officer (COO), quasi sempre rimpiazzato dai singoli funzionari, che mancano però della visione d'insieme necessaria per svolgere tale funzione in modo "orizzontale", oppure (ancora una volta) dall'AD e/o dal CDA, i quali tenderanno inevitabilmente a favorire una "disgregazione" dei processi interni a vantaggio della produttività.

Le poche realtà che riescono a compensare queste "mancanze" in modo efficace sono quelle che hanno al loro interno un amministratore (o un funzionario) che abbia non soltanto ricoperto in precedenza quei ruoli, ma che disponga anche delle forze e delle capacità di svolgere due (o più) lavori contemporaneamente. In tutti gli altri casi, che sfortunatamente ad oggi rappresentano la maggioranza assoluta, l'azienda non ha modo di garantire una inter-operabilità interna, e non ha dunque nessuna possibilità di mettere a punto un piano di system integration con sistemi informativi di altre aziende nel modo corretto.

Tipologie di Interoperabilità

L’approccio dell’UE in merito all'interoperabilità opera tre importanti distinzioni, mettendo a fuoco tre elementi che contraddistinguono questo tipo di attività e che meritano una trattazione distinta:

• Organizational Interoperability (interoperabilità organizzativa), definita come la possibilità delle aziende di far interagire tra loro i vari processi produttivi al fine di raggiungere obiettivi comuni, anche a prescindere dalla eventuale diversità delle piattaforme e infrastrutture tecnologiche.
• Semantic Interoperability (interoperabilità semantica), che si concentra sulla condivisione del significato delle informazioni scambiate, ponendosi come obiettivo quello di assicurarsi che questo sia comprensibile e univocamente determinato tra tutti gli attori coinvolti nel processo.
• Technical Interoperability (interoperabilità tecnica), che ha lo scopo di connettere in modo efficace sistemi diversi per mezzo di interfacce comuni, così da poter assicurarne il funzionamento in maniera unitaria e coordinata.

Un esempio di interoperabilità semantica con cui docenti e studenti delle università italiane si confrontano da qualche anno è quella alla base del sistema European Credit Transfer and Accumulation System (ECTS): un meccanismo di mutuo riconoscimento degli esami universitari all’interno del sistema dei settori scientifico-disciplinari, che funziona attraverso un meccanismo di attribuzione di "crediti formativi" (CFU) riconosciuti dai diversi atenei a prescindere dallo specifico nome dato all’insegnamento.

Questo esempio ci aiuta a comprendere come le tre dimensioni siano tra loro intrinsecamente e inevitabilmente collegate: al fine di ottenere il mutuo riconoscimento di una formazione accademica (interoperabilità semantica ) è necessario prevedere un meccanismo comune di crediti formativi accettato da tutti gli istituti aderenti (interoperabilità organizzativa); ma questo meccanismo, per funzionare, ha inevitabilmente bisogno di una piattaforma comune da utilizzare per lo scambio di informazioni a cui tutti i sistemi dovranno poter accedere in lettura e in scrittura (interoperabilità tecnica).

Linea di sviluppo

Un aspetto fondamentale da tenere in considerazione nello studio di fattibilità di un progetto di interoperabilità inter-aziendale è quello relativo all'appartenenza o meno delle aziende coinvolte al medesimo settore e/o filiera produttiva. Nel caso in cui gli attori coinvolti (e relativi processi) facciano parte dello stesso settore è corretto parlare di interoperabilità verticale; viceversa, se l'integrazione riguarda i processi comuni di aziende che operano all'interno di diversi settori, quello che va realizzato è un percorso di interoperabilità orizzontale.

Un esempio di interoperabilità verticale può essere quello risultante dall'obbligo, introdotto nel 2014, di trasmettere all'anagrafe tributaria i dati relativi ai contratti e ai premi assicurativi da parte di tutte le imprese assicuratrici (rif. prot. 160381/2014): la trasmissione prevede l'invio di un file tracciato avente caratteristiche standard che ha costretto le singole assicurazioni ad adottare interfacce di compilazione e trasmissione comuni; allo stesso tempo, però, si tratta di un processo di standardizzazione verticale poiché riguarda soltanto quello specifico settore.

Un esempio di interoperabilità orizzontale è invece quello rappresentato dalla necessità, comune a tutte le aziende italiane, di trasmettere per via telematica alcuni aspetti contabili e amministrativi relativi ai propri dipendenti e collaboratori (agli enti previdenziali, all'agenzia delle entrate, e così via). In questo caso si tratta dei medesimi obblighi, orizzontalmente validi per tutti i settori.

Confrontando opportunamente questi esempi è già possibile notare una importantissima differenza:

• nel primo caso (interoperabilità verticale) il percorso di adeguamento ha costretto gli attori coinvolti (le imprese assicuratrici) a modificare i propri processi interni, internalizzando l'attività o chiedendone (e verificandone) l'implementazione ai propri fornitori di servizi. Questo avviene perché si tratta di un processo particolarmente importante per l'azienda, riguardando un numero significativo di documenti e/o informazioni relative a processi produttivi caratteristici e non di rado critici: per questo motivo, la sua applicazione è spesso portatrice di apprezzabili guadagni in termini economici, di efficienza e/o di governance dei dati. Nel caso di specie, il processo è necessario per evitare sanzioni potenzialmente anche molto onerose ed ha quindi un impatto rilevante in termini di analisi del rischio.
• nel secondo caso (interoperabilità orizzontale) il processo è quasi sempre affidato a intermediari esterni come commercialisti, consulenti del lavoro e via dicendo. Questo avviene poiché si tratta di un numero limitato e definito di transazioni, il cui trattamento avviene secondo modalità cicliche e in gran parte ripetitive, non presentando così un interesse rilevante per la singola azienda. Anche gli aspetti legati ai rischi di un'errata o mancata trasmissione tendono ad essere trascurabili, in quanto l'ordinamento prevede una responsabilizzazione diretta del professionista incaricato in caso di inadempienze, con ricadute minime sul cliente.

Le conclusioni che abbiamo tratto sono ovviamente di natura tendenziale: esistono infatti alcuni casi particolari in cui soluzioni orizzontali possono determinare rischi e/o opportunità di impresa rilevanti al punto da rendere conveniente un'integrazione delle stesse a livello dei processi aziendali. E' il caso della recente esperienza legata all'introduzione della fatturazione elettronica in italia, che ha contribuito a rivoluzionare la gestione della documentazione fiscale attiva e passiva inter-aziendale, comportando numerosi cambiamenti operativi nei processi interni di aziende di tutte le dimensioni.

Filosofia di sviluppo

Un altro aspetto importante da considerare è quello della filosofia di sviluppo, per stabilire il quale occorre rispondere alla seguente domanda: chi potrà interagire con le specifiche di integrazione che andremo a definire (e relative documentazioni, interfacce, API, etc)?

• Se la risposta a questa domanda è di tipo eager, ovvero "soltanto chi concorre a definirle", ci troviamo di fronte a una interoperabilità chiusa.
• Se la risposta è di tipo lazy, ovvero "chiunque ne abbia necessità", significa che ci si muove verso un progetto di interoperabilità aperta.

Una interoperabilità chiusa tende a rendere le attività di system integration più difficoltose e costose, mentre un'interoperabilità aperta è solitamente più semplice e rapida da implementare.

Un esempio estremo di interoperabilità chiusa e di interoperabilità aperta può darsi nel caso dell'adozione di strumenti software comuni, quando la scelta può cadere un software closed source oppure open source, con ricadute piuttosto ovvie in termini di costi (a parità di complessità).

Fonte di regolazione

Veniamo dunque agli aspetti che determinano la fonte di regolazione che rende possibile (o auspicabile, o necessario) lo sviluppo della soluzione di interoperabilità: a seconda dei casi può trattarsi di una fonte di tipo normativo o volontario.

• Nel primo caso si può parlare di un processo normativo, ovvero imposto da un'autorità competente, come ad esempio è stata la necessaria introduzione delle misure minime di sicurezza sul trattamento dei dati introdotte dal GDPR (in modo orizzontale per tutti i titolari e, in aggiunta, in modo verticale per alcune specifiche legate ai titolari che svolgono particolari tipologie di trattamenti);
• Nei restanti due casi si può parlare di un processo volontario, ovvero deciso dal soggetto stesso, come avviene ad esempio per l'adozione di uno standard (es. la certificazione di qualità ISO 9001:2015 o la ISO/IEC 27001), di un codice etico o di un modello organizzativo non obbligatorio (ad es. il modello di organizzazione e gestione 231/2001).

Ovviamente, i processi di integrazione normativi sono quasi sempre dettati da ragioni di necessità, ovvero per ottemperare a requisiti obbligatori per legge, laddove i processi di integrazione volontari sono spesso il risultato di una valutazione di rischi/opportunità: ad esempio, l'adozione di un modello o di una certificazione - benché non obbligatoria - potrebbe consentire all'azienda di partecipare a determinate gare pubbliche o private ottenendo un punteggio di partenza maggiore, o di ottenere un finanziamento più elevato per un progetto.

Un caso particolare è quello che riguarda i processi di integrazione autonormativi, ovvero quelli che, pur in assenza di una norma imperativa, vengono stabiliti da enti o associazioni di categoria al fine di fissare degli standard di riferimento di settore. Si tratta quasi sempre di integrazioni di tipo verticale, in quanto stabilite all'interno di uno specifico settore di mercato.

Soggetto guida

La definizione del soggetto guida, ovvero di chi stabilisce di intraprendere il percorso di interoperabilità, è strettamente collegata al processo decisionale: nel momento in cui gli operatori di settore decidono volontariamente (ovvero adottando un criterio autonormativo) di intraprendere un progetto di interoperabilità, si tratterà quasi sempre di una integrazione guidata da privati; viceversa, quando il percorso è dettato dalla necessità di ottemperare a un preciso riferimento normativo, è possibile (e in taluni casi auspicabile) che sia il soggetto pubblico a promuovere il processo, effettuando gli investimenti ovvero prevedendo gli incentivi del caso. Nei casi in cui questo non avviene, il percorso rischia di essere svolto in modo sub-ottimale (con le aziende che il minimo indispensabile richiesto dalla legge) a meno che non sussista un sufficiente interesse ad operare i necessari investimenti in standardizzazione - ovvero che i costi di investimento siano compensati dall'efficientamento derivante dal completamento del progetto entro una finestra temporale ragionevole.

Il soggetto guida, il cui compito si esaurisce nello stabilire il perimetro di fattibilità del processo di interoperabilità e i relativi criteri (cosa va fatto), non va confuso con il decisore, ovvero con chi si occuperà di definire le modalità operative dello sviluppo della soluzione (come va fatto): in riferimento a questo secondo ruolo è bene parlare di governance operativa, o più semplicemente di governance.

Governance

Nella maggior parte dei casi i progetti di interoperabilità vengono intrapresi perché presentano dei vantaggi oggettivi: efficientamento dell'azienda che eroga il servizio, semplificazione nella fruizione del servizio da parte gli utenti, minori costi di gestione, e così via. In un contesto di mercato, accade di frequente che l'adozione di interfacce comuni estenda questi vantaggi a tutti i soggetti coinvolti, facilitando l'accesso di nuovi player e andando così ad aumentare il livello di concorrenza.

Ragionando su questo aspetto si comprende come la scelta del soggetto che dovrà avere la governance del processo può essere estremamente delicata: è evidente come, nella maggior parte dei casi, si tratta di un ruolo che non può essere affidato a un leader di mercato, in quanto quest'ultimo potrebbe avere secondi fini o comunque non essere incentivato a realizzare sistemi di integrazione che potrebbero beneficiare i propri concorrenti e compromettere la sua posizione dominante. Viceversa, affidare il controllo della soluzione a una pluralità di interlocutori allo stesso livello - o a un'amministrazione pubblica - potrebbe favorire la definizione di standard aperti e la riduzione delle barriere all'ingresso eventualmente esistenti.

Più in generale, è bene tenere presente come le scelte relative alla governance delle soluzioni di interoperabilità tra aziende non possano prescindere dalle questioni di base relative alla concorrenza. La valutazione dei vantaggi connessi al completamento del progetto che può fare un ente pubblico è infatti inevitabilmente differente da quella che farà un'azienda privata direttamente coinvolta in quel settore di mercato; quest'ultimo, inevitabilmente orientato alla ricerca del profitto, potrebbe infatti avere interesse a non completare la soluzione, o magari a non facilitarne l'introduzione o la messa in esercizio, così da difendere il proprio "feudo". Per questo motivo è opinione di chi scrive che il soggetto pubblico (o qualsiasi associazione di categoria, a patto che operi in rappresentanza di interessi collettivi e non di una categoria specifica), in quanto ragionevolmente interessato alla massima circolazione delle informazioni, all'abbattimento dei costi di funzionamento del mercato, alla semplificazione dei processi e - soprattutto - alla redistribuzione della ricchezza secondo valori di pari dignità e opportunità, dovrebbe assumere - o controllare in modo rigoroso - la governance di qualsiasi percorso di interoperabilità inter-aziendale che preveda impatti di qualsivoglia tipo; non soltanto in ottica G2B (government to business, relativa ai rapporti tra pubblica amministrazione ed imprese), ma anche nel B2B (business to business, relativa ai rapporti tra le imprese) e nel B2C (business to consumer, relativa ai rapporti tra azienda e utenti).

Orientamento

Veniamo infine all'ultima, ma non certo per importanza, caratteristica strutturale di una soluzione di interoperabilità: l'orientamento. A chi giova il progetto di  integrazione? A vantaggio di chi viene svolto? A chi porterà i benefici maggiori?

Si tratta di domande tutt'altro che banali, specialmente considerando un quadro di riferimento dominato da un regime di mercato che ponga i soggetti che partecipano all'integrazione (ovvero le aziende) "naturalmente" in competizione tra loro. E' infatti possibile - e in una certa misura probabile - che l’introduzione di sistemi di ottimizzazione basati su una system integration che impatta tutti allo stesso modo produca un vantaggio di tipo diverso a realtà diverse, alterando in negativo gli equilibri pregressi. Ovviamente, si tratta di una negatività inevitabilmente soggettiva, in quanto legata a una concezione del mercato preesistente e magari tutt'altro che equilibrata: del resto, è proprio la necessità di valutare nel modo più oggettivo e indipendente possibile questo tipo di situazioni che rende così importante e delicata la scelta del soggetto che si occuperà della governance della soluzione, questione su cui abbiamo tanto insistito nel paragrafo precedente.

Stante questa premessa, proviamo a distinguere i principali orientamenti possibili per un sistema di interoperabilità:

• seller oriented (o supplier oriented), ovvero gestiti e organizzati dal venditore: si tratta di un modello piuttosto raro in ambito B2B ma che rappresenta la regola nel B2C, dove il venditore "detta legge" sul prodotto lasciando al compratore unicamente la libertà di acquistare o meno.
• buyer oriented (o client oriented), che si pongono l'obiettivo di definire condizioni di acquisto che consentano al compratore di ridurre o contenere i costi. Un esempio è il ruolo svolto dalle centrali di acquisto, come nel caso della CONSIP per le Pubbliche Amministrazioni, e dai sistemi di e-procurement in generale.
• third-party oriented, ovvero gestite da un soggetto "terzo" orientato al profitto: è il caso di una piattaforma di e-marketplace potenzialmente "neutra" (es. Ebay) in quanto il suo interesse è quello di soddisfare in egual misura venditori e compratori mediante l'adozione di una formula che le consenta di guadagnare da entrambi.

Ovviamente esiste la possibilità che il soggetto terzo sia un ente no-profit (ad esempio un consorzio o un fondo di innovazione finanziato pubblicamente); in quel caso la formula adottata non sarà a scopo di lucro ma finalizzata ad attività di coordinamento e supervisione: definizione di standard di accesso alla piattaforma comune, controllo del rispetto di eventuali prerequisiti, e così via.

Altri aspetti da considerare

Prima di concludere il nostro approfondimento è opportuno spendere qualche parola per enfatizzare l'importanza di interrogarsi sulle condizioni di partenza alla base di un qualsiasi progetto di interoperabilità inter-aziendale: una analisi di questo tipo, idealmente compiuta nelle prime fasi dello studio di fattibilità, può aiutare ad anticipare gran parte delle problematiche che potrebbero verificarsi in corso d'opera e facilitarne la risoluzione.

Il primo aspetto da considerare è senza dubbio la disponibilità dei prerequisiti, ovvero delle infrastrutture necessarie, da parte degli attori che si ha interesse a (o necessità di) coinvolgere; nella maggior parte dei casi, poiché le attività di system integration passano per il settore IT, sarà necessario verificare che si disponga dei necessari collegamenti infrastrutturali (es. connessione a Internet), nonché del know-how tecnico per poter implementare le interfacce (se già note o stabilite) e connettere queste ultime al sistema informativo interno. In merito a questo aspetto, che riveste un'importanza fondamentale per il successo di qualsiasi progetto di questo tipo, è auspicabile che il sistema pubblico garantisca:

• un accesso libero e incondizionato alle infrastrutture necessarie (es. banda larga, 5G, etc) senza "alienarne" la gestione a intermediari o concessionari privati, ovvero trovando il modo di non rendere tali risorse un'opportunità di profitto per questi ultimi;
• un sistema di interfacce comuni e standardizzate, così da consentire lo sviluppo di interfacce software e soluzioni interoperabili e intercambiabili, eliminando il rischio che i fornitori possano costringere utenti e/o imprese all'adozione di sistemi e/o formati closed volte a impedirne tanto la portabilità quanto lo sviluppo trasversale;

Il secondo aspetto è relativo alla quantità e qualità di informazioni da trattare: in linea generale, tanto più elevato e variegato è il numero di informazioni che sarà necessario gestire all'interno della soluzione, tanto maggiori saranno i rischi di dover gestire problematiche legate ad aspetti di sicurezza e/o normativi (es. privacy, data encryption, capacità di storage, modalità di trasferimento, impatto in termini di performance, etc.) e implementare le relative remediation, con conseguente aumento dei tempi e dei costi. E' fondamentale calcolare queste dimensioni durante l'analisi di fattibilità e valutarne attentamente la rilevanza e l'impatto in termini di rischi al fine di non trovarsi a dover gestire varianti in corso d'opera, impedimenti burocratici, data breach o altre problematiche potenzialmente difficili da risolvere.

Un terzo aspetto che è opportuno considerare è legato al numero dei soggetti coinvolti (e alle loro caratteristiche): valutare correttamente le dimensioni della soluzione è un altro requisito fondamentale per aumentare le possibilità di successo della stessa, in quanto si tratta di un dato che impatta a vario titolo sui costi operativi, sui costi infrastrutturali, sui tempi di adozione, nonché sulle possibili difficoltà legate all'adoption della soluzione stessa. In merito a questo ultimo punto è importante sottolineare l'importanza di un'analisi accurata delle differenze tra la pluralità di soggetti oggetto della soluzione, al fine di prevenire e/o ridurre l'impatto sull'adozione della stessa per via di situazioni o problematiche specifiche (divario digitale tra località geografiche, difficoltà di comunicazione legate a lingue o culture diverse, etc.).

Avere un'idea il più possibile precisa del numero dei soggetti che saranno coinvolti dalla soluzione consente anche di calcolare il valore dell'interoperabilità che si andrà a realizzare. Il calcolo può essere effettuato facendo uso della legge di Metcalfe, secondo cui l'utilità e il valore di una rete sono proporzionali al quadrato del numero degli utenti. In base a questa legge il valore dell'integrazione è pari a N(N−1) = N²−N, dove N è il numero di soggetti che possono comunicare tra loro.

Considerazioni conclusive

Osservando l'equazione alla base della legge di Metcalfe possiamo notare come il valore di una rete, e quindi di un sistema di interoperabilità che prevede un numero N di soggetti coinvolti, cresce in misura geometrica al crescere del numero di N. Questo dato di fatto è sufficiente per comprendere quanto sia difficile valutare correttamente i vantaggi di molti progetti di integrazione caratterizzati da una adozione progressiva e dilazionata nel corso del tempo da parte degli utenti: i progetti di questo tipo soffrono soprattutto nelle fasi iniziali, quando la diffusione effettiva è talmente inferiore a quella attesa da rendere difficile per gli stakeholder percepire correttamente il valore di quanto è stato realizzato, specialmente se devono comunque sostenerne i costi. Al tempo stesso, se il progetto riesce a "sopravvivere" a queste prime criticità e a raggiungere un numero di soggetti significativo, il suo valore aumenterà in modo esponenziale, diventando immediatamente percepibile da tutti gli attori coinvolti.

Questa caratteristica, comune alla maggior parte dei progetti basati sulla creazione di reti informatiche, consente di mettere a fuoco la fondamentale importanza del ruolo svolto dai finanziatori iniziali (private investor, pubblica amministrazione, fondi di sostegno all'innovazione, friends family & fools, etc) alla base di qualsiasi progetto di innovazione. E' però fondamentale che questi investimenti, siano essi a fondo perduto o regolati da condizioni di restituzione, vengano sempre accompagnati da quella governance operativa su cui abbiamo più volte insistito al fine di assicurare un orientamento compatibile con la filosofia di sviluppo iniziale, nel rispetto dei principi etici e costituzionali che dovrebbero essere alla base di qualsiasi progetto di innovazione.

Riferimenti bibliografici

• Il nuovo modello di interoperabilità (Agenzia per l'Italia Digitale, 2020)
• Linea di indirizzo sull’interoperabilità tecnica delle Pubbliche Amministrazioni (Agenzia per l'Italia Digitale, 04/09/2020)
• Interoperabilità dei sistemi informativi aziendali (C. Travaglini)
• European Interoperability Framework for Pan-European eGovernment Services (2004)
• European Interoperability Framework (EIF) v 2.066 (2010)

Print Friendly & PDF Download