di Diego Piacentini e Paolo De Rosa

This post is available also in English

Nella nostra quotidianità di cittadini, è purtroppo esperienza molto comune quella di avere a che fare con servizi pubblici lontani dalle nostre esigenze. Tale percezione è indotta dalle frustrazioni nell’utilizzo di servizi inefficienti e complicati, costruiti attorno ai processi amministrativi e alle leggi, e non alle necessità degli utenti. Troppo spesso inoltre ci imbattiamo in funzionari e dirigenti della Pubblica Amministrazione che confondono l’implementazione della strategia digitale con la semplice applicazione di tecnologie digitali a vecchi processi, con il risultato di complicare anziché semplificare.

I fornitori di tecnologia, dall’azienda globale che fattura miliardi alle piccole software house locali, hanno un ruolo vitale nel processo di trasformazione digitale della PA.

Il processo di procurement costituisce una delle attività più onerose e complicate per le PA: questo è il problema principale della digitalizzazione di tutti governi, non solo quello italiano. Lo svolgimento delle procedure di acquisto richiede una significativa quantità di tempo, competenze e risorse che spesso la PA non ha; di conseguenza l’acquisto di prodotti e servizi digitali fatica a tenere il passo con l’evoluzione delle soluzioni tecnologiche.

L’obiettivo di ripensare i servizi digitali partendo dalle esigenze dei cittadini passa necessariamente da un ripensamento del rapporto tra fornitori di tecnologia e Pubblica Amministrazione.

Oggi questo rapporto troppo spesso favorisce il fornitore con più abilità di vendita e non quello con maggiori capacità di innovazione; altrettanto spesso il prodotto fornito non soddisfa né le esigenze della Pubblica Amministrazione né del cittadino.

Ecco perché il Team per la Trasformazione Digitale della Presidenza del Consiglio propone un approccio nuovo: l’adozione di una carta di principi tecnologici per il procurement, concordati e accettati con i fornitori stessi, che definisca la relazione tra fornitori di tecnologia e pubbliche amministrazioni: una sorta di gentlemen’s agreement.

Se inclusa e dettagliata nell’ambito di capitolati di gara di servizi tecnologici della Pubblica Amministrazione e in particolare nelle gare strategiche di Consip, la carta dei principi tecnologici del procurement può migliorare il rapporto tra fornitori e la Pubblica Amministrazione.

Immaginiamo già i commenti di quelli che diranno: “Illusi, in Italia queste cose non funzionano. Non siamo un popolo capace di autoregolamentarsi! Servono le leggi.”

Ma abbiamo già il Codice dell’Amministrazione Digitale che è probabilmente una delle leggi più aggiornate ma meno rispettate proprio dalle stesse amministrazioni pubbliche.

A testimonianza che la trasformazione digitale non avviene per legge è il fatto che nessun Paese, anche tra quelli più digitalizzati dell’Italia, ha avvertito l’esigenza di introdurre un codice che cerchi di regolamentare tutta l’amministrazione digitale.

Quindi cambiamo marcia e proviamo un’altra strada arricchendo le leggi con una serie di principi di comportamento che i fornitori e le amministrazioni possono decidere di adottare in via del tutto volontaria.

Incoraggiamo gli stakeholder a contribuire alla creazione della carta dei principi per il “comportamento etico”, commentando il testo sulla piattaforma Docs Italia).

L’invito non è solamente rivolto ai fornitori privati ma anche alle numerose in-house centrali e regionali, a Consip e a tutte le stazioni di appalto pubbliche. Sia la PA la prima a dare il buon esempio!

La carta dei principi tecnologici

La carta dei principi tecnologici del procurement definisce i criteri minimi per lo sviluppo di servizi digitali della Pubblica Amministrazione che:

• soddisfino le esigenze degli utenti/cittadini;
• siano facilmente manutenibili;
• siano capaci di evolvere in base alle esigenze dei cittadini e al progresso tecnologico;
• siano indipendenti da singole componenti architetturali di terze parti;
• riducano le situazioni di dipendenza da un ristretto numero di fornitori (lock-in).

La carta dei principi tecnologici del procurement raccoglie ed estende le linee guida definite dal Codice dell’Amministrazione Digitale e dal Piano Triennale, riportando in alcuni casi anche norme di legge esistenti, per fornire una visione organica dei principi che la Pubblica Amministrazione e i suoi fornitori dovrebbero rispettare per lo sviluppo di nuovi servizi digitali e per la gestione del ciclo di vita di tali servizi.

1. Partire sempre dalle esigenze degli utenti. Inserire nel capitolato di gara una specifica richiesta per seguire le linee guida di design e i processi di sviluppo di Designers Italia nella realizzazione dei servizi, seguendo un percorso di User Research, Service Design, User Interface Design e Content Design. Se ritenuto opportuno la fase di User Research può essere condotta anche in via preliminare dalle amministrazioni al fine di supportare la stesura della gara.
2. Organizzare la progettazione e lo sviluppo dei servizi digitali adottando ove possibile processi incrementali per il rilascio, sfruttando interazioni brevi e frequenti. Il primo rilascio del servizio deve prevedere il numero minimo di funzionalità essenziali utili a raccogliere informazioni dagli utilizzatori e aggiustare il tiro delle fasi successive, che devono essere opportunamente pianificate in durata e numero tali da ottenere una roadmap con rilasci periodici. Ogni rilascio deve essere stato testato da utenti reali e documentato. I capitolati di gara devono prevedere l’applicazione di tale principio.
3. Assicurarsi che la tecnologia e i servizi sviluppati siano accessibili agli utenti. Inserire nel capitolato l’obbligo di usare gli strumenti forniti da Designers Italia per assicurare che i servizi siano progettati a misura di cittadino, applicando criteri di usabilità e inclusività per aiutare le persone con disabilità.
4. Pubblicare il codice con licenze open source per migliorare la trasparenza, la flessibilità e la responsabilità: seguire le linee guida per l’acquisizione e il riuso del software. Inserire nel capitolato l’obbligo di rilasciare alla pubblica amministrazione la proprietà intellettuale del software che viene sviluppato ad hoc, incluse le pagine dei siti web, e di pubblicare il software sotto licenza aperta, registrandolo su Developers Italia con i processi indicati nelle linee guida.
5. Usare standard aperti per garantire che la tecnologia sviluppata funzioni e comunichi con altre tecnologie e possa essere facilmente aggiornata e ampliata. Inserire nel capitolato l’obbligo di utilizzare standard e formati aperti per file e protocolli di comunicazione, l’obbligo di implementare le funzionalità in forma di API documentate secondo le linee guida di interoperabilità, l’obbligo di fornire funzionalità di esportazione di tutti i dati in formati aperti, l’obbligo di documentare la futura procedura di migrazione verso un prodotto alternativo.
6. Cloud First. Utilizzare sempre prima le risorse del Cloud della PA come indicato dal Piano Triennale in materia di cloud. Inserire nel capitolato l’obbligo di utilizzare le risorse qualificate nell’ambito del Cloud della PA, prediligendo i servizi SaaS dei fornitori qualificati, ogni qualvolta viene sviluppato un nuovo servizio. Qualora i servizi SaaS esistenti nell’ambito del Cloud della PA non siano rispondenti alle esigenze del progetto, prevedere l’utilizzo di servizi infrastrutturali IaaS e PaaS del Cloud della PA; inserire nel capitolato l’obbligo di supporto per il protocollo di rete IPv6.
7. Mantenere sistemi e dati al sicuro rispettando i livelli minimi di sicurezza. Inserire nel capitolato l’obbligo di rispettare le Misure Minime di Sicurezza, così come previsto dalle linee guida di sicurezza del Piano Triennale; inserire nel contratto clausole di manutenzione che impegnino il fornitore a rilasciare patch di sicurezza che verranno scoperte anche al termine del contratto.
8. Assicurarsi che i diritti dei cittadini siano protetti integrando la privacy come parte essenziale del sistema. Inserire nel capitolato l’obbligo di rispettare le prescrizioni della normativa italiana ed europea sulla protezione dei dati personali (GDPR).
9. Promuovere buone pratiche ed evitare duplicazione di sforzi condividendo e riutilizzando servizi, dati e componenti software. Inserire nel capitolato l’obbligo di integrare le piattaforme abilitanti come SPID, pagoPA e ANPR, incluse le piattaforme condivise tipiche del dominio nel quale si opera, come ad esempio il Fascicolo Sanitario Elettronico (FSE), nel caso di una PA dell’ecosistema sanitario; inserire nel capitolato l’obbligo di riutilizzare software, servizi e API messi a disposizione da altre PA evitando ove possibile di re-implementare funzionalità che sono già state implementate da altri; nell’eventualità di sviluppo di nuovi servizi, richiedere che l’applicativo sia sviluppato tenendo presente che possa essere utilizzato da altre PA.
10. La tecnologia sviluppata o acquistata deve funzionare con il resto delle tecnologie, i processi e le infrastrutture esistenti nell’organizzazione e deve poter adattarsi alle esigenze future. Eseguire una valutazione del debito tecnologico* presente nell’organizzazione e pianificare la sostituzione delle tecnologie ormai obsolete per le quali il costo di manutenzione eccede il costo di sostituzione; inserire nel capitolato l’obbligo di utilizzare tecnologie aperte affermate sul mercato e supportate dalla presenza di una ampia comunità di sviluppatori e utilizzatori ;
11. Studiare e implementare soluzioni per minimizzare la raccolta e facilitare il riutilizzo dei dati evitando la duplicazione di dati. Inserire nel capitolato l’obbligo di utilizzare i dataset rilasciati in open data da altre PA, l’obbligo di utilizzare i vocabolari controllati e le ontologie descritti nel Piano Triennale, l’obbligo di rilasciare in open data tutti i dati prodotti dagli applicativi per i quali la pubblicazione non sia esplicitamente vietata per legge.
12. Ridisegnare i processi automatizzando il lavoro ripetitivo. È necessario ridisegnare e ripensare i processi rendendoli nativamente digitali, ridurre il più possibile l’intervento manuale nelle attività ricorrenti e non qualificate (data entry, etc.), automatizzando i processi necessari all’erogazione di un servizio e utilizzando l’intervento umano per il controllo della qualità e il monitoraggio.
13. Stabilire i livelli di servizio per i servizi erogati. Utilizzare indicatori (SLI, Service Level Indicator) oggettivi e misurabili al fine di stabilire obiettivi specifici (SLO, Service Level Objectives) di affidabilità e qualità del servizio, definendo le necessarie penali in caso di mancato raggiungimento degli obiettivi (SLA, Service Level Agreement).
14. Definire le competenze e i profili necessari per lo sviluppo dei servizi digitali. Valorizzare le professionalità a disposizione della PA seguendo le linee guida per la qualità delle competenze digitali nelle professionalità ICT .
15. Introdurre sistemi di valutazione dei progetti ex-post. Nelle clausole dei contratti è necessario prevedere sistemi di valutazione dei progetti eseguiti così che le PA possano indirizzare le proprie scelte, anche tenendo conto delle recensioni di altre PA sull’operato di uno specifico fornitore.
16. Pubblicare i documenti di postmortem quando si verifica un disservizio evidenziando le cause principali e le attività intraprese per evitare che riaccada. Incidenti ed errori sono all’ordine del giorno in ambito tecnologico ed è necessario apprendere da essi per evitare che accadano nuovamente in futuro. Nei contratti con i fornitori è necessario prevedere l’obbligo di fornire una comunicazione puntuale e trasparente delle cause che hanno procurato il disservizio producendo dei documenti di “postmortem” di dettaglio che potranno essere pubblicati dalle amministrazioni.

Aiutiamo tutti insieme la Pubblica Amministrazione a migliorare la qualità dei servizi per il cittadino, passo dopo passo.

Note

*Per debito tecnologico si intende la sommatoria di tutte le inefficienze dovute a processi duplicati e lavoro superfluo causato all’interno di un processo da parte dell’infrastruttura tecnologica perché obsoleta o inadeguata.

Lavora con noi | Seguici su Twitter e LinkedIn | Visita il nostro sito | GitHub