Когда компания внедряет любую новую систему (ERP, CRM, HRM, корпоративный портал или сервис согласований), она начинает жить в двух мирах. С одной стороны, старую систему остановить нельзя: в ней ещё живут заявки, договоры, отчёты, клиенты, финансы и склад. С другой стороны, новую систему тоже нельзя отложить: идут сроки проекта, подрядчик ждёт решений, команда тестирует сценарии, переносит данные, учится и исправляет ошибки. На корпоративном языке это называется Run & Change.
В реальности это называется так: одни и те же люди днём держат старую систему, вечером тестируют новую, а ночью отвечают в проектный чат.
В итоге Run & Change ломается не потому, что люди ленятся или сопротивляются изменениям, а потому, что двойная нагрузка остаётся невидимой. Задача руководителя в такой ситуации — сделать двойную нагрузку управляемой.
Главная ошибка: считать изменение «дополнительной задачей»
Обычно проект начинается так: «Коллеги, текущую работу никто не отменял, но нужно немного помочь внедрению». Слово «немного» опасное. Сначала это созвон на час, потом тестирование, потом таблица замечаний, потом сверка данных, потом обучение коллег. И ещё одна встреча, потому что «без вас не разберёмся». Через две недели «немного» становится второй работой.
В планах это всё ещё выглядит как участие в проекте, а не как отдельная нагрузка. Поэтому никто не снижает операционные ожидания, не убирает лишние задачи и не защищает ключевых людей от перегруза. В итоге команда не тянет две работы одновременно.
Что с этим делать?
Составьте карту двойной нагрузки
Перед тем как требовать вовлечённости, выпишите на один лист две колонки.
Потом отметьте, какие люди отвечают за процессы в обеих колонках. Обычно там окажутся одни и те же лица: эксперты процесса, руководители групп, аналитики, ИТ-специалисты, администраторы систем, будущие суперпользователи.
Здесь вам нужно признать проблему: если человек есть в обеих колонках, он не доступен на 100% ни для операционки, ни для проекта, а значит команда будет закрывать дыры личным временем, нервами и качеством работы.
Разделите роли, время и приоритеты
Run & Change не может держаться на героизме. Нужна простая конструкция.
Роли
Плохо, когда все помогают всем. Тогда всё замыкается на одном самом компетентном человеке, а остальные выполняют роль костылей. Лучше заранее назначить роли:
- Кто держит старую систему и следит, чтобы текущие процессы не упали.
- Кто ведёт изменения на стороне бизнеса: проверяет сценарии, собирает вопросы, помогает команде принять новый порядок.
- Кто поддерживает пользователей: объясняет коллегам, что делать, фиксирует типовые ошибки, передаёт проблемы проектной команде.
- Кто решает конфликты приоритетов: что важнее на этой неделе — тестирование, клиентская задача, отчёт или исправление дефекта.
Время
Самый быстрый способ выжечь команду — ставить проектные задачи «между делом». Между делом можно ответить на письмо, но не внедрить систему, от которой зависит бизнес. Для Change нужны защищённые временные окна:
- два часа в день без операционных задач для тестирования;
- один день в неделю для проектной работы ключевых экспертов;
- запрет на проектные встречи в дни закрытия месяца;
- отдельные окна для разбора дефектов;
- дежурства суперпользователей после запуска
Если защищённого времени нет, операционка всегда съест проект.
Приоритеты
Команда не должна каждый день заново решать, что важнее: клиентская заявка, тестирование, старый отчёт, обучение коллег или ответ подрядчику. Нужны чёткие правила — например, такие:
- критичные операции старой системы выше проектных встреч;
- вопросы, которые блокируют подрядчика, решаются в течение суток;
- тестирование go-live выше необязательных отчётов;
- дефект, который мешает пользователям, выше косметических улучшений;
- временное исключение из нового процесса утверждает конкретный руководитель
Предусмотрите конфликты
Run & Change перегружает команду не только задачами, но и конфликтами: старые процессы vs новые, скорость vs качество, клиент сейчас vs проект потом, регламент vs реальная жизнь. Когда эти конфликты возникают в реальном рабочем процессе, люди почти всегда выбирают безопасный вариант, а не верный.
Предусмотреть и отработать эти конфликты в безопасности можно в симуляции или деловой игре. Например, команда получает ситуацию:
Сегодня закрытие месяца. Одновременно нужно протестировать критичный сценарий в новой ERP. Эксперт процесса один. Подрядчик ждёт ответ до 18:00. Руководитель просит старый отчёт. Пользователи жалуются на ошибку в текущей системе. Что делаем?
В игровой ситуации сразу видно, кто берёт ответственность или уходит в старые схемы, где не хватает правил или какие решения нужно принять до реального запуска.
Мы в Center-Game проводим программы сопровождения изменений, в которых помогаем протестировать новые процессы, схемы коммуникаций и проектные схемы в авторских деловых играх. Сверх этого: помогаем перенести опыт программы в работу, сопровождаем сотрудников во время изменений и помогаем снизить издержки. Вы можете 🔗 собрать свою программу из готовых модулей и сразу получить примерный расчёт.
Защитите ключевых специалистов
В Run & Change первыми выгорают самые нужные люди. Это те, кто одновременно знают старый процесс и понимают новую систему, помнят исключения, обучают коллег, разбирают ошибки — и всё ещё отвечают за операционку. С одной стороны, это удобно: всегда понятно, к кому обратиться. С другой, если такой человек заболеет, уволится или уйдёт в отпуск — проект встанет.
Что делать, чтобы этого не допустить:
- временно снять с эксперта часть операционки;
- назначить заместителя на понятные задачи;
- не звать эксперта на встречи «для статуса»;
- собирать вопросы через координатора, а не напрямую;
- фиксировать решения письменно, чтобы не объяснять одно и то же десять раз;
- дать восстановление после пиков: миграции, go-live, интенсивного тестирования
Ещё раз самое главное
Run & Change изматывает команду, когда старая работа осталась, новая добавилась, а ресурс никто не пересчитал. Чтобы переход совершился и бизнес не остановился:
- выпишите двойную нагрузку;
- найдите людей, которые попали и в Run, и в Change;
- разделите роли, время и приоритеты;
- защитите ключевых экспертов;
- тренируйте реальные конфликты, а не только интерфейс
Цель Run & Change — не героически дотянуть до запуска, а успешно пройти проект перехода так, чтобы старая система не рухнула.