Society

#Agile parola d’ordine per la PA digitale

Che per cambiare aiuti essere # appare del tutto ovvio, come enunciare in altro modo il principio di inerzia di Newton. L’inerzia, che misura la riluttanza con cui un corpo sollecitato da un insieme di forze modifica il suo stato di moto, è esattamente l’opposto dell’agilità.

In questo caso il “corpo in moto” è la italiana, che ha una sua inerzia fisiologica derivante da dimensione e complessità di articolazione e tende perciò a conservare il suo stato di “quiete o di moto rettilineo uniforme”. Le forze che la sollecitano sono quelle, ineluttabili, della trasformazione digitale.

A parità di sollecitazione applicata, una maggiore agilità garantisce cambiamenti più incisivi e sistemici, quindi duraturi. Tradotto in termini pratici:

  • Servizi digitali realmente efficaci ed efficienti per il cittadino, a parità di budget impegnato
  • Reale evoluzione delle infrastrutture, come la banda ultralarga e cloud data center “elastici” per il provisiong e de-provisioning automatico di risorse computazionali e storage
  • Pubblicazione di open data, web API, artefatti standardizzati per il design e lo sviluppo del software, servizi abilitanti e facilmente “riusabili” per l’autenticazione, i pagamenti, la gestione di master data anagrafici.

Sono obiettivi largamente condivisi, la discussione è su come arrivarci. Nerd e geek pensano che basti iniettare nella PA più tecnologia. I consulenti ammoniscono che questa non serve senza una riprogettazione (aka, semplificazione) dei processi dell’Amministrazione. I giuristi reclamano il primato di archivistica, diplomatica e informatica giuridica. Altri, in ordine sparso, sottolineano l’importanza dell’apertura dei dati (big, ma direi anche small) e della loro elaborazione analitica per derivare informazioni a supporto delle decisioni. Ultima arrivata, in questi giorni, una task force governativa che studierà come AI e machine learning possano dare supporto ai servizi digitali pubblici. Tutte posizioni condivisibili, anche se ciascuno ha una sua idea delle priorità.

C’è però una traiettoria di azione che non sembra stimolare molto lo storytelling di settore (figurarsi quindi quello generalista…) e che a mio avviso è invece di importanza cruciale per una reale trasformazione digitale del Paese: rendere più #agili i processi di procurement IT della PA e le modalità di erogazione delle attività contrattualizzate.

Ora avete due possibilità. La prima è fidarvi della precedente asserzione e terminare qui la lettura dell’articolo. La seconda, invece, è sorbirvi una panoramica sulla spesa IT della PA e i relativi strumenti e processi di approvvigionamento. In cambio prometto motivazioni a supporto della mia tesi e qualche specifica proposta di “agilizzazione”.

La spesa IT della PA

Quanto spende la PA italiana in IT? Nel 2016 circa 5,5 miliardi di euro (fonte AgID). Parliamo di tutto il comparto pubblico, nessuno escluso, quindi:

  • Pubbliche Amministrazioni Centrali (PAC): come ministeri, enti di previdenza, fiscalità, ACI, Arma dei Carabinieri, dogane, demanio.
  • Pubbliche Amministrazioni Locali (PAL): Regioni, Province, Comunità Montane, Camere di Commercio).
  • Sanità.
  • Scuola, Università e Ricerca.

In particolare, l’analisi di AgID sulla sola PAC fornisce questi dati:

  • Spesa totale PAC nel 2016 => 2.626 ml di euro, pari a poco meno del 50% della spesa totale della PA (aumento del 7% rispetto alla media annua del precedente triennio 2013-2015)
  • Distribuzione della spesa tra le PA => Il 33% delle amministrazioni centrali (7 su 21 esaminate) consumano l’82% della spesa totale
  • Qualificazione della spesa => Il 53% è gestione corrente, il 47% sono investimenti, in aumento del 16% rispetto alla media annua di investimenti del triennio precedente
  • Tipologia di spesa => il 55% della spesa è relativa alle infrastrutture fisiche (data center, cloud, networking, connettività)
  • Progetti IT => 451 progetti IT pluriennali in corso o in fase di avviamento. Di questi, 309 (pari al 69%) “cubano” il 79% della spesa e sono allineati al Modello Strategico individuato nel Piano Triennale per l’Informatica nella Pubblica Amministrazione.

Chi volesse maggiori dettagli, incluse le distribuzioni dei dati di spesa ICT delle singole Amministrazioni Centrali, può consultare l’efficace quadro sinottico pubblicato come appendice al Piano Triennale per l’Informatica nella PA 2017-19.

“In sintesi, per le Amministrazioni Centrali la spesa IT complessiva è pressoché costante da 4 anni a questa parte (intorno ai 2,5 miliardi annui) e concentrata prevalentemente su pochi big spender (un terzo del totale). Poco più della metà di questa spesa (55%) è dedicata alle infrastrutture fisiche. A parità di spesa si nota un aumento della componente di investimento, probabilmente per effetto di ammodernamenti infrastrutturali non più rinviabili. La maggior parte dei 450 progetti IT in corso è coerente con la strategia ICT di AgID e del Team Digitale.”

Bene. Quali risultati contribuisce a determinare questa spesa? Nel 2017 l’Italia risulta ancora in netto ritardo in termini di sviluppo digitale. Lo dice la Commissione Europea, attraverso il DESI (Digital Economy and Society Index). L’Italia è al 25esimo posto su 28 paesi membri della EU, calcisticamente parlando in piena “zona retrocessione”, anche se va precisato che l’indice DESI misura le performance dell’intero sistema paese e non della sola PA.

Sul versante pubblico, il problema non sembra essere la quantità di servizi online e open data pubblicati (negli ultimi anni le Amministrazioni hanno fatto a gara nel realizzare portali web dove esporli) ma il loro utilizzo. Solo il 16% dei cittadini entra in contatto con la PA tramite piattaforme digitali, meno della metà della media europea. Allora la domanda da porsi è: abbiamo sviluppato i servizi digitali che realmente servivano? E, se la risposta fosse affermativa, quanti di questi sono davvero accessibili e fruibili, ad esempio in mobilità?

Per risalire la classifica dovremmo investire seriamente in infrastrutture fisiche e immateriali, ma soprattutto in progetti efficaci che rilascino valore a cittadini e utenti. Il problema è, come sempre, di risorse. La spending review imposta dalla legge di stabilità 2016 prevede un obiettivo di risparmio della spesa annuale della PA, da raggiungere alla fine del triennio 2016-18, pari al 50% (sic!) della spesa annuale media per la gestione corrente del solo settore informatico. La sola PAC ha quindi un obiettivo di taglio della spesa IT di circa 700 milioni di euro.

Insomma, dobbiamo ottenere molto di più spendendo molto di meno. Obiettivo di efficientamento realisticamente raggiungibile o classico tentativo di “nozze coi fichi secchi”? Proviamo a pensare positivo. La spesa IT della PA deve necessariamente passare attraverso gare di appalto pubbliche, ci sono allora due principali linee di azione da esplorare:

  • razionalizzare il più possibile i processi di spesa IT, analizzando la domanda, aggregandola e accorciando i tempi dei procedimenti di acquisizione e contrattualizzazione
  • aumentare l’efficienza dei progetti IT, producendo più valore, cioè software e sistemi funzionanti realmente utili per cittadini e utenti. Non possiamo più permetterci portali o servizi realizzati senza criteri di massima riduzione di sprechi e ritardi, o peggio ancora inutilizzati.

Razionalizzazione della spesa: #agile

Quali beni e servizi IT servono ad una PA? La narrazione mainstream banalizza parlando solo di portali, siti web e app. Per carità, ci sono anche quelli ma si tratta della parte emersa dell’iceberg. Il grosso sotto il pelo dell’acqua è costituito dalle migliaia di archivi e banche dati, dalle centinaia di applicazioni software in esercizio su N stack tecnologici e altrettante architetture (mainframe – ancora vivo e vegeto -, dipartimentale client-server e web-based), dalla miriade di procedure e sistemi di back-office.

Insomma, da tutto ciò che letteralmente costituisce il “sistema nervoso” di un’Amministrazione, a cui si aggiungono i sistemi (postazioni, server, networking, centri servizi) e le licenze/canoni di specifici prodotti e piattaforme software: applicativi (es. ERP, CMS, BI-BigData, office automation per i dipendenti, etc.), di base (sistemi operativi, database) e middleware (sicurezza, monitoraggio, analytics).

Un universo vasto ed eterogeneo di necessità ed esigenze, prima ancora che di spesa, che deve essere gestito in modo razionale, partendo dalla programmazione dei fabbisogni.

La figura seguente esemplifica il processo di approvvigionamento IT di una PA.

Le durate delle varie fasi sono del tutto indicative e abbracciano una casistica piuttosto ampia, dalle grosse convenzioni nazionali e accordi quadro alle gare per forniture specifiche e verticali. Ora, appare evidente come un processo che, dal manifestarsi di un’esigenza alla stipula del contratto per iniziare a soddisfarla, impieghi come minimo 6-8 mesi non possa essere ripetuto decine di volte per ogni specifica necessità. Per razionalizzare è necessario:

  • aggregare la domanda, ossia raggruppare in forniture di beni e servizi standardizzati esigenze diverse, possibilmente di diverse PA
  • centralizzare la gestione dei procedimenti, affidandola a “Centrali di Committenza” che operino come centri di acquisto per le amministrazioni aggiudicatrici oppure come intermediari, aggiudicando appalti e convenzioni ai quali le amministrazioni aderiscono.

Entrambe queste direttrici di azione sono in atto ormai da qualche anno.

La domanda viene aggregata stipulando convenzioni e contratti quadro pluriennali. In sostanza, meno appalti di dimensioni più grandi (dell’ordine di centinaia di milioni di euro ciascuno). Così, quando una PA ha bisogno di un servizio IT può acquisirlo all’interno dell’accordo quadro, con un fornitore già definito e con regole e tempi di ingaggio certi. Ma soprattutto, cosa non trascurabile, con canoni e costi dei vari servizi (incluse le valorizzazioni delle tariffe professionali) bloccati per l’intera durata dell’accordo (dai 12-18 mesi in su).

La centralizzazione dei procedimenti vede Consip chiamata ad operare come Centrale di Committenza Nazionale, assieme a Centrali di Committenza Regionali, istituite sia per singole amministrazioni regionali che per aggregati di più Regioni rispetto a fabbisogni omogenei.

Tuttavia, agli indubbi vantaggi che aggregazione e centralizzazione portano in termini di economie di scala, la concentrazione delle forniture IT su pochi contratti di grandi dimensioni estromette di fatto dal mercato le PMI, che non hanno i requisiti per partecipare da sole alle grandi gare di appalto. Anche perché la Legge di Stabilità ha ridotto, se non annullato, gli spazi di deroga all’utilizzo di questi contratti. In altre parole, alle PA è oggi sostanzialmente impedito l’approvvigionamento di beni e servizi IT al di fuori dell’accordo quadro di riferimento.

Quindi un mercato ingessato, che avvantaggia solo i grossi player. Come renderlo più #agile?

Una soluzione potrebbe essere l’adozione di un “approccio glocal”, attuando:

  • una programmazione globale, che aggreghi i fabbisogni come adesso, determinando un plafond di spesa nazionale per ogni una specifica tipologia di necessità (es. 500 milioni di euro per servizi applicativi gestionali, siti e portali web per i prossimi 12 mesi)
  • un procurement locale, che lasci alla singola PA facoltà di indire una gara di appalto per una specifica fornitura nell’ambito della tipologia di riferimento. Tale gara sarebbe comunque gestita da una Centrale di Committenza Nazionale o Regionale, ma avrebbe una specificità e un importo tali da consentire la partecipazioni anche a PMI del territorio e il corrispettivo della fornitura, una volta approvata, utilizzerebbe il plafond già stanziato per la tipologia di servizio di riferimento.

Insomma, più gare medio-piccole invece di pochissime gare gigantesche, fermo restando l’aggregazione della domanda e la centralizzazione della committenza. Ovviamente sarebbe da verificare la capacità di Consip e delle altre Centrali di Committenza di gestire un maggior numero di procedimenti. L’articolo 41 del nuovo Codice dei Contratti Pubblici (D.Lgs. 50 del 18/04/2016) contiene indicazioni per creare un sistema di reti di committenza volto a determinare l’effettiva partecipazione delle PMI. Ne verificheremo gli esiti nei prossimi 12–18 mesi.

Quello che però va reso davvero #agile è il processo complessivo, in particolare la fase di aggiudicazione e conseguente stipula del contratto, che è il vero “buco nero” del procurement IT, con dei casi limite come l’ultima convenzione nazionale SPC (Sistema Pubblico di Connettività): appalto in 4 lotti da quasi 2 miliardi di euro a base d’asta, gara indetta nell’autunno del 2014, aggiudicata nel 2016 con ultimo lotto su Open Data e Big Data contrattualizzato nel luglio 2017, dopo quasi 3 anni. Va da sé che qualsiasi proposta tecnica su questi temi, anche la più innovativa e brillante, riletta a distanza di 3 anni risulterebbe obsoleta e superata. Stiamo parlando di contesti dove 6 mesi sono un’era geologica, con architetture, piattaforme e soluzioni che nascono e scompaiono nel giro di poco tempo.

La diffusione dell’e-procurement, cioè della digitalizzazione e dematerializzazione del procedimento di gara, e della collaborazione tra le centrali di committenza migliora le cose ma non risolve il vero problema. Gran parte delle gare, per effetto della dimensione e della relativa posta in palio, vanno in contenzioso, con ricorsi incrociati tra gli offerenti che a volte durano anni. Così, il beneficio di aver sostituito la consegna di un plico cartaceo con l’upload di documenti firmati digitalmente diventa ininfluente.

Fermo restando i doverosi controlli anticorruzione da parte di ANAC, vanno esplorati meccanismi per bloccare l’iter procedurale solo in casi realmente eccezionali e per sveltire le fasi preliminari, come i controlli formali di ammissione degli offerenti e la nomina della commissione giudicatrice. Tanto per fare un esempio, nella gara per il Sistema Agricolo Informativo Nazionale (SIAN), scaduta il 6 dicembre 2016, le sole verifiche formali di ammissione/esclusione e la formazione della commissione di valutazione hanno richiesto quasi 8 mesi (24 luglio 2017).

Aumentare l’efficienza dei progetti: #agile IT Delivery

Dopo aver ragionato su come rendere più #agile la fase di aggiudicazione, passiamo all’ultimo step del processo di approvvigionamento: l’esecuzione della fornitura.

Immaginiamo che questa consista in uno di quei 450 progetti IT pluriennali attualmente in corso o in fase di avviamento nella PA Centrale. Può trattarsi dello sviluppo di nuovi servizi digitali, della migrazione su cloud di tutte le applicazioni web di una PA, della reingegnerizzazione di processi amministrativi accompagnata da gestione documentale e conservazione, o altro ancora.

Fino ad ora, 2017 incluso, nei bandi gestiti da Consip (e, per “imitazione”, anche nella maggior parte delle gare gestite direttamente dalle PA aggiudicatrici) un progetto digitale doveva essere realizzato attenendosi strettamente ad un processo di lavoro strutturato indicato dalla stessa Consip: il cosiddetto Ciclo Completo o una qualche sua variante.

Si tratta di un processo rigido e burocratizzato, che si snoda come una sequenza di fasi di lavoro separate – definizione, analisi, disegno, realizzazione, collaudo… – con decine di documenti di progetto da produrre e tutta una serie di approvazioni formali intermedie. Ma soprattutto è un approccio “predittivo”, tenta cioè di pianificare tutto all’inizio fin nei minimi dettagli. In altre parole, se un’applicazione software è costituita, poniamo, da 100 funzionalità, prima di cominciare a svilupparne e rilasciarne anche solo una agli utenti è obbligatorio averle definite in dettaglio, stimate, “scolpite nella pietra” e approvate formalmente tutte e 100.

Noi informatici chiamiamo questo modo di lavorare waterfall (cascata). E’ così che costruireste anche un ponte. Però un ponte è un oggetto materiale, fatto per durare centinaia di anni, non evolve nel tempo e i suoi requisiti, una volta definiti, non cambiano. Non perché tecnicamente non si potrebbe, ma perchè sarebbe troppo costoso farlo. Una volta che avete gettato le fondazioni per i piloni non potete dire “ops, mi sono sbagliato, mi conviene metterli 200 mt più in là”. Buttereste via centinaia di giornate di lavoro di decine di operai e centinaia di migliaia di euro in materie prime (calcestruzzo, acciaio) e utilizzo di macchinari di movimento terra, ruspe, betoniere e quant’altro.

Il software di trenta o quaranta anni fa, in parte ancora in esercizio come i vecchi programmi COBOL che girano sui mainframe di ministeri ed enti previdenziali, è un po’ come il ponte. Costruito per durare su ambienti tecnologici chiusi e costosi. Per quel tipo di software il waterfall va benissimo.

I moderni servizi digitali, però, sono tutt’altra cosa. Sono caratterizzati da maggiore complessità e stratificazione di architetture e ambienti tecnologici. Da un time to market sempre più ridotto, con tempi di progetto che da anni o mesi, come era solo pochi anni fa, sono oggi dell’ordine delle settimane quando non dei giorni. Da una maggiore velocità di cambiamento, una minore quantità iniziale di informazioni e un cono di incertezza allargato.

Nel mondo reale, su 100 funzionalità software rilasciate, 50 sono quelle individuate all’inizio, le altre 50 si scoprono in corso d’opera parlando con gli utenti, provando, anche fallendo e operando in maniera “adattiva” piuttosto che “predittiva”.

Per questo, da 20 anni a questa parte il software non si realizza come un ponte o una metropolitana, ma con metodi e tecniche #agili, che in estrema sintesi operano così:

  1. costruiamo una prima versione del servizio digitale che soddisfi i requisiti generali e più importanti degli utenti (il cosiddetto minimum viable product, MVP)
  2. mostriamo il risultato agli utenti e raccogliamo feedback, migliorando il prodotto (incrementalità).
  3. ripetiamo il processo fino alla soddisfazione di tutte le reali e necessarie esigenze degli utenti (iteratività).

Che l’approccio #agile nei progetti IT funzioni meglio del waterfall tutt’ora prescritto da Consip lo mostrano i numeri. Ogni anno, dal 1994 Standish Group pubblica il CHAOS Report sullo stato dell’industria di sviluppo software. Il report del 2015, basato sui dati di 10.000 progetti software in tutto il mondo mostra che la percentuale di successo sale nettamente adottando metodi e cicli di lavoro #agili. Per capirci, un progetto ha “successo” quando viene completato nei tempi, stando nel budget e con soddisfazione degli utenti rispetto al prodotto/servizio realizzato.

Fonte CHAOS Report 2015 – The Standish Group

Ora, lo so che sembra tautologico ma se la nostra PA spende soldi pubblici per intraprendere un progetto IT, deve farlo per realizzare del software funzionante con certe caratteristiche da rilasciare quanto prima in esercizio. E’ quello il business value prodotto, il ritorno di investimento che otteniamo, non le decine di documenti formali richiesti da un ciclo di lavoro sequenziale e burocratizzato. Per ottenere di più spendendo di meno dobbiamo aumentare il controvalore in euro della quota di software realizzato.

“In pratica, 100 euro di spesa pubblica IT non debbono più tradursi in 20 euro di software e 80 euro di documentazione formale e contabilità di progetto. La proporzione deve essere completamente ribaltata e gli approcci #agili sono lo strumento principale per farlo.”

Nel Capitolo 13 del Piano Triennale per l’Informatica nella PA 2017-19 si affaccia finalmente sul palcoscenico della PA italiana la parola #agile e si dice che i nuovi servizi digitali dovranno essere realizzati privilegiando le reali esigenze degli utenti e costruendo il risultato in maniera incrementale. Il problema è che anche la contrattualistica dovrebbe essere adeguata di conseguenza, perché se il software viene rilasciato prima e in modo progressivo, invece che tutto insieme alla fine, allora anche la fatturazione dovrebbe seguire regole analoghe.

Auspico fortemente che già dalla prossima revisione del Piano Triennale (in teoria prevista con cadenza annuale) AgID e il Team Digitale provino a gettare il cuore oltre l’ostacolo. Come il governo britannico, che negli anni ha condotto un lavoro poderoso di digitalizzazione del settore pubblico pubblicando strumenti, regole, tecniche e procedure sul portale https://www.gov.uk

Nel nostro Piano Triennale “…si raccomanda alla PA di definire un prodotto minimo (MVP) utilizzabile dagli utenti e i passi incrementali e successivi fino al completamento dei lavori, possibilmente usando le metodologie #agili…”. Questo è solo un suggerimento.

Sul portale governativo britannico, nella pagina introduttiva alla Governance #Agile dei Servizi Digitali si dice semplicemente “You must use the agile approach to build and run government digital services”. Questa invece è una prescrizione senza se e senza ma.

In luogo di una conclusione

Se avete avuto la pazienza di arrivare sin qui, meritate un riepilogo dei temi toccati, delle proposte di agilizzazione e del relativo stato dell’arte.

Gli obiettivi governativi di risparmio sul comparto IT della PA e la contemporanea necessità di recuperare il digital debt del Sistema Paese obbligano ad aumentare l’efficienza della spesa per riuscire a fare di più, con meno risorse ma soprattutto più rapidamente, considerando che l’IT è un prodotto ad alta deperibilità. Questo significa:

  • aggregare la domanda e centralizzare la committenza per razionalizzare la spesa (lo si è già fatto e lo si sta facendo)
  • rendere #agile la contrattualizzazione delle forniture IT evitando l’eccessiva concentrazione su pochissime gare di enormi dimensioni, per favorire la partecipazione di PMI innovative e capaci (non lo si è fatto sinora e non lo si sta facendo adesso, si dice di volerlo fare in futuro).
  • realizzare solo i servizi digitali che realmente servono ai cittadini partendo dalle loro reali esigenze (non lo si è fatto sinora, forse si sta cominciando a farlo adesso, si dice di volerlo sicuramente fare in futuro)
  • diffondere l’e-procurement e la collaborazione tra centrali di committenza per velocizzare il processo di gara (lo si è già fatto sinora e lo si sta facendo adesso)
  • rendere #agile la fase di aggiudicazione degli appalti, abbassando da 6-8 mesi a poche setttimane i tempi necessari per i controlli di ammissione formale e la formazione delle commissioni di valutazione (non lo si è fatto sinora e non lo si sta facendo adesso, non è chiaro se lo si voglia fare in futuro)
  • rendere #agile la fase di aggiudicazione degli appalti disinnescando ove possibile ricorsi e contenziosi e bloccando l’iter di gara solo in casi realmente eccezionali (non lo si è fatto sinora, non è chiaro se lo si stia facendo adesso e se lo si voglia fare in futuro)
  • rendere #agili i processi realizzativi dei progetti IT, diminuendo la burocrazia e privilegiando il rilascio di software funzionante a quello di documentazione formale e omnicomprensiva (non lo si è fatto sinora e non lo si sta facendo adesso, si dice di volerlo sicuramente fare in futuro).

In definitiva, riallacciandoci a Newton, tanto più si è #agili, quanto più si riesce a cambiare e progredire a parità di sforzo. E se vale per tutte le entità del nostro universo fisico, allora deve valere anche per la nostra PA.

Marco Caressa

Marco Caressa

Ingegnere nucleare ceduto a titolo definitivo all’informatica. 25 anni di coding, progettazione, ricerca e management ICT in Engineering Ingegneria Informatica. Attualmente si occupa di ingegneria dell’offerta, attraverso la proposizione di soluzioni architetturali e tecnologiche innovative sulle diverse aree di mercato. PMP®, PMI-ACP®, appassionato di Project Management tradizionale e “agile”. Blogger, trainer, mentor e coach per la preparazione alla certificazione PMP. È intervenuto in diversi eventi formativi e webinar di settore per la Scuola di IT & Management di Engineering, per il Project Management Institute e per la LUISS University.

Twitter 

Clicca per commentare

Commenti e reazioni su:

Loading Facebook Comments ...

Lascia una replica

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

No Trackbacks.

Inizio
Share This