Вернуться к статьям Бизнес-процесс в Битрикс24 — это шаблон маршрута для элемента CRM или смарт-процесса: он проверяет данные, назначает участников, запрашивает решения и фиксирует результат. Чтобы создать процесс, сначала описывают регламент, роли и исключения, затем выбирают сущность, собирают действия в дизайнере и тестируют каждую ветку.
Коротко: бизнес-процесс нужен, когда заявка проходит через несколько ролей и результат зависит от условий. Для одного действия на стадии чаще хватает робота, для разового поручения — задачи, а для нового объекта учёта — смарт-процесса.
Что такое бизнес-процесс
Бизнес-процесс автоматизирует последовательность действий вокруг карточки. Он может поставить задание, запросить утверждение, отправить уведомление, проверить условие, изменить данные и завершить маршрут заданным результатом.
Битрикс24 поддерживает последовательные процессы и процессы со статусами. В первом действия идут по порядку. Второй объединяет несколько последовательных маршрутов и переходы между состояниями, поэтому подходит для долгой работы с возвратами. Разницу объясняет официальная справка о типах бизнес-процессов.
Шаблон собирают в дизайнере: задают действия, условия и участников. Дизайнер доступен не на всех тарифах, поэтому перед подготовкой ТЗ нужно проверить актуальную таблицу возможностей Битрикс24 для России.
Согласование внутри Битрикс24 фиксирует решение участника, но само по себе не создаёт юридически значимую электронную подпись. Требования к подписанию документов и хранению доказательств компания согласует с юристами отдельно.
Если вместе с маршрутом надо настроить CRM-сущности, поля, структуру и права, работу обычно включают во внедрение Битрикс24.
Чем бизнес-процесс отличается от робота, задачи и смарт-процесса
Инструмент выбирают по механике работы. Карточка хранит объект, робот реагирует на стадию, задача фиксирует поручение, а бизнес-процесс ведёт элемент по маршруту между ролями.
| Инструмент | Что делает | Когда выбирать |
|---|---|---|
| Бизнес-процесс | Выполняет маршрут с условиями, заданиями, решениями и возвратами | Несколько участников, ветки согласования, исключения |
| Робот | Выполняет действие при попадании элемента на стадию | Уведомить, создать задачу, изменить поле |
| Триггер | Отслеживает событие и переводит элемент на стадию | Сменить стадию после звонка, письма или другого события |
| Задача | Назначает разовую работу сотруднику | Не нужен формальный маршрут и правила переходов |
| Смарт-процесс | Создаёт отдельный тип CRM-элемента с полями, стадиями и правами | Нужен реестр закупок, договоров, заявок или других объектов |
| Приложение | Добавляет специальный интерфейс или логику | Штатных действий и сущностей недостаточно |
Роботы и триггеры работают со стадиями; их механизм описан в официальной справке. Смарт-процесс — сущность, а бизнес-процесс — исполняемый маршрут. В смарт-процессе можно использовать стадии, роботов и бизнес-процессы. Детали есть в статье о смарт-процессах и справке Битрикс24.
Если штатных механизмов не хватает для интеграции или специального экрана, задачу относят к разработке приложений для Битрикс24, а не усложняют шаблон десятками обходных веток.
Какие процессы стоит автоматизировать
Подходящий процесс повторяется, имеет понятное начало, участников, основные исключения и проверяемый результат.
Типовые кандидаты: закупки и оплаты, запросы в ИТ и кадровую службу, согласование условий сделки, проверка обязательных полей, передача обращения между отделами. Автоматизация полезна, если сотрудники регулярно выясняют, у кого задержалась карточка, или собирают решения в чатах.
Единичный конфликт, постоянно меняющийся порядок работы и маршрут без владельца лучше оставить вне конструктора. Сначала отделы договариваются о правилах. Иначе автоматизация ускорит движение по неверному регламенту.
Как описать вход, выход, роли и исключения
До настройки шаблона нужно зафиксировать, с какого события начинается маршрут, какие данные получает согласующий, кто принимает каждое решение и чем завершается процесс.
| Блок | Что определить | Пример для закупки |
|---|---|---|
| Запуск | Кто и когда начинает процесс | Сотрудник отправил заявку |
| Объект | Где хранится заявка | Смарт-процесс «Заявки на закупку» |
| Вход | Какие данные нужны | Предмет, сумма, обоснование, материалы |
| Роли | Кто создаёт, согласует, контролирует | Автор, руководитель, финансовый согласующий |
| Условие | От чего зависит ветка | Нужно ли второе согласование |
| Исключение | Что делать при проблеме | Нет поля, участника или решения в срок |
| Выход | Как выглядит результат | Статус, комментарий, ссылка на следующий объект |
В карточке должно хватать данных для решения без переписки. Участников определяют по ролям, а исключения — как действия: «не запускать без суммы», «передать диспетчеру, если руководитель не определён».
Как выбрать сущность и инструмент процесса
Сначала выбирают карточку, в которой будет жить заявка, затем строят маршрут вокруг неё. В CRM шаблон привязывают к конкретной сущности или смарт-процессу; настраивать его может администратор либо сотрудник с соответствующим правом. Это следует из справки о параметрах шаблона.
Для согласования скидки объектом может остаться сделка. Для закупочной заявки удобнее отдельный смарт-процесс: у неё свои поля, статусы, права и участники. Перед выбором ответьте на четыре вопроса:
- Нужен ли отдельный реестр заявок?
- Требуются ли собственные поля, права и стадии?
- Нужны ли связи со сделкой, компанией или задачей?
- Должна ли история решения храниться в одной карточке?
Отдельный реестр и собственная карточка указывают на смарт-процесс. Если нужный объект уже есть в CRM, создавать дубль не стоит.
Как собрать маршрут согласования в Битрикс24
Маршрут собирают от минимального рабочего пути к исключениям: сначала проверка данных, назначение участника, решение и итог, затем возвраты, дополнительное согласование и просрочка.
Проектный пример согласования заявки на закупку
Названия полей, роли, условия и сроки определяет регламент конкретной компании. Это проектный пример, а не готовая универсальная настройка.
- Сотрудник создаёт заявку и указывает предмет закупки, сумму, обоснование, подразделение, поставщика, материалы, требуемую дату и автора.
- Процесс проверяет обязательные поля. При ошибке заявка остаётся у автора с перечнем недостающих данных.
- По структуре компании определяется руководитель автора. Если участник не найден, заявка идёт диспетчеру или возвращается автору.
- Руководитель получает задание со сроком из регламента.
- При отказе он оставляет обязательный комментарий; заявка получает статус «Возвращена автору».
- Автор исправляет данные и повторно подаёт заявку по утверждённому правилу.
- После одобрения процесс проверяет условие второго согласования.
- Если условие выполнено, отдельное задание получает финансовый согласующий; иначе заявка переходит в итоговый статус.
- Второй участник утверждает заявку, отклоняет её с комментарием или возвращает автору.
- Процесс фиксирует статус, комментарии и ссылку на связанный документ, задачу или другой результат.
- Если решения нет в срок, отдельная ветка помечает просрочку и передаёт заявку ответственному за эскалацию.
Действие утверждения поддерживает ветки «утверждено» и «не утверждено», варианты решения несколькими участниками, комментарий и срок. Настройки перечислены в справке о заданиях бизнес-процесса.
Как настроить условия, сроки и возвраты
Условие должно опираться на поля карточки и отвечать на один вопрос. Сложное правило лучше разделить на несколько проверок, чтобы владелец процесса мог объяснить каждую ветку.
Параметры указывают при запуске и затем не меняют. Переменные меняются во время выполнения, а константы сохраняют заданное значение в рамках запуска. Шаблон можно запускать вручную или автоматически; детали есть в справке о параметрах.
Срок в действии утверждения не равен готовой эскалации: без решения действие переходит по отрицательной ветке. Напоминание, замена согласующего и передача заявки руководителю требуют отдельных действий и условий. Конкретные сроки и полномочия задаёт регламент; ограничение действия по сроку подтверждает официальная справка.
Как тестировать ветки бизнес-процесса
Готовность проверяют на тестовых элементах по заранее записанным ожиданиям. Одного успешного запуска недостаточно: нужны штатный путь, отказ, просрочка и ошибка данных.
| Сценарий | Условие | Ожидаемый результат |
|---|---|---|
| Штатный путь | Поля заполнены, второй участник не нужен | Заявка согласована |
| Дополнительная ветка | Выполнено условие второго согласования | Создано второе задание |
| Отказ | Участник отказал с комментарием | Заявка вернулась автору |
| Повторная подача | Автор исправил данные | Начался новый цикл |
| Просрочка | Решения нет в срок | Сработала ветка эскалации |
| Ошибка данных | Нет поля или согласующего | Маршрут остановлен с объяснением |
Отдельно проверяют права и способы запуска. Незаполненные константы блокируют ручной запуск. Автозапуск не срабатывает для CRM-элементов, созданных импортом CSV/XLS или другим бизнес-процессом. Ограничения описаны в справке о ручном запуске и автозапуске.
Как версионировать шаблон бизнес-процесса
Правка шаблона действует только для новых запусков. Уже работающие экземпляры продолжают старый маршрут, поэтому владелец должен заранее определить переходный порядок. Правило подтверждает официальная справка.
В журнале версий фиксируют дату, автора, причину и результаты тестов. Перед изменением решают, как завершать старые заявки.
Шаблон можно экспортировать в .bpt и импортировать в пустой шаблон того же типа. Импорт может создать поля исходной сущности, поэтому после переноса проверяют поля, роли и права. Ограничения приведены в справке по экспорту и импорту.
Пример ТЗ на процесс согласования
ТЗ описывает правила, данные и критерии приёмки, а не последовательность кликов в дизайнере.
- Цель: провести закупочную заявку от автора к руководителю и, по условию регламента, ко второму согласующему.
- Участники: автор, руководитель, второй согласующий, ответственный за эскалацию, администратор.
- Поля: предмет, сумма, обоснование, подразделение, автор и материалы; дополнительный состав утверждает компания.
- Логика: проверить данные, определить участников, запросить решения, обработать отказ, возврат и просрочку, зафиксировать итог.
- Права: каждый участник видит данные, необходимые для своей роли; изменение закрытых полей ограничено.
- Приёмка: пройдены штатная и дополнительная ветки, отказ, повторная подача, просрочка и ошибка данных; проверены права и уведомления.
Ошибки и ограничения бизнес-процессов
Главные сбои возникают на стыке регламента, прав и данных. Их дешевле убрать до запуска, чем разбирать в работающем маршруте.
- Шаблон собирают без регламента. Сначала утверждают роли, поля, статусы и исключения.
- Разные заявки помещают в одну карточку. Закупка, доступ и договор требуют разных данных и полномочий.
- Согласующего выбирают без правила. Роль задают через структуру или направляют заявку диспетчеру.
- Отказ не требует комментария. Автор не понимает, что исправлять.
- Просрочку считают эскалацией. Напоминание и передача руководителю проектируются отдельно.
- Шаблон меняют без переходного плана. Текущие запуски остаются на старой версии.
- Журнал отладки считают архивом. Он включается отдельно для шаблона и хранит записи семь дней; это средство диагностики, а не постоянный аудит. См. справку о журнале.
- Согласование приравнивают к электронной подписи. Юридический режим документов проверяют отдельно.
- Тариф не проверяют до ТЗ. Доступность дизайнера и связанных инструментов зависит от текущего тарифа.
Кому подходит и не подходит бизнес-процесс
Бизнес-процесс подходит для повторяемого маршрута с владельцем регламента и понятными полномочиями. Участники получают единый реестр, статус и историю решения.
Инструмент не подходит, пока отделы спорят о правилах, а каждое обращение требует отдельного обсуждения. Сначала настраивают регламент, карточки и права; иногда достаточно робота или задачи.
Чек-лист создания бизнес-процесса
Проверьте сущность, регламент, роли, данные, права и все ветки.
- [ ] Выбрана сущность CRM или смарт-процесс.
- [ ] Назначен владелец регламента.
- [ ] Описаны запуск, результат и статусы.
- [ ] Утверждены обязательные поля.
- [ ] Согласующему хватает данных для решения.
- [ ] Участники определяются по ролям.
- [ ] Настроены утверждение, отказ и возврат.
- [ ] Для отказа обязателен комментарий.
- [ ] Просрочка отделена от явного отказа.
- [ ] Проверены права участников.
- [ ] Протестированы все ветки и способы запуска.
- [ ] Есть журнал версий и переходный порядок.
- [ ] Возможности сверены с текущим тарифом.
FAQ о бизнес-процессах в Битрикс24
FAQ отвечает на практические вопросы о процессе.
- Где создать бизнес-процесс в Битрикс24?
Шаблон создают в настройках выбранной сущности CRM или смарт-процесса при наличии соответствующих прав. Доступность дизайнера зависит от тарифа портала.
- Чем бизнес-процесс отличается от робота?
Робот выполняет действие на стадии. Бизнес-процесс проводит карточку по маршруту с условиями, заданиями и ветками решений.
- Можно ли запустить процесс вручную?
Да, доступный шаблон запускают из карточки CRM или смарт-процесса. Если обязательные константы не заполнены, сначала нужно указать их значения.
- Что происходит после изменения шаблона?
Текущие экземпляры продолжают старую версию. Изменённый шаблон применяется к новым запускам.
- Как тестировать бизнес-процесс?
Создайте тестовые элементы и проверьте штатный путь, дополнительную ветку, отказ, возврат, просрочку и ошибку данных. Права и уведомления проверяйте под ролями реальных участников.
- Заменяет ли согласование электронную подпись?
Нет. Процесс фиксирует маршрут и решения в Битрикс24, но сам по себе не создаёт юридически значимую электронную подпись.
Вывод: как создать рабочий бизнес-процесс
Рабочий бизнес-процесс начинается с регламента, выбранной сущности и проверяемых правил. После сборки шаблона команда тестирует все ветки, сверяет права и фиксирует версию.
Если маршрут уже описан, но его нужно перенести в CRM, начните с аудита карточек, ролей и исключений. Для штатной настройки подходит внедрение Битрикс24, для логики вне возможностей конструктора — разработка приложений для Битрикс24.