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