Senza RTD al tavolo, i comuni non governano davvero il digitale

Immaginate la scena. È giovedì mattina, sala riunioni del Comune, tavolo lungo, caffè ancora caldo. Si discute di come riorganizzare lo sportello unico per le imprese. Siedono il Segretario Generale, i responsabili dell’Area Tecnica, dell’Area Finanziaria, dei Servizi al Cittadino. Qualcuno ha portato una slide con il confronto tra il vecchio e il nuovo processo. Si discute, si propone, si decide. La riunione dura due ore.

Il RTD, il Responsabile per la Transizione al Digitale, non c’è.

Non è stato invitato. Verrà contattato dopo, quando la decisione sarà già presa, per capire se “si riesce a fare” quello che gli altri hanno immaginato. La risposta attesa è sì o no, non “avrei un’idea migliore”.

Questa scena si ripete ogni giorno in centinaia di comuni italiani. E ogni volta che si ripete, il Comune perde qualcosa: non un’opportunità generica, ma l’occasione concreta di fare una cosa diversa, più efficiente, più utile ai cittadini, che oggi sarebbe possibile fare. Ieri no, oggi sì. Ma nessuno lo sa, perché chi lo saprebbe non era in quella stanza.

Il RTD nei comuni italiani resta fuori dalle decisioni

Il RTD è una figura prevista dal Codice dell’Amministrazione Digitale dal 2017. Quasi dieci anni fa. In teoria è il punto di sintesi tra la visione strategica dell’ente e le possibilità offerte dalla tecnologia. In pratica, nella stragrande maggioranza dei comuni italiani, svolge un ruolo ben diverso: gestisce i contratti con i fornitori software, segue gli aggiornamenti dei gestionali, risponde ai ticket interni, presidia le scadenze di AgID.

Lavoro utile, certo. Ma non è strategia. È amministrazione dell’esistente.

Il problema non è la competenza del RTD, che spesso è elevata e aggiornata. Il problema è strutturale: in molti enti il digitale viene pensato come un’infrastruttura di supporto, non come una variabile con cui progettare i servizi. Esattamente come l’elettricità: ci deve essere, deve funzionare, ma non la inviti a decidere come organizzare gli uffici.

Il risultato è che nei comuni italiani la governance digitale è spesso formalmente esistente e sostanzialmente assente. C’è il RTD nominato, c’è il piano di informatizzazione, c’è persino qualche misura del PNRR completata. Ma il digitale non entra nel ragionamento strategico quando si decide come erogare un servizio, come riorganizzare un processo, come rispondere a un bisogno nuovo della comunità. Entra dopo, quando il ragionamento è già chiuso.

Dal Piano Triennale alla trasformazione digitale reale

C’è una cosa curiosa nel panorama della digitalizzazione pubblica italiana. Da un lato, AgID produce ogni anno un Piano Triennale per l’Informatica nella PA di crescente sofisticazione: piattaforme abilitanti, interoperabilità, cloud, intelligenza artificiale, dati aperti. Un documento che, se applicato, ridisegnerebbe radicalmente il modo in cui i comuni erogano servizi.

Dall’altro lato, nei comuni queste visioni arrivano come adempimenti. Si adotta la piattaforma pagoPA perché è obbligatorio, si attiva SEND perché c’è una scadenza, ci si connette alla PDND perché lo dice la norma. Il “perché” non è “vogliamo erogare servizi migliori ai cittadini” ma “dobbiamo essere compliant”.

Il Piano Triennale 2024-2026, aggiornamento 2026, è esplicito su questo: chiede agli enti di passare da una logica di adempimento a una logica di trasformazione. Ma questa transizione non avviene per decreto. Avviene quando qualcuno, dentro l’ente, sa cosa è possibile fare con gli strumenti disponibili e ha la possibilità di dirlo nelle sedi in cui si decide.

Quel qualcuno dovrebbe essere il RTD. Ma se il RTD non è al tavolo della pianificazione strategica, il Piano Triennale rimane un documento di riferimento per i tecnici, non una bussola per la governance dell’ente.

Quando la strategia digitale la guidano i fornitori

Qui arriva la parte scomoda. Perché se la strategia tecnologica del comune non la costruisce il RTD insieme alla dirigenza, qualcun altro la costruisce al posto suo. E quel qualcuno non è neutro.

I fornitori software che presidiano il mercato della PA locale hanno una visione chiara di cosa deve diventare il comune: un buon cliente dei loro pacchetti, solo i più illuminati vogliono anche farlo evolvere. Arrivano con le loro roadmap, i loro moduli aggiuntivi, i loro aggiornamenti. Propongono funzionalità nuove nel linguaggio che conoscono, che è il linguaggio della loro soluzione. L’ente, spesso, non ha la capacità interna di valutare se quella funzionalità risponde davvero a un bisogno reale o se è una risposta a un problema che il fornitore ha costruito ad hoc.

Il problema è aver delegato il pensiero strategico a chi aveva un interesse a orientarlo in una direzione precisa.

Non è una critica ai fornitori. È una fotografia di un vuoto. Il vuoto che si crea quando nessuno, dentro l’ente, ha il mandato e la visibilità per dire: “Attenzione, esistono strade diverse da quella che ci stanno proponendo.”

Cosa significa portare la tecnologia al tavolo della strategia

Chiariamo subito una cosa, perché il rischio di fraintendimento è alto. Portare la tecnologia al tavolo della strategia non significa trasformare le riunioni dirigenziali in presentazioni di prodotti software. Non significa che il RTD arrivi con le slide del fornitore e spieghi le funzionalità del nuovo gestionale.

Significa qualcosa di molto più specifico e di molto più difficile: saper dire, in linguaggio comprensibile alla giunta e ai dirigenti, cosa è diventato possibile fare oggi che ieri non lo era. E collegare quella possibilità a un bisogno reale dell’ente.

Esempi concreti per i servizi comunali

Qualche esempio concreto, per restare ancorati alla realtà dei comuni italiani.

Oggi è possibile costruire sistemi di analisi automatica degli atti amministrativi che individuano incongruenze, errori di compilazione o mancanza di documentazione prima che l’atto venga protocollato. Non è fantascienza: è l’applicazione di strumenti di intelligenza artificiale a flussi documentali strutturati. Per un comune che gestisce centinaia di pratiche ogni mese, l’impatto in termini di qualità e velocità può essere rilevante.

Oggi la PDND, la Piattaforma Digitale Nazionale Dati, consente a un comune di interrogare banche dati di altri enti pubblici senza chiedere al cittadino di portare certificati. Il comune può sapere se un richiedente un sussidio ha già percepito prestazioni analoghe da altro ente, senza che il cittadino debba produrre documentazione. Questo non è solo una semplificazione: è un cambio di paradigma nel rapporto tra ente e persona.

Oggi è possibile automatizzare la gestione di flussi documentali ripetitivi, come le comunicazioni di avvio procedimento, le richieste di integrazione documentale, le notifiche di conclusione. Non per eliminare il lavoro degli uffici, ma per liberare tempo da dedicare ai casi complessi, a quelli che richiedono davvero giudizio umano.

Nessuna di queste cose è difficile da capire. Ma nessuna di queste cose entra nell’agenda strategica di un comune se non c’è qualcuno che la porta, con il linguaggio giusto, nel momento giusto, alla persona giusta.

Il nuovo compito del RTD è tradurre il possibile

Tutto questo richiede al RTD, o al dirigente con delega al digitale, una competenza che non è tecnica. O meglio, non è solo tecnica. È una competenza di traduzione.

Tradurre il possibile tecnologico in opportunità organizzativa, in miglioramento del servizio, in risposta a un bisogno della comunità. Prendere quello che esiste, quello che funziona, quello che è già disponibile, spesso gratuitamente o a costi contenuti, e trasformarlo in una proposta comprensibile a chi governa l’ente.

Questa capacità non si forma da sola. Richiede che il RTD esca dalla propria dimensione operativa e cominci a frequentare le conversazioni strategiche dell’ente, anche solo come osservatore, prima di potervi contribuire. Richiede che si aggiorni non solo sulle tecnologie, ma sui bisogni dell’organizzazione, sui vincoli normativi, sulle priorità politiche dell’amministrazione.

Richiede, soprattutto, che impari a non parlare di server, di licenze, di larghezza di banda. O almeno, che non inizi da lì. Il Segretario Generale che deve decidere se riorganizzare lo sportello unico non ha bisogno di sapere quanta RAM ha il server dell’ente. Ha bisogno di sapere se la tecnologia disponibile può aiutarlo a fare quella cosa che ha in mente, in quanto tempo, con quali rischi e con quali benefici.

Se il RTD sa rispondere a quella domanda in quel modo, cambia tutto. Smette di essere il tecnico da chiamare per implementare le decisioni degli altri e diventa un interlocutore con cui prendere le decisioni. È un salto di ruolo enorme, e non è indolore. Ma è il salto che la PA deve compiere per non restare ferma.

Come costruire una governance digitale con il RTD al centro

Non basta volerlo. Ci vogliono condizioni organizzative precise, e alcune di queste dipendono dalla volontà politica dell’ente, non solo dalla competenza del RTD.

Mandato, coinvolgimento, formazione e fiducia

La prima condizione è che il mandato del RTD sia reale, non nominale. Questo significa che nel Piano Esecutivo di Gestione, il PIAO, nei documenti di programmazione dell’ente, il digitale sia presente come variabile con cui progettare i servizi, non come capitolo separato di adempimenti tecnici. Il RTD deve avere obiettivi collegati ai risultati dell’ente, non solo alla tenuta dei sistemi informativi.

La seconda condizione è che il RTD sia coinvolto nelle fasi iniziali dei processi di cambiamento, non in quelle finali. Non quando si deve implementare qualcosa di già deciso, ma quando si sta ancora definendo cosa fare. Anche solo come consulente interno, anche solo per porre domande: “Avete considerato che con gli strumenti disponibili oggi si potrebbe fare diversamente?”

La terza condizione riguarda la formazione. Non la formazione tecnica del RTD, ma la formazione digitale della dirigenza e della giunta: la capacità di ascoltare e valutare le proposte tecnologiche, di fare domande pertinenti, di distinguere una soluzione efficace da una che suona bene in presentazione. Una dirigenza digitalmente analfabeta non è un interlocutore credibile per il RTD, e finisce per escluderlo dalla conversazione non per malevolenza, ma per incapacità di valutarne il contributo.

La quarta condizione è la più semplice da enunciare e la più difficile da realizzare: fiducia. Il RTD deve potersi fidare del fatto che portare un’idea nuova, anche un’idea che cambia piani già fatti, non gli costi una perdita di credibilità. E la dirigenza deve potersi fidare del fatto che il RTD parla nell’interesse dell’ente, non nell’interesse di un fornitore.

La strategia del fornitore non può sostituire quella dell’ente

C’è una frase che sento spesso nei corridoi degli enti pubblici, variamente declinata: “Noi siamo una PA, non possiamo permetterci di sperimentare.” Come se l’innovazione fosse un lusso per chi ha risorse abbondanti, e non invece una necessità per chi le risorse le deve ottimizzare.

La verità è che i comuni italiani stanno già innovando, ogni giorno: adottano nuove piattaforme, cambiano processi, introducono strumenti digitali. La domanda non è se innovare, ma chi guida l’innovazione. E se a guidarla non è qualcuno che conosce le esigenze dell’ente e ha il mandato di perseguirle, la guida qualcun altro, con obiettivi diversi.

Un fornitore software ottimizza per la retention del cliente, non per l’efficienza del processo amministrativo. Non è una colpa: è la natura del mercato. Ma è un problema quando queste logiche entrano nella governance di un ente pubblico senza che nessuno le filtri.

Il RTD è il filtro. O dovrebbe esserlo. Ma un filtro che non è inserito nel sistema non filtra niente.

La PA italiana ha investito anni a costruire una figura come il RTD: a definirne il ruolo per legge, a formarla, ad aggiornarla. Sarebbe un peccato lasciare che quella figura continui a presidiare sale server invece di presidiare tavoli decisionali. Non perché le sale server non contino, ma perché i tavoli decisionali contano di più.

La tecnologia è già lì, disponibile, matura, spesso già pagata. La domanda che ogni comune dovrebbe farsi non è “ce la possiamo permettere” ma “abbiamo qualcuno che sa dirci cosa potremmo farne?” E se la risposta è sì, la domanda successiva è: quella persona è stata invitata alla riunione di giovedì mattina?