Что такое бизнес-процесс в Битрикс24

Бизнес-процесс — это описанная схема, по которой документ или заявка проходит через людей и действия от начала до результата. Сотрудник запускает процесс — например, создаёт заявку на оплату счёта, — и дальше система сама ведёт её по маршруту: отправляет на согласование руководителю, ждёт ответа, при отказе возвращает автору, при согласии передаёт в бухгалтерию. Человек не пересылает письма и не бегает по кабинетам. За движение отвечает Битрикс24.

Ключевое слово здесь — маршрут. У процесса есть старт, есть финиш, и между ними — цепочка шагов, часть которых требует решения человека, а часть система делает сама. Согласовать, уведомить, заполнить поле, сгенерировать документ, поставить задачу. Всё это блоки, из которых собирается схема.

И вот чем процесс принципиально отличается от роботов и триггеров. Робот привязан к стадии сделки: попала сделка на стадию — робот выполнил действие и забыл. Триггер ловит событие снаружи и двигает сделку. Оба линейны и живут внутри CRM. Бизнес-процесс — это отдельный инструмент со своим конструктором, где есть ветвления, ожидание ответа от человека, параллельные ветки и таймеры. Если по-простому: роботы автоматизируют движение сделки по воронке, а бизнес-процессы автоматизируют документооборот и согласования, где важно, кто и что решил на каждом шаге.

На практике мы объясняем клиентам так. Нужно «когда сделка дошла до счёта — напиши клиенту письмо»? Это робот. Нужно «счёт на 200 000 сначала согласует руководитель отдела, а если больше — ещё и финдиректор, и только потом он уходит в оплату»? Это бизнес-процесс. Разница — в наличии решений и ветвлений внутри цепочки. Подробнее про первый инструмент мы писали в разборе роботов и триггеров Битрикс24.

Где применяют бизнес-процессы

Бизнес-процесс окупается там, где есть повторяющаяся цепочка «кто-то создал — кто-то согласовал — кто-то исполнил». Как только в задаче появляется слово «согласовать», это почти всегда кандидат на процесс. Вот где мы ставим их чаще всего.

  • Согласование счетов на оплату. Менеджер прикладывает счёт, руководитель подтверждает сумму, бухгалтерия оплачивает. Процесс сам решает, нужна ли виза финдиректора, по порогу суммы.
  • Заявки на отпуск. Сотрудник указывает даты, руководитель согласует, кадры фиксируют. Всё видно, никаких бумажных заявлений, которые теряются на столе.
  • Согласование договоров. Юрист, руководитель, иногда служба безопасности проверяют текст по очереди или параллельно, замечания копятся в карточке процесса.
  • Внутренние заявки. Заявка в ИТ на доступ, заявка на закупку, командировка, служебная записка — всё, что раньше жило в почте и мессенджерах.

Общая черта у всех этих задач одна: раньше они висели в переписке, и никто не мог сказать, на ком сейчас застряло. Процесс делает маршрут прозрачным. В любой момент видно, у кого заявка на согласовании и сколько она там висит. Это уже не просто удобство, а часть системной автоматизации бизнеса, когда рутина перестаёт зависеть от того, вспомнил сотрудник переслать письмо или нет.

Отдельно отметим: не всё подряд надо загонять в процессы. Если задача разовая или маршрут каждый раз новый, проще поставить обычную задачу или вести её в задачах и проектах. Бизнес-процесс оправдан, когда цепочка повторяется десятки раз в месяц и её шаги стабильны.

Конструктор БП: последовательный и со статусами

В Битрикс24 два вида бизнес-процессов, и выбор между ними — первое решение, которое приходится принять. Они устроены по-разному, и путать их не стоит.

Последовательный процесс

Схема идёт сверху вниз: старт, потом шаг за шагом действия, потом финиш. Заявка входит в процесс и движется по цепочке строго по порядку, пока не дойдёт до конца. Это классика для согласований, где шаги выполняются один за другим: сначала согласовал руководитель, потом бухгалтерия, потом уведомили автора. Каждый элемент отработал — управление ушло дальше. Последовательный процесс проще собирать и проще держать в голове, поэтому мы начинаем внедрение почти всегда с него.

Процесс со статусами

Здесь другая логика — ближе к канбану. У элемента есть набор статусов (например, «Черновик», «На согласовании», «Отклонён», «Готов»), и на каждом статусе доступны свои действия и переходы. Элемент не идёт по прямой, а гуляет между состояниями и может возвращаться назад. Такой процесс удобен для длинных живых заявок, которые тянутся неделями и ходят на доработку по нескольку раз: договор с правками, крупная закупка, проект.

На практике правило простое. Короткая цепочка с понятным порядком шагов — последовательный процесс. Долгая заявка, которая живёт неделями и катается на доработку — со статусами. В 8 из 10 согласований на старте хватает последовательного: он быстрее собирается и его легче объяснить сотрудникам.

Не начинайте с процесса со статусами только потому, что он «мощнее». Первый бизнес-процесс должен быть максимально простым: один старт, два-три согласующих, финиш. Сложную схему со статусами и ветвлениями достают, когда простая уже работает и людям стало её мало. — практика ooobs

Типовые процессы для компании

Чтобы не гадать, с чего начинать, вот процессы, которые дают эффект почти в любой компании и окупаются первыми. Мы обычно предлагаем стартовать именно с них.

  1. Согласование счёта на оплату. Самый частый и самый благодарный процесс. Убирает бесконечные «а ты счёт подписал?» и даёт руководителю контроль над расходами без ручного перебора почты.
  2. Заявка на отпуск и отгул. Сотрудник заводит заявку, руководитель жмёт «Согласовать», кадры видят готовый график. Никаких бумажных бланков и потерянных заявлений.
  3. Согласование договора. Договор проходит юриста и руководителя, замечания фиксируются прямо в процессе, версии не теряются в почте.
  4. Заявка на закупку. Инициатор описывает потребность, руководитель подтверждает бюджет, снабжение исполняет. Видно, кто заказал и на какую сумму.
  5. Оформление нового сотрудника. Один запуск процесса разом ставит задачи кадрам, ИТ (завести учётки и технику) и руководителю (подготовить план адаптации).

Заметьте общее: все пять — это регулярная рутина, которая раньше жила в голове у людей и в переписке. Как только она переезжает в процесс, у неё появляется история, сроки и ответственные. И руководитель наконец видит, где именно всё тормозит.

Дизайнер, действия и условия

Схему процесса рисуют в визуальном дизайнере. Это поле, на которое перетаскиваются блоки и соединяются в цепочку — примерно как рисование блок-схемы. Открыли шаблон процесса, добавили блок, настроили, соединили со следующим. Кода нет, всё мышкой.

Блоки бывают трёх типов, и в них вся суть. Разберём по порядку.

  • Действия — то, что процесс делает сам: поставить задачу, отправить письмо или уведомление, изменить поле документа, создать элемент в CRM, сгенерировать документ по шаблону.
  • Согласования — блоки с участием человека: «Утверждение» (согласующий жмёт «Да/Нет»), «Ознакомление» (просто подтвердить, что прочитал), «Запрос доп. информации» (вернуть автору за уточнением).
  • Условия и развилки — блок «Условие» проверяет данные (сумма больше 100 000? отдел — продажи?) и направляет процесс по одной из веток. Именно это отличает процесс от робота.

Развилка — сердце любого серьёзного согласования. Пример из жизни: счёт до 50 000 согласует только руководитель отдела; от 50 000 до 300 000 добавляется финдиректор; выше — генеральный. Условие смотрит на сумму и само выбирает, к кому отправить заявку. Один процесс закрывает все случаи, сотруднику не надо помнить регламент.

Ещё пара блоков, без которых мы не собираем ни один процесс. Пауза и таймер — чтобы согласующий не мог держать заявку вечно: не ответил за день — система напоминает, за два — эскалирует его руководителю. Параллельное выполнение — когда договор одновременно уходит юристу и безопаснику, а дальше процесс идёт только после того, как ответили оба. Это ускоряет согласование в разы против последовательной пересылки.

Настройка блока согласования — место, где чаще всего ошибаются. Там важно правильно указать не только кто согласует, но и что делать при отказе (вернуть автору или закрыть заявку) и сколько ждать ответа. Пропустишь эти настройки — получишь процесс, который зависает на первом же «нет».

Частые ошибки при настройке процессов

Грабли повторяются от проекта к проекту. Вот те, на которые мы наступать не советуем.

Переусложнили схему

Главная беда. Компания рисует процесс на сорок блоков с десятком развилок, «чтобы учесть все случаи». В итоге его никто не понимает, поддерживать невозможно, а при первом же изменении регламента схему приходится переделывать целиком. Мы делаем наоборот: собираем минимальную рабочую версию на пять-семь блоков, запускаем, а редкие исключения обрабатываем вручную. Усложнять будем, только если жизнь докажет, что это правда нужно.

Нет ответственных на шагах

Блок согласования настроен «на отдел» или вообще ни на кого. Задача уходит в пустоту, её никто не берёт, заявка зависает — а инициатор уверен, что всё движется. На каждом шаге согласования должен быть конкретный человек или чёткая роль. И обязательно таймер: не ответил за срок — напоминание, потом эскалация выше.

Нет ветки на отказ

Процесс красиво описывает путь, когда все согласовали. А что делать при «нет» — забыли. Согласующий отклоняет заявку, и процесс просто встаёт или, хуже, идёт дальше как ни в чём не бывало. Всегда прорисовывайте ветку отказа: вернуть автору с комментарием, дать переоформить, закрыть.

Запуск без теста на живых людях

Схема собрана, выглядит правильно — включили на всю компанию. А в понедельник выясняется, что согласующий в отпуске и заявки копятся, или уведомления валятся не тем. Любой процесс сначала прогоняем на паре реальных заявок с реальными участниками. Полчаса теста экономят неделю разбора жалоб.

Процесс вместо простой задачи

Обратная крайность — тащить в бизнес-процесс то, что процессом не является. Разовое поручение или задача с плавающим маршрутом живёт удобнее в обычных задачах и проектах. Процесс оправдан только для повторяющихся цепочек со стабильными шагами.

Робот или бизнес-процесс: когда что

Чтобы не держать выбор в голове, вот таблица-шпаргалка. Держите её под рукой в момент, когда решаете, каким инструментом закрыть задачу.

Критерий Робот (и триггер) Бизнес-процесс
Что автоматизирует Движение сделки по воронке продаж Согласования и документооборот
Где живёт Внутри CRM, на стадиях сделки Отдельный конструктор процессов
Ветвления «если/иначе» Нет (только простое условие запуска) Да, полноценные развилки
Участие человека Действие выполняется само Шаги согласования ждут решения людей
Параллельные ветки Нет Да (несколько согласующих сразу)
Сложность настройки Низкая, за минуты мышкой Средняя и выше, нужна схема
Типовая задача Задача менеджеру, письмо клиенту Согласование счёта, договора, отпуска

Простое правило по итогу таблицы: всё про сделку и воронку — роботами, всё про согласования и документы — процессами. Если в задаче есть слово «согласовать» и участвуют несколько человек с решениями — это территория бизнес-процессов.

Где нужен внедренец, а где справитесь сами

Хорошая новость: первый рабочий процесс реально собрать своими силами. Плохая — не всё так просто, и на сложных схемах без опыта легко закопаться.

Сами, без внедренца, обычно делается:

  • Последовательное согласование счёта или отпуска с одним-двумя согласующими.
  • Простая развилка по сумме или отделу.
  • Уведомления участникам и постановка задач внутри процесса.
  • Заявки на закупку и служебные записки по понятному маршруту.

Внедренец или разработчик нужен, когда:

  • Процесс обменивается данными с 1С или сайтом через API — например, тянет остаток на складе или создаёт документ в учётной системе.
  • Нужна генерация договоров и актов по шаблону с автозаполнением из карточки.
  • Схема охватывает несколько отделов и сущностей сразу, с общей логикой и сложными ветвлениями.
  • Процессов много, они связаны между собой, и нужен человек, который держит всю картину и правит её при смене регламентов.

Мы советуем такой порядок: соберите один простой процесс руками, посмотрите, как он приживается у сотрудников, и только под конкретную нехватку зовите специалиста. Это часть здравого внедрения Битрикс24 — сначала быстрые победы на стандартных возможностях, потом точечная доработка там, где она окупается. Если пока не разобрались, что вообще умеет система и с чего начать, посмотрите базовый разбор что такое Битрикс24. А когда дойдёт до сложных схем с интеграциями — эту часть логичнее отдать команде, которая делает такое каждый день.