Про одного парня (или универсальные управленческие практики)

История реальная, я все видел своими глазами (автор статьи nmivan).

Парень - гений-управленец (ВладимирХ)

Несколько лет один парень, как и многие из вас, работал программистом. На всякий случай напишу так: «программистом». Потому что он был 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 раза в год. Плюс бонус — годовая отчетность. Еще разок порулить.

Остальное время управление, как правило, выполняется вслепую.

Когда (и если) цифры все-таки появляются, то вступает в действие вторая проблема — как управлять на основе цифр? Вот с этим пунктом его рассуждений я так и не смог согласиться.

Парень утверждал, что если цифр у руководителя раньше не было, то их появление вызовет вау-эффект. Он будет смотреть и крутить цифры и так и эдак, вызывать людей на ковер, требовать объяснений и расследований. Поигравшись с цифрами, проведя разборы, грозно пообещав всем сотрудникам, что «уж теперь-то я с вас не слезу», руководитель очень быстро успокоится и бросит это дело. Инструментом пользоваться перестанет. А проблемы останутся на месте.

Так происходит, говорил он, из-за недостаточных компетенций руководителя. В контроллинге, в первую очередь. Руководитель просто не знает, что делать с этими цифрами. Что сделать — знает, что делать — нет. Сделать — это то, о чем написано выше (поругаться, поиграться). Делать — это ежедневный бизнес-процесс.

Он утверждал, что все очень просто: цифра должна стать частью бизнес-процесса. В бизнес-процессе должно быть четко понятно: кто, что, и когда должен делать при отклонении цифры от нормы (любые варианты — выше границы, ниже границы, выход за коридор, наличие тренда, невыполнение квантиля и т.д.)

И вот он обозначил ключевую дилемму: цифра есть, она должна стать частью бизнес-системы, чтобы повысить эффективность управления, но… этого не происходит. Почему?

Потому что российский руководитель не отдаст конкуренту кусок своей власти.

Конкуренты российского руководителя — качественный и работающий бизнес-процесс, продуманная взаимовыгодная мотивация и правильная автоматизация — увы, оставят руководителя без работы.

Чушь какая-то, согласитесь? Особенно, про руководителей. Ладно, я рассказал, вы сами решайте.

Чуть меньше, но все равно слишком много, на мой взгляд, он говорил про скрам.

Обязательно, говорил, прочитайте и попробуйте на практике скрам. Если, говорит, читали, но не пробовали — считайте, что не знаете. Читать лучше книгу, например Сазерленда, а не статьи и всякие там гайды (что за хрень?) в интернете.

Скрам, говорил он, познается только практикой, и с обязательными измерениями объемов выполненной работы. Лично попробуйте две важнейшие роли — владельца продукта и скрам-мастера.

Особенно важно, по словам парня, прочувствовать на практике роль скрам-мастера, когда вы сможете увеличить объем закрываемых за спринт задач, не увеличивая ресурсы и стоимость спринта.

Ну и еще в его топе был ТОС (теория ограничений систем).

Это, по словам парня, базовые, фундаментальные принципы повышения эффективности, которые можно применить практически в любой области, в любом бизнес-процессе и бизнес-системе в целом.

Когда он узнал, что мы не знакомы с ТОС, то перестал рассказывать. Лишь добавил, что не будет лишать нас удовольствия от прочтения книг Элияху Голдратта. Рекомендацию дал аналогичную скраму — прочитайте и попробуйте. Типа, на какой бы должности вы не находились, какую бы работу не выполняли, там найдется место для повышения эффективности методами ТОС.

Потом у него багаж методик, видимо, иссяк, и он сказал: миксуйте принципы, для создания прикладных решений в конкретной ситуации.

Это, говорит, главная рекомендация, ключ к успеху. Поймите принципы, суть, и создавайте уникальные прикладные решения — бизнес-процессы и бизнес-системы.

Потом он силился вспомнить какую-то цитату, в итоге пришлось лезть в интернет. Оказалось, цитата из статьи «Стоя на плечах гигантов» Элияху Голдратта:

«Есть разница между прикладными решениями (применениями) и фундаментальными концепциями, на которых основаны эти решения. Концепции являются общими, прикладные решения — это адаптация концепций к конкретной среде. Как мы уже видели, подобная адаптация не является простой и делает необходимой разработку определенных элементов решения. Мы должны помнить — прикладное решение основано на исходных посылках (иногда — скрытых) о конкретной среде. Не надо ожидать, что это прикладное решение будет работать в среде, для которой исходные посылки не верны».

Сказал, что работа программиста и «улучшителя бизнес-процессов» — очень похожи. И ушел.