Gestionali che non si parlano: il prezzo dei silos in Comune

Doppie digitazioni, dati disallineati, export negati: i gestionali che non dialogano tra loro costano all'ente molto più di quanto appaia in bilancio.

La stessa anagrafica inserita tre volte in tre sistemi diversi. La ragioneria che ricopia a mano gli importi dal gestionale dei tributi. La pratica che passa da un ufficio all'altro come allegato di una email, perché i due software non hanno mai imparato a parlarsi. Sono scene ordinarie in molti Comuni, così ordinarie che non vengono nemmeno più percepite come un problema: sono «il modo in cui si lavora qui». Eppure ciascuna di quelle scene è un costo: di tempo, di errori, di dati che smettono di combaciare. E la somma di quei costi, in un ente di medie dimensioni, assorbe una parte tutt'altro che marginale del lavoro amministrativo quotidiano.

Dove nascono i silos

I silos non nascono da scelte sbagliate, ma dalla stratificazione: ogni ufficio ha acquistato negli anni il proprio applicativo, spesso da fornitori diversi, ciascuno con il proprio database e la propria logica. Le integrazioni, quando sono state promesse, si sono rivelate progetti costosi una tantum — fragili al primo aggiornamento — oppure non si sono mai fatte, perché nessuno dei fornitori aveva interesse ad aprire il proprio sistema.

Il risultato è un ente che possiede i propri dati molte volte, in versioni leggermente diverse, senza sapere quale sia quella giusta. E quando arriva un adempimento nuovo — una piattaforma nazionale, una rendicontazione, un monitoraggio — la domanda è sempre la stessa: da quale sistema estraiamo i dati, e chi li ricontrolla a mano?

Il conto, voce per voce

Il costo dei silos non compare in nessuna fattura, ma si compone di voci molto concrete. Ognuna sembra piccola; insieme, dimensionano il problema.

• Le doppie digitazioni consumano ore e producono errori di trascrizione che qualcuno dovrà scovare
• I dati disallineati generano contraddizioni: il cittadino risulta diverso nei tributi e nell'anagrafe, e la bonifica è un progetto a sé
• Il cambio di fornitore diventa un ostaggio: senza export completi, migrare costa più che restare — è il lock-in nella sua forma più pura
• Gli adempimenti verso le piattaforme nazionali si fanno a mano, perché i flussi non escono dai sistemi

La via d'uscita passa da due direzioni

La prima direzione è l'ecosistema nazionale: SPID e CIE per l'identità, PagoPA per gli incassi, ANPR per l'anagrafe, SEND per le notifiche, PDND per l'interoperabilità tra enti. Sono la lingua franca della PA digitale: ogni gestionale che le parla nativamente elimina una famiglia intera di passaggi manuali. Non sono opzioni: per molti servizi sono ormai la condizione di cittadinanza digitale dell'ente.

La seconda direzione è contrattuale: pretendere API aperte e documentate da ogni fornitore, così che i sistemi possano scambiarsi i dati senza progetti speciali. Le due direzioni si sommano: la piattaforma unica dove ha senso unificare, le API dove l'esistente merita di restare. Ciò che non è più accettabile è il silo per default — perché i dati sono dell'ente, e un dato che non circola è un dato che l'ente sta pagando senza poterlo usare. Nei capitolati questo si traduce in requisiti verificabili: integrazioni native con le piattaforme nazionali dimostrate in demo, API consultabili prima della firma, tracciati di esportazione pubblici. Chi li chiede scopre in fretta quali fornitori hanno costruito per l'apertura e quali per la rendita.