Planavimo ciklų paradigmos

Kažkaip čia susimąsčiau kartą apie tai, kaip skiriasi skirtingose vadybos metodologijose naudojami pokyčių planavimo ciklai. Vienur vienaip, kitur kitaip, bet dauguma atvejų lyg ir apie tą patį, labai panašiai. Tačiau visgi su skirtingais akcentais, kurie daug ką pasako apie esmines idėjas, kurios slypi TQM (kokybės vadyboje), Six Sigma, Lean, ToC ar BSC metodologijose. Būtent tie akcentai užkabina ir požiūrių skirtumus tose metodologijose, o tuo pačiu – ir skirtingas problematikas skirtingose įmonėse.

Kartą girdėjau tokią anekdotišką istoriją: kokia tai firma nusipirko autobusą Anglijoje, parsivežė į Lietuvą, tvarkingai perkėlė vairą į kitą pusę, kad Lietuvoje naudoti būtų galima, žibintus susitvarkė ir taip toliau. Ir technikinę praėjo - viskas gavosi labai nebrangiai, lyginant su įprastomis išlaidomis. Bet vat su planavimu buvo nelabai, nes jau išvažiavus į maršrutą, paaiškėjo viena smulkmena. Žinote gi, angliškų autobusų durys yra kitoje pusėje...

Kartą girdėjau tokią seną seną anekdotišką istoriją: kokia tai firma nusipirko autobusą Anglijoje, parsivežė į Lietuvą, tvarkingai perkėlė vairą ir pedalus į kitą pusę, kad Lietuvoje naudoti būtų galima, žibintus susitvarkė ir taip toliau. Ir technikinę praėjo – viskas gavosi labai nebrangiai, lyginant su įprastomis išlaidomis. Bet vat su planavimu buvo nelabai, nes jau išvažiavus į maršrutą, paaiškėjo viena smulkmena. Žinote gi, angliškų autobusų durys yra kitoje pusėje…

Galima nesunkiai suprasti, kad tie skirtumai atsiranda ne šiaip sau, nes jei jau kažkas yra kitaip – reiškia, kad buvo priežasčių. Matyt, susidūrė vieni ar kiti vadybos ekspertai su tuo, kad sistemingai ir nuolat kyla kažkokios labai bendros, visą įmonių valdymą apimančios bėdos. Atitinkamai, tas bėdas ir nutarė išspręsti.

Todėl pažiūrėkim ir užduokim sau klausimą, kokios gi bėdos pas mus kyla, todėl į ką daugiau vertėtų atkreipti dėmesį? Aš jums aišku, nepasakosiu, ką aiškina kai kurie patys tam tikrų metodologijų mylėtojai (kaip pvz., kokie nors iš Six Sigma kartais pradeda skiesti apie tai, kad PDCA tėra DMAIC ciklo dalis skirta gerinimui vykdyti), o geriau padekonstruosiu, kas ten turėjo per problemos būti, kad vienas ar kitas variantas buvo pasirinktas.

Klasikinis planavimas

Pradėkime nuo visiškai klasikinio ciklo, kuris paprastai netgi nenagrinėjamas, bet jį panagrinėti būtina, nes kai jis nenagrinėjamas, tai paskui atsiranda visokie puspročiai, kurie ima kliedėti apie visokius dvasingumus, užmiršdami apie tikrą planavimo esmę. Patikėkit manim, aš esu matęs tokių kliedesiškų schemų, dar ir tokiais rimtais snukiais dėstomų, kad man kildavo klausimas, ar kartais neserga kokia nors schizofrenija nekurie aiškintojai.

Išties į planavimą reikia pažvelgti labai bukai, visiškai elementariai, suprimityvinant ir supaprastinant tiek, kad būtų neįmanoma padaryti jokios klaidos – taip ir gausis klasikinis arba bazinis planavimo ciklas. Vat toksai klasikinis planavimas ir kabins tuos dalykus, be kurių neįmanoma apseiti ir be kurių jums išvis nieko nepavyks padaryti.

Spėju, kad tas klasikinis planavimo ciklas yra toksai senas, kad aš netgi nežinau, kada jis atsirado – savo esme jis tiek smarkiai primena standartinį semiotikoje nagrinėjamą pasakojimo struktūrą (pradinė situacija, kelias, galinė situacija), kad rodos, šitas ciklas egzistavo visada. Taigi, jei nesugebate jo laikytis – esate nevykėliai, tad jau ką ką, tačiau šitą bazinį planavimą turite mokėti absoliučiai ir besąlygiškai:

  1. Kur mes esame? – reikia apibrėžti esamą situaciją (vietą, problemas, etc.), nes jei neapibrėžiame, tai negalime išsiaiškinti, išvis kodėl mums kažko reikia
  2. Kur mes norime būti? – reikia apibrėžti tą situaciją (vietą, veikimo būdą, etc.), koksai mums būtų tinkamas
  3. Kaip mums tenai nueiti? – vat čia jau ir žiūrime, kur yra skirtumai tarp [1] ir [2], o tada ir susiplanuojame reikalingus veiksmus

Verta čia pastebėti, kad vykdymo kontrolės nėra, o pagrindinis fokusavimasis yra į tai, kad norint kažką teisingai suplanuoti, reikia išsiaiškinti, kokia tavo situacija ir ko tu išties nori. O jau tada – gali gauti ir pokyčių planą. Tuo tarpu jei nežinai vieno ar kito – tai iš jokio planavimo nebus jokios naudos. Tiktai žinodamas, ko nori ir kur esi – jau gali rasti sprendimą, o tada ir jį įgyvendinti.

Galime numanyti, kad prie šito ciklo tikslumo galima būtų pridėti dar punktą apie tai, kad reikia ir nukeliauti, bet jis čia toksai savaime aiškus, kad paprastai niekas jo ir nepamini.

Apie tokį ciklą jums būtina pagalvoti bet kokiu atveju, nepriklausomai nuo to, kiek išvystytą planavimą turite. Nes jei neapakankamai gerai apibrėžinėsite esamą ir norimą situaciją, kelio jums irgi nepavyks tinkamai apibrėžti. O tada ir feilinsite. Žodžiu, šitą ciklą būtinai turėkite omeny ir juo nuolat remkitės, nes iš jo kyla absoliučiai visi kiti efektyvaus planavimo metodai.

Kokybės vadybos (TQM) naudojamas Demingo ciklas (PDCA arba PDTV)

Štai čia pasižiūrėkime išsyk į absoliučiai klasikinį Demingo arba PDCA ciklą (lietuviškai būtų PDTV – „planuok, daryk, tikrink, veik“), visiems žinomą iš TQM (Total Quality Management) bei Edward Deming darbų. Šitas ciklas vadyboje jau tapo tokia klasika, kad jį irgi privalote žinoti, nes kitaip visi jus laikys neišmanėliais:

  1. Plan (Planuok) – reikia pirmiausiai susiplanuoti, nusistatyti kas bus daroma, nes jei nesusistatysi, tai bus neaišku kas
  2. Do (Daryk) – tada daryti tai, ką suplanavai, o ne užsiimti nežinia kuo
  3. Check (Tikrink) – pasižiūrėti, ar gerai pavyksta daryti, nes jei nepatikrinsi – tai bus neaišku kas
  4. Act (Veik) – imtis korekcinių veiksmų, šitaip grįžtant į [1] ciklo punktą, tam kad planas būtų atitinkamai pakoreguotas

Pirmas dalykas, kuris krenta į akis – tai tas, kad į pirmą etapą faktiškai sukištas visas klasikinis planavimo ciklas. O jau paskui yra darymas, kontrolė ir korekcija – akivaizdu, kad būtent tą darymą su korekcija ir norėjo akcentuoti Edward Demming.

Kitas svarbus dalykas – nors klasikiniame cikle viso įgyvendinimo etapo išvis net neminėjom, nes viskas atrodė savaime aišku, čia jis ryškiai išskirtas, o taip pat ir nurodyta, kad reikia vis žiūrėti, ar teisingai eini. Ir paskui imtis korekcijos, esant reikalui, perplanuojant.

Galime numanyti, kad Edward Deming susidurdavo su tuo, kad situacija ir norai, kaip ir veiksmai, įmonėse būdavo apibrėžiami ganėtinai neblogai, bet štai paskui jau viskas nueidavo kažkokiais neaiškiais keliais, kurie pasibaigdavo neaišku kuo. Arba dar dažniau priešingai – viskas būdavo pernelyg bukai vykdoma pagal planą, nei nežiūrint į tai, kad paaiškėjo, jog viską reikia daryti kitaip.

Tai labai atsispindi tame, ką kokybės vadyba ir akcentuoja: gerinimas turi būti nuolatinis, neįmanoma padaryti vienkartinių gerinimo veiksmų, nes jie turi kartotis ir kartotis, o ir šiaip tie veiksmai turi nuolat sietis su tikrove ir būti koreguojami taip, kad viskas eitų tinkamai.

Jei jūsų įmonėje viskas daroma bukai pagal planą arba išvis vyksta be jokio tęstinumo, o su paslaugų ar gaminių kokybe yra problemų – pagalvokite apie PDCA ciklą, jis gali jums labai praversti, nes akcentai sudėlioti taip, kad būtų užtikrinamas teisingas vykdymas.

Six Sigma metodologijos DMAIC ciklas

O čia pasižiūrėkime į Six Sigma, kuri ne veltui laikoma visiškai tiesioginiu TQM tęsiniu (nors patys Six Sigma veikėjai neretai bando vaizudoti kitaip). Ir atrasim, kad Six Sigma kažkodėl neįtikėtinai skiriasi savo akcentais:

  1. Define – reikia apibrėžti, ką ir kaip matuojame, nes tai ir yra tikslus esamos situacijos nustatymas
  2. Measure – matuokime ir žiūrėkime realius skaičius bei faktus, nes tada matysime, kaip ir kur einame
  3. Analyze – analizuokime skaičius ir jų sąsajas, kad galėtume atsekti nuokrypių (variacijų) kilmę bei būdus pagerinti situaciją
  4. Improve – gerinkime sistemą taip, kad gerėtų tie skaičiai, kuriuos gauname, matuodami
  5. Control – vykdydami ciklą, valdykime procesą

Aš manau, kad jau krito į akis, jog šitas ciklas primena PDCA, tačiau kažkodėl vietoje planavimo atsiranda apibrėžimas, vietoje darymo atsiranda matavimas, o ir paskutinis etapas kažkodėl išskaidytas į du. Kaip manote, kodėl?

Akivaidu, kad Six Sigma kūrėjai susidūrė su tuo, kad planavimas dažnai būna toksai išskydęs, kad galvojama apie neaišku ką ir norima neaišku ko, tad atitinkamai ir PDCA ciklas ima neveikti. Akivaizdu, kad kai neaišku, kokia esama situacija ir kur norima pakliūti, tai ir veiksmai bei korekijos neveikia.

Taigi, nors iš pirmo žvilgsnio tai ir nėra akivaizdu, bet pamatome, kad nuo Demingo ciklo čia išties sugrįžta link klasikinio planavimo idėjų: reikia aiškiai apsibrėžti bent jau tai, kur mes esame, o tada ne šiaip sau kažkur eiti, o matuoti, kiek ir kur nuėjome (o tai savaime reiškia, kad reikia išsiaiškinti į kur einame). Vėlgi, DMAIC cikle atskiru punktu išskirta, kad ne šiaip koreguoti reikia, o sukti tą ciklą, nes tik taip galima kontroliuoti procesą.

Six Sigma nuolat akcentuoja, kad viskas turi būti išmatuojama, o skaičiai leidžia įvertinti, kur ir ką reikia keisti. Jei nesugebate tiksliai apibrėžti rodiklių, o paskui juos matuoti, tai nežinote esamos situacijos, atitinkamai – neturite ir ką analizuoti, o atitinkamai – ir negalite nieko pagerinti.

Jei jūsų įmonėje planavimas vyksta, žmonės lyg ir gerai viską daro, tačiau vis atsiranda kažkokie neapibrėžtumai ir neaišku, ko išties norite ir kur esate, tai verta pagalvoti apie Six Sigma ciklą. Jie gi akcentuoja matavimus ir skaičius.

Balanced Scorecard – planavimo feilas

Dabar nukrypkim truputį, nes pasižiūrėjom porą gerų metodikų, o verta pamatyti ir blogą variantą, kuris blogas ne šiaip sau, o todėl, kad skirtas visiškai apleistiems, stagnaciniams atvejams, kai susidurta su tokiomis bėdomis, kad visas tas planavimas, ghrmz, kaip čia pasakius jums politkorektiškai… Žodžiu, gal aš jums nesakysiu dabar, o pasakysiu straipsnio gale. O kol kas pasakysiu tik tiek, kad nesvarbu, kaip baisiai atrodytų, neskubėkit sakyti, kad blogas yra Balanced Scorecard, nes išties jis tik realijas atspindi.

Prieš kelis dešimtmečius tokie David Norton ir Robert Kaplan sukūrė Balanced Scorecard (BSC), metodologiją, kuri anuo metu davė pasauliui labai daug naudos, nes sustatė įmonių veiklą į kelias paprastas sritis – rinką, finansus, procesus ir žmones, ganėtinai išmokė visus kontroliuoti veiksmus, bet paskui pavirto į totalų feilą, iš kurio kai kurie užkietėję procesistai iki šiol tyčiojasi. Va kaip atrodo BSC planavimas:

  1. Išversti viziją į konkrečius veiklos tikslus
  2. Paskelbti viziją ir susieti ją su konkrečių skyrių/darbuotojų veikla
  3. Planuoti verslą, nustatyti kriterijus
  4. Grįžtamasis ryšys, mokymasis ir strategijos korekcija

Pabandę suprasti, kas čia per šizofreniški dvasingumai, galime nuspėti, kad David Norton ir Robert Kaplan daug laiko praleido visokiose nerišliose kontorose, strategavo ir duso visokiuose posėdžiuose, kol galų gale patys išprotėjo. Čia nesimato nei aiškių apibrėžimų, nei ėjimo iš situacijos A į situaciją B, nei bendrai įmonės rodiklių. Visas prasmingas gerinimo procesas sukištas į ketvirtą punktą, bet sukištas taip, kad net neaišku kaip. Tiksliau, man tai aišku, bet aš jums kol kas to nesakysiu – paskaitykit ir apie kitas sritis, iki galo, jei norite suprasti.

Visgi yra ir gero tame BSC planavime, vienas dalykas, į kurį būtina atkreipti dėmesį: vizija yra ne šiaip sau kokia tai nesąmonė, o toksai reikalas, be kurio neaišku, į kurią pusę įmonė eina. Ją reikia turėti omeny, nes kitaip užsilenksit. Ir dar vienas reikalas – BSC skorekardai labai neblogai leidžia išsireikalauti iš visokių įmonių vadovų konkrečių darbų.

O šiaip, aš jums siūlau pirmiausiai patiems pagalvoti apie tai, kokia turėjo būti David Norton ir Robert Kaplan patirtis, kad jie tokią planavimo metodiką susigalvotų. Jei tingite galvoti, tai pasakysiu iškart – jie nuolat sukosi nesuvokiamose absoliučiai nuo realybės atšokusių ir užsistagnavusių korporacijų psichozėse. Todėl ir visą tą savo BSC sukūrė ne tam, kad planavimas atsirastų, o tam, kad atsirastų bent kažkokie svertai, kuriais galima stagnacinius vadovus paspaust.

Ir vat čia aš jums pasiūlysiu pagalvoti apie BSC ar kažko panašaus taikymą aukštesnių grandžių vadovų vertinimui. Tai pravers, jei pas jus posėdžiuose nuolat vyksta pelkė, kurioje niekas nieko negali, niekas už nieką neatsakingas, o dėl visų problemų kalti bet kas, išskyrus pačius vadovus. Tiktai su tuo neperlenkit lazdos, nes irgi galit nuprotėti. Geriau paprasčiau darykit.

Ir dar, aš jums kai ką pasakysiu apie Balanced Scorecard visai gale. Po to, kai jūs perskaitysite visus kitus dalykus.

Lean planavimas, penkių žingsnių seka

Grįžkim dabar prie paprastos realybės. Ir vat toji paprasta realybė – tai Lean. Šita metodologija labai įdomi tuo, kad negalvoja apie gilias prasmes ir tolimas pasekmes, o žiūri į viską labai paprastai: reikia padaryti, kad viskas veiktų gerai, tai ir darykim, kad veiktų gerai. Faktiškai, anksčiau Lean išvis netgi nekalbėdavo apie ciklus, o sakydavo, kad reikia tiesiog tam tikrų principų laikytis, kaip kad Iššūkis (tikslas), Kaizen (nuolatinis gerinimas, tarp kitko, šį bei tą apie Kaizen esu rašęs) ir Genchi Genbutsu (dalyvavimas – buvimas gamyboje, teisingi sprendimai, konsensusas ir greitis). Kaip rezultatas – visas planavimas pas Lean mėgėjus neretai tapdavo kažkokiu dvasingumu, kur pagerinti lyg ir aišku kaip, o vat suplanuoti – tai kažkoksai įkvėpiminis dzen. Visgi paskutiniu jie jau kalba apie daug konkretesnę penkių žingsnių seką, kuri aiškiai matosi visas ciklas:

  1. Identifikuoti vertes – apibrėžkime, ką išties gaminame kliento požiūriu, t.y., už ką išties klientas mums moka pinigus (už specifinį produktą specifiniu momentu)
  2. Apibrėžti vertės srovę – apibrėžkime procesą ir jame sužymėkime, kur tos vertės atsiranda ar didėja, kartu pašalindami ar sumažindami tuos žingsnius, kurie nekuria vertės. Čia reikia pagalvoti ir apie problemų sprendimą, ir apie informacijos valdymą, ir apie tai, kaip žaliavos fiziškai transformuojasi į galutinį produktą.
  3. Sukurti srautą – padarykime, kad tie vertės kūrimo žingsniai būtų kuo labiau suspausti tarpusavyje, kad vertė gražiai tekėtų pas klientą. Čia reikia visiškai pašalinti visus srautui trukdančius barjerus ir įmonę perorientuoti į klientą.
  4. Sukurti trauką – padarykime, kad klientas pats galėtų pasiimti ir vertę iš toliau nuo jo esančios srauto dalies, t.y., pull sistemą, kuriai nereikia pardavimų prognozių.
  5. Siekti tobulybės – kartokime ciklą iš naujo, kol išvis neliks jokio švaistymo ir klientas gaus idealiai jam tinkamą produktą

Čia verta pastebėti, kad bent iš pirmo žvilgsnio šitas ciklas atrodo visiškai kitaip, nei koks PDCA ar DMAIC, tiesa? Ogi netiesa.

Šitas ciklas yra beveik tiksli DMAIC ciklo kopija (ne veltui gi Lean ir Six Sigma paskutiniu metu taip susiliejo), tačiau išdėstyta visiškai kitokiu požiūriu. Kaip sakant, kažkaip paprasčiau kažkaip ten – pagal Lean. Žodžiu, nesigilinant į visokias abstrakcijas.

Įdomus čia pats pirmas punktas, kuris mums sako apie tai, kad reikia apibrėžti, ką matuosime, t.y., tą kelią iš situacijos A į B. Tik vat akcentas ant kliento uždėtas – iš ten ir atsiranda japoniška kokybė. Ir į šitą punktą jūs pažiūrėkite itin rimtai, nes aš jau esu rašęs apie orientaciją į klientą ir kaip be jos viskas palūžta.

Antras etapas – jau matuojamas, nes čia jau išsyk kalbame apie veiksmus, bet ir vėl kliento vertės požiūriu. Ir srauto kūrimas – tai ta pati analizė su gerinimu, ir vėl kliento vertės požiūriu. Ir trauka – tai tiesiog gerinimas, ir vėl kliento vertės požiūriu. Ir taip toliau – žodžiu, viskas paprasta, tik visur su kliento požiūriu.

Žinote, kai Japonijoje ėmė rastis sisteminga vadyba (ją ten atnešė tas pats Edward Deming su savo PDCA), daugybė firmų buvo labai dezorientuotos. Pokario metai, suirutė, chaosas – valstybiniai užsakymai dingo, o gyventi reikia. Tarp kitko, primena Lietuvą po SSRS griuvimo. O paskui – nepaprastas augimas ir jau tada kilusi fantastiškai arši japoniška konkurencija įmones privertė labai smarkiai pergalvoti, kodėl išties reikia verslo procesų gerinimo. Iš to ir radosi ta orientacija į klientą.

Lean planavimas nėra trivialus, nors ir atrodo patraukliai bei paprastai (o kas paprasta – dažnai žymiai sunkiau, nei atrodo). Neužmirškime, kad Lean atsirado ne tuščioje vietoje, o per daugybę metų, kai Demingas pačioje Japonijoje kūrė ir vystė savo kokybės vadybą, vėliau tapusią tuo, kas žinoma kaip TQM (Total Quality Management).

Patarčiau pirmiausiai pabandyti naudoti mechaniškesnį planavimą (jei nedarote formalių planų – pirma patariu pagalvoti apie PDCA), nes be jo bus sunku. Bet štai kai jau imsite sėkmingai taikyti Lean – bus labai geras efektyvumo padidinimas. Kita vertus, apie tą kliento suvokiamą vertę siūlyčiau pagalvoti bet kuriuo atveju.

Apribojimų teorija ir POOGI

Toksai ponas Eli Goldratt, ėmęs kurti savo apribojimų teoriją (kai kuo primenančią Lean), kažkaip į viską pažiūrėjo labai hakeriškai (ne veltui eina gandas, kad nuo IT jis ir pradėjo savo veiklą) – vietoje to, kad galvotų gatavus sprendimus, jis pabandė sukurti sisteminį vadybos uždavinių sprendimo metodų rinkinį, o paskui perėjo net ir į aksiomatiką (ToC dilemų kūrimo ir analizės priemones pažiūrėjus, išsyk daug minčių kyla). Žodžiu, ilgainiui gavosi dalykas, kuris stebėtinai efektyvus ir gražus.

Gal dėl to ir ToC planavimo ciklas įdomus, o dar ir pavadintas keistu pavadinimu – POOGI („Process Of Ongoing Improvement“), kuris savo skambesiu ir prasmingumu man primena nesakysiu ką*. Kitas to paties ciklo pavadinimas gal mažiau keistas, užtat labai banalus – „penki fokusavimosi žingsniai“ („five focusing steps“). Tačiau nors ir keistai pavadintas, ToC ciklas yra labai geras:

  1. Identify – identifikuoti apribojimą – norint apribojimą apibrėžti, kyla neišvengiami klausimai: kur mes esame ir kur norime pakliūti? Beje, turint omeny, kad apribojimai būna vidiniai ir išoriniai, čia mes turime ir Lean požiūrio ekvivalentą (jei apribojimas išorinis), ir kartu bendresnį požiūrį.
  2. Exploit – išnaudoti apribojimą – panaudoti visas apribojimo galimybes tam, kad apribojimas imtų dirbti didesniu našumu.
  3. Subordinate – pajungti visus apribojimui – optimizuoti sistemą taip, kad ji būtų subordinuota į to apribojimo išnaudojimą.
  4. Elevate – išplėsti apribojimą – čia jei jau visvien nepakanka – tada galime kalbėti apie apribojimo plėtimą.
  5. Prevent inertia – kartoti ciklą, bet nepasiduoti inercijai – o vat čia ir slepiasi paskutinis, giliausias įdomumas, kurio kitur nebuvo.

Žinote, čia pasižiūrėję į šitą ciklą, randame, kad jis ir vėl panašus į kitus nagrinėtus atvejus, ypatingai artimas PDCA, nors primenantis primenantis ir DMAIC, ir Lean 5 žingsnius. Bet paskutiniame punkte yra įkišta viena frazė, akcentuota paties Eli Goldratto – apie tai, kad negalima pasiduoti inercijai. Ir štai čia yra vienas niuansas, kurį matyt patsai Eli Goldratt pastebėjo, bet vat nemažai jo pasekėjų iki šiol nesuvokia visos šios minties vertės (bent jau toks įspūdis kartais kyla, kai paskaitai nekuriuos vakarietiškus apie ToC rašinėjančius internetus).

Problema, kuri visus nudusina – tai defokusavimasis. Tik dar gilesnė problema yra ta, kad pernelyg gilus ir inertiškas fokusavimasis ir gerinimas gali nudusinti tave patį, virsdamas ne kuo kitu, o stagnacija. Tai ir yra inercija, būtent nuo to ir sergsti Eli Goldratt: jei jau iškėlėme apribojimą, t.y., išplėtėme jį, jis jau negali būti apribojimu, nes apribojimas atsirado kitur. Taigi, jei kartosime ciklą taip pat, tai bet kuriuo atveju reikš inerciją: arba vadovai nesugebėjo pakankamai išplėsti apribojimo, arba jie išplėtė, bet visvien tą patį gerina. Pagaunate, kas per stagnacija?

Aš jums išsyk patariu pagalvoti apie tai, kad pritaikytumėte tą POOGI ciklą, bent minimaliai, bent formaliai. Ir kad užduotumėte klausimą, ar tikrai fokusuojatės į tai, į ką reikia?

Inercija, kaip valdymo žudikė

Jau pakankamai seniai su TQM dirbantys yra pastebėję, kad kokybės vadyba neretai nueina į neadekvatų popierizmą, kur viskas lyg ir idealiai tiksliai, kaip kokioje mašinoje, bet kažkodėl visas tas tikslumas savaime tampa apribojimu. Čia aš prisiminčiau ir vieną iš postdeminginių vadybos ligų – standartizacijos komitetų sindromą, kur visokie sistemų kūrėjai ir derintojai viską taip gerai priderina, kad gaunasi niekam nereikalingi monstriški specifikacijų gargarai, kurie žlunga dėl to, kad nuo juos aprašančių popierių pertekliaus įgriūna kabinetų grindys. Pati vadybos sistema, kad ir kokia gera bebūtų, gali tapti apribojimu, jei pasiduosime inercijai ir laiku nenustosime jos tobulinti. Žiauru, ar ne?

Kitos metodologijos irgi susiduria su inercija. Štai pavyzdžiui Lean atveju kartais galima atrasti, kad visiškai švariai numinimizuotas procesas tampa nepajėgiu natūraliai augti, nes nelieka perteklinių resursų, kurie leistų jį keisti. Dar įdomiau, jei dėl viso išlyginimo procesas praranda apribojimą – tada netgi nesigauna pasakyti, per kur jį išvis tobulinti. Irgi, žinote, inercija, tik visai kitokia: paprasčiausiai nėra už ko užsikabinti. Idealumas tampa stagnaciniu faktoriumi.

Dabar dar sugrįžkime prie Nortono ir Kaplano su jų Balanced Scorecard: ar nekyla jums įtarimas, su kuo anie labiausiai bandė kovoti? Ogi būtent taip – su inercija, kuri buvo tokia stipri, kad jiems teko iškraipyti visą planavimą vien tam, kad bent kažkaip tą inerciją palaužti. Sugrįžkite atgal ir pasižiūrėkite į BSC seką. Gerai įsižiūrėkite ir pagalvokite, kas tenai daroma. Jei nedašyla, tai paaiškinsiu: ogi labai labai planingai, nuosekliai ir kryptingai vadovai užkabinami ant kabliuko, kur jie pirmiausiai pasijunta labai kietais, paismauna ant savo galios, o paskui susiduria su tuo, kad juos kažkas vertins. Vat dabar ir užduokit klausimą: o kodėl tokiam paprastam dalykui reikia tokios klastos?

Žinote, kiekviena vadybos metodologija atsiranda ne šiaip sau – ji atsiranda dėl to, kad reikia išspręsti kažkokias sistemingai, daugelyje sričių kylančias problemas. Kažkada TQM atsirado dėl to, kad visi galvojo, kaip prigaminti daugiau, bet negalvojo apie tai, ko jie išties prigamina. Paskui, sudėtingėjant visokiems gaminiams, atsirado ir Six Sigma, nes paaiškėjo, kad kai kurių dalykų neįmanoma pagaminti, jei yra kad ir nedidelių problemų su kokybe**. O daugmaž paraleliai, bandant labiau orientuotis į vartotojus, atsirado Lean***. Tačiau toksai daiktas, kaip BSC atsirado visiškai iš kitos pusės – nes ėmė vis labiau aiškėti, kad žuvys pūva nuo galvos.

Deja, BSC yra visiškai neadekvati metodologija bendrai įmonių valdymui, nes nei ten turi sisteminio priėjimo prie priežasčių-pasekmių, nei ten kokių nors rišlesnių procesinio valdymo idėjų. Iš esmės, savo metodais BSC yra kažkoks XIX amžius – anais laikais labai skorekardus visi mėgdavo.

Vat matyt ir gavosi taip, kad BSC įmonėms padėjo tiktai tiek, kiek BSC naudotojai sugebėdavo užsiimdinėti vadybine magija, Edward Deming pradėtos srovės nukrypo kažkur į užsiciklinimą, užmirštant apie tai, kad apribojimu gali tapti pati vadybos sistema, o tik vienas Eli Goldratt susiprato apie tai pagalvoti.

Kompleksinis modernus planavimo ciklas, netinkamas visiems

Štai čia aš jums jau pabaigai pridėsiu apie tai, kaip ten visgi pasirinkti ir ką daryti, nes žinau, kaip ima lįsti klausimai į galvas – „o tai kas visgi geriau, kas teisingiau? Tai pasakysiu paprastai, jau neaiškindamas:

Klasikinį ciklą iš trijų etapų, kur yra dabartinė situacija, norima situacija ir kelias nuo vienos prie kitos, visvien turite naudoti, nes neišvengsit. O jei išvengsit, tai feilinsit. Naudokite jį būtinai, nesvarbu kiek atrodytų, jog ir taip viskas aišku. Beje, ypač siūlau atkreipti dėmesį į esamos situacijos analizę: įsitikinimas, kad ir taip žinoma, kokia ta situacija – tai viena iš dažniausių ir viena iš pačių fatališkiausių vadybos klaidų. Ir kai tos klaidos sukeltos pasekmės pasimato, būna per vėlu.

Neužmirškite ir PDCA – planuoti, daryti, tikrinti, veikti. Bukas planų laikymasis – tai beprotybė, o nesilaikymas – irgi beprotybė. Žodžiu, turėkite sveiko proto, nes būtent to šitas ciklas ir moko.

Dėl BSC – jei jums šitokių fokusų prireikia, tai aš jums patariu pagalvoti, ar tikrai verta išvis apie tai galvoti, nes jei to reikia, tai reiškia, kad yra bėdų. Jei esate įmonės savininkas, tai pagalvokite apie tai, kad gal tuos stagnacinius degeneratus geriau išvis atleist iš darbo. Na, o jei pats esate koks iš tokių vadovų ir norite užsiiminėti visokiomis vadybinėmis masturbacijomis – galit bandyt, bet aš tai jus iš darbo atleisčiau už tai. Aišku, gali būti, kad jūs esate klastingas vadybos asas ir jums tokie bajeriai su visokiomis klastomis yra natūralūs ir įprasti, bet tai tada čia jau aš nepatardinėsiu, nes aš tokį asą žinau tik vieną ir jisai pats panašius ciklus susigalvoja pagal poreikį 😀

O vat dėl kitų metodologijų – pažiūrėkime į kompleksinį ciklą, kur yra ir penki žingsniai iš Lean, ir DMAIC, ir POOGI vienu metu:

  1. Identifikuoti vertes, taip pat tai, kas riboja jų kūrimą ir nustatyti matavimo būdus
  2. Apibrėžti vertės tėkmę, išnaudoti jos apribojimą ir imti rinkti matavimų duomenis
  3. Išanalizuoti duomenis ir sukurti veiksmingą srautą, subordinuojant visą procesą į apribojimą
  4. Pagerinti visą procesą, panaikinant (išplečiant) apribojimą ir sukuriant trauką (pull mechanizmą)
  5. Siekti tobulybės, kartu išvengiant inercijos ir imant holistiškai kontroliuoti visą procesą

Jeigu jums atrodo, kad visi tie punktai puikiausiai susiderina, tai išties jūs esate teisūs. Jei jums atrodo, kad šitoksai ciklas yra prastas, tai jūs irgi esate teisūs. Taip, visi žingsniai puikiai susiderina. Bet jiems susiderinus, dingsta fokusavimasis – jūs tiesiog užmirštate, ką išties norite padaryti, nes bandote padaryti viską.

Problema yra paprasta: jei norite kažką išties pagerinti, jums reikia turėti konkrečią paradigmą, t.y., savo įmonėje galiojantį pasaulio suvokimą, kuriame tos problemos ir spręstųsi. Įsivaizduokite, kad turite vištos ir kiaušinio problemą: ar kiaušinius deda vištos, ar vištos išsirita iš kiaušinių? Vadybiniu požiūriu yra paprasta: jei parduodate kiaušinius, tai kiaušinius iš vištų gaminate, o jei vištas parduodate – tai vištas gaminate iš kiaušinių. Atitinkamai ir gerinate procesą. Tačiau taikyti visus požiūrius iškart – tokia pat klaida, kaip ir taikyti netinkamą požiūrį, nes prarandamas fokusavimasis.

Tiesiog jei paimsite viską vienu metu, tai tada ir gausis, kad lyg ir vištų negalima pardavinėti, nes kiaušinių bus per mažai, o ir kiaušinių negalima pardavinėti, nes per mažai bus vištų, o ir išvis neaišku nuo ko pradėti, nes neaišku, kas pirma – višta ar kiaušinis. Todėl patarčiau visgi pasirinkti kažkurią vadybos metodologiją kaip pirminę, o su tuo – ir visą planavimą pasižiūrėti.

Įsivaizduokite, kad pas jus gamybinė linija, kurios procesas nusistovėjęs, bet apleistas, darininkus kamuoja bardakas, pilna visokių kokybės kontrolių, o klientas gauna visai ne tą, ko nori – čia gi akivaizdu, kad Lean turėtų tapti idealiu metodu gerinimui: pramėtot viską, ko nereikia, gražiai pritaikote Kaizen – ir puiku: klientai darosi patenkinti, o srautas auga.

O įsivaizduokite, kad turite tvarkingą liniją, gamyba lyg ir gera, procesas matuojamas, klientas gauna tai, ko nori, bet kažkodėl kokybė šlubuoja, o pasiekti gero rezultato nesigauna, nes gaminiai sudėtingi. Six Sigma metodai matyt bus idealūs, nes vos pradėsite skaičiuoti tai, ką reikia, kokybę pagerinsit stebuklingai ir su mažomis išlaidomis.

O įsivaizduokite, kad gamybos procesas yra pakankamai painus, kad nors ir viskas suderinta, ir klientai patenkinti prekėmis, ir gal kokybė atitinka, o neaišku, nuo ko ir ką išvis gerinti pradėt, nes kažkaip nei šiaip, nei taip nesusidėlioja viskas, kad pelningumas būtų geras? Vat čia ir imame ToC, nes tenai pridėtinės vertės srautai nagrinėjami struktūraliai, tad galima spręsti kompleksines problemas.

Kaip matome, visur savi niuansai. Bet dar kita vertus, galime ir kitaip užduoti klausimą: išties, ar yra didelis skirtumas tarp tų metodologijų, jei teisingai identifikuoji esmines problemas? Juk jeigu identifikuoji, tai ir išsprendi, o pati metodologija tiesiog duoda struktūrą sprendimams, tiesa? O dar kita vertus, prisiminkime tą ToC punktą apie tai, kad inercija neturi mūsų užvaldyti.

Trumpai tariant, atrodytų, kad visi tie ciklai tokie panašūs, skirtumai menki, bet detalių kilmę panagrinėjus, galima atrasti, kad už jų slypi tikri vadybiniai košmarai.

 

————–

* ToC yra tikrai nuostabi metodologija, bet turi ir ji bent vieną trūkumą – ji yra absoliuti ir besąlygiška vadybos metodologijų lyderė pagal savo santrumpų bei terminų idiotiškumą ir beprasmiškumą. Man tai primena tuos sovietinius laikus, kai abreviatūromis vadindavo ką papuola, o kai kurios iš tų santrumpų būdavo tokios durnos, kad durniau nesugalvosi – pvz., „PISK“, kas reiškė „Pedagoginio Instituto Sporto Komanda“. Aš įtariu, kad ponas Eli Goldratt, kuris išties buvo genijus, visgi turėjo kokį tai autistinį sutrikimą, nes kitaip tų durnų pavadinimų paaiškinti negaliu. Reikia tikėtis, kažkada ToC lyderiai susipras, kad atėjo laikas kažką keisti. Juoba ir terminai ten visiškai atsieti nuo klasikinių, tad paskui ir painiava visokia prasideda.

** Įsivaizduokite, kad norite padaryti daiktą iš 1000 detalių, kur visos tos detalės yra 99,9% kokybiškos. Detalės lyg ir kokybiškos, bet iš pagamintų daiktų kokybiški tebus maždaug kokie 37%. Prastai, ar ne? Tokiais atvejais tenka imtis kartais ganėtinai netrivialių kokybės gerinimo metodų. Ir išmokti skaičiuoti. Six Sigma tą pakankamai akcentuoja.

*** Lean idėja didinti srautą – tiesioginis TQM palikimas: visi blogos kokybės kaštai yra švaistymai, t.y., variacija yra švaistymas. O variacijos šaltinis – tai viskas, išskyrus tuos proceso žingsnius, kurie realiai kuria vertę. Atitinkamai, reikia naikinti visus variaciją didinančius faktorius, o taip ir sutaupysime, ir srautą padidinsime. Įdomu, kad neretas Lean mėgėjas apie tai kažkodėl nepagalvoja, kaip apie sisteminį dalyką, bet ir negalvodamas labai neblogai tvarkosi.

Rokiškis Rabinovičius rašo jūsų džiaugsmui

Aš esu jūsų numylėtas ir garbinamas žiurkėnas. Galite mane susirasti ir ant kokio Google Plus, kur aš irgi esu Rokiškis Rabinovičius+.

Dalinkitės visur: Share on Facebook23Share on Google+0Share on LinkedIn4Tweet about this on Twitter

18 thoughts on “Planavimo ciklų paradigmos

    1. Rokiškis Post author

      O, pagaliau pirmas komentaras -- ir apie tai, kad nėra komentarų 😀

      Taip, čia, sakyčiau, kažkoksai seniai nematytas antirekordas 😀

      Reply
  1. Andrius

    Labai įdomus palyginimas. Tikrai jaučiasi, kad minėtos metodikos buvo sukurtos skirtingomis sąlygomis, tačiau tuo pačiu tikslu -- pabandyti nubrėžti kaip sistemingai tobulinti veiklą. Kiekviena metodologija turi savo „įrankių dėžutę“ ir čia slypi lobiai 🙂 Neturiu tikslo būti lean, toc ar 6sigma evangeliku, todėl kai susiduriu su kažkokia problema krapštausi po „įrankių dėžutes“ ir dažniausiai randu tinkamą instrumentą. Būna sudėtingų atvejų, kai vienoje įmonėje persimaišo daug skirtingų veiklų ir problemų -- tokiu atveju vienos metodologijos religija nesuveikia.

    Reply
    1. Rokiškis Post author

      Aš čia pasakyčiau, kad holistinis požiūris reikalingas ne tik į įmonę, bet ir į vadybos metodologijas 🙂

      Reply
  2. Cijunas

    Aš gal atrodysiu panašus į vieną tų užkietėjusių ir durnų įmonės stagnatorių, bet prašau perskaityti iki galo. Visos šios metodologijos gerai „tvarkosi“ gamybos ir paslaugų įmonėse, kur žaliavos imamos iš trečiųjų įmonių (tiekėjų) arba generuojamos įmonėje (darbuotojų žinios paslaugų atveju). Dabar pas mus pradėta diegti Lean metodika, tačia aš manau, kad mūsų sritis yra neįprasta (pastatų konstrukcijų projektavimo), nes klientas yra kartu ir žaliavų tiekėjas: klientas užsako projektą; žaliava projektui parengti -- techninė užduotis, kurią tas pats klientas ir pateikia mums. Iš to išeina, kad įmonė gauna brokuotą žaliavą (trūksta duomenų, ne laiku pataikiama), tačiau vis tiek turi laiku ir kokybiškai atlikti projektą. Taip išeina, kad jei spausi klientą dėl užduoties ištaisymo -- būsi blogas, jei nespausi -- nepavyks laiku ir kokybiškai suprojektuoti. Vat man ir įdomu, ką šioje vietoje gali pakeisti Lean metodika, nes jeigu iš viso proceso išmestume projekto žaliavos įsisavinimo etapą, tai pačiame projektavimo procese tikrai yra ką.
    P.S. Gal Tamsta žinote kiek projektavimo įmonių Lietuvoje (Europoje) jau įdiegta kažkuri metodologija?

    Reply
    1. Tomas Gluosnis-Tyla

      Įdomus klausimas, lauksim atsakymo. Kol laukiam, norėčiau pridėti, kad neteko matyti ar kurioje nors metodologijoje aprašomi defektai, kylantys grynai dėl nekokybiškos žaliavos. Visur yra skaitoma, kad žaliava yra patikrinta ir kokybiškį, o defektai atsiranda gamybos stadijoje dėl sisteminių klaidų, kreivų rankų ir pan. T.y., jeigu gamini trintukus, tai dėdamas gumą į konvejerį esi garantuotas, kad ta guma yra visiškai kokybiška. Labai prašau pataisyti mane, jei esu neteisus.
      Iš to seka, kad šioje vietoje Lean gali būti taikomas, tačiau turi būti užtikrinta, kad žaliava bus kokybiška, kas turėtų būti vadybininkų ar konsultantų darbas.

      Reply
      1. Andrius

        Niekur nėra laikoma, kad žaliava 100% kokybiška, tačiau akcentuojama, kad turi būti siekiama 100% kokybės iš pirmo karto. Kitu atveju įmonės sąnaudos stipriai išauga. Detalių instrukcijų kaip auklėti tiekėjus nėra, nes aiškinama kaip patiems š… nedaryti 🙂
        Jei procese bus neprognozuojamos kokybės žaliavos, proceso rezultatas laike bus neprognozuojamas. Tai reiškia, kad pirkėjui laiku nepristatysite prekių, savikaina išaugs daugiau nei planavote pardavinėdami, negalėsite planuoti gamybos procesų.
        Žaliavos kokybę turi užtikrinti tiekėjas. Gaunamų žaliavų kokybės patikrą gavimo metu atlieka kokybės inspektorius arba patys sandėlininkai. Pirkimų vadybininkai surenka iš tiekėjų nuolaidas už prastas žaliavas + 100 eurų už kiekvienos valandos darbą rūšiuojant žaliavas (skandinaviška praktika, su lean neturinti nieko bendro).

        Reply
        1. Tomas Gluosnis-Tyla

          Na, taip, Jūsų tiesa, 100% būna tik fantazijų pasaulyje. Aš norėjau akcentuoti būtent tai, kad mokoma, kaip teigėte patiems š….. nemalti ir nemokoma, ką daryti, jei žaliava bloga.
          Ir dar ką norėjau akcentuoti -- kad žaliavos gerumu reikia pasirūpinti iš anksto, gamybos atveju tai atlieka kokybės inspektoriai, sandėlininkai, o vadybininkai pasirūpina, kad būtų atlyginta žala.
          O šiuo atveju, kai žaliava tiekiama kliento -- žaliavos kokybe reikia pasirūpinti taipogi iš anksto, tiesiog reikėtų nuteikti klientą, kad kokybiško projekto pateikimas laiku gali įvykti tik tokiu atveju, jei visa informacija bus tvarkinga, tą turėtų daryti vadybininkai, kurie derina kontraktus su klientais.

          Reply
        2. Rokiškis Post author

          Viskas taip, tik dar pridėčiau, kad kokybės reikalavimai tiekėjams turėtų būti įvardinami, o jei yra galimybė, tiekėjai privalo būti parenkami, atsižvelgiant į kokybės reikalavimus.

          Reply
      2. Rokiškis Post author

        Vienas iš TQM principų -- užtikrinti kokybiškos žaliavos tiekimą, nes ji irgi turi būti valdoma. Žaliava nebūna savaime kokybiška -- jos kokybė turi būti užtikrinama.

        Vienas iš principų, kurie leidžia išspręsti nekokybiškos žaliavos problemą, kai nesigauna įtakoti tiekėjo -- tai taisyti neatitiktinę žaliavą kuo anksčiau procese, kad mažėtų likusių grandžių nenaudingas apkrovimas dėl broko, kuris į tas grandis gali ateiti.

        Būtent per tai ir padaroma, kad jau kai dedi gumą į konvejerį, būtum užtikrintas tos gumos kokybe 🙂

        Reply
    2. Andrius

      Čia primena mano situaciją, kai ateinu į kirpyklą susivėlęs ir peraugusiais plaukais. Kirpėja klausia kaip kirpti ? Atsakau, kad atrodytų gerai. Tai gaunasi, aš kaltas (bloga žaliava, specifikacija irgi ne kokia), tai negi kirpėja nebeatsakingą už rezultatą. Gaunas, kad ir kirpimo proceso nebėra kaip tobulinti ? 🙂 Be to, kaip įvertinti kas yra kokybiškas kirpimas ?)
      Kertinė LEAN idėja -- neatlikinėti veiksmų už kuriuos pirkėjas nenorėtų mokėti.
      Projektavimas -- ne paslauga ? Ar tikrai ? Jūsų manote, kad IT įmonėse užsakovai pateikio detalias ir tikslias specifikacijas ? 🙂 Jūsų minėtos problemos visiškai nėra unikalios 🙂 sakyčiau kasdieninės…

      Reply
      1. Tomas Gluosnis-Tyla

        Apskritai, daug kas įsivaizduoja, kad dirba unikalioje įmonėje specialiomis sąlygomis (maža rinka, ypatingi produktai ar paslaugos, požiūris „mes gaminam, o ne pardavinėjam“ ir pan.), todėl jų įmonė negali būti valdoma jokiais vadybos standartais, o tik standartu, kurį sugalvojo patys. Realiai unikalių situacijų beveik nebūna ir viską galima sustatyti pagal šiuolaikinius vadybos principus. Tik visada bus žmonių, kuriems tokie pokyčiai yra baisūs, todėl ir surandama krūva panašių „unikalių“ argumentų.

        Reply
      2. Cijunas

        Aš net neabejoju, kad iš vadybos pusės tos mano problemos yra visai ne unikalios. Tiesiog daugiausiai ką pastebiu, tai visos metodikos yra taikomos gamyboje. O su IT paslaugų sfera neteko susidurti, bet net neabejoju, kad ten irgi klientai nori kosmoso, t.y. tiekia blogą žaliavą. Tai kaip ten toj IT sferoj su bloga kliento žaliava tvarkosi Lean metodika?
        Dėl kirpimo proceso -- viskas per daug paprasta, o ir pinigai visai ne to lygio. Bet pats procesas dėl „prastos žaliavos“ turėtų užtrukti ilgiau ir kainuoti brangiau, tačiau dėl mažų pinigų bei trumpo laiko čia viskas nueina į emocijas (manyčiau). Klientas šiuo atveju supranta, kad bus brangiau ir ilgiau (priimkim, kad tai normalus žmogus, be išsidirbinėjimų). O projektavimo procesas yra pakankamai sudėtingas, trunkantis ilgai ir kainuojantis daug. Todėl jame atsiranda krūva „blogos žaliavos“ faktorių, kurie galutiniam rezultatui turi visokios įtakos. Gal ir čia viskas paprasta, nežinau.

        Reply
        1. Rokiškis Post author

          Su IT sfera yra atskiros metodikos, nes to kosmoso tenai yra pernelyg daug. Paslaugų tiekime tiesiog geros praktikos (ITIL, ypač svarbi yra SLM dalis), o programavime -- bene labai daugeliui dabar padeda Agile, ypač su ta bloga žaliava.

          Reply
    3. Rokiškis Post author

      Straipsnyje nekabinau projektinės pusės -- joje žymiai daugiau painiavos, nes projektas tuo ir skiriasi, kad kažkuriame iš pirmųjų etapų jis pats apsibrėžinėja savo veiksmus, skirtingai nuo proceso. Ir apie projektų valdymą ne vieną straipsnį būtų galima parašyti -- skirtumų yra labai daug.

      O kai projektinis vykdymas su neapibrėžtomis/kaitaliojamomis specifikacijomis (kas matosi iš tamstos komentaro) -- tai klasikinė projektinio valdymo problematika, kuri iš principo turi tik vieną sprendimą -- parodyti vartotojui, kad jis išlošia, jei didina apibrėžtumą ir mažina kaitaliojimus.

      Sakyčiau, tamstai reikia tarti, kad iš esmės, srautas priklauso nuo informacijos panaudojimo greičio, o tai reiškia, kad pralaidumą riboja tie faktoriai, kurie riboja galimybes greitai reaguoti į visą tą užvėlintą informaciją ir visokius jos pasikeitimus.

      Savo ruožtu, tai reiškia, kad procesą reikia perstatinėti taip, kad jis galėtų efektyviai vykti su užvėlintu startu. Pakankamai netrivialu.

      Gerindami, pabandykit tokį haką: darbus išskirti į dvi rūšis -- kietus ir minkštus. Kieti darbai -- tokie, kur apčiuopiami, su konkrečiais neišvengiamais laikais (pvz., kur iš principo neįmanoma kažko padaryti kardinaliai greičiau, nes riboja apdirbimo greitis), o minkšti -- informaciniai-organizaciniai, kur laikai daugeliu atvejų gali būti suspaudžiami, o jums tai aktualu, nes informacija jus stabdo.

      Išskyrus tuos minkštus darbus, jau galima pradėti paskirai minkštosios dalies matavimus ir pertvarkymus taip, kad ji įvyktų maksimaliai greitai -- kuo daugiau paralelizmo darbuose (užduočių skaidymas), kuo didesnė jų dalis perkelta į pirminius projekto etapus, kad būtų galima pereiti į greitą vykdymą pabaigoje ir kuo daugiau universalių paruoštukų, kaip pvz., excelių tipiniams skaičiavimams ir pan..

      To kieto-minkšto išskyrimo esmė labai paprasta: pirmiausiai identifikuoti tas vietas, kur galima gana saikingais sprendimais gauti pakankamai didelius išlošimus.

      Dar vienas dalykas, ką patariu -- tai pasidomėti bent minimaliai Agile metodais (jie labiau žinomi programuotojams, bet anie kai kuriais atžvilgiais labai artimi konstruktoriams) -- nors ir ne visada, bet jie kartais padeda, ypač kai reikia geriau susišnekėti su klientu, o iš jo turi būti grįžtamasis ryšys -- žodžiu, tipinėse neapibrėžtumo situacijose. Ir Agile labai gerai derinasi su Lean idėjomis -- nedaryti to, ko nereikia.

      O dėl Lietuvos projektavimo įmonių -- pas mus išvis projektų valdymas turi ganėtinai nemažai problemų -- jau paprasčiausiai pabandyti su Gantt čartais kažką planuoti -- tai ir tai neretai įmonei būna didelis iššūkis.

      Reply
      1. Cijunas

        Dėkoju už mintis. Bus ką pritaikyt tolesniame etape. Reiks pasiskaitinėti ir apie Agile, tik kažin ar ką panaudosiu tiesiogiai -- mat aš nevadovauju Lean diegimui, o esu tik vykdytojas. Užknisa tik tai, kad dabar dar tik pradžia, o mums duoda užduotis apie „trintukų kanbanus“ ir kitokius gamybos valdymo principus, nepaaiškindami, kad tai yra paprasčiausias mokymosi periodas apie Lean sistemą, ir viskas dar ateityje.
        Tikrai bus įdomu, jei kažką pavyks suvaldyti. Svarbu, kad valdžia į visiškus durnumus nenukryptų…

        Reply

Parašykite komentarą

El. pašto adresas nebus skelbiamas. Būtini laukeliai pažymėti *