Проектування логіки бізнес-процесів Бітрікс24

Проектування логіки бізнес-процесів Бітрікс24

Бізнес-процеси в Бітрікс24 — одна з тих функцій, які при грамотному застосуванні економлять години щоденної ручної роботи, а при непродуманому впровадженні створюють хаос: завислі екземпляри, сповіщення, що нікуди не доходять, і завдання, які «провалилися» на невизначений крок без індикації причини.

За кілька років проектування БП різного масштабу у нас склалося чітке розуміння: більшість проблем виникають не на етапі реалізації у візуальному дизайнері, а на етапі постановки задачі — коли логіка процесу не зафіксована формально до початку «кліку мишкою».

Архітектура БП у Бітрікс24

Рушій бізнес-процесів у Бітрікс24 заснований на модулі bizproc. Процес описується як граф активностей (CBPActivity) з переходами між ними. Кожен екземпляр процесу зберігається в таблицях b_bp_workflow_instance, b_bp_workflow_state, b_bp_task — саме туди потрібно дивитися при діагностиці завислих процесів.

Активності поділяються на:

• Системні — затримка, умова, паралельна активність, цикл.
• Дії — надсилання сповіщення, створення завдання, зміна поля сутності, виклик REST-методу.
• Користувацькі дії (UDA) — кастомні активності, написані на PHP і зареєстровані через CBPActivity::RegisterActivity().

Важливий нюанс: БП у Бітрікс24 можуть бути прив'язані до лідів, угод, контактів, компаній, завдань, документів живої стрічки та елементів смарт-процесів. У кожного типу сутності — свій контекст змінних і свої доступні дії. Це потрібно враховувати при проектуванні: процес, написаний для угоди, не можна напряму перевикористати для смарт-процесу без адаптації.

Процес проектування

Крок 1. Формалізація процесу в BPMN (або спрощеній нотації).

Перш ніж відкривати дизайнер БП — малюємо блок-схему. Обов'язкові елементи: старт, кінець (їх може бути кілька), розгалуження з умовами, відповідальні за кожен крок, таймери та ескалації. Особлива увага — виключним шляхам: що відбувається, якщо клієнт не відповів 3 дні, якщо відповідальний у відпустці, якщо платіж повернувся з помилкою.

Саме виключні шляхи — головне джерело проблем у реалізованих БП. У дизайнері їх забувають, і процес зависає на очікуванні без жодних сигналів.

Крок 2. Інвентаризація змінних.

У Бітрікс24 у кожного процесу є: змінні процесу (зберігаються лише в межах екземпляра), параметри процесу (вхідні значення при старті) та константи. Крім того, через Document доступні поля самої сутності.

Потрібно заздалегідь визначити: які дані процес читає із сутності, які створює сам, що має записатися назад у поля після завершення.

Крок 3. Визначення тригерів.

Процеси запускаються вручну, за подією (зміна поля, зміна стадії, додавання сутності) або за розкладом (через агенти в модулі bizproc). Від типу тригера залежить архітектура: якщо процес стартує при зміні стадії угоди, потрібно передбачити захист від повторного запуску при поверненні на ту саму стадію.

Крок 4. Проектування сповіщень.

Сповіщення в БП налаштовуються через активність «Сповіщення» з адресацією за роллю (відповідальний, автор, конкретний користувач, група). Типова помилка — сповіщення надходить «відповідальному», але в момент виконання кроку поле «Відповідальний» ще не заповнене. Потрібно явно прописувати ланцюжок адресації для кожного кроку.

Кейс: процес погодження договору

Клієнт — виробнича компанія, 80 користувачів Бітрікс24. Завдання: автоматизувати погодження договору через CRM. Договір прикріплений до угоди як користувацьке поле типу «Файл». Учасники погодження: юрист, фінансовий директор, генеральний директор — послідовно.

Початкова спроба клієнта: три послідовних завдання в БП, кожне — «Затвердити/Відхилити». Проблема: при відхиленні на будь-якому кроці процес просто завершувався без можливості доопрацювання та повторної подачі.

Перероблений варіант включав:

• Цикл «подача → погодження» з можливістю повернення на доопрацювання на будь-якому етапі з коментарем
• Таймер ескалації: якщо юрист не відповів за 2 робочих дні — сповіщення керівникові
• Паралельне сповіщення ініціаторові про поточний статус на кожному кроці
• Запис підсумкового статусу погодження в користувацьке поле угоди для звітності
• Автоматичне створення завдання на юрисконсульта із вкладенням файлу договору

Реалізація зайняла 8 робочих днів з урахуванням тестування на тестовому середовищі та перенесення на продакшн.

Обмеження та підводні камені

Версіонування. Запущені екземпляри процесу продовжують працювати за старою версією шаблону. Якщо процес змінили, але старі екземпляри не завершилися — у системі одночасно працюють два варіанти логіки. Це потрібно враховувати при внесенні змін: іноді доводиться примусово завершувати старі екземпляри.

Продуктивність. Важкі БП з великою кількістю паралельних гілок і REST-викликами можуть створювати навантаження на cron. Якщо агент CBPSchedulerService::OnAgent запускається щохвилини, а активних екземплярів кілька сотень — це помітно. Проектуємо з урахуванням навантаження.

REST-активності. Виклик зовнішніх систем через REST із БП здійснюється через активність «Вихідний вебхук» або через кастомну UDA. Потрібно передбачити обробку помилок: якщо зовнішній сервіс недоступний, процес не повинен зависати назавжди.

Терміни

Проектування одного лінійного процесу (5–8 кроків, без паралельних гілок) — 2–4 дні. Складний процес з розгалуженням, ескалаціями, інтеграціями — 1–3 тижні. До послуги входять: блок-схема погодженого процесу, реалізація в дизайнері БП, документація змінних, тестування та передача.