Prevedere come saranno le applicazioni della Pa nel prossimo futuro può aiutare chi fa procurement e chi deve realizzare tali soluzioni ad avere le idee più chiare. Infatti, è importante avere ben presenti questi aspetti perché la velocità di messa a terra richiesta dal PNRR renderà necessario conoscere per bene sia le piattaforme abilitanti, sia i kit e tool di costruzione per prodotti e servizi della PA, sia gli sviluppi necessari a un delivery molto veloce e soprattutto efficace.
Applicazioni PA, i componenti fondamentali
I componenti fondamentali delle applicazioni per la PA sono e saranno:
- Accesso e autenticazione: per questo ambito è fondamentale utilizzare SPID e CIE. Quindi come fornitori della PA è importante, laddove possibile, diventare aggregatori per SPID e CIE in modo da poter fornire applicazioni che siano già SPID e CIE compliant. In alternativa, andrà abilitato il singolo cliente/ente su queste piattaforme per permettere ai cittadini accesso mediante SPID e/o CIE.
- Pagamenti: sui pagamenti non pensiamo ci sia ombra di dubbio: l’unico sistema valido è pagoPA, tutto il resto è da considerare “non compliant” alla PA. Essere/ appoggiarsi a partner tecnologici o intermediari tecnologici di pagoPA dà sicuramente una marcia in più per essere sempre aggiornati sulle politiche dei pagamenti digitali nella PA. In alternativa è fondamentale integrarsi con le soluzioni dei partner tecnologici scelti dal singolo ente, sia a livello di tributo che a livello contabile.
- Messaggistica con gli utenti: l’applicazione da utilizzare per comunicare con il cittadino, in relazione ai messaggi informativi, di pagamento e in futuro forse anche di processo,relativi al software che si sta fornendo come fornitori o richiedendo come PA, è sicuramente IO. IO è l’app dello stato italiano, canale unico di comunicazione con il cittadino di tutte le PA (sia per i pagamenti che per eventuali bonus, come cashback e bonus vacanze).
- Interoperabilità in uscita: l’applicazione deve e dovrà essere in grado di comunicare con API (Application Program Interface) di altre applicazioni, in modo da richiedere dati con (ad esempio) come chiave di richiesta il codice fiscale. Un primo esempio può essere la richiesta di informazioni anagrafiche da ANPR (Anagrafe nazionale della popolazione residente) per semplificare la compilazione di form che oggi sono di autocertificazione, domani saranno solo di conferma informativa Un secondo esempio è la richiesta dell’ISEE all’INPS. L’interoperabilità nel complesso (entrata e uscita) è un salto epocale per poter evitare al cittadino di compilare numerose volte form dove autocertifica dati che la PA ha, ma che in specifico l’ente non ha perché questi dati li ha un altro ente facente parte della PA.
- Interoperabilità in entrata: un’applicazione che a sua volta non mette a disposizione API è solo (come direbbe Forrest Gump se potesse commentare) “una scatola piena di cioccolatini, ma senza il coperchio”. E’ infatti fondamentale che le applicazioni della PA mettano a disposizione API per fare interrogazioni. All’inizio non sarà facile capire cosa dovranno esporre queste API, ma nel medio termine, più l’ecosistema dell’interoperabilità crescerà come una foresta di alberi rigogliosi e sani, più sarà chiaro che dati possono venire richiesti all’applicazione da altre applicazioni e quindi sarà più semplice esporre API.
- Opendata: nel 2021, pensare che i dipendenti di un ente debbano ancora mettersi a decidere cosa pubblicare in opendata, pensiamo sia perlomeno poco sensato. Crediamo infatti che i software dovrebbero permettere di pubblicare dati in maniera aggregata in automatico, secondo criteri come quelli previsti dal sito dati.gov.it in modo da migliorare la trasparenza e la disponibilità di dati. Pubblicare opendata (e tenerli manutenuti, cosa non da sottovalutare) è un importante modo di rendere disponibili i dati della PA all’ecosistema nazione (privato e pubblico). Ed è un modo che si affianca alle API che invece sono molto più mirate e focalizzate su un dato scopo.
Il ruolo del cloud e l’uso di dashboard
L’applicazione cloud nel limite del possibile va erogata/richiesta come servizio SAAS qualificato sul marketplace Agid. In tale modo sono garantiti (anche se autocertificati) una serie di parametri di compliance, di privacy, di security, di backup, di exit, il servizio è gestito in cloud, e si è in regola con il processo di procurement che prevede in ordine come scelta:
- prima riuso
- se non funziona il riuso, si passa a marketplace Agid, gare Consip, Mepa …
- se nessuno dei due sopra funziona, allora si chiede uno sviluppo secondo le regole presentate prima
Nel tempo un differenziatore fondamentale per le soluzioni da dare alla PA, per migliorare la capacità di decisione data-driven, saranno delle dashboard nell’applicativo che permettano di capire come si organizzano, compongono, dividono, classificano, i dati gestiti.
Ad esempio, quanti software di contabilità mostrano un grafico a torta del peso di ogni voce di entrata/uscita di un ente? Quanti software di demografici presentano un grafico di quanti cittadini hanno meno di 18 anni, quanti sono emigrati o immigrati nell’ultimo anno? Quanti software mostrano la divisione dei pagamenti per servizio pagopa sia in euro che in transazioni?
Fig1: Rappresentazione grafica di tutti gli elementi di cui si è parlato.
Soluzioni per i fornitori
I partner della PA possono evolvere ulteriormente diventando partner qualificati PA grazie a:
- presenza in marketplace agid (meglio servizi SAAS)
- essendo aggregatori CIE e/o SPID
- diventando partner tecnologici / intermediari pagoPA
Un modo per differenziarsi dal resto del mondo dei “fornitori/partner” della PA.
Fig2: Concetto di Partner Qualificato PA
