Ieškote idealios vadybos metodikos?

projektai_gamyba

Kažkada jau rašiau, kad dauguma metodikų ne konkuruoja, bet papildo viena kitą. Tiesa, tada paminėjau tik TLS, o dabar apkalbėsime kitas metodikas.

Kažkada besimokant KTU ir griaužiant storas knygas apie mikroprocesorių gamybą, dėstytojas drėbtelio frazę „Susipažinkite su medžiaga, bet jūs vis vien nepateksite tarp tų 100 inžinierių, kurie iš tikro projektuos mikroprocesorius“. Ne itin motyvuojanti frazė, bet nuleidžianti ant realios žemės. Todėl ilgą laiką nesidomėjau “kosminiais laivais“.

Bet taip jau nutiko, kad paskutiniais metais vis dažniau tenka susidurti su įmonėmis, vykdančiomis po 1000 ir daugiau aktyvių projektų, arba gaminančių tūkstančius unikalių gaminių. Tokių įmonių vadovai juokauja, kad jie dirba masinės gamybos aplinkoje, skirtumas tas, kad tai unikalių gaminių masinė gamyba. O joje praktiškai nieko standartinio arba standartizuojamo nėra. Ir realiai nei LEAN, nei Six Sigmos jiems padėti negali. Ir tokiose įmonėse darbuotojai yra priskiriami knowledge works genčiai, todėl čia visos įmonės rezultatai kartais priklauso net nuo mėnulio fazės.

Taigi kas tokiose įmonėse gali būti standartizuota siekiant padidinti įmonės našumą? Vienintelė vieta, kur aš įžvelgiu galimybę, yra vadybos sistema. O dabar pakelkite ranką, kas žino metodiką, tinkančią unikalių gaminių masinei gamybai?

Tiesą pasakius, ir aš nežinau. Bet žinau, kad visos metodikos sukurtos konkrečiai problemai spręsti. Dažniausiai, kad geriau suprastume problemą, mes ją izoliuojame nuo aplinkos. Kai sprendimas surastas, pradedame taikyti praktikoje, ir tada suprantame, kad nenumatėm visos krūvos aplinkybių. Todėl savo metodiką aplipdome prielipomis. Po kiek laiko per prielipas nebesimato, kam ta metodika buvo sukurta, bet svarbiausia – tos prielipos pradeda persidengti su kitomis metodikomis ir jas atkartoti. Ir dažnai atkartoja ne visai tiksliai, o taip, kaip tą prielipą kažkas sumąstė. Dėl šitų skirtumų prielipa atrodo unikali, bet iš principo ji sprendžia tą pačią problemą, kaip ir kita metodika. Kodėl mums tokios prielipos svarbios? Todėl, kad tada mes galime rasti sąlyčio taškus tarp skirtingų metodikų ir jas apjungti į vieną didelį „kosminį laivą“.

O dabar jau informacija apie paveiksliuką. Čia mes kartu su LSI pasakojam apie projektų valdymą statybininkams. Ir rodome, kad direktoriui įdomu tik projekto pradžia ir pabaiga, nes tai susiję su pinigais. Viskas, kas tarpuose, direktorių domina tik tiek, ar galime išstatyti sąskaitą klientui.

Jeigu žiūrėsime į antrą lygį, tai ten pluša vargšai projektų vadovai. Jiems reikia viską pasidetalizuoti, kas vyksta jų projekte, kad laiku suspėtų sugalvoti pasiaiškinimą. Bet jų visai nedomina kiti įmonės projektai, ir jeigu gali, stengiasi nesiaiškinti, kas kasdien vyksta darbų aikštelėje. Tam yra kiti atsakingi darbuotojai. Taigi lieka tik objekto vadovas, besidomintis darbų frontu artimiausioms 2-8 savaitėm, ir brigadininkas, besirūpinantis, kas bus daroma šiandien. Kaip matome, turime 4 lygius, ir visur sava specifika, visur reikia aiškios metodikos, kaip valdyti tokią struktūrą.

Atėjo laikas prisiminti kosminius laivus. Taigi, ką daryti vadovui, kai turi 1000 aktyvių projektų? Tada supranti, kad mano, kaip vadovo, dėmesys tampa apribojimu. Apie tai, kaip vadovo dėmesys tampa apribojimu, parašysiu kada nors vėliau. O dabar sutarkime, kad vadovas tiesiog supranta, kad reikia priimti efektyvius sprendimus, ir kuo efektyviau išnaudoti įmonės išteklius. Aš kalbėjau apie projektinę įmonę, kur turėtų suveikti projektų portfelio valdymas (PMO), bet realiai nuskambėjo kaip gamybinės įmonės vadovo dilema.

Realiai, kai egzistuoja 1000 atvirų projektų, gilintis į juos nėra laiko, reikia tiesiog stovėti prie vartų ir priimti sprendimus, kada į įmonės vidų įleidžiame naujus projektus. Va čia ir padeda mums gamybos valdymo sistema. Jų yra daug, bet aš toli neieškosiu ir paimsiu DBR. Kas gerai su DBR metodika, tai kad labai lengva rasti informaciją, kaip ją įsidiegti, ir su visais paaiškinimais, kodėl kiekvieną elementą reikia turėti save įmonėje. Taigi štai kas ten pasakyta apie vadovus. Jiems reikia stebėti, kur viskas kaupiasi (WIP – work in progress), kad galėtų valdyti apribojimą. Na, gamyklose tai labai paprasta: ten, kur susikaupia atsargos, ten ir yra ribojantis išteklis. O kaip paslaugų įmonėse? Kai įmonė bando suvaldyti 1000 projektų, pas ją jau yra šiokia tokia biurokratija. Todėl tokioje įmonėje reikia sekti dokumentų srautą, ir ten, kur jis užsilaiko, tenai ir turime ribojantį faktorių. Tiesa, apie tai aš jau rašiau. Atrodo radome metodiką, kuri patenkintų įmonės vadovą.

O kokia metodika patenkintų projektų vadovą? Turbūt kvailas klausimas. Žinoma, kad kokia nors populiari projektų valdymo metodika! Tiesa, pastaroji turėtų kažkaip susijungti su vadovo metodika, nes kitaip gausis kaip tame anekdote: atėjo projekto vadovas pas direktorių su savo nuomone, išėjo su direktoriaus nuomone.

Ta proga perverčiau tuziną projektų valdymo metodikų ir nieko gero neradau. Dar nebuvo projektų valdyme tokios prielipos. Visi gyveno vieno projekto aplinkoje. Laikas praėjo, o daugiaprojektinė aplinka nedingo, todėl metodikos apaugo prielipomis, kaip elgtis, kai projektų daug, o direktorius vienas. Va čia dar kartą papuolė CCPM (Critical Chain Project Management), kur diegimo dokumente pirmu punktu nurodyta, kad reikia valdyti projektų kiekį, t.y. jau minėtą WIP. Tiesa, nepaaiškinta, kaip nustatyti WIP, bet paaiškinta kodėl. O WIP nustatymo metodika yra gamyboje. Panašu, kad radome kur galime gamybos valdymo metodiką apjungti su projektų metodika.

Jeigu jau direktorius ir projektų vadovas dirba sinchronizuotai, tai dabar beliko sinchronizuoti ir likusią projekto komandą. Tiksliau, mums reikia labai efektyvios užduočių valdymo metodikos (task management). Va būtent su užduočių valdymų šlubuoja visos projektų valdymo metodikos. Ir aš ilgai ieškojau sprendimo, tam tikru metu atsirado Agile. Kažkaip Agile manęs neįtikino, bet Scrum susikoncentravo ir įrodė savo privalumus. Ir čia kilo klausimas, o kaip man dabar sujungti Scrum su bet kokia projektų valdymo metodik? Jau girdžiu, kaip Scrum gerbėjai aiškina, kad aš neteisus, bet tada pagalvokite, o kuo užsiima produkto savininkas (product owner)? Na va, ir aš apie tą patį. Kol kas neaišku, kaip Scrum jungti, tiesa, paveikslėlyje nurodoma, kad reikia žinoti darbų frontą 2-8 savaitėm. Ir tai primenta – Scrum Sprint‘us.

Ką gi, atrodo aš busiu teisus: visos metodikos laikui bėgant apsitraukia limpančiu sluoksniu. Bet kol kas nelipo, nors ir yra sąlyčio taškas. Ir visai neseniai Google Plus diskusija dėl backlog užvedė ant minties. Backlog pagrindinė paskirtis yra paruošti užduočių frontą vykdymui. O CCPM diegimo dokumente yra labai didelis akcentas apie užduočių paruošimą vykdymui (Full kit). Ir čia jau yra vadybinis sąlyčio taškas. Todėl galima sinchronizuoti projektų valdymą su Scrum metodika. Tiesa, kol kas gavosi tik į vieną pusę, t.y. iš projektų valdymo galima perduoti užduotis per backlog, bet kaip gauti informaciją atgal? Tai neatrodo didelė problema, nes projekto vadovui įdomu tik viena – “kada pabaigsime?”. Būtent tokią informacija pateikia „Sprint Burndown Chart“.  Na va, panašu, kad ir projekto vadovą pavyko sinchronizuoti su savo projekto komanda. Nors projekto komanda naudoja kitokią metodiką savo darbams valdyti, negu projekto vadovas.

Kažkaip paskutiniu metu vis labiau į metodikas žiūriu kaip į Lego kaladėles. Vienos didesnės, kitos mažesnės. Ir visos jau pakankamai apaugusios, kad būtų galima vieną su kita sujungti. O kiek reikia įmonėje naudoti metodikų, tai jau priklauso nuo to, kokį Lego miestą statysite. Jeigu vykdote 1 projektą, tai gal užteks Scrum, jeigu 20 – tai jau be projektų valdymo neišsiversite (vien tik dėl to, kad reiks primityvaus išteklių valdymo). O jeigu jau perlipote 100 projektų, turite turėti projektų valdymo metodiką su gamybos valdymo metodikų priemaišomis. Svarbiausia, neužmiršti visas metodikas sinchronizuoti, užuot bandžius įdiegti kurią nors vienintelę ir neklystančią, nes kitaip kursite savo prielipas. O, va, naujų prielipų kūrimas – tai brangus ir skausmingas kelias, geriau beždžioniauti.

Komentarų dar nėra, tad jūsiškis bus pirmasis.

Jūsų komentaras