In questo breve articolo si metterà in evidenza come la tecnica Design FMEA sia uno strumento per gestire la CONOSCENZA e prevenire la evaporazione delle competenze nel tempo.
La gestione della conoscenza è quindi un’attività a livello MANAGERIALE necessaria per consentire lo sviluppo della gamma dei prodotti in un contesto in cui AUMENTA LA COMPLESSITÀ delle, ed in cui la delocalizzazione e la mobilità del Personale hanno distribuito geograficamente la CONOSCENZA tecnica.
L’origine storica della Design FMEA (Failure Mode ed Effect Analysis) risale alla necessità di avere un metodo che permetta di analizzare in modo sistematico il rischio e di valutare in modo preventivo le debolezze progettuali che potessero mettere a repentaglio l’affidabilità del prodotto.
In questa ottica la Design FMEA ha avuto un’ampia diffusione in ambito di applicazioni militari ed automobilistiche, cioè laddove la problematica dell’affidabilità e sicurezza erano maggiormente sentite.
Paradossalmente, questa origine strutturata e nobile è stata nel tempo il maggior freno alla diffusione capillare di questo metodo in ambiti diversi da quelli di origine, in quanto si è diffusa la consapevolezza che la gestione sistematica è una attività che richiede impegno per mantenerla viva ed aggiornata.
Quindi, in tutti quelle applicazioni dove era meno percepita la criticità della affidabilità, si è consolidata l’opinione che, in fondo in fondo, il rapporto costi/benefici della FMEA non fosse così favorevole.
Un ulteriore paradosso lo si è invece riscontrato in quegli ambiti in cui l’utilizzo della Design FMEA era reso obbligatorio dai requisiti contrattuali. In questi casi la design FMEA ha spesso assunto la connotazione di un documento burocratico da presentare al Cliente e che, nella peggiore delle accezioni, non doveva neppure essere troppo esaustivo per evitare la diffusione del know-how e delle debolezze del prodotto al Cliente.
Può sembrare strano, ma fintanto che le soluzioni tecnologiche hanno mantenuto una bassa integrazione tra i sistemi e un livello basso di innovazione, l’analisi dei rischi era sostanzialmente statica e consolidata nelle esperienze personali di pochi tecnici… quindi la sua formalizzazione è apparsa sostanzialmente inutile.
Come sempre però le cose cambiano e sono intervenuti due fattori di cambiamento:
L’integrazione tecnologia
Delocalizzazione dei processi
Effetto della Integrazione Tecnologica sulla gestione della Conoscenza
Il primo passaggio è avvenuto quando le soluzioni tecniche hanno integrato nel tempo più tecnologie (ad oggi parlare di meccanica e di elettronica in una vettura non ha senso, ma tutti i sistemi sono meccatronici), quindi la conoscenza specialistica dei singoli non riusciva più a comprendere tutto il campo di applicazione.
Il rischio del prodottosi nasconde quindi nelle interfacce tra le tecnologie.
Il secondo passaggio si è verificato quando all’interno di un prodotto i diversi sottosistemi hanno incominciato ad interagire e comunicare continuamente, quindi l’esperienza specialistica di INTERE Aziende capaci di progettare e produrre sotto sistemi, non è stata più in grado di garantire la funzionalità complessiva del prodotto.
In altre parole la perdita, di affidabilità di un sistema NON si può più valutare come il rischio dovuto ad un singolo sottosistema, è l’interazione di più sistemi che genera nuovi rischi.
Il rischio si nasconde quindi nelle interfacce tra i sistemi.
Nel presente, non nel prossimo futuro, prodotti di nature diverse ed i produttori diversi si parlano tra di loro e si parleranno sempre di più (avreste mai pensato che la cappa aspirante della vostra cucina può capire che state bruciando l’arrosto e quindi segnala alla piastra ad induzione di ridurre il calore?).
Quindi non sarà più neppure sufficiente conoscere a fondo il proprio prodotto per saperne valutare i rischi, ma sarà necessario conoscere come esso può interagire con prodotti completamente differenti.
Si aggiunge inoltre un’ulteriore complessità: il ciclo di vita del prodotto non può più essere considerato come gestibile su un singolo prodotto, ma sarà l’interazione dei prodotti, e l’entrare nel sistema di sempre nuovi prodotti, che potrà innescare rischi che, inizialmente non erano neppure prevedibili.
Il rischio si nasconde quindi nelle interfacce tra i prodotti.
Effetto della delocalizzazione sulla gestione della Conoscenza
La globalizzazione ha portato nel tempo anche alla necessità di delocalizzare la conoscenza.
Inizialmente la globalizzazione è nata per trarre il vantaggio economico di produrre in aree in cui il costo era più basso, mantenendo lo sviluppo dei prodotti negli Head Quarters.
Poco dopo è stato inevitabilmente necessario cominciare a trasmettere conoscenza anche verso la periferia delle organizzazioni.
Da quel momento la conoscenza non era più concentrata in un unico punto, ma sono nate forze centrifughe di differenziazione della conoscenza.
Alla periferia sono nati veri e propri centri competenza.
La conoscenza tecnica necessita ora di una vera e propria gestione tra i centri.
Le crisi economiche dei vari settori hanno inoltre generato veri e propri movimenti migratori di tecnici.
Da un lato, questa migrazione ha generato sicuramente un beneficio di contaminazione tecnologica nei settori che hanno ricevuto conoscenza, ma dall’altro ha impoverito altri settori.
È quindi necessario che i settori sia i donatori che i riceventi di questa contaminazione debbano gestire il ricambio di conoscenza.
In estrema sintesi assistiamo a due fenomeni che convergono verso un unico effetto:
La conoscenza tecnica si modifica e si deve modificare ogni giorno sia per la spinta della complessità del prodotto, sia per la spinta del cambiamento del mercato della conoscenza.
Dobbiamo quindi maturare la consapevolezza che la conoscenza in azienda non è statica ma è un continuo flusso, dobbiamo sapere che dovremo integrare nuove conoscenze e che dovremo sostituire conoscenze entranti con conoscenze uscenti.
Ora dobbiamo definire un modo per mantenere e far crescere il prodotto con una risorsa (conoscenza) che è in continuo movimento, quindi
dobbiamo mantenere il focus sul prodotto e formalizzare quali sono le sue caratteristiche più distintive e critiche e su come possiamo perdere il controllo di queste caratteristiche.
Prima di tutto bisogna liberarsi del pregiudizio secondo cui una criticità sia un elemento negativo di rischio, è semplicemente una caratteristica che dobbiamo mantenere sotto controllo:
Se costituisce un elemento competitivo, dobbiamo tenere sotto controllo il rischio di perderla involontariamente
Se costituisce un fattore di rischio dobbiamo tenere sotto controllo la probabilità di introdurlo involontariamente
La Design FMEA per sua natura richiede:
Identificare le caratteristiche (funzioni) – richiede conoscenza
Identificare come le funzione possano essere perse (failure mode= debolezze del prodotto) – richiede conoscenza
Identificare le cause – richiede conoscenza
Valutare gli effetti- richiede conoscenza
In sintesi, la Design FMEA è lo strumento più adatto per svolgere questa funzione di monitoraggio costante delle criticità e delle conoscenze necessarie per permettere che il prodotto si mantenga e si sviluppi.
La Design FMEA si è quindi evoluta da strumento per gestire l’affidabilità del prodotto, a strumento per garantire la funzionalità del prodotto quindi per sviluppare nuovi prodotti, a strumento per garantire lo sviluppo di nuovi concept e quindi per garantire la sopravvivenza dell’Azienda.
Questa crescita continua dell’impatto gestione della conoscenza comporta che essa sia diventata un fattore strategico.
In quanto fattore strategico di sopravvivenza dell’azienda stessa, non può più essere uno strumento operativo in mano a tecnici, ma diventa uno strumento che deve essere patrimonio del Top Management. Solo ora ci si rende conto che il Managment Commitment (sempre richiesto, ma scarsamente ottenuto) non è più sufficiente; cioè non si tratta più di un supporto esterno, ma ci deve essere la partecipazione attiva del management.
Quindi non si tratta più di mettere a disposizione le risorse per la DESIGN FMEA, ma il Top Management deve gestire la conoscenza tecnica tramite una struttura organizzativa centrata sulla DESIGN FMEA.