Il portale Padigitale2026.gov.it è un esempio di come la PA può funzionare, ovvero un punto (ci auguriamo) di non ritorno per:
- modalità di accesso (accesso con Spid e CIE),
- semplicità di utilizzo (interfacce chiare e disegnate per la comprensione e la guida degli utenti),
- standardizzazione (gestione utenti avanzata con editori e incaricati, oltre che legale rappresentante),
- ambiente di supporto personalizzato (helpdesk enti e fornitori)
- interoperabilità (iniziata indicando nella candidatura Spid e CIE le informazioni utili per evitare errori in fase di inserimento dati).
Proviamo allora a descrivere come il portale Padigitale2026.gov.it potrebbe evolvere per semplificare l’inserimento dei dati nelle fasi di esecuzione, rendicontazione e controllo, proseguendo la best practices della fase di candidatura.
Incrociando i dati disponibili nelle varie PAC/PAL, si andrebbe ad attivare a piena potenza “l’interoperabilità interna alla PA”, ovvero “ciò che la PA sa già è inutile che se lo richieda o lo faccia certificare a un altro suo pezzo”, nell’ottica di #onceonlypa.
Il registro Spid
Il registro Spid nella sezione “Fornitori di Pubblici Servizi” permette di scegliere l’ente e visualizzare l’elenco degli endpoint per i quali è stato indicato un accesso con Spid. A questa visualizzazione sarebbe utile aggiungere alcuni attributi, in particolare:
- data collaudo
- protocollo attivo
- nomenclatura aggregatore oppure attivazione singola
In tale modo ogni ente potrebbe da solo verificare la propria situazione Spid. Se, inoltre, questi dati fossero incrociati con le candidature di Padigitale2026.gov.it e resi disponibili su quest’ultimo portale, sarebbe addirittura già possibile effettuare dei controlli incrociati e non permettere la rendicontazione in caso di discrepanze tra candidatura e registro Spid. Tali situazioni anomale potrebbero essere verificate con il proprio Account Manager del Transformation Office territoriale, previa richiesta di rendicontazione.
In fondo i dati e l’interoperabilità servono a quello: a permettere di incrociare informazioni per evitare di scoprire dopo (o mai) alcuni problemi o anomalie e risparmiare tempo.
Il registro CIE
Il registro CIE permette di scegliere l’ente e visualizzare l’elenco degli endpoint per i quali è stato indicato un accesso con CIE. A questa visualizzazione sarebbe utile aggiungere alcuni attributi, in particolare:
- data collaudo
- protocollo attivo
In tal modo, ogni ente potrebbe da solo verificare la propria situazione CIE. Come sopra descritto per Spid, identicamente se questi dati fossero incrociati con le candidature di PADigitale2026.gov.it e resi disponibili su quest’ultimo portale, sarebbe già possibile effettuare dei controlli e non permettere la rendicontazione in caso di discrepanze da verificare con il proprio Account Manager del Transformation Office territoriale.
Fatti tutti questi controlli incrociati, la produzione di una relazione di conformità (sia per Spid che per CIE) generata dal portale, da firmare digitalmente e da caricare sul portale, sarebbe la ciliegina sulla torta per avere “compliance controllata” prima ancora del controllo umano.
In fondo i dati e l’interoperabilità servono a quello: a permettere di incrociare dati per fare controlli automatici.
La situazione pagoPA
Ogni ente dovrebbe avere chiara la sua situazione PagoPA mediante un portale fornito dal partner tecnologico che gli dovrebbe permettere di verificare:
- i servizi attivati
- quando è stata inserita la tassonomia per ogni servizio
- il primo pagamento dopo inserimento della tassonomia per ogni servizio
Del resto, è possibile che il portale non visualizzi questi dati (che sono quelli utili a capire se la candidatura e la rendicontazione per l’avviso corrispondente del PNRR è realizzabile), e che il partner tecnologico li fornisca. Ma anche se li fornisse, chi può dire se i dati forniti dal Partner Tecnologico sono quelli “giusti” per chi poi controllerà gli Avvisi PNRR? Fino a rendicontazione effettiva, nessuno. Per cui, perché non fare in modo che sia PagoPA stessa mediante il DTD a renderli disponibili già ora sul portale PADIGITALE2026?
Ogni ente avrà infatti indicato dei servizi in candidatura, che sono in un database. Se questi venissero visualizzati come da candidatura e di fianco fosse indicato:
- data inserimento tassonomia (se possibile, perché potrebbe essere che in verità la prima data di comprensione dell’esistenza della tassonomia sia quella al punto sotto)
- data primo pagamento con tassonomia attiva.
Questo aiuterebbe a scremare:
- servizi senza pagamento
- servizi con pagamento e tassonomia corretti
- servizi con pagamento e tassonomia non in data corretta (post 01.04.2021 o secondo candidatura)
Ogni ente potrebbe quindi “autocontrollarsi”. Se poi venisse generato un report di compliance solo da firmare dal legale rappresentante… che risparmio di tempo avremmo a livello Paese?
L’app IO
Qui la questione è bicefala. Avendo una dashboard di IO si potrebbe aggiungere la data di attivazione del servizio su IO direttamente sulla sua dashboard, ovvero nel momento in cui il Team di PagoPA/IO accetta il servizio, e la “pallina diventa verde”, potrebbe anche essere indicata la data di attivazione.
L’altra possibilità potrebbe essere quella di raccogliere questi dati nel portale Padigitale.gov.it e quindi fare come per PagoPA e Spid/CIE: incrociare i servizi candidati su IO, aggiungendo in una tabella:
- data di attivazione
in modo che il report sia generato e verificato prima della rendicontazione e non dopo con eventuali errori.
Certo qui il discorso è più articolato perché il nome dei servizi è stato possibile sceglierlo in maniera “naif” senza una tassonomia, del resto un incrocio dei dati può sicuramente semplificare le attività degli 8.000 comuni (ed altri enti) coinvolti e di tutti coloro che dovranno controllare quanto fatto.
In fondo i dati e l’interoperabilità servono anche a quello: a valorizzare un servizio, a semplificare una procedura, a creare conoscenza, ad aumentare la consapevolezza e le competenze per partecipare ad un processo di crescita comune.
