Симулируйте и оптимизируйте BPMN‑процессы с AI. Найдите узкие места и сократите затраты до внедрения

Мы симулируем каждое событие отдельно. Каждая заявка это объект со своим жизненным циклом. Каждый ресурс это состояние которое меняется по событиям. Очереди это структуры с временными метками. Никаких усреднений или формул из таблиц. Только дискретные события и переходы состояний.

Поддерживаем все стандартные распределения вероятностей для времени выполнения задач. Экспоненциальное для процессов без памяти. Нормальное для задач с предсказуемым средним и вариативностью. Равномерное когда время в чётких границах. Детерминированное когда время фиксированное. Можете задать своё распределение, если нужно.

После каждой симуляции проверяем корректность модели через закон Литтла. Среднее количество заявок в системе должно равняться интенсивности потока умноженной на среднее время пребывания. Если расхождение больше пяти процентов показываем предупреждение. Если меньше — модель валидна и результатам можно верить.

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

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

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

Любая имитация начинается с разогрева. Система пустая, ресурсы свободны, очередей нет. Это не установившийся режим. Мы определяем когда процесс стабилизировался. Смотрим на скользящее среднее производительности и длины очередей. Когда вариативность падает ниже порога — установившийся режим достигнут. Только метрики после этого момента идут в финальный отчёт.

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

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

Дальше анализ по принципу Парето: сортируем задачи по стоимости от большей к меньшей. Считаем накопленный процент.

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

Показываем, что оптимизация категории А даёт максимальный эффект.

Ресурс стоит денег даже когда простаивает. Если вы платите зарплату менеджеру пятьдесят долларов в час, то час простоя это тоже пятьдесят долларов потерь. Мы разделяем время работы когда ресурс выполняет задачи и время простоя, когда ресурс свободен.

Считаем стоимость отдельно. Берём среднюю мощность и среднюю занятость из движка имитации. Разница это простой. Умножаем на время симуляции и часовую ставку получаем стоимость простоя. Показываем процент от полной стоимости ресурса. Если стоимость простоя больше тридцати процентов - это сигнал что ресурс недозагружен и можно оптимизировать.

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

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

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

Учитываем выходные и праздники если задали.

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

Нет. Если вы умеете рисовать BPMN в Storm (а вы умеете!), то справитесь с симуляцией. Интерфейс простой: укажите сколько заявок, сколько времени задачи, сколько ресурсов — всё.

Мы валидируем каждую симуляцию через закон Литтла и теорию очередей . Если ошибок< 5% — результаты точные. Если ошибок> 15% — покажем предупреждение.

В реальных кейсах: совпадение с реальностью на 90-95%.

В среднем 40 минут для процесса из 15-20 задач, если у вас есть нужные данные.

Да! Мы поддерживаем шлюзы И, ИЛИ, распределения, календари ресурсов.

Arena/Simul8 — отдельные инструменты. Нужно рисовать процесс с нуля. У нас: ваш BPMN уже нарисован в Storm. Просто добавьте параметры и запустите.

Да! JSON, CSV, PDF.

• Видео-туториалы (5-10 минут каждый)
• Документация с примерами
• Вебинары раз в месяц 
• 1-on-1 обучение для Enterprise