RSS
 

Posts Tagged ‘defineerimine’

Teadmised on kasutud?

29 Mar

Six sigma, defineerimineTeadmised on peaaegu kasutud. Paremini sõnastatult – uute teadmiste lisamine või olemasoleva info kvaliteedi tõstmine ei pruugi sind palju aidata.

Erinevadsignaalid refereerivad teadmusjuhtimise konsultandi artiklit, mille põhilised sõnumid on:

  • Teadmistest on üksnes niipalju kasu, kuivõrd nad aitavad teha paremaid otsuseid,
  • Inimestel on üldiselt kalduvus pikemalt mõtlemata tormata probleeme lahendama,
  • See mis loeb, on arusaamine, teadlikkus asjade olemusest.

 

Lean Six Sigma avastas selle esimesena!

Tegelikult me räägime vähemalt vormiliselt erinevatest asjadest, ma saan sellest aru. Sisulise poole pealt vaadates aga pole asjad nii erinevad. Räägime korraks DMAIC probleemide lahendamise või siis ka parendamise tsüklist. Maakeeli tähendab see peen lühend

defineeri -> mõõda -> analüüsi -> parenda -> kontrolli”.

See ei ole loomulik

Mingisuguse võõrapärase ja veidra nimega tsükli kasutamine pole loomulikult inimesele looduse poolt kaasa antud. Loodus ütles ürginimesele, et kui sul on probleem, näiteks 2 meetri kaugusel olev mõõkhambuline tiiger, siis pussita teda kiviodaga. Defineerida ja planeerida jõuab siis, kui lõkke ääres kintsu küpsetad.

Kivioda on hea tööriist

Probleem kiviodaga on lihtsalt see, et meie probleemid on muutunud keerukamaks. “Oda pihku ja võitlusesse” ei tööta enam, sest maailm on muutunud keerulisemaks ning moodsas organisatsioonis isegi murdosa võrra oma ärist paremini arusaamine võib rahaliselt maksta miljoneid. Sa võid olla makse saaja või makse tegija, valik on sinu.

Probleemi defineerimine on peaaegu sama, mis teadlikkus

Defineerimise faas lean six sigma‘s ei ole mingi mulliajamine. Vastupidi, see on väga konkreetsete tegevuste kogum, mõistmaks asja olemust kogu tema ilus. See on otsimisprotsess, mis peab vastama küsimustele:

  • Milles on probleem? – sõnasta probleem keskendudes ainult sümptomitele. Liiga vara on mõelda põhjustele ja lahendustele. Selle postituse raames olgu probleemiks “langevad müügitulemused” ja vaatame, kuhu me nendega jõuame. Mida spetsiifilisemalt on probleem määratletud seda parem. A’la “Toote1 müük on olnud languses viimased 10 kuud, keskmine kahanemistempo 4% kuus. Selle trendi jätkumisel on toote1 kasumlikkus 6 kuu pärast 0 ja sealt edasi läheb kahjumisse.”  Pikk ja lohisev aga peaks kõigile asja selgeks tegema.
  • Kuidas see probleem firmat, ettevõtet mõjutab? “Kui me seda langustrendi ei muuda, siis 12 kuu pärast on terve firma kahjumis”.
  • Keda see probleem mõjutab? Inimesed, meeskonnad, huvigrupid – mida see probleem nende jaoks tähendab? Kuidas ja kui palju nemad protsessi mõjutavad? Mõtle läbi, kuidas sa nendega suhtled ja mis nende huvi selle probleemi valguses on?
  • Milliseid protsesse me vaatlema hakkame? Inimeste (või ka osakondade) ja protsesside määratlemine võib olla keerulisem, kui esialgu tundub. Mis siis kui langevates müügitulemusi mõjutab kõige enam tarneprotsessi ebakindlus? Mis siis, kui meie turundus olemasolevate klientide suunal on pigem nõrgavõitu?
  • Projekti ulatus? Kiusatus on lahendama asuda Somaalia näljahädaga sarnanevaid globaalseid probleeme. Kui sa korraga üritad parendada tarnekindlust, müügimeeste väljaõpet, klienditeeninduse järelmüüki ja juriidilisi probleeme, siis sa oled võtnud oma taldrikule rohkem, kui süüa jõuad. Piira ja fokusseeri. Pareto diagramm, wink-wink.
  • Eesmärgi püstitus? Mis ajaks peavad tulemused tulema? Näidet vaadates peaks hiljemalt poole aasta pärast trend olema “murtud” ja müük peaks eelneva kuuga võrreldes kasvama hakkam. Kui suur peaks kasvutempo aga olema? Sõltub paljuski, kuidas tajutakse turgu ning potentsiaali. Pikemalt ma SMART eesmärkidest rääkima ei hakkaks,
  • Projekti meeskonna liikmed? Kellega sa hakkad probleemi lahendama? Kas huvigrupid on esindatud? Kui ei ole, siis kuidas ja millal sa nemad kaasad? Sul ei ole mõtet ajama meeskonda suuremaks kui 5-6 inimest. Sellest suuremad grupid ei jõua kuigi kiiresti edasi, väiksemad grupid võivad jääda liiga üheülbaliseks.
  • Kes on kliendid ja mis on nende nõudmised? Voice of the customer on üks kvaliteedijuhtimise olulisemaid märksõnu. Kes on sisemised, kes välised kliendid? Kuidas me mõõdame kliendinõudmiste täitmise määra? Millised üldse on kliendinõudmised? Toote-teenuse puhul on kliendi nõudmiste kaardistamiseks mõistlik kasutada näiteks Kano mudelit.Klientide identifitseerimine meie näite puhul on üsna mitmeti mõistetav – ühelt poolt suurendatakse ettevõtte kasumlikkust ja seega nagu oleks lõppklient ettevõte omanikud. On nad seadnud eesmärke kasumlikkusele või selle saavutamise viisidele? Vahest on need toodud kui missioon, visioon, väärtused + perioodilised eelarvestamise ja eesmärgistamise dokumendid. Klient võib olla ka kogu töötajaskond – kui müük ei suurene, siis võib keegi tööst ilma jääda.
  • Tee SIPOC diagramm. See on selles mõttes kasulik diagramm, et aitab hoida kogu teadmist protsessi kohta fokusseeritult ühel lehel. Piltlikult öeldes – sa tead, mida sa tead.

 

Kui kaua kõigile neile küsimustele vastuse leidmine võiks aega võtta? Katsu 0,5-2 päevaga hakkama saada, vastasel korral pead projekti ulatust piirama, sest oled liiga suure tüki võtnud. Kas sellisest infokogumisest on kasu paremate otsuste tegemisel?

Absoluutselt – ainuüksi nende asjade ülestähendamiseks pead sa kõigi osapooltega suhtlema (sh klientidega). Sa saad suurepärase aimduse oma meeskonnast – kes on sinuga, kes on sinu vastu. Ideaalis saad ka aru, miks nad vastu on – mida see probleem nende jaoks tähendab? Kas nad üldse tajuvad probleemi olemasolu?

Defineerimisest üksi jääb väheks, kuid on väga raske teha kvaliteetset otsust probleemist korralikult aru saamata.

Kuidas sulle tundub?

Sarnased postitused:

 

Kuidas probleemi defineerides leida firmale 1+ miljonit EEK’i.

22 Jan

Oma kogemuse põhjal julgen väita, et suudaksin igas ettevõttes, kus mitte kunagi pole kulude peale teadlikult mõeldud, vähendada ressursside kulu suuremate probleemideta poole aastaga kuni 50%. Ettevõttes, kus aeg-ajalt on teemale tähelepanu pööratud, võiks oodata tulemust 5-20%. Rahalises mõttes võib see tähendada kümneid tuhandeid või ka miljoneid kroone aastas. Seksikas.

Minu esimene katsetus kuue sigmaga sündis lähteülesandest vähendada drastiliselt kulusid. Kasutades Paretot diagrammi tundus kõige mõistlikum olevat keskenduda ühele suurimale kuluallikale – veekulu. Taustainformatsiooni niipalju, et ettevõttes oli sertifitseeritud keskkonnajuhtimise süsteem toiminud juba 10+ aastat ning oli ka päriselt hoitud toimivana.

Probleemi defineerimine

Asja kallale – veesüsteem oli küllaltki keeruline, kuid mitte kindlasti mitte kõige keerukam asi maailmas. Igatahes päris umbes ja puusalt tulistades ei tundunud kulude vähendamine selles süsteemis võimalik ning proovisin läheneda DMAIC lähenemisega. Esimene samm: defineerimine. Probleemi defineerimine kuue sigma maailmas koosneb:

  • Projekti ülevaate (project charter) kirjutamine. Selle koostamine on küllaltki lihtne, kuid aitab sul edaspidi säilitada fookust. Samamoodi abistas see ühtlase info andmisel kõigile asjaosalistelesee on väga oluline.
  • Kinnita probleem ja eesmärgid. Peamine küsimus siinkohal on, kas probleem on päriselt ka olemas, kas ta on olulie ärile ja sise- või välisklientidele. Minu jaoks oli siinkohas probleemi defineerimine läbi erinevate vaatenurkade kõige põnevam. Äri seisukohalt on väga lihtne öelda, et kasumi suurendamine on oluline aga miks? Kasumile muu funktsiooni leidmine kui bosside suuremad boonused on ülioluline hiljem, kui meeskonnale vaja probleem “maha müüa”. Arvesta ka sellega, et leiad hoopis rohkem huvigruppe kui alguses üldse oodata oskasid – neil kõigil on probleemist omamoodi arusaam ja ka erinevad eesmärgid.
  • Kontrolli üle võimalik rahaline võit. Kindlasti on olemas mingisugune pinnapealne finants- ja operatsiooniline informatsioon, mille põhjal sa saad teha mingeid esialgseid oletusi. See on oluline sellepärast, et inimese instinkt paneb ta tegutsema asjadega, mida ta teha oskab. Alati pole see aga see, millest on võimalik enim kokku hoida või teenida. Veekulu vähendamise projektis oli meil üks n.ö. “lemmiktegevus”, mis tundus kõigile loogiline ja tulusaim, kuid peale mõningat andmete töötlemist selgus, et rahalises mõttes puudus sellel igasugune mõte – kokkuhoid oli võimalik ainult ideaalses maailmas ja ka siis oli see liiga väike.
  • Loo protsessikirjeldused ning määratle piirid. Sinu peamised abimehed siin on SIPOC diagramm ning muud erinevad protsesside kaardistamise moodused. Ideepoolest on see ka hea võimalus joonistada väärtuse loomise kaart (value stream map). Veekulu mõõtmisel kasutasime ohtralt veel tehnilisi jooniseid – kust vesi tuli ja kuhu ta läks. See oli minu jaoks küllaltki kriitiline, sest tegelikult tean ma veevärgist samapalju kui lehm piimaautost.
  • Loo kommunikatsiooni plaan. Täitsa ausalt ütlen, et mingit keerulist plaani polnud – rääkisin n.ö. huvigruppidega pidevalt ja eraldi plaani polnud vaja.
  • Arenda projekti tegevuskava. Pane paika tähtajad, eelarve jmt.


Kuidas kõigest sellest aga reaalne kokkuhoid teha?

Probleemi selliselt defineerides ja täpsustades juhtus nii mõndagi. Peamine väärtus on suhtlemine erinevate huvigruppidega, et teada saada nende perspektiivi. See annab sulle tead hoiakud, mured ning arusaamad probleemist. Seda kõike teades saad sa juhina hakata nende hoiakute muutmisega tööle rõhutades probleemi tähtsust ning seletades lahti mida see teiste jaoks tähendab või siis mis selle äriline mõte on.

Juhtus ka see, et probleemi defineerimise lõppedes oli meil selge kaks asja – kulusid saab vähendada nii üldkulu vähendamisega kui ka veehinna vähendamisega. Veehind selle ettevõtte jaoks sõltus reovee kvaliteedist ning seda sai muuta. Vee üldkulu vähendamiseks oli juba huvigruppidega suhtlemisel ning erinevate skeemide joonistamisel tekkinud 7-8 veekulu põhjuste peamist hüpoteesi, mida me siis mõõtmise faasis kontrollima asusime. Igatahes oli see natuke teistsugune lähenemine probleemi põhjuste defineerimisele kui tüüpiline ajurünnaku käigus Ishikawa diagrammi joonistamine.

Kui kõik hüpoteesid on kontrollitud ja probleem pole ikka vee selge…

Me kontrollisime oma hüpoteesid ja suutsime saavutada mingisuguse piiratud edu, kuid olime seatud eesmärkidest ikka veel kaugel. Me kontrollisime teoreetilist veekulu korduvalt ning kõrvutasime seda mõõdetud numbritega, kuid vahed jäid ikka veel uskumatult suureks. Puudu tuli ka hüpoteesidest – neid ei suuda sa ju ka lõpmatuseni genereerida.

Olles välistanud kõik võimaliku, jõudsime me tagasi sinnakohta, kus ainus loogiline lahendus sai olla üks – meie sissetuleva vee mõõtja näitas aiateibaid. Hüpotees leidis peale mõõtja vahetamist ka kinnitust. Kui suurt kahju oli see aastate jooksul tekitanud ei saa me kunagi täpselt teada, kuid rõhutab siiski väga kenasti mõõteriistade kalibreerimise ohjamise olulisust. 🙂

Defineerimisest üksi jääb väheks

Kuigi ma pean edu saladuseks rahulikku ja põhjalikku tööd probleemi defineerimise faasis, siis samavõrra olulised olid tegelikult ka järgnevad mõõtmiste ja analüüsi faasid. Mis seal salata, ka hilisemad tegevused ja nende tulemite kontroll olid olulised. Kuigi ma pealkirjas puhtalt intriigi mõttes tõin välja defineerimise faasi, siis tegelikult on olulised kõik faasid. Täpsemalt – oluline on, et sa neist ühtegi vahele ei jätaks. Probleemi mõistmine ja defineerimine on aga tegevus, mida kiputakse väga tihti vahele jätma. Probleem on ju ilmselge! Oled sa kindel? 🙂

Sarnased postitused: