Историята е реална, видях всичко със собствените си очи.
Няколко години един момък, както и много от вас, работеше като програмист. За сведение ще напиша така: „програмист“. Защото той беше 1С специалист, в производствена компания.
Преди това беше пробвал различни професии - 4 години работи като програмист във франчайз, ръководител на проекти, успяваше да затвори по 200 часа, едновременно получавайки процент от проекта за ръководство и малко занимавайки се със sales. Опитваше се да разработва продукти сам, беше началник на IT отдела в голяма компания с 6000 служители и опитваше различни начини за приложение на своята кавички професия - програмист 1С.
Но всичките тези позиции бяха малко безизходни, в първата редица по доходите. Всички ние тогава получавахме приблизително същите пари, работехме при едни и същи условия.
На този момък му стана интересно как може да печели повече пари, без да се занимава със sales и без да създава собствен бизнес.
Той се възприемаше за умник и реши да намери ниша в компанията, където работеше. Нишата трябваше да бъде нещо специално, никой да не я обработва. И искаше компанията сама да желае да плаща пари на човек в тази ниша, така че да не се налага да лъже или да манипулира. За да бъде обективно: на този пост трябваше да се плаща много.
Търсенето не продължи дълго. В компанията, където работеше, имаше напълно свободна ниша, която условно можем да наречем „организация на бизнес процесите“. Във всяка компания има куп проблеми. Винаги нещо не работи и няма човек, който да дойде и да реши бизнес процеса. Така че той реши да опита себе си в ролята на специалист, който може да помогне на собственика да реши проблемите в бизнес процесите.
В момента той работеше в компанията от шест месеца и получаваше средна заплата на пазара. Нямаше какво да губи - особено, че подобна работа можеше да намери в рамките на една седмица. Общо взето, този момък реши, че нищо страшно няма да се случи, ако случайно не се получи и го уволнят.
Той събра смелост и отиде при собственика. Предложи му да подобри най-проблематичния процес в бизнеса. В този момент това беше складовото счетоводство. Сега на всички, които работят в тази компания, дори им е срам да си припомнят проблемите, но инвентаризациите, които се провеждаха на всеки три месеца, показваха разлики между счетоводната система и действителните остатъци от десетки проценти. И по стойност, и по количество, и по брой позиции. Това беше бедствие. Компанията реално имаше точни остатъци в счетоводната система само четири пъти в годината – на следващия ден след инвентаризацията. Този процес нашият герой започна да оправя.
Момчето договори с собственика, че трябва да намали отклоненията по резултатите от инвентаризацията наполовина. И собственика нямаше какво особено да губи, защото преди нашия герой различни работници бяха опитвали да поправят всичко и общо-взето задачата се считаше почти нерешима. Всичко това силно подгряваше интереса, защото ако всичко успее, то той автоматично щеше да стане човек, който умее да въведе ред и да решава нерешими задачи.
И така, пред него стоеше задачата: в рамките на година да намали отклоненията по резултатите от инвентаризацията наполовина. В момента на започване на проекта той не знаеше как да постигне това, но осъзнаваше, че складовото счетоводство е проста работа, така че все пак ще успее да направи нещо полезно. Още повече, че да се намалят отклоненията от десетки проценти до едноцифрени не е толкова трудно. Всички, които работят в сферата на консултантските услуги или подобна дейност, разбират, че повечето проблеми в процеса се отстраняват с доста прости действия.
От януари до май той се подготвя, малко автоматизира, пренаписва бизнес процеса на складовото счетоводство, променя потоците на работа на складовите работници, счетоводителите и изобщо преработва цялата система, без да показва и разказва на никого. През май той раздава нови инструкции на всички и след първата инвентаризация за годината започва нов живот - работа по неговите правила. За да види резултата, компанията започва да провежда инвентаризации по-често - на всеки два месеца. Първите резултати са положителни, а до края на годината отклоненията по резултатите от ревизията падат до части от един процент.
Успехът е колосален, но в устойчивостта му не се вярва. Самият младеж се съмнява, че резултатът ще остане, ако отстъпи настрани и спре да наблюдава процеса. Въпреки това, резултатът е налице и младежът получава всичко, за което се е разбирал със собственика. След няколко години устойчивостта на резултата се потвърдява - отклоненията остават в рамките на 1%.
Тогава той решава да повтори експеримента и предлага на собственика да усъвършенстват друг проблемен процес - снабдяването. Там имаше дефицити, които попречиха да се изпращат толкова обеми, колкото искаха нашите клиенти. Съгласяват се, че за година дефицитите ще се намалят наполовина, а младежът ще изпълни още 10-15 проекта, свързани с 1С - по автоматизация на различни бизнес процеси и всякаква друга глупост.
През втората година отново всичко успешно завършва, дефицитите намаляват с повече от 2 пъти, всички IT проекти са успешно завършени.
След като заплатата вече напълно удовлетворява всички искания на младежа, за две години напред, той решава да се успокои, да се успокои и да се настани на уютно топло място, което сам е създал.
Какво представляваше то? Формално, той беше IT директор. Но е трудно да се разбере какъв наистина беше той. Защото какво прави IT директор? Обикновено той администрира IT инфраструктурата, ръководи системните администратори, внедрява ERP системи, участва в заседания на борда на директорите.
При него една от основните задължения беше участието в процесите на промени, основно — генерирането, инициирането на тези процеси, търсенето и предлагането на решения, приложението на нови управленски методи, експертизата на предложените промени, анализът на ефективността на други функции и подразделения, и накрая — пряко участие в стратегическото развитие на предприятието, дори до самостоятелното разработване на стратегическия план на цялата компания.
Дадоха му картбланш. Можеше да присъства на всяка среща, до която преди не имаше достъп. Сидеше там с тетрадка, записваше нещо или просто слушаше. Говореше рядко. После започваше да играе на телефона — твърдеше, че така работи по-добре асоциативната памет.
На срещите рядко изказваше нещо полезно. Излизаше, мислеше, след това получаваше имейл — или с критика, или с мнение, или с предложения, или с описание на решения, които вече беше приложил.
Но по-често сам събираше срещи. Откриваше проблема, измисляше варианти за решение, определяше заинтересованите лица и ги водеше в разговорната стая. А там — каквото можеше. Убедяваше, мотивираше, доказваше, спори, постига.
Неофициално той се считаше за третото лице в компанията, след собственника и директора. Разбира се, той ужасно дразнеше всички "лица на компанията", започвайки от номер 4. Особено със своите изтъркани дънки и ярки тениски, а също и — времето на собственника.
Собственикът му отделяше 1 час на ден. Всеки ден. Говореха, обсъждаха проблеми, решения, нови бизнеси, направления за развитие, показатели и ефективност, личностно развитие, книги, просто — живот.
Но момчето беше странно. Все едно — сиди и радвай се, животът е успешен. Но не. Реши да порефлектира.
Интересно му: защо той успя, а другите - не? Собственикът също го подтикваше: казваше, че иска и другите да могат да подреждат нещата, защото има много мениджъри, които, като правило, се занимават с оперативно управление и стратегическо планиране, но практически никой не се занимава със системни промени на своите процеси. В тяхната длъжностна характеристика може и да е записано, че следва да ускоряват процеса си, да увеличават неговата ефективност, но по факти това никой не прави. Защо така? Е, момчето също се заинтересува защо и тръгна да разговаря с всичките тези мениджъри.
Той отиде при зам. директора по качеството и предложи да внедрят контролни карти на Шухарт, за да е продуктът по-добър от японския. Но се оказа, че колегата не знае какво са контролни карти на Шухарт, какво е статистическо управление на процесите, и само е чул накрая за прилагането на цикъла на Деминг в качественото управление. Добре…
Той отиде при друг зам. директор и предложи да внедрят контролинг. Но и тук не намери подкрепа. Малко по-късно научи за управлението на граници и предложи на всички зам. директори да внедрят системната част на тези методики, за да подобрят процесите. Но колкото и да говореше, никой не искаше особено да се интересува какво става. Може би им беше неинтересно или прекалено сложно. Но, по факти, никой не се справи с това.
В общи линии, той разказа всичко, което знаеше и прилагаше в компанията. Но никой не го разбра. И до днес не им е ясно, защо, например, всичко беше успешно поправено в складовия учет, и какво касае контролингът и управлението на границите.
Накрая стигна до своите програмисти – в екипа имаше 3 души. Разказа им за управлението на границите, за контролинга, за качественото управление, за agile и scrum… И на изненада те всички разбраха и дори можеха да обсъждат с него, включително – техническите и методическите нюанси. Те разбраха защо проектите за склада и за доставки се получиха. И тогава момчето осъзна: всъщност светът ще бъдат спасен от програмистите.
Програмистите, осъзна той – единствените, които ще могат адекватно и с нужната детайлност да се разберат в бизнес процесите.
Защо точно те? Всъщност не намери еднозначен отговор. Формулира само тезисни намеци.
На първо място, програмистите познават предметните области на бизнеса, дори по-добре от всеки друг в компанията.
Освен това, програмистите наистина разбират какво е алгоритъм на процеса. Това е важно, защото бизнес-процесите са алгоритми и елементите в тях могат да не са банално координирани. Например, в процеса на снабдяване, по който момчето работеше, първата стъпка е изготвяне на годишен план за покупки, а втората – ежедневно закупуване. Тези стъпки са свързани директно, тоест се предполага, че хората трябва да работят по този алгоритъм – да изготвят годишен план за покупки и в същото време да изпълняват заявките. Годишният план за покупки се изготвя веднъж годишно, а заявките пристигат 50 пъти на ден. На този алгоритъм всичко свършва, и по него трябва да се работи. В действителност, разсъждаваше той, за програмистите знанието на алгоритми е конкурентно предимство, защото всеки друг човек, незапознат с тях, просто не разбира как трябва да работи бизнес процесът и как може да се изобрази.
Още едно предимство на програмистите, според думите на момчето – те имат достатъчно свободно време. Всички разбираме как програмистът може да отдели три пъти повече време за задача, отколкото всъщност е необходимо, и малко хора ще забележат това. Това отново е конкурентно предимство, защото, за да приведеш даден бизнес процес в ред, трябва да имаш много свободно време – да мислиш, наблюдаваш, изучаваш и експериментираш.
Повечето ръководители, по думите на момчето, нямат това свободно време и се гордеят с това. Въпреки че всъщност това означава, че човек не може да стане ефективен, защото няма време за повишаване на ефективността – замкнат кръг. В нашата култура е модерно да бъдеш зает, затова всичко остава на едно и също място. А за нас, програмистите, това е предимство. Ние можем да намерим свободно време и да помислим за всичко.
Програмистите, разказваше той, могат бързо да променят информационната система. Това не важи за всички предприятия, но навсякъде, където той е работил, можеше да се извършват каквито и да е подобрения, които се преценят за подходящи. Особено, ако не засягат работата на никого. Например, той можеше да стартира система, която тайно измерва действията на потребителите и след това да използва тази информация за анализиране на ефективността на същата счетоводство и проследяване на разходите за водене на счетоводство.
И последното, което запомних от думите му – програмистите имат достъп до голямо количество информация, тъй като са наделени с административен достъп до системата. Затова могат да използват тази информация в своя анализ. Никой друг в обикновен завод не разполага с такъв ресурс.
А после той си тръгна. По време на предвидените две седмици за отработване ние го накарахме да сподели опита си, защото искахме да продължим начинанието, с което се занимаваше. А постът му стана вакантен.
През следващите няколко дни го настанявахме на стола, включвахме камерата и записвахме монотоните му. Молихме го да разкаже за всички изпълнени проекти, методи, подходи, успехи и провали, причини и последствия, портрети на ръководителите и т.н. Не го ограничаваме особено, тъй като не знаехме какво става в главата му.
В монотоните, разбира се, основно имаше всякакви глупости и смешки — той беше в прекрасно настроение, тъй като напускаше отдалеченото място и се отправяше към Питер. А къде да работи в Питер? В Газпром, разбира се.
Но успяхме да извлечем нещо полезно от неговите монолози. Ще разкажа какво помня.
И така, препоръките на онзи човек. На тези, които искат да опитат да се заемят с подреждането на бизнес процесите.
За да се занимаваш с такава работа, първо трябва да имаш определено ниво на "отмора". Трябва да не се страхуваш да загубиш работата си, да не те е страх да рискуваш, да не те е страх от конфликти с колеги. При него това ставаше лесно, защото е започнал пътя си, когато е работил в компанията само половин година и не е успял да установи контакт с никого, нито е планирал да го направи. Той разбираше, че хората идват и си отиват, а за него важни са собствените му резултати и тяхната оценка от собственика на бизнеса. Дали колегите го считат за добър или лош — това не го интересуваше особено тогава.
Вторият момент е, че за да се занимавате ефективно с тази работа, за съжаление, ще трябва да учите. Но не на MBA, не на курсове, не в институти, а самостоятелно. Например, в първия си проект, свързан с склада, той действа интуитивно, нищо не знаеше, само че съществува "управление на качеството".
Когато започна да чете литература относно методите за повишаване на ефективността, откри онези технологии, които прилагаше. Момчето интуитивно ги използваше, а се оказа, че това не е негово изобретение, всичко вече беше написано отдавна. Но той загуби време и много повече, отколкото ако беше прочел необходимата книга веднага. Тук е важно да се разбере, че когато изучавате конкретна методология, нито една от тях, дори и най-развитата, няма да реши напълно всички проблеми на бизнес процеса.
Втората идея е, че колкото повече методики знаете, толкова по-добре. Например, в древна Япония живял Миямото Мусаси – един от най-известните фехтовачи, автор на стила с два меча. Той учил в някаква школа при някакъв майстор, след което пътувал из Япония, сражавал се с различни хора. Ако някой е бил по-силен, пътуването за известно време спирало и Мусаси ставал ученик. В резултат той в продължение на няколко години придобивал умения от различни практики на различни майстори и формирал собствената си школа, добавяйки нещо свое. В крайна сметка той развил уникално майсторство. Тук е същото.
Може, разбира се, да действате като бизнес консултанти. Всъщност, те са страхотни хора. Но обикновено идват, за да внедрят някаква методология, и внедряват не онова, което е нужно на бизнеса. И при нас имаше такива тъжни ситуации: никой не знае как да реши проблема и никой не иска да мисли как да го реши. Започваме да търсим или в интернет, или да викнем консултант, и питаме него какво може да ни помогне. Консултантът мисли и казва, че трябва да внедрим теорията на ограниченията. Плащаме му за препоръката, харчим за внедряването, но резултатът е нулев.
Защо се получава така? Защото консултантът казал, внедряваме такава система и всички се съгласили с него. Прекрасно, но една методика не покрива всички проблеми дори на един бизнес процес, особено ако не съвпадат основните предпоставки — нашите и тези, които са необходими за внедряване на методологията.
В практиката, която момчето препоръчва, трябва да вземем най-доброто и да внедрим най-доброто. Не трябва да взимаме методите изцяло, а да вземем техните ключови характеристики, особености, практики. И най-важното - трябва да разберем същността.
Да вземем, казва той, например, скрам (scrum) или еджайл. В монолозите момчето многократно повтори, че не всички напълно разбират същността на скрама. Той също чете книгата на Джеф Сазърленд, която на някои им се струва „леко четиво“. На него му се стори дълбоко четиво, защото една от основополагающите основи на скрама - това е управлението на качеството, за което в книгата е написано директно.
Там е написано за производството на Тойота, за това как Джеф Сазърленд показвал скрам в Япония, колко добре е приет там и колко е близък до тяхната философия. И Сазърленд разказва за важността на ролята на скрам-мастера, за цикъла на Деминг. Ролята на скрам-мастера - това е постоянно ускоряване на процеса. Всичко останало, което има в скрама - етапна предажа, удовлетворение на клиента, ясен списък на задачите за периода на спринта - също е важно, но всичко това трябва да се движи все по-бързо и по-бързо. Скоростта на работа трябва постоянно да нараства в тези единици, в които се измерва.
Може би тук става дума за превода, защото при нас книгата е преведена като „Скрам - революционен метод за управление на проекти“, а ако дословно преведем английското заглавие, ще се получи: „Скрам - два пъти повече за два пъти по-кратки срокове“, тоест дори в заглавието има насочване към скоростта, като ключова функция на скрама.
Когато това момче внедряваше скрам, за първия месец скоростта се увеличи два пъти без някакви специални изменения. Той намери точки за промени, модифицира самия скрам според себе си, за да работи много по-бързо. Единственото, както пишат в интернет, - пред тях възникна въпросът: „Увеличихме скоростта два пъти, остава да разберем какво правим с такава скорост?“. Впрочем, това вече е съвсем друга област...
Той също така лично препоръча няколко методики. Нарече ги основополагающи и фундаментални.
Първата - управление на границите (boundary management).
Преподават го в «Сколково», другите книги и материали, по твърденията на момчето, липсват. Някак си е имал късмета да присъства на лекция на професор от Харвард, който проповядва управление на границите, както и да прочете няколко статии в Harvard Business Review за работата на Ерик Триста.
Управление на границите говори за това, че трябва да можем да виждаме границите и да работим с тях. Наоколо има много граници — между отделите, между различните видове работа, между функциите, между оперативната и аналитичната работа. Знанието за управление на границите не разкрива висши истини, но позволява да виждаме реалността в съвсем различна светлина — през призмата на границите. И, съответно, да ги управляваме — да поставяме там, където е необходимо, и да премахваме там, където пречат.
Но момчето основно говореше за контролинг. Направо имаше мания по тази тема.
Контролингът, накратко, е управление на базата на числа. Тук, казваше той, е важна всяка част от определенията — и «управление», и «на базата на», и «числа».
При нас, казваше той, лошо е с всичките три съставки на контролинга. Особено ако вземем предвид, че те са тясно свързани помежду си, както и с други части на бизнес системата.
Първото, което е зле — числата. Техният брой е малък и качеството им е ниско.
Значителна част от числата тогава взимахме от информационната система 1С. Така че, качеството на числата в 1С, както той твърдеше, не струва. Минимум, заради възможността за промяна на данните назад във времето.
Ясно е, че вината на разработчиците на 1С в това няма — те просто отразяват изискванията на пазара и манталитета на родното счетоводство. Но за целите на контролинга е по-добре принципите на работа на 1С с данните да бъдат променени в конкретното предприятие.
След това числата от 1С, по неговите думи, преминават през полуръчна обработка, с използване на Excel, например. Такъв вид обработка не добавя качество на данните, нито на оперативността.
В крайна сметка, окончателният отчет все още някой го преглежда, за да не подаде случайно на ръководителя числа с грешки. В резултат, числата стигат до адресата красиви, проверени, но много късно. Обикновено — след края на периода (месец, седмица и т.н.).
И тук, казваше той, всичко е много просто. Ако числата за януари ви стигнат през февруари, вече не можете да управлявате дейността на януари. Защото януари вече е приключил.
Ако цифрите са базирани на счетоводството и компанията е съвсем обикновена с ежеквартално деклариране на ДДС, тогава ръководителят получава относително адекватни цифри веднъж на тримесечие.
После става ясно. Получавате цифри веднъж месечно — имате възможност да управлявате по цифри (т.е. да осъществявате контрол) 12 пъти годишно. Практикувате тримесечна отчетност — управлявате 4 пъти годишно. И допълнителен бонус — годишна отчетност. Още веднъж да се завъртите.
През останалото време управлението обикновено се извършва сляпо.
Когато (и ако) цифрите все пак се появят, то в действие влиза вторият проблем — как да се управлява на база цифри? С този пункт от разсъжденията му не можах да се съглася.
Момчето твърдеше, че ако ръководителят преди не е имал цифри, то появата им ще предизвика ефекта вау. Той ще гледа и ще манипулира цифрите по всякакъв начин, ще извиква хора, ще изисква обяснения и разследвания. След като поиграе с цифрите, проведе анализи и сериозно обещае на всички служители, че „сега наистина няма да се откажа от вас“, ръководителят много бързо ще се успокои и ще остави това занимание. Инструментът ще остане ненужен. А проблемите ще останат.
Това се случва, казваше той, заради недостатъчни компетенции на ръководителя. В контрола, преди всичко. Ръководителят просто не знае какво да прави с тези цифри. Какво сда прави — знае, какво да прави — не. Правенето — това е ежедневният бизнес процес.
Той твърдеше, че всичко е много просто: цифрата трябва да стане част от бизнес процеса. В бизнес процеса трябва ясно да е указано: кой, какво и кога трябва да прави при отклонение на цифрата от нормата (всякакви варианти — над границата, под границата, излизане от коридора, наличие на тренд, неизпълнение на квантил и т.н.)
И ето, той посочи ключовата дилема: цифрата съществува, тя трябва да стане част от бизнес системата, за да повиши ефективността на управлението, но… това не се случва. Защо?
Защото руският ръководител не би дал на конкурента част от своето влияние.
Конкурентите на руския ръководител — качественият и работещ бизнес процес, добре обмислената взаимноизгодна мотивация и правилната автоматизация — за съжаление, ще оставят ръководителя без работа.
Глупости, согласете ли се? Особено за ръководителите. Добре, разказах, вие сами решавайте.
Малко по-малко, но все пак прекалено много, според мен, той говореше за скрам.
Обязательно, каза, прочетете и опитайте на практика скрам. Ако, казва, сте чели, но не сте пробвали — смятайте, че не знаете. По-добре е да прочетете книга, например на Сазерленд, отколкото статии и всякакви там наръчници (какво за бога?) в интернет.
Скрам, каза той, се познава само чрез практика, и с задължителни измервания на обемите извършена работа. Лично пробвайте двете най-важни роли — собственик на продукта и скрам-мастър.
Особено важно е, според момчето, да усетите на практика ролята на скрам-мастъра, когато можете да увеличите обема на задачите, завършени за спринта, без да увеличавате ресурсите и цената на спринта.
И още в неговия топ беше ТОС (теория на ограниченията на системите).
Това, според момчето, е основните, фундаментални принципи за повишаване на ефективността, които могат да се приложат практически във всяка област, във всеки бизнес процес и бизнес система като цяло.
Когато той разбра, че не сме запознати с ТОС, спря да разказва. Само добави, че няма да ни лиши от удоволствието да прочетем книгите на Елияху Голдрат. Препоръката беше подобна на скрам — прочетете и опитайте. Типа, независимо на коя позиция сте, каква работа извършвате, там ще намерите място за повишаване на ефективността чрез методите на ТОС.
После явно неговият багаж от методики се изчерпа и той каза: смесвайте принципите, за създаване на приложими решения в конкретна ситуация.
Това, казва, е главната препоръка, ключът към успеха. Разберете принципите, същността, и създавайте уникални приложими решения — бизнес процеси и бизнес системи.
След това той се опитваше да си спомни някаква цитата, в крайна сметка трябваше да потърси в интернет. Оказа се, че цитатът е от статията "Стоя на раменете на гиганти" на Елияху Голдрат:
«Има разлика между приложимите решения (приложения) и фундаменталните концепции, на които се основават тези решения. Концепциите са общи, приложимите решения — адаптация на концепциите към конкретната среда. Както вече видяхме, подобна адаптация не е проста и изисква разработването на определени елементи на решението. Трябва да помним — приложимото решение е основано на първоначалните предпоставки (понякога — скрити) за конкретната среда. Не трябва да очакваме, че това приложимо решение ще работи в среда, за която първоначалните предпоставки не са верни».
Каза, че работата на програмиста и „подобрителя на бизнес процеси“ — много си приличат. И си тръгна.
Източник: habr.com
