Carlo Del Sante Consulente Qualità e Sicurezza
Metti una sera a cena.
“Scusi, Lei che lavoro fa”?
“Quality Manager”
“Ovvero?”
“Ovvero risolvo dei problemi”.
Da qualche anno oramai rispondo così. Sono stanco di tediare le persone al mio tavolo cercando di spiegare cos’è una verifica ispettiva interna, come si fa un riesame della direzione o perché uno strumento di misura deve essere riferibile a campioni nazionali od internazionali ad incertezza nota. E poi così rendo giustizia alla mia casella di posta elettronica, perennemente intasata da segnalazioni, reclami, lamentele, problemi di persone alle quali non interessa nulla della “descrizione delle interazioni fra i processi aziendali”, ma serve invece risolvere un problema. E alla svelta.
Recentemente ho scoperto che tutto questo si chiama “problem solving” e che farlo bene può fare la differenza fra un professionista bello ma inutile ed uno efficace. Per questo ho deciso di mettere nero su bianco alcune considerazioni che potrebbero essere utili non solo una sera a cena, ma anche un giorno qualsiasi in una azienda qualsiasi.
PREMESSA SULLE DEFINIZIONI
Nel testo che verrà quando parlo di “prodotto” posso intendere un prodotto tout court (tangibile), un servizio, o un insieme di prodotti e servizi. Per lo stesso sillogismo, quando parlo di “azienda” posso intendere indifferentemente senso lato una azienda di produzione o una società di servizi, una azienda privata o una struttura pubblica.
PRIMA DOMANDA: IL PRODOTTO E’ CONFORME O NON E’ CONFORME ALLE SPECIFICHE?
Questa è la prima domanda da porsi di fronte ad un problema. A seconda di come risponderemo a questa prima domanda prenderemo due strade diverse, che forse non si incontreranno più.
STRADA A DESTRA: IL PRODOTTO E’ CONFORME ALLE SPECIFICHE
Eppure non funziona.
O meglio: non funziona come se lo aspettava il cliente.
A questo punto ci troviamo di fronte a 3 possibilità:
- le specifiche non ci sono
- le specifiche ci sono ma non sono state aggiornate (o non sono state distribuite)
- le specifiche ci sono ma non sono adatte alle condizioni d’uso del cliente
Nel primo caso (le specifiche non ci sono) probabilmente è stato cortocircuitato il processo di progettazione, sviluppo, validazione, ingegnerizzazione, produzione, controllo, vendita, consegna, fatturazione per consegnare al cliente un prodotto (o erogare un servizio) senza definirne prima le specifiche. In tal caso, urge una analisi dei processi dell’azienda e delle responsabilità corrispondenti, perché senza specifiche non si può parlare di sistema qualità.
Nel secondo caso (le specifiche ci sono ma non sono state distribuite) può essere utile indagare se effettivamente sia un problema di mancata comunicazione o di metodo, ovvero se vi sia o meno un automatismo per cui una specifica tecnica una volta definita e documentata venga automaticamente trasmessa all’interno ed all’esterno dell’azienda, annullando automaticamente le versioni precedenti. L’errore umano ci può stare, gli automatismi e le procedure servono per prevenirlo. Se no sono inutili appesantimenti formali.
Nel terzo caso (le specifiche ci sono ma non sono adatte alle condizioni d’uso del cliente) vale la pena di chiedersi se la “validazione del progetto”, ovvero quel punto finale di sviluppo di un progetto dove si tirano le somme di ciò che è stato fatto e di ciò non è stato fatto, dei risultati attesi ad inizio progetti e dei risultati ottenuti a fine progetto:
- sia stata fatta,
- sia stata fatta in maniera adeguata, ovvero considerando tutti i parametri in gioco (in particolari quelli relativi alle condizioni d’uso del cliente)
- sia stata fatta in maniera sostanziale o solo formale, giusto per chiudere una attività e passare ad un’altra.
In ogni caso sarà probabile incontrare la risposta: “Ma io il progetto l’ho fatto e andava bene. Deve essere successo qualcosa dopo. Pertanto non è un mio problema”. E’ la stessa logica mentale di chi costruì la diga del Vajont.
Lo stato italiano lo assolse. La storia no.
STRADA A SINISTRA: IL PRODOTTO NON E’ CONFORME ALLE SPECIFICHE
Qui siamo più fortunati: abbiamo a disposizione i diagrammi di Ishikava, i grafici fish-bone, le correlazioni di causa-effetto, la analisi di pareto, il metodo delle 4M ecc. che ci porteranno sicuramente ad individuare la causa del problema.
Che in genere è nel responsabile assente alla riunione, colpevole per definizione finché non prova la sua innocenza.
In realtà le cose non sono mai così semplici.
Spesso le cause si sovrappongono e non sempre è facile individuare la vera causa e intraprendere la vera azione correttiva, quella che taglia la testa al toro e risolve veramente il problema, non lo tampona.
In questi anni ho sviluppato un metodo personale, che ho chiamato RASDA per allinearmi alla dilagante moda degli acronimi made in usa (per quanto Cicerone già 2000 anni avesse disciplinato il metodo dell’eloquenza nella famosa sequenza IDEMA: Inventio-Dispositio-Elocutio-Memoria- Actio), che mi aiuta a risolvere i problemi.
Il metodo RASDA si sintetizza in cinque fasi:
- Raccolta dei dati
- Analisi dei dai
- Sintesi dei dati
- Decisione
- Azione
Raccolta dei dati, perché senza dati non c’è oggettività, senza oggettività non c’è qualità: “ciò che non si misura sono chiacchiere attorno al camino” diceva un antico adagio dei corsi sulla qualità (cui facevo seguito un ironico quanto efficace “il responsabile della qualità non capisce ma misura”).
Analisi dei dati, perché i dati vanno aggregati, stratificati, confrontati, perché se non sono correttamente interpretati rischiano di risultare fuorvianti.
Sintesi dei dati, perché il tempo è sempre poco e troppe informazioni dati disorientano, stancano ed allontanano dal vero obiettivo.
Decisione, perché alla fine qualcuno deve decidere, e non c’è nulla di peggio di un responsabile che non decide.
Azione, perché senza azione non c’è soluzione.
ARRIVO: IL PROBLEMA E’ RISOLTO
Bene, tutti contenti.
Ma siamo poi così sicuri di averlo risolto veramente?
Facendo una analisi a consuntivo delle problematiche rilevate, si tende generalmente ad addossarne la colpa all’esterno: al fornitore che non è adeguato, al rivenditore che non conosce il prodotto, al cliente che non ha capito come utilizzarlo, ecc. ecc. Tutto questo fa dormire sonni tranquilli, ma non sempre è professionalmente e deontologicamente corretto.
Una analisi seria ed oggettiva delle problematiche aziendali sul lungo termine porta spesso a scoprire che solo il 50% nasce da cause esterne, e che tale percentuale scende attorno al 20% nel caso di segnalazioni provenienti dai clienti. Questo dovrebbe sempre farci riflettere su quanto una autocritica seria e profonda da parte di tutti possa servire ad intraprendere azioni correttive efficaci e a migliorare costantemente noi stessi e la azienda per la quale lavoriamo: altrimenti il problem solving, per quanto efficace e sistematico, rischia di restare circoscritto ad eventi puntuali e “reparti incaricati”, senza abbracciare le problematiche aziendali nella loro complessità.
