Document Actions
La PA italiana diffida del software aperto
L'autore, S. Brunozzi, analizza le cause che hanno ritardato l'adozione di software aperto all'interno delle PA italiane.
Generalmente parlando, ogni scelta ruota intorno ai seguenti
concetti chiave:
- Diffidenza
- Inerzia
- Certificazione
- Responsabilità
- Interazione sociale
- Dati ( ICRI )
Mi servirò di un esempio di fantasia per illustrare bene come questi fattori intervengano nel processo decisionale.
Immaginiamo la PA di un comune, che possiede una manciata di server con
caratteristiche hardware diverse, e sistemi operativi diversi (di
solito si gira intorno a Windows 2000 server, Windows 2003 server,
SuSE, Red Hat, a volte AIX di IBM).
Vediamo ora come i fattori DICRID (Diffidenza, Inerzia, Certificazione, Responsabilità, Interazione, Dati; è una sigla coniata al momento) intervengono nei vari stadi decisionali.
Nella PA ogni scelta di rilievo comporta delle Responsabilità
per le persone al vertice della scala gerarchica, ovvero dirigenti e
tecnici "EP" (Elevate Professionalità), ma anche per tecnici di rango
inferiore.
Trovandosi spesso di fronte un sistema informativo già
installato e funzionante, l'eventuale scelta di apportare delle
modifiche (adottando ad esempio una piattaforma FLOSS) viene valutata
con Diffidenza , facendo pesare molto la propria
responsabilità in caso di malfunzionamenti. Effettivamente va mossa una
critica al mondo FLOSS: per vari motivi (il principale: mancanza di
tessuto aziendale fertile in campo FLOSS) la qualità dei software FLOSS
e le garanzie di assistenza non competono bene con soluzioni spesso più
costose, ma affidabili.
Le grandi aziende di questo tipo forniscono una affidabile Certificazione
di ciò che viene installato, cosa che mette al riparo i funzionari
pubblici da una consistente fetta dei pericoli relativi alla gestione
dei dati e alla loro eventuale perdita. Una piccola azienda non può
fornire "assicurazioni", né tantomeno disporre della massa critica per
gestire bene situazioni di emergenza. La eventuale gestione di
Certificazione comporta inoltre delle spese ingenti, non sostenibili da
piccole aziende.
L'esistenza di software già in uso, di
hardware già acquistato, di contratti di assistenza software di durata
pluriennale, di personale già abituato ad una certa interfaccia e ad
una certa procedura, fa sì che l'introduzione di nuove tecnologie possa
essere fatta solo con estrema cautela e lentezza, contrastando con
pazienza l' Inerzia del sistema attualmente in uso.
La presenza di software proprietari, che spesso utilizzano formati
di dati chiusi, impedisce di poter fornire una soluzione alternativa
parziale. Non è possibile ad esempio proporre una piccola soluzione per
un piccolo settore, dato che tutti i dati sono fortemente
interconnessi, e basati su piattaforme software e DBMS proprietarie.
I Dati
, poi, rappresentano un ulteriore problema: come gestire tutti i dati
esistenti? Come convertirli o migrarli verso una nuova piattaforma?
Come certificare che il trasferimento è avvenuto senza problemi? Come
rispondere ad eventuali violazioni?
I vari funzionari pubblici che vengono coinvolti, a diversi livelli, nelle decisioni, devono poi tenere conto delle diverse Interazioni sociali che intervengono in un ambiente di lavoro, interazioni spesso sottovalutate in qualsiasi progetto IT. I funzionari, abituati a quella interfaccia o a quella procedura, possono ribellarsi a qualsiasi cambiamento; i tecnici che si devono occupare della gestione dei servizi informatici possono opporre resistenza a nuove soluzioni tecniche, che comportano il bisogno di aggiornare le proprie competenze; in generale, qualsiasi innovazione comporta sempre delle reticenze, che possono essere giustificate solo nel caso in cui si tratti del "solito software" che necessita di aggiornamento (e quindi un cambiamento inevitabile, da accettare e basta).....
Link alla notizia: http://punto-informatico.it/p.asp?id=1488173&r=PI
