Migrazione a software libero: i 3 aspetti da analizzare

Ogni cambiamento costa fatica, è innegabile. Siamo istintivamente portati a rifiutare o addirittura boicottare il cambiamento, spesso preferendo conservare un comportamento vecchio e dannoso, piuttosto che adottarne uno nuovo, migliore e più produttivo. Ma secondo Charles Darwin “Non sono le specie più forti a sopravvivere e neanche le più intelligenti, ma quelle che reagiscono prima ai cambiamenti.” Tutto cambia, in continuazione, soprattutto nel digitale, e se non si tiene conto di questo fattore non facciamo bene il nostro mestiere, quantomeno.

Parlando specificatamente di migrazione a software libero, ci sono almeno 3 aspetti da tenere in forte considerazione:

  • quello umano, rappresentato dai nostri utenti posti davanti ad un cambiamento;
  • quello organizzativo, rappresentato dai processi e dalla struttura organizzativa;
  • quello tecnologico, rappresentato dall’architettura complessiva dei nostri sistemi informativi.

Il fattore umano è spesso sottovalutato, ma rappresenta il motivo principale delle migrazioni non andate a buon fine. Non è l’unico, ovviamente.

È riduttivo immaginare che una migrazione possa riassumersi nella banale sostituzione di una soluzione software con un’altra. Migrare non è mai solo “sostituire”, quindi i due termini non sono uno sinonimo dell’altro.

Piuttosto, è utile cercare una specie di catena logica su cui è utile soffermarsi un attimo prima di cimentarsi: non si tratta di fare (ancora) un cronoprogramma delle attività, ma di visualizzare una sequenza di implicazioni logiche che legano degli elementi innegabilmente coinvolti nel vostro cambiamento.

Facciamo un esempio, semplice, che parte proprio dalla famosa azione “sostituire”:

Sostituzione del software → Uso di un formato dati/documenti diverso → Interfaccia utente diversa → Interazioni/integrazioni con altro software esistente e con il restante sistema informativo → Interscambio di dati/documenti con altre unità organizzative → Modelli di dati/documenti da rivedere e standardizzare → Personale da formare e coinvolgere → Processi da ottimizzare (o meglio reingegnerizzare) → Progetto

Questo non è altro che un possibile percorso logico, certamente non l’unico e nemmeno il migliore.

L’ideale è farsi una propria catena logica, aggiungendo elementi o cambiando sequenza, o meglio creando una mappa mentale. Oppure, se preferite, intanto prendete per buona questa sequenza, ma tenete ben presente che avete la necessità di inquadrare la vostra migrazione in un contesto logico decisamente più ampio di quanto a primo impatto si possa pensare. E se pensate di arrivare al traguardo saltando le caselle, commetterete un grosso errore prima ancora di cominciare.

Il fattore organizzativo

Con l’occasione della migrazione, vi troverete anche ad affrontare un ragionamento profondo sui processi relativi all’informazione presenti nella vostra organizzazione, o più frequentemente sui processi automatici.

Sappiamo bene (o dobbiamo sapere) che, per essere automatizzati, i processi non è che si prendano semplicemente così come sono, riproducendoli in digitale.

Si parla invece di reingegnerizzazione dei processi, perché come scritto da Stefano Epifani sul tema,“…è facile constatare come intervenire sui processi automatizzandoli produca inevitabilmente in essi un cambiamento”.

Ma attenzione: anche intervenire in un processo già automatizzato (ad esempio con la migrazione) produce quasi necessariamente un cambiamento!

Inoltre, per svolgere bene il nostro mestiere nella realtà che viviamo, così densa di rapidi cambiamenti, dobbiamo abituarci ad accompagnare al concetto di “reingegnerizzazione dei processi” anche altri concetti, come digital tranformation e digital disruption.

Lo dobbiamo fare per evitare tragici errori, proprio come continua a scrivere lo stesso Epifani mettendoci bene in guardia “… siamo pieni di organizzazioni che si affannano a automatizzare o reingegnerizzare processi che non servono più perché il mercato è cambiato. Ed il mercato è cambiato perché il mondo è cambiato.”

Intervenire con la migrazione, quindi, non solo induce nei processi un cambiamento, i cui effetti ovviamente vanno opportunamente analizzati per costruire correttamente il progetto. Induce anche un ripensamento generale: con la migrazione arriva l’occasione di (ri)analizzare meglio tali processi, l’occasione per reingegnerizzare (e migliorare) ancora!

Dovremo quindi arrivare a ad avere una visione sistemica, con diversi elementi correlati tra loro, apprestandoci a ottenere una progettualità integrata che aiuti la trasformazione della nostra organizzazione in logica digitale, perché oggi ha sempre meno senso immaginare il nostro “to-be” aziendale come una semplice traslazione in digitale dell’ “as-is”.

Approfittatene. È un’occasione unica per guadagnare in competitività ed avere un futuro.

E da una simile disamina non è esonerato nemmeno il vostro sistema informativo, che avrete necessità di osservare dal punto di vista architetturale. E qui possono essere guai.

Il fattore tecnologico

Quando s’interviene nel sistema informativo di un’organizzazione, si cominciano a fare i conti con le scelte effettuate nel passato.

Tipicamente, tali scelte si basano su soluzioni “verticali”, buone cioè per risolvere problematiche a livello di unità organizzative, spesso non altrettanto buone se si considera una visione d’insieme. Altrettanto spesso, in queste scelte ed in queste soluzioni si è sottovalutata la necessità di dover rivedere qualcosa nel tempo.

Tipicamente, è sottovaluto ad esempio il modo con cui i software interagiscano tra di loro, in pratica il loro “modo” di comunicare, o come questi memorizzino i nostri dati ed i nostri documenti. Si parla infatti di legacy information system (LIS), cioè sistemi che resistono ad evoluzioni e modifiche necessarie per supportare i nuovi e mutevoli requisiti di un’organizzazione.

Sistemi, quindi, che se non abbiamo scelto in prima persona, comunque ci troviamo con difficoltà a dover “ritoccare” in qualche modo.

Ma come accade per i processi, anche per il sistema informatico la migrazione rappresenta un’occasione importante per migliorare la situazione. Si produce cioè un piccolo/grande risultato anche nell’ammodernamento del sistema nel suo insieme, migliorandone la gestione, la qualità delle risposte agli utenti, o semplicemente semplificando quei futuri interventi che dovranno rendersi necessari.

Sta al nostro progetto di migrazione, quindi, applicare dove necessario dei wrapper al sistema, per “smontarlo” ed interfacciarne i pezzi, migliorandolo dal punto di vista architetturale e facendogli fare un passo in avanti nella direzione opposta a quella del lock-in tecnologico.

Le incompatibilità generate da sistemi o da prodotti software differenti, che trattano e memorizzano l’informazione in maniera segreta (“chiusa”) e privata (“proprietaria”), causano enormi problemi per gli utenti, per le aziende, per i Governi e anche grossi grattacapi agli informatici.

La chiave per far dialogare tecnicamente fra loro i pezzi che costituiscono l’architettura di un sistema informativo è una sola: open standard.

Possiamo quindi figurare gli Open standard anche come un insieme di regole che consentono al software ed ai sistemi tecnologici di interagire attraverso protocolli aperti (interoperabilità) e consentono al software ed agli archivi lo scambio di dati attraverso formati di dati e di documenti aperti.

Il “trucco” è tutto qui: dobbiamo conoscere come i sistemi si parlano e come i dati vengono memorizzati o diventano documenti. E possibilmente non dobbiamo inventarci un nuovo modo per farlo, un modo tutto nostro. Dobbiamo viceversa utilizzare un modo standard e, soprattutto, aperto. Solo in modo i nostri wrapper di sistema potranno aprirsi ad una moltitudine di opportunità che al momento, magari, non siamo nemmeno in grado di prevedere.

Grazie all’utilizzo di una modalità di interscambio standard e aperta (quindi usata, ben documentata e liberamente implementabile da qualsiasi nostro fornitore), quindi, potremo non solo implementare la soluzione al nostro problema contingente, ma anche predisporre il sistema a futuri interventi e/o sostituzioni (o implementazioni in senso lato).

Gli open standard, infatti, possono essere implementati sia in soluzioni open source (implementazione tipica) che in soluzioni closed (proprietarie, caso più raro), fornendo così un ambiente che è agnostico e plurale per quanto riguarda la tecnologia, i fornitori e gli accordi commerciali.

In estrema sintesi, gli open standard permettono di condividere tutti i tipi di dati liberamente e con perfetta fedeltà, senza incompatibilità tra sistemi, prodotti software o documenti.

Questo che segue è uno schema con alcune riflessioni utili sul tema:

 

Facebook Comments

LEAVE A REPLY

Please enter your comment!
Please enter your name here