Большинство компаний хранят описание своих процессов сразу в нескольких местах одновременно: документ с регламентом, обсуждение в чате, задача в таск-менеджере, таблица со сроками и устные договорённости. Пока процесс простой и команда небольшая, это работает. Как только появляются развилки, несколько ролей и внешние участники — процесс начинает держаться исключительно на ручной координации.
Одна из российских команд описала, как они решили эту проблему, выстроив операционный контур на базе четырёх слоёв: BPMN-дизайнер моделей, движок Camunda, шаблоны задач и переменные процесса. Ключевая идея — процесс перестаёт быть картинкой или документом и становится исполняемым маршрутом, где каждый шаг имеет входной контекст, ожидаемый результат, форму фиксации и правило перехода к следующему шагу.
| Слой архитектуры | Инструмент | Зона ответственности |
|---|---|---|
| BPMN-дизайнер моделей | Собственный дизайнер | Проектирование маршрута, свойства диаграммы, стартовые переменные |
| Исполнение маршрута | Camunda | Запуск экземпляра, переходы между шагами, обработка BPMN-логики |
| Шаблоны задач | Внутренний слой | Заголовок, описание, участники, сроки, чек-листы, анкеты каждого шага |
| Рабочий интерфейс | Битрикс24 | Интерфейс для людей: просмотр и выполнение задач, заполнение анкет |
BPMN (Business Process Model and Notation) — это стандарт графического описания бизнес-процессов, который используется как в визуальном проектировании, так и в качестве машиночитаемого формата. Camunda — open-source платформа для исполнения BPMN-процессов: она запускает экземпляры, обрабатывает переходы между шагами и управляет логикой развилок. Битрикс24 в этой архитектуре остаётся рабочим интерфейсом для людей — именно там сотрудники видят задачи и заполняют анкеты.
Каждый BPMN-шаг имеет собственный шаблон задачи с исполнителями, чек-листами, анкетами и переменными — общего шаблона на весь процесс нет.
Одно из ключевых разделений, которое команде пришлось объяснять пользователям, — разница между моделью процесса и его экземпляром. Диаграмма процесса — объект проектирования: бизнес-аналитик меняет схему, владелец процесса согласует этапы. Экземпляр процесса — объект исполнения: когда HR запускает процесс для конкретного нового сотрудника, появляется отдельный экземпляр со своими стартовыми данными, задачами и историей прохождения. Конкретная задача в Битрикс24 при этом прямо соотносится с конкретным шагом конкретного экземпляра — это уже не просто поручение, а состояние процесса на карте маршрута.
У каждого исполняемого BPMN-шага свой шаблон задачи. В процессе «Приём сотрудника на работу» разные шаги требуют принципиально разных задач: собрать информацию для выхода, проверить необходимость доступа в 1С, зарегистрировать аккаунт, подготовить рабочее место, выдать оборудование. У этих задач разные исполнители, описания, чек-листы и переменные, поэтому каждый шаг проектируется отдельно.
Исполнитель шага может задаваться несколькими способами: прямой пользователь, группа через ACCESS_CODE, вычисляемый по контексту через Complex Resolver (например, руководитель инициатора или сотрудник, указанный в стартовой форме) — и, наконец, робот через SKILL_CODE. Последний вариант означает, что шаблон задачи уже сейчас может указывать на ИИ-агента как на исполнителя конкретного этапа. Не в формате «бот, помоги с процессом», а как полноценный исполнитель с формализованным входом и ожидаемым результатом.
Данные в процессе делятся на два типа. Стартовые переменные — то, без чего процесс нельзя корректно запустить: инициатор, тип процесса, дата начала, организация, файл заявления. Переменные этапов — данные, которые появляются по ходу работы: решение согласующего, нужен ли ноутбук, нужен ли доступ в 1С, файл, подготовленный на конкретном шаге. Каждая переменная имеет название, код, тип значения (string, integer, boolean, date, enum, file и другие) и признак обязательности.
Это разделение решает практическую проблему: в обычной задаче результат часто фиксируется свободным текстом — «Согласовано, нужен ноутбук, доступ в 1С не нужен». Из такого текста нельзя построить развилку, нельзя передать значение следующему шагу, нельзя дать ИИ-агенту стабильный вход. Структурированные переменные этапа превращают комментарий в данные: LAPTOP_NEEDED = true, ONE_C_ACCESS_NEEDED = false, WORK_FORMAT = remote. Теперь это не текст, а операционные данные процесса, которые можно использовать в условиях маршрута и передавать между шагами.
Подход описывается авторами как шаг к ИИ-native организации — концепции, где компания умеет описывать свою работу так, чтобы её можно было исполнять, проверять и постепенно делегировать отдельные шаги автоматике. Формализованный процесс с переменными и SKILL_CODE-исполнителями создаёт инфраструктуру, в которую ИИ-агенты встраиваются не как вспомогательный инструмент, а как равноправные участники операционного контура.
