Как внедрить новую систему без остановки работы: инструкция и кейсы
Блог Kaiten ·
Инструкция для руководителей по тому, как сменить систему без простоя и издержек
Внедрение нового ПО в работу команды не должно замедлять работу сотрудников или полностью останавливать бизнес-процессы. Как этого избежать, рассказываем в этом статье. 
И разобраться в том, как перейти на новую систему без издержек и промедлений, нам помогла Татьяна Ушакова — руководитель направления аналитики и управления процессами машиностроительной компании. 
Новая система кажется быстрее и удобнее. Но если ее внедрить без подготовки и понимания процессов, переход принесет не пользу, а просадку и издержки. 
Главная причина негативного результата — отсутствие пилотного запуска на несколько сотрудников или процессов. Резкий переход всей компании на новую систему несет за собой большие риски — одна неверно настроенная интеграция или неудобная автоматизация парализует работу сотен сотрудников, а не нескольких человек. 
Тестовый период на малом участке процессов или небольшой группе поможет вовремя заметить узкие места новой системы и эффективно адаптировать ее под нужды команды. 
Другие ошибки при внедрении новой системы:
Какие этапы подготовки нужно пройти команде, чтобы сменить систему без авралов:
Определите цель перехода 
Прежде чем выбирать инструмент, сформулируйте, зачем компании менять систему или добавлять новую: сократить время на рутинные операции, систематизировать задачи, снять нагрузку с конкретного отдела или другое. 
Составьте карту текущих процессов
Зафиксируйте, как работает команда сейчас: какие задачи она решает, кто за что отвечает, какие данные нужны для работы, откуда их брать и т.д. Карта поможет понять, какие функции и интеграции прошлой системы нужно перенести в новую, какие убрать, а какие добавить.
Проведите аудит процессов и зафиксируйте ожидания от новой системы — что должно стать быстрее, где предполагается меньше ручного труда и т.д.
Выбрать систему, исходя из целей и процессов
Система должна подстраиваться под предприятие, а не наоборот. Поэтому в начале важно соотнести предполагаемые варианты с текущей работой команды.
Назначьте ответственного за переход
Внедрением должен заниматься один человек — он будет отвечать за результат и принимать конкретные решения о работе системы. Также важно назначить специалистов поддержки, которые оперативно ответят на вопросы команды о новом инструменте. 
Выберите открытых людей для теста
Найдите сотрудников или отдел, который готов протестировать систему и выполнять рекомендации ответственного за переход. Такая группа людей должна быть готова подчиняться предписаниям руководителя внедрения, чтобы у ответственного была возможность протестировать все необходимые варианты работы.
Самая сложная зона всех изменений — восприятие системы людьми. Каким бы классным не был инструмент — почти каждый сотрудник будет создавать сопротивление этим изменениям.
Из чего состоит модель ADKAR:
A — Awareness (осознание)  
Сотрудник понимает, зачем происходит переход на новую систему и какие проблемы старого подхода она решает. Без этого любое изменение воспринимается как решение «сверху», навязанное без объяснений.
D — Desire (желание)  
Сотрудник не просто понимает необходимость перехода, но и лично готов в нем участвовать. Человеку нужно видеть, что нововведение упростит именно его задачи, а не только «улучшит показатели компании».
K — Knowledge (знание)
Важно внести организационную ясность.
Что должен знать каждый сотрудник перед стартом работы в новой системе (в том числе, пилотная группа):
A — Ability (умение)
Сотрудник может выполнять задачи в новой системе самостоятельно, без пошаговой подсказки администратора системы. Для этого нужно пройтись по сценариям работы каждого сотрудника вместе с ним, чтобы он мог сразу на практике закрепить полученные инструкции. 
Между «знаю, как» и «умею делать» часто есть разрыв, который проявляется только на практике — поэтому этот этап требует времени и обратной связи, а не только инструкции.
R — Reinforcement (закрепление)
Старая система перестает быть равноправной альтернативой — ее постепенно выводят из всех процессов. Если инструмент полностью новый — он не заменит старую систему — важно определить дату, к которой все сотрудники должны пройти обучение и освоиться в инструменте для полноценной работы.
Также руководитель контролирует, что ключевые сценарии действительно выполняются в новом инструменте, и озвучивает прогресс в процессах, связанных с новой системой.
Пилотный запуск системы — это параллельный запуск новой системы на небольшом отделе или процессе. Пока остальная команда продолжает работать в старой системе, несколько человек ведут задачи и в старом ПО, и в новом. 
Шаги для успешного пилота: 
Определите критерии результата до старта работы
Оценивать пилот нужно не по тому, понравился ли интерфейс сотрудникам, а действительно ли система решает рабочие задачи:
Выберите пилотный процесс Лучше взять процесс, который отражает типичный рабочий цикл: с несколькими этапами, разными участниками и понятным результатом.
Проведите аудит процесса, соберите те показатели, которые хотели бы улучшить с помощью внедрения новой системы. 
Выберите сотрудников для теста
Ограничьте пилотную группу одним отделом или даже частью отдела — так проще собирать обратную связь и оперативно вносить правки в систему.
Соберите MVP системы
Подготовьте пространство для работы фокус-группы заранее, чтобы сотрудникам осталось только перенести свои задачи в новую систему. 
Проведите небольшое обучение
Дайте вводные инструкции команде тестирования, чтобы та не тратила время на базовое изучение инструмента, а сразу приступила к работе в нем. 
Ограничьте срок тестирования Ограниченный срок дисциплинирует команду внедрения и пилотную группу, и не дает тестированию превратиться в постоянный параллельный режим работы.
Зафиксируйте, кто и как собирает обратную связь от команды
Определите заранее, кто отвечает за сбор обратной связи от пилотной группы и в каком формате: короткие еженедельные созвоны, форма в чате, регулярный опрос. Также определите метрики и отчеты, на которые будете смотреть после завершения пилотного периода.  
Проанализируйте результаты работы
После сбора обратной связи и отчетов о проделанной работе, откройте зафиксированные показатели при аудите процесса и сравните их. 
Какие показатели можно сравнить:
Как можно перенести процессы из одной системы в другую – несколько реальных историй: 
Старая система, Microsoft, ушла из России в 2022 году, нужна была срочная замена.
В 2022 году компания запустила пилот на бесплатном тарифе Кайтена — проверяли гипотезы, собирали обратную связь от сотрудников. Смогли протестировать новую систему без финансовых вложений. 
Масштабирование: когда стало понятно, что инструмент «прижился», компания перешла на полноценную on-premise-версию . 
Результат : 300+ лицензий. В систему интегрированы BI-дашборды , автоматизации и собственные приложения через API.
Старая система представляла из себя разрозненные папки на Google-диске, чаты и таблицы. Команде было сложно уследить за сроками и согласованиями. 
Пилот запустили на одном конкретном SMM-проекте, где были проблемы с согласованиями. Шаги тестового запуска: определили цель → собрали пилотную группу → провели обучение → создали простую канбан-доску → организовали ритм работы с заказчиком.
После успешного пилота SEO-отдел сам попросил внедрить у себя ту же логику. И компания дальше распространила на все направления агентства.
Результат: отношения с клиентами и между сотрудниками стали более прозрачными и открытыми. Руководитель стал меньше тратить время на контроль и управление задачами. Сейчас система может расти вместе с агентством. 
После окончания тестового периода нужно проверить подтвердились гипотезы, критерии, выдвинутые на старте. 
Сигналы, что система готова к масштабированию:
Если команда выполняла все рекомендации, но не получила желаемого результата, то продлевать пилот нет смысла. Лучше отказаться от системы и искать другие альтернативы. 
Перед переносом нужно явно выписать все правила, ограничения и связи, по которым живет текущий процесс — включая те, что кажутся очевидными.
Определите, какие процессы и данные нужно перенести в первую очередь, а от каких — вовсе отказаться. 
Блоки данных для переноса:
Настройка, перенос данных, проверка интеграций и прав доступа должны быть сделаны до старта миграции, а не одновременно с ней. Меняющаяся в процессе работы система увеличивает время простоя, число ошибок, которые придется исправлять на ходу под давлением сроков и других сотрудников.
Пройдитесь в системе через ключевые сценарии целиком — от начала до конца, — чтобы поймать разрывы в логике процесса до того, как их обнаружит команда.
Даже при идеальной подготовке в первые дни после миграции у сотрудников будут вопросы и сбои. Наличие быстрой поддержки на старте определяет, привыкнет команда к новой системе или начнет искать обходные пути.
Собрали основные пункты в один чек-лист для внедрения системы: