Una nuova politica dell’informatica nella Pubblica Amministrazione

di Enrico Nardelli

In questo articolo rifletto su uno degli elementi cruciali per la realizzazione di una Pubblica Amministrazione (PA) efficiente ed efficace. Si usa spesso a tal proposito il termine “trasformazione digitale”, che se da un lato ricorda l’urgenza di avere una PA adeguata alla società digitale, dall’altro ha secondo me il difetto di richiamare l’attenzione solo sul momento di transizione, mettendo in ombra la situazione a regime. Invece, come sarà più chiaro nel seguito, l’informatizzazione (termine che io preferisco) della PA, così come di ogni altra organizzazione, è un processo continuo, da affrontare in modo diverso da come fatto finora.

Vediamo perché. Venti anni fa, nel 1998, l’uomo della strada non usava né posta elettronica né reti sociali, e la tecnologia ci aveva dato il telefonino. Questo però non era niente altro che il caro buon vecchio telefono, solo che potevamo averlo sempre in tasca con noi dovunque andassimo.

Adesso è come se fossimo su un pianeta diverso, fatto di email, di tweet, di post, di password e di account e via storpiando la nostra bella lingua. Ma questa è solo la superficie. Sotto sotto, noi siamo sempre gli stessi esseri umani, tant’è che, “buoni” e “cattivi”, continuiamo a compiere le stesse azioni. I cattivi, soprattutto, hanno capito forse meglio dei buoni come fare le stesse cose in maniera più produttiva.

Invece, a livello di organizzazioni, questa esplosione della tecnologia digitale è stata enormemente più rivoluzionaria. Ha permesso di automatizzare funzioni un tempo alla portata esclusivamente del cervello umano, ma con il fondamentale tallone d’Achille di non avere la flessibilità e l’adattabilità dell’essere umano. Ho discusso altrove più in dettaglio questi aspetti.

Ciò che qui mi preme sottolineare è che una qualunque applicazione informatica è l’automazione di funzioni legate alle capacità cognitive della persona. Tipicamente, infatti, un’organizzazione acquisisce un sistema informatico per rimpiazzare, mediante un sistema automatico, facoltà cognitive precedentemente esplicate da una o più persone. Si individuano, una volta per tutte, quali sono le funzioni da automatizzare e queste vengono sostituite da un sistema informatico, cioè una “macchina cognitiva” che è la corrispondente, nella società digitale, alla macchina tradizionale della società industriale.

Questa sostituzione, come ogni automazione, avviene per migliorare la produttività, cioè aumentare l’output o diminuire i costi o entrambe le cose. Fin qui niente di male: l’automazione del lavoro è da secoli il fattore chiave che assicura un costante aumento di produttività.

Aver acquisito un sistema informatico vuol dire quindi aver sostituito ad una o più persone una o più “macchine cognitive”. Ma queste, senza capacità di adattamento, non sono in grado di evolversi per far fronte al mutare delle condizioni al contorno. Per questo l’acquisizione o lo sviluppo di un qualunque applicazione informatica deve seguire un percorso diverso.

È necessario cambiare prima di tutto il paradigma mentale con cui si affronta l’automazione informatica. Ogni organizzazione sa bene, quando assume un economista, un ingegnere, un legale o un contabile, che ciò che sa fare quella persona all’inizio non rimarrà immutato nel tempo, ma si evolverà, perché la persona imparerà sul campo tutta una serie di dettagli rilevanti per l’organizzazione stessa ed adatterà il proprio comportamento man mano che il suo scenario operativo si evolve. Ovviamente, all’inizio sotto la guida del suo responsabile, e poi sempre con maggiore grado di autonomia.

Se una parte di questo lavoro cognitivo viene trasferito a sistemi informatici, vengono meno questa flessibilità e capacità di evoluzione, che sono specifiche e caratterizzanti gli esseri umani. Non cambiare questo paradigma mentale vuol dire continuare a sprecare soldi con lo sviluppo di sistemi informatici.

Questo non accade perché la PA italiana sia particolarmente incapace. Gli USA sono spesso giustamente indicati come un modello di riferimento, ma la loro PA, rispetto alla realizzazione dei sistemi informatici è esattamente nelle nostre condizioni. Riprenderò questa situazione più avanti.

L’approccio quindi da usare è considerare l’acquisizione di un sistema informatico come l’acquisizione di una certa quantità di persone con certe competenze di base. Nessun selezionatore del personale si aspetta di trovare sempre “il candidato perfetto”, perché questa non è affatto la norma. Si cerca di trovare una persona col profilo sufficientemente buono per poter “scendere in campo” con efficacia e poi, da lì, evolversi.

Con i sistemi informatici bisogna adottare lo stesso approccio. Il che non vuol dire prendere il primo sistema che capita, ma far diventare parte del processo di acquisizione lo sviluppo incrementale e co-costruito (da utenti e sviluppatori, da committenti e fornitori) del sistema stesso. Esattamente come accade con i dipendenti. Tutti coloro che si occupano di queste problematiche sanno quanto sia complicato l’inserimento di una squadra di 10 dipendenti in un gruppo di 100, tanto più quanto maggiore è la componente cognitiva e non fisica delle attività svolte nell’organizzazione. Quando si digitalizza un processo aziendale si sta facendo sostanzialmente la stessa cosa. Perché dovremmo procedere in modo diverso? Se lo facciamo è perché non abbiamo capito che quella informatica è un’automazione radicalmente diversa da ogni altra e che richiede un approccio diverso.

Come si procede attualmente? Il tradizionale flusso di acquisizione di servizi e prodotti della PA italiana (ma in questo le PA sono sostanzialmente uguali in tutto il mondo) prevede una fase iniziale di definizione dei requisiti del servizio/prodotto necessario con la scrittura di specifiche di dettaglio, a fronte delle quali le aziende propongono offerte. La migliore (in base al costo più una componente di valutazione tecnica) vince ed il contraente inizia a realizzare quanto richiesto. Al termine, se il servizio/prodotto supera i test finali, si entra nella fase operativa.

Quali sono le conseguenze dell’attuale approccio? Sia nella PA italiana che nel resto del mondo, i programmi di sviluppo che prevedono la realizzazione di componenti software sono sempre quelli in maggior ritardo e con i maggiori sforamenti di costi. Recentemente, il direttore del Dipartimento Acquisti del Ministero della Difesa USA (il DOD), Will Roper, ha dichiarato che il sistema di acquisizione tradizionale usato per decenni per comprare navi ed aeroplani, “non funziona per il software” perché “un sistema software non è mai finito, è un processo continuo”.

Le aziende informatiche più innovative al mondo hanno da tempo capito che questo metodo non funziona. Se gli utenti vedono il software solo alla fine, è altamente probabile che non solo i requisiti inizialmente definiti non saranno stati soddisfatti ma anche che ciò di cui hanno bisogno è nel frattempo cambiato. Dalla collaborazione tra il mondo della ricerca e quello dell’industria è emerso da circa una ventina d’anni un approccio radicalmente diverso allo sviluppo del software, l’approccio cosiddetto “agile” (anche in inglese il termine è lo stesso, solo pronunciato diversamente), che è quello appunto usato dalle aziende informatiche all’avanguardia, perché consente loro di sviluppare servizi/prodotti di successo.

D’altro canto, se ci pensate bene, questo è quello che vediamo nelle App di successo che tutti noi usiamo ogni giorno. A noi sembrano sempre le stesse, ma dietro la facciata c’è un lavorìo continuo di aggiornamento ed evoluzione. Appunto, come accade con le persone che, dietro la facciata di un’organizzazione, ci forniscono i suoi servizi. Si evolvono al cambiare delle condizioni al contorno o in funzione di un’eventuale cambiamento deciso dalla direzione. Nel mio articolo di quasi dieci anni fa citato all’inizio avevo scritto, a proposito dello sviluppo dei sistemi informatici: “la manutenzione è la vera implementazione”.

È quindi necessario un radicale cambiamento di paradigma che, ripeto, dev’essere soprattutto un cambiamento mentale.

Da un punto di vista procedurale, l’acquisizione di sistemi informatici non dovrà più, quindi, essere basata sulla definizione iniziale di tutti i requisiti, ma andrà individuato un ristretto insieme di obiettivi e casi d’uso iniziali, sui quali un piccolo gruppo congiunto di sviluppatori e utenti inizierà a lavorare con il compito di produrre un primo nucleo funzionante nel giro di qualche settimana. Da lì in avanti si continua con questo approccio iterativo, che è appunto quello definito “agile”, imparando costantemente da successi ed errori sul campo ed aggiustando il tiro in funzione dell’evolversi degli scenari.

È un cambiamento epocale se si considera l’acquisizione di un sistema software alla stregua di un qualunque altro prodotto. È la soluzione naturale, se la guardiamo nell’ottica dell’acquisizione di personale.

È evidente che questo nuovo paradigma di acquisizione non potrà mai essere adottato dalla PA italiana se non è in accordo con il contesto legale di riferimento. Sarà quindi necessario cambiare l’intero apparato regolamentare che disciplina le procedure con le quali la PA acquisisce sistemi informatici. Qui è necessario uno sforzo fortemente interdisciplinare, perché vanno mobilitate tutte le competenze che entrano in gioco in questo processo: giuridiche, documentarie, informatiche, gestionali, psicologiche, sotto la guida – va da sé – di una politica che deve farsi carico in prima persona della risoluzione di problemi annosi.

Non è un processo breve, richiederà molti anni, ma potrebbe essere un progetto di legislatura volto a lasciare agli Italiani un Paese migliore.

Versione originale pubblicata su "Agenda Digitale" il 31 gennaio 2019.