Mõni aeg tagasi kirjutasin artikli pideva parendamise ehk kaizeni 10 käsust. Olen viimased paar kuud saanud jälle parendusmeeskondadega “mürgeldada” ja mõtlesin mõningaid mõtteid ning tähelepanekuid jagada. Nagu ka kõik muu, peab ju ka pideva parendamise protsess pidevas arengus olema.
Rollide määratlemine ja teadmine
On väga oluline, et kõik teaksid oma rolle ning teaksid ka millises probleemi etapis keegi midagi tegema peab. Näiteks probleemi valiku ja täpsema määratlemise faasis pole mingit mõtet üritadagi teha meeskonnatööd. Siinkohal peab olema inimene, kes tuhnib andmetes, teeb Pareto diagramme, vajadusl mõõdab ning analüüsib andmeid.
See on ka see faas, kus on mõistlik käia protsessi ennast jälgimas – n.ö. jalutuskäik gemba’s. Gemba siis jaapani keeles “koht, kus luuakse väärtust”. Seda ei saa mingi suure saatjaskonnaga – sa pole Puff Daddy, kellel peab pidevalt mingi jõuk sabas tolgendama. Kui midagi üldse, siis see takistab sind – keerulisem on asjade toimimist omas loomulikus tempos jälgida, keerulisem on asjaosalistelt mõnd küsimust küsida ning tagatippu jääd kõigile ette ka veel.
Meeskond tuleb kaasa haarata siis, kui probleem on selge ning on vajada uurida probleemi juurpõhjusi. Meeskonda on vaja ka siis, kui juurpõhjuste hüpoteese on juba kontrollitud. Võimalik, et väiksemat osa meeskonda saab ka selleks kasutada, kuid üldiselt kiirus tuleb meeskonna väiksusest. Meeskonda on jälle vaja siis, kui on vaja leida lahendusi. Enne, pärast ja hiljem on veel mustmiljon tehnilist asja, mida aga meeskonnaga teha pole vaja.
Vali meeskond peale probleemi täpsustamist
Üks hea põhjus, miks ei saa panna meeskonda probleemi valima – enne probleemi püstitamist pole võimalik teada, kes on see meeskond kes selle lahendamisega kõige paremini hakkama saab. Probleemidel puuduvad organisatoorsed piirangud. Neid ei huvita osakonnad, divisjonid, vahetused jm selline.
Sellepärast ei saa sa ka teada milliste osakondade millised inimesed peaksid probleemi lahendama asuda, kui sa ei tea isegi milles probleem olema saab.
Ma proovisin kunagi teatud standardlahendusi – a’la tootmismeeskondade kaizen üritustel osales alati keegi hooldusmeeskonnast. See lähenemine oli enam-vähem ok, kuid meil oli ka üritusi, kus hooldusmees aknast välja vaatas ja kalal käimisest unistas. Lihtsalt probleemid olid seotud sisseostetud materjalidega vm taolisega, milles tal ei olnud midagi kaasa rääkida.
Enne pealehakkamist mõtle rahulikult läbi, keda see protsess puudutab ning maksimaalselt kiireks asjaajamiseks ürita erinevate osakondade inimesi juba varakult ühe laua taha tuua.
Koolita käigult
Ma olen teinud ka massiivseid koolitusprojekte, mille käigus räägitakse pikalt ja laialt kvaliteedijuhtimisest, lean’st, varieeruvusest ja tont teab millest veel.
See ei tööta.
Vähemalt pole see kõige efektiivseim moodus asjade ajamiseks, sest inimesed saavad liiga lühikese aja jooksul liiga palju ning siis ei suudeta murdosagi sellest ellu viia. Seejärel tuleb heitumine ning kogu koolitusel räägitu taandub 1-2 meeldejäänud lausele. Paremaks ei muutu midagi.
Reaalselt piisab meeskonnale 3-4 slaidist: Pareto diagramm. Mis asi on juurpõhjus. 5x miks juurpõhjuse analüüs metoodika. Ishikawa diagramm (kui tahad). Sa ei pea olema ilgelt vinge väljaõppega. Loe mu postitusi nendel teemadel ning sul on piisavalt, et oma ettevõttes miljoneid kokku hoida – tegelikult on see naeruväärselt lihtne.
Keerulisemate probleemide korral räägi põhjus-tagajärg maatriksist, ohjekaartidest, histogrammist, võib olla millestki muust veel. Aga situatsioon peaks tõesti need tööriistad sulle ette dikteerima – kui sa oled kergelt kinni jäänud. 80% probleemide puhul neid ka tegelikult väga vaja pole.
Järgmine osa
Järgmises osas ma räägin, kuidas inimesi kaasa töötama saada, kui palju peaks oma arenguid dokumenteerima, kuidas superstaare ära kasutada ning mida teha siis, kui probleemid oleks just nagu otsa saanud.