Спросите у любого ИИ-агента, где в вашем процессе узкое место, и он ответит. Уверенно, с формулировками уровня «этап согласования перегружен, рекомендую распараллелить». Проблема в том, что этот ответ он может дать, даже если видел только картинку из прямоугольников и стрелок, где нет ни одной цифры о времени, людях и нагрузке.
Модель не ломается. Она делает ровно то, чему обучена: заполняет пробелы правдоподобным содержимым. Проблема возникает дальше, когда правдоподобное принимают за расчёт и несут в качестве обоснования найма.
Разберём по слоям, что ИИ для описания бизнес-процессов извлекает из вашей схемы фактически, что дописывает из общих знаний и в какой момент вам всё равно придётся встать и пойти замерить реальность. В конце - чек-лист из пяти шагов, который занимает неделю и снимает большую часть иллюзий.
Когда агент отвечает на вопрос о процессе, он собирает ответ из трёх разных слоёв. В тексте они перемешаны, а достоверность у них отличается радикально.
BPMN-диаграмма - это XML-файл. Внутри у него описаны элементы и связи между ними: задачи, события, шлюзы, потоки, пулы и дорожки, идентификаторы, названия, координаты для отрисовки. Всё это модель читает буквально, без домыслов. Если задача называется «Проверить документы», агент знает, что такая задача есть, откуда в неё приходит поток и куда уходит.
Это самый надёжный слой. Ошибиться здесь модель может разве что в интерпретации кривых названий - когда задача подписана «Обработка», и непонятно, обработка чего и кем.
Диаграмма редко живёт одна. Вокруг неё есть карточка процесса, ответственные и роли, регламент, история версий, комментарии коллег, связанные системы и документы. Если агент подключён к платформе моделирования, а не работает с выгруженным файлом, этот контекст ему тоже доступен.
Здесь достоверность зависит от вас. Реестр процессов отражает реальность ровно в той мере, в какой его заполняли и обновляли. Агент не отличает актуальный регламент от того, что не трогали три года: для него это одинаково валидный текст, и пометки «устарело» он нигде не увидит.
Третий слой - общие знания. Модель читала тысячи описаний того, как устроена поддержка, закупки, наём, согласование договоров. Она знает такие процессы «вообще»: где копятся задержки, что принято автоматизировать, сколько длится проверка документов в типовой компании.
Слой самый объёмный и самый опасный: он даёт модели материал для экспертного ответа на любой вопрос, включая те, ответа на которые в ваших данных нет.
У верхнего слоя есть чёткие границы, и знание этих границ - главный практический навык в работе с агентом.
Логику процесса модель восстанавливает точно. Она видит последовательность задач, знает, что после эксклюзивного шлюза поток идёт по одной ветке из нескольких, а после параллельного - по всем сразу. Она отличает стартовое событие от промежуточного и конечного, видит таймеры и сообщения.
На этом строятся полезные вещи. Агент находит недостижимые фрагменты, эксклюзивные и инклюзивные шлюзы без условий на ветках, задачи без исполнителя, ветки, которые никуда не приводят. Разбор самих развилок с примерами мы собрали в статье про все шлюзы в BPMN.
Важная оговорка: часть этих проверок идёт прямо из спецификации OMG, а часть - из соглашения о моделировании вашей команды. Конечное событие и исполнитель задачи стандартом не требуются: их обязательность вводит уже конвенция читаемости. Агент в любом случае сверяется с формальным списком правил, а не гадает - вопрос лишь в том, чей это список.
Если в схеме проставлены роли, названы документы и системы, размечены подпроцессы - всё это агент прочитает. Он ответит, кто участвует в процессе, какие документы порождаются, куда уходит вызов внешнего сервиса.
BPMN описан спецификацией OMG, и в части структуры он однозначен. Но у нотации нет обязательного словаря для содержания. Название задачи, формулировка условия на потоке, комментарий в аннотации - свободный текст.
Значит, качество ответов агента напрямую зависит от того, как названы элементы. Диаграмма, где половина задач подписана существительными вроде «Документы» и «Решение», для модели почти нечитаема по смыслу: структуру она восстановит, а вот что там происходит - будет достраивать сама. И вы не увидите, где кончилось чтение и началось сочинение.
Теперь к главному. Есть класс вопросов, на которые схема процесса не отвечает в принципе - независимо от того, насколько она подробная и красивая.
В самой нотации нет атрибутов для среднего времени работы, разброса этого времени, сезонности, доли заявок, уходящих в каждую ветку. Формально расписание запуска можно закодировать таймерным стартовым событием, а произвольные параметры - положить в расширения, но каждый инструмент заполняет их по-своему, и переносимости между системами это не даёт.
Закрыть дыру пытались отдельным стандартом: BPSim от WfMC описывает параметризацию и обмен данными анализа процессной модели. Поддержан он единичными инструментами. На практике параметры расчёта живут не в схеме, а в модуле симуляции или в отдельной таблице.
В диаграмме не записано, сколько человек в отделе, кто работает на полставки, кто в отпуске, сколько стоит час работы. И главное - какие шаги тянет одна и та же группа людей: за её время эти шаги конкурируют между собой. Именно это чаще всего и определяет реальную длительность процесса: не сумма работы, а ожидание в очереди к перегруженному ресурсу.
Узкое место - это место, где спрос на ресурс превышает его доступность и копится очередь. Слова «спрос», «доступность» и «очередь» отсутствуют в схеме как класс данных.
Поэтому ответ «узкое место у вас на согласовании» по одной картинке - это не вывод, а угадывание, опирающееся на статистику похожих процессов из обучающих данных. Иногда угадывание попадает: согласование часто бывает бутылочным горлышком. Проверить это по схеме не может ни человек, ни модель - нужны данные о нагрузке.
| Что модель берёт из схемы | Чего в схеме нет |
|---|---|
| Задачи, события, шлюзы, потоки | Сколько времени занимает задача |
| Роли, дорожки, пулы | Сколько людей доступно и на сколько часов |
| Документы, системы, подпроцессы | Как часто процесс запускается |
| Условия на потоках (если написаны) | Какая доля заявок идёт в каждую ветку |
| Нарушения правил нотации | Где копится очередь и сколько стоит ожидание |
Модель не оставляет пустых мест. Там, где данных нет, она подставляет наиболее вероятное продолжение - и делает это незаметно, тем же уверенным тоном, что и при чтении фактов. Вот подстановки, которые встречаются чаще всего.
Спрашиваете, сколько занимает проверка договора - получаете ответ вида «от двух часов до рабочего дня». Это среднее по всему, что модель читала про юридические проверки. К вашей компании, где договоры смотрит один юрист на три подразделения, цифра отношения не имеет.
Проверяется просто: задайте тот же вопрос про процесс, которого у вас нет. Если ответ такой же складный - вы получаете общие знания, а не анализ.
Даже когда цифры вы дали, модель охотно сводит их к среднему: «в среднем заявка обрабатывается за три часа». Для расчёта очередей одного среднего мало, нужен разброс. Если девять заявок из десяти закрываются за час, а десятая висит сутки, то среднее в три с небольшим часа не описывает ни один реальный случай и прячет ровно ту заявку, из-за которой всё и горит.
Модель дорисовывает шаги, которых у вас нет: уведомление клиенту, проверку на дубликаты, эскалацию руководителю. В пересказе это звучит как описание вашего процесса, хотя половины упомянутого в нём просто нет.
«Задержки возникают из-за ручной классификации обращений» - типичный ответ. Он звучит как вывод из данных, но данных о задержках у модели не было. Это гипотеза, построенная на том, что ручные шаги в среднем медленнее автоматических.
Гипотеза может оказаться верной, но до проверки она остаётся гипотезой.
Самая коварная подстановка - стилистическая. Человек, который не знает, говорит «кажется», «надо посмотреть», «тут я не уверен». Модель по умолчанию так не говорит: она выдаёт догадку тем же ровным тоном, что и цитату из вашего регламента. Отличить на слух невозможно, поэтому и нужны формальные приёмы проверки.
Хорошая новость: разделить слои несложно, если задавать правильные вопросы. Три приёма ниже занимают пару минут каждый и снимают большинство проблем.
После любого содержательного ответа спрашивайте: «Для каждого утверждения укажи, откуда оно: из диаграммы, из данных рабочего пространства или из твоих общих знаний». Хорошая модель честно разложит по полочкам - и вы увидите, что заметная часть выводов пришла из третьего слоя.
Формулировка важна. «Ты уверен?» вызывает у модели вежливое согласие с любой правкой, а не проверку. Вопрос на источник заставляет её пройтись по утверждениям и проверить каждое.
Возьмите ту же схему и переименуйте её из «Обработка обращения» в «Обработка заявки на отпуск», не меняя структуру. Задайте тот же вопрос про узкие места. Если ответ поменялся, хотя структура прежняя, - модель отвечает по названию и общим знаниям о таких процессах, а не по схеме.
Второй вариант той же проверки: спросите про длительность конкретного шага, а потом сообщите цифру, отличающуюся втрое, и попросите пересчитать. Если модель молча принимает любое число, значит своего у неё не было.
Прямо разрешите ответ «данных нет». Формулировка вроде «если в диаграмме или рабочем пространстве нет нужных данных, так и напиши: каких именно данных не хватает и как их собрать» работает лучше любых уговоров быть точным. Модель обучена давать полезный ответ, и пустой ответ для неё выглядит плохим - без явного разрешения промолчать она будет заполнять пробелы.
Ещё один рабочий приём - попросить сначала список вопросов, а не ответ. «Задай мне десять вопросов по одному, ответы на которые нужны, чтобы посчитать этот процесс». Вы получите ровно тот перечень данных, которых не хватает.
Схема есть, слои разделены, стало ясно: чтобы считать, нужны цифры. Дальше ИИ для описания бизнес-процессов уже не помощник - начинается работа с данными. Для первого прогона их требуется немного.
Величин всего четыре:
Этого набора хватает, чтобы посчитать пропускную способность и увидеть, где копится очередь. Всё остальное - уточнения.
Частоту почти всегда даёт та система, где заявки живут: сервис-деск, CRM, почтовый ящик, таблица. Выгрузка за квартал с датами создания закрывает первый пункт целиком.
Длительности сложнее: сквозное время в системе включает ожидание, а нужно чистое время работы. Здесь работает обычный разговор с исполнителями - как это вести, чтобы не получить социально одобряемые ответы, разобрано в материале про интервью для описания бизнес-процессов. На старте хватает оценок исполнителей, снятых в формате «обычно / в плохой день»: пятнадцать минут и час - это уже разброс, с которым можно работать. Доли на развилках берутся из тех же выгрузок по статусам или категориям. Доступный ресурс считается по графику работы и доле занятости в этом процессе.
По нашему опыту сбора данных на пилотах неделя на один процесс - реалистичный срок, если не строить хранилище и не согласовывать методику измерений на трёх уровнях.
Здесь обычно возникает возражение: наши оценки грубые, расчёт будет неточным. Он и будет неточным - в абсолютных числах. Но решения, ради которых всё затевается, обычно сравнительные: нанять ещё одного человека или переставить шаг, добавить смену или изменить порядок проверок.
Для сравнения сценариев грубых, но честных цифр обычно хватает: если один вариант даёт очередь вдвое короче, порядок вывода не перевернётся от ошибки в пятую часть. Оговорка тут важная: чем ближе ресурс к полной загрузке, тем сильнее очередь реагирует на мелкую неточность. При загрузке под девяносто процентов те же двадцать процентов погрешности меняют картину в разы - в такой зоне замеры придётся уточнять. Отраслевые средние, подставленные моделью, не помогут ни при какой загрузке: они не про вашу компанию.
Возьмём процесс, знакомый почти всем: обращение клиента в поддержку SaaS-сервиса. Логика простая - регистрация обращения в общей очереди, попытка решения ботом, классификация на триаже, работа первой линии, эскалация на инженеров для сложных случаев, ожидание реакции клиента с таймером, проверка удовлетворённости, закрытие.
Агент, которому дали только эту диаграмму, отвечает связно и по делу. Он заметит, что классификация выполняется вручную и это потенциальная точка задержки. Предложит расширить сценарии бота, чтобы больше обращений закрывалось без человека. Обратит внимание на ветку ожидания реакции клиента с пятидневным таймером и скажет, что она удлиняет среднее время закрытия.
Каждое из этих утверждений выглядит как результат анализа. На самом деле это перенос типовых знаний о процессах поддержки на вашу картинку. Ни одно из них не следует из схемы: в ней нет ни времени классификации, ни доли обращений, закрываемых ботом, ни количества операторов.
Теперь зададим параметры собирательного примера: сорок обращений в день с всплеском после релизов, полторы минуты на классификацию, два инженера на второй линии, доли на развилках из выгрузки по категориям. Цифры условные, важна механика.
На таких числах расчёт даёт другую картину, чем ответ по картинке. Классификация теряется в фоне, и расширять бота ради неё смысла нет. Очередь копится на второй линии, потому что инженеров двое, а сложные обращения приходят пачками. Пятидневный таймер портит среднее время закрытия, но клиента не задерживает: он ждёт собственной реакции, а не нашей.
Ваши числа дадут свой результат - и в этом вся суть. Вывод меняется от данных, а не от схемы. Схема при этом была верной: она просто отвечала на другой вопрос.
Первое решение - вкладываться в бота и автоклассификацию. Второе - добавить инженера на вторую линию или сгладить пики после релизов. Стоят они по-разному, дают разный эффект, и выбор между ними определяется не логикой схемы, а цифрами о нагрузке.
Это и есть цена вопроса, что ИИ на самом деле знает о вашем процессе. Не академический интерес, а конкретное решение о деньгах и людях, принятое либо по расчёту, либо по правдоподобной догадке.
Три слоя знаний удобно разделять, когда платформа сама показывает, откуда взялся каждый ответ. Работу с ИИ мы строили именно так.
Stormbpmn подключается к Claude Desktop, Cursor и другим средам через MCP - протокол, по которому агент получает доступ к инструментам платформы. Агент читает ваши диаграммы, реестр процессов, роли и оргструктуру, справочные материалы команды. MCP-доступ и настройка правил доступны с тарифа TEAM и выше - на бесплатном аккаунте этой части не будет. Это тот самый второй слой: не общие знания из интернета, а ваш контекст.
Разница видна сразу. На вопрос «кто отвечает за эскалацию» агент без доступа ответит правдоподобно, агент с доступом - по вашей оргструктуре и разметке процесса. Подробнее про ИИ-инструменты для работы с процессами.
В настройках команды живут правила проверки диаграмм: их несколько десятков, каждое можно включить, выключить, изменить важность и добавить подсказку. Правила прогоняются при каждом сохранении, в том числе когда схему сохранил агент: нарушения видно списком, а рейтинг качества считается детерминированно, а не «на глаз модели». Дальше их правит либо человек, либо тот же агент - но по конкретному перечню, а не по ощущению.
Деталь важная: проверка структуры отдана коду, а не нейросети. Модель хороша в порождении вариантов, а роль арбитра остаётся за формальным механизмом.
Второй слой знаний агента вы наполняете сами, и делается это не в чате, а в реестре. Карточка процесса держит рядом со схемой владельца, регламент, показатели, связанные системы и статус согласования. Всё это агент читает как контекст, когда отвечает на вопрос о процессе.
Отсюда практический вывод, неприятный, но честный: качество ответов ИИ упирается в порядок в реестре. Если половина процессов заведена без владельца, а регламенты не обновлялись с прошлого года, агент будет уверенно пересказывать устаревшее. Модель не проверяет актуальность, она работает с тем, что ей дали.
Приятная сторона в том, что порядок окупается дважды. Тот же заполненный реестр, который делает ответы агента точными, экономит время на подготовке расчёта: плановые длительности живут на элементах схемы отдельным оверлеем, ответственные и системы - в карточке, и собирать это заново под каждый эксперимент не приходится.
Четвёртый слой, которого нет ни в схеме, ни у модели, - расчёт. Имитационное моделирование берёт вашу диаграмму, добавляет к ней замеренные параметры и прогоняет тысячи виртуальных заявок, показывая, где копится очередь, сколько ждёт клиент и какой сценарий выгоднее.
Роли распределяются честно: ИИ помогает наполнить модель и объяснить результат человеческим языком, схему правит человек, а вердикт по узким местам выносит математика. Как это работает - в разделе про дискретно-событийную симуляцию.
ИИ для описания бизнес-процессов точно читает структуру: задачи, шлюзы, события, потоки, роли, документы. Здесь агенту можно доверять, и здесь он приносит реальную пользу - находит недостижимые ветки, развилки без условий, пропущенных исполнителей, пересказывает сложную схему простым языком, собирает черновик процесса по вашему описанию.
Модель не знает ничего о времени, объёмах, ресурсах и стоимости: этих данных нет в диаграмме. Всё, что она говорит про длительности, загрузку и узкие места без ваших замеров, - перенос отраслевой статистики на вашу картинку.
Слои разводит один вопрос: откуда взято каждое утверждение. А разрыв закрывает не более умная модель, а четыре замера, которые снимаются за неделю. До черты, за которой начинаются цифры, ИИ работает отлично. Дальше начинается работа с данными, и делать её всё равно придётся вам.
План на неделю укладывается в пять пунктов, и ни один не требует бюджета.
Разница между двумя ответами и есть та часть, которую модель раньше додумывала за вас.
Новые статьи в вашем электрическом ящике
Обзоры конференций, лучшие практики процессного подхода и учебные статьи в вашей почте. Не чаще 1 раза в неделю.
Без спама, только то, что вы запросили.
