В прошлой статье про 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тип значенияобязательностьподсказкаварианты выбора, если нужны
В реальных процессах используются не только строки:
stringintegerbooleandateenumuseruniversal_list1c_entityfile
Пример для onboarding:
LAPTOP_NEEDED = trueONE_C_ACCESS_NEEDED = falseWORK_FORMAT = remoteSTART_DATE = 2026-06-01DOCUMENTS_ATTACHED = file:[...]
Теперь это не комментарий. Это данные процесса.
Их можно использовать:
в условиях gatewayв назначении исполнителейв описании следующих задачв проверкахв роботизированных шагахв AI-agent input
Как данные предыдущих шагов попадают в следующие задачи
Исполняемый процесс полезен не тем, что автоматически создает задачи. Это минимальная функция. Главная польза — он переносит контекст. Следующий исполнитель должен получить не просто новую задачу, а понятную предысторию:
что уже было введено на стартекакие решения принятыкакие файлы приложеныкакие поля заполненыпочему процесс пришел именно к этому шагучто требуется сделать теперь
Контекст приходит из трех источников:
1. Системные переменные startedBy, businessKey, processInstanceId2. Стартовые переменные данные, введенные при запуске процесса3. Переменные этапов данные, собранные исполнителями на предыдущих шагах
В результате исполнитель получает задачу не в стиле:
Подготовьте доступы.
А в стиле:
Новый сотрудник: Иван ИвановДата выхода: 01.06.2026Формат работы: удаленныйНужен ноутбук: даДоступ в 1С: нетПропуск: нетДокументы: приложены
Это экономит не минуты, а качество. Исполнитель не реконструирует контекст из чатов и предыдущих задач.
Задача как интерфейс для человека, процесса и агента
Один и тот же шаг можно рассматривать с трех сторон. Для человека задача — это рабочий экран:
что нужно сделатькакой сроккакие файлы приложеныкакие поля заполнитькто наблюдает
Для процесса задача — это состояние:
taskIdprocessInstanceIdbusinessKeyпеременныечек-листырезультатпереход дальше
Для AI-агента задача — это контейнер входа и результата:
контекстskillинструкцияожидаемый JSON / текст / файлguardrailseval / 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 организации.
ссылка на оригинал статьи https://habr.com/ru/articles/1037056/