5 Miért (5 Why) és a gyökérok-elemzés (RCA, Ishikawa, 4M)

A konyhában a mennyezetről csöpög a víz. Kiteszel egy vödröt, másnap megint tele. A vödör nem oldja meg a bajt, mert nem a csöpögés a probléma, hanem a fölötte szivárgó cső. Amíg a csövet nem javítod, a vödröt ürítheted a végtelenségig. Pontosan ezt a csapdát kerüli el az 5 Miért (angolul 5 Why): ahelyett, hogy a látható tünetet kezelnéd, addig kérdezel rá ismételten a „miért?“-re, amíg el nem éred a valódi kiváltó okot, amelynek megszüntetése után a probléma nem tér vissza. A módszer olyan egyszerű, hogy egy kíváncsi gyerek is használja („de miért?… és az miért?”), mégis ez a Lean gyökérok-elemzésének alapeszköze. Nézzük meg, mi ez, miért működik, és hogyan használd.

Az 5 Miért (5 Why) egyszerű gyökérok-elemzés: a tünettől indulva ismételten a „miért?“-et kérdezzük, amíg a probléma valódi kiváltó okához nem érünk. Jellemzően öt kérdés vezet a felszíni tünettől a cselekvésre alkalmas gyökérokig, de az „öt” csak irányszám. A logika az, hogy a tünet kezelése helyett a gyökérok megszüntetése biztosítja, hogy a probléma ne ismétlődjön. Az A3 problémamegoldás okelemzési szakaszának alapeszköze; az okok kategorizálásához gyakran az Ishikawa- (halszálka) diagramot és a 4M-keretet (Ember, Gép, Anyag, Módszer) hívja segítségül. Az ellenintézkedés mindig a gyökérokra irányul, nem a tünetre.

1. ábra — az 5 Miért a klasszikus olajszivattyú-példán: a gyökérok nem a kiolvadt biztosíték, hanem a hiányzó megelőző karbantartás; az ellenintézkedés erre irányul.

Kinek szól?

Ez a cikk azoknak szól, akik a gyakorlatban is szembejönnek ismétlődő hibákkal és azok kivizsgálásával: operátor · műszak- és üzemvezető · folyamatmérnök · karbantartó · megbízhatósági (reliability) mérnök · minőségmérnök · HSE · Lean/CI-szakember.

Tanulási célok

A cikk elolvasása után képes leszel:

• végigvinni egy 5 Miért-láncot egy tünettől a cselekvésre alkalmas gyökérokig, és megindokolni, miért nem a szám a lényeg;
• megkülönböztetni a tünetet a gyökéroktól, és a rájuk irányuló beavatkozást (tüneti kezelés vs. ellenintézkedés);
• az okokat Ishikawa-diagramon és a 4M/6M keretben kategorizálni, és felismerni, mikor kell lineáris lánc helyett párhuzamos ág-elemzés;
• alkalmazni a „5 Miért, nem 1 Ki“ elvet, azaz a folyamatra, nem a bűnösre kérdezni;
• megvonni a határt: mikor nem elég az 5 Miért, és milyen erősebb módszer egészíti ki.

A lényeg

• A tünettől a gyökérokig láncolt „miért?“ kérdésekkel jutunk el, jellemzően öt lépésben.
• Az „5“ irányszám, nem dogma: addig kérdezz, amíg cselekvésre alkalmas gyökérokot nem érsz el.
• Ellenintézkedés a gyökérokra, nem a tünetre, különben a probléma visszatér.
• Feltétel: validált jelenállapot-megfigyelés (gemba), különben a „miértek“ feltételezésre épülnek.
• Kiegészítők: Ishikawa (halszálka) + 4M az ok-kategóriákhoz; összetett, párhuzamos okoknál fa-alapú elemzés.
• „5 Miért, nem 1 Ki“: a folyamatot vizsgáld, ne a bűnöst; ez a tanuló, büntetésmentes kultúra alapja.

Miért számít? (a tét)

Egy tünet gyors „megjavítása“ olcsónak tűnik, de ha nem a valódi okot szünteted meg, a hiba visszatér, és minden ismétlődéskor újra fizetsz érte: leállással, selejttel, kockázattal. A hagyományos és a Lean szemlélet itt válik szét élesen.

Szemlélet	Mit tesz a hibával	Következmény
Hagyományos	kezeli a tünetet (kicseréli a biztosítékot, kiteszi a vödröt)	a probléma visszatér
Lean	megszünteti a gyökérokot	a probléma nem ismétlődik

Lean tanács

A gyökérok megszüntetése rövid távon több időbe telhet, mint a tüneti javítás, de a befektetés gyorsan megtérül, mert a probléma soha többé nem ismétlődik. A gyökérok-alapú problémamegoldó kultúra magasabb OEE-hez, magasabb termelékenységhez és motiváltabb csapathoz vezet.

Ezért éri meg a fegyelmet: nem az a cél, hogy a hibát gyorsan eltüntesd a szem elől, hanem hogy egyszer, tartósan megszüntesd. Egy probléma a Lean szemében nem bosszúság, hanem a folyamatos fejlesztés lehetősége.

Mi az 5 Miért, és honnan ered?

Az 5 Miért a Lean legrégebbi és legkönnyebben tanítható problémamegoldó eszköze: addig kérdezünk rá a „miért?“-re, amíg a probléma mélyére nem jutunk. Úgy vezet a gyökérokhoz, hogy minden választ egy újabb „miért?” kérdéssel von kérdőre: a láncolt kérdések rétegről rétegre haladnak a felszíni tünettől a cselekvésre alkalmas kiváltó okig, amelynek megszüntetése után a hiba nem ismétlődik. A módszert a Toyota termelési rendszerében Taiichi Ohno tette híressé, aki a gyökérok-elemzés fegyelmét a TPS problémamegoldó kultúrájának középpontjába állította. Az alapötlet, hogy a válaszok egymásba kapcsolódnak: minden „miért?“ az előző válaszra irányul, így lépésről lépésre a felszíni tünettől a rendszer-szintű okig hámozzuk le a probléma rétegeit.

A módszer ereje az egyszerűségében van. Nem igényel szoftvert, statisztikát vagy hosszú képzést, csak fegyelmet, hogy ne álljunk meg az első kézenfekvő oknál. A gyakorlatban az 5 Miért az A3 problémamegoldás okelemzési (Cause Analysis) szakaszának, és a Root Cause Problem Solving (RCPS) módszernek az alapeszköze; a PDCA és a DMAIC elemző fázisának közös gerince.

Hogyan működik lépésről lépésre?

A recept egyszerű: fogalmazd meg pontosan a tünetet, majd ismételten kérdezd, „miért?“, végül tervezz ellenintézkedést a gyökérokra. A lépések:

1. Fogalmazd meg pontosan a problémát/tünetet validált jelenállapot-megfigyelés alapján (lásd gemba-walk).
2. Kérdezd: „Miért történik ez?“ és rögzítsd a választ.
3. Az előző válaszra ismét kérdezz „Miért?“-et.
4. Ismételd, jellemzően ötször, amíg cselekvésre alkalmas gyökérokhoz nem érsz.
5. Ellenőrizd a lánc logikáját visszafelé („ezért, tehát…“).
6. Tervezz ellenintézkedést a gyökérokra, ne a tünetre.

A módszer klasszikus tankönyvi példája (lásd az 1. ábrát) egy leállt gép:

1. Miért állt le a gép? Kioldott a túlterhelés-biztosíték.
2. Miért oldott ki a biztosíték? Kevés olaj volt a tengelyen.
3. Miért volt kevés olaj? A szivattyú keveset szállított, mert elkopott a tengely.
4. Miért nem működött jól a szivattyú? Az olajszűrő eltömődött fémforgáccsal.
5. Miért tömődött el a szűrő? Nem volt megelőző karbantartás, heti szűrőtisztítás.

Az ötödik válasz a gyökérok: a hiányzó megelőző karbantartás. Ha csak a biztosítékot cseréled, a gép pár nap múlva újra leáll. Az ellenintézkedés ezért a heti szűrőtisztítás bevezetése, nem az alkatrészcsere.

Hogyan kategorizáljuk az okokat? Ishikawa és a 4M

Ha a problémának nem egyetlen lineáris ok-lánca van, hanem több párhuzamos oka, egyetlen „miért“-lánc nem fedi le mindet. Ilyenkor az Ishikawa- (halszálka, fishbone) diagram segít: a gerinc a problémához (az „okozathoz“) mutat, a ferde „csontok“ pedig az ok-kategóriák, amelyek mentén rendszeresen végigveszed a lehetséges okokat. A halszálka biztosítja, hogy minden lehetséges okot végiggondolj, és különösen hasznos ismétlődő meghibásodások okának feltárásában.

2. ábra — az Ishikawa-diagram a 4M ok-kategóriákkal; a probléma több párhuzamos ágon vizsgálva, és minden ágon lefuttatható a saját 5 Miért-je.

A leggyakoribb kategóriakeret a 4M, amely egyben a gemba-séta diagnosztikai kerete is:

M	Kategória	Mit néz
Man (Ember)	jelen van, betanított, többfunkciós?	kompetencia, jelenlét
Machine (Gép)	proaktívan karbantartott (TPM)?	megbízhatóság
Material (Anyag)	épp időben és minőségben (JIT)?	feed, segédanyag
Method (Módszer)	standard munka a takt időn belül?	SOP, paraméterablak

A 4M eredetileg 3M volt (ember, gép, anyag), amit a „módszer“ (method) egészített ki. Bővített változata a 6M, ahol két további kategória jelenik meg: a Measurement (mérés) és a Mother Nature / Environment (környezet). Minden „csonton“ érdemes lefuttatni a saját 5 Miért-jét, hogy az adott ág valódi gyökérokáig juss.

Fogalom vs. eszköz

Az 5 Miért és a halszálka nem versenytárs, hanem munkamegosztás: a halszálka szélességben térképezi fel az összes lehetséges ok-kategóriát, az 5 Miért mélységben hatol le egy-egy ágon a gyökérokig. Összetett problémán a kettő együtt a legerősebb.

„5 Miért“, nem „1 Ki“ — a folyamatot vizsgáld

A jó gyökérok-elemzés a folyamatra kérdez, nem a személyre. A vezetői antiminta az „1 Ki?“ (ki hibázott): ez bűnbakot keres, elnémítja a bejelentést, és a valódi, rendszer-szintű ok rejtve marad. Az „5 Miért?” ezzel szemben a rendszert tárja fel, például a hiányzó megelőző karbantartást vagy a be nem tartott standardot.

Ezt az elvet James Womack fogalmazta meg élesen: a vezető szerepe, hogy kérdéseket tegyen fel („5 Miért?, nem 1 Ki?“), ne pedig hogy válaszokat osztogasson vagy felelőst keressen. A legnagyobb akadály a gemba-fóbia: a vezetőket arra képezték, hogy tudják az összes választ, holott a gyökérok nem az irodában, hanem a helyszínen derül ki.

Elrettentő ellenpélda

Egy tipikus rossz reakció: „22 darab A2 hibakód van a múlt heti adatban, de az illető most nincs itt, mit tehetünk vele? Semmit. Ugorjunk a következő pontra.“ A hibakódok adminisztrálva vannak, de senki nem megy ki a helyszínre, és a probléma soha nem oldódik meg. A gyökérok-elemzés épp ennek az ellentéte.

A folyamatra kérdező, büntetésmentes megközelítés a tanuló kultúra alapja, és a near-miss bejelentési hajlandóság előfeltétele.

Mi az ellenintézkedés (countermeasure)?

Az 5 Miért kimenete az ellenintézkedés: a gyökérokot megszüntető, ellenőrizhető beavatkozás. Nem „megoldás“ abban az értelemben, hogy örökre lezárja a témát, hanem a jelenleg legjobb, visszamérhető válasz a feltárt gyökérokra. Jellemzői:

• a gyökérokra irányul, nem a tünetre;
• konkrét: ki, mit, mikorra;
• visszamérhető (PDCA Check-fázis);
• standardba épül (standard-munka), hogy ne csússzon vissza.

Az ellenintézkedés akkor kész, ha a mérés igazolja, hogy a probléma tényleg nem tér vissza, és a bevált megoldás beépült a napi standardba.

Folyamatipari kontextus és biztonság

Incidens- és near-miss kivizsgálásban az 5 Miért a folyamatbiztonsági gyökérok-elemzés bevett, gyors és strukturált belépő eszköze: a megfigyelt eltérés mögötti szervezeti és karbantartási okok feltárásával megelőzhető a hasonló esemény, a tanulság pedig beépül a megelőző karbantartásba és a standardokba.

Összetett, többszörös okú eseményeknél azonban egyetlen „miért“-lánc nem elég, ezért a strukturált kivizsgálás egy egész eszköztárat használ, a súlyosság szerint skálázva:

Eszköz	Mire jó
Fishbone / Ishikawa	összegyűjti az összes lehetséges gyökérok-jelöltet (ok-kategóriák szerint)
Fact Tree (tényfa)	az esemény objektív tényeit és a mögöttes okokat azonosítja
5 Miért	összefoglalja az elemzést, és mélyebbre visz az alapokokig és a hiányzó kontrollokig
Events & Causal Factor	idővonalas ok-hatás elemzés, ahol az alkalmazható
Reality Charting	a legösszetettebb esetekre

Biztonsági határvonal

Nagybaleseti veszélyű (Seveso) eseményeknél az 5 Miért önmagában nem elég: ilyenkor formálisabb, fa-alapú módszerekkel (fault tree, bow-tie) egészítik ki, mert egyetlen lineáris lánc nem fedi le a párhuzamos okokat és a hiányzó védelmi rétegeket (lásd lopa-sil). A gyökérok-elemzés a tanulást szolgálja, de nem helyettesíti a tanúsított kockázatelemzést.

Bevezetés a gyakorlatban (roadmap)

Az 5 Miért mint kultúra a Root Cause Problem Solving (RCPS) részeként vezethető be, amelynek célja a problémák ismétlődésének megelőzése és a folyamatos fejlesztés. Javasolt lépések:

1. Válassz egy fájó, ismétlődő problémát, amely mérhető (leállás, selejt, near-miss). Fogalmazd meg pontosan, mi az eltérés a standardtól.
2. Menj a gembára, és validáld a tünetet valós megfigyeléssel, ne feltételezéssel.
3. Térképezd fel az okokat halszálkával (4M/6M), ha a probléma összetett, majd a legvalószínűbb ágon futtasd le az 5 Miért-et.
4. Azonosítsd a gyökérokot, és tervezz rá ellenintézkedést (felelős, határidő).
5. Vezesd be és mérd vissza a PDCA körrel; ha a probléma nem tér vissza, építsd standardba és terjeszd ki hasonló esetekre.

Gyakorlati rész / worked example

Feladat. A „B“ műszaknak nem áll rendelkezésre a szükséges 100 alkatrész. Fusd le a láncot; jó példa arra, hogy itt nem öt, hanem hat „miért?“ visz le a gyökérokig (az „5“ tényleg csak irányszám):

1. Miért nem állt rendelkezésre a 100 alkatrész? Mert tűrésen kívüliek voltak.
2. Miért voltak tűrésen kívül? Mert a furatok átmérője nem volt megfelelő.
3. Miért nem volt jó a furatátmérő? Mert idő előtt elkopott a fúrószár.
4. Miért kopott el idő előtt a fúrószár? Mert a gép nem megfelelő sebességgel üzemelt.
5. Miért üzemelt rossz sebességgel a gép? Mert a kezelő (operátor) elállította a sebességet.
6. Miért állította el a sebességet? Mert az előző termék gyártásához az volt a helyes paraméter.

A forrás a láncot itt zárja. Lean szemmel a gyökérok azonban nem a kezelő hibája, hanem a hiányzó átállási standard: nincs kényszerített lépés, amely a termékváltáskor visszaállítja és ellenőrzi a paramétert. Ebből következik az ellenintézkedés is: az átállási standard és egy paraméter-ellenőrzés bevezetése (poka-yoke jellegű kényszerített sorrenddel), nem a kezelő megrovása.

Házi feladat. Válassz egy saját területeden ismétlődő problémát, és fusd le rá az 5 Miért-et. Írd le a láncot, jelöld meg a gyökérokot, és fogalmazz meg egy konkrét ellenintézkedést (ki, mit, mikorra). Ellenőrizd: a láncod a folyamatra kérdez-e, vagy egy személyre.

Mérés / audit

• Ismétlődő hibák és leállások trendje (csökken-e a gyökérok-megszüntetés után).
• Lezárt ellenintézkedések aránya és átfutási ideje.
• Visszatérő okok aránya: ha ugyanaz a gyökérok újra felbukkan, az elemzés vagy az ellenintézkedés gyenge volt.
• OEE-kapcsolat: a gyökérok-megoldó kultúra csökkenti az ismétlődő leállásokat, ezzel emeli az OEE-t és a motivációt.

Gyakori hibák

A buktatók szinte mind ugyanabból fakadnak: az elemzés túl korán megáll, vagy rossz irányba fordul. Anti-minta ↔ korrekció párokban:

• Megállás a tüneti oknál. Kicseréljük a biztosítékot, és „kész“. A probléma pár nap múlva visszatér. Helyette: kérdezz tovább a cselekvésre alkalmas gyökérokig, és arra tervezz ellenintézkedést.
• Feltételezésre épülő „miértek“. A választ az irodából, tapasztalati sejtésből adjuk. Helyette: minden „miért“ választ validált gemba-megfigyeléssel támassz alá (San Gen Shugi: valós hely, valós adat, valós alkatrész).
• „1 Ki?“ bűnbakkeresés. Ki hibázott? A bejelentés elnémul, a rendszer-ok rejtve marad. Helyette: „5 Miért?“, a folyamatra kérdezz, ne a személyre.
• Lineáris lánc többszörös oknál. Egyetlen „miért“-sor nem fedi le a párhuzamos okokat. Helyette: előbb halszálka (4M/6M) az ok-kategóriákra, majd ágakra bontott 5 Miért.
• Ellenintézkedés visszamérés nélkül. „Megoldottuk“, de senki nem ellenőrzi. Helyette: PDCA Check, és standardba építés, hogy ne csússzon vissza.

Mikor NE használd? (a módszer korlátai)

Az 5 Miért gyors és olcsó, de nem minden helyzetre való. Tudni, hol a határa, éppolyan fontos, mint a módszer maga:

Helyzet	Miért nem (elsősorban) az 5 Miért	Mi a helyes válasz
Többszörös, párhuzamos okú esemény	egyetlen lineáris lánc nem fedi le az összes okot	előbb Ishikawa/Fact Tree, majd ágakra bontott 5 Miért
Nagybaleseti veszélyű (Seveso) incidens	a lánc nem mutatja a hiányzó védelmi rétegeket	fa-alapú módszer (fault tree, bow-tie), [[lopa-sil	LOPA/SIL]]
A tények bizonytalanok	a „miértek“ spekulációra épülnének	előbb tényfeltárás (Fact Tree, gemba), utána 5 Miért
Statisztikai, változékonyságból eredő probléma	a „miért“ nem kezeli a szórást	adatalapú elemzés ([[dmaic	DMAIC]], SPC)

Ökölszabály: az 5 Miért az egy fő ok-láncra visszavezethető, ismétlődő problémákra a legerősebb. Összetett, sokokú vagy biztonságkritikus eseménynél nem helyettesíti a formális módszereket, hanem azok részeként, összefoglaló eszközként a legjobb.

Vidd haza (kulcsok)

• A tünet nem a gyökérok. A vödör ürítése vagy a biztosíték cseréje nem oldja meg a bajt; a szivárgó csövet, illetve a hiányzó karbantartást kell megszüntetni.
• Kérdezz, amíg cselekedhetsz. Az „5“ irányszám: addig menj, amíg a válasz egy megtehető ellenintézkedést ad.
• Ellenintézkedés a gyökérokra, konkrétan (ki/mit/mikorra), visszamérve, standardba építve.
• „5 Miért, nem 1 Ki“: a folyamatra kérdezz, ne a bűnösre; ez a bejelentés és a tanulás előfeltétele.
• Összetett okra halszálka + 5 Miért, biztonságkritikus eseményre fa-alapú módszer.
• Menj a gembára: a gyökérokot nem az Excel-táblában, hanem a helyszínen találod meg.

Önteszt

1. Egy szivattyú hetente leáll. Fuss le rá egy 5 Miért-láncot, és mondd meg, melyik ponton érnél „cselekvésre alkalmas“ gyökérokhoz, illetve hol állna meg a tüneti javítás.
2. Mikor cserélnéd a lineáris 5 Miért-láncot Ishikawa-diagramra, és melyik 4M-kategóriákat vennéd végig?
3. Mi a különbség az „5 Miért?“ és az „1 Ki?“ kérdés között, és miért fojtja el ez utóbbi a hibabejelentést?

Hogyan jelenik meg a digitális gyakorlatban?

Az 5 Miért elve nem áll meg a workshop flipchartjánál: ugyanez a logika szoftveresen is megvalósul egy jól tervezett eltérés-kezelő rendszerben. A papírlap helyett itt strukturált mezők, kötelező akciók és ismétlődés-figyelés viszik a „tünettől a gyökérokig, majd az ellenintézkedésig“ láncot, a mechanizmus más, az elv ugyanaz.

5 Miért-elv	Digitális megvalósítás	Mit ad
Strukturált gyökérok-lánc	eltérés-rögzítő űrlap láncolt „miért?“ mezőkkel	a lánc dokumentált, nem a fejben marad
Ellenintézkedés a gyökérokra	akció felelőssel és határidővel, kötelező kitöltés	minden gyökérokhoz lezárható, számonkérhető akció tartozik
Visszamérés (Check)	a lezárt akció státusza + eredmény rögzítése	kiderül, ha a beavatkozás nem működött
„5 Miért, nem 1 Ki“	a napló a folyamatot és az okot rögzíti, nem a személyt	büntetésmentes, tanuló nyom
Ismétlődés-figyelés	a visszatérő okok automatikus kimutatása	a Pareto-elv szerint a nagy okokra fókuszál

A lényeg

A modern digitális eltérés-kezelő rendszerek ugyanazt csinálják, mint egy jó 5 Miért-workshop: nem hagyják, hogy egy tünet gyökérok és ellenintézkedés nélkül lezáruljon. Ha egy rendszer minden lezárt eltéréshez okot és visszamért akciót kér, nagy eséllyel az 5 Miért logikája dolgozik a háttérben.

Kapcsolat az OPEREX-hez (műszaknapló)

A near-miss vagy üzemzavar 5 Miért elemzése és az abból fakadó megelőző intézkedés a műszaknaplóban (OPEREX) rögzíthető, dokumentált gyökérok-nyomot adva. Így az ismétlődő hibák trendje és a megtett akciók visszakövethetők és auditálhatók (ISO 45001 §10.2, incidens-kivizsgálás és korrekciós intézkedés). A műszakok közötti átadásnál nem vész el a függőben lévő gyökérok-akció, és a visszatérő okok kiszűrhetők.

Terminológia (HU / EN / JP)

Magyar	Angol	Japán / megjegyzés
5 Miért	5 Why	なぜなぜ分析 — iteratív gyökérok-kérdés
Gyökérok-elemzés	Root Cause Analysis (RCA)	a kiváltó ok feltárása
Gyökérok-alapú problémamegoldás	Root Cause Problem Solving (RCPS)	ismétlődés megelőzése
Halszálka-diagram	Ishikawa / Fishbone / Cause-Effect	特性要因図 — ok-kategóriák
Négy M	4M (Man, Machine, Material, Method)	a halszálka „csontjai“
Hat M	6M (+ Measurement, Environment)	bővített ok-kategóriák
Ellenintézkedés	Countermeasure	対策 — a gyökérokra ható beavatkozás

GYIK

Miért pont ötször kérdezünk rá a „Miért?"-re?

Az öt csak tapasztalati irányszám: átlagosan ennyi kérdés után jutunk el a tüneti októl (pl. kiolvadt biztosíték) a cselekvésre alkalmas gyökérokig. A lényeg nem a szám, hanem hogy ne álljunk meg a felszíni oknál, de ne is menjünk értelmetlenül tovább, ha már megtehető ellenintézkedéshez értünk.

Mi a baj, ha az ellenintézkedés csak a tünetet kezeli?

Akkor a probléma vissza fog térni, és minden ismétlődéskor újra fizetsz érte. Az okelemzés célja épp az, hogy a kiváltó gyökérokot szüntessük meg, így a beavatkozás tartós, nem ismétlődő hatást ér el.

Mi a különbség az „5 Miért" és az „1 Ki" között?

Az „5 Miért?“ a folyamat és a rendszer gyökérokát tárja fel, az „1 Ki?“ a hibás személyt keresi. Az utóbbi bűnbakot kreál és elnémítja a bejelentést; a Lean a folyamatot vizsgálja, nem a bűnöst.

Mi a különbség az 5 Miért és a halszálka-diagram között?

A halszálka (Ishikawa) szélességben térképezi fel az összes lehetséges ok-kategóriát (4M/6M), az 5 Miért mélységben hatol le egy adott ágon a gyökérokig. Összetett problémán a kettőt együtt használjuk: előbb halszálka, majd a legvalószínűbb ágon 5 Miért.

Mikor nem elég az 5 Miért?

Összetett, többszörös okú eseményeknél (pl. Seveso-incidens), ahol párhuzamos okok hatnak, vagy ahol a tények bizonytalanok. Ilyenkor Ishikawa-diagram, Fact Tree vagy fa-alapú elemzés (fault tree, bow-tie) egészíti ki, illetve előzi meg.

Kapcsolódó fogalmak

a3-riport · pdca · jidoka · poka-yoke · kaizen · gemba-walk · standard-munka · near-miss · oee · lopa-sil

Következő lépés

Ha ezt megértetted, innen érdemes tovább menned, ebben a sorrendben:

1. a3-riport — a keret, amelyben az 5 Miért él: az egyoldalas problémamegoldás okelemzési szakasza épp a gyökérok-elemzés.
2. pdca — a fejlesztési kör, amely visszaméri, hogy az ellenintézkedés tényleg megszüntette-e a gyökérokot.
3. poka-yoke — hogyan tedd az ellenintézkedést hibabiztossá, hogy a gyökérokból fakadó hiba fizikailag ne térhessen vissza.

Hivatkozások / További olvasnivaló

• Taiichi Ohno: Toyota Production System: Beyond Large-Scale Production. Productivity Press, 1988. — a gyökérok-elemzés és a „miért ötször“ fegyelmének kanonikus forrása (a szivattyú-példával).
• James P. Womack, Daniel T. Jones: Lean Thinking. Free Press, 1996 (bővített kiadás 2003). — a gyökérok-központú, folyamatra fókuszáló vezetői gondolkodás.
• James P. Womack: Gemba Walks. Lean Enterprise Institute, 2011. — a „5 Whys, not 1 Who“ elv és a gemba-alapú vezetés.
• Kaoru Ishikawa: Guide to Quality Control. Asian Productivity Organization, 1976. — az ok-hatás (halszálka) diagram kanonikus alapműve.