Историята е истинска, видях всичко с очите си.
В продължение на няколко години един човек, като много от вас, работи като програмист. За всеки случай ще го напиша така: „програмист“. Защото той беше 1Snik, на фикс, продуцентска компания.
Преди това пробва различни специалности - 4 години във Франция като програмист, ръководител на проекти, успя да изкара 200 часа, като в същото време получава процент от проекта, за управление и малко продажби. Опитах се да разработвам продукти сам, бях ръководител на ИТ отдела в голяма компания с 6 хиляди души, опитах различни възможности за използване на моята цитирана професия - 1C програмист.
Но всички тези позиции бяха донякъде задънени, предимно по отношение на доходите. Тогава всички получавахме приблизително еднакви пари и работехме при еднакви условия.
Този човек се чудеше как може да спечели повече пари, без да продава или създава собствен бизнес.
Той се смята за умен човек и решава да намери ниша в компанията, в която работи. Тази ниша трябваше да е нещо специално, да не е заета от никого. И исках самата компания да иска да плати пари на човек в тази ниша, така че да няма нужда да заблуждавате никого или да мамите нещо. За целта: човек на тази позиция трябва да получи много пари. Ексцентрик с една дума.
Търсенето продължи кратко. В компанията, в която работеше този човек, имаше напълно свободна ниша, която можеше да се нарече „подреждане на нещата в бизнес процесите“. Всяка компания има много проблеми. Винаги нещо не работи и няма човек, който да дойде и да оправи бизнес процеса. Така че той реши да се опита като специалист, който може да помогне на собственика да реши проблемите си в бизнес процесите.
По това време той работи в компанията от шест месеца и получава средната заплата на пазара. Нямаше какво да губи, особено след като лесно можеше да си намери същата работа в рамките на една седмица. Като цяло този човек реши, че нищо лошо няма да се случи, ако изведнъж нищо не се получи и той беше уволнен.
Той събра смелост и дойде при собственика. Предложих му да подобри най-проблемния процес в бизнеса. Тогава беше складово счетоводство. Сега всички, които работят в тази компания, дори се срамуват да си спомнят за тези проблеми, но инвентаризациите, които се извършваха на тримесечие, показаха несъответствия между счетоводната система и реалните салда от десетки проценти. И като цена, и като количество, и като брой позиции. Беше катастрофа. Фирмата действително е имала коректни салда в счетоводната система само четири пъти в годината - в деня след инвентаризацията. Нашият човек започна да подрежда този процес.
Човекът се съгласи със собственика, че трябва да намали наполовина отклоненията от резултатите от инвентаризацията. Освен това собственикът нямаше какво специално да губи, защото преди нашия герой различни работници вече бяха направили опити да поправят всичко и като цяло задачата се смяташе за практически неразрешима. Всичко това силно подхранва интереса, защото ако всичко се получи, тогава пичът автоматично ще стане човек, който знае как да подреди нещата и да реши неразрешими проблеми.
И така, той беше изправен пред задачата: да намали отклоненията въз основа на резултатите от инвентаризацията 2 пъти в рамките на една година. В началото на проекта той нямаше идея как да постигне това, но разбираше, че складовото счетоводство е просто нещо, така че все пак ще може да направи нещо полезно. Освен това намаляването на отклоненията от десетки процента до една десетка процента не изглежда толкова трудно. Всеки, който е работил в консултантски или подобни дейности, разбира, че повечето проблеми в процеса могат да бъдат разрешени с доста прости стъпки.
От януари до май той подготви, автоматизира нещо малко, пренаписа бизнес процеса на складово счетоводство, промени работните потоци на складодържателите, счетоводителите и като цяло преработи цялата система, без да показва или казва нищо на никого. През май той раздаде нови инструкции на всички и след първата инвентаризация за годината започна нов живот - работа по неговите правила. За да наблюдава резултатите, в бъдеще компанията започна да прави инвентаризации по-често - веднъж на два месеца. Още първите резултати бяха положителни, а до края на годината отклоненията от резултатите от одита спаднаха до част от един процент.
Успехът беше колосален, но човек не можеше да повярва в неговата устойчивост. Самият човек се съмняваше, че резултатът ще се запази, ако се отдръпне и спре да наблюдава процеса. Въпреки това имаше резултат и човекът получи всичко, за което се договори със собственика. След това, след няколко години, беше потвърдена стабилността на резултата - в продължение на няколко години отклоненията останаха в рамките на 1%.
Тогава той решил да повтори експеримента и предложил на собственика да подобри друг проблемен процес – снабдяването. Имаше недостиг, който не ни позволи да изпратим обемите, които нашите клиенти искаха. Разбрахме се, че в рамките на една година дефицитите ще бъдат намалени наполовина, а човекът също ще завърши 10-15 проекта, свързани с 1C - за автоматизиране на различни бизнес процеси и други ереси.
През втората година отново всичко приключи успешно, дефицитите намаляха над 2 пъти, всички ИТ проекти приключиха успешно.
Тъй като заплатата вече напълно задоволяваше всички нужди на този човек за две години напред, той реши да се установи малко, да се успокои и да седне на уютно, топло място, което създаде за себе си.
Как беше? Формално той беше IT директор. Но кой всъщност беше той, е трудно да се разбере. В крайна сметка какво прави един ИТ директор? Като правило той администрира ИТ инфраструктурата, управлява системните администратори, внедрява ERP система и участва в заседанията на борда на директорите.
И този пич имаше една от ключовите отговорности да участва в процесите на промяна и главно - генериране, иницииране на тези процеси, търсене и предлагане на решения, прилагане на нови техники за управление, изследване на предложените промени, анализ на ефективността на други функции и подразделения и накрая пряко участие в стратегическото развитие на предприятието, до самостоятелното разработване на стратегически план за цялата компания.
Даден му е картбланш. Той можеше да дойде на всяка среща, където преди това не е имал достъп. Седях там с бележник, записвах нещо или просто слушах. Рядко говореше. След това започна да си играе по телефона, твърдейки, че асоциативната памет работи по-добре по този начин.
На срещата той рядко раздаваше нещо полезно. Тръгна си, помисли, после пристигна писмо – или с критика, или с мнение, или с предложения, или с описание на решенията, които вече е приложил.
Но по-често сам свикваше събранията. Намерих проблем, предложих решения, идентифицирах заинтересованите страни и доведох всички на срещата. И тогава - както можеше. Той убеждаваше, мотивираше, доказваше, аргументираше, постигаше.
Неофициално той се смяташе за третия човек във фирмата след собственика и директора. Разбира се, той ужасно вбеси всички „лица от компанията“, като се започне от номер 4. Най-вече със скъсаните си дънки и ярки тениски, а също и с времето си като собственик.
Собственикът му отделяше по 1 час на ден. Всеки ден. Разговаряха, обсъждаха проблеми, решения, нови бизнеси, области на развитие, показатели и ефективност, личностно развитие, книги и просто живот.
Но този човек беше странен. Това е като, седнете и бъдете щастливи, животът е хубав. Но не. Реши да помисли.
Той се чудеше: защо на него му се получи, а на други не? Собственикът също го притисна: той каза, че иска и други да могат да възстановят реда, защото има много мениджъри, те, като правило, се занимават с оперативно управление и стратегическо планиране, но практически никой не се занимава със системни промени в техните процеси. В длъжностната им характеристика може да пише, че трябва да ускорят процеса си и да повишат ефективността му, но всъщност никой не го прави. Защо така? Човекът също се заинтересува защо и отиде да говори с всички тези мениджъри.
Той дойде при заместник-директора по качеството и предложи въвеждането на контролни карти на Shewhart, така че продуктите да бъдат по-добри от японските. Но се оказа, че колегата не знае какво представляват контролните карти на Шухарт, какво е статистически контрол на процеса и само е чувал за използването на цикъла на Деминг в управлението на качеството. ДОБРЕ…
Отиде при друг зам.-директор и предложи да се въведе контролинг. Но и тук не намерих подкрепа. Малко по-късно той научи за управлението на границите (управление на границите) и предложи на всички заместник-директори да внедрят системната част от тази методология, за да подобрят процесите. Но колкото и да говореше нашият човек, никой не искаше да се задълбочи за какво става въпрос. Може би не са се интересували или е било твърде трудно. Но всъщност никой не го разбра.
Общо взето разказа всичко, което знае и използва във фирмата. Но никой не го разбра. Те все още не разбират защо, например, всичко е коригирано в складовата отчетност и какво общо имат контролът и управлението на границите с това.
Накрая стигна до програмистите си - персоналът включваше 3 души. Говореше за boundary management, за контролинг, за управление на качеството, за agile и scrum... И изненадващо те разбраха всичко и дори успяха по някакъв начин да обсъдят с него, включително технически и методологически тънкости. Те разбраха защо проектите за склад и доставка се получиха. И тогава на човека му просветна: всъщност програмистите ще спасят света.
Програмистите, осъзна той, са единствените, които могат да разберат бизнес процесите нормално, с необходимите подробности.
Защо те? Всъщност той така и не намери ясен отговор. Формулирах само теза намеци.
Първо, програмистите познават предметните области на бизнеса и ги познават по-добре от всички останали хора в компанията.
Освен това програмистите наистина разбират какво е алгоритъм на процеса. Това е важно, защото бизнес процесите са алгоритми и елементите в тях може просто да не са последователни. Например, в процеса на снабдяване, върху който момчето работеше, първата стъпка беше създаването на годишен план за покупки, а втората беше ежедневните покупки. Тези стъпки са свързани с директна връзка, т.е. предполага се, че хората трябва да работят по този алгоритъм - изготвяне на годишен план за обществени поръчки и незабавно изпълнение на заявката. Годишният план за обществени поръчки се съставя веднъж годишно, а заявките се приемат 50 пъти на ден. Това е мястото, където алгоритъмът свършва и трябва да работите върху него. Всъщност, разсъждава той, за програмистите познаването на алгоритмите е конкурентно предимство, защото всеки друг, който не е запознат с тях, просто не разбира как трябва да работи един бизнес процес и как може да бъде представен.
Друго предимство на програмистите, според момчето, е, че имат достатъчно свободно време. Всички разбираме как един програмист може да отдели три пъти повече време за задача, отколкото всъщност изисква, и малцина ще забележат. Това отново е конкурентно предимство, защото за да подредите някакъв бизнес процес, трябва да имате много свободно време - мислете, наблюдавайте, изучавайте и опитвайте.
Повечето мениджъри, според момчето, нямат това свободно време и се гордеят с това. Въпреки че всъщност това означава, че човек не може да стане ефективен, защото няма време да подобри ефективността - порочен кръг. В нашата култура е модерно да си зает, така че всичко си остава същото. А за нас програмистите това е предимство. Можем да намерим свободно време и да помислим за всичко.
Програмистите, каза той, могат бързо да променят една информационна система. Това не е приложимо във всички предприятия, но където и да е работил, е можел да прави каквито пожелае модификации. Особено ако не се отнасят до чужда работа. Например, той би могъл да стартира система, която тайно да измерва действията на потребителите и след това да използва тази информация, за да анализира ефективността на същия счетоводен отдел и да проследи разходите за счетоводство.
И последното, което си спомням от думите му е, че програмистите имат достъп до голямо количество информация, защото... имат административен достъп до системата. Следователно те могат да използват тази информация в своя анализ. Никой друг в обикновен завод няма такъв ресурс.
И тогава си тръгна. По време на необходимото двуседмично задържане го принудихме да сподели опита си, защото искахме да продължим работата, която вършеше. Е, мястото му се оваканти.
В продължение на няколко дни го сядат на стол, пускат камерата и записват монолозите му. Те поискаха да ни разкажат за всички изпълнени проекти, методи, подходи, успехи и неуспехи, причини и следствия, портрети на мениджъри и др. Нямаше специални ограничения, т.к Те не знаеха какво става в главата му.
Монолозите, разбира се, бяха предимно глупости и смях - той беше в страхотно настроение, т.к. напускаше пустошта за Санкт Петербург. Къде трябва да отидете на работа в Санкт Петербург? На Газпром, разбира се.
Но успяхме да извлечем нещо полезно от неговите монолози. Ще ти кажа какво си спомням.
И така, препоръките на този човек. За тези, които искат да се опитат да подредят нещата в бизнес процесите.
За да извършвате този вид работа, първо, трябва да имате определено ниво на „измръзване“. Не трябва да се страхувате да не загубите работата си, да не се страхувате да поемате рискове, да не се страхувате от конфликти с колеги. За него беше лесно, защото той започна своя път, когато беше работил в компанията само шест месеца и нямаше време да влезе в контакт с никого и не възнамеряваше да го прави. Разбираше, че хората идват и си отиват, но за него са важни неговите собствени резултати и оценката им от собственика на бизнеса. Дали колегите му се отнасяха добре или зле към него, тогава не го интересуваше.
Вторият момент е, че за да вършите ефективно тази работа, за съжаление, ще трябва да учите. Но учете не за MBA, не в курсове, не в институти, а сами. Например, в първия си проект, проект за склад, той действаше интуитивно, не знаеше нищо, какво точно е „управление на качеството“.
Когато започнал да чете литературата за съществуващите методи за повишаване на ефективността, той открил технологиите, които използвал. Човекът ги е приложил интуитивно, но се оказва, че това не е негово изобретение, всичко е написано отдавна. Но той отдели време и много повече, отколкото ако веднага беше прочел правилната книга. Тук е важно само да разберете, че когато изучавате конкретна техника, нито една от тях, дори и най-модерната, няма да реши напълно всички проблеми на бизнес процеса.
Вторият трик е, че колкото повече техники знаете, толкова по-добре. Например в древна Япония е живял Миямото Мусаши, един от най-известните фехтовачи, автор на стила с два меча. Учи в някакво училище при някакъв майстор, след това пътува из Япония, бие се с различни пичове. Ако човекът беше по-силен, тогава пътуването спря за известно време и Мусаши стана ученик. В резултат на това в продължение на няколко години той придобива умения от различни практики на различни майстори и създава своя собствена школа, добавяйки нещо свое. В резултат на това той постигна уникално умение. Тук е същото.
Можете, разбира се, да действате като бизнес консултанти. Като цяло са страхотни момчета. Но като правило идват да въведат някаква методология и внедряват грешната методология, от която има нужда бизнесът. Имахме и такива тъжни ситуации: никой не знае как да реши проблема и никой не иска да мисли как да го реши. Започваме да търсим или в интернет, или се обаждаме на консултант и го питаме какво може да ни помогне. Консултантът мисли и казва, че трябва да въведем теорията на ограниченията. Плащаме му за препоръката, харчим пари за изпълнение, но резултатите са нулеви.
Защо това се случва? Защото консултантът каза, въвеждаме такава и такава система и всички се съгласиха с него. Страхотно, но една методология не покрива всички проблеми дори на един бизнес процес, особено ако първоначалните предпоставки - нашите и тези, необходими за прилагане на методологията, не съвпадат.
В практиката, която човекът препоръчва, трябва да вземете най-доброто и да приложите най-доброто. Не приемайте методите изцяло, но вземете техните ключови характеристики, характеристики и практики. И най-важното е да разберете същността.
Вземете, каза той, например Scrum или Agile. В монолозите си човекът многократно повтаря, че не всеки разбира напълно същността на Scrum. Той също така прочете книгата на Джеф Съдърланд, която някои хора намират за "леко четиво". Изглеждаше му като задълбочено четене, защото един от основните принципи на Scrum е управлението на качеството, това е написано директно в книгата.
В него се казва за Toyota Production, за това как Джеф Съдърланд показа Scrum в Япония, как се вкорени там и колко близо беше до тяхната философия. И Съдърланд говори за важността на ролята на Scrum Master, за цикъла на Деминг. Ролята на Scrum Master е постоянно да ускорява процеса. Всичко останало, което е в Scrum – поетапна доставка, удовлетвореност на клиентите, ясен списък с работа за периода на спринта – също е важно, но всичко това трябва да се движи все по-бързо. Скоростта на работа трябва непрекъснато да нараства в единиците, в които се измерва.
Може би това е въпрос на превод, защото нашата книга беше преведена като „Scrum - революционен метод за управление на проекти“, а ако заглавието на английски се преведе буквално, ще се окаже: „Scrum - два пъти повече за половината време“ , тоест дори в Името се отнася до скоростта като ключова функция на Scrum.
Когато този човек внедри Scrum, скоростта се удвои през първия месец без значителни промени. Той намери точки за промяна и модифицира самия Scrum, за да работи много по-бързо. Единственото, което пишат в интернет, е, че са били изправени пред въпроса: „Удвоихме скоростта, остава само да разберем какво правим с такава скорост?“ Това обаче е съвсем друга област...
Той също така лично препоръча няколко техники. Той ги нарече основни и основни.
Първият е управлението на границите.
Учат го в Сколково, според човека няма други книги и материали. Някак си имаше късмета да присъства на лекция на професор от Харвард, който проповядва управление на границите, а също така прочете няколко статии в Harvard Business Review за работата на Ерик Трист.
Управлението на границите казва, че трябва да можете да виждате границите и да работите с тях. Границите са много, те са навсякъде – между отделите, между различните видове работа, между функциите, между оперативната и аналитичната работа. Познанието за управлението на границите не разкрива никакви по-висши истини, но ни позволява да видим реалността в малко по-различна светлина – през призмата на границите. И съответно ги управлявайте - издигайте ги където е необходимо и ги премахвайте там където пречат.
Но най-често човекът говореше за контрол. Той просто имаше някаква странност по тази тема.
Контролингът накратко е управление, базирано на числа. Тук, каза той, всяка част от дефиницията е важна - и „управление“, и „на база“, и „числа“.
Ние, каза той, сме зле и с трите компонента на контрола. Особено като се има предвид, че те са тясно свързани както помежду си, така и с други части на бизнес системата.
Първото нещо, което е лошо, са числата. Малко са и са с ниско качество.
След това взехме значителна част от числата от информационната система 1C. Така че качеството на номерата в 1C, както той твърди, не е добро. Най-малкото поради възможността за промяна на данните със задна дата.
Ясно е, че това не е по вина на разработчиците на 1C - те вземат предвид само изискванията на пазара и манталитета на вътрешното счетоводство. Но за целите на контрола е по-добре да промените принципите на 1C работа с данни в конкретно предприятие.
Освен това числата от 1C, според него, се подлагат на полуръчна обработка, използвайки например Excel. Такава обработка също не добавя качество към данните, както и ефективност.
В крайна сметка някой друг проверява окончателния отчет, за да не изпрати случайно цифри с грешки на мениджъра. В резултат на това номерата достигат до получателя красиви, проверени, но много късно. Обикновено - след края на периода (месец, седмица и т.н.).
И тук, каза той, всичко е много просто. Ако числата за януари са ви дошли през февруари, тогава вече не можете да управлявате дейностите през януари. Защото януари вече свърши.
И ако цифрите са счетоводни, а фирмата е най-обикновена, с тримесечно подаване на ДДС, тогава нейният ръководител получава относително адекватни цифри веднъж на тримесечие.
Останалото е ясно. Получавате номера веднъж месечно - имате възможност да управлявате по числа (т.е. контрол) 12 пъти в годината. Ако практикувате тримесечно отчитане, управлявате го 4 пъти годишно. Плюс бонус - годишно отчитане. Направете още веднъж.
През останалото време контролът обикновено се извършва на сляпо.
Когато (и ако) числата се появят, тогава се появява вторият проблем - как да се управлява въз основа на числата? Не мога да се съглася с тази точка от разсъжденията му.
Човекът твърди, че ако мениджърът не е имал числата преди, тогава появата им ще предизвика уау ефект. Ще гледа и ще върти номера насам-натам, ще вика хора на тепиха, ще иска обяснения и разследвания. След като играе с числа, извършва анализ и заплашително обещава на всички служители, че „сега няма да се отърва от вас“, мениджърът много бързо ще се успокои и ще се откаже от този въпрос. Спрете да използвате инструмента. Но проблемите ще си останат.
Това се случва, каза той, поради недостатъчни управленски компетенции. В контрола, на първо място. Мениджърът просто не знае какво да прави с тези числа. Какво сда прави - знае какво да прави - не. Да се прави това, за което е писано по-горе (да се карат, да играят). Правенето е ежедневен бизнес процес.
Той твърди, че всичко е много просто: цифровото трябва да стане част от бизнес процеса. В бизнес процеса трябва да е ясно ясно: кой какво и кога трябва да направи, ако числата се отклоняват от нормата (всякакви опции - над границата, под границата, излизане отвъд коридора, наличие на тенденция, неспазване на квантил и др.)
И така очерта ключовата дилема: номерът съществува, трябва да стане част от бизнес системата, за да се повиши ефективността на управлението, но... това не се случва. Защо?
Защото руският лидер няма да отстъпи част от властта си на конкурент.
Конкурентите на руския мениджър - висококачествен и работещ бизнес процес, добре обмислена взаимноизгодна мотивация и правилна автоматизация - уви, ще оставят мениджъра без работа.
Някакви глупости, не сте ли съгласни? Особено за лидерите. Добре, казах ти, решаваш сам.
Малко по-малко, но все пак твърде много, според мен, той говори за Scrum.
Бъдете сигурни, казах, прочетете и опитайте Scrum на практика. Ако, казва той, сте го чели, но не сте го опитали, считайте се за невежа. По-добре е да прочетете книга, например от Съдърланд, отколкото статии и всякакви ръководства (какво, по дяволите?) в интернет.
Scrum, каза той, може да се научи само чрез практика и със задължителни измервания на количеството извършена работа. Лично опитайте двете най-важни роли – Product Owner и Scrum Master.
Особено важно е, според човека, да изпитате на практика ролята на Scrum Master, когато можете да увеличите обема на задачите, изпълнени на спринт, без да увеличавате ресурсите и цената на спринта.
Е, в горната му част имаше TOS (теория на системните ограничения).
Това, според човека, са основните, фундаментални принципи за повишаване на ефективността, които могат да бъдат приложени в почти всяка област, във всеки бизнес процес и бизнес система като цяло.
Когато разбра, че не сме запознати с TOS, спря да ни казва. Той само добави, че няма да ни лиши от удоволствието да четем книгите на Елияху Голдрат. Той даде подобна препоръка на Scrum - прочетете го и опитайте. Например, без значение на каква позиция сте, без значение каква работа вършите, има място за повишаване на ефективността с помощта на методите на TOC.
Тогава торбата му с техники явно пресъхна и той каза: смесете принципите, за да създадете приложни решения в конкретна ситуация.
Това според него е основната препоръка, ключът към успеха. Разберете принципите, същността и създайте уникални приложни решения - бизнес процеси и бизнес системи.
След това се опита да си спомни някакъв цитат и накрая трябваше да влезе в интернет. Оказа се цитат от статията „Стоене на раменете на гиганти“ от Елияху Голдрат:
„Има разлика между приложните решения (приложения) и фундаменталните концепции, на които се основават тези решения. Концепциите са общи; приложните решения са адаптиране на концепции към конкретна среда. Както вече видяхме, такава адаптация не е проста и изисква разработването на определени елементи от решението. Трябва да помним, че едно приложно решение се основава на първоначални предположения (понякога скрити) за конкретна среда. Не трябва да се очаква това решение за приложение да работи в среда, за която предположенията не са правилни.“
Той каза, че работата на програмист и „подобрител на бизнес процеси“ са много сходни. И тръгна.
Източник: www.habr.com