Гісторыя рэальная, я ўсё бачыў на свае вочы.
Некалькі гадоў адзін хлопец, як і многія з вас, працаваў праграмістам. На ўсякі выпадак напішу так: "праграмістам". Таму што ён быў 1Сніком, на фіксе, вытворчай кампаніі.
Да гэтага ён спрабаваў розныя спецыяльнасці - 4 гады ў франчы праграмістам, кіраўніком праектаў, умеў зачыняць па 200 гадзін, адначасова атрымліваючы працэнт з праекта, за кіраўніцтва і крыху займаючыся продажамі. Спрабаваў самастойна распрацоўваць прадукты, быў начальнікам IT-аддзела ў вялікай кампаніі, колькасцю 6 тысяч чалавек, прымяраў розныя варыянты прымянення сваёй двукоссевай прафесіі – праграміста 1С.
Але ўсё гэта пазіцыі былі некалькі тупіковыя, у першую чаргу па даходзе. Усе мы тады атрымлівалі прыкладна адны і тыя ж грошы, працавалі ў адных і тых жа ўмовах.
Гэтаму хлопцу стала цікава, як можна зарабляць больш грошай, не займаючыся продажамі і не ствараючы свой уласны бізнэс.
Ён уявіў сябе разумнікам, і вырашыў знайсці нішу ў той кампаніі, дзе працаваў. Ніша гэта павінна была быць якой-небудзь асаблівай, нікім не занятай. І хацелася, каб кампанія сама захацела плаціць грошы чалавеку ў гэтай нішы, каб не трэба было нікога падманваць ці нешта накручваць. Каб гэта было аб'ектыўна: чалавеку на гэтай пазыцыі трэба плаціць шмат грошай. Дзівак, адным словам.
Пошукі былі нядоўгімі. У кампаніі, дзе гэты хлопец працаваў, была зусім вольная ніша, якую можна ўмоўна назваць "навядзенне парадку ў бізнес-працэсах". У кожнай кампаніі ёсць куча праблем. Заўсёды нешта не працуе, і няма чалавека, які прыйдзе і выправіць бізнэс-працэс. Дык вось, ён вырашыў паспрабаваць сябе ў ролі спецыяліста, які можа дапамагчы ўласніку вырашыць яго праблемы ў бізнес-працэсах.
На той момант ён працаваў у кампаніі паўгода, і атрымліваў сярэдні заробак па рынку. Страчваць не было чаго - тым больш, што такую ж працу ён мог знайсці на працягу аднаго тыдня. Увогуле, гэты хлопец вырашыў, што нічога страшнага не адбудзецца, калі раптам ні дуля не атрымаецца і яго звольняць.
Ён набраўся смеласці і прыйшоў да ўласніка. Прапанаваў яму палепшыць самы праблемны працэс, які быў у бізнэсе. На той момант гэта быў складскі ўлік. Цяпер усім, хто працуе ў гэтай кампаніі, нават сорамна ўспамінаць аб тых праблемах, але інвентарызацыі, якія праводзіліся штоквартальна, паказвалі разыходжанні паміж уліковай сістэмай і фактычнымі рэшткамі ў дзясяткі працэнтаў. І па кошце, і па колькасці, і па колькасці пазіцый. Гэта была бяда. Кампанія рэальна мела правільныя рэшткі ва ўліковай сістэме толькі чатыры разы на год - на наступны дзень пасля інвентарызацыі. Гэты працэс наш хлопец і стаў прыводзіць у парадак.
Хлопец дамовіўся з уласнікам, што мусіць знізіць адхіленні па выніках інвентарызацыі ўдвая. Прычым, уласніку губляць асабліва не было чаго, таму што да нашага героя спробы ўсё выправіць ужо рабілі розныя работнікі, і ў цэлым задача лічылася практычна невырашальнай. Усё гэта моцна падагравала цікавасць, таму што калі ўсё атрымаецца, то чувак аўтаматычна станавіўся б чалавекам, які ўмее наводзіць парадак і вырашаць невырашальныя задачы.
Такім чынам, перад ім стаяла задача: на працягу года зменшыць адхіленні па выніках інвентарызацыі ў 2 разу. У момант пачатку праекту ён не ўяўляў, як гэтага дамагчыся, але разумеў, што складскі ўлік - гэта рэч простая, таму ўсё роўна атрымаецца што-небудзь карыснае зрабіць. Тым больш, што знізіць адхіленні з дзясяткаў працэнтаў да аднаго дзясятка працэнтаў - гэта, накшталт, не так складана. Усе, хто працаваў у сферы кансультавання або падобнай дзейнасці, разумеюць, што большасць праблем працэсу ўстараняюцца дастаткова простымі дзеяннямі.
Са студзеня па май ён рыхтаваўся, крыху чагосьці аўтаматызаваў, перапісаў бізнес-працэс складскога ўліку, памяняў патокі працы кладаўшчыкоў, бухгалтараў і наогул усю сістэму перарабіў, нікому нічога не паказваючы і не расказваючы. У траўні ён раздаў усім новыя інструкцыі, і пасля першай у годзе інвентарызацыі пачалося новае жыццё - праца па яго правілах. Каб назіраць вынік, у далейшым кампанія стала праводзіць інвентарызацыі часцей - раз у два месяцы. Ужо першыя вынікі былі станоўчымі, а да канца года адхіленні па выніках рэвізіі ўпалі да доляй аднаго працэнта.
Поспех быў каласальны, але ў яго ўстойлівасць не верылася. Сам хлопец сумняваўся, што вынік захаваецца, калі адысці ўбок і перастаць назіраць за працэсам. Тым не менш, вынік быў, і хлопец атрымаў усё, аб чым дамаўляўся з уласнікам. Потым, праз некалькі гадоў, устойлівасць выніку пацвердзілася - некалькі гадоў адхіленні трымаюцца ў межах 1%.
Тады ён вырашыў паўтарыць эксперымент і прапанаваў уласніку ўдасканаліць іншы праблемны працэс - забеспячэнне. Там былі дэфіцыты, якія не дазвалялі адгружаць такія аб'ёмы, якія хацелі нашыя кліенты. Дамовіліся, што за год дэфіцыты знізяцца ўдвая, а чувак яшчэ выканае 10-15 праектаў, звязаных з 1С, – па аўтаматызацыі розных бізнес-працэсаў і іншай ерасі.
У другі год зноў усё паспяхова ўдалося завяршыць, дэфіцыты знізіліся больш як у 2 разы, усе IT-праекты былі завершаны паспяхова.
Паколькі заробак ужо цалкам задавальняў усе запыты таго хлопца, гады на два наперад, ён вырашыў крыху пасталець, супакоіцца і пасядзець на ўтульным цёплым месцы, якое сам жа сабе і стварыў.
Што яно сабой уяўляла? Фармальна, ён быў IT-дырэктарам. Але кім ён быў насамрэч быў, зразумець складана. Бо чым займаецца IT-дырэктар? Як правіла, ён адмініструе IT-інфраструктуру, кіруе сіс.адмінамі, укараняе ERP-сістэму, удзельнічае ў нарадах на радзе дырэктараў.
А ў гэтага чувака адной з ключавых абавязкаў быў удзел у працэсах змен, і ў асноўным - генерацыя, ініцыяванне гэтых працэсаў, пошук і прапанова рашэнняў, прымяненне новых методык кіравання, экспертыза прапанаваных змен, аналіз эфектыўнасці іншых функцый і падраздзяленняў, і, нарэшце - непасрэднае удзел у стратэгічным развіцці прадпрыемства, аж да самастойнай распрацоўкі стратэгічнага плана ўсёй кампаніі.
Яму далі карт-бланш. Ён мог прыходзіць на любую нараду, куды раней доступу не меў. Сядзеў там з блакнотам, чагосьці запісваў, ці проста слухаў. Казаў рэдка. Потым пачаў гуляць у тэлефоне - сцвярджаў, што так лепш працаваць асацыятыўная памяць.
На нарадзе рэдка нешта карыснае выдаваў. Сыходзіў, думаў, потым прылятаў ліст - ці з крытыкай, ці з меркаваннем, ці з прапановамі, ці з апісаннем рашэнняў, якія ён ужо прымяніў.
Але часцей збіраў нарады сам. Знаходзіў праблему, прыдумляў варыянты рашэння, вызначаў зацікаўленых асоб і цягнуў усіх у перагаворку. А там ужо - як умеў. Пераконваў, матываваў, даказваў, спрачаўся, дамагаўся.
Неафіцыйна ён лічыўся трэцяй асобай у кампаніі, пасля ўласніка і дырэктара. Зразумела, ён жудасна злаваў усіх «асоб кампаніі», пачынальна з нумара 4. Асабліва сваімі ірванымі джынсамі і яркімі футболкамі, а яшчэ – часам уласніка.
Уласнік надаваў яму 1 гадзіну ў дзень. Кожны дзень. Яны размаўлялі, абмяркоўвалі праблемы, рашэнні, новыя бізнесы, напрамкі развіцця, паказчыкі і эфектыўнасць, асабістае развіццё, кнігі, ды і проста - жыццё.
Але хлопец гэты быў дзіўны. Накшталт - сядзі і радуйся, жыццё атрымалася. Але не. Ён вырашыў парэфлексаваць.
Яму стала цікава: чаму вось у яго атрымалася, а ў іншых - не? Уласнік таксама падштурхоўваў яго: казаў, што жадае, каб у іншых таксама атрымлівалася наводзіць парадак, таму што мэнэджараў шмат, яны, як правіла, займаюцца аператыўным кіраваннем і стратэгічным планаваннем, але практычна ніхто не займаецца сістэмнымі зменамі сваіх працэсаў. У іх службовую інструкцыю, можа, і запісана, што яны павінны паскараць свой працэс, падвышаць яго эфектыўнасць, але па факце гэтым ніхто не займаецца. Чаму так? Вось хлопцу таксама стала цікава, чаму, і ён пайшоў з усімі гэтымі мэнэджэрамі размаўляць.
Ён прыйшоў да намесніка дырэктара па якасці, і прапанаваў укараніць кантрольныя карты Шухарта, каб у прадукцыя было лепш за японскую. Але аказалася, што калега не ведае, што такое кантрольныя карты Шухарта, што такое статыстычнае кіраванне працэсамі, і толькі краем вуха чуў пра прымяненне цыкла Дэмінга ў кіраванні якасцю. Добра…
Пайшоў ён да іншага намесніка дырэктара і прапанаваў укараніць кантролінг. Але і тут не знайшоў падтрымкі. Яшчэ крыху пазней ён даведаўся пра баундры менеджмент (boundary management, кіраванне межамі) і ўсім намеснікам дырэктара прапанаваў укараніць сістэмную частку гэтай методыкі, каб палепшыць працэсы. Але колькі наш хлопец не размаўляў, ніхто асабліва не хацеў унікаць, пра што гаворка. Можа, ім было нецікава ці занадта складана. Але, па факце, ніхто не разабраўся.
Увогуле, ён расказаў пра ўсё, што ведаў і прымяняў у кампаніі. Але ніхто яго так і не зразумеў. Ім і да гэтага часу незразумела, чаму, напрыклад, усё ўдалося выправіць у складскім уліку, прычым тут кантролінг і кіраванне межамі.
У апошнюю чаргу ён дайшоў да сваіх праграмістаў - у штат уваходзіла 3 чалавекі. Распавёў пра кіраванне межамі, пра кантролінг, пра мэнэджмент якасці, пра agile і scrum… І на здзіўленне яны ўсё зразумелі, і нават маглі з ім неяк абгаварыць, у тым ліку — тэхнічныя і метадычныя тонкасці. Яны зразумелі, чаму праекты па складзе і па забеспячэнні атрымаліся. І тут хлопца ахінула: насамрэч мір выратуюць праграмісты.
Праграмісты, зразумеў ён - адзіныя, хто змогуць нармальна, з патрэбнай дэталёвасцю разабрацца ў бізнес-працэсах.
Чаму менавіта яны? Насамрэч адназначнага адказу ён так і не знайшоў. Сфармуляваў толькі тэзісныя намёкі.
Па-першае, праграмісты ведаюць прадметныя вобласці бізнэсу, прычым, ведаюць іх лепш за ўсіх астатніх людзей у кампаніі.
Акрамя таго, праграмісты рэальна разумеюць, што такое алгарытм працэсу. Гэта важна таму, што бізнэс-працэсы - гэта алгарытмы, і элементы ў іх могуць быць банальна не ўзгодненыя. Напрыклад, у працэсе па забеспячэнні, над якім хлопец працаваў, першы крок - гэта складанне гадавога плана закупак, а другі - штодзённая закупка. Гэтыя крокі злучаныя прамой сувяззю, гэта значыць мяркуецца, што па гэтым алгарытме людзі павінны працаваць - складаць гадавы план закупак і тут жа выконваць заяўку. Гадавы план закупак складаецца раз на год, а заяўка паступае па 50 разоў на дзень. На гэтым алгарытм заканчваецца, і па ім трэба працаваць. На самай справе, разважыў ён, для праграмістаў веданне алгарытмаў - гэта канкурэнтная перавага, таму што любы іншы чалавек, не знаёмы з імі, проста не разумее, як бізнес-працэс павінен працаваць, і як гэта можна адлюстраваць.
Яшчэ адзін плюс праграмістаў, па словах таго хлопца - у іх дастаткова вольнага часу. Мы ўсё разумеем, як праграміст можа марнаваць на задачу ў тры разы даўжэй часу, чым на самой справе яна патрабуе, і мала хто гэта заўважыць. Гэта, зноў жа, канкурэнтная перавага, таму што для таго, каб прыводзіць нейкі бізнэс працэс у парадак, трэба мець шмат вольнага часу - думаць, назіраць, вывучаць і спрабаваць.
Большасць мэнэджараў, па словах хлопца, гэтага вольнага часу не маюць і ганарацца гэтым. Хоць фактычна гэта азначае, што чалавек не можа стаць эфектыўным, таму што ў яго няма часу на павышэнне эфектыўнасці - замкнёнае кола. У нашай культуры модна быць занятым, таму ўсё застаецца на месцы. А для нас, праграмістаў, гэтая перавага. Мы можам знайсці вольны час і пра ўсё падумаць.
Праграмісты, расказваў ён, могуць хутка памяняць інфармацыйную сістэму. Гэта не на ўсіх прадпрыемствах дастасавальна, але ўсюды, дзе ён працаваў, можна было ўносіць любыя дапрацоўкі, якія заманецца. Асабліва, калі яны не датычацца нічыёй працы. Напрыклад, ён мог запусціць сістэму, якая будзе таемна вымяраць дзеянні карыстальнікаў, і выкарыстоўваць затым гэтую інфармацыю - для аналізу эфектыўнасці працы той жа бухгалтэрыі і адсочвання кошту вядзення ўліку.
І апошняе, што я запомніў з яго слоў - праграмісты маюць доступ да вялікай колькасці інфармацыі, т.я. надзелены адміністрацыйным доступам да сістэмы. Таму могуць карыстацца гэтай інфармацыяй у сваім аналізе. Ніхто іншы на звычайным заводзе такім рэсурсам не валодае.
А потым ён сышоў. Падчас пакладзенай двухтыднёвай адпрацоўкі мы прымусілі яго падзяліцца досведам, таму што хацелі працягваць справу, якой ён займаўся. Ну і пасада яго станавілася вакантнай.
На працягу некалькіх дзён сядалі на крэсла, уключалі камеру і запісвалі яго маналогі. Прасілі расказаць пра ўсе выкананыя праекты, метады, падыходы, поспехі і няўдачы, прычыны і вынікі, партрэты кіраўнікоў і г.д. Асоба не абмяжоўвалі, т.к. не ведалі, што ў яго ў галаве робіцца.
У маналогах, вядома, у асноўным была ўсякая лухта і іржака - ён знаходзіўся ў выдатным настроі, т.к. адбываў з глухмені ў Піцер. А куды ехаць працаваць у Піцеры? У Газпром, вядома.
Але сёе-тое карыснае нам удалося выцягнуць з яго маналогаў. Раскажу, што памятаю.
Такім чынам, рэкамендацыі таго хлопца. Тым, хто захоча паспрабаваць заняцца навядзеннем парадку ў бізнес-працэсах.
Каб займацца такой працай, па-першае, трэба мець пэўны ўзровень "адмарожанасці". Трэба не баяцца згубіць працу, не баяцца рызыкнуць, не баяцца канфліктаў з калегамі. У яго гэта атрымлівалася лёгка, таму што пачаў ён свой шлях, калі прапрацаваў у кампаніі ўсяго паўгода, і не паспеў ні з кім уступіць у кантакт, ды і не збіраўся гэта рабіць. Ён разумеў, што людзі прыходзяць і сыходзяць, а для яго важныя яго ўласныя вынікі і іх ацэнка уласнікам бізнесу. Дрэнна ці добра да яго ставяцца калегі - яго гэта мала тады хвалявала.
Другі момант - каб эфектыўна займацца гэтай працай, на жаль, давядзецца вучыцца. Але вучыцца не на MBA, не на курсах, не ў інстытутах, а самастойна. Напрыклад, у першым сваім праекце, па складзе, ён дзейнічаў інтуітыўна, нічога не ведаў, толькі што такое "кіраванне якасцю".
Калі ён пачаў чытаць літаратуру, якія метады павышэння эфектыўнасці існуюць, то выявіў тыя тэхналогіі, якія прымяняў. Хлопец інтуітыўна іх ужываў, а аказваецца, гэта не яго выдумка, усё ўжо было даўно напісана. Але ён патраціў час, і нашмат больш, чым калі б адразу прачытаў патрэбную кнігу. Тут толькі важна разумець, што калі вывучаеш пэўную методыку, ніводная з іх, нават самая прасунутая, цалкам не вырашыць усе праблемы бізнес-працэсу.
Другая фішка ў тым, што чым больш методык вы ведаеце, тым лепей. Напрыклад, у старажытнай Японіі жыў Міямота Мусасі - адзін з самых вядомых фехтавальшчыкаў, аўтар стылю двух мячоў. Ён вучыўся ў нейкай школе ў нейкага майстра, потым падарожнічаў па Японіі, ваяваў з рознымі чувакамі. Калі чувак быў мацнейшым, то падарожжа на нейкі час спынялася, і Мусасі ішоў у вучні. У выніку ён за некалькі гадоў набываў навыкі розных практык розных майстроў і сфарміраваў сваю ўласную школу, дадаючы нешта сваё. У выніку ў яго атрымалася ўнікальнае майстэрства. Тут тое самае.
Можна, вядома, дзейнічаць як бізнэс-кансультанты. Наогул, яны выдатныя хлопцы. Але, як правіла, прыходзяць, каб укараніць нейкую методыку, і ўкараняюць не тую методыку, якая патрэбная бізнэсу. У нас таксама былі такія сумныя сітуацыі: ніхто не ведае, як вырашыць праблему і ніхто не жадае думаць, як яе вырашыць. Пачынаем шукаць альбо ў інтэрнэце, альбо зваць кансультанта, і пытаемся ў яго, што нам можа дапамагчы. Кансультант думае і кажа, што трэба тэорыю абмежаванняў укараніць. Плацім яму за рэкамендацыю, які марнуецца на ўкараненне, але выніку нуль.
Чаму так атрымоўваецца? Таму што кансультант сказаў, укараняем нейкую сістэму, і ўсё пагадзіліся з ім. Выдатна, але адна методыка не закрывае ўсіх праблем нават аднаго бізнес-працэсу, асабліва калі не супадаюць зыходныя перадумовы - нашы і тыя, што патрабуюцца для ўкаранення методыкі.
У практыцы, якую хлопец рэкамендуе, трэба браць найлепшае і ўкараняць лепшае. Ня браць метады цалкам, а браць іх ключавыя асаблівасці, фішкі, практыкі. І самае важнае - трэба разумець сутнасць.
Возьмем, казаў ён, да прыкладу, скрам (scrum) ці эджайл. У маналогах хлопец шмат разоў паўтарыў, што не ўсе да канца разумеюць сутнасць скраму. Ён таксама чытаў кнігу Джэфа Сазерленда, якая некаторым здаецца "лёгкім чытвом". Яму яна здалася глыбокім чытвом, таму што адна з асноўных асноў скрама - гэта кіраванне якасцю, пра гэта ў кнізе напісана прама.
Там напісана пра Toyota Production, пра тое, як Джэф Сазерленд паказваў скрам у Японіі, наколькі ён там прыжыўся і было блізка іх філасофіі. І Сазерленд расказваў пра важнасць ролі скрам-майстра, пра цыкл Дэмінга. Роля скрам-майстра - гэта пастаяннае паскарэнне працэсу. Усё астатняе, што ёсць у скраме, - паэтапная здача, задавальненне заказчыка, дакладны пералік работ на перыяд спрынту - таксама важна, але гэта ўсё павінна рухацца ўсё хутчэй і хутчэй. Хуткасць працы павінна ўвесь час узрастаць у тых адзінках, у якіх яна вымяраецца.
Магчыма, тут справа ў перакладзе, таму што ў нас кнігу пераклалі як «Скрам – рэвалюцыйны метад кіравання праектамі», а калі даслоўна англійскую назву перакладаць, то атрымаецца: «Скрам – у два разы больш за ўдвая меншы тэрмін», гэта значыць нават у назве ідзе адсылка да хуткасці, як ключавой функцыі скраму.
Калі гэты хлопец укараняў скрам, за першы месяц хуткасць павялічылася ўдвая без якіх-небудзь асаблівых змен. Ён знайшоў кропкі для змен, мадыфікаваў сам скрам пад сябе, каб ён працаваў нашмат хутчэй. Адзінае, як у інтэрнэце пішуць, — перад імі паўстала пытанне: "Мы павялічылі хуткасць удвая, засталося зразумець, што ж мы робім з такой хуткасцю?". Зрэшты, гэта ўжо зусім іншая вобласць…
Яшчэ ён асабіста рэкамендаваў некалькі методык. Назваў іх фундаментальнымі і асноватворнымі.
Першая - boundary management (кіраванне межамі).
Выкладаюць яго ў "Сколкава", іншых кніг і матэрыялаў, па сцвярджэннях хлопца, няма. Яму неяк пашчасціла прысутнічаць на лекцыі прафесара з Гарварда, які прапаведуе boundary management, а таксама прачытаць некалькі артыкулаў у Harvard Business Review пра працы Эрыка Трыста.
Boundary management кажа аб тым, што трэба ўмець бачыць межы і працаваць з межамі. Меж поўна, яны паўсюль - паміж аддзеламі, паміж рознымі відамі работ, паміж функцыямі, паміж аператыўнай і аналітычнай працай. Веданне boundary management не адчыняе нейкіх вышэйшых ісцін, але дазваляе бачыць рэальнасць у некалькі іншым святле — праз прызму меж. І, адпаведна, кіраваць імі - узводзіць там, дзе гэта неабходна, і прыбіраць там, дзе яны перашкаджаюць.
Але больш і часцей за ўсё хлопец казаў пра кантролінг. Прам бзік нейкі ў яго быў на гэтую тэму.
Кантролінг, калі коратка - гэта кіраванне на аснове лічбаў. Тут, казаў ён, важная кожная частка вызначэння - і "кіраванне", і "на аснове", і "лічбаў".
У нас, казаў ён, дрэнна з усімі трыма складнікамі кантролінгу. Асабліва калі ўлічыць, што яны цесна ўзаемазвязаны як сябар з сябрам, так і з іншымі часткамі бізнэс-сістэмы.
Першае, што дрэнна - лічбы. Іх мала і яны нізкай якасці.
Значную частку лічбаў мы тады бралі з інфармацыйнай сістэмы 1С. Дык вось, якасць лічбаў у 1С, як ён сцвярджаў, нікуды не падыходзіць. Прынамсі, з-за магчымасці змяняць дадзеныя заднім лікам.
Зразумела, што віны распрацоўшчыкаў 1С у гэтым няма - яны толькі ўлічваюць патрабаванні рынку і менталітэту айчыннага ўліку. Але для мэт кантролінгу прынцыпы працы 1С з дадзенымі лепш змяніць, на пэўным прадпрыемстве.
Далей лічбы з 1С, паводле яго слоў, праходзяць паўручную апрацоўку, з выкарыстаннем Excel, напрыклад. Якасці дадзеных, роўна як і аператыўнасці, такая апрацоўка таксама не дадае.
У рэшце рэшт, выніковую справаздачу яшчэ нехта пераправярае, каб выпадкова не падаць кіраўніку лічбы з памылкамі. У выніку, лічбы трапляюць да адрасата прыгожымі, праверанымі, але вельмі позна. Звычайна - пасля заканчэння перыяду (месяца, тыдня, і г.д.).
І тут, казаў ён, усё вельмі проста. Калі лічбы аб студзені вам патрапілі ў лютым, то дзейнасцю студзеня вы ўжо кіраваць не можаце. Бо студзень ужо скончыўся.
А калі лічбы заснаваныя на бух. ўліку, і кампанія - самая звычайная, з паквартальнай здачай ПДВ, то адносна адэкватныя лічбы яе кіраўнік атрымлівае раз у квартал.
Далей зразумела. Атрымліваеце лічбы раз у месяц - у вас ёсць магчымасць кіраваць па лічбах (г.зн. ажыццяўляць кантролінг) 12 раз у год. Практыкуеце квартальную справаздачнасць - кіруеце 4 разы на год. Плюс бонус - гадавая справаздачнасць. Яшчэ разок паруліць.
Астатні час кіраванне, як правіла, выконваецца ўсляпую.
Калі (і калі) лічбы ўсё ж такі з'яўляюцца, то ўступае ў дзеянне другая праблема - як кіраваць на аснове лічбаў? Вось з гэтым пунктам ягоных разваг я так і не змог пагадзіцца.
Хлопец сцвярджаў, што калі лічбаў у кіраўніка раней не было, тое іх з'яўленне выкліча ваў-эфект. Ён будзе глядзець і круціць лічбы і так і гэтак, выклікаць людзей на дыван, патрабаваць тлумачэнняў і расследаванняў. Пагуляўшы з лічбамі, правёўшы разборы, грозна паабяцаўшы ўсім супрацоўнікам, што «ўжо зараз я з вас не слязу», кіраўнік вельмі хутка супакоіцца і кіне гэтую справу. Інструментам карыстацца перастане. А праблемы застануцца на месцы.
Так адбываецца, казаў ён, праз недастатковыя кампетэнцыі кіраўніка. У кантролінгу, у першую чаргу. Кіраўнік проста ня ведае, што рабіць з гэтымі лічбамі. Што срабіць - ведае, што рабіць - не. Зрабіць - гэта тое, пра што напісана вышэй (палаяцца, пагуляць). Рабіць - гэта штодзённы бізнес-працэс.
Ён сьцьвярджаў, што ўсё вельмі проста: лічба павінна стаць часткай бізнэс-працэсу. У бізнес-працэсе павінна быць дакладна зразумела: хто, што, і калі павінен рабіць пры адхіленні лічбы ад нормы (любыя варыянты - вышэй мяжы, ніжэй мяжы, выхад за калідор, наяўнасць трэнду, невыкананне квантылю і г.д.)
І вось ён абазначыў ключавую дылему: лічба ёсць, яна павінна стаць часткай бізнес-сістэмы, каб павысіць эфектыўнасць кіравання, але… гэтага не адбываецца. Чаму?
Бо расейскі кіраўнік не аддасць канкурэнту кавалак сваёй улады.
Канкурэнты расійскага кіраўніка - якасны і які працуе бізнэс-працэс, прадуманая ўзаемавыгадная матывацыя і правільная аўтаматызацыя - нажаль, пакінуць кіраўніка без працы.
Лухта нейкая, пагодзіцеся? Асабліва пра кіраўнікоў. Добра, я расказаў, вы самі вырашайце.
Крыху менш, але ўсё роўна занадта шмат, на мой погляд, ён казаў пра скрам.
Абавязкова, казаў, прачытайце і паспрабуйце на практыцы скрам. Калі, кажа, чыталі, але не спрабавалі - лічыце, што не ведаеце. Чытаць лепш кнігу, напрыклад Сазерленда, а не артыкулы і ўсякія там гайды (што за хрень?) у інтэрнэце.
Скрам, казаў ён, спазнаецца толькі практыкай, і з абавязковымі вымярэннямі аб'ёмаў выкананай працы. Асабіста паспрабуйце дзве найважнейшыя ролі – уладальніка прадукта і скрам-майстра.
Асабліва важна, па словах хлопца, адчуць на практыцы ролю скраму-майстра, калі вы зможаце павялічыць аб'ём зачыняюцца за спрынт задач, не павялічваючы рэсурсы і кошт спрынту.
Ну і яшчэ ў яго топе быў ТГС (тэорыя абмежаванняў сістэм).
Гэта, паводле слоў хлопца, базавыя, фундаментальныя прынцыпы павышэння эфектыўнасці, якія можна прымяніць практычна ў любой галіне, у любым бізнес-працэсе і бізнес-сістэме ў цэлым.
Калі ён даведаўся, што мы не знаёмыя з ТГС, то перастаў расказваць. Толькі дадаў, што не будзе пазбаўляць нас задавальнення ад чытання кніг Эліяху Голдрата. Рэкамендацыю даў аналагічную скраму - прачытайце і паспрабуйце. Тыпу, на якой бы пасады вы не знаходзіліся, якую б працу не выконвалі, там знойдзецца месца для павышэння эфектыўнасці метадамі ТГС.
Потым у яго багаж методык, мабыць, вычарпаўся, і ён сказаў: міксуйце прынцыпы, для стварэння прыкладных рашэнняў у канкрэтнай сітуацыі.
Гэта, гаворыць, галоўная рэкамендацыя, ключ да поспеху. Зразумейце прынцыпы, сутнасць, і стварайце ўнікальныя прыкладныя рашэнні - бізнес-працэсы і бізнес-сістэмы.
Потым ён намагаўся ўспомніць нейкую цытату, у выніку прыйшлося лезці ў інтэрнэт. Аказалася, цытата з артыкула «Стоячы на плячах гігантаў» Эліяху Голдрата:
«Ёсць розніца паміж прыкладнымі рашэннямі (прымяненнямі) і фундаментальнымі канцэпцыямі, на якіх заснаваны гэтыя рашэнні. Канцэпцыі з'яўляюцца агульнымі, прыкладныя рашэнні - гэта адаптацыя канцэпцый да канкрэтнай асяроддзя. Як мы ўжо бачылі, падобная адаптацыя не з'яўляецца простай і робіць неабходнай распрацоўку пэўных элементаў рашэння. Мы павінны памятаць - прыкладное рашэнне заснавана на зыходных пасылках (часам - утоеных) аб канкрэтным асяроддзі. Не трэба чакаць, што гэтае прыкладнае рашэнне будзе працаваць у асяроддзі, для якога зыходныя пасылкі не дакладныя».
Сказаў, што праца праграміста і "паляпшальніка бізнэс-працэсаў" – вельмі падобныя. І сышоў.
Крыніца: habr.com