Innovazione, progettazione e analisi preventiva dei guasti

L’innovazione è un processo soggetto ad un alto tasso di fallimento. Ciò si deve a diversi fattori, sia di ordine sistemico che di carattere metodologico. Fra i motivi di carattere metodologico si può certamente annoverare la scarsa attenzione solitamente dedicata nell’immaginare anticipatamente, e in maniera ragionata, la possibilità che si verifichino guasti e fallimenti.

Ciò è quantomeno curioso alla luce del gran parlare che si fa sul miglioramento continuo. Anche metodologie che sono dichiaratamente orientate al miglioramento e alla generazione di valore per il cliente, come ad esempio Lean, 6Sigma e TQM, hanno poco approfondito, nelle modalità più pratiche ed esecutive, come anticipare i potenziali fallimenti funzionali dei sistemi. In compenso, paradossalmente, sta crescendo l’interesse verso le modalità di crisis management. Ma come, non si è sempre detto che “prevenire è meglio che curare”?

Una possibile spiegazione di ciò sta nel fatto che non è semplice pre-vedere cosa potrebbe accadere, mentre è facile attivarsi sull’accaduto. La gente preferisce occuparsi del tangibile rispetto all’intangibile, sul guasto avvenuto, presente e misurabile, rispetto alla sua potenziale analisi preventiva, anche quando ciò è palesemente controproducente. Infatti analizzare e risolvere (solvere, sciogliere) un problema, prima che si verifichi, è evidente che rende i sistemi più efficaci ed efficienti.

Una fase nella quale è utile svolgere tale analisi è durante la fase intermedia della progettazione. Per progettazione intendo qui quella fase “produttiva” durante la quale si definiscono i dettagli realizzativi di futuri prodotti, processi e servizi, che devono essere pensati nel dettaglio per essere realizzati.

Dal punto di vista più pratico possiamo pensare a guasti e fallimenti di un sistema come a dei “mal-funzionamenti”. Come suggerisce tale termine, un guasto comporta sempre un deterioramento di almeno una funzione utile rilasciata dal sistema, se non il sopraggiungere di una funzione addirittura nociva e indesiderata.

I sistemi esistono per erogare funzioni, cioè “verbi” rilasciati da “qualcosa” verso “qualcos’altro” del quale viene modificato almeno un parametro. La “sedia” sulla quale siete posati rilascia “sostenere” verso il vostro corpo. Se la sedia cedesse sotto il vostro peso si avrebbe un malfunzionamento, cioè una compromissione della funzione utile rilasciata dal sistema sedia.

I sistemi sono composti da sottosistemi (parti di livello inferiore come le gambe, lo schienale o i braccioli della vostra sedia) e interagiscono con sovrasistemi (voi siete sovra sistemici rispetto alla sedia sulla quale siete seduti). Tutto ciò si configura come un insieme di funzioni interrelate che si veicolano all’interno e tra i sistemi.

Quando si progetta è utile adottare tale visione sistemica, perché consente di approfondire e arricchire di significati profondi ciò che si sta ideando e ragionando. Ancora possiamo dire che le funzioni presenti nei sistemi variano nel tempo, dal passato al futuro. La sedia prima di essere usata dovrà anche essere ideata e prodotta, i relativi materiali approvvigionati. Dovrà essere spedita e venduta. A fine vita dovrà essere smaltita. Tra un uso e il successivo potrebbe essere impilata. Pure potrebbe accadere che sia utilizzata per scopi non inizialmente ragionati, ad esempio usandola come scala, oppure per dondolarsi gravando sulle gambe posteriori.

Se applichiamo tali ragionamenti a sistemi ben più complessi di una sedia, a dispositivi e ausili di vario genere, agli impianti, ai processi produttivi o ai servizi, è intuibile quanto sia facile perdere di vista alcuni scenari che possono pregiudicare l’erogazione funzionale inizialmente prevista, o non soddisfare funzionalità richieste ma non previste. Ciò potrà causare insoddisfazione dei fruitori, o malauguratamente, nei casi più gravi, perfino incidenti e richiami di prodotto o sospensione di servizi.

Negli ultimi anni ho perfezionato un mio metodo per condurre in maniera sistematica una fase di “analisi preventiva di guasto”. Tale approccio strutturato consiste in una sorta di re-ingegnerizzazione del sistema, attuato però con l’intento di sabotare il sistema, portandone al fallimento le relative funzionalità e facendo emergere funzionalità potenzialmente sgradite.

L’obiettivo consiste nella generazione di scenari negativi inizialmente non previsti, dai quali ottenere, mediante specifici “operatori”, dei fallimenti funzionali. Partendo poi da questi fallimenti è possibile attuare solving a ritroso e irrobustire il progetto di partenza attraverso la generazione di nuovi e più completi requisiti di progettazione. In tal modo sono inoltre concepibili specifici requisiti critici di funzionalità, che sarà utile presidiare e condividere con ogni attore e sistema coinvolto.

L’adozione di questa prassi consente un irrobustimento generalizzato del progetto e del relativo sistema, dovuto all’anticipazione di alcune eventualità che a posteriori potrebbe costare assai caro non avere considerato. Del resto, come recita la Legge di Murphy, “se ci sono due o più modi di fare una cosa, e uno di questi modi può condurre a una catastrofe, allora qualcuno la farà in quel modo”.

Nel metodo non è previsto solo il potenziale avverarsi di questa legge, ma sono incluse anche specifiche modalità per immaginare cause radice indipendenti dalla volontà delle persone.

La prassi non è alternativa ma complementare ad altre, utili a valutare le probabilità di accadimento e la gravità dei rischi, come ad esempio si fa con le tecniche FMEA o FMECA.

La modalità che ho ideato, essendo un metodo, è trasmissibile, cioè insegnabile. Serve una sola giornata per apprendere il metodo. È comunque consigliabile una successiva attività di mentoring per supportare almeno un primo caso concreto.

Se state realizzando una innovazione o un progetto complesso e che può avere delle criticità, e se volete capire di più su questa prassi di anticipazione e risoluzione dei potenziali guasti, potrebbe essere utile confrontarci per valutarne l’applicazione.