Как внедрить новую систему без остановки работы: инструкция и кейсы

Кайтен

Ускоряет проекты. +25% к скорости внедрения решений

Попробовать бесплатно

Внедрение нового ПО в работу команды не должно замедлять работу сотрудников или полностью останавливать бизнес-процессы. Как этого избежать, рассказываем в этом статье. 

И разобраться в том, как перейти на новую систему без издержек и промедлений, нам помогла Татьяна Ушакова — руководитель направления аналитики и управления процессами машиностроительной компании. 

Почему внедрение новой системы может разрушить процесс работы, а не укрепить его

Новая система кажется быстрее и удобнее. Но если ее внедрить без подготовки и понимания процессов, переход принесет не пользу, а просадку и издержки. 

Главная причина негативного результата — отсутствие пилотного запуска на несколько сотрудников или процессов. Резкий переход всей компании на новую систему несет за собой большие риски — одна неверно настроенная интеграция или неудобная автоматизация парализует работу сотен сотрудников, а не нескольких человек. 

Тестовый период на малом участке процессов или небольшой группе поможет вовремя заметить узкие места новой системы и эффективно адаптировать ее под нужды команды. 

Другие ошибки при внедрении новой системы:

• процессы пытаются подстроить под новую систему, а не систему — под процессы. Система — это инструмент для поддержки работы, а не ее основа. 
• система существует в вакууме. Новая система должна интегрироваться с другими инструментами: мессенджером, базой знаний, отчетностью, CRM.  
• нет сбора обратной связи сотрудников. Чтобы сотрудники пользовались системой, она должна быть удобной. Иначе система станет дополнительной нагрузкой, а не инструментом решения задач. Насколько команде комфортно пользоваться системой, невозможно узнать без сбора фидбека. 

Подготовка процессов к переходу на новую систему работы 

Какие этапы подготовки нужно пройти команде, чтобы сменить систему без авралов:

Определите цель перехода 

Прежде чем выбирать инструмент, сформулируйте, зачем компании менять систему или добавлять новую: сократить время на рутинные операции, систематизировать задачи, снять нагрузку с конкретного отдела или другое. 

Составьте карту текущих процессов

Зафиксируйте, как работает команда сейчас: какие задачи она решает, кто за что отвечает, какие данные нужны для работы, откуда их брать и т.д. Карта поможет понять, какие функции и интеграции прошлой системы нужно перенести в новую, какие убрать, а какие добавить.

Проведите аудит процессов и зафиксируйте ожидания от новой системы — что должно стать быстрее, где предполагается меньше ручного труда и т.д.

Выбрать систему, исходя из целей и процессов

Система должна подстраиваться под предприятие, а не наоборот. Поэтому в начале важно соотнести предполагаемые варианты с текущей работой команды.

Назначьте ответственного за переход

Внедрением должен заниматься один человек — он будет отвечать за результат и принимать конкретные решения о работе системы. Также важно назначить специалистов поддержки, которые оперативно ответят на вопросы команды о новом инструменте. 

Выберите открытых людей для теста

Найдите сотрудников или отдел, который готов протестировать систему и выполнять рекомендации ответственного за переход. Такая группа людей должна быть готова подчиняться предписаниям руководителя внедрения, чтобы у ответственного была возможность протестировать все необходимые варианты работы.

Кайтен — российский сервис для совместной работы. Все процессы компании в одном месте: проекты, задачи, цели, сотрудники, документы, переписки, отчеты, заявки.

Попробовать бесплатно

Система ADKAR: подготовка сотрудников к изменениям

Самая сложная зона всех изменений — восприятие системы людьми. Каким бы классным не был инструмент — почти каждый сотрудник будет создавать сопротивление этим изменениям.

Из чего состоит модель ADKAR:

A — Awareness (осознание) 

Сотрудник понимает, зачем происходит переход на новую систему и какие проблемы старого подхода она решает. Без этого любое изменение воспринимается как решение «сверху», навязанное без объяснений.

D — Desire (желание) 

Сотрудник не просто понимает необходимость перехода, но и лично готов в нем участвовать. Человеку нужно видеть, что нововведение упростит именно его задачи, а не только «улучшит показатели компании».

K — Knowledge (знание)

Важно внести организационную ясность.

Что должен знать каждый сотрудник перед стартом работы в новой системе (в том числе, пилотная группа):

• что конкретно изменится в работе. Какие задачи решаются в новом инструменте, какие кнопки нужно для этого нажать, какие процессы остались прежними, какие поменялись, что делать, если что-то не работает;
• в какой конкретный момент старая система «отпадает». Определите точный дедлайн, когда все сотрудники должны изучить новую систему и перенести необходимые данные в нее. Иначе переход растянется на неопределенный срок. Одни коллеги будут ставить задачи в старом ПО, другие — в новом, и всем придется пользоваться обеими системами. 
• где искать инструкции. Создайте базу знаний для пользования новой системой. Сделайте так, чтобы она всегда была под рукой у подчиненных. Некоторые системы сами создают открытые базы знаний для пользователей. Пример — базы знаний Кайтен.  
• кому обращаться за помощью. Определите конкретного человека, администратора системы, который будет сопровождать команду в новом ПО. 

A — Ability (умение)

Сотрудник может выполнять задачи в новой системе самостоятельно, без пошаговой подсказки администратора системы. Для этого нужно пройтись по сценариям работы каждого сотрудника вместе с ним, чтобы он мог сразу на практике закрепить полученные инструкции. 

Между «знаю, как» и «умею делать» часто есть разрыв, который проявляется только на практике — поэтому этот этап требует времени и обратной связи, а не только инструкции.

R — Reinforcement (закрепление)

Старая система перестает быть равноправной альтернативой — ее постепенно выводят из всех процессов. Если инструмент полностью новый — он не заменит старую систему — важно определить дату, к которой все сотрудники должны пройти обучение и освоиться в инструменте для полноценной работы.

Также руководитель контролирует, что ключевые сценарии действительно выполняются в новом инструменте, и озвучивает прогресс в процессах, связанных с новой системой.

С чего начать внедрение новой системы: 8 шагов пилотного запуска

Пилотный запуск системы — это параллельный запуск новой системы на небольшом отделе или процессе. Пока остальная команда продолжает работать в старой системе, несколько человек ведут задачи и в старом ПО, и в новом. 

Шаги для успешного пилота: 

Определите критерии результата до старта работы

Оценивать пилот нужно не по тому, понравился ли интерфейс сотрудникам, а действительно ли система решает рабочие задачи:

• сотрудники реально ведут работу в новой системе, а не дублируют ее в старой;
• задачи не теряются между этапами и ответственными;
• сроки и ответственные по каждой задаче понятны для всех участников процесса;
• руководителю хватает встроенной отчетности, чтобы понимать статус работы;
• количество ручных действий сократилось, а не выросло;
• ключевые сценарии работают без обходных решений и других инструментов (например, без переписок в личных мессенджерах);
• сотрудники способны работать самостоятельно, без постоянной поддержки команды внедрения;
• задачи закрываются в срок.

Выберите пилотный процесс Лучше взять процесс, который отражает типичный рабочий цикл: с несколькими этапами, разными участниками и понятным результатом.

Проведите аудит процесса, соберите те показатели, которые хотели бы улучшить с помощью внедрения новой системы. 

Выберите сотрудников для теста

Ограничьте пилотную группу одним отделом или даже частью отдела — так проще собирать обратную связь и оперативно вносить правки в систему.

Соберите MVP системы

Подготовьте пространство для работы фокус-группы заранее, чтобы сотрудникам осталось только перенести свои задачи в новую систему. 

Проведите небольшое обучение

Дайте вводные инструкции команде тестирования, чтобы та не тратила время на базовое изучение инструмента, а сразу приступила к работе в нем. 

Ограничьте срок тестированияОграниченный срок дисциплинирует команду внедрения и пилотную группу, и не дает тестированию превратиться в постоянный параллельный режим работы.

Зафиксируйте, кто и как собирает обратную связь от команды

Определите заранее, кто отвечает за сбор обратной связи от пилотной группы и в каком формате: короткие еженедельные созвоны, форма в чате, регулярный опрос. Также определите метрики и отчеты, на которые будете смотреть после завершения пилотного периода.  

Проанализируйте результаты работы

После сбора обратной связи и отчетов о проделанной работе, откройте зафиксированные показатели при аудите процесса и сравните их. 

Какие показатели можно сравнить:

• насколько быстрее стали закрываться задачи;
• число автоматизаций;
• оценка инструмента командой;  
• число закрытых задач за определенный период;
• качество решенных задач и другое.

Примеры пилотного внедрения от клиентов Кайтен

Как можно перенести процессы из одной системы в другую – несколько реальных историй: 

АСГ (Алкогольная сибирская группа), от пилотного запуска до 300+ сотрудников в системе Кайтен

Старая система, Microsoft, ушла из России в 2022 году, нужна была срочная замена.

В 2022 году компания запустила пилот на бесплатном тарифе Кайтена — проверяли гипотезы, собирали обратную связь от сотрудников. Смогли протестировать новую систему без финансовых вложений. 

Масштабирование: когда стало понятно, что инструмент «прижился», компания перешла на полноценную on-premise-версию. 

Результат: 300+ лицензий. В систему интегрированы BI-дашборды, автоматизации и собственные приложения через API.

Агентство MST: сотрудники сами попросили внедрить Кайтен после пилотного запуска

Старая система представляла из себя разрозненные папки на Google-диске, чаты и таблицы. Команде было сложно уследить за сроками и согласованиями. 

Пилот запустили на одном конкретном SMM-проекте, где были проблемы с согласованиями. Шаги тестового запуска: определили цель → собрали пилотную группу → провели обучение → создали простую канбан-доску → организовали ритм работы с заказчиком.

После успешного пилота SEO-отдел сам попросил внедрить у себя ту же логику. И компания дальше распространила на все направления агентства.

Результат: отношения с клиентами и между сотрудниками стали более прозрачными и открытыми. Руководитель стал меньше тратить время на контроль и управление задачами. Сейчас система может расти вместе с агентством. 

Как понять, что систему можно масштабировать

После окончания тестового периода нужно проверить подтвердились гипотезы, критерии, выдвинутые на старте. 

Сигналы, что система готова к масштабированию:

• Пилотная группа не хочет возвращаться назад. Команда сама работает в новой системе, без напоминаний.
• Ключевые сценарии работают без «костылей». Не нужно закрывать пробелы перепиской в мессенджерах, таблицами или ручными операциями.
• Руководителю хватает встроенной отчетности, чтобы понимать статус работы без дополнительных созвонов и выгрузок.
• Количество ручных действий сократилось, а не выросло — иначе система добавляет нагрузку на команду, а не снимает ее.
• Сотрудники способны работать самостоятельно, без постоянной поддержки команды внедрения.

Если команда выполняла все рекомендации, но не получила желаемого результата, то продлевать пилот нет смысла. Лучше отказаться от системы и искать другие альтернативы. 

Полная миграция команды: этапы и ошибки

1. Зафиксируйте текущие правила и связи процесса

Перед переносом нужно явно выписать все правила, ограничения и связи, по которым живет текущий процесс — включая те, что кажутся очевидными.

2. Систематизируйте информацию перед внедрением

Определите, какие процессы и данные нужно перенести в первую очередь, а от каких — вовсе отказаться. 

Блоки данных для переноса:

• обязательно для переноса: активные задачи и проекты, которые нельзя остановить; документы, которыми команда пользуется каждый день.
• перенос по необходимости: шаблоны и документы, которые команда использует реже, чем раз в несколько недель; архив задач и проектов. 
• отказ от переноса: устаревшие документы. 

3. Подготовьте систему заранее, а не в момент переключения

Настройка, перенос данных, проверка интеграций и прав доступа должны быть сделаны до старта миграции, а не одновременно с ней. Меняющаяся в процессе работы система увеличивает время простоя, число ошибок, которые придется исправлять на ходу под давлением сроков и других сотрудников.

Пройдитесь в системе через ключевые сценарии целиком — от начала до конца, — чтобы поймать разрывы в логике процесса до того, как их обнаружит команда.

4. Обеспечьте поддержку в первые дни после перехода

Даже при идеальной подготовке в первые дни после миграции у сотрудников будут вопросы и сбои. Наличие быстрой поддержки на старте определяет, привыкнет команда к новой системе или начнет искать обходные пути.

Коротко о внедрении новой системы: чек-листы для руководителя

Собрали основные пункты в один чек-лист для внедрения системы: