В прошлой статье про AI-native организации я писал, что AI-native — это не компания, в которой всем выдали доступ к LLM и поставили несколько ботов в мессенджер. Ключевой переход начинается позже: когда компания умеет описывать свою работу так, чтобы ее можно было исполнять, проверять, передавать по маршруту и постепенно делегировать отдельные шаги AI-агентам.

Эта статья — про один из таких практических шагов. Я хочу рассказать, как мы у себя в компании автоматизировали процессное управление на базе BPMN моделей, Camunda, Битрикс24 и получили операционный контур, в котором процесс — это не регламент и не картинка BPMN, а исполняемый маршрут с задачами, контекстом, переменными и передачей контекста между шагами.

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

Но для AI-native здесь важна другая мысль: если шаг процесса формализован, к нему можно подключить не только человека, но и робота или AI-агента. Не в формате “бот, помоги с процессом”, а в формате конкретного исполнителя конкретного этапа с конкретным результатом.

Что мы называем исполняемым процессом

Обычный процесс в компании часто существует сразу в нескольких местах:

регламент в документе
обсуждение в чате
задача в Bitrix24
таблица с контрольными сроками
память руководителя
устные договоренности

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

Исполняемый процесс отличается тем, что каждый его шаг имеет:

входной контекст
исполнителя
ожидаемый результат
форму фиксации результата
правило перехода дальше
способ передать контекст следующему шагу

То есть задача в Битрикс24 перестает быть просто “поручением”. Она становится, состоянием процесса, точкой на карте маршрута.

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

Архитектура контура

Наш контур состоит из четырех основных слоев.

1. BPMN дизайнер моделей
   Модель процесса: BPMN, свойства диаграммы, владелец, стартовые переменные,
   флаги доступности и режимы запуска.

2. Camunda
   Исполнение маршрута: запуск экземпляра, переходы между шагами,
   обработка BPMN-логики.

3. Шаблоны задач
   Операционная спецификация каждого шага: заголовок, описание,
   участники, сроки, чек-листы, вложения, анкеты.

4. Переменные процесса
   Сбор данных на старте и по ходу маршрута, передача ответов
   в следующие задачи и условия процесса.

Важный принцип: модель процесса, поведение задач и исполнение не смешаны в один объект.

BPMN отвечает на вопрос:

когда и почему выполняется шаг

Шаблон задачи отвечает на вопрос:

как должна выглядеть работа исполнителя на этом шаге

Переменные процесса отвечает на вопрос:

какие данные должен зафиксировать исполнитель

Camunda отвечает за исполнение маршрута. Битрикс24 остается рабочим интерфейсом для людей.

Модель процесса и экземпляр процесса — разные сущности

Это первое разделение, которое пришлось постоянно объяснять пользователям. Диаграмма процесса — объект проектирования. Экземпляр процесса — объект исполнения.

Например, бизнес-аналитик меняет BPMN-схему “Прием сотрудника на работу”. Это работа с моделью. Владелец процесса согласует, правильно ли устроены этапы. Это тоже работа с моделью.

А когда HR запускает процесс для конкретного нового сотрудника, появляется экземпляр процесса. У него есть стартовые данные, задачи, исполнители, ответы анкет и история прохождения.

При этом конкретная задача в Битрикс24 прямо соотносится с конкретным этапом запущенного экземпляра процесса. Мы развели эти три типа объектов таким образом:

диаграмма процесса
    проектирование маршрута и согласование модели

экземпляр процесса
    конкретный запуск процесса с конкретными данными

маршрутная задача
    конкретный исполняемый шаг внутри экземпляра

Это разделение важно и для AI-агентов. Агент не должен “помогать с процессом вообще”. Он должен понимать, что выполняет конкретный шаг конкретного экземпляра процесса.

Шаблон задачи — это спецификация шага

У процесса нет одного общего шаблона задачи. У каждого исполняемого BPMN-шага свой шаблон.

Например, в процессе “Прием сотрудника на работу” разные шаги требуют разных задач:

собрать информацию для выхода сотрудника
проверить необходимость доступа в 1С
зарегистрировать аккаунт в Битрикс24
подготовить рабочее место
выдать оборудование
подтвердить готовность к выходу

У этих задач разные исполнители, описания, чек-листы и переменные. Поэтому каждый шаг проектируется отдельно.

Шаблон задачи хранит:

заголовок
описание
постановщика
ответственного
соисполнителей
наблюдателей
сроки
приоритет
чек-листы
вложения
анкеты
служебные настройки

Участники могут задаваться несколькими способами.

Первый — прямой пользователь. Это подходит для стабильных ролей: конкретный кадровый специалист, бухгалтер, администратор.

Второй — ACCESS_CODE, если участник задается через группу или оргструктуру.

Третий — Complex Resolver, если исполнитель вычисляется по контексту процесса. Например:

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

Четвертый вариант особенно важен для AI-native модели: исполнитель-робот через SKILL_CODE. В этом случае шаблон говорит, что шаг должен выполнить не обычный пользователь, а робот-исполнитель. Интеграционный слой передает код навыка в задачу, и дальше эту задачу может обработать соответствующий агент.

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

Главное правило данных: стартовые переменные или переменные этапа

Самый частый вопрос при проектировании процесса: где собирать данные? Можно собрать все на старте. Можно спрашивать в каждой задаче. Можно писать в комментарии. Можно хранить в пользовательских полях. Можно прикладывать файлы. Если нет правила, процесс быстро превращается в набор полей “на всякий случай”.

Мы используем простое разделение.

Стартовые переменные нужны для данных, без которых процесс нельзя корректно запустить:

инициатор
сотрудник
тип процесса
дата начала
организация
проект
контрагент
файл заявления

Переменные этапов нужны для данных, которые появляются по ходу работы:

решение согласующего
список недостающих документов
нужен ли ноутбук
нужен ли доступ в 1С
результат проверки
комментарий исполнителя
файл, подготовленный на шаге n

Например, в процессе оформления заявления на отпуск на старте логично спросить:

сотрудник
вид отпуска
дата начала
длительность
организация
замещающий
файл заявления

Без этого процесс не может нормально стартовать.

А решение руководителя “согласовано / не согласовано / требуется уточнение” — это уже результат конкретного шага. Его нужно собирать не на старте, а в анкете задачи согласования.

Переменные этапа превращают комментарий в данные

В обычной задаче результат часто фиксируется так:

Согласовано.
Проверил, все ок.
Нужен ноутбук, доступ в 1С не нужен.
Документы приложил.

Из такого текста сложно построить развилку. Нельзя надежно передать значение дальше. Нельзя проверить обязательность. Нельзя использовать результат в резолвере. Нельзя дать AI-агенту стабильный вход.

Переменные этапа решают эту проблему.

У каждого вопроса есть:

название
CODE
тип значения
обязательность
подсказка
варианты выбора, если нужны

В реальных процессах используются не только строки:

string
integer
boolean
date
enum
user
universal_list
1c_entity
file

Пример для onboarding:

LAPTOP_NEEDED = true
ONE_C_ACCESS_NEEDED = false
WORK_FORMAT = remote
START_DATE = 2026-06-01
DOCUMENTS_ATTACHED = file:[...]

Теперь это не комментарий. Это данные процесса.

Их можно использовать:

в условиях gateway
в назначении исполнителей
в описании следующих задач
в проверках
в роботизированных шагах
в AI-agent input

Как данные предыдущих шагов попадают в следующие задачи

Исполняемый процесс полезен не тем, что автоматически создает задачи. Это минимальная функция. Главная польза — он переносит контекст. Следующий исполнитель должен получить не просто новую задачу, а понятную предысторию:

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

Контекст приходит из трех источников:

1. Системные переменные
   startedBy, businessKey, processInstanceId

2. Стартовые переменные
   данные, введенные при запуске процесса

3. Переменные этапов
   данные, собранные исполнителями на предыдущих шагах

В результате исполнитель получает задачу не в стиле:

Подготовьте доступы.

А в стиле:

Новый сотрудник: Иван Иванов
Дата выхода: 01.06.2026
Формат работы: удаленный
Нужен ноутбук: да
Доступ в 1С: нет
Пропуск: нет
Документы: приложены

Это экономит не минуты, а качество. Исполнитель не реконструирует контекст из чатов и предыдущих задач.

Задача как интерфейс для человека, процесса и агента

Один и тот же шаг можно рассматривать с трех сторон. Для человека задача — это рабочий экран:

что нужно сделать
какой срок
какие файлы приложены
какие поля заполнить
кто наблюдает

Для процесса задача — это состояние:

taskId
processInstanceId
businessKey
переменные
чек-листы
результат
переход дальше

Для AI-агента задача — это контейнер входа и результата:

контекст
skill
инструкция
ожидаемый JSON / текст / файл
guardrails
eval / human review

Поэтому задача становится удобной точкой подключения AI. Не нужно придумывать отдельный “AI-интерфейс” для каждого процесса. Достаточно формализовать шаг.

Что меняется в проектировании процессов

После внедрения исполняемых процессов мы начали проектировать процессы иначе.

Раньше обсуждение часто начиналось со списка задач:

кто кому что должен поставить
какие сроки
какие ответственные

Теперь правильнее начинать с данных и решений:

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

Практический чек-лист для проектирования одного шага:

1. Как называется шаг?
2. Какой BPMN-элемент его запускает?
3. Кто исполнитель?
4. Исполнитель фиксированный или вычисляемый?
5. Нужен ли Complex Resolver?
6. Может ли шаг выполнить робот / skill?
7. Что исполнитель должен увидеть в описании?
8. Какие данные он должен заполнить?
9. Какие поля обязательны?
10. Какие ответы влияют на gateway?
11. Какие ответы нужны следующим задачам?
12. Какие файлы должны быть приложены?
13. Что считается завершением шага?

Если на эти вопросы нет ответов, шаг еще не готов к автоматизации.

Специальные режимы запуска

Когда процесс становится исполняемым, важно не только “что он делает”, но и “откуда он запускается”. У нас используются несколько режимов.

Общекорпоративный процесс

Флаг IS_COMPANY_WIDE делает процесс доступным для запуска сотрудниками из каталога процессов.

Это удобно для типовых сценариев:

предоставление отпуска
заказ документов
заявка на подбор
проверка материалов

Динамический выбор проекта

Флаг IS_DYNAMIC_BX_GROUP нужен, когда одна и та же логика процесса должна исполняться в разных проектах.

В этом случае проект не зашивается в модель. Он выбирается на стартовой форме, становится effectiveGroupId и используется как группа исполнения задач.

Пример:

один процесс подготовки ТЗ
разные проектные группы
проект выбирается при запуске

Этот режим не стоит включать “на всякий случай”. Если процесс всегда живет в одном проекте, лучше задать проект явно.

Периодический запуск

Флаг IS_PERIODIC нужен для процессов, которые запускаются по расписанию.

Например:

ежемесячный запуск рекламной кампании проекта
регулярная проверка данных
периодический сбор отчетности

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

Внешний контур

Флаг IS_COLLAB_AVAILABLE открывает процесс для внешней аудитории через отдельный контур.

Это не “та же форма по другой ссылке”. У внешнего запуска должны быть отдельные правила видимости, проверки аудитории и доступа к данным.

Для AI-агентов это тоже важно. Агент должен работать в том же контуре прав, что и процесс. Если внешний пользователь не должен видеть часть данных, AI-исполнитель тоже не должен получать эти данные во входном контексте.

Что появляется после запуска процесса

После первых рабочих экземпляров у процесса появляется история. Это не отчетность ради отчетности, а операционная память компании.

По каждому экземпляру можно восстановить:

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

Эта история полезна для трех задач.

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

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

Третья — выбор AI-кандидатов. Хороший кандидат для AI — не самый модный шаг, а шаг с повторяемой интеллектуальной работой. Это видно по истории: люди снова и снова проверяют комплектность, переписывают однотипные письма, суммируют данные предыдущих задач, ищут расхождения в файлах.

Без исполняемого процесса такие места обычно ищутся по ощущениям. С процессом они становятся видны как на ладони.

Где исполняемые процессы дают эффект быстрее всего

Не каждый процесс нужно автоматизировать первым.

Лучшие кандидаты:

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

Хорошие первые процессы:

прием сотрудника
предоставление отпуска
заявка на подбор
проверка стоимости материалов и работ
периодический запуск рекламной кампании

Плохие первые процессы:

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

Как выбрать первые точки для AI

После того как процесс стал исполняемым, точки для AI находятся намного проще.

Не нужно спрашивать:

какой процесс полностью отдать AI

Лучше спрашивать:

какой шаг можно усилить AI

Типовые кандидаты:

проверка полноты и качества данных
классификация заявки
подготовка черновика письма
сравнение документа с чек-листом
поиск противоречий
резюмирование предыдущих шагов
формирование списка вопросов
предварительная оценка риска

Для каждого кандидата нужно описать контракт:

input
    какие переменные и анкеты получает агент

instruction
    что именно он должен сделать

output
    в каком формате вернуть результат

guardrails
    что агенту запрещено делать

review
    кто проверяет результат

next step
    как результат влияет на процесс

Пример для заявки на подбор:

AI-шаг: анализ заявки на подбор

Input:
    должность
    подразделение
    руководитель
    требования
    зарплатная вилка
    причина открытия
    дата выхода

Instruction:
    проверить полноту заявки, найти противоречия,
    подготовить уточняющие вопросы для руководителя

Output:
    статус: ok / needs_clarification
    список вопросов
    список рисков

Review:
    рекрутер

Next step:
    если ok → согласование заявки
    если needs_clarification → возврат инициатору

Это уже не чат-бот. Это исполнитель шага процесса.

Что остается человеку

Исполняемые процессы не убирают человека из работы.

Они убирают ручной перенос контекста.

Человек остается там, где нужна ответственность:

определить цель процесса
спроектировать маршрут
согласовать правила
принять решение в точке риска
проверить результат AI
изменить процесс после обратной связи

AI и роботы могут брать на себя действия:

проверить
сравнить
классифицировать
сжать
подготовить черновик
подсветить риск
найти недостающее поле

Разница принципиальная: AI не “заменяет процесс”. AI подключается к процессу как исполнитель отдельных формализованных шагов.

Почему это шаг к AI-native

В статье про AI-native я писал, что компания должна переходить от документов, инструкций и процессов к исполняемой операционной системе. Исполняемые процессы — один из самых практичных способов сделать этот переход. Пока процесс живет в регламенте, AI может только прочитать текст и дать совет. Пока процесс живет в чате, AI может только помочь участнику сформулировать ответ. Пока процесс живет в голове руководителя, AI вообще не видит операционную логику.

Но когда процесс становится исполняемым, у AI появляется место в системе:

шаг процесса
входной контекст
skill
ограничения
результат
проверка
следующий переход

Это и есть переход от “у нас есть AI-инструменты” к “AI встроен в операционную модель”.

Короткий вывод

Мы автоматизируем процессное управление не ради красивых BPMN-схем и не ради автоматического создания задач.

Главный результат — появление исполняемого контура:

модель → запуск → задачи → анкеты → переменные → контекст → следующий шаг

В таком контуре задача становится состоянием процесса, переменные процесса — источником данных, шаблон — спецификацией шага, а AI-агент — потенциальным исполнителем формализованной работы.

Именно поэтому исполняемые процессы для нас — не просто развитие Битрикс24.

Это инфраструктурный шаг к AI-native организации.