Системное подчинение

Не знаю, как вы, а я наблюдаю за проектами изменений лет 10. Кроме наших любимых ИТ-проектов (которые ведь тоже — изменения), много приходилось и видеть, и делать самому обычных, организационных изменений.

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

Но еще важнее другой, побочный итог — мы убедились, что методика_такая-то — фуфло. Потому что не работает.

Так часто бывает, например, с внедрением принципов agile, или конкретно методики скрам. Так будет и с методикой #Ускорение4X, если действовать с той же ключевой ошибкой — главной ошибкой внедрения изменений в нашей стране.

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

Неподчинение

Итак, вот она, ошибка: системное неподчинение.

И сразу принцип, о котором публикация: системное подчинение.

Обратите внимание — не систематическое, а системное. Систематическое — это вроде периодического, т.е. регулярно возникающего.

Системное неподчинение — это неподчинение, как система, как часть мировоззрения, как одна из ценностей, как повод гордиться собой.

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

Причем, фильмы-то, в основном, не наши, а страсть к неподчинению наиболее сильна, наоборот — в нас. Об этом, кстати, есть очень хорошая книга — «Русская модель управления» Прохорова (не того, который ё-мобиль делал).

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

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

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

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

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

Недостающий элемент

Возьмем простой пример, наглядный почти для всех — правила дорожного движения. Например, правило про пересечение стоп-линии на запрещающий сигнал светофора.

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

Кто помнит, в какой степени это правило выполнялось лет 10 назад? Я помню — ни в какой, или в никакой, не знаю, как правильнее сказать.

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

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

Результат есть? Конечно, это видно невооруженным взглядом — заторов на перекрестках стало меньше.

Что изменилось? Ответ вы знаете — на перекрестках появились камеры, которые автоматически фиксируют пересечение стоп-линии, определяется номер и выписывается штраф.

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

Но главное — в том, что обеспечив подчинение, человек доказал действенность методики.

Рассмотрите сами, если хотите, в той же последовательности внедрение эвакуаторов. Да, сразу скажу, я не сторонник и не противник этих правил, мне они интересны, как проекты изменений.
 

Методика — фуфло

Сколько еще правил и методик, которые, по задумке, должны приносить какой-то результат, а на деле приносят ничего? Вы без труда перечислите пару десятков. И причина почти всегда одна и та же — неподчинение.

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

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

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

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

А про теорию ограничений что пишут? Про критическую цепь? Про контроллинг? Про self-management? Про boundary management? Продолжать можно до бесконечности, но смысл один — «методика не рабочая, сырая, не подходит для наших особых условий, это только для стартапов, это не научный подход, бла-бла-бла».

Как формируется такое мнение — «методика — фуфло»? Рассмотрим обобщенный пример того, как это происходит в бизнесе.

Вот придумал руководитель изменение. В худшем, но самом простом случае — лишь объявил подчиненным или коллегам — все, теперь вы работаете по такой-то методике. Это может быть скрам, ТОС, Lean, Канбан, Standard Work и т.д… Вот вам ссылка, там написано, что надо делать, жду результатов.

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

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

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

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

А руководитель побежал к выходу черного ящика, и стал ждать результатов. Ждет, ждет, и вот показалась та же голова — вот, говорит, результат.

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

И отправляется писать отчет и делать презентацию о том, как он организовал проект изменений по методике agile, с применением концепции fail fast, fail cheap, результатом которой стал однозначный вывод об ущербности методики_такой-то для предприятий_такого-то_профиля.

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

Да еще статью напиши в журнал про методику_такую-то! — добавляет генерал — чтоб все знали, что нельзя ее применять на предприятиях_такого-то_профиля!

А в черном ящике голова думает, как снова смыть с задницы следы тонера — бумагой для офисной техники формата А4, 80 г/кв.м., белизна 146 %, с 5-процентным заполнением, не так-то легко подтираться.

Вот мнение и сформировалось — «методика — фуфло», и оно будет тиражироваться — как минимум, внутри компании. А если у того парня дойдут руки, то и статья выйдет, может даже на Инфостарте — очередная плаксиво-агрессивная история о том, что методика_такая-то — фуфло.

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

Примеров подхода "методика_такая-то — фуфло" — масса. Они отличаются двумя характерными свойствами:

1. Вывод про то, что методика — фуфло;
2. Неподчинение на элементарном уровне.
 

Примеры

Вот несколько из моей практики, кратенько.

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

Стали в цехе применять элементарные методы SPC (статистическое управление процессами). Рабочему написали в тех.карте — измеряй каждую десятую деталь. Толковые люди написали — знали, что времени у рабочего — вагон, а измерения сведут брак от фактического процента к вероятному. Но рабочий не измеряет. Ни один рабочий не измеряет. Потому что ни один рабочий не измеряет ). Результат — брак, до 100 % деталей. В итоге решили: «SPC — это для японцев, у нас станки старые, мы уж как-нибудь так… И бракованные детали ведь крутятся».

В отделе закупок очень известные внедренцы теории ограничений Голдратта внедряли новый бизнес-процесс, по методу «барабан-буфер-канат». Все было автоматизировано, оставалось одно узкое место — решение о количестве заказываемых деталей принимал менеджер. И он принял — покупал 100 штук, когда по методике требовалось 20. Очень известные внедренцы спрашивали — чего ж ты, гадина такая, 100 покупаешь? Я же не дурак — отвечал менеджер — завтра они клиентам понадобятся, а у меня нету. В итоге решили: «Теория ограничений не подходит для нашего предприятия_такого-то_профиля, мы будем составлять план закупок на год».

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

Возвращаемся к #Ускорению4X

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

Это — две крайности, в которые нам нельзя залезать. Сделать суррогат из методики #Ускорение4X — сложнее, чем из скрама, например, потому что ожидаемый результат заложен в названии.

Но сделать «методика — фуфло» — раз плюнуть. Такой результат вообще легко достигается — можно даже публикацию не дочитывать, а сразу минус поставить. Если у вас ровно такой настрой, то за #Ускорение4X лучше не браться вообще.

А если настрой правильный, то вот вам радостная новость — мы, авторы #Ускорения4X, собаку съели на разборе черных ящиков, и контролю исполнения методики уделяем самое пристальное внимание. Везде, где только можно, мы будем рассказывать о способах контроля — прямых, косвенных, количественных, альтернативных, и т.д. Потому что мы много — очень много раз видели, как сильно влияет неподчинение на проекты изменений. И знаем, что причина провала почти всегда одна и та же.

Единственное узкое место внедрения #Ускорения4X — это вы, дорогой читатель. В том случае, если вы — тот самый, кто пойдет внедрять наши подходы в свою команду. Потому что вас проконтролировать сможете только вы сами, и главной проблемой станет не подчинение, а самоподчинение.
 

Самоподчинение

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

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

Если вам повезло, и внедрять #Ускорение4X вас просто кто-то заставил — отлично, выводите проект в суррогат, или в «методика — фуфло». Мы даже помочь в этом можем — напишем публикацию-проходилку, которая подскажет правильные точки приложения усилий для увода проекта в песок. И не только #Ускорения4X — любого.

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

О том, как контролировать себя, мы тоже будем писать. Расскажем об инструментах и приемах, которые применяли мы сами. Постараемся поддержать, если сможем.

Но главный, все-таки, вы. Если будет успех, то причиной будете вы. Если будет провал, то причиной будете вы.