Se le persone si parlano con la parola e la voce, con lo scritto e la penna o la tastiera, i sistemi informatici si parlano tramite le API (Application Programming Interface).
Dalle API dipende l’interoperabilità dei servizi digitali che sta alla base anche, per quanto attiene alla Pubblica Amministrazione, del principio onceonly basato sull’assunto che “al cittadino va chiesto il dato solo se non in possesso della PA, e di qualsiasi PA non solo di quella che sta erogando il servizio”.
Interoperabilità dei servizi pubblici, partiamo dalle API: come fare
Il principio #onceonly si basa infatti sulla interoperabilità tra i sistemi, ovvero i sistemi devono poter comunicare scambiandosi dati, senza intervento umano. Dai dati dei singoli sistemi, è possibile mediante l’incontro con altri dati estrarre informazioni e quindi conoscenza per erogare servizi migliori.
Per permettere questa comunicazione serve che vengano definiti degli standard. Come, dunque, per comunicare usiamo dei vocabolari (la lingua italiana) e delle regole (grammatica e sintassi), così anche le applicazioni hanno bisogno di regole per comprendersi. Per alcuni di questi scopi (es. ontologie e vocabolari controllati) è disponibile il catalogo nazionale per lo scambio di dati e informazioni tra pubbliche amministrazioni, raggiungibile al link schema.gov.it.
Quali dati ha senso rendere disponibili e a che scopo
Ma quali basi dati ha senso rendere disponibile, mettere in comunicazione, incrociare e a che scopo?
Per rispondere a questa domanda sono state definite le basi di dati di interesse nazionale. Ultima ma non per importanza, nel percorso di progressiva integrazione tra applicazioni, basi di dati, api e standard, è stata attivata la PDND (piattaforma digitale nazionale dati) il cui scopo è proprio permettere di avere un hub di incontro tra domanda di dati e offerta di dati nella PA (e in futuro probabilmente anche con i privati), mediante erogatori e fruitori.
Sommando tutto quanto sopra: potremmo avere un grande cambiamento di comportamento delle applicazioni e servizi della PA, grazie alle API e allo scambio automatico di informazioni.
Ad esempio ad oggi la domanda per un servizio Mensa richiede al genitore di inserire i propri dati, quelli del figlio, il proprio ISEE, eventuali problemi alimentari etc etc, tutto a mano. Domani, il software potrebbe leggere da basi di dati centrali i dati del genitore (ANPR), i dati del figlio (Anpr), l’ISEE (Inps), eventuali problemi alimentari, e quindi richiedere al genitore solo di accettare la lettura dei dati da queste basi dati e la conferma che siano corretti, evitando l’imputazione di informazioni (e la conseguente verifica a valle del personale della PA).
Questa breve sintesi, sicuramente non esaustiva e con qualche semplificazione, ci permette di dire che il percorso di progressiva implementazione dell’interoperabilità tra applicazioni di un ente e l’esterno (basi di dati di interesse nazionale e/o altre PA) è avviato. Nei prossimi mesi e anni vedremo gli sviluppi, stimati in un risparmio di 5 miliardi di euro per cittadini ed imprese secondo la Commissione Europea. La stima pare molto conservativa, perché una effettiva implementazione del principio #onceonly e dei principi che verranno analizzati di seguito, potranno comportare risparmi su più dimensioni che ad oggi sono difficili anche solo da immaginare.
Ma quali sono i principi #onceonly che potremmo pensare?
Perché le PA ignorano il principio “once only”? Ecco il vero problema
Onceonlysuite
Molti enti locali hanno più software per i diversi uffici: ad esempio il software dell’anagrafe, il software dei tributi, il software dell’ufficio tecnico. Questo spesso è dovuto al lavoro a silos dei singoli uffici, oppure al voler ottimizzare per ogni area il miglior software come funzionalità, ignorando le integrazioni con gli altri uffici, oppure al voler avere il migliore strumento per il proprio lavoro curandosi meno dell’effetto sui servizi dell’ente. Questa configurazione tecnologica comporta la necessità di effettuare integrazioni, spesso sommarie, tra applicativi (ad esempio per allineare le anagrafiche dei servizi demografici con quelle dei servizi finanziari) con conseguenti errori, discrepanze ed effetti sul servizio erogato.
Nel tempo gli enti si sono quindi indirizzati (soprattutto quelli più piccoli) sulle suite: si tratta di prodotti che coprono la maggior parte o tutti gli uffici, con come riferimento banca dati integrata sia a livello dati che di funzioni. Questo se fatto bene avrebbe potuto portare il concetto di #onceonlysuite, ovvero il concetto che dentro la suite un dato non viene richiesto una seconda volta se già presente. In alcuni casi i prodotti software per la PA sono davvero così, in altri semplicemente sono i software delle singole aree (es. anagrafe, tributi …) “incollati” insieme in una suite, con ridotti vantaggi a livello di interoperabilità.
Per capire come è stata fatta la soluzione ci si può fare una semplice domanda: se la soluzione fosse davvero #oneonlysuite non si potrebbe già oggi avere il “cassetto del cittadino” con come chiave il codice fiscale?
Ad esempio: ipotizziamo di entrare nel software-suite e avere un’interfaccia che si chiama: cassetto del cittadino. Si entra, si inserisce il codice fiscale prescelto, e da lì appare una videata modello videogame dove al posto dell’equipaggiamento, vedo:
- situazione anagrafica
- situazione stato civile
- situazione elettorale
- situazione tributaria
- situazione multe
- situazione pagamenti pagoPA
- situazione fabbricati
- situazione protocolli di competenza staccati associati al codice fiscale
- situazione documenti associati al codice fiscale
- pratiche suap
- pratiche sue
- e chi più ne ha più ne metta
Se tutto fosse integrato o pensato integrato, si potrebbe già fare. E se non si può fare perché non si può? Questa sarebbe la domanda da porre alla software house che eroga la suite.
Tra l’altro, pensandoci, quanto indicato sopra non è niente altro che il cassetto del cittadino che poi va visualizzato nell’esperienza del cittadino, avviso 1.4.1, con l’aggiunta del flusso dei fascicoli aperti, quindi praticamente il portale del cittadino diventerebbe un visualizzatore di questa situazione senza bisogno di intelligenza di gestione.
Piattaforma digitale nazionale dati, a che punto siamo? I servizi già disponibili e i prossimi step
#onceonly tra applicativi dell’ente back e/o front-end
Spesso non si riesce ad implementare l’#onceonlysuite proprio perché non c’è una suite. Anche nei comuni più orientati alla semplificazione, capita spesso ci sia una suite centrale, e poi un software per l’ufficio tecnico, uno per la mensa, uno per il partner tecnologico pagoPA.
Quindi diventa fondamentale la comunicazione tra applicativi di aziende diverse tra loro, utilizzati dallo stesso ente. Questa è la chiave di volta del PNRR Digitale.
Con il sistema pagoPa si è aperto il mondo delle integrazioni tra applicativi: un ente ha un partner tecnologico a cui tutti gli applicativi devono collegarsi per poter staccare gli IUV. Da qui il “grande caos” delle software house, con le più variegate risposte alla richiesta di integrazione:
- “meglio se inserisci me come partner tecnologico cosi facciamo prima, ti faccio lo sconto”
- “faccio l’integrazione, costa mille mila euro” (e poi viene implementata dopo 2 anni e nemmeno va oppure ha un prezzo talmente assurdo che l’ente rinuncia)
- “non facciamo l’integrazione perché siete in troppo pochi a chiedercela”
- “facciamo l’integrazione” (e dopo 2 anni non è ancora fatta)
- “la facciamo appena rifacciamo il software in cloud” (e dopo 2 anni non è successo niente)
- “integrazione fatta, andava ma ora è cambiato qualcosa e non va, appena possibile la mettiamo a posto”
- “abbiamo già degli export excel che possono aiutare a integrare così valgono per tutti i fornitori” (una bestemmia in ambito integrazioni perché richiede comunque intervento umano).
Riassumendo: manca proprio la cultura dell’integrazione, ovvero si hanno ancora programmi chiusi che non parlano con nessun altro software se non via export excel. Probabilmente mancano anche i programmatori evoluti in qualche software house, che abbiano una cultura di API, Cloud e affini.
Inoltre manca un concetto di base: esporre le API e rendere disponibili integrazioni non è un optional, ma è uno dei principi di base dei servizi e dei programmi della PA. Ovvero se il servizio della software house A non ha API e la software house non è disponibile a fare integrazioni, il software e la software house sono da scartare, come non lo è uno che se gli si chiede autenticazione con SPID risponde “SPEED cosa? o SPEED certo”.
Fortunatamente grazie al PNRR negli ultimi mesi, si è visto un passo in avanti: alcuni fornitori (spesso degli outsider o coloro che non hanno software di backoffice) un po’ per lungimiranza un po’ per necessità hanno capito che l’integrazione è la loro chiave per entrare nel mondo PNRR Digitale offrono ad esempio il loro portale dell’ente con i loro servizi, integrazioni incluse (si, incluse, non c’è da pagare niente).
Quindi se le applicazioni non si parlano tra loro nel back-end perché le software house di backoffice non riescono a fare parlare tra loro le basi di dati, almeno quelli del front-end hanno deciso di provare ad integrarsi con tutti i back-end, introducendo come “ovvie” le API e la cultura dell’integrazione. Per cui se non esiste un cassetto del cittadino nel backoffice, almeno forse lo avremo nel frontoffice, aziende di back-office permettendo
Once only pa
Infine, abbiamo il passaggio di dati tra PA, che è sempre finalizzato all’erogazione del servizio ovvero rientra nel #onceonly, ma è più orientato a scambi i dati tra PA per fini statistici o altro.
Tra le attività più noiose, onerose, fastidiose di un ente locale infatti ci sono le richieste che arrivano dalle PA centrali di compilare questionari, moduli, informative, basi dati, spesso anche a mano, che richiedono informazioni che hanno già altri enti locali o centrali.
Per fare un esempio, con il PNRR sono arrivate richieste di informazioni agli enti locali da parte di:
- Istat
- Agid
- RGS
- Prefettura
- Vari ministeri per gli avvisi
Buona parte di questi dati potevano scambiarseli a livello centrale senza chiedere agli enti locali. Ovvero in periodo PNRR (ancora in corso) è stato evidente come alcuni enti centrali invece di chiedere ad un altro ente centrale i dati di partecipazione agli avvisi PNRR, chiedano agli enti locali di elencare gli avvisi PNRR a cui hanno partecipato, in una logica Hub (ente locale) e Spoke (tutti gli enti centrali che richiedono dati, spesso su questionari in pdf da inviare via pec).
A parte l’”efficiente gestione” del dato trasmesso su moduli pdf, è importante evidenziare la necessità che la rete informativa diventi mesh, ovvero tutti gli enti possano parlare con tutti e domandarsi: il dato che mi serve chi ce l’ha?
Il #onceonlypa non è un tema tecnologico, ma organizzativo: chiedere il dato all’ente locale, che poverino cerca di rispondere sempre, è meglio che chiedere all’altro ministero, che non risponderà mai. Quindi procedo così perché “si è sempre fatto così”.
Un esempio virtuoso di inversione di questo meccanismo è la compilazione del Regis per gli avvisi digitali effettuata direttamente dal portale padigitale2026.gov.it. Ovvero l’ente compila il portale padigitale2026.gov.it e poi questo compila il Regis, senza richiedere all’ente locale la doppia compilazione o doverlo far parlare con due interlocutori.
Conclusioni
“Cinque miliardi di risparmio in caso di implementazione del principio #onceonly”, questa la stima della Commissione Europea. Per quanto indicato sopra, probabilmente si intendeva “nel primo mese o giorno di implementazione effettiva”. Quello che ci sta aspettando, se implementato per bene, avrà un impatto che sommato alla diffusione della cultura del dato, all’intelligenza artificiale, alle RPA, e al quantum computing, è prematuro stimare.
