Ühest poisist

Lugu on tõeline, ma olen seda oma silmadega näinud.

Mõned aastat töötas üks noormees, nagu paljud teist, programmeerijana. Igaks juhuks ütlen nii: "programmeeri". Sest ta oli 1C spetsialist, fikseeritud palgaga tootmisettevõttes.

Enne seda proovis ta erinevaid ametikohti – 4 aastat frantsiisi programmeerijana, projektijuhina, suutis teha 200 tundi, samal ajal teenides protsenti projektist, juhtimistasu ning tegelema veidi ka müügiga. Ta proovis iseseisvalt tooteid välja töötada, oli suurettevõtte IT-osakonna juht, kus töötas 6000 inimest, katsetas erinevaid viise oma kutse – 1C programmeerija – rakendamiseks.

Aga kõik need positsioonid olid mingil määral tupiktee, eelkõige sissetulekute poolest. Me kõik teenisime siis enam-vähem sama raha, töötasime samades tingimustes.

Sellele noormeest hakkas huvi pakkuma, kuidas teenida rohkem raha, tegelemata müügiga ja loomata oma äri.

Ta arvas end olevat geenius ning otsustas leida oma niši firmas, kus ta töötas. See nišš pidi olema eriline, keegi ei tohtinud seda hõivata. Ja ta soovis, et firma tahaks ise maksta sellele inimesele, et ei peaks kedagi petma või midagi meelevaldset välja mõtlema. See pidi olema objektiivne: sellele positsioonile tuleb palju maksta. Ühesõnaga, veider inimene.

Otsingud ei kestnud kaua. Firmas, kus see noormees töötas, oli täiesti vaba nišš, mida võiks nimetada „äri protsesside korrastamiseks“. Igas firmas on hunnik probleeme. Alati on midagi katki ja ei ole kedagi, kes tuleks ja parandaks äriprotsessi. Ta otsustas proovida ennast spetsialistina, kes suudab aidata omanikul oma äri probleemidega toime tulla.

Sel hetkel oli ta ettevõttes töötanud kuus kuud ja teenis turu keskmist palka. Kaotada ei olnud midagi — eriti kuna ta sai sama töö leida nädalaga. Ühesõnaga, see noormees mõtles, et ei juhtu midagi hullu, kui äkki ei õnnestu ja ta saadetakse lahti.

Ta kogus julguse ja läks omaniku juurde. Pakutas talle parendada kõige probleemsemat protsessi, mis ettevõttes oli. Selleks ajaks oli see laovaru haldamine. Praegu on kõigil, kes selles ettevõttes töötavad, isegi piinlik meenutada neid probleeme, kuid kvartali arvestused näitasid erinevusi raamatupidamissüsteemi ja tegelike varude vahel kümnete protsentide ulatuses. Nii väärtuse kui koguse ja ka kaubadeta. See oli tõeline mure. Ettevõttel olid tegelikult õiged varud raamatupidamissüsteemis ainult neli korda aastas – järgmisel päeval pärast inventuuri. Just selle protsessi meie poiss oligi hakanud korda ajama.

Noormees tegi omaniku jaoks lepingu, et vähendada inventuuri tulemuste kõrvalekaldeid poole võrra. Omanikul polnud suuri riske, kuna enne meie kangelast on erinevad töötajad proovinud kõike parandada, ja ülesanne peeti peaaegu lahendamatuks. See tõstis huvi, sest kui kõik õnnestub, muutuks noormees automaatselt isikuks, kes oskab korda luua ja lahendada lahendamatuks peetavaid probleeme.

Nii et tema ees seisis ülesanne: kahe aasta jooksul vähendada inventuuri tulemuste kõrvalekaldeid kaks korda. Projekti alguses ei osanud ta aimatagi, kuidas seda saavutada, kuid mõistis, et laoarvestus on lihtne asi, seega suudab ta ikka midagi kasulikku teha. Eriti kui kõrvalekaldeid vähendada kümnetest protsentidest paari protsendini - see ei tundu just ülemäära keeruline. Kõik, kes on töötanud konsultatsiooni või sarnastes valdkondades, mõistavad, et enamiku protsessiga seotud probleeme saab lahendada suhteliselt lihtsate tegevustega.

Jaanuarist maini valmistas taendusi, automatiseeris veidi, ümber kirjutas laoarvestuse äriprotsessi, muutis lao töötajate, raamatupidajate töövooge ja ümber kujundas kogu süsteemi, kellelegi midagi näitamata ja rääkimata. Mais jagas ta kõigile uusi juhiseid, ja pärast aastat esimest varude arvestust algas uus elu – töö tema reeglite järgi. Et tulemust jälgida, hakkas ettevõte edaspidi korraldama varude arvestusi tihemini – iga kahe kuu järel. Esimesed tulemused olid juba positiivsed, ja aastaks tuli auditi tulemuste kõrvalekalded alla vähem kui ühe protsendi.

Edu oli tohutu, kuid tema vastupidavusse ei usutud. Poiss ise kahtles, kas tulemus püsib, kui ta kõrvale astub ja protsessi jälgimist lõpetab. Siiski, tulemus oli olemas ja poiss sai kõik, milles omanikuga kokku leppis. Aastate möödudes kinnitati tulemuse püsivus – mitu aastat jäi kõrvalekaldeid 1% piiresse.

Siis otsustas ta eksperimenti uuesti teha ja pakkuda omanikule välja teise probleemse protsessi – varustamise parandamine. Seal olid puudujäägid, mis ei võimaldanud meil tarnida nii suures mahus, nagu meie kliendid soovisid. Lepiti kokku, et aasta jooksul vähenevad puudujäägid poole võrra ja too mees viib ellu veel 10-15 projekti, mis on seotud 1C-ga – erinevate äriprotsesside automatiseerimise ja muu taolisega.

Teisel aastal õnnestus jälle kõik edukalt lõpetada, puudujäägid vähenesid rohkem kui kahe korra, kõik IT-projektid lõpetati edukalt.

Kuna palk rahuldas juba täielikult selle mehe kõik nõudmised, vähemalt kaheks aastaks, otsustas ta natuke rahuneda, lõõgastuda ja istuda mugaval soojal kohal, mille ta ise endale lõi.

Mis see siis täpselt oli? Föderaalselt oli ta IT-direktor. Kuid kelleks ta tegelikult oli, on keeruline mõista. Mida teeb IT-direktor? Tavaolukorras haldab ta IT-infrastruktuuri, juhib süsteemiadministreerijate meeskonda, rakendab ERP-süsteemi ja osaleb koosolekutel direktorite nõukogus.

Sellel inimesel oli üks peamisi kohustusi osaleda muudatuste protsessides, peamiselt nende genereerimisel ja algatamisel, lahenduste otsimisel ja pakkumisel, uute juhtimismeetodite rakendamisel, pakutud muudatuste ekspertarvestuses, teiste funktsioonide ja osakondade tõhususe analüüsimisel ning viimaks – otsesel osalemisel ettevõtte strateegilises arengus, sealhulgas kogu ettevõtte strateegilise plaani iseseisval väljatöötamisel.

Talle anti vabakäekiri. Ta võis tulla igale koosolekule, kuhu varem ei pääsenud. Istus seal märkmeraamatu ja kirjutamisega või lihtsalt kuulas. Rääkis harva. Siis hakkas telefonis mängima – väitis, et nii on assotsiatiivne mälu paremini töös.

Koosolekul harva andis ta väljastpoolt midagi kasulikku. Lahkus, mõtles, siis tuli meil – kas kriitika, arvamus, ettepanekud või lahenduste kirjeldus, mida ta juba rakendanud oli.

Kuid enamasti organiseeris koosolekuid ikkagi ise. Leidis probleemi, mõtles välja lahendused, määras osalised ja tõi kõik koosolekuruumi. Seal läks juba nii, nagu oskas. Veenis, motiveeris, tõestas, vaieldes saavutas oma eesmärgid.

Ametlikult peeti teda ettevõttes kolmandaks isikuks, pärast omanikku ja direktor. Loomulikult häiris ta kõiki "ettevõtte isikuid", alates number 4. Eriti oma rebenenud teksade ja erksate T-särkide tõttu, aga ka omaniku maagiliste tundide tõttu.

Omanik pühendas talle iga päev 1 tunni. Iga päev. Nad rääkisid, arutasid probleeme, lahendusi, uusi äriideid, arendusvaldkondi, näitajaid ja tõhusust, isiklikku arengut, raamatuid ning lihtsalt — elu.

Aga see noormees oli kummaline. Näiliselt peaks just nagu olema rahul ja nautima elu, kuid ei. Ta otsustas hakata enesetäiendama.

Tahtis oli huvitav: miks tal õnnestus, aga teistel ei? Omanik sundis teda ka: ütles, et tahab, et teisedki suudaksid asju korda saada, kuna juhte on palju, nad tegelevad tavaliselt operatiivse juhtimise ja strateegilise planeerimisega, kuid praktiliselt keegi ei tegele oma protsesside süsteemsete muutustega. Nende tööülesannetes võib-olla on kirjas, et nad peavad kiirendama oma protsessi, suurendama selle tõhusust, aga tegelikult ei tegele sellega keegi. Miks nii? Poiss oli ka huvitatud, miks, ja läks rääkima kõigi nende juhtidega.

Ta läks kvaliteedi ase-direktori juurde ja pakkus välja Shuharti kontrollkaartide rakendamist, et tooted oleksid paremad kui jaapanlastel. Aga selgus, et kolleeg ei tea, mis on Shuharti kontrollkaardid, mis on statistiline protsesside juhtimine, ja ainult eemalt oli ta kuulnud Demingi tsükli rakendamisest kvaliteedijuhtimises. Nojah…

Ta läks teise direktori asetäitja juurde ja pakkus välja kontrollimise rakendamise. Kuid ka siin ei leidnud ta toetust. Veel hiljem kuulis ta piiride haldamisest (boundary management) ja pakkus kõigile asetäitjatele välja süsteemse osa selle metoodika rakendamiseks, et protsesse parandada. Kuid kui palju ta ka ei rääkinud, ei olnud keegi eriti huvitatud, millest jutt käib. Võib-olla polnud neile huvitav või oli see liiga keeruline. Kuid fakt on see, et keegi ei saanud aru.

Kokkuvõttes rääkis ta kõigest, mida teadis ja rakendas ettevõttes. Kuid keegi ei saanud temast aru. Neil on siiani arusaamatu, miks näiteks õnnestus laohaldusega kõik korda saada, miks selle juures on kontrollimine ja piiride haldamine.

Viimase asjana jõudis ta oma programmeerijateni – meeskonnas oli 3 inimest. Ta rääkis piiride haldamisest, kontrollimisest, kvaliteedihaldusest, agile'ist ja scrum'ist… Ja üllatuseks said nad kõik aru ning isegi suutsid temaga seda arutada, sealhulgas tehnilisi ja metoodilisi nüansse. Nad mõistsid, miks projektid laos ja tarnevaldkonnas välja tulid. Ja siis sai poisile selgeks: tegelikult päästavad maailma programmeerijad.

Programmeerijad, mõistis ta – on ainsad, kes suudavad normaalselt ja vajaliku detailsusega äri protsessidesse süveneda.

Miks just nemad? Tegelikult ei leidnud ta sellele küsimusele ühtegi kindlat vastust. Ta sõnastas ainult teemasid vihjeid.

Esiteks tunnevad programmeerijad ettevõtte tegevusvaldkondi ning tunnevad neid paremini kui keegi teine ettevõttes.

Lisaks mõistavad programmeerijad tõeliselt, mis on protsessi algoritm. See on oluline, sest äriprotsessid on algoritmid ning nende elemente võib olla lihtsalt mitteühendatud. Näiteks, hankimisprotsessis, mille kallal noormees töötas, on esimene samm aastase ostuplaani koostamine ja teine – igapäevane ostmine. Need sammud on omavahel tihedas seoses, tähendab, et inimesed peaksid töötama selle algoritmi alusel – koostama aastase ostuplaani ja kohe seejärel tegema tellimuse. Aastane ostuplaan koostatakse kord aastas, samas kui tellimusi esitatakse 50 korda päevas. Sellega algoritm lõpeb ja selle alusel tuleb töötada. Tegelikult, mõtles ta, on programmeerijatele algoritmide tundmine konkurentsieelis, sest keegi teine, kes ei ole nendega tuttav, ei mõista lihtsalt, kuidas äriprotsess peaks toimima ja kuidas seda ette kujutada.

Veel programmidel on üks suur eelis – nende arvates on neil piisavalt vaba aega. Me kõik mõistame, et programmeerija võib veeta ülesande täitmiseks kolm korda rohkem aega, kui see tegelikult peaks võtma, ja vähesed seda märkavad. See on taas konkurentsieelis, sest äri protsesside korrastamiseks on vaja palju vabast ajast — mõelda, jälgida, uurida ja katsetada.

Enamikul juhtmetest, nagu poiss ütleb, pole sellist vaba aega ja nad on sellega uhked. Kuid tegelikult tähendab see, et inimene ei saa tõhusaks, kuna tal pole aega tõhususe suurendamiseks — see on nõiaring. Meie kultuuris on moes olla hõivatud, seega jääb kõik paigale. Meile, programmeerijatele, on see eelis. Me suudame leida vabast aega ja mõelda kõigest.

Arendajad võivad kiiresti muuta teavet süsteemides. See ei kehti kõikide ettevõtete kohta, aga seal, kus ta töötas, sai teha igasuguseid muudatusi, mis ainult tahtmine oli. Eriti kui need ei puudutanud kellegi teise tööd. Näiteks sai ta käivitada süsteemi, mis salaja mõõdab kasutajate tegevust ja kasutada seejärel seda teavet — analüüsimiseks, kuidas raamatupidamine töötab ja jälgides raamatupidamise kulusid.

Viimane asi, mis mulle tema sõnadest meelde jäi – arendajatel on juurdepääs suurele hulgale teabele, kuna neil on süsteemisadministraatori õigused. Seetõttu saavad nad seda teavet oma analüüsis kasutada. Keegi teine tavalises tehases sellise ressursiga ei pea.

Siis lahkus ta. Kaks nädalat kohustuslikku teavitusaega jooksul sundisime teda jagama oma kogemusi, kuna soovisime jätkata tema teed. Samuti jäi tema koht вакантseks.

Mõne päeva jooksul panime ta toolile, lülitasime kaamera sisse ja salvestasime tema monolooge. Palusime rääkida kõigist lõpetatud projektidest, meetoditest, lähenemistest, saavutustest ja ebaõnnestumistest, põhjustest ja tagajärgedest, juhtide portreedest jne. Ei piiranud eriti, kuna ei teadnud, mis tal peas toimub.

Monoloogides oli muidugi peamiselt igasugust jubedust ja nalja — ta oli suurepärases tujus, kuna lahkus ääremaast Peterburi. Aga kuhu Peterburis tööle minna? Gazpromisse, loomulikult.

Aga mõningaid kasulikke asju suutsime tema monoloogidest välja tuua. Räägin, mis mulle meelde jäi.

Nii et soovitused sellelt noormehelt. Neile, kes tahavad proovida äritegevuse korraldamisega tegeleda.

Selle töö tegemiseks on kõigepealt vajalik teatud määral "külma närvi". Ei tohi karta töö kaotamist, ei tohi karta riske võtta, ei tohi karta konfliktide tekkimist kolleegidega. Temal tuli see kergesti välja, kuna ta alustas oma teed alles siis, kui oli ettevõttes töötanud ainult kuus kuud ning ei olnud kellegagi ühtegi kontakti loonud ega planeerinud seda teha. Ta mõistis, et inimesed tulevad ja lähevad, kuid tema jaoks on olulised ainult tema enda tulemused ja nende hindamine ettevõtte omanikult. Kolleegide negatiivne või positiivne suhtumine ei huvitanud teda tol ajal kuigivõrd.

Teine punkt on see, et selle töö tõhusaks tegemiseks tuleb kahjuks õppida. Kuid mitte MBA-d, mitte kursustele, mitte institudi raames, vaid iseseisvalt. Näiteks oma esimeses projektis, mis oli seotud lao juhtimisega, tegutses ta intuitsiooni põhjal, teadis vähe, ainult seda, mis on "kvaliteedihaldus".

Kui ta hakkas lugema kirjandust, et mõista, millised tõhususe suurendamise meetodid olemas on, avastas ta tehnoloogiad, mida ta juba kasutas. Poiss kasutas neid intuitsiooniliselt, aga osutus, et see ei olnud tema leiutis – kõik oli juba ammu kirja pandud. Kuid ta raiskas aega, ja palju rohkem, kui oleks tad olnud, kui ta oleks otse õige raamatu läbi lugenud. Siin on oluline mõista, et kui uurid konkreetset meetodit, ei lahenda ükski neist, isegi kõige kõrgem, täielikult kõiki äriprotsessi probleeme.

Teine nüanss on see, et mida rohkem meetodeid sa tead, seda parem. Näiteks elunes muistses Jaapanis Miyamoto Musashi – üks kõige tuntumaid mõõgaheitjaid, kahe mõõga stiili autor. Ta õppis mingis koolis mõnelt meistrilt, seejärel reisides ringi Jaapanis, võitles ta erinevate meestega. Kui vastane oli tugevam, siis tema teekond peatati ja Musashi läks õpilaseks. Tulemuseks oli see, et ta omandas mitme meistri erinevaid praktikaid ja kujundas omaenda kooli, lisades midagi enda oma. Lõpuks saavutas ta ainulaadse oskuse. Siin on sama lugu.

Muidugi võime käituda ärianalüütikutena. Nad on tõesti häid inimesi. Kuid tavaliselt tulevad nad, et rakendada mingit meetodit, ja rakendavad mitte seda meetodit, mida ettevõte vajab. Meil on olnud ka selliseid kurbi olukordi: keegi ei tea, kuidas probleemi lahendada, ja keegi ei taha mõelda, kuidas seda lahendada. Alustame otsimist kas internetist või kutsume konsultandi ja küsime temalt, mis võiks meid aidata. Konsultant mõtleb ja ütleb, et peaks rakendama piirangute teooriat. Me maksame talle soovituse eest, kulutame rakendamisele, aga tulemus on null.

Kuidas see nii juhtub? Sellepärast, et konsultant ütles, et rakendame sellise süsteemi, ja kõik nõustusid sellega. Suurepärane, aga üks meetod ei kata kõiki probleeme isegi ühe äri protsessi puhul, eriti kui lähtetingimused ei kattu – meie omad ja need, mis on vajalikud meetodi rakendamiseks.

Praktikas, mida soovitab noormees, tuleb võtta parim ja rakendada parimat. Mitte võtta meetodeid tervikuna, vaid võtta nende võtmeomadused, nipid, praktikad. Ja kõige olulisem – tuleb mõista sisu.

Võtame näiteks scrumi või agile'i. Noormees kordas monoloogides mitu korda, et kõik ei mõista täielikult scrumi olemust. Ta luges ka Jeff Sutherlandi raamatut, mida mõned peavad "kergeks lugemiseks". Tema jaoks tundus see sügava sisuga, sest üks scrumi põhialuseid on kvaliteedi juhtimine, millest raamat otseselt räägib.

Seal on juttu Toyota tootmisest, sellest, kuidas Jeff Sutherland tutvustas scrum'i Jaapanis, kui hästi see seal juurdus ja kui lähedane see nende filosoofiale oli. Sutherland rääkis scrum-masteri rolli tähtsusest ning Demingi tsüklist. Scrum-masteri roll on protsessi pidev kiirendamine. Kõik muu, mis scrum'isse kuulub – etappidena üleandmine, kliendi rahulolu, selge tööde nimekiri sprindi perioodiks – on samuti oluline, kuid kõik see peab toimuma järjest kiiremini. Töö kiirus peab pidevalt tõusma nendes mõõtühikutes, milles seda mõõdetakse.

Võib-olla on asi tõlkes, sest meil tõlgiti raamat kui „Scrum – revolutsiooniline projektijuhtimise meetod“, kuigi sõna-sõnalt ingliskeelset pealkirja tõlkides saame: „Scrum – kaks korda rohkem poole lühema ajaga“, mis viitab kiirusel kui scrumi võtmeomadusele.

Kui see kutt scrumi rakendas, siis suurenes kiirus esimesel kuul kahekordselt ilma eriliste muudatusteta. Ta leidis muudatuste kohad, kohandas scrumi enda vajadustele, et see töötaks palju kiiremini. Ainuke, nagu internetis kirjutatakse, — nende ees kerkis küsimus: „Me oleme kiirust kahekordistanud, nüüd tuleb aru saada, mida me sellise kiirusaga teeme?“. Kuid see on juba hoopis teine valdkond…

Ta soovitas ka isiklikult mitmeid meetodeid. Nimetas neid fundamentaalseteks ja peamisteks.

Esimene — boundary management (piiride juhtimine).

Seda õpetatakse «Skolkovo» programmis, muid raamatuid ja materjale noormehe sõnul pole. Talle on õnnestunud osaleda Harvardi professori loengus, kes räägib piiride juhtimisest, ning lugeda mitmeid artikleid Harvard Business Review's Eric Trista töödest.

Piiride juhtimine tähendab, et tuleb osata näha piire ja nendega töötada. Piire on palju, need on kõikjal — erinevate osakondade vahel, erinevate tööde vahel, funktsioonide vahel, operatiivse ja analüütilise töö vahel. Piiride juhtimise teadmine ei avada mingeid kõrgemaid tõdesid, kuid võimaldab näha reaalsust teises valguses — läbi piiride prisma. Seega on võimalik neid juhtida — rajada seal, kus see on vajalik, ja eemaldada seal, kus need segavad.

Kuid sagedamini rääkis noormees kontrollimisest. Tal oli sellel teemal tõeline kinnisidee.

Kontrollimine, kui lühidalt öelda — see on juhtimine numbrite alusel. Siin on, ütles ta, oluline iga osa määratlusest — nii «juhtimine», «alus» kui ka «numbrid».

Meie puhul, ütles ta, on kõik kolm kontrollingu komponenti kehvasti. Eriti arvestades, et need on tihedalt seotud omavahel ja teiste ärisüsteemi osadega.

Esimene halb asi on numbrid. Need on vähesed ja madala kvaliteediga.

Oluline osa numbritest tuli toona meie infosüsteemist 1С. Ning kvaliteet, nagu ta väitis, on 1С-is täiesti kehv. Kõige vähem, sest andmeid on võimalik tagantjärele muuta.

On selge, et 1С arendajate süü selles ei ole — nad arvestavad lihtsalt turu nõudmisi ja kohalikke raamatupidamise mentaliteete. Kuid kontrollingu eesmärkide jaoks oleks parem muuta 1С andmetöötluse põhimõtteid konkreetses ettevõttes.

Edasi, ütles ta, läbivad 1Сist saadud numbrid poolteis käsitsi töötlemist, näiteks Exceli abil. Selline töötlemine ei too andmete kvaliteeti, ega ka operatiivsust.

Lõpuks kontrollib lõpparuannet keegi veel, et juhile ei saadetaks kogemata valeid numbreid. Tulemuseks on, et numbrid jõuavad saajani ilusana, kontrollituna, kuid väga hilja. Tavaliselt pärast perioodi lõppu (kuu, nädala jne).

Ja siin ütles ta, et kõik on väga lihtne. Kui jaanuari numbrid jõudsid teieni veebruaris, siis ei saa te jaanuari tegevust enam juhtida. Sest jaanuar on juba läbi.

Ja kui numbrid põhinevad raamatupidamisel ja ettevõte on täiesti tavaline, millel on kvartaalne käibemaksu esitamine, siis saab ettevõtte juht enam-vähem adekvaatsed numbrid kord kvartalis.

Edasi on juba selge. Kui saate numbrid kord kuus, siis on teil võimalus juhtida numbrite põhjal (st teostada kontrollimist) 12 korda aastas. Kui praktiseerite kvartali aruandlust, siis juhtite 4 korda aastas. Lisaks boonusena - aastaaruandlus. Veel kord roolida.

Ülejäänud aja jooksul toimub juhtimine enamasti pimedalt.

Kui (ja kui) numbrid lõpuks ilmuvad, siis tuleb mängu teine probleem - kuidas numbrite põhjal juhtida? Selle punktiga tema mõtisklustes ma nõustuda ei saanud.

Noormees väitis, et kui juht ei ole varem numbreid näinud, siis nende ilmumine tekitab wow-efekti. Ta vaatab ja keerab numbreid igas suunas, kutsub inimesi kokku, nõuab selgitusi ja uurimisi. Numbritega mängides, analüüse tehes ning ähvardavalt lubades kõigile töötajatele, et "nüüd ma ei lase teil küll jalga", rahuneb juht kiiresti ja loobub sellest tegevusest. Tööriista kasutamine katkeeb. Probleemid jäävad aga alles.

Nii juhtub, ütles ta, juhi ebapiisavate oskuste tõttu. Eelkõige kontrollimise osas. Juht ei tea lihtsalt, mida nende numbritega ette võtta. Mis koosteha - teab, aga kuidas teha - ei tea. Teha - see on see, millest eespool räägitud (kriitika, mängimine). Tegutsemine - see on igapäevane äritegevus.

Ta väitis, et kõik on väga lihtne: number peab olema osa äri protsessist. Äri protsessis peab olema selgelt määratletud: kes, mida ja millal peab tegema juhul, kui number ei vasta normile (iga variandi - üle piiride, alla piiride, koridori ületamine, trendi olemasolu, kvantiilide mittetäitmine jms).

Ja ja tähendas tähtsat dilemmasid: numbrid on olemas, need peavad saama osa ärisüsteemist, et suurendada juhtimise tõhusust, kuid... seda ei toimu. Miks?

Kuna Vene juhi ei anna konkurendile osa oma võimust.

Vene juhi konkurendid — kvaliteetsed ja toimivad äriprotsessid, läbimõeldud vastastikku kasulik motivatsioon ja õige automatiseerimine — kahjuks jätavad juhi ilma töökohast.

Nonsense, nõustute? Eriti juhidest. Olgu, ma rääkisin, nüüd otsustage ise.

Veidi vähem, aga ikka liiga palju, minu arvates, rääkis ta scrumi kohta.

Tähtis, ütles ta, loe ja proovi scrumi praktikas. Kui, ütleb ta, olete lugenud, aga pole proovinud — arvestage, et te ei tea. On parem lugeda raamatut, näiteks Sutherlandilt, mitte artikleid ja igasuguseid juhendeid (mis asi see on?) internetis.

Scrum, ütles ta, mõistetakse ainult praktika kaudu, ja kohustuslike mõõtmistega tehtud töö mahust. Proovige isiklikult kahte tähtsamat rolli — toote omaniku ja scrum juhi.

Eriti oluline on, meeste sõnul, praktikas tunnetada skram-meistri rolli, kui suudate suurendada sprindis lahendatud ülesannete arvu, ilma et see tõstaks ressursse ja sprindi maksumust.

Tema nimekirjas oli veel TOC (süsteemide piirangute teooria).

Need on, meeste sõnul, põhialused efektiivsuse tõstmiseks, mida saab rakendada praktiliselt igas valdkonnas, igas äriprotsessis ja ärisüsteemis tervikuna.

Kui ta sai teada, et me ei tunne TOC-d, lõpetas ta rääkimise. Ta lisas vaid, et ei kavatse meid jätta ilma Eliyahu Goldrathti raamatute lugemise naudingust. Soovitus oli analoogne skramiga — lugege ja proovige. Tüüpiline, sõltumata teie ametist või tehtavast tööst, leidub seal võimalusi efektiivsuse tõstmiseks TOC meetoditega.

Siis ilmselt sai tema meetodite pagas otsa, ning ta ütles: segage põhimõtteid, et luua rakendusi konkreetsete olukordade lahendamiseks.

See, ütles ta, on peamine soovitus, edu võti. Mõistke põhimõtteid, olemust ja looge ainulaadsed rakendavad lahendused — äriprotsessid ja ärisüsteemid.

Siis püüdis ta meenutada mõnda tsitaati ja lõpuks pidi internetist otsima. Selgus, et tsitaat on Eliyahu Goldratt'i artiklist "Gigantide õlgadel seistes":

„On erinevus rakenduslahenduste (rakenduste) ja fundamentaalsete kontseptsioonide vahel, millel need lahendused põhinevad. Kontseptsioonid on üldised, rakenduslahendused - need on kontseptsioonide kohandamine konkreetsele keskkonnale. Nagu me juba nägime, ei ole selline kohandamine lihtne ning see teeb vajalikuks teatud lahenduse elementide väljatöötamise. Peame meeles pidama - rakenduslahendus põhineb algsetel eeldustel (mõnikord varjatud) konkreetse keskkonna kohta. Ära oota, et see rakenduslahendus töötaks keskkonnas, kus algsed eeldused ei kehti.“

Ta ütles, et programmist ja „äritegevuse protsesside lihtsustamisest“ on väga sarnased. Ja lahkus.

Allikas: habr.com