Следующая эволюция в улучшении бизнес -процессов
17 июня 2025 г.Таблица ссылок
Аннотация и 1. Введение
Фон и связанная работа
Метод исследования
Результаты
Дискуссия
Заключение и ссылки
2 предыстория и связанная с ним работа
Организации всех отраслей и размеров выполняют различные комбинации деятельности для достижения желаемых результатов, возможно, это производство физических товаров или предоставление услуг. Эти комбинации деятельности называются бизнес -процессами [1]. Они часто стандартизируются и задокументированы, что означает, что каждый раз, когда организация пытается достичь определенного результата, они используют аналогичную комбинацию действий. Такой стандартизированный бизнес -процесс часто смоделируется графически с моделью бизнес -процесса и обозначениями (BPMN) [22]. BPI является центральной частью BPM [6], а также основной темой этого исследования. Традиционный жизненный цикл BPM (см. Не голубые области и пунктирная стрелка на рисунке 1), как правило, является последовательным [6] и не считает неудачи как «первоклассные граждане». Это означает, что сбои не считаются необходимой частью улучшения и систематически оцениваются, а скорее неприятность, вызванная недостаточным планированием на этапе редизайна; И если произойдет неудача, весь жизненный цикл должен быть повторен.
Более полным подходом к оценке последствий изменений является тестирование AB. Основная цель тестирования AB - быстро определить, улучшит ли конкретное изменение в системном компоненте важные показатели производительности [2]. Начальная и обновленная версия компонента тестируется параллельно с использованием рандомизированных экспериментов в производственной среде (A VS B). Новая версия часто доступна только для избранной группы потребителей, ограничивая любые потенциальные неблагоприятные последствия. Метод стал популярным подходом при обновлении программных систем для бизнеса к потребителям [11].
Особенно динамичный подход к тестированию AB может быть облегчен RL. В то время как контролируемое обучение направлено на то, чтобы научиться маркировать элементы из набора помеченных данных, а обучение без присмотра пытается найти скрытые структуры в немеченых данных, RL имеет цель оптимизации поведения программного агента на основе числового вознаграждения в интерактивной среде [26]. В RL агент расположен в определенной среде и должен принять решение о действии. Затем это действие оценивается, и вознаграждение рассчитывается на основе последствий действия. Цель агента - максимизировать полное вознаграждение, которое он получает. Обучение, какой выбор сделать в какой ситуации, по сути, через систематический подход к проб и ошибкам [26].
Как упоминалось выше, последовательный подход традиционного жизненного цикла BPI не может быстро реагировать на гипотезы улучшения, которые фальсифицированы в реальности. Это решающий недостаток: исследования BPI показали, что 75 процентов идей BPI не привели к улучшению: половина из них не оказала эффекта, а четверть даже имели вредные результаты [7]. Эта проблема может наблюдаться в разных доменах: в исследовании, проведенном в Microsoft, только треть идей по улучшению веб -сайта фактически оказали положительное влияние [12]. Кроме того, сравнение производительности процесса до и после реализации само по себе является проблематичным, потому что изменение факторов окружающей среды может быть основным фактором изменений в производительности процесса (или их отсутствия). Чтобы смягчить эти проблемы, [24] предлагает использование тестирования AB при переходе от анализа на этап реализации. Это будет означать, что переработанная версия развернута параллельно старой версии процесса, что позволяет справедливо сравнить. Поскольку тестирование AB традиционно не используется в таком высоком риске и длительной обстановке, как BPM, авторы [24] применяют RL для облегчения динамического тестирования. С алгоритмами RL мы можем
![Fig. 1. Traditional BPM/AB-BPM lifecycle, adapted from [24,6]; dotted arrow represents flow in traditional BPI lifecycle, blue areas represent additions in AB-BPM lifecycle.](https://cdn.hackernoon.com/images/fWZa4tUiBGemnqQfBGgCPf9594N2-0o033hr.png)
Принимайте решения на основе полученных данных быстрее, уже динамически динамически маршрутизации запросов экземпляров, на более эффективную версию во время самого эксперимента, тем самым минимизируя риск подверженности клиентам на неоптимальные версии процесса слишком долго. В целом, AB-BPM также должен обеспечить более короткий теоретический анализ редизайна, в соответствии с мантрой DevOps «FASH FAST, FASH LOAK». Рисунок 1 (включая синие области, за исключением пунктирной стрелки) представлен улучшенный жизненный цикл AB-BPM.
В дополнение к тестированию гипотез об улучшении, поддерживаемом RL, полный метод AB-BPM предлагает некоторые другие методы тестирования и анализа. Наш запрос фокусируется на тестировании AB-вариантов процесса, поддерживаемом RL: он находится в ядре метода AB-BPM, тогда как другие шаги в AB-BPM просто поддерживают конструкцию тестов AB, поддерживаемого RL. Ссылки на AB-BPM в этой работе ссылаются исключительно на тестирование AB, поддерживаемое RL, варианты бизнес-процессов.
Авторы:
(1) Аарон Фридрих Курц [0000 −0002 −2547 −6780], Technische Universitat Berlin, Берлин, Германия и SAP Signavio, Берлин, Германия (Aaron.kurz@sap.com);
(2) Timotheus Kampik, Sap Signavio, Berlin, Германия (timotheus.kampik@sap.com);
(3) Luise Pufahl, Technische Universitat Munchen, Мюнхен, Германия (luise.pufahl@tum.de);
(4) Ingo Weber [0000 –0002 −4833 −5921], Technische Universitat Munchen, Munich, Германия и Фраунхофер Геселлшафт, Мюнхен, Германия (Ingo.weber@tum.de).
Эта статья есть
Оригинал