För att förebygga misstag
Det finns en populär tradition som Shigeo Shingo har gett oss, som säger att det ursprungliga namnet för att förebygga misstag (Poka-Yoke) var ”fool-proofing” (Baka-Yoke). Shingo kritiserade cheferna på Panasonic för att de använde den sistnämnda termen, eftersom den var respektlös mot arbetarna och i princip kallade dem för idioter. Shingo bytte ut ordet ”misstag” mot ”idiot”, eftersom det är en del av mänskligheten att göra misstag, som han så träffande påpekade. ”Misstag är oundvikliga”, sade han, ”men de defekter som uppstår på grund av dem är inte oundvikliga.”
Trots Shingos förmaningar hör jag dock fortfarande termen ”fool-proofing” användas regelbundet, och ibland med lite mer giftighet, ”idiot-proofing”. Utan tvekan har dessa nedsättande termer, tillsammans med andra som ”screw-up” och dess mindre vänliga derivat, gett ett dåligt rykte åt ett av de mest energigivande, stärkande och kreativa verktygen i TPS-verktygslådan. Många organisationer kommer inte ens ut ur blocken med denna teknik på grund av en öppet förolämpande, skuldbeläggande miljö. Vem vill rapportera ett misstag när belöningen är skuldbeläggning och förlöjligande? Precis som Mr T tenderar chefer att säga fel ord när misstag inträffar. Dåliga vanor dör hårt.
Men även för mer upplysta chefer finns det fortfarande några vanliga hinder för att skapa ett riktigt kraftfullt Poka-Yoke-system. För några veckor sedan höll jag ett kort webbseminarium för AME om Poka-Yoke och fick den här frågan av en tittare:
”Hur säkerställer jag att Poka-Yoke-enheten används effektivt? Folk brukar inte vilja fortsätta att använda den.”
Här, med några utsmyckningar, var mitt svar:
”Det allmänna svaret på denna fråga från dagens webbseminarium är att om folk inte tycker att ett visst verktyg är ändamålsenligt så använder de det inte. Mer specifikt för poka-yoke finns det sju anledningar till att verktyget inte ses som ändamålsenligt av teammedlemmarna:
- För att säkra kvaliteten läggs ibland ett ytterligare steg till i verksamheten för att förhindra eller upptäcka felet, men detta steg beaktas inte i det standardiserade arbetet, dvs. ingen ytterligare tid tillåts. Om anordningen eller metoden kräver ett extra steg som tar mer tid (t.ex. användning av en checklista eller att matcha delar mot en mall) kommer de anställda att känna sig pressade och pressade att välja mellan hastighet och kvalitet.
- En följd av bristen på standardiserat arbete är bristen på kommunikation till lagmedlemmar, lagledare och chefer. En odokumenterad och otränad standard är ingen standard.
- Om anordningen eller metoden orsakar påfrestningar för den anställde kommer den inte att hålla i längden. Att ersätta Muri med Muda är ingen bra kompromiss.
- För anordningar av typen ”detect-type poka-yoke” (dvs. en defekt skapas, men upptäcks innan den kan övergå till nästa operation) innebär konceptet att man svärmar in defekten när den är fångad för att förstå dess grundorsak. Jag ser många fall där defekter fångas upp, men där det inte sker någon uppföljning. Defekterna hopar sig, eller så plockas de upp ibland av teknik eller kvalitet, men ingen återkoppling går tillbaka till produktionslinjen. När problem inte åtgärdas främjar detta cynism. Det är inte poka-yoke, bara en skrotsorterare.
- Ibland, som antyds i frågan ovan, sätts en anordning på plats, men felet kvarstår. Det kan betyda att enheten inte används av lagmedlemmen, men det kan också betyda att enheten helt enkelt inte fungerar. Det behövs mer PCDA. Om anordningen inte fungerar kommer gruppmedlemmarna att vara de första som får veta det. Att säga åt dem att använda något som inte fungerar är respektlöst och oengagerande.
- Tecknet Poka-Yoke används för brett för att beskriva motåtgärder som inte har något att göra med mänskliga fel, utan som snarare handlar om att ge lagmedlemmarna rätt verktyg och fixturer. Om ett visst arbete till exempel kräver supermänsklig sensorkapacitet för att slutföras (mer Muri), är det inte en Poka-Yoke-lösning att skapa fixturer för att göra arbetet genomförbart. Min far, som var maskinist av yrke och konstnär av fritidsintresse, kunde rita en rak linje på fri hand runt ett helt rum. De flesta av oss andra skulle vilja ha en raksträcka och ett vattenpass för att utföra den uppgiften. Poängen är att när vi hänvisar till sådana motåtgärder som ”felskydd”, så visar vi återigen bristande respekt för lagmedlemmarna.
- Det viktigaste är att om den anställde som använder enheten inte är inkluderad i lösningen finns det vanligtvis ett litet engagemang för att använda den, särskilt om någon av punkterna 1 till 6 gäller.
Det är det långsökta svaret på den korta frågan. Det korta svaret på frågan är att den ”tekniska” delen av poka-yoke inte fungerar om den inte är förankrad i en kvalitetskultur.”
Kanske kan du komma på några andra vanliga misstag för att skydda mot misstag som du kan dela med dig av till våra läsare. Låt mig höra av dig.
O.L.D.
Förresten, för några år sedan gjorde GBMP en Lean-utbildnings-DVD om poka-yoke med titeln ”Achieving Zero Defects By Respecting Human Nature” (Uppnå noll fel genom att respektera människans natur). Om du vill veta mer om poka-yoke och hur du kan tillämpa det i din organisation kan du kolla in den här där du kan läsa om den, se ett klipp från videon och köpa den om du vill.