Fejlsikring af fejl
Der er en populær overlevering fra Shigeo Shingo, der fortæller, at det oprindelige navn for fejlsikring (Poka-Yoke) var “fool-proofing” (Baka-Yoke). Shingo irettesatte lederne hos Panasonic for at bruge sidstnævnte betegnelse, da det var respektløst over for medarbejderne, idet det i bund og grund kaldte dem for fjolser. Shingo erstattede “fjols” med ordet “fejl”, for som han så rammende bemærkede, er det en del af menneskeligheden at begå fejltagelser. “Fejl er uundgåelige”, sagde han, “men det er de fejl, der opstår som følge af dem, ikke.”
Men på trods af Shingos formaninger hører jeg stadig jævnligt udtrykket “fool-proofing”, og lejlighedsvis med lidt mere giftighed, “idiot-proofing”. Der er ingen tvivl om, at disse nedsættende udtryk, sammen med andre som “screw-up” og dets mindre venlige afledninger, har givet et dårligt ry til et af de mest energigivende, styrkende og kreative værktøjer fra TPS-værktøjskassen. Mange organisationer kommer slet ikke ud af blokken med denne teknik på grund af et åbenlyst fornærmende og beskyldningsorienteret miljø. Hvem har lyst til at rapportere en fejl, når belønningen er bebrejdelse og latterliggørelse? Ligesom Mr. T har ledere en tendens til at udbasunere de forkerte ord, når der opstår fejl. Dårlige vaner dør hårdt.
Men selv for de mere oplyste ledere er der stadig nogle almindelige hindringer for at skabe et virkelig effektivt Poka-Yoke-system. For et par uger siden holdt jeg et kort webinar for AME om Poka-Yoke, og blev stillet dette spørgsmål af en seer:
“Hvordan sikrer jeg effektiviteten i brugen af Poka-Yoke-enheden? Folk vil normalt ikke fortsætte med at bruge det.”
Her var mit svar, med nogle få udsmykninger:
“Det generelle svar på dette spørgsmål fra dagens webinar er, at hvis folk ikke finder et bestemt værktøj formålstjenligt, bruger de det ikke. Mere specifikt for poka-yoke er der syv grunde til, at værktøjet ikke opfattes som formålstjenligt af teammedlemmerne:
- For at sikre kvaliteten tilføjes der nogle gange et ekstra trin til operationen for at forhindre eller opdage fejlen, men dette trin tages ikke i betragtning i det standardiserede arbejde, dvs. at der ikke tillades ekstra tid. Hvis enheden eller metoden kræver et ekstra trin, der tager mere tid (f.eks. brug af en tjekliste eller matchning af dele til en skabelon), så vil medarbejderne føle sig pressede og pressede til at vælge mellem hastighed og kvalitet.
- En konsekvens af manglen på standardiseret arbejde er den manglende kommunikation til teammedlemmer, teamledere og ledere. En udokumenteret og uoplært standard er ikke en standard.
- Hvis enheden eller metoden medfører belastning for medarbejderen, vil den ikke holde. At erstatte Muri med Muda er ikke en god afvejning.
- For poka-yoke-enheder af detektionstypen (dvs. en defekt skabes, men opdages, før den kan overgå til næste operation) indebærer konceptet, at man skal sværme om fejlen, når den er fanget, for at forstå dens grundårsag. Jeg ser mange tilfælde, hvor defekter er fanget, men der er ingen opfølgning. Fejlene hober sig op, eller de opfanges lejlighedsvis af teknik eller kvalitet, og der kommer ingen feedback tilbage til produktionslinjen. Når problemerne ikke bliver løst, fremmer det kynismen. Det er ikke poka-yoke, det er bare en skrottriller.
- Sommetider, som antydet i spørgsmålet ovenfor, sættes der en anordning på plads, men fejlen fortsætter. Det kan betyde, at enheden ikke bruges af holdmedlemmet, men det kan også betyde, at enheden bare ikke virker. Der er behov for mere PCDA. Hvis enheden ikke fungerer, vil teammedlemmerne være de første, der får det at vide. At fortælle dem, at de skal bruge noget, der ikke virker, er respektløst og uengagerende.
- Tegningen Poka-Yoke bruges for bredt til at beskrive modforanstaltninger, der ikke har noget at gøre med menneskelige fejl, men som i højere grad handler om at give teammedlemmerne korrekt værktøj og fastgørelsesudstyr. Hvis et bestemt job f.eks. kræver supermenneskelig sensorkapacitet for at blive udført (mere Muri), er det ikke en Poka-Yoke-løsning at skabe udstyr, der gør det muligt at udføre jobbet. Min far, som var maskinarbejder af profession og kunstner af fritidsinteresse, kunne tegne en lige linje i fri hånd rundt om et helt rum. De fleste af os andre ville have brug for et lineal og et vandret mål for at udføre den opgave. Pointen er, at når vi henviser til sådanne modforanstaltninger som “fejlsikring”, er vi endnu en gang respektløst over for holdmedlemmerne.
- Det vigtigste er, at hvis den medarbejder, der bruger enheden, ikke er med i løsningen, er der typisk ikke meget engagement i at bruge den, især hvis nogen af punkterne 1 til 6 er gældende.
Det er det langhårede svar på det korte spørgsmål. Det korte svar på spørgsmålet er, at den “tekniske” del af poka-yoke ikke virker, hvis den ikke er baseret på en kvalitetskultur.”
Måske kan du komme i tanke om nogle andre almindelige fejlsikringer, som du kan dele med vores læsere. Lad mig høre fra dig.
O.L.D.
For øvrigt lavede GBMP for et par år siden en Lean Training DVD om poka-yoke med titlen “Achieving Zero Defects By Respecting Human Nature” (Opnå nul fejl ved at respektere menneskets natur). Hvis du gerne vil vide mere om poka-yoke, og hvordan du kan anvende det i din organisation, kan du tjekke den ud her, hvor du kan læse om den, se et klip fra videoen og købe den, hvis du har lyst.