Как согласовать единый процесс перед автоматизацией, если отделы работают по-разному?

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

Почему «у нас все делают по-разному» — полезный сигнал

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

Представьте ресторан, где официанты по-разному понимают слово «готово». Для одного заказ готов после кухни, для другого — после оплаты, для третьего — когда гость получил чек. Кухня может быть очень быстрой, но посетитель всё равно будет ждать, если команда не договорилась о последнем шаге.

С чего начать разбор

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

На этом этапе полезно собрать пять вещей:

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

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

Как выбрать единый вариант

Единый процесс — не обязательно самый сложный. Хорошее правило помогает новому человеку принять следующее решение без звонка «тем, кто знает». Поэтому для каждой спорной точки полезно спросить: какое решение должно быть одинаковым всегда, а где нужен осознанный выбор человека?

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

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

Какие ошибки встречаются чаще всего

Первая — начинать с демонстрации CRM или BPM-системы. Продукт можно выбрать позже; сначала нужен рабочий ответ на вопрос, что система обязана сохранить. Вторая — описывать только нормальный путь и забывать о возврате, отмене, неполных данных и срочных случаях. Именно там сотрудники обычно снова уходят в мессенджеры.

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

Короткий чек-лист перед автоматизацией

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

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

Как провести встречу без бесконечного спора

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

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

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

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

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

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