Per i pochi che ancora non lo sapessero, RTD sta per Responsabile per la transizione al digitale nel mondo della Pubblica Amministrazione.
Questa figura che dovrebbe sommare in sé competenze informatiche, di informatica giuridica e competenze organizzative è prevista all’art. 17 del Codice dell’Amministrazione digitale.
Insomma, una sorte di ircocervo.
Questa figura, come si capirà, importantissima, dovrebbe guidare, meglio coordinare, i processi di digitalizzazione nelle Pubbliche Amministrazioni.
Alla fine del 2019 i Responsabili per la transizione al digitale erano, secondo AGID, 5200.
Proprio per questo motivo, la diffusione forte e capillare degli RTD (anche se ancora non tutti gli Enti Pubblici hanno nominato un RTD), mi fa sentire la necessità di scrivere le considerazioni che seguiranno come esortazione a qualificare e a precisare meglio le attività in capo agli RTD.
Il mio timore infatti è che la figura del RTD divenga, con il trascorrere del tempo, una sorta di “funzione ordinaria” nella Pubblica Amministrazione. Ritengo, all’opposto, che la figura del RTD debba presiedere il costante cambiamento della Pubblica Amministrazione.
Partiamo da un presupposto. Sulla base della mia esperienza non esiste oggi in Italia un dipendente pubblico nominato RTD che abbia assieme le competenze informatiche, organizzative e di informatica giuridica. Ho usato non a caso la definizione di ircocervo.
Se le competenze in materia di informatica giuridica si possono acquisire, le competenze informatiche e organizzative, soprattutto se integrate, sono tutte da acquisire.
La Legge prevede (v. art. 17 del CAD) che la figura del RTD NON possa essere impersonificata in un consulente esterno all’Ente. Il RTD DEVE essere un dipendente di quell’Ente.
Ricordo a tutti noi che la circolare n. 3 del 2018 emanata dal Ministro per la Pubblica Amministrazione, oltre a sollecitare tutti gli Enti alla nomina del RTD, ne precisa molto bene i compiti, soprattutto quelli di coordinamento, insomma una sorta di primus inter pares.
Alla luce di tutto ciò vediamo, allora, i due errori che più frequentemente incontro lavorando in molti Enti pubblici.
Il primo errore, il più comune.
Poiché erroneamente si ritiene che il processo di digitalizzazione sia una “cosa da informatici” il RTD viene identificato nel responsabile del CED, o, in una figura “che ne sa di informatica”.
Nei Comuni di più piccola dimensione, poiché al geometra capo, al ragioniere capo ecc. si è spesso affidato anche il compito di gestire “l’informatica” (a partire dal garantire l’efficienza del server) ecco che questa figura diventa “di default” il RTD.
Il secondo errore è quello di affidare al Segretario Generale dell’Ente il compito di svolgere la funzione di RTD.
Scambiando l’autorevolezza, che deriva dalla funzione svolta, con la “competenza organizzativa”, non avendo nessuno di meglio al quale affidare la figura del RTD, il Segretario Generale viene nominato RTD.
In questo modo si pensa di aver così assolto all’obbligo previsto dalla legge.
Insisto, il RTD è una figura decisiva per il futuro dei processi di digitalizzazione della Pubblica Amministrazione, per questo motivo la scelta del RTD, i poteri del RTD, l’autorevolezza del RTD, la competenza organizzativa sono decisivi.
Soprattutto gli RTD NON VANNO LASCIATI SOLI di fronte a problemi e a ritardi enormi, anche perché la Legge attribuisce al RTD responsabilità importanti per le quali risponde. Ricordo ad es. le recenti norme in materia di accessibilità degli strumenti informatici.
Il RTD non può essere un profeta disarmato.
Scrivo queste considerazioni rivolgendomi in primis ai Sindaci e alle Giunte (che nominano il RTD), ai Segretari e ai Direttori generali che consigliano il Sindaco e la Giunta sulla nomina del RTD.
Vorrei ricordare a tutti noi che il processo di digitalizzazione “di successo” in una P.A. passa, prima di tutto, attraverso profonde fasi di riorganizzazione e di formazione (rindirizzamento culturale) del personale.
Non è un caso che io parli sempre di “analisi organizzativa” e, successivamente delle “modalità di utilizzo” delle dotazioni informatiche.
Vale sempre quella mia vecchia esortazione: non si può digitalizzare l’esistente e pensare di migliorare lo stato delle cose lasciandole così come sono. L’informatica senza cambiamento organizzativo consolida il disastro.
Oggi le P.A. non hanno bisogno, quasi sempre, di comprare nulla (servizi di cloud a parte). Al massimo devono meditare sulla qualità dei fornitori, premunendosi dal rischio di lock in, garantendo sempre l’interoperabilità dei diversi flussi digitali e la disponibilità dei dati e delle informazioni.
I fornitori di software e di hardware non possono e non devono influire sui modelli organizzativi o, peggio ancora, interpretare il CAD e la legislazione vigente.
Ciò detto ….
UN PRIMO, GRANDE POTERE DA ATTRIBUIRE AL RTD.
I processi di riorganizzazione e di digitalizzazione della Pubblica Amministrazione vanno accuratamente pianificati e codificati attraverso gli strumenti previsti dalla Legge.
I tempi e le modalità, come noto, sono stabiliti dal Piano triennale redatto dall’AGID e approvato dalla Presidenza del Consiglio dei Ministri.
Attualmente nel DUP, nel PEG, nel PTCPT la pianificazione ORGANICA di questi continui processi di cambiamento (spesso scambiati per adempimenti formali) non è ricompresa o prevista in modo “alquanto artigianale”. Questa affermazione, molto dura, è figlia di un esame, molto approfondito, di molti DUP.
Il processo di digitalizzazione è spesso concepito come un costo da comprimere o come “buffi” obiettivi a partire dal famoso “tagliacarta”. La riorganizzazione non è ricompresa nella pianificazione.
Il RTD, sulla base di quanto previsto dal Piano Triennale deve predisporre annualmente il piano del proprio Ente. Ovvio che, affinché tutto non si riduca a chiacchiere, il Piano va codificato nel DUP, va inquadrato, analizzato, “pesato”, retribuito attraverso il PEG. Per alcuni versi, come ad esempio il processo di dematerializzazione e il sito, questi obiettivi vanno inquadrati anche nel PTCPT.
Chiaro che il processo di digitalizzazione, in senso lato, è sovraordinato a tutta l’attività dell’Ente.
È attraverso il momento di pianificazione che vengono esercitate le funzioni di coordinamento e di guida del RTD.
È qui che si capiscono bene le motivazioni che hanno portato il legislatore a prevedere all’art. 17 del CAD “l’ufficio per la transizione al digitale”.
L’ufficio per la transizione al digitale non va inteso come “l’ufficio informatica”, come una nuova infrastruttura verticale, quanto piuttosto esso va concepito come il momento in cui il RTD si avvale delle diverse competenze organizzative e informatiche presenti nell’Ente, che vanno coordinate per ottenere i migliori risultati.
La redazione del Piano non è frutto di autoreferenzialità informatica, quanto piuttosto di una capacità (figlia di autorevolezza) di coordinare i diversi servizi, di condividere i diversi obiettivi.
UN SECONDO GRANDE POTERE DA ATTRIBUIRE AL RTD.
Il RTD deve poter dire l’ultima parola in materia di acquisti “informatici”.
Il CAD norma agli artt. 68 e 69 lo “Sviluppo, acquisizione e riuso di sistemi informatici nelle Pubbliche Amministrazioni”.
Certamente nel processo di acquisto dei sistemi informatici vanno rispettate le norme in materia di contratti, ma ciò non è sufficiente.
Quante Amministrazioni che si servono da diversi fornitori (ogni Funzionario responsabile di servizio è spesso innamorato di un fornitore e di una soluzione applicativa) si sono preoccupati di garantire l’interoperabilità o di tutelare le condizioni di condivisione dei diversi dati.
Insomma, viene rispettato quanto previsto all’art. 68 comma 1 bis b) del CAD “livello di utilizzo di formati di dati e di interfacce di tipo aperto nonché di standard in grado di assicurare l’interoperabilità e la cooperazione applicativa tra i diversi sistemi informatici della pubblica amministrazione”??
Inoltre le Amministrazioni Pubbliche devono acquistare, a far data dal 1 aprile 2019, i loro servizi di IAS, PAS e SAS esclusivamente da Aziende accreditate nel “Cloud Marketplace di AGID“.
Nella Pubblica Amministrazione si può fare legittimamente un acquisto se viene rilasciato dall’Ufficio Ragioneria il visto di regolarità contabile.
Allo stesso modo si potranno fare scelte ed acquisti di “sistemi informatici” se il RTD rilascerà il proprio visto che attesterà quanto previsto all’articolo del CAD di cui sopra e alle disposizioni di AGID.
Interoperabilità, system integration, cloud, condivisione sono le parole d’ordine del RTD.
UN GRANDE DIRITTO PER IL RTD.
Come dicevo più sopra il RTD non può essere lasciato da solo.
Il RTD è una figura fiduciaria (di un Sindaco in un Comune ad es.). Questa figura deve contribuire a realizzare le linee di mandato o altri indirizzi programmatori.
Il RTD ha il diritto di non essere lasciato da solo di fronte ad un compito epocale. Il processo di pianificazione e di realizzazione della digitalizzazione è un compito epocale.
Chi è responsabile in un Ente della mancata adesione a PAGO PA.? Se il 1 luglio il Comune di Roccacannuccia non ha ancora aderito a PAGO PA, o non offre ancora questo servizio, chi è il responsabile (v. art. 1 comma 8 del Decreto Milleproroghe)?
Se il RTD deve garantire che l’infrastruttura informatica funzioni, il Ragioniere capo e i diversi responsabili dei settori che emettono mandati di pagamento se ne assumono tutti gli oneri.
Ciò, spessissimo, non è chiaro. È opportuno che gli OIV intervengano e che la Corte dei Conti cominci ad operare.
Il RTD non è il responsabile di tutto.
Il RTD è responsabile se non esercita tutte le funzioni e i poteri che la legge gli attribuisce.
Il RTD è responsabile se accetta questo compito convinto che si tratti di ordinaria amministrazione.
Il RTD è responsabile se non esercitare le funzioni di coordinamento.
Il RTD è responsabile se esercita questa attività come residuale rispetto a ciò che ordinariamente deve fare.
Potrei continuare ancora.
Il RTD può essere invece una attività entusiasmante e decisiva se ….
