Comuni digitali, troppi vincoli al cambiamento: come superarli

La trasformazione digitale dei comuni italiani ha attraversato diverse fasi di ostacoli e progressi. Inizialmente, la mancanza di risorse finanziarie ha frenato il cambiamento, ma con l’arrivo del Team Digitale e l’introduzione di fondi significativi, come quelli del PNRR, si sono avviati i primi passi verso l’innovazione.

Tuttavia, superato il vincolo economico, la sfida si è spostata sulla carenza di competenze tecniche e STEM all’interno della pubblica amministrazione. Oggi, nonostante i fondi e il supporto manageriale disponibili, i comuni affrontano problemi legati a software obsoleti e chiusi, che ostacolano l’interoperabilità e l’automazione dei processi. Per superare questi limiti

In principio il vincolo erano i soldi

In principio, come detto, il cambiamento dei comuni era frenato dalla mancanza di risorse. Realizzare progetti digitali ad invarianza di bilancio, nominare un RTD e il suo ufficio senza costi, era il mantra della digitalizzazione. Poi è arrivato (nel 2017) il Team Digitale che ha iniziato a raccontare una storia diversa: per fare digitale servono fondi. Da quel momento sono iniziati piccoli ma significativi cambiamenti con uno stanziamento di qualche milione per ANPR, così come di qualche milione per il Fondo Innovazione e l’introduzione di pagoPA, SPID e appIO. Ma successivamente è arrivato il Covid19 e così il PNRR, con un’ondata di fondi sul digitale per i comuni che si sono visti in pochi mesi trasformati da aridi viaggiatori nel deserto dei fondi per il digitale a surfisti nel mare di fondi del PNRR Digitale.

Poi il vincolo diventarono le competenze

Arrivati i fondi, nella PA si è cercato un nuovo alibi: mancano figure tecniche o STEM, come se fosse una novità. Della serie: i soldi fanno molto ma non tutto. A questo punto sono nate alcune entità centrali come PagoPA S.p.A., Il Dipartimento per la Trasformazione Digitale con i team territoriali di supporto. Il tutto con lo scopo primario rendere operativo il PNRR Digitale e spendere al meglio i soldi, e come secondario quello di creare nuove strutture centrali in grado di governare in maniera snella (nel limite della PA) la trasformazione digitale anche dei comuni (oltre alle scuole e alla sanità).

Poi il vincolo divenne la tecnologia e il mindset

Ad oggi quindi ci sono sia fondi che supporto manageriale (account manager) che tecnico (technical implementation manager). Cosa sta frenando quindi il cambiamento? Perché vediamo servizi digitali in cui convivono due back office ovvero quello del sito (1.4.1) e il backoffice vero e proprio dell’ente (il gestionale) e non una connessione tra i due?

Sono due gli aspetti che stanno ancora frenando il cambiamento e ostacolando l’automazione dei processi:

• software obsoleti: tranne in alcuni casi quasi eroici, alcune software house hanno preso software degli anni ‘90 e hanno fatto un restyling di qualche funzione per poter essere inclusi nell’avviso 1.2 come soluzioni adatte e soprattutto come soluzioni definibili “Aggiornamento in sicurezza”. Il che comporta che i comuni dopo il PNRR avranno in cloud un software risalente agli anni ‘90, pur avendo rimpinguato le casse dei fornitori che hanno speso qualche euro per aumentare la potenza della struttura, ma nessun euro impegnato in sviluppo.
• software chiusi: non crediamo esista un solo dipendente pubblico dei comuni in Italia che non si sia sentito dire “se fai tutti gli avvisi con me avrai tutto collegato senza nessun problema”. Chi può averlo detto? Un commerciale di una software house qualsiasi della PAL, che vuole il lock-in totale fornendo tutti i suoi prodotti come soluzione per gli avvisi PNRR. Questo mediante il vantaggio ancora tutto da dimostrare dell’interoperabilità totale tra gli stessi.
• interoperabilità obsoleta: più entriamo nei pochi pertugi lasciati dalle software house (con calma e senza fretta perché tanto c’è tempo…) nella comprensione del modo in cui fanno interoperabilità, più si capisce che hanno pensato l’interoperabilità in modo abbastanza originale, ovvero senza considerare le API che avrebbero potuto rendere disponibili gli altri fornitori. Del resto era anche difficile fare un’analisi considerando API di terzi: quasi nessuno le espone e non c’è un catalogo di esposizione (no, non è PDND, magari lo fosse davvero per API utili)
• mindset antico: siamo ancora fermi ai moduli da comprare, al costo per attivazione delle API, alla mancanza delle API per esportazione di dati dai servizi cloud dei fornitori. Un po’ è anche colpa di chi non ha creato standard a livello centrale perché se scrivi che un fornitore certificato deve avere API per esportazione di dati in formato aperto, devi spiegare anche quale formato aperto vuoi e soprattutto fare in modo che il formato aperto possa essere utilizzato dall’ecosistema delle software house.
• sfinimento moderno: anche i più fiduciosi nell’interoperabilità totale stanno notando che la PDND si sta popolando di API povere dal punto di vista della qualità dei dati erogati dai comuni, cosa del resto prevedibile avendo lasciato spazio alla fantasia. Del resto che conta sono gli obiettivi PNRR, non l’impatto. Il che porta a dover poi negoziare API specifiche utili (ad esempio per staccare un banale numero di protocollo). Si può fare sicuramente di meglio con un catalogo API pubblico dei principali fornitori e moduli e con la spinta verso l’erogazione di specifici servizi da parte dei comuni (protocollo, creazione fascicolo, modifica fascicolo)

Eppure una buona notizia c’è

Per certi aspetti comunque ci stiamo lamentando del “brodo grasso”. Infatti sebbene non sia stato raggiunto anche l’obiettivo finale ovvero l’once only verso imprese e cittadino e l’once only tra PA, perlomeno stiamo discutendo di come migliorare le API esistenti, fare tassonomie e cataloghi e standard di import-export dei dati, cosa che 4 anni fa sarebbe sembrata impensabile. E poi PDND esiste: se ne parlava ormai da 10 anni senza vedere una sola linea di codice (o tenendola bene nascosta).

Cosa servirebbe davvero alla PA per cambiare pelle grazie alla tecnologia

Ipotizzando di riuscire nei prossimi 5 anni a migliorare l’interoperabilità e quindi l’automazione dal punto di vista tecnologico, cosa servirebbe davvero alla PA per cambiare pelle grazie alla tecnologia (AI inclusa?)

• competenze: nella PA non ci sono abbastanza STEM, figuriamoci ICT, tantomeno possiamo aspettarci personale che capisca di AI se non ben pagato o in modalità missionario
• software migliori: software aperti (API), che siano eventualmente suite di fatto oltre che di nome ovvero con basi dati interne uniche e integrate e non sviluppate come monolitici incollati con il superattack
• tanta consulenza: personale in grado di capire di digitale (piattaforme abilitanti, ai, interoperabilità …), pubblica amministrazione (normative, leggi …), trasformazione di processi (es. process mining, process analysis) e persone (es. OKR) per utilizzare al meglio quello che abbiamo a disposizione

Ad oggi abbiamo infatti gli avanzi del PNRR, poche competenze di digitale nella PA, software un po’ obsoleti e scarsa interoperabilità.

Forse aiutare le software house a trasformarsi in software e consulting house potrebbe aiutare anche loro a capire quali sono i problemi di una trasformazione reale degli enti, che si trovano limitati anche dai loro software , e aiutare davvero i comuni nella rivoluzione AI e Digitale. Anche perché le software house hanno ottenuto molti soldi grazie al PNRR, e restituirli al Paese con un cambiamento di prospettiva (che comunque le aiuterebbe a fare nuovo business, mediante investimenti in competenze del proprio personale) potrebbe essere un miglioramento notevole del servizio fornito.