Il PNRR è partito e corre veloce al ritmo delle ferree scadenze semestrali imposte dall’Europa.
Proviamo a elencare lo stato dei principali interventi di trasformazione digitale delle PA avviati con il PNRR.
Il punto su PNRR per la PA digitale
- La missione 6 sulla sanità digitale e la telemedicina è partita speditissima, con vari leak dei documenti strategici relativi al Fascicolo Sanitario Elettronico FSE2.0 (che diventerà il luogo in cui, oltre ai documenti, ci saranno anche i dati e verranno erogati i servizi per il cittadino relativi a prestazioni sanitarie) e alla Piattaforma nazionale di Telemedicina (su cui è avviata la procedura PPP per la realizzazione), il tutto basato sulle più recenti architetture in ambito ehealth;
- Sempre in sanità, sono già state compilate da parte dei RUP delle aziende del sistema sanitario le “schede” per ricevere il finanziamento della digitalizzazione degli ospedali DEA, delle centrali COT, ecc all’interno dell’apposita piattaforma Agenas. Entro giugno saranno firmati dei “Contratti Istituzionali di Sviluppo” (CIS) tra ogni singola Regione ed il Ministero della Salute. L’attuazione è stata vincolata all’utilizzo delle soluzioni negli AQ Consip “sanità digitale” con pochi grandi RTI individuati come aggiudicatari per l’esecuzione;
- Agenas, con il DL n.4/2022 è stata recentemente designata anche nel ruolo di “Agenzia nazionale per la sanità digitale (ASD)” con altre competenze che vengono quindi ad essere sottratte ad AgID;
- L’Agenzia per la cybersicurezza nazionale ha assunto tutte le competenze che furono di AgID sulle misure di sicurezza e sulla qualificazione cloud, ed ha già emesso i primi bandi di finanziamento per le amministrazione centrali del c.d. “Nucleo per la cybersicurezza” . Dovrebbero seguire a breve bandi per altre amministrazioni particolarmente interessate dalle minacce cyber ed entro il 18 luglio si dovrà procedere alla compilazione dei form di classificazione di dati e servizi (anche se a pochi mesi dalla scadenza si hanno solo indicazioni generiche in merito al lavoro che dovranno fare gli enti);
- Avanzano spediti anche gli investimenti per le competenze digitali di base, in piena collaborazione attuativa tra Ministro dell’innovazione e Conferenza delle Regioni. Una best-practice in tal senso;
- Il Dipartimento per la trasformazione digitale ha avviato la procedura di gara PPP per il dacenter/cloud nel “Polo Strategico Nazionale” (PSN) il cui disegno fu prefigurato nel 2012 (ai tempi del governo Monti) ed ora sembra arrivare alla realizzazione dopo dieci anni;
- AgID ha avviato gli interventi della missione 1 posti direttamente a suo carico, tra cui il “Single Digital Gateway” e l’accessibilità dei siti web;
- il Ministro Brunetta ha attivato sul territorio 1.000 esperti a sostegno della semplificazione, anche se con risultati ancora da valutare . Dovrebbero arrivare prossimamente anche gli esperti delle task force territoriali del Ministro dell’innovazione (c.d. “Project Management Office” nazionale);
- Presto si apriranno le porte per i finanziamenti alla digitalizzazione degli enti locali, veicolati attraverso lo “store padigitale2026” con avvisi per finanziare soluzioni standard (con l’impegno a migrare al cloud un certo numero di servizi e altri target) oppure presentare progetti (con una “platea ristretta di beneficiari fino a 1.000 PA” recita il sito). Gli enti che lo desiderano potranno aggregarsi “spontaneamente” nei tempi, brevi, che saranno concessi e a patto di confermare la somma dei target attesi dai singoli enti e le stesse scadenze: apparentemente quindi mettersi insieme potrebbe rappresentare un rallentamento o un rischio che gli enti potrebbero non voler correre, ma la definizione degli avvisi è ancora in divenire.
Centralizzazione e standardizzazione
Cosa possiamo dedurre da questi primi interventi avviati e quali domande emergono?
Di sicuro da questi primi mesi di attuazione emerge che con il PNRR ci sarà una forte spinta alla centralizzazione dei processi di digitalizzazione e di innovazione nel settore pubblico in Italia.
Tutto sembra portare verso soluzioni standard “one size fit all” costruite per rispondere primariamente agli indicatori di realizzazione del PNRR, indicatori che, in molti casi, non sembrano solidi: tanto per fare degli esempi parliamo di cose come “numero di CED negli ospedali DEA”… ebbene sì, c’è proprio scritto CED nell’accordo con l’Europa… “numero di enti migrati al cloud”… basta un mero lift-and-shift? e con quali costi di esercizio finali?… “numero di API pubblicate” …con quali dati? usate da chi?
Sono indicatori che sicuramente permetteranno di rendicontare in Europa, ma se ci facciamo guidare solo da questi indicatori, in una logica di “burocrazia difensiva” ormai così consueta nelle PA, rischiamo di orientare tutta la realizzazione in una direzione senza effettivo ritorno dell’investimento del PNRR.
E bisogna sempre ricordare che i fondi del PNRR sono, in gran parte, debito.
Probabilmente questa impostazione centralizzata è un po’ guidata dalla paura delle scadenze strette/frequenti e dalle esigenze impellenti di rendicontazione “per non perdere soldi”, ma è anche una impostazione che fa da contraltare alla stagione precedente dei “bandi egov” dell’era Stanca/Elisa, con i fondi che finirono in centinaia di progetti oggi definiti “di campanile”, progetti che assicurarono una digitalizzazione diffusa ma non di sistema. In realtà non è possibile confrontare due epoche tecnologicamente così profondamente diverse, inoltre sono almeno dieci anni che la fase Stanca/Elisa è chiusa(!) ed il Paese ha spostato ormai da molti anni le sue strategie di digitalizzazione sulle grandi piattaforme nazionali (FatturaPA, SPID, PagoPA, NoiPA, FSE1.0, ecc) e su piani nazionali come quello BUL per la banda ultra-larga o il PNSD per la scuola digitale.
Con un approccio centralizzato/standardizzato sarà davvero ben poco praticabile parlare nei prossimi anni di “open innovation” nelle PA (nonostante gli infiniti dibattiti degli anni passati). Non sarà praticabile perché in primis permangono norme che non aiutano certo gli enti ad approcciare startup o a fare sperimentazioni/contaminazioni (le regole su appalti, budgeting e rendicontazione non accettano il concetto stesso di rischio e di apertura)… ma come secondo fattore avverso si aggiunge oggi il fatto che il PNRR spinge per soluzioni standard e “chiavi in mano” per la quasi totalità dei fondi stanziati.
Soluzioni standard che saranno prodotte (per forza di cose) da grandi player/RTI scelti tramite Accordi quadro Consip. Il che ridurrà ulteriormente il numero di fornitori di IT nel settore pubblico, numero che era già fin troppo ristretto, come dimostrano i dati delle ultime ricerche degli Osservatori del Polimi.
La nostra Costituzione dice che lo Stato ha il compito di standardizzare i dati, non i sistemi informativi in toto. E come salvaguarderemo concorrenza e sussidiarietà?
Team e progetti
Ricordo che il governo UK inventò il “team digitale” nel 2010 proprio per uscire dai grossi contratti multi-miliardari che tanti danni avevano fatto nel decennio precedente nel settore pubblico inglese.
Uno degli slogan nati dal team digitale inglese è “finanziare team non progetti”. Noi in Italia non solo non costruiamo team (si continua a non investire in assunzioni di personale e i vincoli organizzativi e di budgeting/rendicontazione rendono improbabile lavorare davvero per team multi-disciplinari) ma ormai non si parla più neanche di progetti (project management, questo sconosciuto).
Senza impostare il lavoro per team e senza progetti ci resteranno solo soluzioni da adottare “plug-and-play”.
Viceversa, già nel 2017 Deloitte metteva in luce che le organizzazioni moderne hanno la necessità di lavorare per team. E a maggior ragione dopo il covid non possiamo inseguire modelli gerarchici sia nei singoli enti che per la governance complessiva dell’innovazione.
Tutti sul cloud
È bene chiarire che tutte le domande poste fin qui, non hanno assolutamente lo scopo di mettere in dubbio l’approccio Cloud-first/API-first perché è giusto, senza dubbio alcuno, guardare oggi solo a soluzioni erogate in cloud e puntare su interoperabilità via API in ottica “once only”.
C’è, tuttavia, la necessità di capire come (e da chi) verranno sviluppate, selezionate e dispiegate le soluzioni cloud e le API, chi le standardizzerà e se saranno sostenibili i costi di esercizio una volta finito il PNRR visto che si è deciso di non strutturare precise forme di aggregazione territoriale e non c’è una ricerca esplicita di economie di scala e di scopo. Senza una premialità esplicita verso l’aggregazione territoriale e verso la ricerca di economie la questione dei costi di esercizio viene messa sotto il tappeto.
Passare al cloud dovrebbe significare per le amministrazioni avere maggiore flessibilità, maggiore scelta e meno lock-in. Ma la partita per arrivare a questo è ancora tutta da giocare e, a mio avviso, richiede competenze che dentro le amministrazioni non ci sono. Soprattutto per andare oltre il mero lift-and-shift, ma passare a veri servizi cloud SaaS che permettano agli enti di avere servizi evoluti e non occuparsi più di aspetti sistemistici, infrastrutturali e di sicurezza.
Resta anche da definire quale ruolo avranno in futuro le numerose società in house pubbliche del settore ICT, che chiedono di avere riferimenti per i loro piani industriali e manifestano problematiche nel nuovo quadro delinato dal PNRR: vedi ad esempio l’articolo “Società informatiche regionali a rischio 8.300 posti” . A cosa verrà destinato il personale formato presente nelle in house, mentre al tempo stesso per le imprese ICT private si annuncia uno skill shortage senza precedenti e non si sa dove trovare gli informatici necessari?
La fine del riuso
Sembra non essere più un tema di primo piano a livello nazionale quello relativo al “riuso”, sia di soluzioni software che di buone pratiche organizzative. Visto che non sono stati aboliti i relativi art.68-69 nel CAD le PA dovranno fare valutazioni comparative per selezionare le soluzioni nel PNRR? qualcuno le farà per loro a livello centrale? Come si sposa la vecchia impostazione prevista dalle LG riuso con il nuovo approccio seguito nel PNRR? Il futuro del “catalogo del riuso” è solo ospitare piccoli moduli open source e kit SDK per developers? Forse il legislatore dovrebbe rimettere mano agli art.68-69 del CAD per adeguarsi allo scenario attuale, se ci sono nuove politiche perseguite a livello nazionale.
Ma senza riuso, neanche delle esperienze, le nuove soluzioni cloud risolveranno automaticamente gli annosi problemi organizzativo/burocratici delle PA italiane? È ritenuto ancora necessario collaborare dentro e tra PA e sviluppare comunità di pratica (CoP)? Purtroppo, i fondi del PNRR escludono esplicitamente ogni forma di assistenza tecnica, che molte volte permettevano di lavorare su queste tematiche. Speriamo trovino spazio nel nuovo PON governance, ancora da scrivere, anche ripartendo dalle esperienze portate avanti in OCPA.
Le persone non sono “standardizzabili”. Nessuna organizzazione riesce ad innovare, o semplicemente adottare una nuova tecnologia, perchè è obbligata… l’innovazione e le tecnologie devono rispondere a dei bisogni, portare benefici per prima cosa alle persone (dentro e fuori l’ente) e richiede manager in grado di guidare il cambiamento. E siccome parliamo di digitale richiede anche competenze di e-leadership, il che è un fattore non banale.
Front vs back
Negli interventi di digitalizzazione italici c’è una costante fin dai tempi dei primi “bandi egov” del Ministro Stanca che vale fino al PNRR di oggi: il focus è sempre sul front-office e mai sul back-office.
Per back intendo proprio come lavorano gli uffici quotidianamente, le applicazioni che usano (excel compreso), come sono (dis)organizzati i processi dentro le PA e tra PA.
Ad oggi, in molti casi, nelle PA il dato non è affatto gestito (o non è gestito correttamente). Che fine ha fatto la “strategia nazionale dati” prevista dall’art.50-ter del CAD?
Le aspirazioni della piattaforma dati PDND subiranno l’effetto “garbage in garbage out” con conferimenti obbligatori di dataset pieni di dati inservibili? Come si devono preparare le singole amministrazioni sul tema dati? Il catasto o l’elenco dei codici CAP saranno mai liberati come dataset in open data? La tessera sanitaria è stata appena ridisegnata su plastica: come mai non viene dematerializzata dentro l’app IO insieme alla patente di guida? Come arriveremo ad un “fascicolo digitale del fabbricato” e a digitalizzare sterminati archivi cartacei delle pratiche pregresse negli uffici edilizia che non sanno come rispondere alle richieste di accesso fatte per via del bonus 110%? Come tracceremo le pratiche “in stile amazon” se tale dato non è presente in un sistema informativo?
Si era iniziato a parlare di vero “service design” ai tempi del commissario Piacentini… ma con le ultime LG siamo tornati al solo aspetto uniforme dei siti web senza aspirare a rivedere i processi di erogazione dietro i servizi: un lavoro faticoso, che si continua a rimandare.
Le nuove soluzioni standard finiranno per appoggiarsi su uno strato sottostante di sistemi obsoleti e di difficile mantenimento, vera e propria “tecnologia tossica” che in maniera crescente rende la vita difficile (se non impossibile) agli informatici che lavorano negli enti. Personale informatico interno che ha numeri sempre più esigui e competenze pre-
Un quadro complessivo di difficile lettura
Mi accorgo di avere troppe domande e poche risposte: non possiamo addossare al PNRR la soluzione di problemi di sburocratizzazione e digitalizzazione irrisolti nel Paese da oltre 40 anni, ma la speranza era che il PNRR potesse incidere almeno su alcuni degli elementi più critici già emersi con chiarezza nelle precedenti interazioni.
Speriamo che l’adozione di grandi soluzioni standard erogate da pochi fornitori (o un solo fornitore in alcuni casi, come il PSN e la Piattaforma di telemedicina) porti ad un effettivo “salto di sistema”, almeno per i servizi delle amministrazioni centrali, generando soluzioni funzionali e sostenibili nel tempo.
Speriamo quindi di non ritrovarci con soluzioni ispirate al primo portale turistico italia.it.
Altrimenti avremo solo ridottoulteriormente la diversità e la creatività nell’ecosistema dell’innovazione nel settore pubblico, senza benefici concreti.
Diversità e vitalità degli ecosistemi
La vita sboccia dalla diversità, ogni ecosistema richiede diversità. Se vogliamo che si sviluppi davvero un ecosistema digitale pubblico bisogna riportare in qualche modo al centro della strategia temi quali diversità, sussidiarietà e openness.
Probabilmente questi elementi sono stati compressi per via di molti fattori (come ho cercato di illustrare) e non per via di un preciso disegno. Siamo, quindi, in tempo per dedicare attenzione e risorse anche a questi aspetti.
Il PNRR ormai è partito e la destinazione dei fondi è fissata, ma speriamo che all’interno della programmazione dei fondi strutturali 2021-2027 le amministrazioni centrali (PON) e quelle regionali (POR e agende digitali regionali) si sappia trovare le risorse per alimentare diversificazione e innovazione diffusa.
Ma c’è una condizione perché ciò avvenga e sia effettivamente realizzabile: è importante che nelle soluzioni standard del PNRR, e negli avvisi di altra natura, sia lasciato sempre un preciso spazio per l’attivazione di azioni in sussidiarietà (per migliorare o personalizzare un servizio standard, per aggiungere altri servizi, per aggregarsi stabilmente intorno ad una soluzione, oppure come comunità di pratica professionali).
Questo spazio deve essere previsto formalmente anche negli accordi quadro e nei contratti con i fornitori che saranno affidati nel PNRR a livello nazionale, ed anche perseguendo seriamente una strategia di interoperabilità API-first (altro termine che si è appannato nelle ultime versioni del Piano triennale). Solo se le soluzioni di front-end saranno costruite veramente dopo le interfacce API ci aprirà lo spazio per interfacciare altri sistemi e servizi, siano essi sviluppati a livello locale dalle PA oppure sviluppati autonomamente da startup o in PPP. Solo così si può garantire in futuro una spazio alla concorrenza tra più opzioni contemporaneamente disponibili rispetto ad un certo servizio, sia per le PA che devono erogare quel servizio, sia per il cittadino che deve fruire di quel servizio.
Lo schema classico degli appalti ICT trattati come “fornitura” è affidare un contratto per la realizzazione di un servizio on line e poi (man)tenersi quel servizio per 3/5 anni, e questo sia che la realizzazione si riveli soddisfacente o meno, sia se le esigenze dei dipendenti/cittadini che lo usano nel frattempo possano cambiare, ecc. Le interfacce API permetterebbero di entrare in una nuova logica in cui, per un certo servizio pubblico, possono essere sviluppati più servizi on line concorrenti o complementari. E questo sia su richiesta della stessa amministrazione oppure per iniziativa del mercato.
Sussidiarietà o monoliti
Ma dove si attesta, esattamente, la responsabilità di un servizio pubblico e relativi servizi online?
Nell’era della trasformazione digitale, non esiste più la possibilità di avere un ruolo senza portare la relativa responsabilità, e quindi a livello istituzionale occorre scegliere bene su quale ente si debba attestare la responsabilità per un certo intervento, salvaguardando il principio di sussidiarietà come da Costituzione.
Solo così possiamo puntare a migliorare la capacità del sistema pubblico di resilienza/evoluzione di fronte ad un mondo che cambia sempre più velocemente. E il mondo è già cambiato radicalmente anche mentre si muovevano i primi passi del PNRR, pensate potrebbe accadere da qui al 2026.
Se, invece, si punterà su servizi offerti alle PA (nel back-office) e ai cittadini (nel front-office) attraverso sistemi “monolitici”, non ci sarà la possibilità di esercitare una vera opzione “exit”, sia per le PA che per i cittadini.
Per quanto riguarda, invece, il livello del personale tecnico preposto all’attuazione, occorre potenziare i RUP non solo nella classica definizione di “Responsabile Unico del Procedimento”, ma come vero e proprio “Responsabile Unico di Progetto” e/o “Responsabile Unico di Processo”. E i RUP possono operare solo se hanno a disposizione un vero e proprio team operativo (ma dei team abbiamo già parlato). Nelle PA bisogna superare la logica degli appalti episodici. Si può realizzare un servizio on line senza pensare a come funzionerà in esercizio? Come affrontare seriamente policy di sicurezza informatica se non in una logica di continuità?
Openness
Se non è possibile puntare esplicitamente sulla “open innovation”, almeno bisognerà trovare forme di “open governance” con processi di standardizzazione aperti a tutti, ben documentati e collaborativi.
In tal senso, un irrinunciabile punto di partenza sarebbe rivitalizzare un presidio per forum.italia.it e docs.italia.it anche per gli interventi sul digitale nel PNRR.
Ciò non allo scopo di raggiungere un “consenso” su ogni decisione, ma almeno per garantire un pieno “allineamento” a tutti coloro che dovranno/vorranno prepararsi o concorrere all’attuazione in pieno spirito collaborativo tra le parti. Il cambiamento richiede anche tempi “fisiologici” a processi di questa natura, che non possono essere ignorati
Conclusioni
Camminare insieme non è una perdita di tempo, a meno di voler arrivare in fondo ritrovandosi soli.
Lavorando in corsa, per rispettare le scadenze PNRR, è molto facile che la standardizzazione porti di fatto ad un approccio “monolitico” e che si dica “alle API ci pensiamo dopo” oppure “ad allineare gli attori coinvolti ci pensiamo dopo”… speriamo tra 3 anni di non ritrovarci a vagare tra monoliti inutilizzabili dicendo “plis visit digital servizi in linea” come ai tempi del primo italia.it.
* L’autore è dirigente ingegnere presso la Azienda USL Umbria 1 ma scrive a titolo personale
