La trasformazione digitale dei Comuni italiani è un processo in pieno svolgimento, sostenuto anche dai fondi del PNRR. Tuttavia, l’elevata quantità di risorse disponibili comporta il rischio di frammentazione tecnologica e di dinamiche poco concorrenziali se non vengono adottate adeguate contromisure.
Indice degli argomenti
La trasformazione digitale e il rischio di frammentazione
In molti enti locali coesistono sistemi informatici eterogenei che non comunicano tra loro, creando cosiddette “isole digitali”.
Per superare queste “macchie di leopardo” tecnologiche e garantire servizi pubblici efficienti e integrati, si delineano due approcci principali: affidarsi a un partner tecnologico unico (mono fornitore) oppure puntare sull’interoperabilità basata su standard aperti. Vediamo i punti chiave di entrambe le soluzioni e come bilanciarle.
Vantaggi e svantaggi dell’approccio mono fornitore
In questa strategia, un Comune adotta un’unica piattaforma software fornita da un solo partner tecnologico, che copre tutti i servizi digitali dell’ente. L’idea è che un fornitore unico garantisca un ambiente integrato “chiavi in mano”, semplificando la gestione tecnica e riducendo i problemi di integrazione tra sistemi diversi.
Spesso solo i grandi player del mercato sono in grado di offrire un’intera suite completa di servizi digitali integrati, motivo per cui molti enti valutano questa opzione. I principali vantaggi e svantaggi di un approccio mono fornitore sono:
Vantaggi del fornitore unico
- Semplicità gestionale: un unico interlocutore per assistenza, manutenzione e sviluppo, con contratti e responsabilità centralizzati.
- Piattaforma unificata: dati e servizi risiedono in un sistema omogeneo, già interconnesso internamente, senza necessità di costose integrazioni tra prodotti diversi.
- Omogeneità degli strumenti: i vari moduli applicativi si mostrano (in teoria) con interfacce utente e logiche operative in modo omogeneo , facilitandone apprendimento e utilizzo.
Svantaggi del fornitore unico
- Rischio lock-in: dipendere da un solo vendor crea un vincolo tecnologico difficile da sciogliere. Se il fornitore aumenta i prezzi o il software non evolve adeguatamente, il Comune può trovarsi bloccato (effetto lock-in).
- Meno concorrenza e innovazione: una soluzione mono fornitore tende a favorire i grandi fornitori e ad escludere i piccoli operatori specializzati. Ciò riduce la libera concorrenza, con il rischio di minori incentivi a migliorare i prodotti e di costi più alti sul lungo periodo.
- Falsa interoperabilità: la soluzione monolitica, proposta come “integrata”, in realtà è l’esatto opposto di ciò che si immagina, architetturalmente, essere un sistema basato su componenti interoperabili e interfacce aperte
In sintesi, l’approccio del partner unico risolve la frammentazione creando un ecosistema unico, ma comporta dipendenza da un solo attore e meno competizione nel mercato ed, in sostanza, minore qualità di prodotto.
L‘interoperabilità come alternativa alla soluzione monolitica
L’alternativa alla soluzione monolitica è investire nell’interoperabilità, permettendo a sistemi differenti (anche di fornitori diversi) di dialogare fra loro attraverso standard comuni. Questo approccio punta a integrare le diverse piattaforme utilizzate dai Comuni tramite API e formati dati standard, in modo che condividano informazioni in tempo reale e funzionino come un unico grande sistema virtuale. L’interoperabilità è fondamentale proprio per evitare che i Comuni si trovino costretti a optare per un unico fornitore per far parlare tra loro i sistemi. Ecco alcuni punti chiave di questa strategia:
Vantaggi dell’interoperabilità
- Libertà di scelta: con standard condivisi, ogni ente può scegliere le soluzioni migliori da fornitori diversi, sapendo che si integreranno facilmente. Si evita così l’obbligo di un mono fornitore e si scongiura l’effetto lock-in, favorendo una scelta libera e modulare dei servizi.
- Concorrenza e innovazione: standard aperti mettono tutti i fornitori (grandi e piccoli) sullo stesso piano tecnico, permettendo loro di offrire servizi compatibili. Questo favorisce la concorrenza e stimola il miglioramento continuo dei prodotti, con benefici in termini di qualità e costi per la PA.
- Continuità e scalabilità: sistemi interoperabili rendono più semplice sostituire o aggiungere componenti in futuro. Un Comune può aggiornare un modulo (es. gestione tributi, anagrafe, protocollo) senza dover stravolgere l’intero ecosistema, purché i nuovi software rispettino gli stessi standard.
Sfide dell’interoperabilità
- Definizione di standard univoci: perché l’interoperabilità funzioni, occorre stabilire a livello centrale standard tecnici e normativi chiari (formati di dati, protocolli, ontologie condivise). La mancanza di standard definiti, dovuta alla declinazione molto restrittiva del concetto di interoperabilità presente nel Piano Triennale che si limita alla comunicazione fra stessi software (es. protocollo del comune A che comunica con protocollo del comune B) e fra PA differenti, finora ha reso difficile coordinare sistemi e fornitori diversi all’interno di uno stesso ente, perciò è indispensabile colmare questa lacuna con linee guida uniche e omnicomprensive.
- Governance e coordinamento: adottare standard comuni richiede un coordinamento tra enti, fornitori e istituzioni nazionali. Iniziative come le piattaforme abilitanti nazionali (es. pagoPA, App IO, ANPR) e le circolari AgID/ACN stanno spingendo in questa direzione, imponendo requisiti di interoperabilità nelle forniture cloud SaaS della PA. È fondamentale proseguire su questa strada affinché tutti gli attori adottino davvero degli standard concordati, altrimenti “senza uno standard unico si rischia il caos” nel lungo termine. E’ importante che a livello centrale si capisca che per gli Enti è fondamentale definire interfacce standard (e vocabolari controllati) per ogni modulo applicativo (es. contabilità, anagrafe, tributi, ecc.) e che queste siano pensate per consentire anche la comunicazione fra i diversi moduli applicativi presenti nel sistema informatico del singolo Ente, oltre che verso le piattaforma abilitanti.
In sostanza, l’interoperabilità basata su standard mira a eliminare non solo la frammentazione rendendo cooperativi sistemi plurali, ma anche fra moduli dello stesso sistema. Pur richiedendo uno sforzo iniziale maggiore per definire e applicare regole comuni, essa consente di mantenere un ecosistema aperto e competitivo, dove le amministrazioni non sono vincolate a un solo fornitore e possono innovare agilmente.
Verso un modello equilibrato di trasformazione digitale
Per evitare la frammentazione tecnologica nei Comuni, è necessario trovare un equilibrio tra le soluzioni. Affidarsi a un unico partner può offrire immediatezza e semplicità, ma comporta rischi di dipendenza e monopolio tecnico. Puntare sull’interoperabilità aperta, d’altro canto, garantisce flessibilità e concorrenza, ma richiede impegno nel definire standard solidi e nel farli rispettare da tutti gli attori coinvolti. Impegno che non può essere, assunto dalla singola Amministrazione, ma deve avvenire attraverso un soggetto capace di operare il necessario coordinamento e di imporre lo standard, meglio se a livello regionale o nazionale.
L’approccio ottimale potrebbe combinare il meglio di entrambe le strategie: utilizzare piattaforme comuni e condivise dove possibile (anche tramite fornitori affidabili), ma senza chiudersi in un ecosistema proprietario. Ciò significa pretendere dai fornitori soluzioni aperte e interoperabili, in linea con gli standard nazionali, così da poter integrare nuovi servizi o cambiare partner in futuro senza trauma. In questo modo i Comuni potranno sfruttare le opportunità della trasformazione digitale mantenendo sovranità tecnologica e possibilità di scelta, a vantaggio di un’innovazione sostenibile e di servizi migliori per i cittadini.
Il caso PagoPA e le sfide dell’interoperabilità
Negli ultimi periodi sta risultando sempre più chiaro che la strada dell’interoperabilità è quella più difficile. I fornitori più importanti mediante frasi motivazioni come “se fai tutto con me asseveri altrimenti è da vedere” o “posso integrarmi con l’altra software house ma riesco ad occuparmene dal 2027 finito il PNRR” stanno sempre più minando la costruzione di un mercato aperto di soluzioni api-driven e sempre più obbligando scelte di lock-in e mono fornitore.
Speriamo ci sia spazio con gli avanzi del PNRR di cambiare nella direzione di maggiore interoperabilità la situazione. Anche perché il fenomeno sta portando alla moltiplicazione di Partner tecnologici non strettamente necessari ma di fatto obbligatori. Ad esempio per un Ente che abbia affidato ad un fornitore la realizzazione di servizi on-line che prevedano dei pagamenti (con PagoPA) viene quasi sempre imposto l’utilizzo di un partner tecnologico PagoPA, anche se differente da quello che il Comune utilizza abitualmente per veicolare i pagamenti elettronici. E se il Comune ha più fornitori di servizi on-line il rischio è che gli vengano imposti più intermediari PagoPA differenti. Lo stesso dicasi per SEND, anzi, in questo caso, essendoci due soggetti intermediari (quello per SEND e quello per PagoPA) la situazione porta da ulteriore moltiplicazione dei PT (con conseguenze tecnologiche e economiche di breve e lungo termine=
Arriviamo così al paradosso che, sebbene in presenza di piattaforme abilitanti, dotate di API ben definite, l’Ente, dovendo di fatto utilizzarle attraverso un Partner Tecnologico, a cui non è chiesta nessuna standardizzazione delle interfacce esposte al cliente, si viene a creare una dipendenza “a cascata” dai vari partner tecnologici, economicamente poco sostenibile e tecnicamente ingiustificata.
Con buona pace della promessa di riconciliazione automatica e riduzione della spesa corrente (canoni) degli anni successivi.
