
Jeg var veldig imponert over Sissels Lean Six Sigma kunnskap. Hun gjør det enkelt å identifisere forbedringer og skape resultater.

De jobbet hardere. Ansatte flere folk. Jobbet overtid. Problemet kom tilbake. Igjen og igjen. Fordi de aldri fant årsaken.
En produksjonsbedrift hadde lav produktivitet for produksjon av epoksyfylte deler. Leveringene kom på etterskudd. Stresset på produksjonsgulvet økte.
Teamet jobbet på spreng, men klarte likevel ikke å møte kundenes frister.
De visste de måtte endre noe. Men hva?
Situasjon: Produksjonsbedrift med lav produktivitet på epoksyfylte deler. Leveringene kom på etterskudd.
Problem: Produksjonen leverte 44 deler per time. Kapasiteten holdt ikke.
Årsak: Formen holdt ikke rørene ordentlig på plass. Overfylte rør, bortkastet materiale og tidkrevende omarbeid.
Resultat: Fra 44 til 64 deler per time. 45% økning. Ingen nye ansettelser. Ingen overtid.
Første instinkt:
«Vi må jobbe raskere.» «Vi trenger mer folk.» «Vi trenger mer kapasitet.»
Teamet kunne ha ansatt flere folk. Jobbet overtid hver dag. Men det ville ikke løst det grunnleggende: formen fungerte ikke.
Overfylte rør. Bortkastet materiale. Tidkrevende omarbeid. Selv når alle jobbet for fullt, var kvaliteten og konsistensen uforutsigbar.
Ved å bruke strukturert rotårsaksanalyse fant de ut hva som faktisk skapte utfordringen. Da kunne de sette inn tiltak som hadde effekt, i stedet for å fikse det samme om igjen.
Som bildet illustrerer kan et problem (treet) ha mange årsaker (røttene). Over tid vil symptomene (bladene på treet) og problemet (treet) vokse og bli mer synlige.
Å fokusere på bladene gjør det vanskelig å få klarhet i problemet og identifisere de virkelige rotårsakene.
For epoksybedriften var symptomene forsinkede leveranser og frustrerte kunder. Problemet var lav produktivitet, målt i deler per time. Årsaken var formen som ikke holdt rørene på plass.
Rekkefølgen betyr noe: Først forstå problemet. Deretter undersøk årsaker. Til slutt sett inn tiltak.
Disse tre begrepene brukes ofte om hverandre. Det skaper forvirring og fører til at team jobber med feil ting.
Symptomer er det du ser og opplever. Forsinkede leveranser. Høy vrakprosent. Frustrerte kunder. Symptomene er bladene på treet. De vokser tilbake hvis du ikke tar tak i røttene.
Problemet er avviket fra ønsket tilstand, knyttet til en målbar størrelse. I epoksycasen: 44 deler per time når kapasitetsbehovet var høyere. Uten en klar måling vet du ikke hva du forbedrer, og du vet ikke om du lykkes.
Årsaker er de underliggende faktorene som skaper problemet. De er røttene. Ofte usynlige til du graver.
Hyppigheten av problemet avgjør hvilken strategi du trenger. Er det en enkelthendelse eller noe som skjer systematisk? Les mer om det i artikkelen Gulrot eller tre: To typer problemer krever to typer verktøy.
Statistisk prosesskontroll (SPC) skiller signal fra støy. Det vil si: skiller spesiell variasjon fra normal variasjon.
Dette er avgjørende for å velge riktig tilnærming.
Spesiell variasjon betyr at noe unormalt har skjedd. Det finnes én hendelse å spore. En lineær årsak-effekt-kjede.
Normal variasjon er summen av alle tilfeldige faktorer i prosessen. Ingen enkelt årsak. Løsningen krever forståelse av hele systemet.
Kritisk feil: Hvis du reagerer på normal variasjon som om det var spesiell variasjon, gjør du sannsynligvis ting verre.
Her er verktøy som kan hjelpe deg med rotårsaksanalyse:
Strukturer analysen:
• Tankekart, A3 eller prosjektmandat for å strukturere problemløsningen.
Avgjør variasjonstype:
• Statistisk prosesskontroll avgjør om normal eller spesiell variasjon forårsaker problemet. Eller kanskje det ikke er variasjon, men sentrering som er utfordringen. SPC vil fortelle deg det også.
Identifiser mulige årsaker:
• Prosesskartlegging identifiserer mulige rotårsaker.
• 5 Hvorfor og årsak-virkning-diagram (Fiskebein) identifiserer mulige rotårsaker.
Bevis rotårsaker:
• Grafisk analyse kan bevise rotårsaker.
• Hypotesetesting beviser rotårsaker når grafiske analyser ikke er tydelige.
Optimaliser og kontroller:
• Korrelasjon og forsøksplanlegging (DOE) bestemmer optimale faktorverdier.
• Statistisk prosesskontroll (kontrolldiagram) overvåker variasjon i kritiske variabler og sikrer varig løsning.
Verktøyene over brukes innenfor en strukturert problemløsningsmetode. I Lean Tech bruker vi FAST metoden, en forenklet versjon av DMAIC:
Fokus: Forstå problemet og sett felles fokus. Et problem må være knyttet til en målbar størrelse.
Analyse: Forstå variasjon, kartlegg prosessen, bevis rotårsaker med data.
Solve: Løs rotårsakene med tiltak som faktisk virker.
Track: Overvåk og sikre varige resultater.
Kanskje du ikke produserer epoksyfylte deler. Men du kjenner sannsynligvis igjen dynamikken:
• Samme utfordring kommer tilbake til tross for flere tiltak.
• Teamet hopper til løsninger uten å undersøke årsaker.
• Raske tiltak feires, men problemet er tilbake uker senere.
• Det reageres på hvert avvik uten å vite om det er normal eller spesiell variasjon.
• Korrigerende tiltak gjør prosessen mer ustabil, ikke mindre.
Ressurser brukes på å behandle symptomer, ikke løse rotårsakene.
Steg 1: Start med problemet, ikke løsningen
Neste gang et problem dukker opp, motstå impulsen til å gå rett til tiltak. Bruk tid på å forstå problemet og knytt det til en målbar størrelse. Hva er avviket fra ønsket tilstand?
Steg 2: Still spørsmålet «Hvor ofte skjer dette?»
Hyppigheten avgjør hvilken strategi du trenger. En enkelthendelse krever en annen tilnærming enn et tilbakevendende mønster.
Steg 3: Bevis årsaken med data
Ikke anta. Test hypoteser. Samle inn data målrettet, ikke all data, bare det som er relevant for hypotesen du tester.
Steg 4: Sett inn tiltak på rotårsaksnivå
Tiltak på symptomnivå gir midlertidig lindring. Tiltak på rotårsaksnivå gir varige resultater.
Hva er egentlig forskjellen på et symptom, et problem og en årsak?
Symptomer er det du ser og opplever: forsinkede leveranser, høy vrakprosent, frustrerte kunder. Problemet er avviket fra ønsket tilstand, knyttet til en målbar størrelse. Årsaken er det som faktisk skaper problemet. Mange team jobber med symptomene og tror de løser problemet. Det gjør de ikke. Treet vokser tilbake fra røttene.
Hvordan vet jeg hvilket verktøy jeg skal bruke?
Start med spørsmålet: «Hvor ofte skjer dette?» Svaret avgjør strategi. Skjer det sjeldent eller for første gang, er det sannsynligvis en spesiell hendelse med én klar årsak. Skjer det regelmessig, er det sannsynligvis et systemproblem med mange samvirkende faktorer. De to krever helt ulike verktøy. Les mer i artikkelen Gulrot eller tre: To typer problemer krever to typer verktøy.
Hva hvis samme problem fortsetter å komme tilbake?
Da er det et tydelig tegn på at tiltakene treffer symptomene, ikke årsaken. Stopp opp. Kartlegg prosessen. Spør: «Hva er det i systemet som gjør at dette skjer igjen og igjen?» Tilbakevendende problemer er nesten alltid systemiske, ikke enkelthendelser.
Hva er forskjellen på en spesiell hendelse og et systemproblem?
En spesiell hendelse har én utløsende årsak du kan spore. Noe unormalt skjedde. Et systemproblem er bygd inn i prosessen selv. Det skjer fordi systemet er designet til å produsere det resultatet. Å behandle et systemproblem som en enkelthendelse er en av de vanligste feilene i problemløsning, og den gjør som regel ting verre.
Når skal jeg bruke hypotesetesting vs grafisk analyse?
Start alltid med grafisk analyse. Det er raskere og ofte tydelig nok. Bruk hypotesetesting når mønstrene ikke er åpenbare, eller når du trenger statistisk bevis for en viktig beslutning.
Må jeg alltid gå til rotårsaken?
Ikke alltid. Noen ganger er symptomhåndtering det pragmatiske valget, for eksempel når kostnaden ved å løse rotårsaken overstiger gevinsten. Men den beslutningen skal tas bevisst, etter analyse. Ikke som standard fordi det er raskere.
Denne historien er fra vårt ukentlige nyhetsbrev, hvor vi deler erfaringer. Korte historier for deg som vil løse problemer ved roten og oppnå målbar, varig verdiskapning.
Meld deg på nyhetsbrevet vårt:
Hvis du vil lære mer om temaene i dette innlegget:
• Lær systematisk problemløsning i Green Belt kurs
• Skill signal fra støy med statistisk prosesskontroll
• Hvorfor team må bli enige om problemet før de løser det
Lean Tech AS | Kristoffer Robins vei 13
0047 481 23 070
Oslo, Norway
L - Løsningsorientert
E - Engasjert
A - Analytisk
N - Nysgjerrig