È peggio fare la cosa corretta erratamente, o la cosa errata correttamente?
Qualche anno fa lavoravo come consulente esterno per un ospedale in Inghilterra e ho avuto una conversazione molto interessante con la caposala di un reparto. Mi raccontò di un nuovo sistema informatico che l'ospedale aveva implementato per gestire gli appuntamenti nel departimento - in questo caso, appuntamenti per donne incinta entro le prime 10 settimane di gravidanza. L'ospedale aveva pagato una compagnia esterna fior fior di quattrini per creare un sistema informatico che li aiutasse a gestire gli appuntamenti e i pazienti. Invece, il sistema ha creato code e reso più lunghi i tempi di attesa.
"Com'è possibile?", chiederai. Ti sento già che dici: "I sistemi informatici sono così semplici e rendono la vita migliore, sono sicura che il problema era che le infermiere non sapevano come usarlo nel modo migliore". Devo essere sincera: anch'io ho pensato la stessa cosa inizialmente ma, avendo imparato a sospendere il mio giudizio e fare domande prima di tutto, ho chiesto altre informazioni sul funzionamento di questo sistema informatico. La risposta mi fa ancora venire gli incubi.
All'inizio, il procedimento per prenotare un appuntamento era il seguente: la donna incinta chiama il suo medico di base; il medico di base le fa qualche domanda e chiede l'indirizzo di residenza - questo per prenotare l'appuntamento nell'ospedale più vicino; poi il medico, che può visualizzare le disponibilità dell'ospedale, procede a prenotare l'appuntamento. Facile come rubare le caramelle ai bambini.
Il nuovo sistema informatico aveva introdotto un'applicazione. "Beh ma non c'è niente di male", dici tu, "anzi le app di solito funzionano meglio se si deve prenotare dal cellulare. E poi in questo modo elimini il passaggio del medico di base: le donne possono prenotare l'appuntamento direttamente con l'ospedale, e il medico di base ha più tempo da dedicare ad altri pazienti. Un classico caso di riduzione dello spreco in classica modalità Lean."
In teoria l'idea dell'app è ottima, ma la sua realizzazione sembra più una punizione dantesca. L'app aveva reso più semplice la prenotazione degli appuntamenti da parte delle donne incinta, ma sai cosa riceveva l'ospedale dall'app? Email. Decine e decine di email, una per ogni prenotazione. Senza nessuna possibilità di filtrarle a seconda della settimana di gravidanza (per esempio, per dare la precedenza alle donne più vicine alla decima settimana) o di mettere in evidenza le donne che avevano bisogno di più accorgimenti o gravidanze ad alto rischio.
Chi aveva creato l'app non si era preoccupata di pensare a come sarebbe stato gestito il flusso delle richieste. Cosa sarebbe cambiato se il reparto avesse semplicemente dato a tutti il proprio indirizzo email? Probabilmente il risultato sarebbe stato molto simile, ma sarebbe costato molto di meno!
Uno dei problemi con questo tipo di approccio verso i sistemi informatici è che il team che lavora sul progetto è organizzato secondo una logica di economie di scala per sfruttare al massimo lo specialista informatico: per esempio dividendo il team in gruppi separati di progettazione, collaudo, implementazione, ecc. Quindi il team di progettazione sviluppa la soluzione per poi passarla al team che effettuerà il collaudo, e così via. Quello di cui invece c'è bisogno è economie di flusso e iterazioni. [1]
"Ma le iterazioni di solito sono incluse nel contratto di appalto per il progetto", mi dirai. Questo è vero, ma è anche vero che i team (che, ripeto, sono divisi in gruppi separati di progettazione, collaudo, implementazione, ecc.) sono vincolati dallo scopo limitato del progetto (quindi progettazione, collaudo, implementazione, ecc.) e sono pagati per portare a termine l'incarico piuttosto che per risolvere un problema. Per risolvere un problema in modo iterativo, i team devono essere in grado di rispondere ai feedback (dati analitici sull'utilizzo della soluzione, sondaggi degli utenti) dati in risposta a versioni precedenti della stessa soluzione. Invece, gli incentivi intrinseci ad un progetto informatico spingono il team a trascurare l'integrità architetturale nel medio-lungo termine a favore dell'implementazione di funzionalità nel breve periodo. [2]
Ma c'è di più: l'approccio tradizionale all'implementazione di soluzioni informatiche vuole che le decisioni più importanti vengano prese da un mix di specialisti informatici e manager - il che riflette una prospettiva di comando e controllo, in cui le decisioni sul flusso di lavoro sono state separate dal lavoro stesso. Si tratta di un'implementazione "push" - ecco il nuovo sistema informatico, ora dobbiamo convincere gli impiegati ad usarlo - quando invece quello che servirebbe è un approccio "pull" - coinvolgere le persone che effettivamente svolgono le attività e che capiscono il "che cosa e il perché" del lavoro e "tirano" a sé le soluzioni informatiche in alcuni punti specifici del flusso di lavoro, sapendo esattamente quale sarà il risultato. In questo approccio, i problemi classici delle implementazioni informatiche (incomprensione e resistenza al cambiamento) semplicemente non esistono. [3]
Quindi, i managers investono migliaia di euro in soluzioni informatiche senza avere nessuna conoscenza dell'impatto che queste soluzioni avranno sul flusso di lavoro, rendendo il lavoro più complicato per l'utente e più costoso per l'organizzazione. [4] Quando invece il modo migliore per introdurre soluzioni informatiche è quello di capire il flusso di lavoro nella sua interezza (studiare il sistema), migliorarlo senza cambiare la tecnologia e, quando il nuovo processo è stabile, "tirare" le soluzioni informatiche necessarie e compatibili con la nuova impostazione del lavoro. Il risultato è un maggiore rendimento con meno costi. [5]
Se avessi 1 ora per risolvere un problema, passerei 55 minuti a pensare alla soluzione (citazione attribuita ad Albert Einstein).
[1] NARAYAN, Sriram, 2018. Products Over Projects. [in data 22 Luglio 2024]. https://martinfowler.com/articles/products-over-projects.html
[2] NARAYAN, Sriram, 2018.
[3] SEDDON, John, 2003. Freedom from Command and Control: a better way to make the work work. Vanguard Consulting Ltd, pp.176-77
[4] SEDDON, 2003. p. 175
[5] SEDDON, John, 2008. Systems Thinking in the Public Sector: The Failure of the Reform Regime.... and a Manifesto for a Better Way. Vanguard Consulting Ltd, p.159