Praktisk problemlösning

Det finns inget viktigare affärsredskap än problemlösning. Trots detta är det ytterst få organisationer som verkligen tar det på allvar. Problemlösning är nyckeln till såväl förbättrade resultat som högre engagement från medarbetarna.

Praktiskt problemlösning är kanske det enskilt viktigaste verktyget vi har till vårt förfogande. För att försöka förklara hur oerhört central det faktiskt är kanske det är intressant att höra att det är det enskilda moment, förutom standardiserat arbetegivetvis, man lägger mest tid och resurser på att utbilda och jobba med inom Toyota. Vi på reLean har hållit i träningar både på Toyota och mot leverantörsbasen så vi vet hur mycket tid man faktiskt lägger på det. Det finns en mängd olika metoder och begrepp inom problemlösning, men vi gillar praktisk problemlösning mest. Inte bara för att det är ger snabba resultat och att Toyota använder det utan också för att det är enkelt, logiskt och kräver egentligen ingen extra struktur i företaget (till skillnad från t.ex. sex sigma). PPS är någotalla ska göra som en del av sitt dagliga arbete och om nu alla ska göra det så behöver vi inga extra strukturer utan varje chef är coach till sina medarbetare.

PDCA

PDCA, Plan Do Check Act, är centralt inom lean och problemlösningstänk. Det genomsyrar all typ av arbete som genomförs. PDCA har fått ett starkt genomslag på grund av sin enkelhet, oavsett om det gäller problemlösning, projektledning eller bara generell planering.

PDCA är grunden för den praktiska problemlösning vi lär ut. Det är även grunden inom projektplanering och generell planering för att uppnö en tidseffektiv process. PDCA lär oss att ta beslut långsamt och implementera snabbt - en oerhört central tanke inom Lean. Det finns inget till att spendera stora medel på att ta beslut till höger och vänster eller vända på steken varje år. Lean är långsiktighet. Då behöver vi fundera på beslut ordentligt, se till att de synkar med vår riktning och att alla intressenter är med på tåget. Sedan tar vi beslut och implementerar väldigt fort och effektivt (eftersom alla är med på tåget). Vi talar mer om beslut och PDCA i våra sidor om ledarskap och beslutsfattande, men nedan kommer vi att fokusera på PDCA ur ett problemlösningsperspektiv.

Vi brukar dela upp problemlösningen i 7 steg (ni kan se dem i bilden ovanför). Ibland kan man även lägga till ett steg 0 där vi förbereder problemlösningen. Låt oss kika lite närmare på hur vi tar oss igenom de olika stegen när vi löser ett problem

Problemlösningsprocessen

Definiera problemet

Det första steget när vi väl börjat vår problemlösning är att definiera vad problemet egentligen är. Vi kan inte göra någonting förrän vi vet detta. Ibland kallas det för gap analysis, vilket inte är helt fel, för det handlar om att hitta ett kvantifierbart gap. Ett kvantifierbart gap kräver i sin tur att det behöver finnas en standard eller mål. Annars har vi inget att jämföra mot. Har vi ingen standard är det första åtgärden från problemlösningen att införa en standard. Många gånger räcker det i sådant fall för att lösa problemet. Vi behöver samla in så mycket information vi kan om problemet i detta steg. Så mycket data det bara går. Desto bättre data desto enklare att kvantifiera problemet. Försök att specificera problemet SMART (Specifikt, Mätbart, Action-orienterat, Realistiskt och Tidbundet).

Intressentanalys

Intressentanalys är ett användbart verktyg oavsett vilken organisation du arbetar i. Genom att strukturerat identifiera intressenter samt definiera vad vi vill få ut av dem, vad de vill få ut av oss och vilken inställning de har till projektet kan vi dra upp riktlinjer för hur vi behöver agera med varje intressent.

Intressentanalysen är central i de flesta förändringssituationer. Genom att göra ett ordentligt jobb från början kommer vi att undvika mycket bekymmer i senare steg av förändringen. Se även vår utbildning i intressentanalys.

Bryt ner problemet

För oss statistiknördar är detta det roligaste steget i problemlösningen. Vi börjar med att leta reda på point of cause - där problemet skapas och händer. Här får vi ställa oss och applicera frågekanonen 5W2H (where, when, what, who, which, how och how much). För er som trodde 5W hade med 5 varför analyser att göra så kommer det lite längre ner. När vi bryter ner problemet frågar vi inga varför. Typiska frågeställningar här är vilket skift? vilken produkt? vilken maskin? vilken medarbetare? vilken dag? när på dagen? vilken temperatur? Hur mycket för sen? vilket typ a problem? var i processen? var i maskinen? var i verksamheten? likadant på alla fabriker? osv. Ibland använder i till och med mer avancerade verktyg (ni kan läsa om den i DMAIC processen) för statistisk analys, men vi tycker man kommer långt med excel och frågebatteriet ovan. När vi väl kommit fram till ett mycket specifikt och SMART problem behöver vi sätta ett lika specifikt och SMART mål för vår problemlösning. Vi gör inte förrän nu, för det är först nu vi vet vad problemet verkligen är. Glöm inte att ett mål måste vara att ta bort containment.

Följ upp och standardisera

Innan vi är klara är det några saker kvar att göra. För det första mäta och följa upp så att våra åtgärder faktiskt stoppar problemet. Vi brukar testa genom att ta bort åtgärden och se om problemet uppstår igen. Viktigt att vi kontrollerar genom att följa både process och KPI. Fungerar det så är sista steget att fundera och standardisera. Först och främst, har alla standarder uppdaterats för att spegla våra förbättringar? När det är gjort frågar vi oss om det finns någon liknande produkt eller process som kan dra nytta av vad vi lärt oss. Kan vi replikera lösningen? Det sista vi gör är att fira vår framgång i teamet och fundera på vilket problem vi ska angripa nu.

För att göra livet lite enklare har vi givetvis lagt till ett par mallar för detta. Ni hittar dem här nedan. Det finns två mallar, en enkel och en avancerad. Den enkla brukar återfinnas i alla bröst- eller bakfickor på Toyota för att snabb plocka fram och strukturera ett problem. Den mer avancerade plockas fram då problemet kräver det.

Identifiera direkta orsaker

Det vanligaste verktyget för att definiera direkta orsaker är ishikawa-diagrammet. Vi använder det för att tänka igenom möjliga orsaker. Ibland gör vi det som en brainstorming övning på plats där problemet händer ibland ber vi någon eller några i gruppen sätta sig och göra ett förslag som vi sedan diskuterar i gruppen. Det viktiga i detta steg är att inte utesluta möjliga orsaker. När vi är nöjda med vår holistiska approach börjar i strukturerar att verifiera varje möjlig direkt orsak med fakta. En direkt orsak är som en volymknapp för oss som inte är förtjusta i hög musik. Vi kan påverka problemet, men inte helt stänga av det. Det är ofta här vi bommar och hoppar till vad vi tror är den rätta lösningen direkt. Om och om igen. Och problemet försvinner inte. Konstigt?! När vi har hittat våra direkta orsaker baserat på fakta går vi vidare till nästa steg.

5 varför analys

Så här brukar vi på reLean lägga upp arbetet med 5 varför. Det är även så här vi utbildade kring 5 varför inom Toyota;

1. Definiera problemet (om det går, ställ dig där problemet inträffar)

2. Identifiera direkta orsaker (Gör en ordentlig ishikawa om det behövs)

3. Ställ frågan varför för varje direkt orsak. Utvärdera varje varför med en ny ishikawa, eller tänk åtminstone att varje varför kan grena ut sig i svar inom Människa, Maskin, Material, Metod (och miljö & management om man ska vara petig)

4. Utvärdera varje alternativ som dök upp i ditt logikträd med fakta (eller sunt förnuft beroende på hur avancerat problemet är)

5. Iterera processen för varje steg djupare du går (5 varför kan vara allt mellan 2 till 15 varför)

6. När du hittar en rotorsak till ditt problem ska du fråga dig om du har hittat den kortsiktiga (tar bort problemet för gott) eller långsiktiga (ser till att liknande problem inte kan hända igen) rotorsaken. Båda behöver identifieras och åtgärdas

Var smarta när ni gör er 5 varför analys och skapa inte hela trädet först utan verifiera fakta i varje steg och stäng inaktuella vägar direkt. "Otränad medarbetare" är inte en godtagbar rotorsak. Aldrig. Det finns alltid några fler varför att fråga på det. Principen för 5 varför är egentligen oerhört enkelt. Vi gör ändå ofta fel. 5 varför handlar om konsten att bryta ner ett symptom till det verkliga problemet. Rotorsaken. Genom att ställa en följd frågor. Låter enkelt i teorin, men det som gör processen lite mer komplicerad är dock att vi behöver verifiera varje steg med fakta. Vi har dock alldeles för bråttom och hoppar snabbt till slutsats istället för att verifiera fakta. När vi 'rättar' problemlösningar som inte gått hela vägen i mål och nått resultat ser vi ofta att man har letat efter "ursäkten" istället för "orsaker" när man gör sitt 5 varför träd. Det klassiska misstaget. Undvik för allt smör i småland att landa i ursäkts-träsket. Ni lägger tid och energi på att bortförklara något men kommer aldrig till en lösning, det blir bara en ny bortförklaring till varför inget hänt sedan den förra.

Några tips

Därför. Testa ditt varför träd med att vänta på trädet och ställa frågan "därför" i andra riktningen.
Ända in i kaklet. Fortsätt tills det inte går att ställa "varför" frågan längre. När svaret som kommer tillbaka är ologiskt så stannar vi.
Hitta båda lösningarna. Det finns alltid både ett kortsiktigt och ett långsiktigt svar på varje ben. Ibland går de ihop, men de finns där.
Strukur. Problemlösning handlar om struktur, se till att du har en strukturerad mall att jobba efter med din 5 varför analys. Vi brukar använda den som är bifogad nedan. 1 för varje direkt orsak.

Utveckla och implementera åtgärder

När vi har våra rotorsaker är det dags att utveckla någon form av lösning till dem. Det finns alltid två lösningar till varje problem. En kortsiktig och en långsiktig lösning. Exempel på kortsiktiga lösningar är en jig eller poka yoke som gör att vi inte kan montera ihop 2 saker fel eller en designändring som gör två komponenter vi lätt plockar fel mellan till samma komponent. De kortsiktiga åtgärderna ser till att problemet inte fortsätter och vi kan ta bort vår containment utan risk till kund. Det långsiktiga åtgärderna, however, är de som ofta pekar tillbaka till våra sourcing, design och produktutvecklingsprocesser. Eller till vår ledningsmetodik. Här behöver vi stärka våra processer och metoder så att vi inte tillåter att någon annan produkt eller del kan tillåtas få samma fel som i nyss har löst. Detta löser den riktiga rotorsaken som bygger upp företaget långsiktigt. Nu skapar vi tydliga planer och klubbar igenom ansvaret för att sedan snabbt implementera alla åtgärder.

Stoppa problemet från att nå kund

När vi listat ut vad problemet är behöver vi ibland sätta in någon form av containment för att stoppa problemet från att påverka våra kunder. Behöver vi det kommer ett av våra mål med problemlösningen vara att ta bortcontainment igen innan vi är klara. Alldeles för många gånger stannar problemlösningen här med effekt att företag har lager på lager av manuella inspektioner för att inte "läcka" igenom problem istället för att faktiskt lösa dem.. känner ni igen er?

Identifiera rotorsaker

Det finns flera sätt att genomföra detta på, det vanligaste brukar vara 5 varför, som beskrivs nedan. Man kan även använda faktoranalys för mer matematiska problemformuleringar. Oavsett metod så är det viktiga att håll atungan rätt i mun och förbi faktabaserad i sin approach. Orsak kan lätt bli ursäkt och då kommer man ingenstans. Händer det är det oftast pga att man inte är faktabaserad.

Logikträd och hypotesträd

Struktur är bland det viktigaste som finns inom såväl ledarskap som problemlösning. Det hjälper oss att strukturera tankar, idéer, kommunikation och strategier. Det låter oss säkerställa att vi tänker på allt och inte missar något. Det låter oss på ett enkelt sätt involvera andra i våra tankar och nyttja krafterna från teamwork.

Det absolut enklaste verktyget i strukturlådan är logik- och hypotesträden. Strukturen som sådan är likadan, men användningen skiljer sig lite mellan logik- och hypotesträdet. Det enklaste sättet att förklara är nog att ta exemplet problemlösning. Vi kan lösa problem på två sätt beroende på vilka förutsättningar vi har:

Logikdrivet. Logikdriven problemlösning är mattematiskt total. Varje del av problemet delas upp i underdelar som i sin tur delas upp i ytterligare underdelar. Vi tänker på alla möjliga alternativ. På så sätt skapar vi oss ett holistiskt förgrenande träd som täcker alla möjligheter till att problemet kan inträffa. Praktiskt sätt tar vi det hela nivå för nivå (se 5 varför), men vi skulle kunna göra ett jätteträd om vi hade tid och lust. Logikträdet är oftast frågande, dvs vi skriver i frågoformuleringar i vårt träd
Hypotesdrivet. Hypotesdriven problemlösning skiljer sig i att vi har en idé om vad lösningen kan vara. Vi grenar upp trädet på samma sätt som den logikdrivna problemlösningen, men istället för att ta med alla lösningar så säger vi vad vi med stor sannolikhet tror att problemet är (sedan verifierar vi den hypotesen och går vidare eller börjar om). Hypotesträdet är oftast påstående.

Låt oss sätta detta i ett exempel.

Problem: Jag väger 5 kilo för mycket (o-lean) och min fru (och således jag) vill att de försvinner till sommaren.

Ett logikdrivet träd hade utforskat alla möjliga anledningar till att jag väger 5 kilo för mycket och börjat med att ställa sig frågan "hur går jag ner 5 kilo till sommaren?" Ni ser ett exempel på detta till höger. Vi hade utforskat alla möjligheter och sedan försökt verifiera vilka som faktiskt kommer ha effekt.

Ett Hypotesträd skulle istället angripa utmaningen med ett påstående; "Det enda långsiktigt nyttiga sättet att gå ner 5 kilo till sommaren är att äta nyttigare och träna mera". Sedan hade detta brutits upp till ett par underkategorier som jag misstänker applicerar på mig själv hade inneburit "sluta äta onödigt småplock i tv-soffan", "max en after work i veckan" samt "spring minst 1 mil 3 gånger i veckan".

Där har vi skillnaden mellan logik- och hypotesträd. Använd gärna vår mall och skapa dina egna logik- och hypotesträd.

Fördjupande statistikverktyg

Det finns flera avancerade statistikverktyg som vanligtvist förekommer i 6 sigma processerna, men som vi även använder vid behov. Det är onödigt att koka havet för en kopp te och använda dessa alltid då de tar lång tid och är rätt avancerade, men när de verkligen behövs för att bryra ner problemet är de också riktigt bra!

Regressionsanalys

Regressionsanalysen är ett viktigt verktyg inom sex sigma's DMAIC process men även brett använt inom kvalitetsteknik. Hela målet med regressionsanalys är egentligen att lyckas tolka en mängd datapunkter efter någon form av kurva (=trend). För de mer avancerade tillämpningarna är minitab ett använtbart verktyg, men i de allra flesta fallen räcker det att öppna excel och plottra upp två värden mot varandra i en vanlig graf. Det brukar räcka längt för att dra slutsatser om vad vi ser.

Kapabilitetsindex

Enligt all maskinteknisk och kvalitetsteknisk standard ska en maskin vara capable, repeatable och reliable. Det innebär lätt sagt att maskinen ska vara kapabel att göra rätt sak, ha förmågan att göra det hela tiden och vara så driftsäker att det går att lite på att den gör det hela tiden. Kapabilitetsindex är ett verktyg som används för att bedöma hur capable en process eller maskin är, det vill säga vilken förmåga processen eller maskinen har att mäta krav, toleranser och specifikationer. Kapabilitetsindex är ett vanligt förekommande verktyg inom t.ex. sex sigma och kvalitetskontroll.

SIPOC

SIPOC är ett strukturerar sätt att beskriva en end-to-end process på ett enkelt och övergripande sätt. SIPOC står för Supplier, Input, high-level Process, Output och Customers. SIPOC är en viktig del i DMAIC processen inomsex sigma världen.

7QC tools

Inom kvalitetsteknik talar man ofta om de 7 Quality Control verktygen, som används för att identifiera och klassificera kvalitet och lite mer specifikt kvalitetsproblem. De är mycket användbara och starkt ihopkopplade med praktiskt problemlösning framför allt här, när vi ska bryta ner problemet enligt 5W2H.

Pareto - Utmärkt verktyg för att prioritera arbetek osv

Histogram - lämpliga vid t.ex. toleransproblem, tekniska avvikelser, Cp och Cpk

Control charts (SPS) - Till de mer avancerade problemen där vi misstänker toleransproblem eller maskinproblem som ett av spåren att undersöka

Regressionsanalys - Oftast bättre än man tror. Bra för att utvärdera påverkande faktorer, som t.ex. maskinhastighet, injektionstryck, temperatur, lufttryck osv

Grafer - Data kan formas på många sätt. Det är viktigt att hantera alla olika typer av grafer för att visa data på det sätt att man ser avvikelse

Fiskben - Fiskbensanalysen är en "cause and effect" analys som hjälper till att identifiera första gradens anledningar till problem på ett strukturerar sätt

Check sheets - Enklaste formen av uppföljning ger massvis med information om vad vi har för problem och kan enkelt sammanställas till någon a de andra verktygen