Dal magazine – edizione gennaio/febbraio 2026
Il déjà-vu del 2008: quando già il problema non era il software
Chi lavora sui sistemi informativi dei servizi a rete (acqua, energia, rifiuti) sa molto bene che, seppur le tecnologie cambino, alcuni ostacoli ideologici restano. Era il 2008 quando, durante una sessione del convegno MondoGIS, l’attenzione della platea veniva richiamata su un punto focale: il vero ostacolo al successo dei progetti tecnologici non era la mancanza di strumenti software, ma l’incapacità delle strutture organizzative di collaborare, condividere dati e assumersi responsabilità trasversali. A distanza di quasi diciotto anni, nonostante l’avvento del cloud, dell’Intelligenza Artificiale e della rivoluzione digitale, ci ritroviamo a discutere delle medesime criticità. Sembra che il settore sia intrappolato in un “loop” temporale dove la tecnologia progredisce a ritmi esponenziali, ma la cultura decisionale e collaborativa rimane ancorata a dinamiche di “burocrazia difensiva” e a compartimenti stagni. Il PNRR avrebbe dovuto essere il catalizzatore del cambiamento, ma rischia di diventare l’ennesima occasione per alimentare una burocrazia che guarda alla forma piuttosto che alla sostanza del risultato.
La scelta “rassicurante” del grande brand
Il problema si genera quando, in seno alle Utility, la scelta di una piattaforma ERP o GIS non viene gestita come una decisione ingegneristica basata su requisiti funzionali e flussi operativi. Al contrario, diviene una scelta percepita come “di campo”, dove il marchio di software dominante diventa sinonimo di affidabilità a prescindere. Si radica così un automatismo mentale pericoloso: se si parla di gestione aziendale complessa, la risposta deve essere BRAND X; se si parla di cartografia e reti, la risposta deve essere BRAND Y. È un riflesso comprensibile; scegliere un leader di mercato può sembrare una forma di autotutela amministrativa, perché la decisione appare più facilmente difendibile. Ma è anche la quintessenza della burocrazia difensiva. Il punto, però, non è contrapporre grandi vendor e piccoli fornitori. Il punto è assicurarsi che il grande brand non sostituisca la verifica tecnica. Esistono soluzioni, anche sviluppate da PMI italiane ed europee, mature, affidabili e adottate da anni in organizzazioni identiche per dominio e necessità. Valutarle con criteri oggettivi è doveroso; riduce il rischio reale e aumenta l’aderenza ai processi.
La frattura tra chi decide e chi opera: governance e capitolati
Un segnale tipico di questo clima è la frase: “Tecnicamente siete più aderenti alle necessità, ma dall’alto hanno deciso diversamente”. Qui si rivela in tutta la sua ampiezza la frattura tra direzioni generali e uffici acquisti, da un lato, e uffici tecnici e operativi, dall’altro. Chi presidia budget e procedure, raramente userà gli strumenti nel quotidiano, mentre chi li usa non ha peso nella definizione dei requisiti. In questi vuoti si inseriscono capitolati-fotocopia e consulenze esterne, competenti sul Codice degli Appalti ma non altrettanto sulle specificità di dominio (basti pensare alle peculiarità del Sistema Idrico Integrato e del mondo rifiuti a Tariffa Puntuale). Ne derivano griglie di punteggio che premiano descrizioni teoriche, certificazioni e completezza formale più della reale efficacia operativa e aderenza ai requisiti tecnici del software.
PNRR, fiducia e risultato: principi sacrosanti, applicazione da rendere concreta
Il nuovo Codice degli Appalti e l’impostazione PNRR hanno introdotto due concetti rilevanti: la fiducia e la preminenza del risultato. L’intento è chiaro: semplificare per innovare. Nella pratica, però, paura della firma e timore di ricorsi, spingono spesso verso requisiti economico- finanziari sproporzionati, con l’effetto di alzare barriere che penalizzano le PMI innovative. Il risultato è un mercato in cui molte competenze entrano solo tramite Raggruppamenti Temporanei di Imprese (RTI), dove il partner “grande” garantisce copertura finanziaria, ma non sempre porta la soluzione più adatta sul piano tecnico. Così si irrigidiscono architetture, si allungano i tempi e si alzano i costi per la collettività.
Integrazione nativa e sovranità del dato: l’architettura del servizio
Un sistema isolato, anche se prestigioso, genera inefficienza. Nelle Utility moderne l’integrazione non è un’opzione: è l’architettura del servizio. Il GIS non può essere un semplice visore e l’ERP non può essere solo contabilità. I dati devono fluire tra modellazione, asset management, forza lavoro sul campo, manutenzione e fatturazione. Quando si sceglie una soluzione di grido, ma che risulta poi essere rigida, emerge il costo occulto delle integrazioni personalizzate: ogni riconciliazione manuale tra sistemi diversi è una tassa invisibile, ma significativa. Per questo diventano centrali modelli dati aperti e portabili, basati su standard consolidati (PostgreSQL/PostGIS, SQL Server), e API documentate. La proprietà e la portabilità delle informazioni sono un asset strategico per le utility.
Focus tecnico: il “metodo del risultato” per valutazioni meno opinabili
Per riportare la tecnologia al servizio della funzione, le gare ICT dovrebbero evolvere dalle relazioni descrittive a evidenze pratiche e misurabili. Quattro leve, semplici e difendibili, per una valutazione realistica dell’adeguatezza degli strumenti tecnologici:
- Stress-test sul campo: A fronte di relazioni che spesso ricalcano semplicemente le richieste di capitolato, la commissione dovrebbe chiedere ai concorrenti di dimostrare sul campo di avere quanto richiesto e dichiarato.
- Calcolo del TCO (Total Cost of Ownership): Un software che richiede onerosi investimenti di adattamento normativo e di dominio, indipendentemente dal prezzo d’acquisto, rappresenta un investimento non vantaggioso. La valutazione deve poter distinguere esplicitamente tra le funzionalità, già disponibili ed operative, e quelle ancora da implementare. Questa trasparenza consente al decisore tecnico di pesare correttamente le funzionalità non disponibili ed i rischi relativi, derivanti dai tempi di messa in esercizio di ciascuna proposta.
- Test di usabilità “Zero Training”: Il software deve avere un alto livello di usabilità e tener conto delle diverse caratteristiche dell’utente che opera in ufficio e di quello che opera sul campo. Se l’utilizzo richiede settimane di formazione e non risponde alle aspettative, la resistenza al cambiamento del personale diventerà il principale motivo di fallimento del progetto.
- Interoperabilità e “no lock-in”: Bisogna premiare chi offre API (Application Programming Interface) aperte e documentate e quindi la garanzia di proprietà certa del dato, in quanto esportabile anche autonomamente. L’Utility deve essere libera di cambiare fornitore in futuro, senza artificiosi impedimenti e senza dover riprogettare il tutto.
Fattore umano e compliance ARERA: la qualità passa dal dato
La tecnologia deve aiutare a rispettare obblighi normativi sempre più stringenti. ARERA, con la regolazione sulla qualità tecnica (RQTI e TQRIF) e commerciale, ha reso il dato, spesso georeferenziato, il perno della gestione del servizio: localizzare un punto di fornitura, tracciare interventi, pianificare manutenzioni e alimentare indicatori. Qui il discrimine non è la “marca” del software, ma la competenza di dominio incorporata nei processi e nei controlli di qualità del dato. Esistono applicazioni nate in Italia, per il mercato italiano, che integrano gestione asset, manutenzione e produzione di indicatori: valutarle con criteri oggettivi non è un favore alle PMI, è una scelta razionale nell’interesse del servizio e del sistema- paese.
Conclusioni: scegliere con responsabilità professionale
Per uscire dal “loop” evidenziato già nel 2008 serve un cambio di impostazione: riportare la scelta ICT dai loghi alle evidenze. La fiducia non può essere un assegno in bianco, ma deve essere un patto basato su prove e risultati misurabili. E modificare le gare non significa complicarle inutilmente: significa legare ogni punto di punteggio a un riscontro verificabile. Solo così gli investimenti, fatti con i finanziamenti PNRR, lasceranno in eredità alle Utility, non “nomi importanti” da sbandierare, ma sistemi interoperabili, capaci di migliorare la qualità del servizio per cittadini, la fruibilità per le imprese e di garantire un ciclo di vita delle infrastrutture tramite manutenzione e controllo, capaci di assicurare al paese un ritorno del prestito PNRR. È tempo che la tecnologia torni a sposare la funzionalità, con scelte tecniche difendibili perché misurabili.
