Почти на каждом аудите я вижу одну и ту же картину: половина автоматизации собрана роботами там, где нужен бизнес-процесс, а вторая — тяжёлым бизнес-процессом там, где хватило бы двух роботов. Работает и то и другое, но криво: где-то не хватает логики, где-то никто не может разобраться, что вообще происходит. Разница между этими инструментами простая, и если её один раз понять, выбор занимает минуту. Давайте разберём на пальцах, что чем считается и по какому признаку принимать решение.
Робот — это действие, привязанное к стадии
Робот в Битриксе живёт на конкретной стадии воронки. Сделка на неё зашла — робот отработал: поставил задачу, отправил письмо, сменил ответственного, изменил поле, создал элемент в смарт-процессе. Он не спрашивает, не ждёт, не принимает решений. Просто выполняет то, что вы записали, и идёт дальше по списку.
Отсюда его главная сила — прозрачность. Роботы видно прямо в канбане: открыл стадию, посмотрел список, понял всю логику. Их настраивает руководитель отдела без разработчика, меняет за пять минут, отключает одной галочкой. Когда через полгода приходит новый человек, он разбирается в такой автоматизации самостоятельно.
И отсюда же ограничение. Робот линеен. У него есть условие запуска и есть действие — но нет маршрута. Он не умеет остановиться и подождать, пока руководитель нажмёт кнопку, не умеет вернуть заявку на доработку и не помнит, что было три шага назад. Как только логика перестаёт укладываться в цепочку простых действий, роботы начинают множиться и путаться.
Бизнес-процесс — это маршрут с развилками
Бизнес-процесс — другой зверь. Это схема, по которой документ или сделка идёт от начала до конца: с условиями, ветками, паузами и участием людей. Он умеет остановиться на шаге согласования и ждать, пока конкретный сотрудник примет решение. По результату решения он расходится на разные ветки: согласовано — идём дальше, отклонено — возвращаемся на доработку с комментарием.
Именно это отличие и есть главное: бизнес-процесс держит состояние. Он помнит, на каком шаге находится, кто уже ответил, а кто нет, сколько раз документ уходил на возврат. Роботами такую память не соберёшь — точнее, соберёшь, но через набор служебных полей, и потом сам не поймёшь, что там происходит.
Плата за возможности — сложность. Конструктор бизнес-процессов доступен не на всех тарифах, требует аккуратности в проектировании и обычно живёт на стороне интегратора, а не заказчика. Схема, которую собрал один человек, редко бывает понятна другому без документации. Поэтому запускать бизнес-процесс ради двух действий подряд — из пушки по воробьям.
Критерий выбора: спросите, есть ли развилка
Я пользуюсь одним вопросом: в этой логике человек где-нибудь принимает решение, от которого зависит дальнейший путь? Если да — это бизнес-процесс. Если нет и всё сводится к «случилось событие, сделай действие» — это робот. Проверка занимает минуту и работает почти всегда.
Второй уточняющий вопрос: нужен ли возврат назад. Согласование заявки на скидку, утверждение договора, приём работ, отпуск сотрудника — везде есть шаг, где что-то могут отклонить и отправить обратно. Возврат — верный признак бизнес-процесса. А напоминание менеджеру, автозадача при переходе на стадию, уведомление руководителю о крупной сделке — это роботы, и лезть туда с тяжёлой схемой не надо.
Третий признак — количество участников. Если в цепочке один ответственный, почти наверняка хватит роботов. Если задействованы несколько ролей и порядок между ними важен, нужен маршрут. Логику связывания разных сущностей мы отдельно показывали в статье про робота «Изменить элемент» — часто именно он снимает половину запросов на бизнес-процесс.
Типичные ошибки в обе стороны
Первая ошибка — собирать согласование роботами. Выглядит это так: робот ставит задачу руководителю, дальше стоит второй робот, который через сутки двигает сделку, а решение руководителя приходится ловить через отдельное поле, которое кто-то должен заполнить руками. Через месяц никто не помнит, зачем нужно это поле, и процесс тихо разваливается.
Вторая ошибка — обратная: тяжёлый бизнес-процесс на простое уведомление. Он запускается на каждой сделке, висит в списке запущенных процессов, при любой правке приходится останавливать все экземпляры. Руководитель отдела не может ничего поменять сам и идёт с каждой мелочью к интегратору. Скорость изменений падает в разы, а выигрыша никакого.
Третья ошибка — не тестировать. И роботы, и бизнес-процессы работают тихо и массово: ошибётесь в условии — и через час у вас сотни сделок с неверными данными или лавина писем клиентам. Мы отдельно писали, почему автоматизацию нельзя запускать без теста, и это правило не зависит от выбранного инструмента.
Что ещё влияет на выбор
Первое — тариф. Роботы доступны шире, конструктор бизнес-процессов есть только на старших планах. Если вы спроектировали красивый маршрут с согласованиями, а портал живёт на младшем тарифе, придётся либо доплачивать, либо перекладывать логику на роботы. Этот вопрос лучше выяснить до проектирования, а не после.
Второе — кто будет это поддерживать через полгода. Роботы читаются прямо в канбане: открыл стадию, увидел список действий. Схему бизнес-процесса без описания не поймёт никто, включая того, кто её рисовал. Если у вас нет привычки документировать, а изменения в процессе случаются часто, лишний вес схемы обернётся простоем на каждой правке.
Третье — отладка. Когда что-то пошло не так, по роботу вопрос закрывается за минуту: смотрим, на какой стадии он стоял и с каким условием. По бизнес-процессу приходится разбирать журнал выполнения и понимать, на каком шаге он завис и кого ждёт. Это нормально для сложной логики, но за простое уведомление такой ценой платить не стоит.
Как это выглядит в рабочем проекте
На практике почти всегда получается смесь. Основной путь сделки едет на роботах: они ставят задачи, шлют уведомления, заполняют служебные поля, тянут данные в связанные смарт-процессы. А в местах, где нужно чьё-то решение, включается бизнес-процесс: согласование скидки, утверждение договора, приёмка работ. Это нормальная архитектура, а не компромисс. Плохо становится тогда, когда обе технологии применяют к одной и той же задаче одновременно и они начинают спорить друг с другом за одно поле.
Я всегда начинаю от самого простого. Сначала собираем роботами то, что собирается роботами, смотрим неделю, как это живёт на реальных сделках. Если видим, что логика упирается в развилку и её приходится обходить костылями, — только тогда достаём бизнес-процесс. Обратный порядок обычно заканчивается схемой, которой никто не пользуется.
И последнее. Любая автоматизация должна быть понятна тому, кто с ней работает каждый день, а не только тому, кто её собрал. Если руководитель отдела не может объяснить, что произойдёт со сделкой на этой стадии, — схему надо упрощать. Разбор такой логики и её настройку мы берём на себя в рамках доработок и сопровождения.
Частые вопросы
Что проще настроить самому — робота или бизнес-процесс?
Робота. Он настраивается в канбане без разработчика: условие запуска и действие. Бизнес-процесс требует проектирования маршрута и обычно собирается интегратором.
Можно ли заменить бизнес-процесс набором роботов?
Иногда да, если логика линейная. Но как только появляется согласование с возможностью отклонить и вернуть на доработку, роботы превращаются в костыли из служебных полей, в которых через месяц никто не разберётся.
Бизнес-процессы доступны на всех тарифах Битрикс24?
Нет, конструктор бизнес-процессов есть только на старших тарифах, а роботы доступны шире. Это тоже стоит учитывать при выборе инструмента и при планировании автоматизации.