di Alessandro Capezzuoli, funzionario ISTAT e responsabile osservatorio dati professioni e competenze Aidr

Nel famoso saggio intitolato Dal big bang ai buchi neri, Stephen Hawking invita a riflettere sulla direzione del tempo, ipotizzando di invertire la freccia e descrivendo uno scenario in cui i bicchieri rotti si ricompongono, gli esseri umani ringiovaniscono, e altre situazioni paradossali simili fino alla contrazione di tutta la materia all’interno del punto primordiale da cui è nato tutto nell’istante del big bang. Una descrizione analoga venne fatta da Woody Allen, che ipotizzò di invertire la freccia della vita e vivere in un mondo in cui si nasce anziani e si muore al momento del concepimento. In poche parole, la scienza e l’ironia dimostrano che il detto popolare “Si stava meglio quando si stava peggio” ha delle basi scientifiche solide e non è poi così populista. Anche l’informatica, o IT che dir si voglia, in particolare nella PA, non può sottrarsi al paradosso dell’inversione temporale: serve per capire meglio se, come e in quale momento sia possibile ricomporre il bicchiere rotto.

Come si gestiva un progetto di un qualsiasi sistema informativo, quando si stava peggio? In primis, c’era il capo progetto, una figura di altissimo livello a metà tra il manager e il tecnico specializzato. Il capo progetto aveva la possibilità di formare un team di persone tra le quali spiccavano l’analista e il progettista di software, delle figure mitologiche metà uomo e metà scheda madre, che raccoglievano i requisiti e diventavano esperti dei contenuti come e più degli esperti di contenuti. Studiavano a fondo il problema fino a conoscerne i dettagli, cercavano soluzioni metodologiche e tecnologiche, scrivevano le specifiche progettuali e sviluppavano soluzioni ad hoc, che rispondevano molto bene alle esigenze dell’organizzazione. Poi c’erano i programmatori, in un periodo in cui si programmava o in C e in Cobol e i linguaggi di programmazione erano pochissimi: insomma, c’era un mondo in cui esperti e meno esperti erano coinvolti totalmente nei processi lavorativi. L’informatica non era un’isola a parte, ma era immersa nel tessuto produttivo dell’amministrazione. I processi erano governati e governabili e la conoscenza era obbligatoria. Un informatico non poteva permettersi di saperne solo di linguaggi di programmazione, di reti o di sistemi operativi, doveva conoscere bene i tematismi perché altrimenti non avrebbe potuto trovare soluzioni efficaci e di qualità. Insomma, l’informatica era una cosa seria e gli informatici pure. Nonostante oggi sia passato del tempo, e l’offerta di app superi di gran lunga la richiesta, l’informatica, quella seria, continua a essere complessa. Anzi, è diventata molto più complessa rispetto al passato perché deve garantire agli utenti una semplicità di utilizzo elevatissima senza la quale non sarebbe possibile vivere nella società digitale, quella in cui è cambiato tutto, perfino i rapporti umani. Servizi fondamentali per la popolazione come SPID non decollano perché i cittadini li reputano ancora troppo “difficili” da gestire tecnicamente e burocraticamente: arriverà un momento in cui ci sarà un’identità digitale alla portata di tutti, da utilizzare come un bancomat, che richiederà sicuramente un’informatica più complessa e aprirà nuovi scenari nei rapporti tra i cittadini e lo Stato. La PA, però, ha delle esigenze molto diverse dall’utente comune, e purtroppo questo aspetto si è perso completamente di vista. C’è stato un momento, intorno agli inizi del 2000, in cui, per gli informatici,i colleghi delle altre aree produttive sono diventati “i clienti”, come se all’interno ci fosse una società esterna che esterna non era, dividendo l’organizzazione tra “noi” e “loro”. E là è cominciato il tracollo, grazie anche alla complicità delle ingenti risorse economiche affidate alla gestione di manager dalla moralità discutibile. Così, mentre il mondo agiva e reagiva alla rivoluzione culturale introdotta da internet e dal web, la Pubblica Amministrazione subiva le offerte di prodotti e tecnologie cresciute a dismisura e perdeva di vista l’unico patrimonio di cui disponeva: la conoscenza condivisa dei dipendenti pubblici. Perdendo la conoscenza, è venuta meno anche la necessità di selezionare manager e capi progetto tecnicamente preparati, che sapessero indirizzare le attività e le scelte. La conoscenza della sostanza è stata sostituita dalla millantazione della cosiddetta “fuffa digitale” diffusasi rapidamente attraverso l’uso spericolato di tutte quelle parole imposte dalla moda: open data, big data, cloud, microservices, digital transformation, data deluge, geolocalizzazione e così via. Per svuotare una parola da qualsiasi contenuto e privarla del suo significato, non c’è modo migliore che ripeterla, ripeterla e ripeterla a sproposito fin quando le persone non ci facciano più caso. Così, molti informatici, soprattutto i meno esperti e più arrivisti, sono diventati dei parolai inconcludenti, addetti agli acquisti di soluzioni e prodotti, spesso “quasi” utili, che hanno abbandonato il pesante fardello del  “come fare?” e si sono ritrovati a dover rispondere alla madre di tutte le domande esistenziali. No, non è il caso di tirare in ballo Shakespeare e il dubbio amletico “be or not to be” , è più appropriato rievocare la macchietta dell’imprenditore senza scrupoli, che portava il nome di  CarCarlo Pravettoni, e immaginare una sua risposta al quesito  “to make or to buy?”. Quanti sono, oggi, i manager pubblici in grado di valutare l’onere intellettuale ed economico del “to make”? L’orientamento della maggioranza al “to buy” ormai è dilagante, anche se ci sono, per fortuna, delle minoranze eccellenti. Cominciamo col dire che la dirigenza, per rispondere al quesito, dovrebbe avere le idee ben chiare sul significato delle parole “fare” e “acquistare” e sulle ricadute organizzative, economiche e sociali delle scelte.

Per fare è necessario conoscere, e non c’è nessuno che possa conoscere le esigenze e le dinamiche aziendali meglio dei dipendenti che lavorano in quell’organizzazione. Certo, l’IT è un settore che corre: per non restare indietro, bisogna investire nella formazione giusta e nella ricerca, altrimenti si rischia di fare male e di rilasciare soluzioni superate e inadeguate. È necessario avere la situazione sotto controllo, reingegnerizzare le applicazioni, prevedere scalabilità, scenari futuri e, caratteristica ormai impossibile da trovare nella dirigenza pubblica, assumersi delle responsabilità e dei rischi di fallimento. Negli anni ‘90, un capo progetto aveva una fiducia cieca nei suoi collaboratori, che esportavano la cultura informatica all’esterno, oggi prevale la diffidenza rispetto alle conoscenze interne e una fiducia a volte esagerata verso quelle dei fornitori. Così, l’applicazione della logica  “make or buy” non è diventata nemmeno così difficile: buy! Ovviamente, ci sono acquisti da cui è quasi impossibile sottrarsi e acquisti assolutamente inutili. Per produrre in casa il bicchiere citato da Hawking,  bisognerebbe imparare a lavorare il vetro, avere un forno adeguato e procurarsi delle materie prime: sicuramente sarebbe molto più oneroso che acquistarne una dozzina al supermercato. Nell’IT, lasciando da parte le guerre personali a favore dell’open source e del riuso, la questione è più complessa. Se per produrre un sistema operativo servirebbero competenze di altissimo livello e tempi lunghi, che ne renderebbero sconveniente la realizzazione, per rilasciare un applicativo che eroghi un qualsiasi servizio la situazione è completamente diversa: le competenze spesso esistono, ma vengono ignorate e messe da parte a causa (ma sarebbe più appropriato scrivere “per colpa”) delle scelte dei manager dell’IT. Va fatto un doveroso distinguo tra la dirigenza pubblica e privata: il ricorso all’acquisto, nel caso di un’azienda privata, non è mai superficiale, non fosse altro per due evidenze incontestabili: i soldi privati hanno un valore diverso da quelli pubblici e l’obiettivo principale dei privati è il profitto, non certo la remissione. Nella Pubblica Amministrazione, a causa dell’applicazione di un sistema malato che fa ricorso allo spoil system (il contrario del merit system aziendale), le cariche della dirigenza di vertice durano tre anni. Questo significa che un dirigente impiega metà del suo mandato a cercare di capire cosa fare e l’altra metà, supponendo che la prima sia realmente servita a capire, a trovare il sistema per collocarsi dopo la scadenza dell’incarico. Da ciò nasce la necessità di fare meno danni possibile, assumersi il minimo delle responsabilità, ostentare successi, evitare rischi, costruire consensi ed elargire favori, per trovare un altro incarico adeguato che duri altri tre anni. Non c’è senso istituzionale o sensibilità verso l’interesse pubblico, nella questione make or buy, c’è spesso l’interesse personale ai danni della collettività: acquistare un prodotto mette al riparo da qualsiasi contestazione e permette sempre di ripararsi dietro un diplomatico “la soluzione c’è, ma gli altri non sono in grado di farla funzionare”. Il problema è che gli acquisti spericolati e incauti li pagano i cittadini e creano dei buchi neri lasciati qua e là nei conti e nei bilanci per i quali nessuno paga, nessuno rende conto e nessuno è responsabile. Ci sono delle distinzioni da fare, per evitare di trarre l’errata conclusione che il ricorso all’acquisto sia sempre sbagliato. Può diventare sbagliato quando vengono messe da parte le professionalità interne allo scopo di favorire consulenze di basso livello (perché le gare pubbliche vengono fatte sempre al ribasso) per le quali è necessario ricorrere a una formazione consistente, spesso erogata proprio dagli stessi dipendenti esclusi, finalizzata al rilascio di soluzioni non governabili se non attraverso onerosi rinnovi contrattuali. Capita spesso che una società esterna, dopo la scadenza contrattuale, porti con sé le conoscenze acquisite e lasci in eredità dei prodotti ingovernabili. Può diventare sbagliato quando si acquistano prodotti che fanno “quasi” tutto ciò che serve e per essere adeguati richiedono mesi di consulenze extra e pezze messe qua e là nei software. Può diventare sbagliato quando si acquistano prodotti senza conoscerne il reale valore e gli ambiti di utilizzo. Può diventare sbagliato quando si scelgono soluzioni chiuse che complicano il lavoro e non lo semplificano. Può diventare sbagliato quando l’assistenza costa alla comunità cento volte il costo del prodotto. Ed è sbagliato quando il manager, uscito dalla Pubblica Amministrazione, prosegue il suo mandato in una delle società a cui ha erogato favori. Negli altri casi no. Ben vengano le soluzioni innovative, il cloud, le consulenze di alto livello, che fanno crescere il bagaglio culturale collettivo, e la commistione sana e costruttiva tra pubblico e privato finalizzata al benessere della comunità. Attuare correttamente la logica del “make or buy” si può, però bisogna invertire la freccia del tempo e ricominciare dall’istante che ha preceduto la rottura del bicchiere.