I progetti premiati

PARTE 1: ANAGRAFICA
Progetti OpenSource per la PA: un nuovo virtuoso modello di sviluppo. Il Progetto FE fatturazione elettronica
EPOCA s.r.l.
(indicare la denominazione completa del soggetto proponente, ad esempio: Comune di Roma, Provincia di Milano, ASL Roma A etc.)
-
-
Responsabili del progetto
Dirigente
Diego
Macrì
diegomaria.macri [at] unimore.it
Referente
Matteo
Vignoli
matteo.vignoli [at] epocaricerca.it
SEZIONE E CATEGORIA DI CONCORSO
Sezione di concorso:
X Imprese ICT e Consulting
Stato del progetto:
X in corso di realizzazione
Il progetto riguarda:
SCHEDA SEZIONE SPECIALE IMPRESE
Dimensione dell'Azienda:
X Piccola Impresa (numero di occupati < 50 unità)
EPOCA – spin-off accademico dell’Università di Modena e Reggio Emilia specializzato nella integrazione tecnologica e organizzativa - ha sviluppato un modello in ambito organizzativo e tecnologico che sia permetta un’adozione economica, rapida ed efficace di prodotti OS per la Pubblica Amministrazione.
La soluzione progettuale descritta è già stata testata con successo da Epoca (nel ruolo di coordinatore) e da alcune PA pioniere, e oggi sono ormai 2 anni che si è concretizzata nel progetto FE Fatturazione Elettronica (maggiori informazioni sul forge di progetto: www.epocaricerca.it/fe-forge), a cui sempre più soggetti stanno aderendo.
La soluzione risponde ad una domanda: come superare i limiti severi delle “tradizionali” adozioni di prodotti Open Source che peccano di localismo, di chiusura, della difficoltà di sviluppare economie legate ai volumi e alla condivisione dei prodotti?
Come intuibile, la soluzione è nella rete e nello sviluppo di un contesto non arroccato all'interno di un'unico Ente pubblico ma allargato a una molteplicità di attori. Lavorare in rete però non garantisce automaticamente i benefici auspicati di economie di scopo, acquisizione delle best practices, rapida diffusione delle applicazioni. E’ necessario dunque che la rete si caratterizzi per la presenza di altri elementi, fra loro interdipendenti, individuati nei concetti di rete, prodotti OpenSource, configurabilità, repository dei bisogni, coordinamento. E’ la presenza di tali elementi che consente infatti lo sviluppo di un circolo di rinforzo di processi virtuosi.

- La rete. I prodotti OS per la PA devono nascere come progetti della rete, avendo cioè come fruitore finale, come “cliente”, la rete e non invece i singoli attori. In altri termini, i progetti devono nascere dalla collaborazione di una pluralità di PA che stabiliscono di condividere l'intero processo di management del ciclo di vita del software, partecipando e collaborando a:
1. analisi;
2. progettazione;
3. sviluppo;
4. diffusione e gestione del prodotto software.

- La configurabilità. La cooperazione sopra descritta non sarebbe possibile in assenza di approcci architetturali (cioè specifiche tecnologie software d’integrazione fra parti diverse) che consentano di concepire il prodotto finale come un insieme di componenti modulari che ciascuna PA potrà liberamente scegliere, adottare e assemblare allo scopo di “costruire” (di configurare) il proprio sistema (tecnicamente, “architettura modulare e configurabile” significa, nel 2010, l’impiego contemporaneo di architetture SOA e/o Component Oriented, di sistemi di Work Flow e di codice aperto). Il contesto Open Source qui descritto non intende infatti promuovere l’uniformità dei sistemi gestionali nella PA. Al contrario, EPOCA ritiene che alcune specificità costituiscano un valore e che la differenziazione delle soluzioni sia anche un essenziale ingrediente per i successivi processi evolutivi. La rete sarà dunque “depositaria” di un patrimonio ampio di componenti funzionali modulari, un patrimonio che sarebbe certamente ridondante se riferito ai bisogni di una singola organizzazione. Se per esempio il Comune di Reggio Emilia e quello di Genova avessero lo stesso sistema contabile, allora nello sviluppare specifiche applicazioni, come per esempio la fatturazione elettronica, questi Comuni potrebbero utilizzare la stessa interfaccia per inserire la fattura nel sistema contabile. Altri Comuni, invece, dovrebbero utilizzare un modulo diverso perché diverso sarebbe il loro sistema. Sulla rete sarebbero pertanto presenti una molteplicità di moduli per inserire la fattura in contabilità, ciascuno dei quali potrebbe essere progettato e sviluppato da tutti o da una parte di quei Comuni che utilizzano il sistema contabile che richiede quello specifico modulo. E’ in tal senso che il patrimonio di moduli presenti in rete sarebbe ridondante se riferito a un singolo Comune. Come detto però, l’idea di OS qui presentata non ha a riferimento il singolo attore, bensì la rete. Se la rete è il cliente o “fruitore collettivo”, allora non vi è, al contrario, alcuna ridondanza. Questo punto solleva la questione della conoscenza dei bisogni degli attori (in assenza della quale non sarebbe possibile avviare progetti condivisi) e la necessità di sviluppare un Repository come di seguito descritto.

- Il repository dei bisogni. Un elemento essenziale per garantire nel tempo l’innovazione è la raccolta continua dei bisogni funzionali che i diversi attori della rete dovranno sistematicamente comunicare. Tale bisogni dovranno essere raccolti in un Repository che dovrà classificarli e archiviarli per “similitudine”. Quando il numero di partecipanti a una determinata “categoria” di bisogno avrà raggiunto una dimensione soddisfacente (il processo di popolazione di una determinata categoria risulterà certamente favorito dall’interazione fra gli attori), i partecipanti potranno convertirlo in una proposta di progetto suddividendone i costi.

- Il coordinamento. Il modello descritto implica la necessità di disporre di un nuovo ruolo a supporto della rete volto a coordinare progetti condivisi da una molteplicità di enti pubblici. Nel tempo più di un attore dovrebbe potere svolgere un tale ruolo aumentando la velocità di diffusione della conoscenza e di propagazione delle prassi eccellenti.
(descrivere sinteticamente la soluzione progettuale proposta)
Le Pubbliche Amministrazioni investono enormi cifre sul software. Negli ultimi anni molte PA hanno cercato di ridurre questi costi con uno spostamento dal software proprietario ai prodotti Open Source. Come noto i prodotti Open Source (d’ora in avanti OS) sono prodotti software (cioè applicazioni, programmi o insiemi di programmi), acquisibili senza dovere sostenere i corrispondenti costi di licenza. E’ sufficiente scaricarli dalla rete e, per generosità del web, se ne diventa fruitori a titolo gratuito.
Sebbene la condizione sia apparentemente conveniente, essa non rende però necessariamente vantaggioso abbandonare l’utilizzo di un sistema proprietario per un OS. Numerosi Comuni (molti dei quali di piccole dimensioni) stanno per esempio riconvertendo i loro sistemi gestionali (proprietari) in prodotti Open, stanno cioè riscrivendo con codice aperto (avvalendosi di parti o moduli già presenti in rete) alcune delle loro procedure interne se non l’intero sistema gestionale. E’ questo, almeno nella maggior parte dei casi, un esempio sbagliato di utilizzo dell’OS perché antieconomico, discutibile sotto il profilo dell’efficacia e della sua possibile evoluzione nel tempo. Infine, anche i problemi di assistenza e di manutenzione evolutiva non sono trascurabili.
I motivi sono molteplici. In primo luogo riscrivere procedure complesse (sia pure assemblando parti già esistenti in rete) non produce le cosiddette economie di scopo. Le peculiari funzionalità sviluppate da un certo Comune rendono infatti il software “specifico” e, come tale, sostanzialmente inutilizzabile da altri Comuni. In secondo luogo non consente ai suoi utilizzatori di avvantaggiarsi dell’esperienza straordinaria che i software proprietari hanno accumulato e “incorporato” nel codice nel corso di decenni di esperienza. Infine, mortifica la velocità dei processi di apprendimento e di evoluzione, perché questi sono necessariamente condizionati dalla limitatezza e dalle specificità del luogo ove il progetto è sviluppato. In definitiva, il risparmio dei costi di licenza non è in grado, nonostante l’orgoglio campanilistico che l’avventura suscita, di compensare gli svantaggi che tale “semplicistica” modalità di sviluppo può produrre in termini di: funzionalità limitate, probabile presenza di errori, evoluzione condizionata dal contesto, scarsa riutilizzabilità.
Molte persone e molti dirigenti della PA tendono a identificare l’idea di Open Source con i prodotti Open così come sopra descritti e convengono, conseguentemente, sulla scarsa convenienza di una loro adozione. Tale conclusione – almeno così interpretando gli Open Source - appare ineccepibile.
(indicare sinteticamente il problema a cui la soluzione dà risposta)
Con il modello sopra descritto, EPOCA intende diffondere nella Pubblica Amministrazione una modalità innovativa per rispondere ai fabbisogni di software.
La domanda da cui è partito lo studio e il progetto di EPOCA è semplice: se la maggior parte del software di cui necessitano le PA risponde a bisogni comuni agli enti, perchè ogni PA si fornisce dei prodotti di cui necessita indipendentemente dalle altre, senza fare leva sulle economie che la collaborazione con altre PA porterebbero? EPOCA ritiene che la PA possa produrre in rete (con l'opportuno coordinamento) le applicazioni sw di cui necessita.
La soluzione progettuale descritta è già stata testata con successo da Epoca (nel ruolo di coordinatore) e da alcune PA pioniere, e oggi sono ormai 2 anni che si è concretizzata nel progetto FE Fatturazione Elettronica (maggiori informazioni sul forge di progetto: www.epocaricerca.it/fe-forge), a cui sempre più soggetti stanno aderendo.
Tale esperienza non è mai stata tentata in precendenza in quanto di norma le PA adottano soluzioni disponibili sul mercato o si dotano in autonomia delle soluzioni di cui hanno bisogno replicando costi che potrebbero essere condivisi. Rappresenta quindi un'assoluta innovazione dal punto di vista tecnico nella gestione dei progetti di informatizzazione nella Pubblica Amministrazione per le scelte metodologiche e tecnologiche adottate (SOA e "agile").
Vi sono due linee parallele di innovazione del progetto. La prima è tecnico – organizzativa. La seconda è tecnologica, legata all'architettura di sistemi informativi. La modalità organizzativa del progetto e l'impatto che questo ha sui soggetti coinvolti sono aspetti estremamente innovativi. A livello organizzativo il progetto permetterà di testare un nuovo modello di collaborazione tra PA: si tratta del primo caso in Italia di software prodotto sistematicamente in cooperazione tra le pubbliche amministrazioni in ambiente open source, con una modalità di riuso del software tanto auspicata dal CNIPA. Quest'innovativo approccio di soddisfacimento dei fabbisogni di informatizzazione della PA potrà diventare una best practice: la modalità di cooperazione e l'infrastruttura che la supporta potranno essere riutilizzate per ampliamento ad altre funzionalità o ad altri progetti. Il progetto fa inoltre uso di tecnologie complesse distribuite. La versatilità e la stabilità dell'architettura sono garantite da un'architettura SOA-ESB Mule, database SQL, ORM Hibernate, Java2 EE JBOSS, motore di workflow, interfaccia portlet Liferay. Tutte le soluzioni adottate sono OS.
(indicare sinteticamente gli elementi di innovatività della proposta)
Il motivo per il quale la community sta crescendo è anche da trovarsi nella semplicità implementativa della soluzione. Questa semplicità è raggiunta grazie alla architettura modulare del prodotto (che permette una alta flessibilità, adattandosi perfettamente alle logiche organizzative locali) e grazie alla figura del coordinatore, ruolo al momento necessario per l'accompagnamento delle PA verso una nuova forma mentis, più responsabilizzante, più coraggiosa e più “snella” (la PA deve auto-gestire i propri bisogni, accompagnata nella loro individuazione e nella analisi e sviluppo di possibili proposte risolutive).
La architettura modulare del progetto rende il software molto flessibile, poichè si può utilizzare in diversi scenari in ottica di riuso, grazie al principio di configurabilità sopra descritto. Su tale base è stato e sarà possibile soddisfare bisogni “locali” di PA attraverso assemblaggi specifici volti a realizzare configurazioni altrettanto specifiche. Detto in altri termini, ciascun attore ha potuto e potrà, sulla base della grande disponibilità d’ingredienti presenti in rete, scegliere la propria ricetta.
Il ruolo del coordinatore all'interno della community inoltre supporta le PA in tutte le attività legate al progetto, accompagnandole in questo nuovo modello di sviluppo e utilizzo di prodotti open source. Infatti il coordinatore supporta la PA e il gruppo di PA in diversi modi: raccoglie e classifica nel Repository i bisogni provenienti dalla Rete; preventiva il costo dei singoli progetti; suddivide fra i partecipanti il costo complessivo dei progetti una volta che siano stati approvati da un gruppo di attori; stabilisce momenti intermedi di controllo e di feedback dei progetti; garantisce la qualità del software e la documentazione; supporta la formazione degli attori della rete.
(indicare sinteticamente gli elementi che determinano la semplicità di introduzione della soluzione nei processi della PA)
Oltre ai classici vantaggi legati all'utilizzo dei prodotti OS, il modello offre vantaggi che l'utilizzo “tradizionale” dei prodotti OS non riesce ad avere: il modello infatti persegue economie di scopo abbattendo ancora più drasticamente i costi, permette l'acquisizione delle best practices sviluppate all'interno della community da parte di ogni singolo partecipante (anche grazie ad incontri di formazione e “racconto” tra i partecipanti alla community), e permette la rapida diffusione delle applicazioni grazie ad un circolo virtuoso partecipativo alimentato dai partecipanti stessi.
La rete utilizzata come mezzo di condivisione per una cooperazione tra PA che abbraccia l'intero processo di sviluppo del software (analisi, progettazione, sviluppo) dà numerosi vantaggi. La presenza contemporanea di prospettive diverse in fase di analisi (quelle di tutti gli attori che partecipano al progetto) produce necessariamente un’ampia visione del problema che si concretizza, nella successiva fase di progettazione, con lo sviluppo di un concetto di prodotto in grado di soddisfare le esigenze di molteplici partecipanti. Se il gruppo è sufficientemente ampio, allora il risultato sarà il disegno di un software “generale” e, come tale, adottabile da molti altri attori della rete. Potendo i costi dello sviluppo essere suddivisi fra i diversi partecipanti, coinvolgere numerose PA nel processo di sviluppo significa altresì ottenere straordinarie economie. Infine, la successiva diffusione nella rete (cioè l’adozione del software da parte di nuovi fruitori) consente una rapida propagazione di conoscenze e di best practices, nonché la raccolta di nuovi bisogni e nuove prassi che contribuiranno a loro volta ad alimentare virtuosamente il processo. Mutatis mutandis, lo stesso può dirsi per la gestione, la manutenzione e l’evoluzione del prodotto. Di ciascun intervento di miglioramento potrà infatti beneficiare tutta la rete, così come tutta le rete, costituendo un formidabile punto di osservazione e utilizzo, segnalerà prontamente suggerimenti di miglioramento.
Inoltre EPOCA ritiene che l’utilizzo del Repository dei Fabbisogni qui descritto possa incoraggiare – attraverso l’interazione degli attori - lo sviluppo di “gare al ribasso”, cioè la sistematica ricerca di nuovi partecipanti che abbiano lo stesso bisogno e possano condividere i costi totali dello sviluppo, abbattendo i costi sostenuti dalla singola PA. Un Comune X ingaggiato sin dall’inizio in un progetto potrebbe, per esempio, essere a conoscenza che un altro Comune Y avverte proprio quel bisogno che il progetto in questione intende soddisfare e, allora, potrebbe adoperarsi per convincere quel Comune a partecipare al progetto. Quando il gruppo avrà raggiunto una certa dimensione, i partecipanti intuiranno che il beneficio economico derivante dall’aggiunta di un nuovo partner all’interno del gruppo potrebbe essere più che annullato dai maggiori oneri di coordinamento del progetto o da un più lungo tempo di attesa, cioè da una posposizione eccessiva dei benefici attesi. Il progetto sarebbe a questo punto probabilmente avviato. Anche la visibilità dei bisogni espressi dalla Rete e categorizzati nel Repository sarebbe comunque, in quanto “vetrina” di potenzialità di miglioramento, un’occasione per suscitare interesse, adesioni e, in definitiva, lo sviluppo di nuovi progetti. Il vantaggio degli innovatori o early adopters rispetto alle organizzazioni che potranno successivamente beneficiare in forma gratuita del software sviluppato sarebbe quello di:
- condizionare il disegno del progetto;
- avvantaggiarsi anticipatamente dei benefici del software.
(indicare sinteticamente i vantaggi/benefici che la soluzione comporta per la PA sotto il profilo organizzativo e procedurale)