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