ГЛАВА 16
Управление изменениями
70 % провалов цифровых трансформаций — не из-за технологии (BCG, 2024). Технология обычно работает. Не работают люди, которым предложено пользоваться этой технологией. И самое обидное в этом — что главная причина провала находится не в коде, не в архитектуре, не в выборе платформы. Она в том, что мастера на участке через 3 месяца после запуска в эксплуатацию MES (система оперативного управления производством) вернулись к Excel «как привыкли». Что мастера ОТК (отдел технического контроля) не доверяют машинному зрению и параллельно проверяют детали глазами. Что директор по производству не открывает дашборд BI (бизнес-аналитика), потому что «и так всё знаю».
Управление изменениями (управление изменениями) — это не «корпоративные тренинги». Это полтора-два года систематической работы с людьми, без которой даже идеально внедрённая технология остаётся неиспользуемой.
В этой главе — что такое управление изменениями в производственном контексте, четыре этапа на основе логики «осознать → понять → сделать → закрепить», карта заинтересованных сторон, преодоление сопротивления на пяти уровнях.
Главная статистика и почему её игнорируют
65-75 % цифровых трансформаций не достигают целей
*Источники: BCG 2024 (~35 % успеха), Gartner (55-75 % ERP-провалов), McKinsey*
Главная причина: «people dimension» — оргструктура, операционная модель, культура
Эта цифра в разных формулировках кочует из отчёта в отчёт уже более двадцати лет — её корни в исследовании McKinsey 2003 года и подтверждениях BCG/Gartner в последующих волнах. Её цитируют на каждой конференции. Её упоминают в каждой презентации интегратора. И при этом — она систематически игнорируется при планировании проектов. Бюджет на управление изменениями в типичном цифровом проекте составляет 2-5 % от общего бюджета. Это в 10 раз меньше, чем должно быть.
Причина: управление изменениями — это «невидимая» работа. Её результат не отображается в дашбордах через месяц. Её невозможно «купить коробкой». Она требует длительной работы людей, не покупки лицензий. Поэтому при урезании бюджета (а его всегда урезают) — управление изменениями режут первым.
В результате — проект сделан технически идеально, и не работает. Самое типовое наблюдение в моей практике: «у нас MES стоит уже год, всё работает, но мастера ведут Excel параллельно». Это — провал управления изменениями. Технология ни при чём.
Что такое управление изменениями в производственном контексте
Не корпоративный тренинг. Не «вебинар по новой системе». Это:
- Понимание людьми, зачем меняется их работа.
- Согласие с тем, что изменение — необходимо.
- Освоение новых инструментов и процессов.
- Закрепление нового поведения как нормы.
Это четыре отдельных этапа. Каждый требует своих действий, своих метрик, своих ресурсов. Перепрыгивать этапы — самая частая ошибка управления изменениями.
Это упрощённая версия ADKAR (Awareness, Desire, Knowledge, Ability, Reinforcement), без англоязычных аббревиатур и с поправкой на российский производственный контекст.
Этап 1. Осознание — «что-то меняется»
Что: люди должны узнать о предстоящем изменении заранее, не «обнаружить новую систему утром».
Когда: за 3-6 месяцев до запуска в эксплуатацию.
Как:
- Анонс CEO (генеральный директор)/CDTO (директор по цифровой трансформации) на общем собрании.
- Письма руководителей подразделений.
- Корпоративный портал/тг-канал.
- Вопросы-ответы с пользователями.
Метрика: % сотрудников целевой аудитории, знающих о проекте (опрос).
Типичная ошибка: «потом узнают, когда покажем». Узнают они от слухов, и слухи будут хуже реальности.
Этап 2. Понимание — «зачем и как мне это»
Что: люди должны понять, как изменение касается лично их. Не «вообще цифровая трансформация», а «как изменится моя смена, какие новые шаги, что я выиграю, что я потеряю».
Когда: за 2-4 месяца до запуска в эксплуатацию.
Как:
- Встречи с разными группами пользователей (мастера, операторы, диспетчеры) отдельно.
- Демонстрация системы в реальной работе.
- Ответы на возражения — лично, в формате «я понимаю ваше беспокойство, давайте разберём».
- Карта изменений: что было → что станет.
Метрика: % сотрудников целевой аудитории, согласных с тем, что изменение нужно (опрос).
Типичная ошибка: «продаём чудо». Сотрудники не верят в чудеса. Лучше продавать реальные изменения — «у вас исчезнут эти отчёты в Excel, появятся эти кнопки, время на смену сократится на 20 минут».
Этап 3. Освоение — «я умею пользоваться»
Что: люди должны технически освоить новые инструменты и процессы.
Когда: за 1-3 месяца до запуска в эксплуатацию, и в течение 3-6 месяцев после.
Как:
- Обучение, обязательно с практикой на тестовой системе.
- Сертификация (аттестация по знанию).
- Наставники из числа «первых пользователей» (внутренние чемпионы).
- Hyperсare-команда — 2-4 человека на цех в течение 3 месяцев после запуска в эксплуатацию, помогают «вживую».
- Регулярные сессии «как делать в системе вот это» — каждые 2-4 недели первые полгода.
Метрика: % аттестованных пользователей; среднее время выполнения типовой операции в новой системе vs старой.
Типичная ошибка: «одно обучение перед запуском в эксплуатацию, и всё». Через неделю забывают. Нужны повторные сессии и наставники в режиме «всегда рядом».
Этап 4. Закрепление — «это норма для меня»
Что: новое поведение становится нормой. Старое поведение (Excel параллельно, бумажные журналы) — исчезает.
Когда: 6-18 месяцев после запуска в эксплуатацию.
Как:
- KPI (ключевой показатель эффективности) на использование системы — для мастеров, начальников цехов, операторов.
- Премирование за активное использование, рейтинги «лучших пользователей».
- Регулярные ритуалы — например, ежедневная планёрка ведётся по дашборду из системы, не по бумажному отчёту.
- Постепенное «отрезание» альтернативных способов — например, мастер не может закрыть смену в Excel, потому что нет такого процесса в новом регламенте.
- Аудит уровня использования системы раз в квартал, выявление «зон сопротивления».
Метрика: уровень использования системы (% активных пользователей от целевой аудитории); частота использования ключевых функций; объём данных, проходящих через систему.
Типичная ошибка: «уже работает, обучение закончили». Закрепление — это самый длинный этап, 6-18 месяцев. Преждевременная остановка → уровень использования системы падает на 6-м месяце ниже 40 %.
Куратор от руководства — главная фигура
Куратор от руководства — это не «куратор проекта». Это личный носитель изменения. Без активного куратора цифровая трансформация не работает.
Кто это:
- CEO или член СД (для крупных программ).
- COO (операционный директор) или директор по производству (для проектов в производстве — MES, EAM (система управления активами)).
- CFO (для проектов в финансах — ERP (система планирования ресурсов предприятия), BI).
Что должен делать:
- Лично участвовать в УК проекта (раз в месяц).
- Лично объявлять о проекте на общем собрании.
- Лично разрешать политические эскалации.
- Лично использовать систему («идти впереди»). Если CEO смотрит дашборд BI, остальные подтянутся. Если CEO просит распечатать «как раньше» — система мертва.
Что НЕ должен делать:
- Делегировать роль куратора другому. «Я делегировал директору по производству» — это не куратор уровня СД (совет директоров).
- Появляться только когда «что-то горит». Регулярное участие — обязательно.
Карта заинтересованных сторон
Прежде чем планировать управление изменениями, надо понять — кто будет затронут и как они отнесутся.
По квадрантная стратегия:
- Союзники (высокое влияние + поддержка): использовать как агентов изменений. Просить выступать, рассказывать кейсы.
- «Работать активно» (высокое влияние + скептическое отношение): главный фокус управление изменениями. Без них проект не пройдёт.
- Информировать (низкое влияние + поддержка): держать в курсе через корпоративный канал.
- «Игнорировать» (низкое влияние + скептическое отношение): не тратить ресурс на них, само рассосётся.
Карта — не разовое упражнение. Перерисовывать раз в 3-6 месяцев: позиции людей меняются, скептики становятся союзниками или наоборот.
Преодоление сопротивления на разных уровнях
Сопротивление новой системе — это не «плохие люди». Это рациональная защита разных групп.
Уровень 1. СД и собственник — страх «потратим много, не получим эффект»
Источник: предыдущий опыт провалов цифровых проектов, своих или у знакомых.
Что делать:
- Бизнес-кейс на 1 странице с реалистичными цифрами (см. главу 15).
- Точки go/no-go — СД должен видеть, что проект можно остановить.
- Этапные результаты — не «всё через 3 года», а «после 6 месяцев — пилот с измеренным эффектом».
- Личное общение с собственниками компаний-референсов (где аналогичный проект сработал).
Уровень 2. Топ-менеджмент — страх перераспределения власти
Источник: цифровая трансформация делает прозрачными зоны ответственности. Где раньше начальник цеха «контролировал» процесс по своим источникам — теперь данные видны и директору производства, и СД. Власть смещается вверх.
Что делать:
- Объяснить, что прозрачность работает в обе стороны: им тоже видны зоны под их управлением.
- Дать топам ранний доступ к системе, чтобы они «приватизировали» её как свой инструмент.
- Включить топов в УК проекта — они станут соавторами решений.
Уровень 3. Средний менеджмент — страх потери контроля и видимости
Источник: новая система может «обходить» средний менеджмент. Раньше начальник участка получал отчёт у мастера и передавал начальнику цеха. Теперь начальник цеха видит данные напрямую. Кто такой начальник участка?
Что делать:
- Объяснить новую роль среднего менеджмента: они становятся аналитиками и оптимизаторами процессов, а не «передаточным звеном».
- Дать им мощные инструменты анализа (BI на их уровне).
- Поощрять инициативы по улучшениям, найденные через систему.
Уровень 4. Мастера и операторы — страх «увидят, что я химичу»
Источник: десятилетиями выработаны практики, как «обыкновенно списываются» небольшие отклонения. Внезапная прозрачность ломает их рабочий контракт с реальностью. Это не злоумышленники — это люди, которые привыкли работать в системе, где «химичение» было нормой.
Что делать:
- Амнистия: явно сказать, что прошлые расхождения не разбираются. Стартуем с чистого листа.
- Объяснение: новая система — про планирование на будущее, не про разбор прошлого.
- Премии за активное использование: положительная мотивация, не штрафы.
- Прозрачность для них самих: мастер видит свой OEE (общая эффективность оборудования) и может работать над его улучшением — это новая возможность, не угроза.
Это самый сложный уровень сопротивления. Без активной работы здесь система фактически не работает в цеху.
Уровень 5. ИТ — страх «нагрузят и не дадут ресурсов»
Источник: типичная история ИТ — много новых задач, мало новых ресурсов.
Что делать:
- Бюджет ИТ растёт пропорционально объёму поддержки.
- Найм или аутсорс под новые задачи — заранее.
- Аутсорс эксплуатации частей ландшафта, чтобы не размывать внутреннюю команду.
Источники сопротивления — по уровням
Обучение: реальный ROI и типичные ошибки
Бюджет обучения — это статья, которая работает или не работает.
Что работает
- Практика на тестовой системе (не «теория в презентации»).
- Малые группы (5-15 человек), не «вебинар на 200».
- Регулярное повторение: 3-4 сессии с интервалами 2-4 недели.
- Привязка к рабочим задачам: учим не «как настраивать», а «как делать вот эту вашу задачу».
- Внутренние наставники — «первые пользователи», обученные в первой волне, потом обучают коллег.
- Аттестация: каждый сотрудник проходит проверку знаний с фиксацией.
Что не работает
- Разовый тренинг перед запуском в эксплуатацию: через неделю забывают.
- Лекции без практики: усваивается 10-15 %.
- Внешние тренеры без знания вашей специфики: учат «по учебнику», не по вашему процессу.
- «Электронные курсы»: для сложных систем — почти бесполезны. Работают только для простых типовых задач.
- «Дать инструкцию и пусть читают»: не читают.
Бюджет
Реальный бюджет обучения для среднего проекта (MES + IIoT (промышленный интернет вещей) на 200 пользователей): 3-8 млн ₽. Это 5-10 % от общего бюджета проекта. Меньше — почти гарантированный провал принятия системы.
Метрики управления изменениями
Качественные показатели:
| Метрика | Целевое значение | Когда измерять |
|---|---|---|
| Осведомлённость о проекте (% знающих) | >90 % | До запуск в эксплуатацию |
| Согласие с необходимостью (% поддерживающих) | >60 % | До запуск в эксплуатацию |
| % аттестованных пользователей | >85 % | За месяц до запуска в эксплуатацию |
| Уровень использования системы (% активных пользователей от целевой аудитории) | >70 % через 3 мес, >85 % через 12 мес. Сигналы: <60 % — change management работает плохо; <40 % — проект на грани провала (параллельный учёт в Excel); <30 % — нужен перезапуск программы | После запуска в эксплуатацию |
| Частота использования ключевых функций | Растёт каждый месяц первые 6 мес | После запуска в эксплуатацию |
| NPS внутренних пользователей | >0 (нейтральный), цель >+30 | Через 6 и 12 мес после запуска в эксплуатацию |
| % операций без альтернативного учёта (без параллельного Excel) | >90 % через 12 мес | После запуска в эксплуатацию |
| Время выполнения типовой операции | Снижается в течение 6 мес после запуска в эксплуатацию | После запуска в эксплуатацию |
Эти метрики надо измерять регулярно и докладывать на УК проекта. Без метрик управление изменениями — это «декларация о благих намерениях».
Когда проект «передан в эксплуатацию»
Проект формально завершается, когда:
- Все целевые KPI достигнуты или показывают чёткий тренд достижения.
- Уровень использования системы >85 %.
- Параллельные Excel/бумажные процессы исключены.
- Внутренняя команда самостоятельно поддерживает систему.
- Документация передана и актуальна.
- План развития на следующий год утверждён.
Без этих 6 пунктов проект «формально завершён», но фактически не работает. Через год его придётся «реанимировать» с потерей бюджета и времени.
Чек-лист управления изменениями
| # | Пункт | Что значит | ✓ |
|---|---|---|---|
| 1 | Куратор от руководства назначен и активен | Член СД или CEO, не делегирует | |
| 2 | Карта заинтересованных сторон построена и актуализируется | Раз в 3-6 мес | |
| 3 | План коммуникации | Что, кому, когда, как | |
| 4 | План обучения с практикой и аттестацией | Не «лекции», а тренировки | |
| 5 | Бюджет обучения 5-10 % от общего бюджета | Не «по остаточному принципу» | |
| 6 | Внутренние чемпионы определены | По 1-2 на цех/функцию | |
| 7 | Hyperсare-команда сформирована | На 3-6 мес после запуска в эксплуатацию | |
| 8 | KPI на использование системы для пользователей | Привязка к премии | |
| 9 | Программа поощрения активных пользователей | Премии, рейтинги, признание | |
| 10 | Amnesty для мастеров и операторов | Прошлое не разбираем, стартуем с чистого | |
| 11 | Ритуалы использования системы в управлении | Совещания «по дашборду», не «по бумаге» | |
| 12 | Отрезание альтернативных каналов | Постепенное, чтобы Excel «не было нужно» | |
| 13 | Регулярное измерение уровень использования системы | Раз в квартал | |
| 14 | NPS внутренних пользователей | Раз в полгода | |
| 15 | План реагирования на «зоны сопротивления» | Где уровень использования системы <60 % — целевая работа | |
| 16 | Документация в актуальном состоянии | Не «есть, но устарела» | |
| 17 | Внутренняя поддержка самостоятельно работает | После 6-12 мес — без интегратора | |
| 18 | Менеджер изменений в штате или подряде | Не «по совместительству HR» | |
| 19 | Связь с UI/UX-улучшениями системы | Что неудобно — фиксируем и улучшаем | |
| 20 | Регулярные ретроспективы | Раз в полгода: что работает, что нет, что менять |
Антипаттерны
Антипаттерн 1. «Обучили один раз перед запуском в эксплуатацию — поставили галочку». Через неделю забыли. Без повторных сессий и период интенсивной поддержки после запуска — уровень использования системы падает за 3 месяца.
Антипаттерн 2. «Change management начнём после запуска в эксплуатацию». Поздно. К запуску в эксплуатацию люди уже должны быть на этапе «осознание + понимание + освоение». Если начинать после — это работа с реальностью «система работает, но никто не пользуется».
Антипаттерн 3. «Куратор от руководства — это директор по производству». Если речь про MES — может быть. Но если речь про общую цифровую трансформацию — куратор должен быть CEO или член СД. Иначе у проекта нет «защитника» на стратегическом уровне.
Антипаттерн 4. «Менеджер изменений — это HR по совместительству». Менеджер изменений — отдельная роль с полной загрузкой. HR работает с кадрами, не с управление изменениями. Это разные компетенции.
Антипаттерн 5. «Если все согласны — это управление изменениями работает». Часто люди говорят «да, конечно» в лицо, а потом продолжают делать по-старому. Реальная метрика — поведение, не слова. Уровень использования системы, а не «опрос удовлетворённости».
Связанные главы
- 02. Чек-лист готовности предприятия — пункты 41-50 (люди).
- 05. Команда и роли — роль менеджера изменений.
- 03. Антипаттерны и провалы — главная причина провалов — люди, не технологии.
- 15. Экономика: ROI, TCO, NPV — управление изменениями как часть TCO (совокупная стоимость владения).