Mentre si fa un gran parlare (e giustamente) di servizi web, rimane sempre fuori dai radar una voce di costo informatico estremamente rilevante nella PA italiana: quella per lo sviluppo dei software a uso dei dipendenti. Nei più svariati settori: dagli uffici anagrafe, ai servizi sociali, al catasto, all’ambito medico-sanitario.

Il tema si interseca con quello dei servizi online rivolti al cittadino. Perché spesso questi operano sugli stessi “oggetti”, e spesso con funzioni simili, a quelli di questi software che possiamo chiamare di back-office. Ad esempio, se un cittadino può, che ne so, prenotare esami sanitari online grazie a un nuovo servizio online della sua Azienda Sanitaria, la funzione dovrà in qualche maniera utilizzare lo stesso database di prenotazioni sul quale opera anche il software dell’operatore dell’ufficio prenotazioni che riceve i cittadini allo sportello.

E così via: ogni cosa che si mette online per il cittadino, non opera in solitudine (tranne rari casi) ma interopera con basi di dati già esistenti su cui operano altri software, a volte di molte generazioni fa (quindi con logiche molto diverse da quelle che operano oggi attraverso le tecnologie web attuali).

La moltiplicazione dei software e dei pesci

Questa interoperabilità è ovviamente un problema. Ma c’è un altro problema, altrettanto occulto: il fatto che molti soldi vengano spesi per realizzare adattamenti continui alle nuove normative o alle modifiche delle stesse.

Un esempio su tutti.

Quando è stato introdotto il SIA, sostegno al reddito sperimentato in alcune regioni, le aziende informatiche regionali hanno dovuto (o avrebbero dovuto…) realizzare dei software per l’apertura della pratica con il cittadino che ne facesse richiesta, che comprendesse la registrazione dei dati, delle firme sui moduli, il possesso dei requisiti, l’accettazione delle condizioni, il calcolo dei parametri economici. A volte queste procedure richiedono una comunicazione fra diversi uffici (per esempio con i Centri per l’Impiego, o l’INPS). Insomma, sono cose che devono essere usate dagli operatori pubblici ogni giorno, se si vuole che il provvedimento venga attuato.

In molti casi l’applicazione dei provvedimenti come il SIA varia da regione a regione, a volte viene attuata in modo diverso anche in parti diverse della stessa regione: questo si traduce naturalmente in una moltiplicazione dei costi.

Spesso poi i tempi di implementazione delle misure normative sono estremamente accelerati, anche per ragioni di comunicazione politica. Questo fa mancare altrettanto spesso i tempi tecnici per un’analisi e una progettazione efficace, lasciamo stare orientata al cittadino, di questi software. Che poi vengono corretti in corsa. Quando vengono corretti, intendo…

Quando i costi si scaricano sui dipendenti

A volte si verificano casi in cui gli operatori pubblici sono costretti a iniziare a implementare le misure senza avere ancora la disponibilità del software. Raccolgono documentazione cartacea, obbligandosi poi a reinserire i dati nel sistema informatico non appena il software viene rilasciato.

Ma non solo: a volte, semplicemente, proprio per una scarsa linearità e prevedibilità delle norme, insomma, per incertezza politica, si preferisce aspettare prima di realizzare il software. Magari la norma cambia. Formalmente quindi la misura, la policy inizia ad essere attuata, ma senza fornire ai dipendenti gli strumenti per farlo.

Questo rende l’implementazione delle politiche inefficaci, e sicuramente la produttività dei dipendenti si abbassa… ma non per colpa loro! Quando si parla di inefficienza della PA, i media generalisti forse dovrebbero iniziare a parlare non solo dei “furbetti del cartellino”, che ci sono, ma sono una minoranza; ma pure delle condizioni nelle quali i dipendenti pubblici che vogliono lavorare si trovano costretti a operare. Non solo a livello informatico: ma anche a livello informatico.

Cambiare per cambiare, non importa a quale costo

Ma c’è dell’altro. Nell’esempio del SIA di cui s’è detto sopra, la sperimentazione è partita in alcune regioni da pochi mesi, e da poco si è deciso di sostituirla con una misura differente, il REI, reddito di inclusione. Ebbene, senza entrare nel merito dei singoli provvedimenti, che non ci competono: qualcuno si è posto il problema di quanto costi modificare/adattare i software per attuare questi cambi di politiche? Passare da una misura all’altra, dal punto di vista degli strumenti informatici?

E, se queste modifiche non vengono realizzate per ragioni di tempo o di costi, quanto ci costi in ore uomo buttate il lavoro dei dipendenti che sono costretti a operare senza lo strumento informatico, o con uno strumento informatico inefficiente, che provoca errori, danneggia i cittadini e aumenta lo stress lavoro-correlato?

E’ chiaro che una sperimentazione va fatta, per politiche di questo genere: ma non sarebbe meglio in quei casi evitare di produrre software diversi, per poi trovarsi ad aggiornarli o a sostituirli, e partire subito con un software unico per le diverse realtà locali che si candidano alla sperimentazione, magari fornito dallo Stato, e già pensato per eventuali successive modifiche qualora dalla sperimentazione si passasse a una misura definitiva?

Il sistema operativo delle applicazioni pubbliche

In tempi di design-jam, di codesign e di linee guida, utili ma ancora lente a produrre servizi online per il cittadino, vi è tutto un capitolo di produzione informatica grosso, rilevante, e completamente occulto nella PA italiana che contribuisce all’inefficacia e all’inefficienza della macchina amministrativa. E, no, non sono i dipendenti. Non sono le regole tecniche. Sono le decisioni dall’alto.

E’ possibile che l’annunciato “sistema operativo della PA” in fase di realizzazione dal team guidato da Diego Piacentini possa rendere presto più semplice sia la rapida implementazione di strumenti software (anche realizzati da soggetti diversi, che si troverebbero parte dell’infrastruttura realizzata e API ben definite), che più rapida una loro modifica. Togliendo discrezionalità alle molte aziende private che ci lavorano, velocizzando al tempo stesso il loro lavoro. Ce lo auguriamo, perché di questo ci sarebbe davvero bisogno, anche più di SPID.

Sarebbe bello se, ogni tanto, ne parlassimo.