Sok fejlesztési ötlet első hallásra jól hangzik.
Csökkentsük a selejtet.
Gyorsítsuk fel a folyamatot.
Legyen kevesebb reklamáció.
Tegyük hatékonyabbá az adminisztrációt.
Rövidítsük le az átfutási időt.
Javítsuk a kommunikációt a területek között.
Ezekkel a mondatokkal önmagukban nincs baj. A gond ott kezdődik, amikor egy ilyen általános szándékot máris Lean Six Sigma projektnek nevezünk.
Pedig még nem az.
Egy jó Lean Six Sigma projekt nem attól jó, hogy fontosnak tűnik. Nem is attól, hogy sokakat zavar a probléma. Hanem attól, hogy egy üzletileg fontos kulcsfolyamathoz kapcsolódik, van mérőszáma, van célértéke, megfogalmazható a probléma, becsülhető a veszteség, és világos, milyen külső vagy belső vevői igény sérül.
Ebben segít a Lean Six Sigma projektalapító okirat.
Angolul gyakran project charternek nevezik. Magyarul használhatjuk rá a projektalapító okirat kifejezést. A lényeg azonban nem a dokumentum neve, hanem az, hogy már a projekt elején tisztázzuk: pontosan milyen problémán dolgozunk, miért fontos, mit akarunk elérni, kik vesznek részt benne, milyen eredményt várunk, és reálisan végrehajtható-e a feladat.
Személyes tapasztalatom szerint a fejlesztési projektek világában gyakran nagyjából ez a kép rajzolódik ki:
háromból egy projekt egyértelmű siker, egy egyértelmű kudarc, egy pedig valahol a kettő között marad.
A különbség sokszor nem a résztvevők szorgalmán, hozzáállásán vagy intelligenciáján múlik.
Hanem azon, hogy már az elején jól volt-e megfogalmazva a projekt.
A sikertelen vagy félsikeres projektek jelentős része nem a megvalósítás közben romlik el. Hanem sokkal korábban.
Már akkor, amikor a projektet kiválasztják.
Tipikus hiba, hogy a csapat túl nagy problémát akar megoldani. Ezt szoktam úgy nevezni: az óceánt akarjuk felforralni.
Ilyenkor a projekt címe jól hangzik, de kezelhetetlenül nagy:
„Javítsuk a termelés hatékonyságát.”
„Csökkentsük a veszteségeket.”
„Fejlesszük a belső kommunikációt.”
„Tegyük rendbe a minőségügyi folyamatokat.”
„Gyorsítsuk fel a teljes rendeléskezelést.”
Ezek fontos törekvések lehetnek, de Lean Six Sigma projektként túl szélesek. Nem látszik, pontosan hol kezdődik a probléma, hol ér véget, mivel mérjük, kinek fáj, és mikor mondhatjuk azt, hogy sikerült javítani.
A másik gyakori hiba, hogy a projektből hiányzik valamelyik alapvető elem:
Ha ezek közül akár csak egy is hiányzik vagy homályos, a projekt könnyen szétesik. A csapat sokat dolgozik, de nem biztos, hogy valódi üzleti eredmény keletkezik.
Nem véletlen, hogy a Six Sigma szakirodalomban a projektkiválasztás önálló kutatási téma. Egy International Journal of Lean Six Sigma folyóiratban megjelent szisztematikus irodalmi áttekintés 59 cikk alapján 111 különböző projektpriorizálási és projektkiválasztási módszert azonosított. Ez is mutatja, hogy a jó projekt kiválasztása nem adminisztratív részletkérdés, hanem a teljes fejlesztési program egyik kulcspontja.
A Lean Six Sigma projektalapító okirat a fejlesztési projekt induló dokumentuma.
De nem egyszerű adminisztráció.
Inkább döntési szűrő.
Segít eldönteni, hogy az adott téma valóban alkalmas-e Lean Six Sigma projektre, vagy csak egy fontosnak tűnő, de túl tág, túl homályos, nem mérhető vagy üzletileg gyenge fejlesztési ötlet.
A jó projektalapító okirat legalább ezekre a kérdésekre választ ad:
Ha ezekre nem tudunk válaszolni, akkor valószínűleg még nem projektünk van, hanem csak fejlesztési szándékunk.
Ez önmagában nem baj.
De nem szabad összekeverni a kettőt.
Egy Lean Six Sigma projektalapító okiratban sok információ szerepelhet, de van öt olyan elem, amely nélkül a projekt nagyon könnyen ingataggá válik.
Ezek a következők:
Nézzük meg ezeket részletesebben.
A projekt nem lóghat a levegőben.
Kapcsolódnia kell egy üzleti kulcsfolyamathoz.
Ez lehet például rendeléskezelés, ajánlatadás, gyártási előkészítés, gyártás, minőségellenőrzés, karbantartás, beszerzés, kiszállítás, reklamációkezelés vagy számlázás.
Azért fontos a kulcsfolyamat megnevezése, mert így a projekt nem általános szervezeti panaszból indul, hanem egy konkrét működési területből.
Nem azt mondjuk:
„Sok a káosz.”
Hanem azt:
„Az ajánlatadási folyamatban az ajánlatok átfutási ideje gyakran meghaladja a vállalt célértéket.”
Vagy:
„A végellenőrzési folyamatban az XY termékcsaládnál a forrasztási hibák aránya tartósan a célérték felett van.”
Ez már más minőségű kiindulópont.
Látszik, hol kell vizsgálódni.
Lean Six Sigma projektet nem érdemes pusztán érzésekre építeni.
Persze a tapasztalat fontos. A vezetői megérzés, az operátori visszajelzés, a vevői panasz vagy a napi tűzoltás mind jelezheti, hogy valami nincs rendben. De projektet akkor tudunk indítani, ha van valamilyen mérőszámunk is.
Ez lehet például:
A mérőszám mellé cél is kell.
Nem elég azt mondani, hogy „sok a hiba”. Azt kell látni, mihez képest sok.
Például:
„A célérték 2% alatti hibaarány lenne, de az elmúlt három hónapban az átlagos hibaarány 4,8% volt.”
Vagy:
„Az ajánlatadási célidő 3 munkanap, de az ajánlatok 42%-a ennél később készül el.”
Itt már megjelenik a probléma alapja: a teljesítmény nem éri el, vagy nem stabilan éri el a célértéket.
A projektkiválasztásnál ezért nem elég az, hogy „ez sokakat zavar”. A szakirodalom is hangsúlyozza, hogy olyan projekteket érdemes kiválasztani, amelyek jól definiáltak, és jelentős hatással lehetnek a vevői elégedettségre vagy az üzleti eredményre.
Fontos gyakorlati kérdés, hogy mennyire kell megbízhatónak lennie az adatnak.
Ideális világban minden mérőrendszerünk tökéletes lenne.
A valóságban ilyen ritkán van.
A gyártásban is találkozunk mérési bizonytalansággal, eltérő értelmezésekkel, hiányos adatgyűjtéssel, rosszul kitöltött mezőkkel, következetlen kategóriákkal. Adminisztratív folyamatokban ez még gyakoribb.
Ezért nem életszerű azt várni, hogy csak 100%-ban tökéletes adatokkal lehet fejlesztést indítani.
Sokszor már 80–85%-ban megbízható adatokkal is lehet valamit kezdeni, ha tisztában vagyunk a korlátokkal.
A kérdés inkább ez:
A projektalapító okiratban nem kell azt állítani, hogy az adat tökéletes.
De azt igenis tisztázni kell, hogy mire alkalmas, mire nem, és milyen óvatossággal használjuk.
A probléma nem ugyanaz, mint a megoldás hiánya.
Nem problémafelvetés az, hogy:
„Nincs új szoftverünk.”
„Nincs elég emberünk.”
„Nem vezettük még be az 5S-t.”
„Nem használunk automatizált riportot.”
„Nincs új ellenőrző sablonunk.”
Ezek lehetnek megoldási ötletek vagy feltételezett okok, de nem biztos, hogy maga a probléma.
A Lean Six Sigma projektalapító okiratban a problémát abból kell levezetni, hogy egy mérőszám nem, vagy nem stabilan éri el a célértéket.
Például:
„Az XY termékcsalád végellenőrzésén a forrasztási hibák aránya az elmúlt három hónapban átlagosan 4,8% volt, miközben a célérték 2,5% alatt lenne.”
Ez már probléma.
Látszik benne:
Innen lehet továbbmenni a gyökérokok felé.
De először a problémát kell pontosan megfogalmazni.
A Lean Six Sigma projekt nemcsak szakmai gyakorlat. Üzleti kezdeményezés is.
Ezért a projektalapító okiratban már az elején meg kell jelennie a várható megtakarításnak vagy üzleti hatásnak.
Minimum naturáliában.
Például:
Ezek már értelmezhető veszteségek.
De ha lehet, a megtakarítást pénzben is érdemes kifejezni, méghozzá évesített formában.
A menedzsment ugyanis ezt érti.
Nem azért, mert ne érdekelné őket a szakmai rész. Hanem azért, mert dönteniük kell erőforrásról, időről, prioritásról, emberekről és támogatásról. Ehhez látniuk kell, hogy a projekt nagyságrendileg milyen üzleti hatással járhat.
Egy projektalapító okiratban ezért nem baj, ha a pénzügyi becslés kezdetben még közelítő.
De legyen ott.
Mert ha egy projekt várható hatása nem becsülhető legalább nagyságrendileg, akkor nehéz eldönteni, megéri-e elindítani.
Van egy egyszerű, de gyakran elfelejtett szempont.
A probléma megoldására fordított idő és erőforrás ne legyen aránytalanul nagy ahhoz képest, amekkora veszteséget maga a probléma okoz.
Ha egy probléma havonta egyszer fordul elő, alkalmanként 10 perc veszteséget okoz, akkor nem biztos, hogy érdemes rá többhetes Lean Six Sigma projektet indítani.
Tegyük fel, hogy egy kisebb adminisztratív hiba havonta egyszer jelentkezik, és alkalmanként 10 perc javítást igényel. Ez évente 120 perc, vagyis 2 óra. Öt év alatt 10 óra.
Ha erre a problémára egy csapat 80–100 munkaórás projektet indít, akkor könnyen előfordulhat, hogy a megoldásra fordított idő nagyobb lesz, mint a probléma által okozott veszteség.
Ez nem jelenti azt, hogy kis problémákkal nem kell foglalkozni.
Csak azt jelenti, hogy a módszert és a projektméretet a probléma nagyságrendjéhez kell igazítani.
Van, amire elég egy gyors kaizen.
Van, amire elég egy standard módosítása.
Van, amire elég egy vezetői döntés.
Van, amire valóban Lean Six Sigma projekt kell.
A projektalapító okirat egyik szerepe éppen az, hogy ezt segítsen eldönteni.
Egy fejlesztési projekt akkor erős, ha világos, milyen vevői igényt érint.
Ez lehet külső vevői igény:
De lehet belső vevői igény is:
Ha nem tudjuk megmondani, kinek fáj a probléma, akkor könnyen előfordulhat, hogy nem valódi üzleti problémát kezelünk, hanem csak valakinek a kellemetlen érzését.
A kellemetlen érzés is lehet fontos jelzés.
De Lean Six Sigma projekt akkor lesz belőle, ha meg tudjuk mutatni, milyen vevői igény sérül, milyen mérőszám romlik, és milyen veszteség keletkezik.
Az alábbi táblázat összefoglalja a legfontosabb elemeket.
| Elem | Mit kell tisztázni? | Miért fontos? |
|---|---|---|
| Üzleti kulcsfolyamat | Melyik fő folyamat teljesítményét érinti a probléma? | Ne elszigetelt tünetet javítsunk, hanem üzletileg fontos működést. |
| Mérőszám | Mivel mérjük a teljesítményt? | A projektnek mérhető problémából kell indulnia. |
| Célérték | Mihez képest gyenge vagy instabil a jelenlegi teljesítmény? | Célérték nélkül nem tudjuk, mit jelent a javulás. |
| Probléma | Mi történik, ha a mérőszám nem vagy nem stabilan éri el a célértéket? | A projekt nem megoldásból, hanem pontos problémából indul. |
| Adatmegbízhatóság | Elég jó-e az adat a döntéshez és követéshez? | Nem kell tökéletes adat, de teljesen bizonytalan adatra nem építhető jó projekt. |
| Vevői igény | Milyen külső vagy belső vevői elvárást érint? | A fejlesztésnek értéket kell teremtenie valakinek. |
| Megtakarítás naturáliában | Milyen veszteség csökken: idő, várakozás, keresés, érintések száma, selejt, újramunka? | Láthatóvá teszi a probléma nagyságrendjét. |
| Évesített pénzügyi hatás | Mekkora az éves szintű becsült megtakarítás? | A menedzsment ezt érti, és ez segíti a priorizálást. |
| Hatókör | Mi tartozik bele, és mi nem? | Megakadályozza az óceán forralását. |
| Csapat | Kik vesznek részt a projektben? | A jó projekt keresztfunkcionális együttműködést igényel. |
| Folyamattulajdonos | Ki felel a folyamat működéséért? | A fejlesztésnek be kell épülnie a működésbe. |
| Dolgozói részvétel | Jelen van-e az, aki ténylegesen működteti a folyamatot? | A valós működést azok ismerik legjobban, akik naponta benne dolgoznak. |
| Projekt szponzor | Ki biztosít vezetői támogatást? | Akadályelhárításhoz és döntésekhez szükséges. |
| Elfogadás | Kik írják alá a projektalapító okiratot? | Amihez a nevünket adjuk, ahhoz nagyobb az elköteleződés. |
Ez elsőre soknak tűnhet.
De nem az a cél, hogy hosszú dokumentumot írjunk.
Hanem az, hogy a projekt indulásakor ne maradjanak homályban azok a kérdések, amelyek később kudarcot okoznának.
A projektalapító okirat egyik legfontosabb része a jól megfogalmazott problémafelvetés.
Ebben sokat segít az 5W2H gondolkodás:
Nem az a cél, hogy ezeket mechanikusan felsoroljuk.
Hanem az, hogy egy jól szerkesztett, összetett mondatban vagy rövid bekezdésben világosan megfogalmazzuk a projekt kiindulópontját.
Például nem így:
Sok a forrasztási hiba, ezért javítani kell a folyamatot.
Hanem inkább így:
Az XY termékcsalád végellenőrzési folyamatában az elmúlt három hónapban a forrasztási hibák aránya átlagosan 4,8% volt, miközben a célérték 2,5% alatt lenne; ez heti szinten átlagosan 18 óra újramunkát, késedelmes kiszállítási kockázatot és többletterhelést okoz a minőségügyi, termelési és logisztikai területek számára.
Ez már sokkal jobb problémafelvetés.
Tartalmazza a kulcsfolyamatot, a mérőszámot, a jelenlegi értéket, a célértéket, az időtávot, a veszteséget és az érintett belső vevőket.
Innen már lehet SMART célt megfogalmazni.
Sokan összekeverik a célt és a célállapotot.
A cél általában azt mondja meg, mit akarunk elérni.
A célállapot azt mutatja meg, számszerűen hogyan fog kinézni az elért állapot.
Például:
Cél:
Csökkenteni szeretnénk az újramunka mennyiségét az XY termékcsalád végellenőrzési folyamatában.
Ez érthető, de még nem elég pontos.
Célállapot:
A forrasztási hibák aránya három hónapon belül 4,8%-ról 2,5% alá csökken, miközben a mérés azonos adatforrásból, heti bontásban történik.
Ez már kvantitatív.
Van benne kiinduló érték, célérték, időtáv, mérési logika és hatókör.
A SMART cél nem önmagában lebeg a levegőben. A jó SMART célt a problémafelvetésből vezetjük le.
Ha a problémafelvetés gyenge, a cél is gyenge lesz.
Ha a problémafelvetés pontos, a cél szinte adja magát.
A jó Lean Six Sigma projekt nem túl kicsi, de nem is kezelhetetlenül nagy.
Olyan feladatot érdemes keresni, amely reálisan végrehajtható egy 3–5 napos Lean Six Sigma kaizen workshop, vagy egy 1–2 hónapos projekt keretében.
Ez nem azt jelenti, hogy minden problémát ilyen rövid idő alatt teljesen meg lehet oldani.
De azt igen, hogy a projekt hatókörét úgy kell meghatározni, hogy a csapat belátható időn belül eredményt tudjon felmutatni.
A túl nagy projekt egyik jele, hogy minden beletartozik.
„A teljes termelés hatékonyságát javítjuk.”
„A teljes adminisztrációs folyamatot átalakítjuk.”
„A vállalati kommunikációt fejlesztjük.”
„Minden reklamációt csökkentünk.”
„Az egész raktári működést rendbe tesszük.”
Ezek gyakran nem projektek, hanem programok.
A Lean Six Sigma projektalapító okiratnak segítenie kell abban, hogy a nagy problémát kezelhető részre bontsuk.
Például:
Nem:
„Csökkentsük a raktári keresési időt.”
Hanem:
„Csökkentsük az A zónában a gyártáshoz gyakran használt segédanyagok átlagos keresési idejét műszakonként 42 percről 20 perc alá két hónapon belül.”
Nem:
„Javítsuk a reklamációkezelést.”
Hanem:
„Csökkentsük az XY vevőhöz kapcsolódó ismétlődő dokumentációs reklamációk számát havi 12 esetről havi 4 eset alá három hónapon belül.”
Nem:
„Legyen jobb a meetingkultúra.”
Hanem:
„Csökkentsük a heti termelési státuszmeeting átlagos időtartamát 75 percről 45 percre, miközben a döntéssel záruló napirendi pontok aránya legalább 80% legyen.”
A különbség óriási.
Az első változatok irányokat jelölnek.
A második változatok már projektszerűen kezelhetők.
A projektalapító okiratot nem érdemes egy embernek magányosan megírnia az irodában.
A jó projektalapító okirat keresztfunkcionális egyeztetés eredménye.
Legalább három szereplőnek szinte mindig ott kell lennie:
Emellett szükség lehet minőségügyre, termelésre, logisztikára, karbantartásra, pénzügyre, HR-re, IT-ra vagy más támogató területre is, attól függően, milyen problémáról van szó.
Azért fontos a keresztfunkcionális csapat, mert a problémák ritkán állnak meg egy osztály határánál.
A hiba sokszor az egyik területen keletkezik, a másikon derül ki, a harmadikon okoz többletmunkát, és a vevőnél válik igazán fájdalmassá.
Ha csak egy nézőpontból írjuk meg a projektalapító okiratot, könnyen félremegy a fókusz.
A projektalapító okirat elfogadása aláírással zárul.
Ez elsőre formalitásnak tűnhet.
Pedig nem az.
Amit aláírunk, ahhoz a nevünket adjuk.
Ez más elköteleződési szintet jelent, mint amikor egy meeting végén valaki annyit mond:
„Jó, akkor ezzel majd foglalkozzunk.”
Az aláírás segít tisztázni, hogy:
Természetesen az aláírás önmagában nem garantálja a sikert.
De nélküle könnyebb kibújni a felelősség alól.
Egy jó Green Belt képzés nem ott kezdődik, hogy a résztvevők megtanulják a statisztikai eszközöket.
Hanem ott, hogy van egy jól kiválasztott, jól körülhatárolt, mérhető projektjük.
Ha a projekt gyenge, a képzés is könnyen elméleti marad. A résztvevő megtanulhatja a DMAIC lépéseit, a Pareto-diagramot, az ok-okozati elemzést, a folyamatképesség alapjait vagy a kontrollterv szerepét, de ha nincs mögötte valós, üzletileg fontos probléma, akkor az egész nehezen épül be a vállalati működésbe.
Ha viszont a képzés előtt vagy a képzés elején elkészül egy jó projektalapító okirat, akkor a tanulás rögtön kapcsolódik a valós munkához.
A résztvevő nem általános példákon gondolkodik.
Hanem a saját folyamatán.
A saját mérőszámán.
A saját veszteségén.
A saját belső vagy külső vevői igényén.
Ezért a projektalapító okirat nemcsak projektmenedzsment-dokumentum.
Hanem tanulási eszköz is.
Segít abban, hogy a Lean Six Sigma képzésből ne csak tantermi tudás, hanem üzleti eredmény szülessen.
A projekt sikere nemcsak a módszertani tudáson múlik. Egy 62 lezárt Lean Six Sigma projektet vizsgáló tanulmányban a projekt sikerét többek között ahhoz kötötték, hogy elérte-e a kitűzött célt és a kezdetben meghatározott KPI-okat. A kutatás szerint a kritikus sikertényezők — például a governance, a teljesítménykövetés, a szponzoráció, az érintettek bevonása és a jól meghatározott hatókör — szignifikáns kapcsolatban álltak a projekt sikerével.
A Lean Six Sigma projektalapító okirat célja nem az, hogy még egy dokumentummal terheljük a szervezetet.
A cél az, hogy ne induljunk el rossz projekttel.
Ne akarjuk az óceánt felforralni.
Ne kezdjünk mérhetetlen problémába.
Ne dolgozzunk olyan témán, amelynek nincs világos vevői igénye.
Ne indítsunk többhetes projektet olyan veszteségre, amely öt év alatt sem okoz akkora kárt, mint amennyi időt a megoldására fordítanánk.
És ne nevezzünk Lean Six Sigma projektnek egy olyan ötletet, amelyből hiányzik a kulcsfolyamat, a mérőszám, a cél, a probléma, a megtakarítás vagy a vevői igény.
A jó projektalapító okirat ezzel szemben fókuszt ad.
Segít megérteni, hol van a probléma, miért fontos, mennyibe kerül, kit érint, mit akarunk elérni, és kik vállalják a megvalósítást.
Egyértelművé teszi, hogy a projekt nem pusztán jó ötlet, hanem közösen vállalt, mérhető, üzletileg értelmezhető fejlesztési kezdeményezés.
Sok Lean Six Sigma projekt sikere vagy kudarca már itt eldől.
Még azelőtt, hogy a csapat elkezdené az adatgyűjtést, az elemzést vagy a megoldások keresését.
Ha vállalatánál Lean Six Sigma Green Belt képzésben vagy projektalapú folyamatfejlesztésben gondolkodik, érdemes nemcsak a tananyagot előkészíteni, hanem a lehetséges projektötleteket is.
Egy jó projektalapító okirat segít eldönteni, melyik ötletből lehet valódi projekt, melyikből inkább kaizen feladat, melyikhez vezetői döntés kell, és melyikkel nem érdemes most foglalkozni.
A Lean Six Sigma akkor működik igazán, ha nem az óceánt akarjuk felforralni, hanem olyan problémát választunk, amely fontos, mérhető, kezelhető és üzletileg is értelmes.
Ha szeretné gyakorlatiasan tanulni a folyamatfejlesztést, akkor jelentkezzen kihelyezett Lean Six Sigma Green Belt képzésünkre, vagy kezdheti a tanulást önállóan a Magyar Minőség Szakirodalmi Díj 2019 elismerésben részesült A Lean Six Sigma folyamatfejlesztés kézikönyvvel.
Viszont, ha úgy érzi erre most még nincs ideje, akkor ajánlom legújabb Fókuszálj, vagy sodródj! című könyvem, ami mini PDCA fejlesztés keretében segít időt teremteni arra, hogy a sürgős feladatok ne szorítsák ki a fontosakat.
Melyik Lean Six Sigma könyv segít most Önnek? Három könyv, egy fejlesztési út: hibák felismerése, vezetői fókusz és adatalapú folyamatfejlesztés.
A Fókuszálj, vagy sodródj! nem egyszerű időgazdálkodási könyv, hanem PDCA-alapú fókuszállítási útmutató vezetőknek és leanszakembereknek. A könyv abban segít, hogy ne csak reagáljon a sürgős ügyekre, hanem tudatosabban irányítsa saját idejét, figyelmét és csapata fókuszát.
Sok Lean Six Sigma projekt már az elején eldől. A projektalapító okirat nem adminisztráció, hanem döntési szűrő: segít elkerülni, hogy túl nagy, túl homályos vagy üzletileg gyenge projektbe kezdjünk.
Kiemelt kép alt szöveg: Lean Six Sigma projektalapító okirat és projektindítás üzleti kulcsfolyamatok alapján
Jelentkezzen lean six sigma green belt képzésünkre, amelynek alapja a Magyar Minőség Szakirodalmi Díj 2019 elismerésben részesült A lean six sigma folyamatfejlesztés kézikönyve. A képzés oktatója pedig a könyv szerzője Fehér Norbert 17 év lean six sigma tapasztalattal és 500+ mentorált, vezetett projekttel.
Rövid, gyakorlatias levelekben végigvesszük a PDCA gondolkodást, a legfontosabb veszteségforrásokat, a fejlesztési problémák kiválasztását, valamint azt is, mely módszerek és szakmai anyagok segíthetnek a következő lépésben.
