Сначала в сделке появляется один робот: поставить задачу менеджеру. Затем второй отправляет письмо, третий проверяет поле, четвёртый ждёт оплату, пятый уведомляет руководителя. Через несколько месяцев автоматизация работает, но никто уже не может быстро объяснить весь маршрут и причину текущего состояния сделки.
Проблема не в количестве роботов. Один сложный робот может быть ошибкой, а десять простых — нормальным решением. Граница проходит там, где компания перестаёт управлять отдельными реакциями и должна управлять единым экземпляром процесса с ролями, решениями, ожиданиями, возвратами и результатом.
Команда компании «Первый Приятный Интегратор» | 1PI.PRO показывает признаки этой границы и порядок безопасного перехода.
Что хорошо делает робот
Робот удобен, когда нужно выполнить локальное действие при понятном событии в CRM:
- поставить задачу после перехода сделки на стадию;
- заполнить поле известным значением;
- отправить шаблонное уведомление;
- создать документ или связанную сущность;
- запланировать контроль через заданный интервал;
- вызвать интеграционное действие;
- изменить ответственного по однозначному правилу.
Такое действие имеет ясный вход и короткий проверяемый результат. Оно не требует долгой жизни отдельного маршрута и сложной координации нескольких участников.
Если робот не срабатывает, сначала используйте диагностику роботов в Битрикс24: проверьте событие, стадию, условия, порядок и изменения других автоматизаций. Не стоит заменять исправимую локальную настройку большим процессом.
Когда локальных реакций уже недостаточно
Несколько ролей принимают разные решения
Менеджер собирает данные, юрист проверяет условия, финансы подтверждают оплату, руководитель утверждает исключение. Каждая роль должна получить собственное задание, увидеть нужные данные и зафиксировать решение.
Цепочка уведомлений не управляет решениями. Нужен маршрут, который знает текущую роль, допустимые ответы и следующий шаг.
Появляется возврат на доработку
Сценарий перестаёт быть линейным, когда участник может вернуть работу назад. Нужно определить:
- кому возвращается сделка;
- какие данные нужно исправить;
- какой срок начинает отсчитываться заново;
- какие решения сохраняются;
- кто должен согласовать повторно;
- как отличить возврат от окончательного отказа.
Если это реализовано несколькими перемещениями стадии и независимыми роботами, контекст возврата легко теряется.
Ветки идут параллельно
Юрист и финансы могут проверять сделку одновременно. После этого процесс должен понять, получены ли оба решения, есть ли замечания и кто разрешает конфликт. Ожидание двух независимых результатов — уже задача маршрута, а не одного действия.
Нужно ждать внешнее событие
Процесс может ждать оплату, ответ клиента, документ, результат интеграции или наступление даты. Важно знать, кто владеет ожиданием, когда наступает просрочка и что делать, если событие не произошло.
Робот с паузой способен отложить действие, но длинная система пауз без общего состояния становится непрозрачной: непонятно, какие экземпляры ждут, почему и кто должен вмешаться.
Требуется единый результат
В конце нужно не просто перевести сделку на стадию, а зафиксировать результат процесса: решения ролей, комплект документов, причину исключения, срок, ответственного за следующий этап. Если эти данные разбросаны по задачам и комментариям, руководитель не получает управляемой картины.
Не выбирайте инструмент по числу блоков
Полезнее оценить структуру:
| Признак | Роботы в стадиях | Бизнес-процесс | |---|---|---| | одно короткое действие | подходит | обычно избыточен | | несколько зависимых решений | быстро усложняется | управляет маршрутом | | возврат на доработку | требует дополнительных стадий и правил | описывается отдельной веткой | | параллельные роли | трудно объединить результат | можно проектировать совместное ожидание | | длительное ожидание | возможна пауза, но теряется общий контекст | экземпляр хранит состояние маршрута | | входные параметры и промежуточные данные | ограниченный контекст сделки | можно определить параметры и переменные | | итог процесса | часто равен стадии или действию | фиксируется отдельно |
Таблица не означает, что бизнес-процесс всегда лучше. Он сложнее в проектировании, тестировании и сопровождении. Используйте его только там, где эта сложность уже существует в работе компании.
Проверьте процесс до переноса
Возьмите пять недавних сделок одного типа и для каждой выпишите:
- Событие старта.
- Итоговый результат.
- Участников и их решения.
- Обязательные данные на каждом шаге.
- Возвраты и причины.
- Ожидания внешних событий.
- Исключения.
- Точку, где меняется ответственность.
Если сделки проходят по разным правилам, сначала согласуйте процесс. Руководство по этой проверке есть в статье что автоматизировать, а что сначала описать.
Для проектирования можно обратиться в компанию «Первый Приятный Интегратор» | 1PI.PRO. Мы поможем разделить локальные действия и единый маршрут, не усложняя систему без необходимости.
Как перейти без остановки продаж
1. Зафиксируйте работающих роботов
Составьте реестр: стадия, событие, условие, действие, ответственный и зависимость. Не удаляйте старую автоматизацию до проверки новой.
2. Выберите один тип сделки
Не переносите сразу все направления. Возьмите устойчивый сценарий с понятным владельцем и ограниченным числом исключений.
3. Оставьте простые действия роботам
Необязательно помещать всё внутрь одного шаблона. Отправка уведомления или заполнение поля может остаться локальной, если она не конфликтует с маршрутом.
4. Передайте процессу координацию
В бизнес-процессе сосредоточьте роли, решения, параллельные ветки, возвраты, ожидания, эскалации и итог.
5. Запретите двойное управление
Одна стадия или поле не должны одновременно изменяться старым роботом и новым процессом без явного приоритета. Иначе диагностика превратится в поиск гонки автоматизаций.
6. Проведите контрольные сценарии
Проверьте основной путь, возврат, отказ, просрочку, отсутствие сотрудника, неполные данные и повторный запуск. Свяжите тесты со сквозным процессом продаж, если после сделки работа переходит в исполнение и оплату.
Что можно проверить самостоятельно
Владелец процесса может без изменения портала:
- отметить роботов, которые только уведомляют или заполняют поля;
- найти места, где решение принимает человек;
- перечислить возвраты и ожидания;
- определить владельца результата;
- выбрать пять сделок для теста;
- записать ожидаемый маршрут одним предложением;
- выделить данные, которые должны остаться после завершения.
Если маршрут нельзя объяснить без открытия десятка роботов, это не автоматическое доказательство необходимости бизнес-процесса, но сильный сигнал провести архитектурный разбор.
Когда нужен специалист
Специалист нужен, если:
- автоматизации меняют одни и те же поля или стадии;
- процесс проходит через несколько подразделений;
- есть параллельные решения и повторные согласования;
- требуется перенос без остановки текущей работы;
- используются внешние интеграции;
- нужно разграничить права участников;
- процесс может запускаться повторно;
- важна отчётность по причинам возврата и длительности этапов.
Результатом должен быть не самый большой шаблон, а понятная архитектура: что осталось роботом, что стало процессом, кто владеет каждым состоянием и по каким сценариям принимается работа.
Чего не стоит делать
Не рекомендуем:
- считать число роботов единственным критерием;
- переносить несогласованный маршрут в дизайнер процессов;
- дублировать старую и новую автоматизацию;
- строить один процесс для всех типов сделок;
- скрывать исключения в длинных условиях без описания;
- завершать процесс созданием задачи без проверки решения;
- тестировать только под администратором;
- удалять работающие роботы до приёмки замены.
Частые вопросы
Есть ли точное число роботов, после которого нужен бизнес-процесс?
Нет. Важны роли, зависимости, возвраты, ожидания и единый результат, а не количество блоков.
Можно ли использовать роботов и бизнес-процесс вместе?
Да, если зоны ответственности разделены и одно состояние не меняется конфликтующими правилами.
Когда достаточно робота?
Когда есть одно понятное событие, короткое действие и проверяемый результат без отдельного маршрута согласований.
Что переносить в бизнес-процесс?
Координацию ролей, решения, возвраты, параллельные ветки, ожидания, эскалации и общий результат.
Как проверить переход?
Прогнать основной путь, возврат, отказ, просрочку, отсутствие участника, неполные данные и повторный запуск.
Результат для бизнеса
Хорошая архитектура не противопоставляет роботов и бизнес-процессы. Роботы выполняют локальные действия, а бизнес-процесс управляет маршрутом там, где компании нужно видеть экземпляр работы целиком.
Чтобы разобрать существующую автоматизацию, можно обратиться в компанию «Первый Приятный Интегратор» | 1PI.PRO. Мы зафиксируем текущие правила, найдём конфликтующие участки и предложим минимально достаточную структуру.
