Premessa

L’ultimo paragrafo del commento al “Report IT 2014” auspicava “un nuovo stile per la realizzazione dei piani strategici e operativi”¹. Si diceva che la distinzione tra piani strategici e piani operativi è capziosa; il disegno della strategia deve tener conto dei piani di realizzazione: considerare i processi gestionali in atto, individuare e sfruttare le sinergie tra azioni risolutive, definire le priorità tra gli obiettivi (considerati i vincoli), definire protocolli per disciplinare le collaborazioni esterne. Si lanciava l’idea di creare profonda “cultura d’impresa”, per gestire con accortezza i cambiamenti(senza cedere inconsapevolmente alle mode commerciali). Si auspicava l’utilizzazione di competenze di auditing effettivamente qualificate, per la (ri-)progettazione e/o la verifica dei processi (soltanto il test certificato delle procedure informatiche implicate nei processi gestionali garantisce, se verificata la qualità dei dati in input, la “data quality” dei risultati). Sono temi ripresi e discussi (col riferimento all’informatica della pubblica amministrazione) nel seminario sull’“IT vendor management”, in occasione della presentazione del quaderno di ricerca numero 7 (dell’Inail)²; aggiungono potenzialità operative alla “riforma delle stazioni appaltanti”³. Tre brevi considerazioni su quella discussione possono tornare utili, anche come note in margine a questo Report IT 2015.

1. Le priorità

Nel seminario è stato detto che anche l’informatica è inquinata di modernismo: si guarda al guscio (portale, cruscotti, meglio se giustificati con slogan anglofoni), si tiene in secondo piano il processo digestione e di lettura dei dati e delle informazioni (architetture di database,modalità di acquisizione, “data quality”, flussi di elaborazione, garanzia di efficienza computazionale, verifica dei risultati, schemi di analisi). Le Istituzioni esibiscono attenzioni per garantire collegamenti via APP con tablet e smartphone, ma si trovano a gestire procedure (essenziali per la gestione) scritte in linguaggi d’altra epoca, oramai assolutamente inefficienti,non documentate, con difficoltà e costi di manutenzione elevatissimi;e spesso a utilizzare, per processi fondamentali, soluzioni di nessunagaranzia, realizzate con fogli elettronici (esposti a errori giudicati ancora recentemente “extremely difficult to detect and correct” ⁴). Si ha l’impressione di voler (dover?) viaggiare su un’automobile con carrozzeria di fuoriserie e motore di vecchia utilitaria, un po’ singhiozzante e inquinante. D’altra parte i motori di elaborazione inefficienti trasmettono inefficienza(temporale e sostanziale) alle “interrogazioni” dei sistemi informatici,anche se il collegamento è realizzato con le migliori tecnologie. Perciò è importante pianificare con la massima accortezza le priorità di azione, privilegiando la sostanza gestionale rispetto alle mode del cosiddetto “social”. (La sostanza va protetta anche nella fase di proposta degli schemi di analisi, vietando le sciatterie dell’info-grafica commerciale.)

2. Quale piano

Sul “come fare i piani”, conviene riprendere un lontano suggerimento di Massimo Severo Giannini (erano gli anni ’50 del secolo scorso): l’impianto informatico deve essere pensato (e realizzato) “come un unico apparato anziché come un complesso”⁵. E’ diffusa la condizione che si abbia a che fare con impianti che hanno forma di “complesso”:sono stati costruiti (nel tempo) “a mosaico” e “in verticale” (con la logica dei silos), per risolvere singoli problemi in singoli contesti; rendono ardui collegamenti trasversali diventati (nel tempo) sempre più necessari per soddisfare le esigenze di una gestione (amministrativa, tecnica, strategica) a componenti sempre più interdipendenti. E’ importante convincersi che non è possibile (né conveniente) evolvere progressivamente dal “complesso” all’“apparato”. Se si vuole costruire un sistema informatico efficiente c’è bisogno di un cambiamento strutturale della logica del piano. E’ necessario tamponare l’impianto (complesso) in-essere; e progettare ex-novo il nuovo apparato. Richiede – per la pianificazione e la realizzazione – professionalità di alto livello, completamente dedicate: per ri-analizzare i processi amministrativi, per ri-disegnare innanzi tutto l’architettura dei dati, per progettare le procedure informatiche che dei processi siano sostegno. Qui si avverte forte l’esigenza di “nuova cultura”: i dati e i processi vanno organizzati analizzando con le categorie informatiche le procedure amministrative e le esigenze di contesto. E’ alibi ingenuo (e pericolosamente diffuso, anche nell’Inail) pensare che sia sufficiente riunire in un “gruppo di lavoro” competenze singole: c’è bisogno di formare una competenza nuova (prodotto di “contaminazione culturale”), di un’unica mente (esperta del problema e delle tecniche di analisi e di soluzione) capace di pensare “in sintesi”. In questo senso, e in questa situazione, la formazione diventa componente essenziale del piano. (Della formazione strumentale ai progetti – fondata sul “fare e formare” –, già si disse in margine al Report IT 2014, nella pagina 5.) D’altra parte soltanto così la sinergia tra informatica e organizzazione può diventare efficace. Anche per questo aspetto, suggerimento prezioso ci viene dagli anni ’50⁶: il progetto per la razionalizzazione di un settore di attività non deve essere concepito dai dirigenti come un semplice cambiamento di strumenti (più efficienti) per eseguire le medesime elaborazioni che precedentemente si eseguivano a mano o con mezzi meno progrediti; è necessario invece analizzare le finalità dei lavori usuali, riprogettare i flussi di lavoro considerando le potenzialità delle nuove tecnologie; “uno dei maggiori vantaggi della meccanizzazione è consistito nell’accorgersi che un lavoro che si faceva poteva essere non meccanizzato, ma abolito”. Definito il piano generale si dovrebbe procedere per passi: avviare “un programma minimo suscettibile di pratica realizzazione entro un tempo ragionevole, e di esperimenti parziali entro breve tempo”, e poi procedere alle estensioni e alla sostituzione (per componenti, del vecchio complesso con il nuovo apparato). Gestire secondo le necessità la politica del personale (superare il blocco delle assunzioni) aiuterebbe; per poter costituire (è il seguito del suggerimento prezioso) “organismi nuovi giovani e composti prevalentemente di personale giovanissimo entusiasta immune da spirito burocratico, affiancato da pochi elementi sceltissimi delle vecchie amministrazioni dotati di pari spirito giovanile d’iniziativa”. Comunque già con le dotazioni disponibili – potendo per di più utilizzare collaborazioni esterne – è doveroso e possibile avviare il cambiamento. Tutto si gioca sulla capacità di gestire il piano (fuori dalla retorica delle slides e degli slogan in inglese, che poco dicono sul come fare), di coordinare competenze, consapevoli di dover tutelare l’equilibrio tra “inventors/innovators” e “bureaucrats”⁷.

3. Fare i progetti

Il controllo della qualità dei servizi offerti dai fornitori (di informatica) richiede la definizione di standard, metriche e criteri, con i quali valutare gli esiti delle realizzazioni. E’ un lavoro che condiziona positivamente lo stile di analisi dei problemi, e la ricerca di soluzioni efficaci: in particolare nel non facile trapasso dal “complesso” all’“apparato”. Esemplificare in riferimento al progetto di “revisione della tariffa dei premi” (di cui si tratta a pagina 14 del Report, e vista la rilevanza e l’urgenza dell’impegno per l’Inail) può essere utile esercizio. Per la “revisione” sono da intraprendere otto azioni principali: 1 – documentazione del processo di calcolo in-essere (fasi di elaborazione, input e output di ciascuna fase, pseudo-codice dei nuclei di calcolo, schema di funzionalità); 2 – verifica logica e formale dei nuclei di calcolo, eventuali revisioni; 3 – definizione dei livelli di parametrizzazione (debbono essere parametrici almeno il nomenclatore, le variabili e i coefficienti della funzione di costo); 4 – realizzazione del processo di reperimento, controllo e validazione dei dati di input; 5 – realizzazione del processo di elaborazione; 6 – costruzione di un “bilancio stilizzato” per valutare se la revisione garantisce solvibilità (con la tecnica del what-if dei parametri); 7 – disegno dei cruscotti di comando dei processi e di gestione dei risultati; 8 – documentazione del nuovo processo. Le azioni dovrebbero scandire gli impegni nel capitolato di gara; debbono essere disciplinate dagli standard (su stile della documentazione, linguaggi di programmazione, criteri di controllo e validazione dei dati, funzionalità dei cruscotti). Senza standard ben definiti non è possibile gestire in modo efficace la fornitura e misurarne la qualità. Anche qui (un’analisi preliminare della situazione lo conferma) ci sarebbe urgenza di inserire nel progetto un itinerario parallelo di formazione: che dia nuovo slancio e competenze alla cultura attuariale, per tutelare adeguatezza e efficienza della soluzione.

Massimo De Felice