La gestione di un progetto di trasformazione digitale e le modalità di coinvolgimento in questo processo della parte politica oltre agli stakeholder sono i temi emersi nell’ambito della sessione di chiusura dell’Osservatorio sullo Switchoff del Politecnico di Milano.
Diversi gli spunti interessanti emersi dal dibattito, che vorrei elencare e approfondire di seguito.
Partiamo da quelli più importanti, che sono stati evidenziati come i principali dal tavolo di lavoro, unendoli a quelli emersi dalla ricerca scientifica.
Come gestire un progetto di trasformazione digitale?
Gestione e cultura agile
Nel mondo attuale per riuscire a fare trasformazione e cambiamento, in particolare digitali, serve prima di tutto creare una cultura agile. Per cultura agile si intende, semplificando, una cultura che preveda iteratività e incrementalità nella creazione delle soluzioni contrapposta al waterfall (studio tutto, lo faccio fine alla fine e poi metto sul mercato il prodotto): l’agile prevede di creare un prodotto magari con meno funzionalità di quante previste, ma pronte per il mercato (sia esso un vero prodotto, un servizio, altro) e di lanciarlo per avere feedback immediati. Infine, agile prevede un salto culturale enorme: l’errore è una possibilità e dall’errore si impara, non si cerca il capro espiatorio. Questo è un salto cultura enorme per noi italiani, abituati a cercare il colpevole davanti ad un errore: pensare che negli USA i venture capitalist considerano come uno dei parametri fondamentali per finanziare un progetto che il progetto stesso sia guidato da persone che hanno già fallito, perché vuol dire che sanno come si sbaglia.
Misurabilità e prioritizzazione degli obiettivi
In Italia si lavora ancora a quintali, ovvero a ore. La gestione del futuro prevede la creazione di obiettivi che siano:
- per livelli: partiamo con obiettivi più semplici per poi averne di più complessi
- misurabili: un obiettivo deve essere spiegato con chiarezza e misurabile
- prioritiizzati: gli obiettivi più importanti prima, tenendo conto dei concetti di incrementale, iterativo e di semplice prima
- avere degli obiettivi iniziali semplici permette di raggiungere velocemente dei risultati tangibili, procedere nel progetto o nel prodotto e creare fiducia nei lavoranti al progetto. Individuare dei Quick Win, aiuta tutti gli stakeholder a prendere fiducia nel progetto e se ben comunicati, a rendere il progetto un successo da subito.
Formazione e cultura digitale
Per creare cultura agile e di obiettivi, serve sicuramente il buon esempio, ma soprattutto formazione. La formazione deve essere fatta gli interni alla PA, ma i concetti devono essere condivisi anche con gli esterni (gli stakeholder) altrimenti non sarà possibile procedere con “agilità” perché non verrà compreso il metodo di lavoro.
Tra gli stakeholder si includono quindi anche gli amministratori dell’ente, le figure di management, i lavorato singoli, ma anche l’ultimo degli operai perché un altro concetto dell’agile working è quello che le decisioni devono essere prese il più vicino possibile a chi ha la maggiore conoscenza in merito a una materia, e spesso questo vuole dire che sono gli operativi a decidere, non i manager (altro cambiamento culturale enorme).
Strategia di comunicazione
Quando si raggiungono obiettivi, risultati, successi, vanno comunicati e festeggiati. Inoltre ci deve essere una forte sinergia con gli stakeholder, perché il coinvolgimento permette alle informazioni di girare più velocemente, alle soluzioni di diffondersi velocemente, alla partecipazione di diventare più diffusa e alle partnership di consolidarsi. Tanto le cattive notizie girano comunque alla velocità della luce, perché non creare terreno anche per far girare le notizie buone e soprattutto quelle utili?
Interoperabilità e sostenibilità
Sulla scia della comunicazione, che è un interoperabilità relazionale, abbiamo l’interoperabilità applicativa, che mira a permettere alle soluzioni che si creano di corrispondere a determinati livelli di interazione e integrazione con altri sistemi. Nello specifico dei comuni, le soluzioni acquisite o commissionate devono o dovrebbero essere il più possibile interoperabili con le piattaforme abilitanti (Anpr, Spid, Cie, PagoPa, App IO), ma anche in grado di esporre dati (opendata) e di avere api per l’interfacciamento di terzi.
Questo permette di rendere i sistemi sostenibili (ovvero sistemi che nel tempo sopravvivono perchè sono in grado di comunicare con altri sistemi e aprirsi alle evoluzioni).
Come coinvolgere la parte politica nel progetto di trasformazione digitale?
Coinvolgimento e codesign
E’ finita l’epoca dell’autoreferenzialità della PA e dei programmatori. All’inizio erano i programmatori, che senza conoscere la materia, prevedevano di fare la soluzione migliore (sia a livello di logica che di interfaccia) per poi scoprire che l’utente non riusciva ad usare il prodotto. A quel punto il programmatore dava la colpa alla stupidità dell’utente (il famoso utonto) e il prodotto diventava inusabile. Il tutto era esacerbato nella PA, che credeva di poter calare dall’alto la soluzione come la riteneva corretta per i propri processi, a cui il cittadino doveva adattarsi.
Ora siamo nell’epoca del #citizenfirst. Il cittadino/stakeholder/utente finale deve essere parte integrante del processo di creazione di una soluzione (come fatto con IO) e deve essere il giudice finale di un progetto della PA. Se si mira a risolvere un problema del cittadino, perché non coinvolgerlo? Solo dopo vengono i processi interni, che magari a seguito del feedback del cittadino vanno anche rivisti.
Perché digitalizzare un servizio non vuol dire solo informatizzarlo, ma anche reingegnerizzarlo. La differenza è che reingegnerizzare implica informatizzare (Software) ma anche rivedere i processi. Nel 50% dei casi (dice l’osservatorio secondo i dati raccolti) non viene fatta reingegnerizzazione, ma solo informatizzazione di vecchi processi. E’ proprio in questi casi che digitalizzare diventa l’aggiunta di un layer che peggiora la situazione, invece di migliorarla.
Identificare e coinvolgere i fornitori di progetto
Dopo aver coinvolto i cittadini, vanno anche coinvolti i fornitori. Sembra ovvio, ma non così tanto. Il fornitore di progetto (o i fornitori) devono essere parte integrante della cultura (agile), del team di lavoro, facendo sistema in un rapporto di partnership (molto diverso da fornitura) dove la creazione del servizio o del prodotto diventano momenti di opportunità, sperimentazione e scambio di esperienza sia per la PA che per i fornitori. Crescere insieme (PA e fornitori) guardando ai feedback del cittadino è l’unico modo di fare servizi utili per la PA.
Vendere al politico i benefici di breve
Tra gli stakeholder è fondamentale considerare la figure politiche. Spesso si cerca di spiegare al politico i benefici del servizio a livello tecnologico, a volte economico, a volte di territorio. Ma il politico è una figura molto varia: ogni politico ha i suoi obiettivi precisi, che derivano dall’estrazione umana, professionale, personale, politica (appunto), dal momento storico e da tanti altri aspetti. Qui il consiglio è coinvolgere il politico cercando di capire cosa gli interessa e “vendendogli” il prodotto o servizio cercando di capire quali sono i suoi interessi. Gli interessi possono essere i più nobili (il bene del territorio, l’economicità, la volontà di innovare), ma anche altri magari considerati meno nobili (la visibilità ad esempio). Capire questo aiuta a considerare il politico come uno stakeholder da coinvolgere, secondo i suoi parametri, non i propri.
