Как понять, что новой бизнес-системой действительно пользуются?

Понять, что новой бизнес-системой действительно пользуются, можно не по числу созданных учётных записей и не по словам «всё освоили». Нужны следы реальной работы: ключевая задача проходит через систему, ответственный видит следующий шаг, а старый обходной путь постепенно исчезает. Проверять это лучше в первые недели после запуска, пока привычки ещё можно спокойно поправить.

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

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

Сначала выберите одну рабочую цепочку

Не пытайтесь измерить «использование системы вообще». Возьмите один процесс, ради которого её запускали: передача заказа из продаж в исполнение, согласование договора, обработка заявки или планирование закупки. У цепочки должен быть понятный старт, результат и ответственный.

Например, для заказа можно спросить: создана ли карточка после разговора с клиентом, все ли существенные условия в ней есть, видит ли исполнитель задачу без дополнительного звонка и можно ли по системе понять текущий статус. Это гораздо полезнее общего вопроса «вам удобно?».

Если процесс сам по себе расплывчатый, система не сделает его ясным одной настройкой. Сначала полезно договориться, кто принимает решение и что считается завершением. Там, где правила меняются постоянно, особенно важно не зашивать догадки в автоматизацию. Ранее я разбирал, как автоматизировать процесс с меняющимися правилами.

Пять признаков реального использования

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

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

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

Четвёртый — старый обходной путь становится ненужным. Это не означает запретить все чаты и таблицы. Они нужны для обсуждения и черновиков. Но если именно в них хранится обязательная для процесса информация, новая система ещё не стала рабочим местом.

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

Смотрите не на активность, а на качество следа

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

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

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

Короткая проверка после запуска

1. Выберите один процесс и пять–десять свежих случаев.
2. Пройдите каждый случай по времени: где он начался, кто его передал, что увидел следующий участник.
3. Запишите только повторяющиеся провалы: пропавшее поле, непонятный статус, двойной ввод, ожидание без владельца.
4. Спросите участников, какое действие они делают вне системы и почему.
5. Исправьте одну наиболее частую причину, затем повторите выборку через неделю.

Важно не превращать этот разбор в проверку дисциплины. Если сотрудник обходит систему, он обычно пытается выполнить работу, а не испортить внедрение. Возможно, карточка долго открывается, у неё нет нужного поля, или ответственный появляется слишком поздно. Когда причина названа, можно выбрать нормальное изменение вместо очередного напоминания в общем чате.

Чего не делать в первые недели

Не требуйте от команды одновременно заполнить всё, что когда-либо может пригодиться. Когда форма становится длиннее самой работы, люди начинают сохранять минимум и обещать себе вернуться потом. Лучше оставить обязательными только поля, без которых следующий человек не может принять решение, а остальные данные собирать в том месте, где они реально нужны.

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

Что делать с параллельным ведением

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

Иначе переход затягивается: люди начинают выбирать удобный канал для каждого случая, а руководитель получает две несовместимые версии реальности. Если разные программы показывают разные данные, не стоит сразу искать ошибку в отчёте. Сначала нужно определить, какой момент считается завершением в каждой из них и где находится главный источник. Об этом подробнее — в материале про единый источник данных.

Когда система не приживается из-за процесса

Бывает, что интерфейс удобен, обучение прошло, а система всё равно пустует. Частая причина — процесс не даёт людям времени или права на новое действие. Например, менеджер обязан мгновенно ответить клиенту, но для создания заявки нужно сначала получить код от отдела, который работает до шести. Или руководитель требует статус, но не использует его в принятии решений. В такой конструкции сотрудники быстро понимают, что старая переписка надёжнее.

Тогда нужно менять не инструкцию, а саму связку ролей и решений. Где появляется информация? Кто может её подтвердить? В какой момент следующий сотрудник реально начинает работу? Вопросы кажутся простыми, но именно они превращают систему из дополнительного окна в полезный инструмент.

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

Связанные вопросы

• Какие показатели внедрения можно показать собственнику?
• Сколько времени давать команде на переход со старой системы?
• Как понять, что сотрудникам не хватает обучения, а не функции?
• Нужно ли запрещать рабочие чаты после запуска системы?

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