Представим, что компания запускает новую систему: CRM, ERP, HRM, корпоративный портал или сервис для согласований. Вот как, скорее всего, это выглядит:
- Сотрудников обучили, провели демонстрацию, разослали инструкцию, назначили ответственных. В проектном чате написали: «Коллеги, с понедельника работаем только в новой системе».
- В понедельник всё выглядит прилично.
- Во вторник менеджер всё равно ведёт клиента в старой таблице. Финансист просит прислать данные в Excel. Руководитель отдела говорит: «Занесите потом, сейчас быстрее в чате». Суперпользователь полдня вносит данные за тех, кто «пока не разобрался».
- Через месяц в отчёте написано: обучение проведено, доступы выданы, инструкции есть. А в реальности компания живёт в двух системах: официальной и настоящей.
Это называется «саботаж». Но дело не в том, что люди воюют с новой программой — на самом деле они защищают привычный способ работать: понятный, быстрый, безопасный и уже встроенный в отношения внутри команды.
В такой ситуации руководителю нужно не «ещё раз объяснить интерфейс», а найти место, где сотрудник возвращается к старому процессу, и убрать причину возврата.
Сначала проверьте: это правда проблема обучения?
У обучения есть понятная задача: показать, как устроена система:
- где создать заявку,
- как заполнить карточку,
- куда прикрепить файл,
- кто согласует следующий шаг,
- как посмотреть статус.
Проблема в том, что переход на новое ПО ломается не только на кнопках. Сотрудник может знать систему и всё равно не пользоваться ей. Потому что в реальной работе у него другие вопросы:
- что будет, если я ошибусь?
- почему старый способ теперь запрещён?
- кто поможет, когда срок горит?
- зачем мне тратить больше времени сейчас?
- будут ли меня оценивать по новым правилам?
- не отменят ли эту инициативу через три месяца?
Главная причина сопротивления изменениям состоит в том, что человек не может ответить себе, зачем это нужно и что изменится лично для него.
Найдите признаки «саботажа»
Открытого бунта почти никогда нет. Никто не выходит к руководителю с плакатом «Верните старую CRM». Обычно всё тише:
- «Сейчас быстро сделаем в таблице, потом занесём»;
- «Я в системе не вижу, кто ответственный, поэтому написал в чат»;
- «Клиент ждёт, не до регламента»;
- «В прошлый раз я заполнил, а смежники не посмотрели».
Для сотрудника это не саботаж, а здравый смысл: выбрать путь, где меньше риска. А вот для компании это проблема, потому что новая система становится не рабочей средой, а витриной для отчётности.
Найдите точку возврата
Вопрос «Почему вы сопротивляетесь?» звучит как обвинение. Сотрудник начнёт защищаться или говорить общие вещи: «неудобно», «много полей», «не хватает времени», «система сырая».
Лучше искать точку возврата — момент, когда сотрудник должен работать в новой системе, но уходит в старый способ.
После такой диагностики разговор меняется. Не «почему вы саботируете», а «в какой момент новый процесс становится опаснее, медленнее или бессмысленнее старого».
Причина первая: сотрудник не видит пользы для себя
Для бизнеса новая система может быть очевидным благом: меньше ручных операций, больше контроля, единая база, точные отчёты, прозрачные процессы. Но сотрудник живёт не на уровне бизнес-целей. Он живёт в своём рабочем дне: клиент на линии, смежный отдел не отвечает, сроки горят, руководитель просит результат сегодня. Если польза не переведена на язык его задач, новая система выглядит как налог на работу.
Как исправить
Не объясняйте внедрение только словами «эффективность», «прозрачность», «единый контур», «цифровизация». Покажите, что изменится в конкретной роли. Польза должна быть не «для компании вообще», а для человека в его рабочей ситуации.
Причина вторая: старая экспертиза обнулилась
В каждом старом процессе есть люди, на которых всё держалось — таких людей часто называют неформальными экспертами. Когда приходит новая система, они снова становятся новичками: вчера к ним шли за советом, а сегодня им самим нужно спрашивать, куда нажать. Когда человек теряет власть, статус, идентичность или контроль над своей работой, возникает сопротивление.
Как исправить
Не обнуляйте старых экспертов фразой «теперь всё будет по-новому». Используйте их опыт и заранее включайте в роли суперпользователей, наставников, участников пилотного запуска, давайте проверять сценарии, собирать вопросы, тестировать инструкции, показывать проектной команде, где регламент расходится с жизнью. Так человек не теряет статус, а переводит старую экспертизу в новую систему.
Используйте их опыт:
Причина третья: команда устала от изменений
Иногда проблема не в конкретной системе, а в том, что изменений слишком много: структура, ERP, искусственный интеллект, регламенты, подрядчики, роли, отчётность, KPI… Таким образом, хорошее изменение попадает в уставшую команду.
Как исправить
Не делайте ещё одну большую презентацию «почему это важно». Уставшая команда не верит манифестам. Но может поверить маленькому улучшению, которое произошло на её глазах. Сделайте короткий цикл изменения:
- Выбрали один проблемный сценарий.
- Разобрали его с командой.
- Договорились о новом правиле.
- Проверили через неделю.
- Убрали лишнее.
- Перешли к следующему сценарию.
Что делать, если обучение уже прошло, а поведение не изменилось
Вот рабочий порядок:
- Не назначайте повторное обучение сразу. Если проблема в отношении к изменениям, это только усилит раздражение: «Нас опять учат тому, что мы уже знаем».
- Разберите реальный сценарий. Не «как пользоваться системой», а что-то из реальной рабочей жизни: менеджер заводит новую позицию; HR запускает кадровое изменение; проектная команда передаёт задачу смежникам. Дальше спрашивайте, в какой момент люди хотят вернуться к старому способу, почему и что сделать, чтобы пользоваться новой системой стало удобнее.
- Дайте людям ошибиться до «боевого» запуска. Ошибки в реальной работе пугают, потому что могут подсветить «некомпетентность» сотрудника, а то и разрушить процесс. А вот ошибиться в симуляции, тестовом контуре или деловой игре — не страшно, потому что цена ошибки низкая. Создание такого тестового контура поможет сэкономить на исправлении будущих ошибок.
- Поддержите после запуска. Дать людям технологию недостаточно, чтобы они начали использовать её эффективно — изменение должно быть встроено в рабочие процессы и поддерживаться руководством. Для этого нужны регулярные сверки, каналы поддержки и обратной связи, реакции на жалобы.
Мы в Center-Game разрабатываем и проводим программы сопровождения изменений. Наш фокус — помочь сотрудникам наладить коммуникацию с руководством и друг с другом во время переходного периода. В программу входят исследования потребностей, симуляции новых коммуникаций и внедрения изменений в деловых играх, сопровождение и поддержка. Вы можете собрать программу из тех модулей, которые нужны именно вашей компании, а если сомневаетесь, что выбрать, — мы подскажем. 🔗 Попробуйте собрать своё решение в нашем конструкторе и сразу получите примерный расчёт.
Помните главное: изменения вступают в силу, когда сотрудники понимают, зачем нужны эти изменения, и становятся их амбассадорами, а не жертвами.