Бизнес-процессы Битрикс24: кого бы вы взяли аналитиком

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

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

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

Запускаться процесс может вручную, при создании документа или при его изменении, и последний вариант самый коварный: процесс меняет поле, изменение запускает другой процесс, а тот меняет ещё одно поле. Цепочка растёт, и по ней уже трудно понять, кто инициатор.

Почему бизнес-процессы конфликтуют

Когда в проекте около 30 процессов, конфликты почти неизбежны. Самые частые причины:

• Два процесса меняют одно и то же поле, и результат зависит от того, кто успел последним.
• Процесс ждёт условия, которое другой процесс уже никогда не выполнит.
• Автозапуск при изменении документа создаёт цикл, и система его прерывает.
• Процесс запущен на старой версии шаблона, а логика уже поменялась.
• Права: процесс выполняется от имени сотрудника, у которого нет доступа к нужным данным.

Журнал и отладка процессов

У каждого запущенного процесса есть журнал: какие шаги выполнены, где он остановился, какие значения были у полей. Для поиска конфликта это главный инструмент, но смотреть его нужно на конкретных проблемных документах, а не наугад.

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

Временные блоки записи в журнал с текущими значениями полей — примитивный, но надёжный способ понять, в какой момент данные меняются не так, как ожидалось, и какой процесс в этом виноват.

Разбор двух ответов кандидатов

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

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

Второй подход хорош в другой ситуации: процесс один, сломался вчера и нужно срочно восстановить работу. Тогда сначала чинят, потом разбираются. Хороший аналитик умеет и то, и другое, но понимает, когда что применять.

На портале с 30 процессами такая инвентаризация занимает 2–3 дня. Кажется долго, но дальнейшие правки после неё идут в разы быстрее.

Как искать сбой в бизнес-процессах Битрикс24

Порядок, которым пользуюсь я, когда процессов много и они мешают друг другу:

• Выгрузить список всех шаблонов процессов и роботов по каждой сущности.
• Для каждого записать: когда запускается, какие поля читает и какие меняет.
• Найти пересечения: одно поле меняют несколько процессов, или один процесс запускает другой.
• Посмотреть журнал выполнения у проблемных документов: на каком шаге процесс остановился.
• Сверить схему с тем, как отдел реально работает сейчас, а не год назад.
• Удалить или объединить процессы, которые дублируют друг друга.

Как не допустить конфликтов в будущем

Простое правило: у каждого поля, которое меняют процессы, должен быть один владелец. Если два процесса хотят менять одно поле, их логику надо объединять.

Второе правило — документация. Короткая таблица «процесс — триггер — что меняет — кто владелец» экономит недели на разборе. Её стоит обновлять при каждом изменении шаблона.

Третье — тестовый портал или хотя бы тестовая воронка. Новые процессы сначала гоняются там, а не на рабочих сделках.

Что спрашивать на собеседовании аналитика Битрикс24

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

Кроме кейса, я бы проверял знание платформы и умение говорить с бизнесом.

• Чем роботы отличаются от бизнес-процессов и когда что выбирать.
• Как устроены смарт-процессы и зачем они нужны.
• Как бы вы описали процесс продаж отдела, который ничего не документировал.
• Как проверить, что процесс работает, до запуска на всех сотрудников.
• Что делать, если стандартных возможностей не хватает: REST API, приложения, доработка.

Аналитик Битрикс24: какие навыки важнее

Знание конструктора процессов осваивается за месяц. Умение увидеть, как процессы связаны с работой людей, приходит годами.

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

Когда бизнес-процессов становится слишком много

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

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

Если логика сложная и постоянно растёт, стоит подумать о доработке через REST API или приложение, потому что конструктор удобен, только пока процесс помещается на один экран.

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