Történetek a gembáról sorozat
Az elmúlt hónapokban több, párhuzamosan futó lean projektünkben is alkalmam volt megfigyelni egy érdekes mintázatot. Más-más iparágban működő cégek nagyon hasonló problémákkal szembesültek az „elsőre jót” (right the first time) témakörben. Íme Történetek a gembáról sorozatunk következő része: Elsőre jót! Na jó, akkor másodikra…
A szakmai cikk elolvasásához szükséges idő: kb. 4 perc
Szerző: Balogh György – lean coach
Az elmúlt hónapokban több, párhuzamosan futó lean projektünkben is alkalmam volt megfigyelni egy érdekes mintázatot. Más-más iparágban működő cégek nagyon hasonló problémákkal szembesültek az „elsőre jót” (right the first time) témakörben.
Azt, hogy elsőre jó minőséget előállítani a legideálisabb, és hogy a folyamat előrehaladtával egyre drágul a hibák kijavítása, nem kell magyarázni. Alapvetések, amelyekkel mindenki egyetért. Legalábbis elméletben. A gyakorlat azonban azt mutatja, hogy ez a logika sokszor nem érvényesül. Nézzünk erre három valós példát!
Majd GYURI megoldja
Amikor ez a mondat elhangzott egy prosperáló multinál, kíváncsi lettem, vajon ki lehet az a kolléga, akire ilyen magabiztosan rábízzák a feladatokat. Hamar kiderült, hogy nem hús-vér munkatársról, hanem a Gyártás Utáni Rendrakó Intelligenciáról van szó. Ez a saját fejlesztésű automatizmus szolgált arra, hogy a gyártási folyamat során elmaradt adatrögzítéseket (felhasznált anyag, maradék anyag, selejt stb.) pótolja, azaz az eredeti tervek alapján „kitalálja”.
Jogosan merülhet fel a kérdés:
- Miért marad el az adatrögzítés? – Mint oly sokszor, most is csípőből jött a válasz: „mert a kollégák elfelejtik, nem figyelnek oda”. Ez azonban mindig csak tünet. A valódi ok valahol a folyamatban, a rendszerben van. Azaz:
- Miért tudják a kollégák elfelejteni, kihagyni a szükséges adatokat? – Mert ez esetben a gyártástámogató rendszer nem tette kötelezővé az adatok megadását, és az adminisztráció ideje gyakran vetekedett a gyártási ciklus idejével a kis gyártási tételek miatt.
Habár a maga nemében GYURI kétségkívül remek szoftver, mégiscsak egy utólagos javítás, ami nem mindig egyezik a tényleges felhasználással, így készleteltérések keletkezhetnek. Az automatizmust ráadásul futtatni, frissíteni is kell. Ezzel szemben a meglévő standard betartása – vagy a rendszerben kötelező adatmezők beállítása – megbízható, valós idejű adatokat és összességében kevesebb erőforrásfelhasználást jelentene.
A rendszer találja ki, mire gondolt a másik rendszer!
A második eset tipikus esete annak, amikor egy hibára építünk folyamatokat. Egy nagy nemzetközi cég kollégái arra panaszkodtak, hogy a háttérfolyamatokban (back office) egy ember teljes munkaidejét kitölti az, hogy havonta manuálisan kijavít 5.000 hibás sort, azokat, ahol a tranzakció kezdő és záró ideje megegyezik. Erre azért van szükség, mert az adatokat fogadó külső rendszer ezeket az adatsorokat nem tudja értelmezni, ezért hibát jelez.
A csapat remek munkát végzett a gyökérok felderítésében: az 5.000 hibás sort az a gyakorlat eredményezte, amely szerint az ügyfélszolgálatos (front office) munkatársak így zárták le azokat a tranzakciókat, amelyek végül nem az eredeti kondíciók szerint mentek végbe. Ezek tehát gyakorlatilag nem is történtek meg.
Innen – azt gondolnánk – már csak egy ugrás az elsőre jót állapot megvalósítása. Két ötlet is született:
- Az elsődleges megoldási javaslat arra irányult, hogy IT fejlesztéssel „tanítsák meg” a fogadó rendszernek a hibás adatok figyelmen kívül hagyását.
- A második megoldási javaslat egy új – hibás – standard bevezetését javasolta. Ez azt jelentette volna, hogy a front office kollégák az ilyen tranzakciókat egy perces időtartammal zárják le, így nem okoznak gondot a fogadó rendszernek. Ez igaz, ellenben az alap rendszerben ez 5.000 valótlan tranzakciót, ebből következően számos hibás folyamatot és eredményt (számlázás, riportok stb.) jelentene.
Ahogy tovább kérdezősködtem kiderült, hogy a meg nem valósult tranzakciók kezelésére egyébként létezik egy funkció a rendszerben, amit mindenkinek használnia kellene. Ennek a funkciónak a használata nem eredményez téves bejegyzést. Havonta 5.000 esetben ez mégsem történik meg.
Ebben az esetben a front office és a back office távolsága, a megoldásorientáltság és a sürgetettség ahhoz vezetett, hogy a gyökérok megszüntetése helyett inkább költséges, bonyolult látszatintézkedések felé kanyarodtak a problémamegoldók.
Mr. AutoCorrect
Egy Budapesten működő szolgáltatóközpont multinacionális ügyfelei számára végez adminisztratív szolgáltatásokat. Az ügyfelektől kapott különböző adatállományok formázása a folyamat első lépése. A folyamatot végző csapat sok eltéréssel, nem a standard formátummal találkozik. Az okok között abszolút nyertes a „vevő az első, azzal kell dolgoznunk, amit kapunk tőle”. A megoldás is készen vár, a neve AutoCorrect.
Ezek a cég saját rendszerébe épített szabályok, parancsok, amelyek az egyes partnerek és azok leányvállalatainak egyedi formázásait, hibáit, hiányosságait kezelik. Ha egy oszlop neve eltér az egyik fájlban, az AutoCorrect átírja, ha egy oszlop mindig üres, az AutoCorrect kitörli…stb. Az eredmény magáért beszél(ne): nem kell manuálisan javítani ezeket az ismert hibákat. Ellenben fenn kell tartani egy komplex szabályrendszert és a kezeléséhez szükséges tudást.
Az adatfeldolgozó csapat nyitott volt az újításokra, így kísérletképpen egy kiválasztott ügyfél számára összegyűjtötték azokat az eltéréseket, hibákat, amelyek rendszeresen fennakadást okoznak a folyamatban. A válasz szinte postafordultával jött az ügyféltől: „köszönjük, a felvetések nagy részét be tudjuk építeni a folyamatunkba”.
A sikereken felbuzdulva a csapat már dolgozik egy újabb javaslatcsomagon a következő nagy ügyfelük számára.
Konklúzió
Sokszor egyszerűbbnek, gyorsabbnak, konfliktusmentesebbnek tűnik a folyamatokba kívülről érkező hibás anyagok, alkatrészek, információk utólagos javítása. A tapasztalat azonban azt mutatja, hogy nagyon is megéri feltenni a Miért? kérdéseket, visszamenni a gyökérokig, majd egyszer és mindekorra kiküszöbölni a hiba előfordulását. Gyakran elég egy kötelezővé tett cella, egy standard megfelelő betanítása vagy egyszerűen csak egy beszélgetés a másik féllel.
Arra bátorítalak titeket, vizsgáljátok meg a folyamataitokat, és keressetek olyan lépést, feladatot, ami korábban egy hiba miatt épült be a rendszerbe! Keressétek meg a gyökérokot és javasoljatok hatékony, egyszerű megoldást a megszüntetésére! Ezalatt pedig mindenképp beszéljetek a másik osztállyal, az ügyféllel, a beszállítóval!
A 100%-os siker természetesen nem garantált, de talán ismerős a vicc csattanója:
- „Medve, nem tudnál engem lehúzni a listádról?”
- „Ja, dehogynem!”
A cikk szerzője
lean coach
Történetek a gembáról sorozat
Nagyon sokat írtunk már a lean szemlélet alapelveiről, bevált eszközökről, hasznos technikákról és a kritikus gondolkodás fontosságáról. A fenti témák rendkívül fontosak, viszont úgy éreztük, hogy itt az ideje kivinni titeket a gembára, és megnézni, hogyan alkalmazhatjátok a korábban tanultakat a gyakorlatban! Íme Történetek a gembáról sorozatunk részei:
- Rázva, nem keverve – a „mix well” kísérlet
- Mit tegyünk, ha a dolgozó nem elég ügyes?
- Most akkor melyik a jó termék?
- Lean = józan paraszti ész?
- “Hagyja a cipekedést másra” – logisztikai robotok találkozása a leannel
- Lean IT? – programozók az evidencia csapdájában
- Elsőre jót! Na jó, akkor másodikra…
- Műszakvezetői standard – „Mit is csinál a műszakvezető egész nap?”
Könyvajánló
Rövidebb átfutási időt szeretnél elérni?
Szeretnéd alacsonyabb költségen működtetni a folyamatokat?
Célodul tűzted ki a veszteségforrások megszüntetését?
Az értékfolyamat-térképezésnek nevezett módszer kivételesen hatékony eszköz lehet a fenti célok megvalósításban. A módszer elsajátításának leghatékonyabb eszköze pedig Tanulj meg látni című könyv.
