Ühe mehe kohta

Lugu on tõsi, nägin kõike oma silmaga.

Mitu aastat töötas üks mees, nagu paljud teist, programmeerijana. Igaks juhuks kirjutan selle nii: "programmeerija". Sest ta oli 1Snik, fix, tootmisettevõte.

Enne seda proovis ta erinevaid erialasid - 4 aastat Prantsusmaal programmeerijana, projektijuhina, suutis läbida 200 tundi, saades samal ajal protsentuaalset projekti, juhtimise eest ja veidi müüki tehes. Proovisin tooteid ise arendada, olin 6 tuhande inimesega suures ettevõttes IT-osakonna juhataja, proovisin erinevaid võimalusi oma tsiteeritava elukutse - 1C programmeerija - kasutamiseks.

Kuid kõik need positsioonid olid mõnevõrra ummikseisus, eelkõige sissetuleku osas. Sel ajal saime kõik ligikaudu sama raha ja töötasime samadel tingimustel.

See mees mõtles, kuidas ta saaks rohkem raha teenida ilma oma ettevõtet müümata või loomata.

Ta pidas end targaks meheks ja otsustas leida niši ettevõttes, kus ta töötas. See nišš pidi olema midagi erilist, mitte kellegi poolt hõivatud. Ja ma tahtsin, et ettevõte ise tahaks selles nišis olevale inimesele raha maksta, et poleks vaja kedagi petta ega midagi välja petta. Selle eesmärgi saavutamiseks: sellel ametikohal olevale inimesele tuleb maksta palju raha. Ekstsentrik, ühesõnaga.

Otsingud olid lühiajalised. Ettevõttes, kus see mees töötas, oli täiesti vaba nišš, mida võiks nimetada “äriprotsessides asjade korda seadmiseks”. Igal ettevõttel on palju probleeme. Midagi alati ei tööta ja pole inimest, kes tuleks ja äriprotsessi parandaks. Niisiis otsustas ta proovida end spetsialistina, kes aitab omanikul äriprotsessides probleeme lahendada.

Sel ajal oli ta ettevõttes töötanud kuus kuud ja saanud turu keskmist palka. Kaotada polnud midagi, seda enam, et ta leidis hõlpsasti sama töö ühe nädala jooksul. Üldiselt otsustas see tüüp, et midagi hullu ei juhtu, kui äkki midagi ei õnnestu ja ta vallandatakse.

Ta võttis julguse kokku ja tuli omaniku juurde. Soovitasin tal parandada ettevõtte kõige problemaatilisemat protsessi. Tol ajal oli selleks laoarvestus. Nüüd on kõigil selles ettevõttes töötavatel isegi häbi neid probleeme meenutada, kuid inventuurid, mida tehti kord kvartalis, näitasid raamatupidamissüsteemi ja tegelike saldode vahel kümneid protsente. Ja maksumuse, koguse ja positsioonide arvu poolest. See oli katastroof. Ettevõttel olid raamatupidamissüsteemis õiged saldod tegelikult vaid neli korda aastas – päev pärast laoarvestust. Meie mees hakkas seda protsessi korda seadma.

Tüüp leppis omanikuga kokku, et peaks inventuuritulemustest kõrvalekaldeid poole võrra vähendama. Pealegi polnud omanikul midagi erilist kaotada, sest enne meie kangelast olid erinevad töötajad juba teinud katseid kõike parandada ja üldiselt peeti ülesannet praktiliselt lahendamatuks. Kõik see tekitas tohutult huvi, sest kui kõik õnnestuks, muutuks kutist automaatselt inimene, kes teab, kuidas asju korda seada ja lahendamatuid probleeme lahendada.

Niisiis seisis ta silmitsi ülesandega: vähendada aasta jooksul inventuuritulemuste põhjal hälbeid 2 korda. Projekti alguses polnud tal õrna aimugi, kuidas seda saavutada, kuid ta mõistis, et laoarvestus on lihtne asi, nii et midagi kasulikku saab ta siiski teha. Pealegi ei tundu kõrvalekallete vähendamine kümnetelt protsentidelt ühele kümnele protsendile nii keeruline. Igaüks, kes on töötanud nõustamise või muu sarnase tegevusega, mõistab, et enamik protsessiprobleeme on lahendatavad üsna lihtsate sammudega.

Jaanuarist maini valmistas ette, automatiseeris veidi midagi, kirjutas ümber laoarvestuse äriprotsessi, muutis laopidajate, raamatupidajate töövooge ja tegi üldiselt kogu süsteemi ümber, ilma kellelegi midagi ette näitamata ja ütlemata. Mais jagas ta kõigile uued juhised ja pärast aasta esimest inventuuri algas uus elu - töötamine oma reeglite järgi. Tulemuste jälgimiseks hakkas ettevõte edaspidi inventuuri tegema sagedamini – kord kahe kuu tagant. Juba esimesed tulemused olid positiivsed ning aasta lõpuks olid kõrvalekalded audititulemustest langenud ühe protsendini.

Edu oli kolossaalne, kuid selle jätkusuutlikkusesse ei osanud uskuda. Kutt ise kahtles, kas tulemus säilib, kui ta kõrvale astub ja protsessi jälgimise lõpetab. Sellegipoolest oli tulemus ja tüüp sai kõik, milles ta omanikuga kokku leppis. Seejärel kinnitati mitme aasta pärast tulemuse stabiilsus - mitu aastat jäid kõrvalekalded 1% piiresse.

Seejärel otsustas ta katset korrata ja soovitas omanikul parandada veel üht probleemset protsessi – tarnimist. Tekkis defitsiit, mis ei võimaldanud tarnida selliseid koguseid, mida meie kliendid soovisid. Leppisime kokku, et aastaga vähendatakse puudujääke poole võrra ning tüüp teeb ka 10-15 1C-ga seotud projekti - automatiseerida erinevaid äriprotsesse ja muid ketserlusi.

Teisel aastal sai kõik taas edukalt lõpule viidud, puudujäägid vähenesid üle 2 korra, kõik IT projektid said edukalt lõpule viidud.

Kuna palk rahuldas juba kaks aastat ette tolle tüübi kõik vajadused, otsustas ta end veidi maha rahustada, maha rahuneda ja istuda enda loodud hubasesse sooja kohta.

Milline see oli? Formaalselt oli ta IT-direktor. Aga kes ta tegelikult oli, on raske aru saada. Lõppude lõpuks, mida teeb IT-direktor? Üldjuhul haldab ta IT infrastruktuuri, haldab süsteemiadministraatoreid, juurutab ERP-süsteemi ning osaleb juhatuse koosolekutel.

Ja sellel mehel oli üks peamisi kohustusi osaleda muutuste protsessides ja peamiselt - genereerimine, nende protsesside algatamine, lahenduste otsimine ja pakkumine, uute juhtimisvõtete rakendamine, kavandatud muudatuste uurimine, muude funktsioonide efektiivsuse analüüs ja divisjonid ja lõpuks otsene osalemine ettevõtte strateegilises arengus kuni kogu ettevõtte strateegilise plaani iseseisva väljatöötamiseni.

Talle anti carte blanche. Ta võis tulla igale koosolekule, kuhu tal varem juurdepääsu polnud. Istusin seal märkmikuga, kirjutasin midagi üles või lihtsalt kuulasin. Ta rääkis harva. Seejärel hakkas ta telefoniga mängima, väites, et assotsiatiivne mälu töötab niimoodi paremini.

Koosolekul andis ta harva midagi kasulikku. Ta lahkus, mõtles, siis saabus kiri - kas kriitikaga või arvamusega või ettepanekutega või juba rakendatud lahenduste kirjeldusega.

Kuid sagedamini kutsus ta ise koosolekuid kokku. Leidsin probleemi, leidsin lahendused, tuvastasin huvilised ja tõin kõik koosolekule. Ja siis – nii hästi kui oskas. Ta veenis, motiveeris, tõestas, vaidles vastu, saavutas.

Mitteametlikult peeti teda ettevõttes omaniku ja juhataja järel kolmandaks isikuks. Muidugi ajas ta kohutavalt vihale kõik “seltskonna isikud”, alustades numbrist 4. Eelkõige oma lõhkiste teksade ja heledate T-särkidega ning ka oma omaniku ajaga.

Omanik andis talle 1 tund päevas. Iga päev. Räägiti, arutati probleeme, lahendusi, uusi ärisid, arenguvaldkondi, näitajaid ja efektiivsust, isiklikku arengut, raamatuid ja lihtsalt elu.

Aga see mees oli imelik. See on nagu istuge ja olge õnnelik, elu on hea. Kuid mitte. Ta otsustas järele mõelda.

Ta mõtles: miks see talle korda läks, aga teistel mitte? Omanik tõukas teda ka: ta ütles, et soovib, et ka teised saaksid korra taastada, sest juhte on palju, nemad reeglina tegelevad operatiivjuhtimise ja strateegilise planeerimisega, aga süsteemsete muutustega praktiliselt keegi ei tegele. nende protsessides. Nende ametijuhendis võib olla kirjas, et nad peaksid oma protsessi kiirendama ja tõhustama, aga tegelikult ei tee seda keegi. Miks nii? Tüübil tekkis ka huvi, miks ja ta läks kõigi nende juhtidega rääkima.

Ta tuli kvaliteedi pärast asedirektori juurde ja soovitas võtta kasutusele Shewharti kontrollkaardid, et tooted oleksid paremad kui Jaapani omad. Aga selgus, et kolleeg ei teadnud, mis on Shewharti kontrollkaardid, mis on statistiline protsessikontroll ja oli kuulnud vaid Demingi tsükli kasutamisest kvaliteedijuhtimises. OKEI…

Ta läks teise asedirektori juurde ja soovitas kontrollingut juurutada. Kuid ma ei leidnud ka siit tuge. Veidi hiljem sai ta teada piirihaldusest (piirihaldus) ja soovitas kõigil asedirektoritel protsesside täiustamiseks juurutada selle metoodika süsteemne osa. Kuid hoolimata sellest, kui palju meie tüüp rääkis, ei tahtnud keegi väga süveneda sellesse, millega tegu. Võib-olla nad ei olnud huvitatud või oli see liiga raske. Aga tegelikult ei saanud sellest keegi aru.

Üldiselt rääkis ta kõigest, mida teadis ja ettevõttes kasutas. Kuid keegi ei mõistnud teda. Siiani ei saa aru, miks näiteks laoarvestuses kõike parandati ning mis seos on sellega kontrollil ja piirihaldusel.

Viimasena jõudis ta oma programmeerijateni – personali kuulus 3 inimest. Ta rääkis piirihaldusest, kontrollimisest, kvaliteedijuhtimisest, agile’ist ja scrum’ist... Ja üllataval kombel said nad kõigest aru ja isegi suutis temaga kuidagi arutada, ka tehniliste ja metoodiliste peensusteni. Nad said aru, miks lao- ja tarneprojektid õnnestusid. Ja siis jõudis mehele kohale: tegelikult päästavad programmeerijad maailma.

Ta mõistis, et programmeerijad on ainsad, kes saavad äriprotsessidest normaalselt ja vajaliku detailiga aru.

Miks just nemad? Tegelikult ei leidnud ta kunagi selget vastust. Sõnastasin ainult lõputöö vihjeid.

Esiteks tunnevad programmeerijad ettevõtte teemavaldkondi ja tunnevad neid paremini kui kõik teised ettevõtte inimesed.

Lisaks saavad programmeerijad tõesti aru, mis on protsessialgoritm. See on oluline, kuna äriprotsessid on algoritmid ja nende elemendid ei pruugi lihtsalt olla järjepidevad. Näiteks hankeprotsessis töötas tüüp, esimene samm oli iga-aastase ostuplaani koostamine ja teiseks igapäevane ostmine. Neid etappe ühendab otseühendus, st eeldatakse, et inimesed peaksid selle algoritmi järgi töötama - koostama iga-aastase hankeplaani ja viivitamatult täitma päringu. Aastane hankeplaan koostatakse kord aastas, taotlusi võetakse vastu 50 korda päevas. See on koht, kus algoritm lõpeb ja peate selle kallal töötama. Tegelikult arutles ta, et programmeerijate jaoks on algoritmide tundmine konkurentsieelis, sest kõik teised, kes nendega kursis ei ole, lihtsalt ei saa aru, kuidas äriprotsess peaks toimima ja kuidas seda kujutada saab.

Programmeerijate eeliseks on mehe sõnul ka see, et neil on piisavalt vaba aega. Me kõik mõistame, kuidas programmeerija võib kulutada ülesande täitmisele kolm korda kauem, kui see tegelikult nõuab, ja vähesed panevad seda tähele. See on jällegi konkurentsieelis, sest mingi äriprotsessi kordategemiseks peab sul olema palju vaba aega – mõelda, jälgida, uurida ja proovida.

Enamikul juhtidest pole mehe sõnul seda vaba aega ja nad on selle üle uhked. Kuigi tegelikult tähendab see seda, et inimene ei saa muutuda efektiivseks, kuna tal pole aega tõhusust parandada – nõiaring. Meie kultuuris on moes olla hõivatud, nii et kõik jääb samaks. Ja meile, programmeerijatele, on see eelis. Leiame vaba aega ja mõtleme kõige üle.

Tema sõnul suudavad programmeerijad infosüsteemi kiiresti muuta. See ei kehti kõigis ettevõtetes, kuid kõikjal, kus ta töötas, võis ta teha soovitud muudatusi. Eriti kui need kellegi teise tööd ei puuduta. Näiteks võiks ta käivitada süsteemi, mis mõõdaks salaja kasutajate tegevusi ning seejärel analüüsiks seda infot sama raamatupidamisosakonna efektiivsust ja jälgiks raamatupidamise kulu.

Ja viimane asi, mida ma tema sõnadest mäletan, on see, et programmeerijatel on juurdepääs suurele hulgale teabele, sest... omada süsteemile administraatorijuurdepääsu. Seetõttu saavad nad seda teavet oma analüüsis kasutada. Kellelgi teisel tavalises tehases pole sellist ressurssi.

Ja siis ta lahkus. Nõutud kahenädalase kinnipidamise ajal sundisime teda oma kogemusi jagama, sest tahtsime tema tehtud tööd jätkata. Noh, tema koht jäi vabaks.

Mitme päeva jooksul istutasid nad ta toolile, lülitasid kaamera sisse ja salvestasid tema monolooge. Nad palusid meile rääkida kõigist lõpetatud projektidest, meetoditest, lähenemisviisidest, õnnestumistest ja ebaõnnestumistest, põhjustest ja tagajärgedest, juhtide portreedest jne. Erilisi piiranguid polnud, sest Nad ei teadnud, mis tema peas toimus.

Monoloogid olid muidugi enamjaolt jaburad ja naersid – tal oli tuju suurepärane, sest oli lahkumas ääremaalt Peterburi. Kuhu peaksite Peterburis tööle minema? Muidugi Gazpromile.

Aga meil õnnestus tema monoloogidest midagi kasulikku välja tõmmata. Ma räägin teile, mida ma mäletan.

Niisiis, selle mehe soovitused. Neile, kes soovivad äriprotsessides asju korda ajada.

Sellise töö tegemiseks peab esiteks olema teatud “külmakahjustuse” tase. Ei tasu karta töö kaotamist, mitte karta riskida, mitte karta konflikte kolleegidega. Tal oli lihtne, sest ta alustas oma teekonda siis, kui oli ettevõttes töötanud vaid kuus kuud, kellel polnud aega kellegagi kokku puutuda ega kavatsenud seda teha. Ta mõistis, et inimesed tulevad ja lähevad, kuid tema enda tulemused ja nende hinnang ettevõtte omaniku poolt on talle olulised. See, kas kolleegid kohtlesid teda hästi või halvasti, ei teinud talle siis suurt muret.

Teine punkt on see, et selle töö tõhusaks tegemiseks peate kahjuks õppima. Kuid õppige mitte MBA-ks, mitte kursustel, mitte instituutides, vaid iseseisvalt. Näiteks oma esimeses projektis, laoprojektis, tegutses ta intuitiivselt, ta ei teadnud midagi, lihtsalt seda, mis on "kvaliteedijuhtimine".

Kui ta hakkas lugema kirjandust selle kohta, millised tõhususe suurendamise meetodid on olemas, avastas ta tehnoloogiad, mida ta kasutas. Kutt rakendas neid intuitiivselt, kuid selgub, et see polnud tema leiutis, kõik oli juba ammu kirjutatud. Aga ta kulutas aega ja palju rohkemgi, kui oleks kohe õige raamatu läbi lugenud. Siin on ainult oluline mõista, et konkreetse tehnika uurimisel ei lahenda ükski neist, isegi kõige arenenum, täielikult kõiki äriprotsessi probleeme.

Teine nipp on see, et mida rohkem tehnikaid teate, seda parem. Näiteks elas muistses Jaapanis Miyamoto Musashi, üks kuulsamaid mõõgamehi, kahe mõõga stiili autor. Ta õppis mõnes koolis mõne meistri juures, seejärel reisis mööda Jaapanit, võitles erinevate kuttidega. Kui tüüp oli tugevam, peatus teekond mõneks ajaks ja Musashist sai õpilane. Selle tulemusena omandas ta mitme aasta jooksul erinevate meistrite erinevate praktikate oskused ja moodustas oma kooli, lisades sinna midagi oma. Selle tulemusena saavutas ta ainulaadse oskuse. Siin on sama.

Loomulikult võite tegutseda ärikonsultantidena. Üldiselt on nad suurepärased poisid. Aga reeglina tullakse mingit metoodikat juurutama ja rakendatakse vale metoodikat, mida äri vajab. Meil oli ka selliseid kurbi olukordi: keegi ei tea, kuidas probleemi lahendada ja keegi ei taha mõelda, kuidas seda lahendada. Hakkame otsima kas internetist või helistame konsultandile ja küsime, mis meid aidata saab. Konsultant mõtleb ja ütleb, et peame piirangute teooriat tutvustama. Maksame talle tema soovituse eest, kulutame raha rakendamisele, kuid tulemus on null.

Miks see juhtub? Sest konsultant ütles, et me juurutame sellist ja sellist süsteemi ja kõik olid temaga nõus. Tore, aga üks metoodika ei kata kõiki isegi ühe äriprotsessi probleeme, eriti kui esialgsed eeldused - meie ja metoodika rakendamiseks vajalikud - ei lange kokku.

Praktikas, mida mees soovitab, peate võtma parima ja rakendama parimat. Ärge võtke meetodeid täielikult, vaid võtke arvesse nende põhifunktsioone, funktsioone ja tavasid. Ja kõige tähtsam on mõista olemust.

Võtke tema sõnul näiteks Scrum või Agile. Oma monoloogides kordas kutt mitu korda, et mitte kõik ei mõista Scrumi olemust täielikult. Ta luges ka Jeff Sutherlandi raamatut, mida mõned inimesed peavad "kergeks lugemiseks". See tundus talle sügava lugemisena, sest Scrumi üks aluspõhimõtteid on kvaliteedijuhtimine, see on otse raamatus kirjas.

See räägib Toyota Productionist, sellest, kuidas Jeff Sutherland Scrumi Jaapanis näitas, kuidas see seal juurdus ja kui lähedal oli see nende filosoofiale. Ja Sutherland rääkis Scrum Masteri rolli tähtsusest, Demingi tsüklist. Scrum Masteri roll on protsessi pidevalt kiirendada. Kõik muu, mis Scrumis on - etapiviisiline tarne, klientide rahulolu, selge sprindiperioodi tööde nimekiri - on samuti oluline, kuid see kõik peab liikuma üha kiiremini. Töö kiirus peab pidevalt suurenema ühikutes, milles seda mõõdetakse.

Võib-olla on see tõlkimise küsimus, sest meie raamat tõlgiti kui "Scrum - revolutsiooniline projektijuhtimise meetod" ja kui ingliskeelset pealkirja tõlgitakse sõna-sõnalt, selgub: "Scrum - poole ajaga kaks korda rohkem" , ehk isegi aastal Nimetus viitab kiirusele kui Scrumi võtmefunktsioonile.

Kui see mees Scrumi kasutusele võttis, kahekordistus kiirus esimese kuuga ilma oluliste muudatusteta. Ta leidis muudatusteks punkte ja muutis Scrumi ennast, et see palju kiiremini töötaks. Ainus, mida nad Internetis kirjutavad, on see, et nad seisid silmitsi küsimusega: "Oleme kiiruse kahekordistanud, jääb vaid aru saada, mida me sellise kiirusega teeme?" See on aga hoopis teine ​​ala...

Ta soovitas ka isiklikult mitmeid tehnikaid. Ta nimetas neid fundamentaalseteks ja fundamentaalseteks.

Esimene on piiride haldamine.

Nad õpetavad seda Skolkovos, tüübi sõnul muid raamatuid ja materjale pole. Tal oli millegipärast õnn osaleda piirihaldust jutlustava Harvardi professori loengus ja lugeda ka mitmeid artikleid ajakirjas Harvard Business Review Eric Tristi töö kohta.

Piiride haldamine ütleb, et tuleb osata näha piire ja piiridega töötada. Piire on küllaga, need on igal pool – osakondade vahel, eri tüüpi tööde vahel, funktsioonide vahel, operatiiv- ja analüütilise töö vahel. Teadmised piiride haldamisest ei paljasta mingeid kõrgemaid tõdesid, kuid võimaldavad näha tegelikkust veidi teises valguses – läbi piiride prisma. Ja vastavalt hallake neid - püstitage need vajadusel ja eemaldage need, kus need on teel.

Kuid enamasti rääkis tüüp kontrollimisest. Tal oli sellel teemal lihtsalt mingi veidrus.

Kontroll on lühidalt öeldes numbritel põhinev juhtimine. Siin on tema sõnul oluline definitsiooni iga osa - nii "juhtimine" kui ka "põhine" ja "arvud".

Ta ütles, et meil on kõik kolm kontrollimise komponenti halvasti. Eriti kui arvestada, et need on omavahel tihedalt seotud nii omavahel kui ka ärisüsteemi muude osadega.

Esimene asi, mis on halb, on numbrid. Neid on vähe ja need on madala kvaliteediga.

Võtsime siis olulise osa numbritest 1C infosüsteemist. Niisiis, nagu ta väitis, pole 1C numbrite kvaliteet hea. Vähemalt tänu võimalusele andmeid tagasiulatuvalt muuta.

On selge, et see pole 1C arendajate süü - nad võtavad arvesse ainult turu nõudeid ja kodumaise raamatupidamise mentaliteeti. Kuid kontrolli eesmärgil on parem muuta 1C andmetega töötamise põhimõtteid konkreetses ettevõttes.

Lisaks töödeldakse 1C-st pärit numbreid tema sõnul poolkäsitsi, kasutades näiteks Excelit. Selline töötlemine ei lisa ka andmetele kvaliteeti, samuti efektiivsust.

Lõpuks kontrollib keegi teine ​​lõpparuannet üle, et mitte kogemata juhile vigadega arve esitada. Selle tulemusena jõuavad numbrid adressaadini ilusana, kontrollituna, kuid väga hilja. Tavaliselt - pärast perioodi lõppu (kuu, nädal jne).

Ja siin on tema sõnul kõik väga lihtne. Kui jaanuarikuu numbrid tulid sulle veebruaris, siis jaanuari tegevustega enam hakkama ei saa. Sest jaanuar on juba läbi.

Ja kui arvud on raamatupidamispõhised ja ettevõte on kõige tavalisem, käibemaksu kvartaalne esitamisega, siis selle juht saab kord kvartalis suhteliselt adekvaatsed arvud.

Ülejäänu on selge. Saate numbreid kord kuus – teil on võimalus numbrite järgi hallata (s.t. kontrollida) 12 korda aastas. Kui harjutate kvartaliaruandlust, juhite seda 4 korda aastas. Pluss boonus – iga-aastane aruandlus. Juhtige veel üks kord.

Ülejäänud ajal toimub kontroll tavaliselt pimesi.

Kui (ja kui) numbrid ilmuvad, siis tuleb mängu teine ​​probleem – kuidas numbrite põhjal hakkama saada? Ma ei saanud tema mõttekäigu selle punktiga nõustuda.

Kutt väitis, et kui juhil varem numbreid poleks, siis nende välimus tekitab vau-efekti. Ta vaatab ja väänab numbreid nii ja naa, kutsub inimesi vaibale, nõuab selgitusi ja uurimisi. Pärast numbritega mängimist, analüüsi läbiviimist ja kõigile töötajatele ähvardavalt lubamist, et "nüüd ma teist ei saa", rahuneb juht väga kiiresti ja loobub selles asjas. Lõpetage tööriista kasutamine. Aga probleemid jäävad paika.

See juhtub tema sõnul ebapiisava juhtimispädevuse tõttu. Kontrollimises ennekõike. Juht lihtsalt ei tea, mida nende numbritega peale hakata. Mida сteha - teab mida teha - ei. Teha on see, millest ülalpool kirjutatud (tüli, mängima). Tegemine on igapäevane äriprotsess.

Ta väitis, et kõik on väga lihtne: digi peab saama äriprotsessi osaks. Äriprotsessis peaks olema selgelt arusaadav: kes mida ja millal peaks tegema, kui numbrid normist kõrvale kalduvad (mis tahes võimalused - üle piiri, piirist allapoole, koridorist kaugemale minemine, trendi esinemine, mittevastavus kvantiil jne)

Ja nii tõi ta välja võtmedilemma: number on olemas, see peaks saama osaks ärisüsteemist, et tõsta juhtimise efektiivsust, aga... seda ei juhtu. Miks?

Sest Venemaa juht ei loovuta killukestki oma võimust konkurendile.

Vene juhi konkurendid - kvaliteetne ja toimiv äriprotsess, läbimõeldud vastastikku kasulik motivatsioon ja korralik automatiseerimine - jätavad paraku juhi ilma tööta.

Mingi jama, kas sa ei nõustu? Eriti juhtide kohta. Olgu, ma ütlesin, et sa otsustad ise.

Natuke vähem, aga siiski liiga palju, minu meelest rääkis ta Scrumist.

Ma ütlesin, et lugege kindlasti ja proovige Scrumit praktikas. Kui olete tema sõnul seda lugenud, kuid pole proovinud, pidage end võhiklikuks. Parem on lugeda raamatut, näiteks Sutherlandilt, mitte artikleid ja igasuguseid juhendeid (mida kuradit?) Internetis.

Scrumit saab tema sõnul õppida ainult harjutades ja tehtud töö mahu kohustuslike mõõtmiste abil. Proovige isiklikult kahte kõige olulisemat rolli – tooteomanik ja Scrum Master.

Eriti oluline on kuti sõnul praktikas kogeda Scrum Masteri rolli, mil saab sprindi kohta sooritatavate ülesannete mahtu suurendada ilma sprindi ressursse ja maksumust suurendamata.

Noh, tema topis oli TOS (süsteemipiirangute teooria).

Need on tüübi sõnul efektiivsuse tõstmise põhilised, aluspõhimõtted, mida saab rakendada peaaegu igas valdkonnas, igas äriprotsessis ja ärisüsteemis tervikuna.

Kui ta sai teada, et me pole TOS-iga tuttavad, ei rääkinud ta meile. Ta lisas vaid, et ei võta meilt ära Eliyahu Goldratti raamatute lugemise naudingut. Ta andis Scrumile sarnase soovituse - lugege seda ja proovige seda. Nagu, olenemata sellest, mis ametikohal te olete, ükskõik mis tööd te ka ei teeks, on TOC meetodite abil tõhususe suurendamiseks koht.

Siis kuivas tema tehnikate kott ilmselt kokku ja ta ütles: segage põhimõtteid, et luua konkreetses olukorras rakenduslikke lahendusi.

See on tema sõnul peamine soovitus, edu võti. Mõista põhimõtteid, olemust ning luua ainulaadseid rakenduslahendusi – äriprotsesse ja ärisüsteeme.

Siis püüdis ta mõnda tsitaati meelde jätta ja lõpuks pidi ta netti minema. Selgus, et see oli tsitaat Eliyahu Goldratti artiklist “Standing on the Shoulders of Giants”:

„Rakenduslahenduste (rakenduste) ja nende lahenduste aluseks olevate põhikontseptsioonide vahel on erinevus. Mõisted on üldised, rakenduslahendused on mõistete kohandamine konkreetse keskkonnaga. Nagu juba nägime, ei ole selline kohandamine lihtne ja nõuab lahenduse teatud elementide väljatöötamist. Peame meeles pidama, et rakenduslahendus põhineb esialgsetel (mõnikord varjatud) eeldustel konkreetse keskkonna kohta. Seda rakenduslahendust ei tohiks eeldada, et see töötab keskkonnas, mille eeldused ei ole õiged.

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

Allikas: www.habr.com