Már nem tudom, melyik lean, vagy kaizen könyvben olvastam (talán a Toyota Katá-ban), hogy miben különbözik egy "nyugati" kultúrában egy gyárbejárási felmérés (egy hibafeltáró értekezlet, vagy akármilyen komplex témákat/problémákat kezelő izé) és egy gemba, vagy kaizen (ezek madártávlatból ugyanazok (illetve ezek már magukban foglalják a fejlesztés gondolatát is, mégpedig a "folyamatos fejlesztés"-ét), mint az előzőek, csak japánul... Ahogy a jogászoknak, orvosoknak egy csomó mindent meg kell tanulni latin kifejezéssel is, aki leanre adja a fejét, az japán-tanulásba is kezd...).
Szóval, az úgynevezett "nyugati" kultúrkörben (amiben állítólag mi is élünk, bár a kis piros pont óta ebben már nem vagyok annyira biztos...) ilyenkor egy ún. listát (hiba/feladatlistát) készítenek, azt kiosztják felelősökre és határidőket adnak neki, a felelősök szétszélednek és mindenki hozzáfog a maga kis feladatához, szeletéhez és ha minden jól megy, a legjobb tudása szerint a feladatot végrehajtja, a hibát kijavítja, vagy a fejlesztési lépést megteszi, azután megint lesz egy menetrendszerű megbeszélés, ahol kiértékelik, mit csináltak, annak alapján készítenek egy újabb listát, felelősök, határidők, és kezdődik az újabb ciklus.
Ezzel egy - alapvető - baj van: a lista elemei általában erősen összefüggenek, amit az egyikkel valaki valamit csinál, az ki fog hatni a másikakra is, amelyeket párhuzamosan ugyancsak éppen - a listán kiadott feledatkiosztás szerint - valamilyen változást hajtanak végre, ami megint vissza fog hatni az elsőre és amúgy az összes többire is, amellyel egy rendszert alkotnak. Egyszerre össze-vissza változtatják a dolgokat, soha nem lehet pontosan tudni, hogy a következő meetingen értékelt állapot egész pontosan minek alapján alakult ki, mennyi a változtatásból a konkrét direkt közbeavatkozás eredménye és mennyi a többi, közvetett változtatás - nem szándékolt és alkalmasint figyelembe se vett - mellékhatásainak az eredménye.
Mi ezzel szemben a PDCA ciklusos fejlesztésnek a lényege? Egyáltalán, mi az a PDCA? Miközben Japánból jön, egy amerikai, Deming ötlete a tervezz (P) - csináld (D) - ellenőrizd (C) - módosítsd (A) ciklusa. A lényeg az, hogy kitűznek egy általánosabb, hosszú távú célt, és azt középtávú célokra ("target condition" - célfeltétel) bontják. Ezek a célfeltételek viszonylag függetlenek, mondjuk a hosszú távú cél egyes egységekre lebontott célfeltételeit jelentik. Azután minden egyes egység a saját rövid-távú célfeltételét további feladatokra bontja és beindítja a PDCA-"kereket".
A P-tervezés (Planning) fázisban meghatároznak egy adott részfeladatot/akciót, és azt, hogy ennek végrehajtásától milyen eredményt várnak. Használják erre például a zseblámpa analógiát. A zseblámpa fénye valameddig elér, de nem ér el az egységre megállapított rövidtávú célig, nem látni pontosan az egész hozzá vezető utat, ezért kell kisebb feladatokra bontani, pontosan olyanokra, amelyek a "zseblámpánk" fényében beláthatóak valamennyire. Mindjárt ki fog derülni, hogy PFCA-ciklusban van egy trial-error (próba-szerencse) elem is, ezért általában bár belátható, de nem mindig teljesen pontosan előrelátható eredményű feladatról van szó ebben a folyamatmodellben.
A D - csináld (Do) fázisban az egység végrehajtja a feladatot és a C - ellenőrizd (Check) fázisban az eredményt összevetik az előrejelzett eredménnyel.
Ennek az összevetésnek alapján az A - cselekedj, módosíts (Act vagy Adjust) fázisban azt, ami sikerült az előrejelzésből, beépítik ("sztenderdizálják"), ami nem, annak megfelelően módosítják a tervezés alapját (P) és indul újra a ciklus.
Tehát egy rész-feladat elvégzése nem feltétlenül egy PDCA-ciklusban hajtódik végre. Amennyiben egy részfeladat végrehajtása kielégítően megtörtént, elő lehet venni az egység célfeltételének eléréséhez szükséges következő részfeladatot. És ha az utolsó részfeladat kielégítő elvégzésével az egység célfeltételét elérték (az utolsó PDCA-ciklus után), egy rövid értékelés és ünneplés után - a folyamatos fejlesztés, a "kaizen" éretelmében - lehet kitűzni a nagyobb egység, a cég távlati célfeltételével harmonizáló, a konkrét egységre megállapítandó újabb célfeltételt. És így tovább...
Hol van itt az a híres különbség a lista és a kaizen módszer között? Abban, hogy a kaizen szerint egyszerre egy dolgot változtatnak csak meg (PDCA-ciklus...) és annak eredményét alaposan kielemzik és az új, módosított alapról indul a következő PDCA-ciklus... Itt is van lista: az egység célfeltételeinek eléréshez szükséges feladatok lineáris (1,2,3,4...) listája... de, nem esnek neki egyszerre, mint... hanem szép akkurátusan egyszerre csak eggyel foglalkoznak és ezzel elérik, hogy a lista következő feladatainál már fel lehessen használni az előző fejlesztések hatásait is a tervezésnél... Nos, ennyi...
Ez egyébként, jelzem, egy magasabb, majdnem mondom, "filozófiai" szinten is megáll (kár, hogy ettől a szótól mindenki, mint ördög a tömjénfüsttől, fél...)... Otto Scharmer U-elméletéhez szerintem ezen a kerülő (?) úton is el lehet jutni... vagy ha azt mondja valaki, heurisztikus megközelítés, mennyire beszél más dologról? És a megoldásközpontú megközelítés "következő kis lépése", az kutyafüle?
Vissza a földre... érdemes, hasznos ennek az elvnek a mélyebb megértése... vannak céljaink, és ha rendesen emberesek, a kis "zseblámpánk" kizárt, hogy bevilágítsa az egész utat. Valamennyit meg bevilágít, illetve, van egy homályos zóna, amit ha akarom, bevilágít, ha akarom nem... homályos... valahová oda érdemes belőni a részcélt, ami legjobb tudomásunk szerint a nagy cél felé vihet. Azután megtervezni az akciót, és végrehajtani... vagy eltaláltunk valamit, vagy nem, vagy csak részben... lehet a célzást pontosítani, és újrakezdeni a tervezést... azután, ha már jobban belelátunka a homályos részbe, akkor menjünk előre, egészen a széléig... és újra kapcsoljuk be a zseblámpánkat. ...és így tovább...
