Nella sua ultima e-lettera, il CEO di LEI, John Shook, descrive tre esempi di visual management, quello buono, quello cattivo e quello pessimo. Qui vi riporto la traduzione di quello buono, per gli altri due vi invito a leggere direttamente in lingua originale:
Rendere visibili entità quali qualità o ritmo di lavoro rende più facile la soluzione dei problemi e il sostenimento nel tempo dei miglioramenti. “Se posso vederlo, posso risolverlo”. L’opposto è altrettanto vero: è difficile risolvere ciò che non si riesce a vedere.
Il primo caso ha coinvolto una giovane donna che faceva il controllo di qualità alla fine di una linea di assemblaggio di componenti elettromeccanici. Per due anni raccoglieva le stesse informazioni riguardanti la qualità. Facendo una serie di controlli, confermava che tutti i connettori erano collegati in maniera corretta, che tutti i componenti sono stati assemblati e in ordine giusto. Man mano che trovava i problemi, li inseriva in un database che poi veniva copiato in un database superiore. Il database veniva riesaminato, analizzato, e i risultati venivano passati in forma di feedback alla produzione ed altri.
Più o meno così:
assemblaggio -> ispezione a fine linea -> inserimento dati -> riesame/analisi -> feedback assemblaggio/progettazione
Non vi era una diretta connessione tra i lavoratori che facevano gli errori e gli ispettori che li trovavano, e l’informazione che veniva condivisa seguiva una lunga e irregolare linea temporale. Il management ha iniziato a guardare questa situazione a causa della percepita “mancanza di motivazione” tra i lavoratori e gli ispettori. Quando hanno iniziato a esplorare i vari modi per aumentare il coinvolgimento e la motivazione dei lavoratori, un ingegnere di qualità ha notato la disconnessione tra i lavoratori e il feedback nella loro prestazione. I problemi che potevano essere risolti immediatamente ci mettevano giorni e anche settimane solo per emergere, e il tempo richiesto per la correzione degli errori era anche più lungo. L’ingegnere voleva risolvere questo problema tecnico.
Ed era la donna che faceva l’ispezione che fece il suggerimento. “E se”, disse lei, “anziché inserire l’informazione sull’errore nel database, non metto tutti gli esempi, nel momento in cui avvengono, su questo tabellone non utilizzato?” Le sembrava facile semplicemente fare una breve nota di ogni problema e metterla sul tabellone, per poi inserirla nel database.
Più o meno così:
assemblaggio -> ispezione a fine linea -> feedback all’assemblaggio -> inserimento dati -> riesame/analisi -> feedback progettazione
Ciò che successe dopo non era pianificato. Il leader della linea produttiva ha iniziato a notare quello che lei stava facendo. Era un pò nervoso, vedendo la prestazione, ossia gli errori, dei suoi lavoratori mostrati in bella vista per tutti. Il prossimo suggerimento era suo. “E se”, disse lui, “io porto qui la mia squadra per dare un’occhiata al tabellone alla fine di ogni giornata, così possiamo sapere come stiamo andando?”
Ciò che successe dopo era interessante. Mentre l’ispettrice e i lavoratori guardavano il tabellone insieme, hanno iniziato a parlarne. Venne fuori che uno dei lavoratori che commetteva molti errori menzionò che aveva da sempre avuto il problema con uno dei connettori. Le due estremità del connettore erano molto piccole, le sue mani grandi, e lo spazio nel quale doveva lavorare era molto stretto. Un problema ricorrente era stato scoperto, la sua causa identificata, e l’ingegnere era felicissimo in quanto sapeva che poteva rendere la situazione più facile con un aggiustamento ingegneristico relativamente semplice. Altri problemi che sono stati portati alla luce erano spesso anche più facili da risolvere, spesso direttamente sul posto.
Cosa è che motiva?
Ciò che successe dopo era ancora più interessante. Man mano che l’ispettrice e i lavoratori si sono conosciuti meglio, anziché aspettare la fine del turno, hanno iniziato a fermarsi accanto al tabellone durante la loro pausa pranzo. Potevano vedere come stavano andando fino a quel momento della giornata. Ancora più importante, stavano soffrendo meno producendo di più e il ruolo dell’ispettrice nel processo è cambiato completamente. Management voleva migliorare la motivazione e l’ha fatto. Ma non in maniera in cui si aspettavano. E’ venuto fuori che ciò che era necessario per migliorare la motivazione tra i lavoratori era un supporto efficace nell’aiutargli ad avere successo e di essere coinvolti nel loro lavoro.
Questo aneddoto mi ricorda uno della mia esperienza. Per rovesciare la piramide in una delle aziende dove lavoravo, sono semplicemente andato dagli operai (ero d’accordo con l’alta direzione…) e gli ho chiesto: “In che modo posso aiutarvi a rendere migliore questo processo?” Le idee non mancarono, lavorammo tutti insieme nella risoluzione dei problemi più ricorrenti, e i risultati erano straordinari: riduzione del lead time dall’ordine del cliente alla consegna che passo da 6 a 2 settimane.
I controlli visuali devono servire per aiutare la risoluzione dei problemi. Se li mettete solo per “abbellire il reparto” e “sembrare lean”, non servono a niente. E gli altri due esempi di John Shook lo mostrano benissimo. E l’articolo finisce con le tre domande da farsi prima di applicare un controllo visuale, come una regola da seguire:
- Quale è lo scopo?
- Per chi è questo indicatore?
- Quanto spesso lo utilizzate e/o rispondete agli indicatori di anormalità: quale è il vostro RITMO DEL PDCA?
Riflettete anche voi riguardo la vostra azienda e i vostri processi. Questo esempio potrebbe esservi molto utile.
