Üks noormees,

Tegel on tõeline, ma nägin kõike oma silmaga.

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

Enne seda oli ta proovinud erinevaid erialasid – neli aastat frantsiisi programmeerijana, projektijuhi ametikoht, suutis sulgeda kuni 200 tundi, samal ajal saades protsendipalku projektist ning tegelema veidi müügiga. Ta proovis iseseisvalt tooteid arendada, oli suure ettevõtte IT-osakonna juht, millel oli 6000 töötajat, ja katsetas oma eriala – 1C programmeerijat – erinevaid rakendusi.

Aga kõik need ametid olid üsna lootusetud, peamiselt sissetuleku pärast. Me kõik saime siis enam-vähem ühte ja sama raha, töötasime sama laadi tingimustes.

Sellele noormeest hakkas huvitama, kuidas võiks rohkem raha teenida, mitte müügiga tegelema ega oma äri looma.

Ta kujutas end nutikaks ja otsustas leida oma koha ettevõttes, kus ta töötas. See koht pidi olema mingi eriline nišš, mida keegi ei valda. Ja tal oli soov, et ettevõte ise sooviks selle niši eest inimesele raha maksta, et ei peaks kedagi petma või midagi üle paisutama. Et see oleks objektiivne: sellele positsioonile tuleb maksta palju raha. Ühesõnaga, veidrik.

Otsingud ei kestnud kaua. Ettevõttes, kus see noormees töötas, avanes täiesti vaba nišš, mida võiks tinglikult nimetada "korralduse loomine äriprotsessides". Igas ettevõttes on hulgaliselt probleeme. Alati on midagi, mis ei tööta, ja pole kedagi, kes tuleks ja parandaks äriprotsessi. Nii et ta otsustas proovida olla spetsialist, kes saab aidata omanikku tema äriproblemide lahendamisel.

Sel hetkel oli ta olnud ettevõttes kuus kuud ja teenis keskmiselt turuhinda. Kaotada polnud midagi – veelgi enam, et sama töö leidmine ei olnud tal problemaatiline nädalaga. Ühesõnaga, see noormees mõtles, et midagi hullu ei juhtu, kui äkki ei tule välja ja ta vallandatakse.

Ta kogus end kokku ja läks omanikule lähenema. Ta pakkus välja, kuidas parandada kõige problemaatilisemat protsessi, mis ettevõttes oli. Tookord oli see laovarude arvestus. Praegu on kõigil, kes selles ettevõttes töötavad, isegi piinlik meenutada neid probleeme, kuid kvartaalsetel inventuuridel leiti süsteemi ja tegelike jäänuste vahel tosin protsenti erinevusi ning seda nii väärtuse kui ka koguste ja soovitud positsioonide hulga osas. See oli tõeline katastroof. Ettevõttel olid õiged jäänused raamatupidamissüsteemis vaid neli korda aastas – inventuurile järgnev päev. Just selle protsessi viis meie peategelane korda.

Noormees kokkuleppis omanikuga, et peab vähendama inventuuri tulemuste varieeruvust viiekordselt. Samas ei olnud omanikul eriti midagi kaotada, sest enne meie kangelast olid erinevad töötajad proovinud olukorda parandada ja ülesanne peeti peaaegu lahendamatu. See kõik suurendas huvi, sest kui kõik õnnestub, saaks mehest automaatselt inimene, kes oskab korda luua ja lahendada näiliselt lahendamatu ülesande.

Nii et tal oli ülesanne: vähendada inventuuri tulemuste erinevusi aastaga kahe korra võrra. Projekti alguses ei osanud ta ette kujutada, kuidas seda saavutada, aga ta sai aru, et laovarude arvestus on lihtne asi, seega õnnestub tal ikkagi midagi kasulikku teha. Eriti arvestades, et vähendada erinevusi kümnete protsentide juures kuni üheksakümne protsendini ei tundu ju nii keeruline. Kõik, kes on töötanud konsultatsioonide või sarnaste tegevuste valdkonnas, mõistavad, et enamik protsessiprobleeme saab lahendada üsna lihtsate tegevustega.

Alates jaanuarist maini valmistus ta ette, automatiseeris veidi, ümber kirjutas laoarvestuse äriprotsessi, muutis laohoidjate, raamatupidajate töövooge ja tegelikult kogu süsteemi, näitamata ega rääkides kellelegi. Mais jagas ta kõigile uued juhised, ja pärast esimest inventuuri sel aastal algas uus elu – töö tema reeglite järgi. Tulemusi jälgides hakkas ettevõte tulevikus inventuure tihemini korraldama – iga kahe kuu tagant. Esimesed tulemused olid juba positiivsed, ja aasta lõpuks vähenesid revideerimise kõrvalekalded alla ühe protsendi.

Edu oli kolossaalne, kuid selle püsivusse ei usutud. Isegi noormees kahtles, et tulemus püsib, kui ta kõrvale astub ja protsessi jälgimise lõpetab. Sellegipoolest oli tulemus olemas, ja poiss sai kõik, milles omanikuga kokku oli lepitud. Aastate möödudes kinnitati tulemuse püsivus — mitme aasta jooksul püsisid kõrvalekalded 1% piires.

Siis otsustas ta eksperimenti korrata ja pakkus omanikule teise probleemse protsessi – tarne – täiustamist. Seal olid puudujäägid, mis ei võimaldanud tarnida selliseid koguseid, nagu meie kliendid soovisid. Lepiti kokku, et aasta jooksul vähenevad puudujäägid poole võrra, ning tüüp täidab ka 10-15 projekti, mis on seotud 1C-ga – erinevate äriprotsesside automatiseerimise ja muu sälitsege.

Teisel aastal õnnestus kõik taas edukalt lõpetada, puudujäägid vähenesid rohkem kui kaks korda, kõik IT-projektid olid edukalt lõpetatud.

Kuna palk rahuldas juba täielikult kõik selle noormehe soovid, otsustas ta natuke rahuneda, rahulikult istuda ja nautida mugavat sooja kohta, mille ta ise endale loonud oli.

Mis see tegelikult endast kujutas? Formaalselt oli ta IT-direktor. Kuid kes ta tegelikult oli, on raske mõista. Mida IT-direktor tavaliselt teeb? Reeglina haldab ta IT-infrastruktuuri, juhib süsteemi administreerijaid, rakendab ERP-süsteemi, osaleb juhatuse koosolekutel.

Selle mehe üks peamisi kohustusi oli osaleda muutmisprotsessides, eelkõige nende genereerimisel ning algatamisel, lahenduste otsimisel ja pakkumisel, uute juhtimismeetodite rakendamisel, ettepanekute ekspertülevaatamisel, teiste osakondade ja funktsioonide efektiivsuse analüüsimisel ning lõpuks – otsekohe osaleda ettevõtte strateegilises arendamises, sealhulgas kogu ettevõtte strateegilise plaani iseseisval koostamisel.

Talle anti vabad käed. Ta võis osaleda igas koosolekus, kuhu tal varem ligipääsu ei olnud. Istus seal vihikuga, midagi üles märkides või lihtsalt kuulates. Rääkis harva. Siis hakkas telefonis mängima – väitis, et nii töötab assotsiatiivne mälu paremini.

Koosolekutel andis ta harva midagi kasulikku. Läks minema, mõtles, siis tuli e-kiri – kas kriitika, arvamus, ettepanekud või lahenduste kirjeldus, mida ta juba rakendanud oli.

Aga tihti korraldas ta koosolekuid ise. Leidis probleemi, mõtles välja lahenduse variandid, määras asjaosalised ja tõi kõik läbirääkimistuppa. Ja seal – kuidas oskas. Veenis, motiveeris, tõestas, vaielas, saavutas.

Mittetehniliselt peeti teda ettevõttes kolmandaks isikuks, peale omaniku ja direktori. Loomulikult häiris ta kõiki ettevõtte "isikuid", alustades neljandast. Eriti oma rebitud teksade ja erkade T-särkidega, aga ka omaniku olemasolu ajal.

Omanik pühendas talle iga päev 1 tunni. Igal päeval. Nad rääkisid, arutasid probleeme, lahendusi, uusi äriideid, arengu suundi, tulemusi ja efektiivsust, isiklikku arengut, raamatuid ja lihtsalt – elu.

Aga see poiss oli kummaline. Nagu öeldakse – istu ja naudi, elu on korda läinud. Aga ei. Ta otsustas mõelda.

Talle sai huvitav: miks tal õnnestus, aga teistel mitte? Omanikki suunasin teda: ütles, et soovib, et teistel ka õnnestuks korda luua, sest juhte on palju, nad tegelevad enamasti operatiivse juhtimise ja strateegilise planeerimisega, aga praktiliselt keegi ei pühendu oma protsesside süsteemsetele muudatustele. Nende ametijuhendis võib-olla on kirjas, et nad peaksid oma protsessi kiirendama, parandama selle tõhusust, aga tegelikult ei tegele sellega keegi. Miks nii? Ka noormeest huvitas, miks, ja ta läks rääkima kõikide nende juhiga.

Ta läks kvaliteedi asedirektori juurde ja pakkus välja Schuharti kontrollkaardi rakendamise, et tootmine oleks parem kui Jaapanis. Aga selgus, et kolleeg ei teadnud, mis asi need Schuharti kontrollkaardid on, mis asi on protsesside statistiline juhtimine, ja oli ainult kõrva äärest kuulnud Demingi tsüklist kvaliteedihalduses. No ja…

Ta läks teise asedirektori juurde ja pakkus välja kontrollerimise rakendamise. Aga ka seal ei leidnud ta toetust. Veel natuke hiljem kuulis ta piirihalduse (boundary management) kohta ja pakkus kõigile asedirektoritele süsteemse osa rakendamist, et protsesse parandada. Aga kui palju noormees ei rääkinud, keegi ei soovinud eriti süveneda, milles asi. Võib-olla polnud see neile huvitav või liiga keeruline. Aga tõeliselt ei saanud keegi aru.

Ühesõnaga, ta rääkis kõikidest asjadest, mida ta firmas teadis ja rakendas. Aga keegi ei saanud aru. Neile ei ole siiani selge, miks näiteks õnnestus laohaldust täielikult parandada, ja mis seondub sellega kontrollerimise ja piirihaldusega.

Lõpuks jõudis ta oma programmeerijateni – firmasse kuulus 3 inimest. Rääkis piirihalduse, kontrollerimise, kvaliteedihalduse, agiilse ja scrum’i kohta… Ja üllatuseks said nad kõik aru, ja isegi said temaga mingil moel arutada, sealhulgas ka – tehnilisi ja metoodilisi nüansse. Nad mõistsid, miks lao- ja varustuse projektid õnnestusid. Ja siis taipas noormees: tegelikult päästavad maailma programmeerijad.

Programmeeriad, mõistis ta – on ainsad, kes saavad korralikult, vajaliku detailitasemega aru ettevõtte protsessidest.

Miks just nemad? Tegelikult ei leidnud ta sellele kindlat vastust. Ta vormistas vaid teesisarnaseid vihjeid.

Esiteks, programmeerijad tunnevad ärivaldkondi, ning nad tunnevad neid paremini kui kõik teised inimesed ettevõttes.

Lisaks mõistavad programmeerijad tõeliselt, mis on protsessi algoritm. See on oluline, sest äriprotsessid on algoritmid ja nende elemendid võivad olla lihtsalt omavahel koordineerimata. Näiteks tema töötatud hankimisprotsessis on esimene samm aastase ostuplaani koostamine ja teine - igapäevane ost. Need sammud on omavahel otseselt seotud, st eeldatakse, et selle algoritmi järgi peaksid inimesed töötama - koostama aastase ostuplaani ja kohe sellele vastama. Aastase ostuplaani koostatakse kord aastas, samas kui taotlusi saadakse 50 korda päevas. Selle algoritmiga peabki töötama. Ta arvas, et programmeerijate jaoks on algoritmide tundmine konkurentsieelis, kuna ükski teine inimene, kes neist ei tea, ei saa aru, kuidas äriprotsess peaks toimima ja kuidas seda kujutada.

Veel üks pluss programmeerijate juures, nagu noormees ütles - neil on piisavalt vaba aega. Me kõik mõistame, kuidas programmeerija võib kulutada ülesandele kolm korda rohkem aega, kui tegelikult on vajalik, ja vähesed seda märkavad. See on jälle konkurentsieelis, kuna mingi äriprotsessi korrastamiseks on vaja palju vaba aega – mõelda, jälgida, uurida ja katsetada.

Suurem osa juhte, noormehe sõnul, ei oma seda vaba aega ja on sellest uhked. Kuigi tegelikult tähendab see, et inimene ei saa olla tõhus, kuna tal pole aega tõhususe tõstmiseks – suletud ring. Meie kultuuris on moes olla hõivatud, seetõttu jääb kõik paigale. Meie, programmeerijad, saame aga leida vaba aega ja mõelda kõigest.

Programmeerijad, rääkis ta, saavad kiiresti vahetada infosüsteemi. See ei kehti kõikidele ettevõtetele, kuid igal pool, kus ta töötas, oli võimalik teha igasuguseid täiustusi, mis tahes viisil. Eriti kui need ei puuduta kellegi teise tööd. Näiteks võis ta käivitada süsteemi, mis salaja mõõdab kasutajate tegevust, ja kasutada seejärel neid andmeid — näiteks raamatupidamise töö tõhususe analüüsimiseks ja arvestuse pidamise kulude jälgimiseks.

Ja viimane, mis ma tema sõnade juures meelde jätsin – programmeerijatel on ligipääs suurele hulgale teabele, kuna neid on volitatud administreerima süsteemi. Seega saavad nad seda teavet oma analüüsides kasutada. Keegi teine tavalisel tehases sellist ressurssi ei oma.

Ja siis ta läks ära. Kaks nädalat, mis tal olid ettenähtud, sundisime teda oma kogemusi jagama, kuna soovisime jätkata seda, mida ta tegi. Ehkki tema ametikoht pidi vabanema.

Mõne päeva jooksul panime ta toolile istuma, lülitasime kaamera sisse ja salvestasime tema monoloogid. Palusime rääkida kõigist lõppenud projektidest, meetoditest, lähenemistest, edusammudest ja ebaõnnestumistest, põhjustest ja tagajärgedest, juhtide portreedest jne. Ei olnud mingeid piiranguid, kuna ei teadnud, mis tal peas toimub.

Monoloogides, muidugi, oli peamiselt igasugu loba ja nalju — ta oli suurepärases meeleolus, kuna lahkus maapiirkonnast Peterburgi. Ja kuhu Peterburgis tööle minna? Gazpromi, muidugi.

Aga mõningaid kasulikke asju suudsime tema monoloogidest välja tuua. Räägin, mida mäletan.

Nii et selle noormehe soovitused. Neile, kes soovivad proovida korda majja saada äriprotsessides.

Et sellise tööga tegeleda, peab kõigepealt olema teatud tase „külmaverelisusest”. Ei tohi karta töö kaotamist, ei tohi kartma jääda, ei tohi karta konflikte kolleegidega. Tal õnnestus see kergesti, kuna ta alustas oma teed, kui oli ettevõttes töötanud vaid kuus kuud, ja ei olnud veel kellegagi kontaktidele asunud ning ei plaaninud seda teha. Ta mõistis, et inimesed tulevad ja lähevad, ja tema jaoks on olulised tema enda tulemused ja nende hindamine ettevõtte omaniku poolt. Kolleegide suhtumine temasse — hea või halb — ei muretsenud teda siis eriti.

Teine asi on see, et selle töö tõhusaks tegemiseks tuleb kahjuks õppida. Aga õppida ei MBA-lt, mitte kursustelt, mitte institutsioonides, vaid iseseisvalt. Näiteks oma esimeses projektis, mis puudutas ladu, tegutses ta intuitiivselt, ei teadnud midagi, ainult seda, mis on "kvaliteedijuhtimine".

Kui ta hakkas lugema kirjandust efektiivsuse tõstmise meetoditest, sai ta teada tehnoloogiatest, mida ta oli juba rakendanud. Noormees rakendas neid intuitiivselt, kuid selgus, et see polnud tema väljamõeldis, kõik oli ammu kirja pandud. Kuid ta kulutas aega ning palju rohkem, kui kui oleks kohe õige raamatu lugenud. Siin on oluline mõista, et kui õpid mingit konkreetset meetodit, ei lahenda ükski neist, isegi kõige arenenum, täielikult kõiki äriprotsessi probleeme.

Teine nipp on see, et mida rohkem meetodeid sa tead, seda parem. Näiteks elas muistses Jaapanis Miyamoto Musashi – üks tuntumaid mõõgameistreid, kahe mõõga stiili looja. Ta õppis mingis koolis mingi meistri juures, siis rändas Jaapanis, võitles erinevate vendadega. Kui keegi oli tugevam, siis peatati teekond mõneks ajaks ning Musashi läks õpilaseks. Tulemusena omandas ta paari aasta jooksul erinevate õpetajate erinevate praktikate oskused ja lõi oma kooli, lisades midagi enda oma. Tulemuseks oli tal ainulaadne meisterlikkus. Siin on sama lugu.

Muidugi, võib tegutseda nagu ärinõustajad. Nad on üldiselt toredad inimesed. Kuid tavaliselt tulevad nad, et rakendada mingit meetodit, ja rakendavad mitte seda meetodit, mis on äri jaoks vajalik. Meil on ka olnud selliseid kurbade olukordade: keegi ei tea, kuidas probleemi lahendada ja keegi ei taha mõelda, kuidas seda lahendada. Alustame otsingut kas internetist või kutsume nõustajat ning küsimme temalt, mis võiks aidata. Nõustaja mõtleb ja ütleb, et tuleb rakendada piirangute teooriat. Maksame talle soovituse eest, ei säästa rakendamise pealt, aga tulemus on null.

Miks see nii on? Sest nõustaja ütles, et rakendame seda süsteemi, ja kõik nõustusid temaga. Hästi, aga ükski meetod ei lahenda kõiki probleeme isegi ühe äriprotsessi osas, eriti kui lähtealused ei ühti – meie omad ja need, mis on vajalikud meetodi rakendamiseks.

Praktikas, mida noormees soovitab, tuleb võtta parim ja rakendada parimat. Ei tohi võtta meetodeid täielikult, vaid võtta nende võtmeomadused, nipid, tavad. Ja kõige olulisem on aru saada olemusest.

Võtame, ütles ta, näiteks scrum või agile. Oma monoloogides kordas noormees korduvalt, et mitte kõik ei mõista lõpuni scrumi olemust. Ta oli ka lugenud Jeff Sutherlandi raamatut, mis mõnele tundub "kerge lugemine". Temale tundus see sügava sisuga, kuna üks scrumi aluseid on kvaliteedi juhtimine, millest raamatus on otse juttu.

Seal on juttu Toyota tootmisest, sellest, kuidas Jeff Sutherland tutvustas scrum'i Jaapanis, kui hästi see seal juurtus ja kui lähedane see nende filosoofiale oli. Ja Sutherland rääkis scrum-meisteri rolli tähtsusest, Demingi tsüklist. Scrum-meisteri roll on pidev protsessi kiirendamine. Kõik muu, mis scrum'is olemas on, – etappide kaupa täitmine, kliendi rahulolu, selge tööde loetelu sprinti perioodil – on samuti oluline, kuid kõik see peaks liikuma järjest kiiremini. Töö kiirus peaks pidevalt suurenema nendes ühikutes, milles seda mõõdetakse.

Võib-olla on siin asi tõlkes, kuna meil tõlgiti raamat kui "Scrum – revolutsiooniline projektijuhtimise meetod", kuid kui ingliskeelset pealkirja sõna-sõnalt tõlkida, siis tuleks: "Scrum – kaks korda rohkem poole vähem ajaga", ehkki isegi pealkirjas viidatakse kiiruselle, kui scrumi võtmefunktsioonile.

Kui see noormees scrum'i rakendas, siis esimese kuu jooksul kasvas kiirus kaks korda ilma eriliste muudatusteta. Ta leidis muudatuste punktid, kohandas scrumi enda jaoks, et see töö sõltumatult kiiremini. Ainuke, nagu internetis kirjutatakse, oli see, et nende ette kerkis küsimus: "Me oleme kiirus kaks korda suurendanud, nüüd tuleb mõista, mida me sellise kiirusuga ette võtame?" Kuid see on juba täiesti teine valdkond...

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

Esimene on boundary management (piirihalduse juhtimine).

Seda õpetatakse «Skolkovo» instituudis, teisi raamatuid ja materjale, väidab noormees, pole. Tal oli õnn osaleda Harvardist pärit professori loengul, kes räägib piiride juhtimisest, samuti lugeda mitmeid artikleid Harvard Business Review's Eric Trista töödest.

Piiride juhtimine räägib sellest, et tuleb osata näha piire ja nendega töötada. Piire on palju, need on igal pool – osakondade vahel, erinevate tööde vahel, funktsioonide vahel, operatiivse ja analüütilise töö vahel. Piiride juhtimise teadmised ei ava mingeid kõrgemaid tõdesid, kuid võimaldavad näha reaalsust veidi teises valguses – läbi piiride prisma. Ja seega, neid juhtida – ehitada üles seal, kus see on vajalik, ja eemaldada seal, kus nad segavad.

Kuid enamasti rääkis noormees kontrollimisest. Tal oli selle teema suhtes tõeline kinnisidee.

Kontrollimine, kui lühidalt kokku võtta – see on juhtimine numbrite alusel. Siin, rääkis ta, on oluline iga osa määratlusest – nii «juhtimine», «alusel» kui ka «numbrid».

Meil, rääkis ta, on kõik kolm kontrollimise komponente halvasti. Olles arvesse võtnud, et need on tihedalt seotud nii üksteise kui ka teiste ärisüsteemi osadega.

Esiteks, numbrid on kehvad. Neid on vähe ja need on madala kvaliteediga.

Oluliselt osa numbritest võtsime siis me infovaramust 1C. Noh, kvaliteet numbrites 1C, nagu ta väitis, ei ole sugugi sobiv. Vähemalt seetõttu, et andmeid võib tagantjärele muuta.

On selge, et 1C arendajate süü selles ei ole – nad arvestavad vaid turu nõudmisi ja kodumaise raamatupidamise mentaliteeti. Kuid kontrollimise eesmärkidel oleks 1C töö põhimõtteid andmetega paremini muuta konkreetses ettevõttes.

Edasi, rääkis ta, 1C andmed läbivad poolautomaatselt töötlemise, näiteks Exceli abil. Selline töötlemine ei lisa andmete kvaliteeti ega operatiivsust.

Lõpuks, lõplikku aruannet kontrollib veel keegi, et juhile ei saaks kogemata esitada vale andmeid. Lõpuks jõuavad numbrid adressaadini ilusate, kontrollitud, kuid väga hilja. Tavaliselt – pärast perioodi lõppu (kuu, nädala jne).

Ja siin, rääkis ta, on kõik väga lihtne. Kui jaanuari numbrid jõuavad teie kätte veebruaris, ei saa te jaanuari tegevuse üle enam juhtida. Sest jaanuar on juba läbi.

Ja kui numbrid põhinevad raamatupidamisel ning ettevõte on täiesti tavaline, esitab käibemaksu kvartaliaruande, siis saab juht suhteliselt mõistlikud numbrid kord kvartalis.

Edasi on selge. Saate numbreid kord kuus — teil on võimalus numbrite alusel juhtida (st teha kontrolli) 12 korda aastas. Kui harjutate kvartaliaruandlust — juhtite 4 korda aastas. Pluss boonuseks — aastaaruandumine. Veel kord roolida.

Ülejäänud aja juhtimine toimub enamasti pimeda peale.

Kui (ja kui) numbrid lõpuks ilmuvad, siis astub teise probleemi — kuidas juhtida numbrite alusel? Selle punkti osas ma tema arutlusega nõustuda ei suutnud.

Poiss väitis, et kui juhil pole varem numbreid olnud, siis nende ilmumine tekitab wow-efekti. Ta vaatab ja keerab numbreid igas suunas, kutsub inimesi “vaibale”, nõuab selgitusi ja uurimisi. Numbritega mängides, tehes analüüse ja hirmuäratavalt lubades kõigile töötajatele, et “nüüd ma teid enam ei lase”, rahuneb juht väga kiiresti ja loobub sellest. Ta ei kasuta enam tööriista. Probleemid jäävad paika.

Nii juhtub, ütles ta, juhil ebapiisava kompetentsuse tõttu. Eeskätt kontrollimises. Juht ei tea lihtsalt, mida nende numbritega ette võtta. Mis jotteha — teab, mida teha — ei tea. Teha — see on see, millest eelnevalt räägiti (kitsutamine, mängimine). Tegema — see on igapäevane äriprotsess.

Ta väitis, et kõik on väga lihtne: number peab muutuma äriprotsessi osaks. Äriprotsessis peab olema selgelt arusaadav, kes, mida ja millal peab tegema, kui number normist kõrvale kaldub (iga variandi puhul — üle piiri, alla piiri, koridori ületamine, suundumuse olemasolu, kvanti täitmata jäämine jne.)

Ja siin ta tõi välja võtmedilemma: number on olemas, see peab olema osa ärisüsteemist, et suurendada juhtimise efektiivsust, kuid… seda ei toimu. Miks?

Kuna Venemaa juht ei anna konkurendile tükki oma võimust.

Venemaa juhi konkurendid — kvaliteetne ja toimiv äriprotsess, läbimõeldud vastastikku kasulik motiveerimine ja õige automatiseerimine — kahjuks jätavad juhi tööta.

Mispe, kas pole? Eriti juhtide kohta. Olgu, ma rääkisin, nüüd otsustage ise.

Veidi vähem, aga ikkagi liiga palju, minu arvates, rääkis ta scrum'ist.

Ta ütles kindlasti, et lugege ja proovige scrum'it praktikas. Kui olete lugenud, kuid ei ole proovinud — kaaluge, et te ei tea. Paremini lugeda raamatut, näiteks Sutherlandilt, mitte artikleid ja igasuguseid liideseid (mis tähendab?) internetis.

Scrum'i, ütles ta, tuntakse ainult praktika kaudu, ja see vajab kohustuslikke mõõtmisi tehtud töö mahust. Proovige isiklikult kahte kõige olulisemat rolli — toote omaniku ja scrum'i meistri rolli.

Eriti oluline, ütles noormees, on praktikas tunda scrum'i meistri rolli, kui suudate suurendada spurtide jooksul lahendatud ülesannete hulka, suurendamata ressursse ja spurtide maksumust.

Ja veel tema tipus oli TOC (süsteemide piirangute teooria).

See, ütles noormees, on põhilised, fundamentaalsed efektiivsuse tõstmise põhimõtted, mida saab kohandada praktiliselt igas valdkonnas, igas äri protsessis ja ärisüsteemis kokkuvõttes.

Kui ta sai teada, et me ei ole TOC'ga tuttavad, lõpetas ta rääkimise. Ta lisas vaid, et ei taha meid ilma jätta Eliyahu Goldratti raamatute lugemise naudingust. Soovitus oli sarnane scrum'ile — lugege ja proovige. Tüüpi, olenemata positsioonist, mida te ei täida, leiab seal koha efektiivsuse tõstmiseks TOC meetodite kaudu.

Siis näib, et tema meetodite pagas oli ammendunud ja ta ütles: segage põhimõtteid, et luua praktilisi lahendusi konkreetsetes olukordades.

See, ütles ta, on peamine soovitus, edu võti. Mõistke põhimõtteid, olemust ja looge ainulaadsed praktilised lahendused — äri protsessid ja äri süsteemid.

Siis ta püüdis meenutada mingit tsitaati, lõpuks tuli tal interneti poole pöörduda. Selgus, et tsitaat oli artiklist "Seistes hiidude õlgadel" Eliyahu Goldrattist:

«On olemas vahe rakenduslahenduste (rakenduste) ja fundamentaalsete kontseptsioonide vahel, millel need lahendused põhinevad. Kontseptsioonid on üldised, rakenduslahendused on need kontseptsioonid, mis on kohandatud konkreetse keskkonna jaoks. Nagu oleme näinud, ei ole selline kohandamine lihtne ja vajab teatud lahenduse elementide väljatöötamist. Peame meeles pidama, et rakenduslahendus põhineb algseisukohtadel (mõnikord - varjatud) konkreetse keskkonna kohta. Ärge oodake, et seda rakenduslahendust saab rakendada keskkonnas, kus algselt seatud eeldused ei kehti.»

Ta ütles, et programmeerija ja „äriprotsesside täiustaja“ töö on väga sarnane. Ja lahkus.

Allikas: habr.com