Prof. Diego Macrì - Open source nella pubblica amministrazione: un nuovo modello collaborativo
•
0 likes•483 views
Open Source nella Pubblica Amministrazione: un nuovo modello collaborativo ***** Prof. Diego Macrì - Università di Modena e Reggio Emilia
![Introduzione ,[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
More Related Content
Viewers also liked
Viewers also liked (20)
Similar to Prof. Diego Macrì - Open source nella pubblica amministrazione: un nuovo modello collaborativo
Similar to Prof. Diego Macrì - Open source nella pubblica amministrazione: un nuovo modello collaborativo (20)
More from EPOCA
More from EPOCA (15)
Prof. Diego Macrì - Open source nella pubblica amministrazione: un nuovo modello collaborativo
- 1. Open Source nella Pubblica Amministrazione: un nuovo modello collaborativo Diego Maria Macrì Matteo Vignoli June, 30 rd 2011 Facoltà di Ingegneria di Reggio Emilia
- 5. Il Nuovo Modello Collaborativo 4. I ruoli di coordinamento 2. La configurabilità 3. Il Repository dei bisogni 1. La Rete I prodotti Open Source
- 10. Sviluppo possibile del modello Collaborazione aperta, ma coordinata Consorzio Comunità fondatrice Comunità innovativa gerarchica piatta aperta chiusa 1 PARTICIPATIONE GOVERNANCE
Editor's Notes
- 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 utilizzatori a titolo gratuito. Sebbene la condizione sia apparentemente conveniente, essa non rende però necessariamente vantaggioso abbandonare l’utilizzo di un sistema proprietario per sostituirlo con 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é (1) antieconomico, (2) discutibile sotto il profilo dell’efficacia e (3) 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 mettendo insieme 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 “semplicistico” modo 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 irreprensibile. Riguardo a questo importante tema ancora aperto dell’OS, EPOCA – uno spin-off accademico dell’Ateneo - ha pensato di sviluppare un ambito organizzativo e tecnologico compatibile con un’adozione economica, rapida ed efficace di prodotti OS per la Pubblica Amministrazione. Come superare, dunque, i limiti severi delle “tradizionali” adozioni che peccano di localismo, di chiusura, della difficoltà di sviluppare economie legate ai volumi e alla condivisione dei prodotti? La soluzione, come intuibile, è nella rete, nello sviluppo di un contesto allargato a una molteplicità di attori, ma tutto questo non basta: lavorare in rete non garantisce automaticamente i benefici sopra 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, rappresentati nella figura e di seguito brevemente descritti. E’ la presenza di tali elementi che consente infatti lo sviluppo di un circolo di rinforzo, di processi virtuosi.
- 1. 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 un processo di: 1. analisi, 2. progettazione, 3. sviluppo e 4. diffusione e gestione del prodotto. Numerosi sono i potenziali benefici di una tale cooperazione. 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 concreta, 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 utilizzatori) consente una rapida propagazione di conoscenze e di best practices , e così pure la raccolta di nuovi bisogni e 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 la rete, costituendo un formidabile punto di osservazione e utilizzo, segnalerà prontamente suggerimenti di miglioramento.
- 2. La configurabilità Il processo sopra descritto 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 elementi modulari che ciascuna PA potrà liberamente scegliere, adottare e mettere insieme 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). L’ambiente 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 elementi funzionali modulari, un patrimonio che sarebbe certamente ridondante se riferito ai bisogni di una singola organizzazione. Su tale base sarà però possibile soddisfare un grande numero di bisogni “locali” attraverso assemblaggi specifici volti a realizzare configurazioni altrettanto specifiche. Detto in altri termini, ciascun attore potrà, sulla base della grande disponibilità d’ ingredienti presenti in rete, scegliere la propria ricetta . 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, il “ fruitore collettivo ” , allora non vi è alcuna ridondanza. Questo punto solleva però la questione della conoscenza dei bisogni degli attori della rete (in assenza della quale non sarebbe possibile avviare progetti condivisi) e la necessità di sviluppare un Repository come di seguito descritto.
- 3. 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. Tali 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 sarà certamente favorito dall’interazione fra gli attori), i partecipanti potranno convertirlo in una proposta di progetto suddividendone i costi. EPOCA ritiene, in definitiva, che l’utilizzo del Repository possa incoraggiare – attraverso l’interazione degli attori - lo sviluppo di “gare al ribasso”, cioè la sistematica ricerca di nuovi partecipanti che possano condividere (e abbattere) i costi dello sviluppo. 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, poiché “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 in seguito beneficiare in forma gratuita del software sviluppato sarebbe quello di: (1) condizionare il disegno del progetto e (2) avvantaggiarsi anticipatamente dei benefici del software.
- 4. I ruoli di integrazione e il coordinamento Il modello descritto implica la necessità di avere un nuovo ruolo a supporto della Rete volto a coordinare progetti condivisi da una molteplicità di enti pubblici. Più specificamente, tale attore dovrebbe preoccuparsi di: raccogliere e classificare nel Repository i bisogni provenienti dalla Rete; preventivare il costo dei singoli progetti; suddividere fra i partecipanti il costo complessivo dei progetti una volta che siano stati approvati da un gruppo di attori; stabilire momenti intermedi di controllo e di feedback dei progetti; garantire la qualità del software e la documentazione; supportare la formazione degli attori della Rete … 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.
- This was achieved because the Open Source Community, using this model was able to produce in one year a flexible, reusable and extremely efficient infrastructure for full electronic invoicing process support. The main challenge in this collaboration was related to its intrinsic complexity: different Public Administrations can have very different needs and procedures to acquire, validate and store electronic invoices. Such a support system therefore needs to cope with heterogeneous requirements in a modular and flexible way. Given the intrinsically diversified nature of the scenario, our model was the key in addressing this organizational and architectural challenging task.