ÁLTALÁNOS ÉS IRÁNYÍTÁSI KÉRDÉSEK 1.2 2.1
A Hat Szigma projektek egyes szakaszaihoz kapcsolódó sajátos problémák és azok kezelése – 1. rész Tárgyszavak: Hat Szigma; minőségfejlesztés; minőségirányítás; minőségjobbítás; vállalati szervezés.
A Hat Szigma mint ciklikus eljárás A Hat Szigma módszerét alkalmazó projektek általában ötszakaszos ciklusból állnak (1. ábra). A gyártási és más folyamatok tökéletesítésére alkalmas eljárás jelentős hasznokat ígér, de sok buktatóval is jár. Mind az öt szakaszban lehetnek olyan speciális hibalehetőségek és problémák, amelyeket feltétlenül el kell kerülni vagy meg kell oldani, ellenkező esetben az egész projekt kudarcba fulladhat. Ezeket a veszélyforrásokat és a megoldási lehetőségeket legáttekinthetőbben talán egy gyártósor tökéletesítésének példáján keresztül lehet bemutatni. meghatározás (define)
szabályozás (control)
tökéletesítés (improve)
DMAICciklus
mérés (measurement)
elemzés (analyse)
1. ábra A Hat Szigma projektek ún. DMAIC-ciklusa
I. szakasz: meghatározás – a Hat Szigma projekt tisztázása A Hat Szigma projektekben általában az utolsó négy fázis (mérés, elemzés, tökéletesítés, szabályozás) kap hangsúlyt, a meghatározást viszont – mint valami felesleges rosszat – gyakran elhanyagolják. Ez azért súlyos hiba, mert az első fázis alapos és pontos megvalósítása a későbbi siker fontos feltétele. A projektmenedzsment feladatai egyértelműen ebben a szakaszban a legnehezebbek, nem utolsósorban azért, mert itt van szükség a legtöbb emberi kommunikációra.
Esetpélda Jól mutatja az elmondottakat annak az embernek az esete, aki a Hat Szigma gyakorlati alkalmazását egy konkrét projekttel kapcsolatban, projektvezetői minőségben tanulta. A projektben megoldandó feladatot az üzemvezető határozta meg: a felszerszámozási idők csökkentése egy gyártósorban. A projektvezető a munka során egy sor olyan hibát követett el, amelyek a gyakorlatban biztosan kudarcra ítélik a projektet. 1. hiba: elmaradt az ügyfél szempontjainak pontos azonosítása Az ügyfél és a projektvezető nézőpontjai közötti különbségek miatt előfordulhat, hogy a projekt nem az ügyfél valódi problémájára összpontosít. A jelen esetben, amikor az üzemvezető a felszerszámozási idő csökkentését jelölte meg feladatként, a projektvezetőnek kapcsolatot kell találnia a felszerszámozási idő mint műszaki mutató és az üzemvezető mutatószámai között. Megoldás Általában lényegesen egyszerűbb közvetlenül a feladatot meghatározó személy mutatószámaiból kiindulni, amely jelen esetben a felszerszámozás költsége volt. A mutatószámok elemzése révén biztosítható (pl. regresszióelemzéssel vagy affinitásvizsgálattal), hogy a munka az ügyfél valódi problémájára irányuljon. 2. hiba: a feladat megfogalmazása megoldási javaslatot tartalmaz A „Felszerszámozási idők csökkentése a gyártósorban” megfogalmazást közelebbről vizsgálva, kiderül, hogy itt nem egy projekt számára megfogalmazott problémáról van szó, hanem közelebbről nem meghatározott probléma megoldására vonatkozó javaslatról. Fennáll ezért annak veszélye, hogy a projektvezető olyan megoldással próbálkozik, amely
helytelennek bizonyul, és nem közvetlenül az üzemvezető problémájára irányul. Megoldás A problémát fel kell bontani az ügyfél elégedettsége szempontjából lényeges tényezőkre (critical to satisfaction). Ennek az eljárásnak az alapgondolata az, hogy az ügyfélnek alapjában véve csak három igénye van: mennyiség (critical to delivery), minőség (critical to quality) és költség (critical to cost). Ezt szem előtt tartva, a továbbiakban az első teendő az üzemvezető céljainak felosztása erre a három tényezőre, a következő feladat pedig a megoldási javaslat (felszerszámozási idők csökkentése a gyártósorban) vizsgálata abból a szempontból, hogy milyen hatása van az elégedettség kritikus tényezőire. Esetünkben a költség, pontosabban a felszerszámozás költsége bizonyult kritikus tényezőnek. Ezzel sikerült meghatározni az üzemvezető céljainak megfelelő igazi feladatot: a felszerszámozási költségek csökkentését. 3. hiba: az összefüggéseket leíró modell hiánya A projektvezető meghatározta már feladatát. A következő lépésben a megbízást adó üzemvezetővel közösen kijelölik a projekt célját, és kiszámítják az elérendő megtakarításokat. Itt leselkedik a következő veszély. Előfordulhat például, hogy a feltételek változása miatt a megtakarítások a vártnál kisebbek lesznek, vagy teljesen elmaradnak. Ha például időközben nő a termékváltozatok száma, automatikusan növekednek a felszerszámozási költségek is – a projekttel elért esetleges eredmények ellenére. Megoldás Ki kell dolgozni a gyártási folyamat összefüggéseit leíró modellt, amelynek segítségével vizsgálható a feltételek változásának hatása a projekt céljaira. Erre szolgál az ún. SIPOC-módszer (supplier, input, process, output, customer), amely a folyamatot térképszerűen ábrázolja, és tartalmazza annak összes lényeges elemét. Segítségével nyomon követhető, hogy milyen hatása van egy–egy tényező megváltoztatásának a rendszer többi elemére. 4. hiba: nem értékelték a projekt feltételeit Az összes eddigi információ sem elegendő azonban a projekt értékeléséhez. Elemezni kell a feltételeket is, elsősorban azok fontosságát. Az outputoknál, illetve az ügyfélnél jelentkező hatásokat a legjobb, illetve
a legrosszabb lehetőségek szempontjából szemlélve, két lehetőség van: vagy nem történik semmi, és akkor kiváló kiindulópontot sikerült találni a projekthez, vagy pedig az output és az ügyfél az inputoldalhoz hasonlóan viselkedik. Ebben az esetben olyan kontrolltényezőt sikerült felfedezni, amely a projekt szempontjából kritikus jelentőségű. Megoldás Az így nyert információk alapján felvázolható egy olyan diagram, amely az ügyfél várakozásai alapján elkülöníti és vizuálisan megjeleníti az egyes tényezőket. Az elkülönített tényezőkkel összeállítható a projekt számára egy ún. kockázatmátrix, és kidolgozhatók a kockázatokkal szembeni intézkedések. 5. hiba: nem tervezték az erőforrásokat A projekt meghatározását és a feltételek rögzítését ebben a stádiumban sokszor befejezettnek tekintik, elérkezettnek látva az időt a projekt elindítására. Legkésőbb a végrehajtó team első ülésén azonban kiderül, hogy sem a részvevőknek nincs elegendő idejük a feladatok végrehajtására, sem a szükséges erőforrások nem állnak rendelkezésre. Megoldás Az erőforrások tervezésekor abból kell kiindulni, hogy az összes teamtagnak hetente legalább nyolcórányi projektmunkát kell teljesítenie rendes munkája mellett. A teamtagok munkája mellett természetesen biztosítani kell a megfelelő gépi és egyéb kapacitást is. 6. hiba: elmaradt a projektvezető felelősségének egyértelmű rögzítése Gyakran úgy kezdenek el projekteket, hogy nem határozzák meg egyértelműen a felelősségek körét. Különösen súlyos hiba, ha nem rögzítik a projektvezető személyes felelősségét, mivel a vezető nélküli team tagjai egy idő után hátat fordítanak a projektnek. Megoldás Az Egyesült Államokban a projektszerződésekben világosan leszögezik, hogy a projekt sikeréért a projektvezető felelős, és ezért ő irányítja a teamet. A szerződést általában az üzemvezető és annak főnöke is aláírja, kötelezve magukat a projekt támogatására. A projektvezető aláírása a célok eléréséért való elkötelezettség biztosítéka, az ún. controlleré pedig a könyvviteli szabályok betartásának és a későbbi megtakarítások
elkönyvelésének biztosítéka. A szerződésben felsorolják a várt eredményeket és a team tagjait (név szerint). 7. hiba: elmaradt a nyitó megbeszélés Végzetes hibát követ el a projektvezető, ha az érintetteket nem értesíti arról, hogy megkezdődött a projekt. Az adott esetben az üzemek dolgozói ingerülten fogadnák, ha egyik főnökük egyszerre csak elkezdené mérni a felszerszámozási időket. Valószínűleg haladéktalanul értesítenék a szakszervezetet. Az adatgyűjtés és a folyamatok vizsgálata előtt tájékoztatni kell az érintett dolgozókat ezekről a tevékenységekről, ellenkező esetben olyan szintű ellenállás alakulhat ki (pl. a munkahely elvesztésétől való félelem miatt), amely a projekt sikerét is veszélyeztetheti. Megoldás A Hat Szigma stratégiája megköveteli a projekt elindítása előtti megbeszélés, ún. „kick-off meeting” megtartását. Ezen az összes érintettnek elmagyarázzák a projekt lényegét és céljait. A megbeszélésre a teamtagokon és közvetlenül érintetteken kívül meghívják a művezetőket, a szakszervezetiseket, a munkavédelmi felelősöket, a személyzetügyi vezetőket és másokat.
II. szakasz: mérés Miután az első szakaszban megtörtént a projekt műszaki és gazdasági céljainak meghatározása és a projektteam megszervezése, következik a mérés szakasza. Idő- és költségigényes folyamat ez, amelynek során a projektvezető és a team végig a projekt tárgyát képező folyamat közegében tevékenykednek. A továbbiak is a Hat Szigma módszerét tanuló projektvezető előző fejezetben elkezdett példán keresztül mutatják be a felmerülő problémákat. A team első ülésén elkészítették az ok–hatás, más szóval halszálkadiagramot, és a folyamatábrát, az ún. folyamattérképet. A halszálkadiagram célja a különböző hibalehetőségek elkülönítése, a folyamattérkép pedig az adatgyűjtési lehetőségek meghatározásában és a felesleges folyamatlépések megszüntetésében hasznos eszköz. 1. probléma: hiányzik a folyamat világos leírása Ez a hiba többnyire összetett folyamatokkal kapcsolatban lép fel, és általában időhiány az oka. A projektteam által elkészített vagy már eleve adott leírást sokszor nem vetik össze a valóságos gyártási folyamattal,
aminek az a következménye, hogy nem ismerik fel és nem küszöbölik ki a felesleges műveleteket. Ezzel kihasználatlanul marad a folyamat tényleges tökéletesítésének lehetősége. Megoldás A folyamat megfigyelésével vagy külső szakértők bevonásával végrehajtott auditálásával minden részletre kiterjedően mélyen és részletesen meg kell ismerni a gyártási folyamatot. 2. probléma: nincsenek műveleti utasítások A folyamattérképezés vagy az auditálás alapján megítélhető a folyamat működése, hatékonysága és reprodukálhatósága. Ilyenkor többnyire azonnal felismerhető, hogy az érvényes műveleti utasításokat (standard operative procedures) valóban alkalmazzák-e? A műveleti utasítások maradéktalan és állandó betartása szükséges ahhoz, hogy a projekt ne csak a problémának egy részét, hanem az egészet megoldja. Megoldás A Hat Szigma módszert tanuló projektvezető összehasonlította az előírt műveleti utasításokat a ténylegesen működő folyamattal, és megállapította, hogy nem sikerült megszüntetni minden hibalehetőséget. Megoldásként megbízható adatokat szavatoló és megismételhető műveleti utasításokat dolgoztak ki. A megismételt audit kimutatta, hogy most már adva van az összes műveleti lépés leírása, és azokat be is tartják. 3. probléma: az adatgyűjtés módja nem célszerű A mérés szakasza – a tökéletesítéssel együtt – a költségek keletkezésének fő forrása. Elsősorban az adatok előállítása a költséges tevékenység (programozás, idők rögzítése, mérőberendezések alkalmazása), ezért az adatokat a halszálkadiagramra épülő első hipotézisnek megfelelően célzottan kell gyűjteni. Szerencsés esetben használni lehet már meglevő adatokat is. Ebben az esetben azonban meg kell győződni arról, hogy az értékek valóban tükrözik a problémát, és nem szabad mért értékeket és mutatókat csak azért használni, mert azok kényelmesen elérhetők. Megoldás Kiindulási adatként mindig a folyamatparaméterekre vonatkozó mutatószámokat kell alkalmazni. Elővigyázatosan kell kezelni azokat a már
meglevő jelentéseket, amelyek adatforrásai nincsenek kellőképpen leírva vagy nem megismételhetők. 4. probléma: a mérőeszköz-vizsgálat fontosságának lebecsülése Mivel a Hat Szigma projektek kulcsjelentőségű tényezője a mérőeszközök hitelességének ellenőrzése, ezért az eszközök pontosságát, illetve a mérések reprodukálhatóságát – statisztikai eszközökkel – vizsgálni kell. Ha pl. a mérőeszköz szórása nagyobb, mint a folyamaté, akkor a folyamatban bekövetkezett változások esetleg nem ismerhetők fel, és szinte lehetetlen az egyes tényezők hatását meghatározni. Megoldás A mérőeszközök alkalmasságának vizsgálata rendkívül időigényes, ezért költséges művelet. Alaposan meg kell fontolni ezért, hogy milyen esetekben érdemes elvégezni. A folyamatok eredményeit mérő berendezéseket mindig ellenőrizni kell, mivel az itt elkövetett hibák később statisztikai úton nem ismerhetők fel. Más a helyzet a folyamatparamétereket rögzítő berendezések vizsgálatával: itt célszerű konzultálni a folyamatért felelős vezetővel, mivel a paraméterek mérésekor elkövetett hibák felismerhetők. Az adott esetben elegendő a felszerszámozási időket mérő rendszer ellenőrzése. 5. probléma: az adatok nem felelnek meg a hipotézisnek Sok Hat Szigma projektben vagy nem állítanak fel a hibaokokra vonatkozó hipotézist a későbbi vizsgálathoz, vagy pedig nincsenek meg a szükséges adatok. Ez különösen akkor okoz gondot, ha az adatok a projekt sikeréhez elengedhetetlenül szükségesek, és nincs mérőrendszer. Megoldás Ilyenkor csak ideiglenes mérőrendszer bevezetése lehet a megoldás. 6. probléma: az adatok helyes kiválasztása Az adatgyűjtés igen költséges dolog, különösen az ideiglenes mérőrendszerek kerülnek sokba. Megoldás Olyan szúrópróbát lehet alkalmazni, amely elég kiérlelt a folyamat viselkedésének előrejelzésére (pl. a folyamatok minősége, a megbízhatósági tartomány és a folyamat működésében bekövetkező változások).
Irányelvként megfogalmazható, hogy változó adatokhoz (mint pl. a felszerszámozási idő) 50 adatból álló állomány, az ún. minőségi vagy attributív adatokhoz (ilyen pl. a szerszámtörés) 250-es állomány szükséges. Az itt vizsgált projektben elegendőnek bizonyult 50-es szúrópróba alkalmazása, amely a felszerszámozási idő mellett tartalmazta az alkatrész bonyolultságára vonatkozó hipotézis paramétereit is. 7. probléma: nem határozták meg a kezdőpontot A projektvezető most már mindennel el van látva a következő szakaszhoz, az elemzéshez: jól ismeri a folyamatot, van hipotézise és rendelkezésére állnak a nyers adatok. Elvileg tehát megkezdhető az elemzés, előbb azonban rögzíteni kell a kiindulási helyzetet, amiről gyakran megfeledkeznek. Ez azért hiba, mert az utolsó fázisban, amikor a folyamat régi és új minősége közötti különbségből adódó megtakarításokat kell kiszámítani, nem állnak majd rendelkezésre a tökéletesítések előtti folyamatra vonatkozó adatok. Megoldás A folyamat minőségét az ún. Z-értékkel fejezik ki. Ezzel a mutatóval a folyamat mind a minőségi, mind a változó tulajdonságok tekintetében jellemezhető. Ha példánkban az adatfajta változóból (felszerszámozási idő percben kifejezve) minőségivé (előre megadott felszerszámozási idő betartása) alakul át, a Z-értékek segítségével még mindig adva van az összehasonlíthatóság. 8. probléma: nem értékelték a folyamat működését A projektvezető megállapította, hogy a folyamat az előírt tartományon kívül működik, így a projekt céljaként tökéletesítés jelölhető meg. El kell dönteni, hogy természetes szórású folyamatról van-e szó, vagy az eltérésért valamilyen fontos tényező felelős. Megoldás A kérdés eldöntésére alkalmas eszköz az ún. „szabályozás vagy technológia” diagram, amelyben a folyamat hosszú és rövid távú működését hasonlítják össze. A negyedekre felosztással megállapítható, hogy a probléma az alkalmazott technológiára vagy a folyamatirányításra vezethető-e vissza. Ha az utóbbi esetről van szó, akkor hagyományos DMAIC-projekt a megoldás (mint esetünkben). Ha viszont elsősorban az alkalmazott technológia a probléma forrása, akkor inkább DFSS (Design
for Six Sigma) projektet kell indítani. Ez utóbbihoz megfelelő beruházásra van szükség.
III. szakasz: elemzés Az eddigiekben sikerült rögzíteni a projekt célját, felmérték az üzemi környezetet és a szükséges erőforrásokat, létrehozták a projektteamet (meghatározás), illetve hipotézist állítottak fel a hibák lehetséges okairól, ellenőrizték a mérőrendszer pontosságát, végül pedig összegyűjtötték azokat az adatokat, amelyekre az elemzés fázisában van szükség a hipotézis vizsgálatához (mérés). Az elemzés során a hibalehetőségekre vonatkozó hipotézis vizsgálata mellett különböző szempontok és módszerek, pl. anyagárammenedzsment, raktármenedzsment és szűk keresztmetszetek elemzése alkalmazásával vizsgálják a gyártási folyamat egészét is. Ennek célja a folyamat egyszerűsítése és olcsóbbá tétele. Ebben a szakaszban a következő problémákra kell felkészülni. 1. probléma: hiányosságok a teamépítésben Az elemzés szakasza leginkább adatokra épülő folyamatauditra emlékeztet, ebből adódóan a felmerülő problémák is hasonlóak. Gyakoriak pl. a teamttagok és a folyamatért felelősek aggodalmai, például amiatt, hogy a folyamattal kapcsolatos problémák okai közül valamelyik éppen az ő területükön van, és ezt a statisztikai módszerek ki is fogják mutatni. Megoldás A projektvezetőnek meg kell teremtenie a bizalom légkörét. A projektben való részvételt feltétlenül honorálni kell. A kölcsönös bizalom kialakulására csak akkor lehet számítani, ha a team már keresztülment a teamek fejlődésének négy jellegzetes szakaszán: – a team létrehozása (forming), – a struktúrával és feladatokkal kapcsolatos konfliktusok fellépése (storming), – csoportszellem kialakulása (norming) és – a csoport egységes a kitűzött cél megvalósításában (performing). A projektvezetőnek gondoskodnia kell arról, hogy a team végigmenjen ezeken a fázisokon, és ne maradjon a projekt sikerét veszélyeztető rejtett konfliktus. A hiányos teamépítés egyik jellegzetes tünete, ha a folyamatért felelős vagy a folyamat tulajdonosa figyelmen kívül hagyja a statisztikai folyamatkiértékelés eredményeit.
2. probléma: hamisnak bizonyult a hipotézis A mérésben kidolgozott hipotézisből adódó adatállományt ki kell értékelni. Példánkban a felszerszámozási idő a vizsgálat tárgya, vagyis egy gép felszerszámozásához jelenleg szükséges idő összehasonlítva a művelet múltbeli idejével. A korábbi adatokat a folyamatfelelős kiértékelte, és úgy találta, hogy „a múltban minden jobb volt”. A következő lépésben a helyzetet statisztikai problémává fogalmazzák át. Az adott esetben a középértékek összehasonlítása a következőképpen fest: „felszerszámozási idő korábbi középértéke = felszerszámozási idő jelenlegi középértéke”. Az ily módon felállított hipotézisben tehát nincs különbség a két felszerszámozási idő között. Az adatok szignifikanciáját kétmintás Ttesztekkel kell értékelni. Így dönthető el, hogy elfogadható-e a fenti hipotézis. A hipotézis vizsgálatának harmadik lépése statisztikai megoldások kidolgozása, pl. megfelelő paraméterek értelmezésével, ami lehetővé teszi a folyamat működésére vonatkozó következtetések utólagos megfogalmazását. Esetünkben a paraméter (P-érték) nem szignifikáns, mert a kritikus érték (általában 0,5) felett van. Ez azt jelenti, hogy hipotézisünk (a régi és az új felszerszámozási idő megegyezik), elfogadható. Az utolsó lépésben a statisztikai eredményt visszavezetik a gyakorlatba. A felszerszámozási idő esetében el lehet vetni azt a feltételezést, hogy a folyamat az idővel számottevő módon romlott. Megoldás Ha rosszul választották meg a hiba lehetséges okát (esetünkben az időbeli lefolyást vizsgálták folyamatparaméterek – pl. megrendelésállomány vagy gyártási tételek nagysága – helyett), akkor nem a megfelelő adatokat gyűjtötték. Ennek következtében nem határozzák meg a probléma megoldásában felhasználható szignifikáns paramétereket. A problémamegoldás hatékony eszköze lehet az okok és hatások mátrixa. Ebbe a mátrixba a teamttagok a probléma egyes tényezői valószínűségének értékelését viszik be, és így az egyéni vélemények és nézőpontok mintegy közömbösítik egymást, a tartható hipotézis valószínűsége pedig nő. 3. probléma: oksági kapcsolat vagy merő egybeesés? A statisztikai megoldások gyakorlati megvalósítása maga is hibaforrás. A statisztika ugyanis X paramétert veti össze Y eredmény „viselke-
désével”. Előfordulhat, hogy egy jelentéktelen folyamatparaméter a folyamat eredménye tekintetében kritikus tényezőként viselkedik. Úgy tűnik, hogy szoros korreláció áll fenn, pedig a fizikai kapcsolat hiányzik – kb. úgy, mint a gólya és a baba között. Megoldás Az ilyen hamis korrelációk felfedezése érdekében célszerű a folyamat felelősével egyrészt előzetesen megvitatni a hipotézist, másrészt megítélni a kiértékelés eredményének elfogadhatóságát. Ily módon legalább két személy értékeli a statisztikát, de még jobb, ha az egész team részt vesz ebben. A projektvezető szakértői minőségben a statisztikát elemzi, a folyamatfelelős pedig megmagyarázza az adatok viselkedését. Csak a statisztikai eredményeknek a gyakorlatba való ilyen visszavezetése révén érhető el a projekttől a várt eredmény. 4. probléma: a problematikus terület célzott feltárása Ha kiderül, hogy nem a megfelelő adatokat gyűjtötték, vagy a hipotézis volt hamis, akkor vissza kell lépni a II. szakaszba, a méréshez. Új hipotézist kell felállítani és megfelelő adatokat gyűjteni. Megoldás A visszalépéshez nagy fegyelemre van szükség a projektvezető és a team részéről, mert a projekt számára előírt időkeret általában igen szűk. A projekt előrehaladását ezért mérföldkövek vagy ún. kapuk segítségével folyamatosan ellenőrizni kell. Ez többnyire szintén a projektvezető feladata, aki az elemzés fázisában a következő eszközöket alkalmazhatja ehhez: a hipotézis ellenőrzése, statisztikák és az azokból adódó paraméterek. Amennyiben a statisztikai paraméterek a kritikus értékhez képes szignifikánsnak bizonyulnak, akkor sikerült a visszalépés. Meghatároztak egy kritikus tényezőt, és megkezdődhet a projekt következő szakaszának feldolgozása. 5. probléma: hiányos az ellenőrzés a kapuknál A már említett kapuknál (vagy mérföldköveknél) azt ellenőrzik, hogy megvalósították-e a listán szereplő tevékenységeket, és betartották-e a projekt tervét. Sok tevékenységgel kapcsolatban előfordulhat, hogy a team a következő szakaszban azt állapítja meg, hogy a projekt okafogyottá vált (ilyen tevékenység pl. a kockázati tényezők rendszeres ellenőrzése). Esetünkben erre lenne példa többek között egy felszerszámozásigényes termék gyártásának megszüntetése (pl. áthelyezés követ-
keztében). A veszély ilyenkor a projekt megszüntetésének halogatása, és az ebből adódó felesleges erőforrás-felhasználás. 6. probléma: a vezetés jelenléte Általános szabály, hogy a projektre megbízást adó üzem- vagy vállalatvezetőnek tanácsos személyesen is részt vennie a kapuellenőrzésekben (gate-reviews), az elemzés fázisában azonban különösen fontos a jelenléte, mivel ilyenkor történik meg a folyamattal kapcsolatos probléma okainak megnevezése. A vezető személyes jelenléte nemcsak a team, hanem ő maga számára is fontos, mert már itt betekintést nyerhet a jövőbeli optimálási lehetőségekbe. Összeállította: Liebner Anikó Seufferlein, R.; Kaps, M.: Start in der Define-Phase. = Qualität und Zuverlässigkeit, 49. k. 5. sz. 2004. p. 47–48. Seufferlein, R.; Kaps, M.: Zur Sache in der Measure-Phase. = Qualität und Zuverlässigkeit, 49. k. 6. sz. 2004. p. 34–35. Seufferlein, R.; Kaps, M.: Etappenerfolg in der Analyze-Phase. = Qualität und Zuverlässigkeit, 49. k. 7. sz. 2004. p. 47–48.
