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

Дальше перед каждым стоит выбор: продолжать максимально улучшать свой островок стабильности или пытаться продвинуть изменения в компании. Как можно понять, рассмотрим второй вариант. Усложним задачу: возьмем типичный ФГУП или завод (где разрабатывается что‑то физическое, не код и услуги), где слова «изменения» и «реформирование» не любят.

Скажем сразу: вся история — «мысленный» эксперимент. Любые совпадения с реальностью случайны, даже если так и не кажется. Порой даже самый абстрактный «мысленный» эксперимент очень похож на реальность.

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

Давайте сразу обусловился: слова Lean, Agile, стейкхолдеры, ROI, KPI, Kanban и другие «чудесные» слова мы ставим под запрет, и не только потому, что с 1 марта нельзя использовать англицизмы. Термины — это супер, и в IT‑компаниях их знает каждый второй сотрудник, но мы в разработке железа, тут много тех, кто при этих словах если не пошлет, уже будет чудом. Так же, чтобы избежать осуждений, сразу скажем сразу, я не эксперт в всем этом, скорее человек который в начале своего пути и пытается систематизировать имеющиеся знания. Тем более в менеджменте много течений и каждый считает, что только его система самая лучшая. Я в этом уже очень сильно убедился, что для одних что‑то считается основой, для других считается полным бредом, в связи со спецификой, отсутствием навыков и знаний, да и многим другим. Поэтому если вы с чем‑то не согласны, не гневайтесь (хотя мы в интернете, хейт тут вечно моден).

Этап первый: Оценка изменений

Первое, о чем я бы задумался: насколько полезно моё изменение? Это тот вопрос, от которого процентов на 50 зависит успех затеи. Интуитивное ощущение «так работать неудобно» — это не основание для изменений, а лишь повод разобраться. Необходимо проанализировать текущий процесс, выделить ключевые метрики, сравнить их с планируемыми нововведениями и оценить предстоящие затраты и риски.

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

Продавец будет смотреть на то, насколько стало удобнее и быстрее работать, так как именно он будет ежедневно работать с этим нововведением. Старший по смене скорее подумает о сбоях и пограничных ситуациях: что делать, если система падает и сколько головной боли у него из‑за этого будет. Охранника изменения вообще никак не затронут, (разве что оценка нововведения на защиту от воров). Директор же будет смотреть на более высокий уровень — как это влияет на выручку, издержки и стабильность работы.

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

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

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

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

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

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

Этап второй: Изучение вопроса

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

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

Возвращаясь к внедрению изменений: я уже знал две системы, которые предлагают структурный подход, — это ADKAR и 8 шагов Коттера. Не буду подробно рассказывать про каждую, но в нашем случае я бы воспользовался ADKAR с вкраплениями 8 шагов Коттера. Почему? ADKAR не дает четкой последовательности действий, а Коттер, наоборот, предлагает слишком жесткую иерархию, которая в реальной жизни редко работает. Оговоримся сразу: у этих систем полно критиков. Говорят, что у них слабая доказательная база, что они слишком линейны, что ADKAR, например, чересчур зациклен на индивидуальном подходе. И это справедливые замечания. Именно поэтому на первом этапе я только наметил для себя шаги, а не воспринимал их как догму.

Тут возникает закономерный вопрос: а насколько такие системы вообще применимы в компаниях вроде нашей? Честно? Не знаю. Совсем. Редко кто пытается трансформировать всё, что связано с госструктурами и заводами, пользуясь структурированным подходом. А если и пытаются, то обычно разочаровываются и уходят. Исследования только подтверждают, что такие системы встречают колоссальное внутреннее сопротивление. Но при этом катастрофически мало информации про то, какие методы реально работают в наших условиях.

Этап третий: Проработка изменений

Итак, вооружившись книжками и всем чем только можно, надо начать прорабатывать изменения. Так как мы для нашего «эксперимента» выбрали самый странный способ внедрения изменений, а именно с самого низа, так еще и во ФГУПе/заводе, нам необходимо учитывать всё. Вооружившись системой, я бы начал с Awareness (Осведомленность) и отдаленно Desire (Желание) ADKAR или 1 шага Коттера. Необходимо проработать мотивацию (желание) для того, чтобы все поняли, что данное изменение необходимо, а также хорошо бы сразу прописать, как изменение затронет каждую из ролей процесса. Это крайне необходимо, особенно в системах, которые обладают повышенной инертностью, где одного «Да, хорошо бы ввести нововведение» не хватает, чтобы начать меняться, и необходимо создавать условия для этого. Можно было бы сказать, что это должны делать другие люди, но, как говорится, начальство любит лишь готовые решения и не очень любит работать.

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

Тут тоже может быть много возражений: что это за изменения, на которые надо всех мотивировать? Если сами не замотивировались от одной только идеи, значит, меняться не надо. Думаю, многие уже поняли, что если даже внутренне мы согласны с чем‑то, то далеко не факт, что мы это будем делать, в угоду, например, уже сформированным привычкам. Как раз именно для этого мы и прописываем мотивацию, чтобы снизить внутреннее сопротивление человека (лень). Это, кстати, пятый шаг Коттера, который при изменениях снизу лучше продумать заранее, иначе потом это будет выглядеть так, будто ты пытаешься навязать это и на ходу придумываешь плюсы своего изменения.

Этап четвертый: Сбор команды

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

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

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

Единственное, что я еще бы использовал, — это то, что команда должна подчиняться правилу 7 плюс‑минус 2 или правилу двух пицц (там вариаций этого куча, но суть везде одна). Иначе работа внутри команды будет, скорее всего, парализована. Хотя в отличном коллективе это не помеха, жаль только, что никто в таком не работал, кроме комментаторов в интернете.

Этап пятый: MVP

Как и любое изменение, необходимо создать MVP (Minimum Viable Product, «минимально жизнеспособный продукт»), мы это приурочим к 6 шагу Коттера (Быстрые победы) или к Ability (Способность) из ADKAR. Я бы уделил этому тоже особое внимание.

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

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

Этап шестой: Внедрение

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

Вот тут всё зависит от того, насколько сильно мы попали с мотивацией, как хорошо смогли донести свое видение до нашего «посредника» и, самое главное, сняли ли головную боль со среднего звена, кто должен будет внедрять его. Кому‑то наши изменения вообще неинтересны, особенно тем, кто далек от работы подчиненных и кому в целом не очень интересно, что там происходит. Главное — поменьше головной боли. А так как мы во ФГУПе или заводе, таких тут много.

Именно поэтому к этому моменту у нас должна быть инструкция для каждой роли нашего процесса (мы об этом говорили еще на первом этапе), тот самый Knowledge (Знания) из ADKAR. Да, они не всегда будут точными, потому что полной специфики работы мы можем не знать. Но мы должны сделать так, чтобы вопросов у исполнителей было как можно меньше, и они не бежали к начальству с вопросом «а что с этим делать?», по самым глупым вопросам. Иначе есть шанс, что времени на решение этих проблем не будет и нужно все срочно, то приведет к возврату к старым уже проверенным процессам

Ну вот и всё. Всё, что зависит от нас, мы сделали. Дальше наше влияние настолько ничтожно, что можно даже не пытаться что‑то делать. Наверное, тут в качестве упражнения можно предположить, что, если мы всё сделали правильно, есть шанс, что это начнут как минимум обсуждать. Но стоит помнить, как показывает, например исследование Harvard Business Review неудачей заканчивается 75–95% трансформаций, хотя стоит уточнить, что речь шла о цифровых трансформациях. А McKinsey & Company в давних свои исследованиях приводило число в 70% неудач при внедрении изменений. Так что в нашем эксперименте, мы ставим и идем внедрять следующие изменения.

Этап седьмой: Поддержка

Кстати, тоже недооценённый всеми этап, а готова ли ваша система выйти из строя, и кто это будет чинить или тот самый Reinforcement (Укрепление) из ADKAR. Потому что вы можете даже внедрить изменения, но если в итоге не будет поддержки, эффективность начнет падать и падать, и уже те заветные цифры в начале окажутся тем что обычно пишут на гаражах. Кажется, вроде не очень критично прям здесь и сейчас при внедрении, но это то, что сильно влияет на будущие нововведения. Все будут боятся, потому что видят во что превратилось «прорывное» изменение в прошлом.

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

Заключение

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

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

Небольшой список источников

• Производственный менеджмент: учебник / под ред. В.А. Козловского. – М.: ИНФРА-М, 2003. – 574с.

• Hiatt, J. M. (2006). ADKAR: a Model for Change in Business, Government and our Community: How to Implement Successful Change in our Personal Lives and Professional Careers. Prosci Research, Loveland, Colorado.

• An Introduction To Change Management. Prosci Research, Loveland, Colorado.

• Методы принятия решений Harvard Business Review

• The J-Curve of Change. David Viney (https://www.david-viney.me/post/the-j-curve-of-change)

• Change is changing: How to meet the challenge of radical reinvention (https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/change-is-changing-how-to-meet-the-challenge-of-radical-reinvention#/)

• 3 Stages of a Successful Digital Transformation by Didier Bonnet (https://hbr.org/2022/09/3-stages-of-a-successful-digital-transformation)

• Управление изменениями: ADKAR vs Коттер. Как впихнуть новое в старые мозги. (https://lyucean.com/change_management/)

• Как не навредить себе и коллегам, когда проводишь изменения в компании (https://habr.com/p/713896/)

• Пять пороков команд Патрик Ленсиони