Управление изменениями: ADKAR vs Коттер — как впихнуть новое в старые мозги

Почему большинство изменений в ИТ проваливаются

Мы, ИТ-директора, любим технологии и процессы. Можем часами спорить о микросервисной архитектуре или CI/CD инструментах.

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

Реальный кейс: В 2020 году я внедрял 1С в компании, где половина сотрудников работала удалённо. Технически всё было идеально: настроены права, интеграции, автоматизированы процессы. Но через полгода они продолжали пользоваться самописным складским учётом и собирать отчёты в богомерзком экселе.

Бухгалтерия дублировала данные “на всякий случай” на бумаге. Менеджеры не заполняли карточки товаров. Руководители игнорировали встроенные отчёты, предпочитая сводные таблицы в экселе, куда данные вносились вручную.

И это на 2000 SKU! Какая тут оперативность, когда половина времени уходит на сверку таблиц?

👨‍🎓 ADKAR: когда нужно менять конкретных людей

ADKAR — это не название нового стартапа, а аббревиатура от пяти этапов, через которые должен пройти каждый человек:

1. Awareness (Осознание) — “Почему мы вообще должны что-то менять?”
2. Desire (Желание) — “Окей, и что мне с этого будет?”
3. Knowledge (Знание) — “Как именно я должен работать по-новому?”
4. Ability (Способность) — “У меня получается, я могу это делать!”
5. Reinforcement (Закрепление) — “Теперь я делаю это на автомате и не хочу возвращаться к старом

🤔 Когда использовать ADKAR

• Внедряете новые инструменты (CRM, ERP, тикеты)
• Меняете конкретные рабочие процессы в отдельных отделах
• Обучаете новым навыкам
• Изменение влияет в первую очередь на отдельных сотрудников

💻 Пример из жизни: Как я заставил всех полюбить Битрикс24

В 2021 году мне пришлось совершить подвиг — перевести компанию с обожаемого всеми Trello на корпоративный Битрикс24. Технически это было несложно. Но я знал, что главная битва будет с людьми и их “так-мы-всегда-делали” синдромом.

1️⃣ Awareness (Осознание)

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

Что сработало: Конкретные примеры из их опыта. “Помните тот релиз, когда вы три дня искали, кто должен был сделать интеграцию с платежкой? А потом оказалось, что карточка просто затерялась между колонками? Вот это всё блядство мы починим!”
Что было бы эпик-фейлом: Абстрактные обещания типа “новая система будет эффективнее”. Людям нужно ткнуть носом в их боль.

2️⃣ Desire (Желание)

Я использовал древнюю технику “что здесь для меня?”. Для руководителей — аналитика и отчёты. Для проджект-менеджеров — автоматизация и интеграции. Для разработчиков — возможность не отвлекаться от кода на заполнение отчётов.

Что сработало: Индивидуальный подход к каждой группе. Я нашёл то, что заставит глаза загореться у каждого.
Что было бы катастрофой: Директивы сверху типа “с понедельника все работаем в Битриксе, потому что я так сказал”. Сотрудники — настоящие ниндзя пассивной агрессии и саботажа.

3️⃣ Knowledge (Знание)

Мы создали серию микро-туториалов (по 2-3 минуты максимум) с кликбейтными названиями типа “Как поставить задачу за 10 секунд” и “Как получить ответ по продажам за одну минуту”.

Что сработало: Короткие и простые обучалки под конкретные сценарии. Никаких двухчасовых тренингов, после которых все ненавидят тебя, твою систему и тот день, когда ты пришёл в компанию.
Что было бы провалом: Одинаковое обучение для всех со скучной докой на 100 страниц.

4️⃣ Ability (Способность)

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

Что сработало: Поддержка от своих воспринималась лучше, чем от ИТ-отдела. Людям проще спросить у коллеги, чем признаться айтишнику, что они не могут найти кнопку “создать задачу”.
Что было бы фиаско: Бросить людей в новую систему со словами “там интуитивный интерфейс, разберётесь”.

5️⃣ Reinforcement (Закрепление)

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

Что сработало: Признание и поощрение тех, кто принял изменение. Люди любят, когда их хвалят при всех — используйте это беспощадно.
Что было бы ошибкой: Считать, что после внедрения работа закончена. Без постоянного подкрепления люди вернутся к старым привычкам быстрее, чем вы скажете “agile”.

🏆 Результат

Через три месяца 99% сотрудников активно использовали Битрикс (оставшийся 1% — это те, кто до сих пор отправляет задачи по факсу, им уже не помочь).

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

🏢 Модель Коттера: когда нужно изменить всю организацию

Модель Джона Коттера — это 8 шагов для масштабных организационных изменений:

1. Создание ощущения срочности — “Если не изменимся, всем пизда”
2. Формирование влиятельной команды реформаторов — “Собираем Мстителей”
3. Создание видения — “Вот так будет выглядеть наш светлый завтрашний день”
4. Пропаганда видения — “Повторяем о светлом завтра, пока всех не затошнит”
5. Устранение препятствий — “Убираем всё, что мешает двигаться к светлому завтра”
6. Планирование и достижение быстрых побед — “Смотрите, уже работает!”
7. Закрепление достигнутых успехов — “Теперь давайте сделаем ещё круче”
8. Институционализация изменений — “Теперь это просто наш новый нормальный день”

🤔 Когда использовать модель Коттера

• Масштабные организационные трансформации (Agile, DevOps)
• Изменение корпоративной культуры
• Слияния и поглощения
• Радикальное изменение бизнес-модели
• Когда требуется преодолеть значительное сопротивление

💻 Пример из жизни: Переход на Agile

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

1️⃣ Создание ощущения срочности

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

Сработало: Сравнение с конкурентами мотивировало собственников. Для рядовых сотрудников эффективнее оказались примеры конкретных проблем, с которыми они сталкивались ежедневно.
Не сработало: Абстрактные разговоры о “современных подходах” и “лучших практиках”.

2️⃣ Формирование влиятельной команды реформаторов

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

Работает: Включение неформальных лидеров, у которых не было официальной власти, но было огромное влияние на коллектив изнутри.
Не сработало: Команда исключительно из руководителей. Без участия рядовых сотрудников изменения воспринимались как “ещё одна инициатива начальства”.

3️⃣ Создание видения

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

Сработало: Конкретные примеры того, как изменится повседневная работа каждого сотрудника. “Вместо того чтобы ждать неделю, пока кто-то доберётся до твоей задачи, вы будете получать обратную связь в течение дня”.
Не сработало: Слишком абстрактное видение без конкретики. Фразы типа “мы станем более гибкими” никого не мотивируют.

4️⃣ Пропаганда видения

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

Сработало: Последовательность и повторение. Люди начинают воспринимать изменения серьезно, только когда слышат о них постоянно.
Не сработало: Одноразовые анонсы. Коллеги быстро забывают то, что не затрагивает их ежедневно.

5️⃣ Устранение препятствий

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

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

6️⃣ Планирование и достижение быстрых побед

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

Сработало: Конкретный, измеримый результат, который можно было продемонстрировать скептикам.
Не сработало: Слишком амбициозные первые проекты с высоким риском провала. Люди обожают неудачи – если бы ты облажался, старожилы вспоминали бы это ещё лет пять.

7️⃣ Закрепление достигнутых успехов

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

Сработало: Постепенное расширение, а не попытка изменить всё одним махом.
Не сработало: Остановка после первых успехов. Многие компании совершают ошибку, полагая, что после успешного примера остальные подтянутся сами.

8️⃣ Институционализация изменений

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

Сработало: Делать новичков сразу “правильными”. Это гарантировало, что новая культура будет поддерживаться даже при смене персонала.
Не сработало: Расчет только на энтузиазм команды без изменения фундаментальных процессов.

🏆 Результат

Через пару лет трансформация была завершена. Время вывода новых фич сократилось вдвое. Количество инцидентов в продакшене уменьшилось на 90%, а удовлетворенность сотрудников я не измерял, но вскоре уже никто и не помнил, что когда-то работали иначе.

ADKAR vs Коттер: когда что использовать и как их комбинировать

🤷‍♂️ Как понять, что выбрать?

Вот тебе простой тест:

1. Если ты можешь описать изменение одним предложением без использования модных словечек — скорее всего, подойдет ADKAR.
   • “Мы переходим с Excel на CRM” — ADKAR
   • “Мы трансформируем нашу организационную культуру для повышения адаптивности в условиях VUCA-мира” — Коттер (и, возможно, психотерапевт)
2. Если изменение затрагивает меньше 30% сотрудников — ADKAR. Если больше — доставай Коттера и готовься к долгой войне.
3. Если можно внедрить изменение, не трогая организационную структуру — ADKAR. Если придется менять оргструктуру, должностные инструкции и систему оценки — Коттер.

И самый важный тест:

• если ты можешь внедрить изменение и при этом не стать главным врагом народа — используй ADKAR.
• Если готов временно побыть “тем самым директором, который всё сломал” — Коттер твой выбор.

🚀 С чего начать управление изменениями

1. Оцени текущую ситуацию

Прежде чем выбирать методологию, ответь на несколько вопросов:

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

2. Выбери подходящую методологию

На основе твоей оценки выбери ADKAR, модель Коттера или их комбинацию:

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

3. Начни с пилотного проекта

Выбери небольшой, но важный проект для первого применения:

• Это должно быть реальное изменение, а не учебное упражнение
• Проект должен быть достаточно важным, чтобы привлечь внимание
• Но не настолько критичным, чтобы неудача была катастрофой

4. Создай команду управления изменениями

Даже если ты ИТ-директор, ты не сможешь управлять изменениями в одиночку:

• Включи представителей затрагиваемых групп
• Обучи команду выбранной методологии
• Чётко распредели роли и ответственности

5. Разработай план коммуникаций

Коммуникация — ключевой элемент любого изменения:

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

6. Подготовь инструменты и шаблоны

Чтобы не изобретать велосипед каждый раз, создай набор инструментов:

• Шаблоны для оценки воздействия изменений
• Чек-листы для каждого этапа
• Формы для сбора обратной связи
• Метрики для оценки прогресса

7. Начни с малого, но думай о большом

Начни с пилотного проекта, но имей план масштабирования:

• Документируй уроки, извлечённые из пилота
• Адаптируй подход на основе обратной связи
• Постепенно расширяй применение методологии на другие проекты
• Обучай больше людей принципам управления изменениями

💩 Типичные ошибки при управлении изменениями

За 10 лет в роли ИТ-директора я собрал все возможные грабли. Вот топ-10 самых распространенных ошибок и способы их избежать:

1. Фокус на технологии, а не на людях

Ошибка: Считать, что если технология хороша, люди сами начнут её использовать.

Решение: Помни, что любое технологическое изменение — это в первую очередь изменение человеческого поведения. Уделяй не менее 50% усилий работе с людьми.

2. Недооценка сопротивления

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

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

3. Отсутствие чёткого “WIIFM” (What’s In It For Me)

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

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

4. Слишком быстрый темп

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

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

5. Недостаточная коммуникация

Ошибка: Объявить об изменении один раз и ожидать, что все поняли и запомнили.

Решение: Коммуницируй постоянно, через разные каналы и в разных форматах. Повторяй ключевые сообщения минимум 7 раз.

6. Игнорирование “молчаливого большинства”

Ошибка: Работать только с активными сторонниками и противниками, забывая о “молчаливом большинстве”.

Решение: Активно вовлекай тех, кто обычно молчит. Часто именно от них зависит успех изменений, а не от громких единиц.

7. Отсутствие празднования успехов

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

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

8. Недостаточное обучение

Ошибка: Считать, что люди сами разберутся, как работать по-новому.

Решение: Инвестируй в качественное обучение. Используй разные форматы для разных стилей обучения.

9. Отсутствие метрик успеха

Ошибка: Не определять заранее, как ты будешь измерять успех изменений.

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

10. Преждевременное завершение

Ошибка: Считать, что изменение завершено после внедрения технологии или процесса.

Решение: Планируй долгосрочную поддержку и закрепление изменений. Настоящий успех — это когда новый подход становится “просто способом, которым мы работаем”.

🔮 Что дальше?

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

Вот что я рекомендую сделать прямо сейчас:

1. Выбери один небольшой блок изменений, который ты можешь начать в ближайшие две недели
2. Примени принципы ADKAR к этому проекту
3. Документируй всё, что работает и не работает
4. Через месяц проанализируй результаты и скорректируй подход

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

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

Удачи в твоих трансформациях! И да, когда всё получится — не забудь это отпраздновать. Ты заслужишь.

P.S. Если эта статья помогла тебе избежать хотя бы одной ошибки при внедрении изменений — моя миссия выполнена. А если ты всё равно наступил на все описанные грабли — добро пожаловать в клуб! Здесь всегда найдётся место для ещё одного боевого ИТ-директора со шрамами от изменений.