Szerző: Filius Ágnes
Megjelent: 9 éve

LeanSWAT: kevesebb az elhalt folyamat

- A lean módszertana kiforrott, 70 éves, japán alapokon nyugszik. Miért kellett ezt a bevált módszert átdolgozni?

- 2004 óta foglalkozom folyamatfejlesztéssel. Dolgoztam termelési körülmények között is és jó néhány éve a szolgáltató-iparban terjesztem a leant. Ez egy filozófia, amely alapján el lehet kerülni a veszteség termelését és ember-központúvá válhat a működésmód. De azt vallom, hogy bármely fejlesztési projekt a Six Sigma módszertan logikai lépéseit kell, hogy kövesse. Ez a folyamat-optimalizáló modell is a gyártás ésszerűsítésére jött létre és Magyarországon a lean-nel szemben, amely már elmozdult a szigorúan vett gyártás-támogatási alapokról, ez a metodika kevésbé tudott sikers lenni a nem termeléssel foglalkozó szférában.

Mivel a Six Sigmát idehaza egy multinacionális gyártóvállalat kezdte terjeszteni, és a szakemberek 80 százaléka - köztük jómagam is - ebből a műhelyből került ki, más irányzat pedig nem nagyon nevelt szakembereket, ezért nem sokat változott a módszer. Ez az "archaikus" Six Sigma azonban nem alkalmas a szolgáltató szektor gyorsan változó körülményeinek, kevésbé transzparens munkafolyamatainak a szabályzására. A gyártásban láthatóvá válik a termelés folyamata, a hibás, selejtes termékek mennyisége és a sorokon dolgozók leterheltségének hullámzása. De egy irodában virtuálisan folyik a munka, e-mailen, szervereken keresztül történik az információ-áramlás és a hiba sem jelentkezik rögtön. Gyártási szemléletű, mérnök végzettségű tanácsadók próbálják ezt a tradicionális Six Sigmát lenyomni a szolgáltató vállalatok torkán. Az eredmény pedig elégedetlenség lett, szinte minden esetben. A termék nevében a SWAT egyrészt rajtaütést, kommandót jelent, másrészt mozaikszó. (S) Six Sigmát, (W) waste elimination-t/veszteség megszüntetését, (A) applicable-t /alkalmazhatóságot és (T) teamwork-öt, csapatmunkát jelölnek a betűk.

- Mi az a változás, amit a LeanSWAT a korábbiakhoz képest nyújt?

- A legfontosabb talán a rugalmasság megjelenése. Mi egy 30 napos programot építettünk föl, szemben a többhónapos Six Sigma bevezetésekkel. Egy-egy 3 napos workshop, illetve tréning kapcsán megnézzük együtt, hogy milyen konkrét, fejlesztendő feladok várnak átalakításra. Fölrajzoljuk a SIPOC-ábrát, ezzel konkrét fókuszt adunk a folyamatnak. Ennek a munkának része a Gemba is, amikor beülünk például a call-centerbe és magunk tapasztaljuk meg a folyamatot. Ilyenkor adatgyűjtést végzünk, hogy lássuk, mi az, ami ténylegesen elcsúszott. Rengeteg ésszerűtlen folyamattal találkozunk.

- Hogy lehet azt megakadályozni, hogy a dolgozók még ebben a fázisban a programot ellehetetlenítsék? Ha egy call-center operátor mögé beül valaki, azzal a szándékkal, hogy az adott operátor munkáját megreformálja, automatikusan a leépítésre gondol a dolgozó.

- A felsővezetést felkészítjük arra, nehogy úgynevezett "kamikaze kaizen-t" kezdjen alkalmazni, vagyis ne az legyen a hozzáállás, hogy minél kevesebb emberrel működjön egy adott folyamat. A lean és a Six Sigma nem a leépítést segítő eszközök, hanem ezek segítségével a munkafolyamatokat lehet úgy optimalizálni, hogy a vevő elégedettsége nőjön. Ha a dolgozók biztosak abban, hogy a projekt végére jobb lesz a helyzetük, akkor támogatni fogják a törekvéseinket. Például, az egyik szolgáltató központban új árstruktúrát akartak 50 országban bevezetni, de az erőltetett értékesítési megállapodások keresztülvitele gyakorlatilag megbénította az alapfolyamatokat is. Olyan nagy lett a probléma, hogy négy hónapig számlázni se tudtak. Ezt a helyzetet 6 hét alatt oldottuk meg. Ráadásul, addig hat ember dolgozott lélekszakadva, most pedig három ügyintéző dolgozik úgy, hogy várják a nagyobb leterhelést. A több millió eurós számlázási restancia pár százezresre csökkent a LeanSWAT használatával és a vezetői támogatással.

- Hol lehet megtakarítani időt, a projekt bevezetése során illetve a lebonyolításakor?

- A LeanSWAT-ot nem kell bevezetni. Pont ez a lényege, a módszertan a "learning by doing" alapelvre épül, harminc napos ciklusokban működik és nem igényel különösebb felkészülést a megrendelő részéről. Alkalmazásakor elég egy kétnapos tréning és az azt követő három napos LeanSWAT Workshop. A workshopon a probléma definiálása után egy gyors módszerrel gyűjtünk adatokat és ebben a lépésben, a sávos folyamatábra kialakítását végezzük, aminek a kapcsán a hétféle veszteségtípust detektálni tudjuk és a rendelkezésre álló adatok alapján az akadályokat, a szűk keresztmetszeteket feltárjuk. A harmadik napon már priorizálunk és a következő 20 nap folyamán a megoldást implementáljuk. Legalább háromszor tesztelünk, finomítunk, vagy esetleg új javaslatot készítve a régit eldobjuk.

- Az érték-folyam térkép hol marad? Ez minden lean-es folyamatmenedzsment alapja, vagy tévedek?

- Mi azt tapasztaltuk, hogy a value stream maping folyamat nem ad annyit a projekthez, amennyi időt elvesz, ezért nálunk ez a lépés nincs a módszertanunkban. Tapasztalati tudást szereztünk arról, hogy két tanácsadó, rövid idő alatt az érték-folyam térkép készítés nélkül is meg tudja oldani a problémákat. Egyrészt, a több hétig tartó map-pelésre a szolgáltató szektornak nincs erőforrása. Nem lehet ilyen hosszú időre a dolgozókat kiemelni a munkavégzésből. Ráadásul, a cégek szempontjából nem költséghatékony a térképkészítést napi több mint 1000 eurós napidíjért két-két és fél hétig irányíttatni.

- Miből lehet akkor eredményes akciótervet készíteni, ha nem ábrázolják az érték-folyam térképet?

- Vannak használható adataink a gemba és a folyamat-térkép alapján. Természetesen, mivel többnyire hozzáadott értéket teremtő cégek veszik igénybe a szolgáltatásainkat, nem biztos, hogy mindent egyszerüen számosíthatunk. De, úgy gondolom, hogy még mindig jobb kevesebbet mérni, mint objektív adatok hiányában hibás vezetői döntéseket hozni. A probléma egyébként sokkal inkább a probléma definiálásánál jelentkezik, mint a mérés érvényességénél.

- Hogyan derítik ki, mi az igazi oka egy-egy problémának?

- Fontos, hogy egy lean bevezetéskor ne a legbonyolultabb folyamatokat próbáljuk először átvilágítani. Mindig az adott cég szabja meg, mit nézünk, milyen sorrendben. Sehol sincs átmásolható megoldásmód, mert mindegyik cégnek más-más a szempontja. Mi elsősorban nem statisztikai elemzéseket végzünk a Lean és Six Sigma világában kevésbé járatos cégeknél. A hipotézis tesztek sokszor elriasztják a kollégákat a folyamat-fejlesztésben való részvételtől. Mi ehelyett lean-szemüvegen keresztül vizsgáljuk a folyamatot. Megnézzük mekkora a baj nagysága, hol vannak a szűk keresztmetszetek, akadályok, selejtes munkafolyamatok. Ez így sokkal érthetőbb az adott területen dolgozók számára mint egy statisztikai elemzés. Fejlesztés során is azonnal adódnak a fejlesztési lehetőségek, ezekből rögtön javaslatot csinálunk és azokat válsztjuk ki, amelyekkel a leghamarabb a legnagyobb hatékonyság növelés érhető el. Ezek után az elfogadásra és a változás tratóssá tételére koncentrálunk.

A LeanSWAT lényege a gyorsan adott válasz. Az egyik raktárban a nyomtatást nem tudták megoldani, és csak ezért az egy tevékenységért át kellett egy másik emeletre járkálniuk. Kiderült, hogy egy IT-s beállítás miatt nem működött a rendszer, amit ezzel a módszerrel pár nap alatt kiderítettünk és orvosoltunk. A középvezető, aki a területért felelt, a napi "tűzoltással" foglalkozott. Neki nem tűnt föl, hogy az adminisztrátor naponta több kilométert lépcsőzött. Ez azonban havonta 3-400 ezer forintos veszteséget termelt, mert a kolléga a lépcsőházban ballagott a számlázás és a bevételezés menedzselése helyett. A sok, nem hatékony folyamatra jó példa az is, amikor logisztikai számlázást egy partnerünknél manuális adatfelvitellel oldottak meg. A beavatkozásunknak köszönhetően elektronikusan kapták a továbbiakban az adatokat és nem a gépeléssel kellett az adott adminisztrátornak foglalkoznia, hanem a fő tevékenységre figyelhetett, a kiszállításra.

- Milyen területeken használható a LeanSWAT?

- A legutóbbi projektjeink túlnyomó többsége raktározási, logisztikai területeken zajlott. De a másik, céges szempontból költség- és energia-igényes területen, az ügyfélszolgálatoknál is sokszor alkalmaztuk a LeanSWAT-t. Sokszor dolgoztunk a harmadik, erősen költségtermelő szervezeti egységeknél, az IT-nél is. Ma még sokszor azt gondolják a menedzsmentek tagjai, hogyha valamilyen folyamat hibás, akkor majd az IT leprogramozza. De ez nem így van. Az IT csak azzal tud valamit kezdeni, ami letisztult, rendbetett számokból áll. A kialakított struktúrát gépre lehet vinni, de ha csak a káoszt digitalizáljuk, attól nem lesz rend.

Segítettünk HR folyamatok rendbetételénél is. Ezen a területen azt a jellemző megközelítést találtuk, miszerint megbíznak minket egy olyan feladattal, amire a lean nem megfelelő eszköz. Például a fluktuáció csökkentését szerintem, nemcsak a folyamatok hatékonyságának, hanem a dolgozók elégedettségét növelő fejlesztésekkel kellene kezdeni. Általánosságban elmondható, hogy soha nem azt kell eldöntenie egy cégnek, hogy lean-t akar-e bevezetni, hanem az adott, hibásan működő folyamathoz kell megtalálni a megfelelő eszközt és ehhez ad a LeanSWAT bevezetése egy nagyon jó megoldást.

- A projektektől eltávolodva, visszanézve mekkora a projekt-elhalási arányuk?

- A Lean-Six Sigma bevezetések jelentős része magától elhal, átlagosan a projektek 10-15 százaléka valósul meg. Nálunk ez az arány 40 százalékos, ami jónak mondható. Kudarc ezen a területen nincs, mert rosszat tenni, a lean-elvből kiindulva nem lehetséges, csak kevésbé lesz jó az eredménye annak, amit csinálunk. Mivel hét éve foglalkozom a folyamatfejlesztéssel, látom, hol-miért haltak el a projektek. Ami fontos tényezője a sikeres lean-es bevezetésnek, az a céges kultúrába való beágyazottság. Ezért működünk együtt a Flow Csoporttal a LeanSWAT bevezetésekor, mert úgy láttam, ők tudják azt a fejlesztési környezetet megteremteni, amely a LeanSWAT elfogadottságát növeli. A sikeres projektnek része a támogató, hozzáértő vezetői réteg, akiknek a készségfejlesztését ezen a módon oldjuk meg. Azt is észleltük, hogy ha csak egyirányú a kommunikáció, amikor a lean-tanácsadó áll a táblánál és magyaráz, akkor az csak egy újabb papíron lévő tudás marad. Ha azonban a levonulás után tréningekkel megtámogatja, interaktívvá teszi a menedzsment a bevezetést, akkor élővé válik a folyamat-menedzsment.
  • 2020.02.20Készülj fel a 2020-as Munka törvénykönyve változására! Hogyan kell előkészíteni munkajogi szempontból a felmondást? Hogyan működhet jogszerűen az elektronikus munkaidő nyilvántartás? Milyen változások várhatók a Munka törvénykönyvében, az elfogadott uniós irányelvek tükrében? Milyen tanulságok vonhatók le a legújabb munkaügyi bírói gyakorlatból? Részletek Jegyek
  • 2020.02.20recruiTECH Idén minden eddiginél erősebb programmal, számos külföldi (IRL, UK, PL) és hazai előadóval indítjuk útjára a recruiTECH, 2020.02.20-i eseményünket! Várjuk szeretettel a toborzási szakma színe-javát, és mindenkit, aki felelősséget érez a tehetségek megtalálásában. Részletek Jegyek
  • 2020.03.31Vigyázz, jönnek az ellenőrök! Az ellenőrzésektől mindenki tart. Sok esetben azonban nem könnyű magunkat kiismerni a jogszabályok és az ellenőrzési folyamatok útvesztőjében. Ebben az eligazodásban szeretnénk segíteni olyan szakértőkkel, akik az ellenőrzések napi gyakorlatára látnak rá. Részletek Jegyek
Follow hrportal_hu on Twitter
További cikkek
Az egészség nem költség, hanem befektetés

Hosszú számsorokkal lehet bizonyítani, hogy az egészségtelenül élő munkavállaló alacsonyabb profitot jelent: közép- és hosszútávon is így van... Teljes cikk

Akkor is hagyni kell a kollégát dönteni, ha belegyalogol a pofonba

A vezetés kihívásairól, élethelyzetek által meghatározott igényekről, a cég értékeinek a dolgozók bevonásával történt meghatározásáról... Teljes cikk

Minőség vagy mennyiség?

Mondják, hogy megváltozott a munkaerőpiac - legalább ennyire fontos, hogy nemcsak a munkaerőpiac, de a munkaerő is alaposan megváltozott. Már... Teljes cikk