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

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

Данное ограничение существенно для сквозных межфункциональных процессов, включающих разнородные документы, неполные сведения и изменяющиеся требования. Современное направление развития BPM связано с применением искусственного интеллекта не только для анализа журналов, но и для моделирования, исполнения и мониторинга процессов

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

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

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

Научная новизна заключается не в самом наборе ролей типа planner, executor и critic, известных в современных агентных архитектурах, а в процедуре перехода от модели бизнес-процесса к составу агентов посредством операциональной оценки применимости, проверки архитектурных условий и назначения автономности каждой операции.

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

2.1. Формализация бизнес-процесса и исполнителей

Бизнес-процесс представлен кортежем:

где T — множество операций;

G — граф переходов;

D — данные;

R — организационные роли;

S — программные системы;

C — нормативные, временные, ресурсные и безопасностные ограничения;

K — показатели результата.

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

Интеллектуальный агент определяется как:

где Gᵢ — локальная цель;

Pᵢ — механизм восприятия входного контекста;

Mᵢ — оперативная и долговременная память;

Lᵢ — механизм планирования;

Uᵢ — доступные инструменты;

Πᵢ — политика допустимых действий;

Hᵢ — механизм взаимодействия с человеком и другими агентами.

Обозначим

Уровень автономности определяется только для множества агентно исполняемых операций

Отображение

Таким образом, детерминированным сервисам не назначается «уровень автономности», они исполняют заранее формализованную функцию в пределах заданных правил. Это устраняет смешение автоматического программного исполнения и автономности интеллектуального агента.

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

2.2. Оценка агентной применимости

Каждая операция оценивается по шести критериям в диапазоне от 0 до 1 с шагом 0,25 (табл. 1).

Примечание к таблице 1. Рост f, d, v и r повышает потенциальную применимость агентного исполнения, тогда как рост c и u её снижает. Для критерия v высокая вариативность означает наличие неструктурированного текста или контекста, где интеллектуальный агент потенциально полезнее детерминированного сервиса. При этом высокое значение v не означает безопасности автономного действия — фактический уровень автономности дополнительно ограничивается критичностью, обратимостью, неопределённостью и качеством данных.

2.2.1. Экспертная процедура

Оценивание выполняют не менее трёх специалистов — владелец процесса, специалист ИТ-отдела и специалист по рискам и (или) безопасности. Каждый эксперт независимо выставляет оценки f, d, v, r, c, u. Итоговая оценка операции по каждому критерию определяется медианой. Для определения весов каждый эксперт независимо формирует матрицу попарных сравнений критериев между собой. Индивидуальные суждения агрегируются на уровне элементов матриц геометрическим средним, после чего из агрегированной матрицы определяется нормированный вектор приоритетов. Отношение согласованности проверяется как для индивидуальных матриц, так и для агрегированной матрицы, а условием принятия является

Для ранжирования операций по критериям рассчитывается коэффициент конкордации Кендалла W. В качестве проектного условия принимается

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

Для модельного примера используются веса:

Уровень 4 разрешается только при c=0, u=0, r≥0,75 и наличии формальной проверки результата. При невыполнении хотя бы одного из указанных условий предварительный уровень ограничивается значением 3.

Значения 0,45, 0,60, 0,75 и 0,85 не устанавливаются как универсальные нормативные границы. Это проектные пороги демонстрационной модели, которые должны калиброваться на журналируемых процессах конкретной организации.

Аддитивная свёртка является предварительным показателем и не должна компенсировать критически низкое качество данных другими благоприятными признаками. Поэтому до окончательного назначения уровня действует условие-вето: при d=0 операция исключается из

Обозначим данный предел через

До применения Ia также выполняется проверка на детерминированность. Если f≥0,75, v≤0,25, u≤0,25, алгоритм полностью задаётся правилами и результат формально проверяем, предпочтение отдаётся программному сервису. В этом случае Ia может рассчитываться только как диагностический показатель и не определяет автономность.

Для операции

где

Если операция отнесена к детерминированному сервису или обязательному персональному решению, она не входит в

2.3. Выбор типа архитектуры

Введён индекс архитектурной сложности:

где h — неоднородность предметных областей, p — параллельность операций, q — потребность в независимом контроле, a — различие прав доступа, k — нестабильность общего контекста, e — различие локальных целей, l — потребность в локализации ошибок.

Показатели оцениваются по шкале 0; 0,5; 1.

Коэффициенты формулы (7) в демонстрационной модели являются авторскими проектными весами, а не эмпирически установленными универсальными величинами. При промышленном применении веса должны определяться отдельной экспертной процедурой МАИ, аналогично приведённой в разделе 2.2, а условием принятия весов является

Мультиагентная архитектура выбирается при Im≥0,55, а также независимо от индекса, если q=1 или a=1. Если q=1 или a=1, решение о мультиагентной архитектуре уже определяется безусловным правилом, а значение Im используется только как диагностическая характеристика сложности. Поэтому индекс имеет самостоятельное решающее значение прежде всего для случаев q<1 и a<1. Например, при h=1, p=1, q=0, a=0, k=1, e=1, l=0,5, поскольку q=0 и a=0, безусловные условия выбора мультиагентной архитектуры не выполняются. В этом случае Im=0,6>0,55 и решение определяется непосредственно значением индекса архитектурной сложности.

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

2.4. Процедура проектирования

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

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

На третьем этапе для операций-кандидатов на агентное исполнение рассчитывается Ia, применяется условие по качеству данных и определяется предварительный уровень

На четвёртом этапе строится отображение

На пятом этапе операции объединяются в область одного агента при совпадении цели, контекста, прав и политики; независимая проверка при необходимости реализуется отдельным агентом-контролёром.

На шестом этапе рассчитывается

3.1. Структурно-функциональная архитектура

Предлагаемая архитектура включает шесть уровней (табл. 3).

Концепция Agentic BPMS предполагает сочетание автономности и процессной осведомлённости

Семь функциональных ролей — восприятие, контекстуализация, планирование, принятие решения, исполнение, контроль и коммуникация — не рассматриваются как самостоятельная новая таксономия. Они являются адаптацией распространённых шаблонов planner-executor-critic к процессной архитектуре. Несколько ролей могут быть объединены, если отсутствует конфликт полномочий.

Граф G задаёт допустимую последовательность и параллельность операций. Формальные ограничения могут быть представлены средствами сетей Петри или аналогичных моделей

3.2. Матрица автономности

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

Матрица покрывает все сочетания диапазонов критичности и признака полной необратимости. Уровень 0 соответствует ручному исполнению, уровень 1 — информационной поддержке, уровень 2 — подготовке решения, уровень 3 — ограниченной автономности, уровень 4 — автономному исполнению некритичного фрагмента. При ухудшении данных или росте неопределённости уровень понижается в соответствии с формулой (6).

Риск-ориентированное назначение автономности соответствует функциям управления, определения контекста, измерения и обработки рисков NIST AI RMF

3.3. Сопоставление с существующими подходами

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

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

3.4. Модельная апробация

Рассмотрен процесс обработки внутренней заявки. Процесс включает регистрацию, извлечение реквизитов, проверку полноты, сопоставление данных ERP, MES и PLM, подготовку варианта решения, утверждение ответственным работником и исполнение утверждённого изменения (табл. 6).

Примечание к таблице 6. Значения Ia приведены с округлением до двух знаков после запятой. Точные значения приведены в таблице 7. При d≥0,5 дополнительное ограничение по качеству данных отсутствует, поэтому для агентно исполняемых операций в столбце

Исполнение в ERP/MES имеет обязательное предварительное условие — завершённое утверждение ответственным работником, однако основным исполнителем самой операции является детерминированный сервис.

Оценки являются авторскими модельными значениями и приведены для проверки расчётной процедуры.

Регистрация и исполнение в ERP/MES относятся к детерминированным сервисам не по величине Ia, а по причине выполнения правила детерминированности, т.е. операции структурированы, формализуемы и выполняются по однозначному алгоритму. Поэтому значения Ia=0,80 и 0,69 для них являются оценочными и не используются для назначения автономности.

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

В рассматриваемом примере ни одна операция не получает уровень 4. Наиболее близка к такому режиму операция проверки полноты, для неё действие обратимо r=1, неопределённость отсутствует u=0 и результат допускает формальную проверку, однако Ia=0,8225<0,85 и c=0,25

3.4.1. Проверка архитектуры

Для выбора архитектуры приняты h=1, p=0,5, q=1, a=1, k=0,5, e=0,5, l=1. По формуле (7)

3.4.2. Анализ чувствительности

Однофакторный анализ чувствительности выполнен изменением одного веса формулы (5) на ±20% с последующей нормировкой. Ни для одной операции исходный интервал Ia не изменился.

При одновременном граничном варьировании всех весов на ±20% с последующей нормировкой показатель регистрации заявки изменяется в пределах 0,745–0,845 и пересекает границу 0,75. Это не изменяет итогового назначения, поскольку регистрация отнесена к детерминированному сервису до применения Ia, однако показывает, что утверждение об устойчивости интервалов справедливо только для однофакторного анализа.

Для практической оценки устойчивости дополнительно рассчитывается запас до ближайшего порога (табл. 7).

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

Дополнительно исследовано изменение одной исходной оценки на один шаг шкалы, то есть ±0,25. Для большинства операций режим сохраняется. Для операции извлечения реквизитов увеличение критичности с c=0,25 до c=0,50 уменьшает Ia=0,81 до 0,7475, что переводит операцию из диапазона ограниченной автономности в режим подготовки решения с подтверждением. Следовательно, данная операция является чувствительной к экспертной оценке критичности и перед промышленным внедрением требует повторной оценки. Это не противоречит процедуре, а демонстрирует назначение анализа чувствительности.

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

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

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

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

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

Разработан структурно-функциональный подход к проектированию мультиагентных систем автоматизации сквозных бизнес-процессов.

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

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

Сформированы шестиуровневая архитектура и матрица автономности, связывающая режим исполнения с риском конкретной операции.

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

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

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

– частоту эскалаций на 1000 экземпляров процесса;

– долю ошибочных автономных решений среди выполненных агентом действий;

– долю действий, заблокированных независимым контролем до изменения данных;

– среднее время обработки исключения после эскалации;

– изменение доли операций, возвращённых с уровня 3–4 на уровень 1–2 после накопления эксплуатационной статистики.

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