Главная » Хабрахабр » Про одного парня

Про одного парня

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

На всякий случай напишу так: «программистом». Несколько лет один парень, как и многие из вас, работал программистом. Потому что он был 1Сником, на фиксе, производственной компании.

Пробовал самостоятельно разрабатывать продукты, был начальником IT-отдела в большой компании, численностью 6 тысяч человек, примерял разные варианты применения своей кавычечной профессии – программиста 1С. До этого он пробовал разные специальности – 4 года во франче программистом, руководителем проектов, умел закрывать по 200 часов, одновременно получая процент с проекта, за руководство и немного занимаясь продажами.

Все мы тогда получали примерно одни и те же деньги, работали в одних и тех же условиях. Но все это позиции были несколько тупиковые, в первую очередь по доходу.

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

Ниша эта должна была быть какой-нибудь особенной, никем не занятой. Он возомнил себя умником, и решил найти нишу в той компании, где работал. Чтобы это было объективно: человеку на этой позиции надо платить много денег. И хотелось, чтобы компания сама захотела платить деньги человеку в этой нише, чтобы не надо было никого обманывать или что-то накручивать. Чудак, одним словом.

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

Терять было нечего — тем более, что такую же работу он вполне мог найти в течение одной недели. На тот момент он работал в компании полгода, и получал среднюю зарплату по рынку. В общем, этот парень рассудил, что ничего страшного не произойдет, если вдруг ни фига не получится и его уволят.

Предложил ему улучшить самый проблемный процесс, который был в бизнесе. Он набрался смелости и пришел к собственнику. Сейчас всем, кто работает в этой компании, даже стыдно вспоминать о тех проблемах, но инвентаризации, которые проводились ежеквартально, показывали расхождения между учетной системой и фактическими остатками в десятки процентов. На тот момент это был складской учет. Это была беда. И по стоимости, и по количеству, и по количеству позиций. Этот процесс наш парень и стал приводить в порядок. Компания реально имела правильные остатки в учетной системе только четыре раза в год – на следующий день после инвентаризации.

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

В момент начала проекта он не представлял, как этого добиться, но понимал, что складской учет – это вещь простая, поэтому все равно удастся что-нибудь полезное сделать. Итак, перед ним стояла задача: в течение года снизить отклонения по результатам инвентаризации в 2 раза. Все, кто работал в сфере консультирования или подобной деятельности, понимают, что большинство проблем процесса устраняются достаточно простыми действиями. Тем более, что снизить отклонения с десятков процентов до одного десятка процентов – это, вроде, не так сложно.

В мае он раздал всем новые инструкции, и после первой в году инвентаризации началась новая жизнь – работа по его правилам. С января по май он готовился, немного чего-то автоматизировал, переписал бизнес-процесс складского учета, поменял потоки работы кладовщиков, бухгалтеров и вообще всю систему переделал, никому ничего не показывая и не рассказывая. Уже первые результаты были положительными, а до конца года отклонения по результатам ревизии упали до долей одного процента. Чтобы наблюдать результат, в дальнейшем компания стала проводить инвентаризации чаще – раз в два месяца.

Сам парень сомневался, что результат сохранится, если отойти в сторону и перестать наблюдать за процессом. Успех был колоссальный, но в его устойчивость не верилось. Потом, по прошествии нескольких лет, устойчивость результата подтвердилась — несколько лет отклонения держатся в пределах 1 %. Тем не менее, результат был, и парень получил все, о чем договаривался с собственником.

Там были дефициты, не позволявшие отгружать такие объемы, которые хотели наши клиенты. Тогда он решил повторить эксперимент и предложил собственнику усовершенствовать другой проблемный процесс – снабжение. Договорились, что за год дефициты снизятся вдвое, а чувак еще выполнит 10-15 проектов, связанных с 1С, — по автоматизации разных бизнес-процессов и прочей ереси.

Во второй год опять все успешно удалось завершить, дефициты снизились более, чем в 2 раза, все IT-проекты были завершены успешно.

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

Формально, он был IT-директором. Что оно собой представляло? Ведь чем занимается IT-директор? Но кем он был на самом деле был, понять сложно. Как правило, он администрирует IT-инфраструктуру, руководит сис.админами, внедряет ERP-систему, участвует в совещаниях на совете директоров.

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

Он мог приходить на любое совещание, куда раньше доступа не имел. Ему дали карт-бланш. Говорил редко. Сидел там с блокнотом, чего-то записывал, или просто слушал. Потом принялся играть в телефоне — утверждал, что так лучше работать ассоциативная память.

Уходил, думал, потом прилетало письмо — или с критикой, или с мнением, или с предложениями, или с описанием решений, которые он уже применил. На совещании редко что-то полезное выдавал.

Находил проблему, придумывал варианты решения, определял заинтересованных лиц и тащил всех в переговорку. Но чаще собирал совещания сам. Убеждал, мотивировал, доказывал, спорил, добивался. А там уж — как умел.

Разумеется, он жутко бесил всех «лиц компании», начиная с номера 4. Неофициально он считался третьим лицом в компании, после собственника и директора. Особенно своими рваными джинсами и яркими футболками, а еще — временем собственника.

Каждый день. Собственник уделял ему 1 час в день. Они разговаривали, обсуждали проблемы, решения, новые бизнесы, направления развития, показатели и эффективность, личное развитие, книги, да и просто — жизнь.

Вроде — сиди и радуйся, жизнь удалась. Но парень этот был странный. Он решил порефлексировать. Но нет.

Собственник тоже подталкивал его: говорил, что хочет, чтобы у других тоже получалось наводить порядок, потому что менеджеров много, они, как правило, занимаются оперативным управлением и стратегическим планированием, но практически никто не занимается системными изменениями своих процессов. Ему стало интересно: почему вот у него получилось, а у других — нет? Почему так? В их должностную инструкцию, может, и записано, что они должны ускорять свой процесс, повышать его эффективность, но по факту этим никто не занимается. Вот парню тоже стало интересно, почему, и он пошел со всеми этими менеджерами разговаривать.

Но оказалось, что коллега не знает, что такое контрольные карты Шухарта, что такое статистическое управление процессами, и только краем уха слышал про применение цикла Деминга в управлении качеством. Он пришел к заместителю директора по качеству, и предложил внедрить контрольные карты Шухарта, чтобы у продукция было лучше японской. Ладно…

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

Но никто его так и не понял. В общем, он рассказал обо всём, что знал и применял в компании. Им и до сих пор непонятно, почему, например, все удалось исправить в складском учете, причем тут контроллинг и управление границами.

Рассказал про управление границами, про контроллинг, про менеджмент качества, про agile и scrum… И на удивление они все поняли, и даже могли с ним как-то обсудить, в том числе — технические и методические тонкости. В последнюю очередь он дошел до своих программистов – в штат входило 3 человека. И тут парня осенило: на самом деле мир спасут программисты. Они поняли, почему проекты по складу и по снабжению получились.

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

На самом деле однозначного ответа он так и не нашел. Почему именно они? Сформулировал только тезисные намеки.

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

Это важно потому, что бизнес-процессы – это алгоритмы, и элементы в них могут быть банально не согласованы. Кроме того, программисты реально понимают, что такое алгоритм процесса. Эти шаги соединены прямой связью, то есть предполагается, что по этому алгоритму люди должны работать – составлять годовой план закупок и тут же исполнять заявку. Например, в процессе по снабжению, над которым парень работал, первый шаг – это составление годового плана закупок, а второй – ежедневная закупка. На этом алгоритм заканчивается, и по нему надо работать. Годовой план закупок составляется раз в год, а заявка поступает по 50 раз на день. На самом деле, рассудил он, для программистов знание алгоритмов – это конкурентное преимущество, потому что любой другой человек, не знакомый с ними, просто не понимает, как бизнес-процесс должен работать, и как это можно изобразить.

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

Хотя фактически это означает, что человек не может стать эффективным, потому что у него нет времени на повышение эффективности — замкнутый круг. Большинство менеджеров, по словам парня, этого свободного времени не имеют и гордятся этим. А для нас, программистов, это преимущество. В нашей культуре модно быть занятым, поэтому все остается на месте. Мы можем найти свободное время и обо всем подумать.

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

наделены административным доступом к системе. И последнее, что я запомнил с его слов – программисты имеют доступ к большому количеству информации, т.к. Никто другой на обычном заводе таким ресурсом не обладает. Поэтому могут пользоваться этой информацией в своем анализе.

Во время положенной двухнедельной отработки мы заставили его поделиться опытом, потому что хотели продолжать дело, которым он занимался. А потом он ушел. Ну и должность его становилась вакантной.

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

отбывал из захолустья в Питер. В монологах, конечно, в основном была всякая чушь и ржака — он пребывал в прекрасном расположении духа, т.к. В Газпром, конечно. А куда ехать работать в Питере?

Расскажу, что помню. Но кое-что полезное нам удалось вытащить из его монологов.

Тем, кто захочет попробовать заняться наведением порядка в бизнес-процессах. Итак, рекомендации того парня.

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

Но учиться не на MBA, не на курсах, не в институтах, а самостоятельно. Второй момент – чтобы эффективно заниматься этой работой, к сожалению, придется учиться. Например, в первом своем проекте, по складу, он действовал интуитивно, ничего не знал, только что такое «управление качеством».

Парень интуитивно их применял, а оказывается, это не его выдумка, все уже было давно написано. Когда он начал читать литературу, какие методы повышения эффективности существуют, то обнаружил те технологии, которые применял. Здесь только важно понимать, что когда изучаешь конкретную методику, ни одна из них, даже самая продвинутая, полностью не решит все проблемы бизнес-процесса. Но он потратил время, и намного больше, чем если бы сразу прочитал нужную книгу.

Например, в древней Японии жил Миямото Мусаси – один из самых известных фехтовальщиков, автор стиля двух мечей. Вторая фишка в том, что чем больше методик вы знаете, тем лучше. Если чувак был сильнее, то путешествие на какое-то время прекращалось, и Мусаси шел в ученики. Он учился в какой-то школе у какого-то мастера, потом путешествовал по Японии, сражался с разными чуваками. В итоге у него получилось уникальное мастерство. В результате он за несколько лет приобретал навыки различных практик разных мастеров и сформировал свою собственную школу, добавляя что-то свое. Здесь то же самое.

Вообще, они отличные ребята. Можно, конечно, действовать как бизнес-консультанты. У нас тоже были такие грустные ситуации: никто не знает, как решить проблему и никто не хочет думать, как ее решить. Но, как правило, приходят, чтобы внедрить какую-то методику, и внедряют не ту методику, которая нужна бизнесу. Консультант думает и говорит, что надо теорию ограничений внедрить. Начинаем искать либо в интернете, либо звать консультанта, и спрашиваем у него, что нам может помочь. Платим ему за рекомендацию, тратимся на внедрение, но результата ноль.

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

Не брать методы целиком, а брать их ключевые особенности, фишки, практики. В практике, которую парень рекомендует, надо брать лучшее и внедрять лучшее. И самое важное – надо понимать суть.

В монологах парень много раз повторил, что не все до конца понимают суть скрама. Возьмем, говорил он, к примеру, скрам (scrum) или эджайл. Ему она показалась глубоким чтивом, потому что одна из основополагающих основ скрама – это управление качеством, об этом в книге написано прямо. Он тоже читал книгу Джеффа Сазерленда, которая некоторым кажется «легким чтивом».

И Сазерленд рассказывал про важность роли скрам-мастера, про цикл Деминга. Там написано про Toyota Production, про то, как Джефф Сазерленд показывал скрам в Японии, насколько он там прижился и было близок их философии. Все остальное, что есть в скраме, – поэтапная сдача, удовлетворение заказчика, четкий перечень работ на период спринта — тоже важно, но это все должно двигаться все быстрее и быстрее. Роль скрам-мастера – это постоянное ускорение процесса. Скорость работы должна все время возрастать в тех единицах, в которых она измеряется.

Возможно, здесь дело в переводе, потому что у нас книгу перевели как «Скрам – революционный метод управления проектами», а если дословно английское название переводить, то получится: «Скрам – в два раза больше за вдвое меньший срок», то есть даже в названии идет отсылка к скорости, как ключевой функции скрама.

Он нашел точки для изменений, модифицировал сам скрам под себя, чтобы он работал намного быстрее. Когда этот парень внедрял скрам, за первый месяц скорость увеличилась вдвое без каких-то особых изменений. Впрочем, это уже совсем другая область… Единственное, как в интернете пишут, — перед ними встал вопрос: «Мы увеличили скорость вдвое, осталось понять, что же мы делаем с такой скоростью?».

Назвал их фундаментальными и основополагающими. Еще он лично рекомендовал несколько методик.

Первая — boundary management (управление границами).

Ему как-то посчастливилось присутствовать на лекции профессора из Гарварда, который проповедует boundary management, а также прочитать несколько статей в Harvard Business Review про работы Эрика Триста. Преподают его в «Сколково», других книг и материалов, по утверждениям парня, нет.

Границ полно, они повсюду — между отделами, между разными видами работ, между функциями, между оперативной и аналитической работой. Boundary management говорит о том, что надо уметь видеть границы и работать с границами. И, соответственно, управлять ими — возводить там, где это необходимо, и убирать там, где они мешают. Знание boundary management не открывает каких-то высших истин, но позволяет видеть реальность в несколько ином свете — через призму границ.

Прям бзик какой-то у него был на эту тему. Но больше и чаще всего парень говорил про контроллинг.

Здесь, говорил он, важна каждая часть определения — и «управление», и «на основе», и «цифр». Контроллинг, если кратко — это управление на основе цифр.

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

Их мало и они низкого качества. Первое, что плохо — цифры.

Так вот, качество цифр в 1С, как он утверждал, никуда не годится. Значительную часть цифр мы тогда брали из информационной системы 1С. Как минимум, из-за возможности изменять данные задним числом.

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

Качества данным, равно как и оперативности, такая обработка тоже не добавляет. Дальше цифры из 1С, по его словам, проходят полуручную обработку, с использованием Excel, например.

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

Если цифры о январе вам попали в феврале, то деятельностью января вы уже управлять не можете. И тут, говорил он, все очень просто. Потому что январь уже закончился.

А если цифры основаны на бух.учете, и компания — самая обычная, с поквартальной сдачей НДС, то относительно адекватные цифры ее руководитель получает раз в квартал.

Получаете цифры раз в месяц — у вас есть возможность управлять по цифрам (т.е. Дальше понятно. Практикуете квартальную отчетность — управляете 4 раза в год. осуществлять контроллинг) 12 раз в год. Еще разок порулить. Плюс бонус — годовая отчетность.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Steal: кто крадёт у виртуалок процессорное время

Хочу рассказать простым языком о механике возникновения steal внутри виртуальных машин и о некоторых неочевидных артефактах, которые нам удалось выяснить при его исследовании, в которое мне пришлось погрузиться как техдиру облачной платформы Mail.ru Cloud Solutions. Привет! Платформа работает на KVM. ...

Почему бессмысленно писать прогнозы

Сейчас в различных СМИ да и на Хабре публикуется большое количество прогнозов о бурном развитии робототехники, беспилотных автомобилей и альтернативной энергетики. Люди зачастую настроены излишне оптимистично, и ожидают какого-то рывка. Я предлагаю посмотреть, что прогнозировали на Хабре, и каким видели ...