Блог Center-Game

Run & Change: как внедрять новую систему и не выжечь команду

Когда компания внедряет любую новую систему (ERP, CRM, HRM, корпоративный портал или сервис согласований), она начинает жить в двух мирах. С одной стороны, старую систему остановить нельзя: в ней ещё живут заявки, договоры, отчёты, клиенты, финансы и склад. С другой стороны, новую систему тоже нельзя отложить: идут сроки проекта, подрядчик ждёт решений, команда тестирует сценарии, переносит данные, учится и исправляет ошибки. На корпоративном языке это называется Run & Change.
В реальности это называется так: одни и те же люди днём держат старую систему, вечером тестируют новую, а ночью отвечают в проектный чат.
В итоге Run & Change ломается не потому, что люди ленятся или сопротивляются изменениям, а потому, что двойная нагрузка остаётся невидимой. Задача руководителя в такой ситуации — сделать двойную нагрузку управляемой.

Главная ошибка: считать изменение «дополнительной задачей»

Обычно проект начинается так: «Коллеги, текущую работу никто не отменял, но нужно немного помочь внедрению». Слово «немного» опасное. Сначала это созвон на час, потом тестирование, потом таблица замечаний, потом сверка данных, потом обучение коллег. И ещё одна встреча, потому что «без вас не разберёмся». Через две недели «немного» становится второй работой.
В планах это всё ещё выглядит как участие в проекте, а не как отдельная нагрузка. Поэтому никто не снижает операционные ожидания, не убирает лишние задачи и не защищает ключевых людей от перегруза. В итоге команда не тянет две работы одновременно.
Что с этим делать?

Составьте карту двойной нагрузки

Перед тем как требовать вовлечённости, выпишите на один лист две колонки.
Run — что нельзя остановить
Change — что требует новая система
— закрытие месяца; — обработка заявок; — поддержка пользователей; — отчёты и выгрузки; — ручные сверки; — исправление ошибок; — критичные процессы для клиентов, денег и сроков
— интервью с экспертами; — описание процессов; — проверка целевых сценариев; — тестирование; — миграция данных; — обучение пользователей; — подготовка инструкций; — разбор дефектов; — участие в go-live
Потом отметьте, какие люди отвечают за процессы в обеих колонках. Обычно там окажутся одни и те же лица: эксперты процесса, руководители групп, аналитики, ИТ-специалисты, администраторы систем, будущие суперпользователи.
Здесь вам нужно признать проблему: если человек есть в обеих колонках, он не доступен на 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 — не героически дотянуть до запуска, а успешно пройти проект перехода так, чтобы старая система не рухнула.