Программирование и отладка бизнеса: стань самым ценным сотрудником

Как повысить свой доход в разы, занять другую должность в компании и стать самым ценным сотрудником?

Сначала - моя история

Несколько лет я, как и многие из вас, работал программистом 1С на фиксе в одной из компаний. До этого я пробовал разные специальности – 4 года во франче работал программистом, руководителем проектов,

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

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

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

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

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

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

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

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

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

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

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

Поскольку зарплата полностью удовлетворяла все мои запросы на 1-2 года, я решил немного остепениться, успокоиться и посидеть на уютном теплом месте, которое я себе создал. Что оно собой представляло? Формально я был IT-директором, но кем я на самом деле был, понять сложно. Ведь чем занимается IT-директор? Как правило, он администрирует IT-инфраструктуры, руководит сисадминами, внедряет ERP-систему, участвует в совещаниях на совете директоров. Одной из моих ключевых обязанностей участие в процессах изменений, и по большей части - генерация, инициирование этих процессов, поиск и предложение решений, применение новых методик управления, экспертиза предлагаемых изменений, анализ эффективности других функций и подразделений, и, наконец - непосредственное участие в стратегическом развитии предприятия, вплоть до самостоятельной разработки стратегического плана всей компании. Таким образом, реализовалась та самая концепция самого ценного сотрудника - я им стал..

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В практике, которую я рекомендую, надо брать лучшее и внедрять лучшее. Не брать методы целиком, а брать их ключевые особенности, фишки, практики. И самое важное – надо понимать суть. Возьмем, к примеру, скрам (scrum) или аджайл. Мне кажется, что не все их до конца понимают. Я тоже читал книгу Джеффа Сазерленда, которая некоторым кажется «легким чтивом». Мне она показалась глубоким чтивом, потому что одна из основополагающих основ скрама – это управление качеством, и про это там написано. Там написано про Toyota Production, про то, как Джефф Сазерленд показывал скрам в Японии, насколько он там прижился и было близок их философии. И Сазерленд рассказывал про важность роли скрам-мастера, про цикл Деминга. Роль скрам-мастера – это постоянное ускорение процесса. Все остальное, что есть в скраме, – поэтапная сдача, удовлетворение заказчика, четкий перечень работ на период спринта - тоже важно, но это все должно двигаться все быстрее и быстрее. Скорость работы должна все время возрастать в тех единицах, в которых она измеряется.

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

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

Методики решения бизнес-проблем

Я выбрал несколько методик, которые лично рекомендую.

1.      Баундри менеджмент (управление границами).

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

2.      Контроллинг (управление на основе цифр).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Контроллинг я особенно рекомендую, и особенно - программистам 1С. Это голубой океан повышения эффективности управления в России.

3.      Скрам

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

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

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

4.      ТОС (теория ограничений систем)

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

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

5.      Миксуйте принципы, для создания прикладных решений в конкретной ситуации

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

Вот что сказал на эту тему Элияху Голдратт в статье "Стоя на плечах гигантов":

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

Не правда ли, похоже на кастомизацию типового решения 1С под конкретное предприятие, т.е. под среду? А мы с вами не этим разве каждый день занимаемся?

Осталось лишь расширить свой пакет инструментов - влиять не только на информационную систему, но и на окружающую ее среду.

P.S.

Тема программирования и отладки бизнеса продолжается, обогащается новыми знаниями и практическим опытом.

Пока в виде блогов, но это только начало.

Автор и источник:

http://business-programming.blogspot.ru

http://biz-programming.livejournal.com/