бизнес-процессы (бп) в битрикс24: как настроить
Бизнес-процессы в Битрикс24 — это более сложные сценарии, чем роботы. Роботы делают одно действие в один момент, а БП — цепочку действий с ветвлениями, согласованиями и параллельными потоками. Ниже — когда БП реально нужны, а когда достаточно роботов, и как настроить самые частые сценарии.
бизнес-процесс vs робот: в чём разница
Робот — простое действие в момент: «поставить задачу», «отправить письмо», «изменить статус». БП — сложная схема: «согласовать с руководителем → если да → создать документ → отправить в бухгалтерию → уведомить менеджера → если нет → вернуть на доработку». Правило: если можно решить одним роботом — используйте робот. Если нужны условные ветвления и согласования — берите БП. Смешивать (робот запускает БП) — можно, часто удобно.
когда бизнес-процессы реально нужны
БП оправданы там, где есть многоступенчатое согласование или несколько ответственных: согласование договоров с юристом и директором; заявка на отпуск с согласованием у руководителя и HR; выставление счёта с проверкой у главбуха; согласование скидки свыше определённого процента; закупка с одобрением по бюджету. Общий признак: 3+ участников, ветвления «да/нет», нужна история согласований для аудита. Если процесс линейный и участник один — БП избыточен. На моих проектах внедрение первого согласования занимает один рабочий день вместе с тестами, а окупается уже на второй неделе — за счёт того, что договоры перестают лежать без движения по три дня.
где запускаются бп и как создать первый из шаблона
Бизнес-процессы в Битрикс24 живут не только в CRM. Запускать их можно для элементов CRM — лидов, сделок, контактов, компаний; для записей в живой ленте — это классические согласования «выдать пропуск», «согласовать документ»; для файлов на диске; и для универсальных списков — справочников, которые вы создаёте сами (реестр договоров, заявки на закупку). Список — самый недооценённый вариант: любая внутренняя заявка, для которой сейчас используют почту или чат, укладывается в связку «список + БП поверх него».
Создание по шагам: откройте раздел с шаблонами бизнес-процессов (для CRM — настройки CRM → роботы и бизнес-процессы, для списков — настройки конкретного списка), нажмите «Добавить шаблон», выберите тип — последовательный бизнес-процесс или процесс со статусами. Последовательный подходит для цепочек «запустился — прошёл шаги — завершился», статусный — для документов с жизненным циклом вроде «черновик → на согласовании → утверждён → расторгнут».
Дальше открывается визуальный конструктор (дизайнер БП): слева — палитра действий, в центре — схема. Перетаскиваете блоки: «Утверждение документа», «Уведомление», «Изменение элемента», условия «если/иначе», параллельное выполнение веток. У шаблона есть параметры — например, сумма договора или ФИО согласующего, — которые запрашиваются при запуске и подставляются в поля действий. Первый рабочий БП из готового шаблона собирается за 20–30 минут, без программирования.
тарифы, коробка и предел «без кода»
Важный тарифный нюанс: бизнес-процессы доступны не на всех тарифах облака — на младших их просто нет, и это частая причина, почему «у знакомого работает, а у нас кнопки нет». Перед проектированием процессов проверьте свой тариф; если БП нужны, а тариф младший — считайте апгрейд в бюджете автоматизации, я разбирал это в статье про выбор тарифа облака.
В коробочной версии конструктор тот же, но появляется козырь — вставка собственного кода прямо в шаблон БП: разработчик может обратиться к внешней системе, сделать расчёт, которого нет в стандартных действиях, или интегрировать процесс с 1С. В облаке предел «без кода» обходят через вебхуки и действие «REST-команда» — сложнее, но большинство задач решаемо.
Отдельно про смарт-процессы: если ваш сценарий — это по сути отдельная сущность со своей воронкой (закупка, рекламация, тендер), сначала посмотрите на смарт-процессы с роботами, а не на классический БП. Разница в пороге входа: роботов в смарт-процессе настроит администратор, классический БП со сложными ветками уже требует человека, который умеет читать схему.
запуск, журнал и отладка
Запускается БП тремя способами: автоматически при добавлении или изменении элемента (создали сделку — процесс стартовал сам), вручную кнопкой из карточки, или из робота — когда простая автоматизация в воронке передаёт эстафету сложной цепочке согласования. Про сами роботы и их триггеры писал отдельно в разборе роботов и триггеров — связка «робот запускает БП» закрывает большинство реальных схем.
Участники получают задания процесса — они видны в отдельном счётчике, и это первое, что стоит показать сотрудникам при запуске: согласование не потеряется в потоке чатов, оно висит как задание, пока человек не нажмёт «утвердить» или «отклонить». У каждого запущенного процесса есть журнал выполнения — по нему видно, на каком шаге и на ком процесс стоит. Это главный инструмент отладки: «договор завис» почти всегда означает «задание висит на согласующем, который в отпуске», а не ошибку схемы.
Перед раскаткой прогоните процесс минимум трижды: на положительном сценарии, на отказе с доработкой и на «согласующий молчит». Третий сценарий — самый важный: без правила эскалации по таймауту любой БП рано или поздно встанет. И заведите привычку раз в месяц смотреть список активных процессов: зависшие экземпляры копятся незаметно и портят статистику согласований.
Последний штрих — права: создавать и изменять шаблоны бизнес-процессов должен только администратор портала или выделенный ответственный за автоматизацию. На аудитах регулярно вижу портал, где шаблоны правили четыре разных человека в разные годы — в итоге никто не помнит, почему схема устроена именно так, и трогать её боятся. Один владелец у автоматизации — такое же правило гигиены, как разграничение доступа к сделкам.
типовой БП: согласование договора
Схема: менеджер → юрист → директор → менеджер. Как настроить: 1) триггер запуска — при переходе сделки в статус «Договор» или ручной кнопкой. 2) Шаг 1: задача юристу «согласовать договор» с прикреплённым файлом. 3) Ответ юриста: «согласовано» или «на доработку с комментариями». 4) Если «на доработку» — задача менеджеру исправить, потом опять юристу. 5) Если «согласовано» — задача директору «подписать». 6) После подписания — сделка автоматически в «Ждём оплату», менеджеру задача отправить клиенту. Вся история согласований — в карточке сделки.
типовой БП: заявка на отпуск
Схема: сотрудник → руководитель → HR → бухгалтерия. Как настроить: сотрудник заполняет форму (даты, тип отпуска) → автоматически задача руководителю согласовать → если согласовано, задача HR внести в календарь → HR прикрепляет приказ, задача бухгалтерии рассчитать отпускные → бухгалтерия помечает «оплачено», сотрудник получает уведомление. Плюсы: не бегают с бумажками, вся история в системе, легко посчитать статистику.
типовой БП: согласование счёта
Актуально для B2B с крупными счетами. Схема: менеджер запрашивает счёт → бухгалтер выставляет → если сумма >X → директор согласовывает → счёт отправляется клиенту. Если сумма меньше — сразу к клиенту без директора. Ветвление по сумме экономит время директора на мелких счетах и держит контроль над крупными. Все счета — в истории сделки, отдельно не хранятся.
типовой БП: согласование скидки
Проблема: менеджеры дают скидки, чтобы «дожать» клиента, а руководитель узнаёт об этом из отчёта в конце месяца. Решение: любая скидка >5% (или своя граница) — через согласование. Менеджер запрашивает скидку в форме → задача руководителю «согласовать скидку X% на сделку Y» → руководитель либо утверждает, либо предлагает свою границу. Только после согласования менеджер отправляет клиенту финальное КП. Дисциплинирует и убирает «серые» скидки.
типичные ошибки при настройке БП
Слишком длинные цепочки согласования. 7 шагов через 5 ответственных = процесс встанет на первом же отсутствующем сотруднике. Максимум 3–4 согласующих для типового процесса.
Нет альтернативных путей. Что делать, если согласующий в отпуске? Обязательно правило замещения: если через N часов нет ответа — задача переходит дублёру.
Настроили БП там, где хватало робота. Простое уведомление в чат — это робот на 1 минуту настройки, а не БП на неделю проектирования.
Не тестировали на реальных сценариях. Запустили в бой, поймали 3 бага за первую неделю. Всегда прогоняйте на тестовых сделках до раскатки.