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

Инструменты бизнес-анализа (business intelligence, BI) помогают принимать решения на основе данных о событиях, вместе с тем под всевозможными сложными аббревиатурами, объединенными понятием бизнес-анализа, скрываются простые методы формирования отчетов и информационных панелей: BAM (business activity monitoring — «мониторинг бизнес-активности»), CPM (corporate performance monitoring — «мониторинг эффективности предприятия»), CPI (continuous process improvement — «непрерывное совершенствование процессов») и BPI (business process intelligence — «анализ бизнес-процессов»). Лишь немногие инструменты бизнес-анализа предлагают развитые возможности добычи данных, но они не являются процессно-ориентированными, а предназначены для извлечения сведений, помогающих в принятии тактических решений, и не охватывают процесс как таковой.

Инструменты управления бизнес-процессами (business process management, BPM), в свою очередь, позволяют с помощью соответствующих моделей анализировать текущие и планируемые операционные процессы, но, к сожалению, эти модели часто не соотносятся с реальными данными по событиям. Как следствие, результаты такого анализа ненадежны, поскольку основаны на идеализированной модели, а не на реально наблюдаемых фактах.

Задача анализа процессов (process mining) — заполнить пробел между BI и BPM путем одновременного использования данных о событиях, хранящихся в рабочих журналах и моделей процессов. В отличие от традиционных подходов, цель анализа процессов не в том, чтобы однократно сконструировать статичную модель, — аналитик строит динамически меняющуюся карту процесса на основании актуальных данных, чтобы делать прогнозы или отвечать на конкретные вопросы.

Анализ процессов

Отправной пункт анализа процессов — получение протокола событий. Каждое событие сопоставляется с действием (четко определенным этапом некоторого процесса) и относится к конкретному прецеденту (case) или экземпляру процесса. События каждого прецедента упорядочены и описывают один «проход» процесса. В протоколах могут сохраняться и другие данные, связанные с событиями. В сущности, в методах анализа процессов всегда используются дополнительные сведения (например, о человеке или устройстве, исполняющем или запускающем действие), указываются даты (временные отметки) и прочие атрибуты и показатели процесса (например, размер заказа).

Анализ процессов состоит из трех этапов (рис. 1). На первом аналитик с помощью методов (альфа-алгоритмов) распознавания процесса (process discovery) восстанавливает модель, используя протокол событий. Эту начальную модель процесса также можно построить вручную. Затем с помощью механизмов проверки соответствия (conformance checking) диагностируются расхождения между протоколом событий и начальной моделью процесса. Наконец, на этапе доработки модели (model enhancement) с помощью сохраненных в протоколе показателей процесса модель исправляется или дополняется. Например, по отметкам времени к ней можно добавить информацию о сроках (время ожидания и время обслуживания). Результирующую доработанную модель процесса можно применять для принятия решений.

Анализ процесса: а — c помощью алгоритмов распознавания процесса по протоколу событий автоматически строится модель; б — на этапе проверки соответствия выявляются различия между наблюдаемым и смоделированным поведением; в — начальная модель дорабатывается с использованием данных о событиях
Рис. 1. Анализ процесса: а — c помощью алгоритмов распознавания процесса по протоколу событий автоматически строится модель; б — на этапе проверки соответствия выявляются различия между наблюдаемым и смоделированным поведением; в — начальная модель дорабатывается с использованием данных о событиях

 

Распознавание процесса

События относятся к экземплярам процесса, например, анализ крови в больнице относится к лечению пациента, а платежная транзакция относится к заказу покупателя. Все события, относящиеся к определенному экземпляру (прецеденту) процесса, можно упорядочить. Так как эти события также относятся к действиям, то каждый прецедент можно представить в виде очередности (trace) имен действий.

Предположим, что процесс включает действия А, Б, В, Г и Д, которые могут располагаться в следующей очередности: АБВД, АВБД и АГД. Допустим, что протокол событий, записанный для этого процесса, содержит информацию о 238 прецедентах с очередностью АБВД, о 56 прецедентах с очередностью АВБД и о 88 прецедентах с очередностью АГД. Алгоритмы распознавания процессов могут преобразовать этот протокол событий в модель процесса, адекватно описывающую наблюдаемое поведение. В данном случае легко сконструировать процесс, который всегда начинается с действия А, оканчивается действием Д, а между ними происходят либо Б и В (в любом порядке), либо Г.

Распознавание модели процесса, состоящего из десятков или даже сотен действий, гораздо сложнее. На рис. 2 показаны фрагмент большого протокола событий процесса обработки страхового требования и автоматически построенная по нему модель в виде блок-схемы в нотации BPMN (Business Process Modeling Notation). На ее примере можно наблюдать одновременность, выбор, циклы и другие конструкции потока управления, идентифицированные из очередности событий в приведенном образце протокола.

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

 

Процесс, представленный на рис. 2, всегда начинается с действия «регистрация запроса» и оканчивается выплатой возмещения или отказом. Действия «изучение» и «проверка квитанции» происходят одновременно. Изучение бывает двух типов. Решение о выплате или отказе принимается в зависимости от результата проверок. Также бывает, что принять решение нельзя. Действие «повторный запрос» вновь запускает действия проверки, тем самым формируется цикл.

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

Проверка соответствия

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

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

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

Доработка модели

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

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

Google Maps для бизнес-процессов

На врезке «Манифест анализа процессов» перечислены базовые принципы и нерешенные проблемы технологии анализа процессов, сформулированные комитетом IEEE по анализу процессов. Сверхзадача анализа процессов — предоставить организациям подобие сервиса Google Maps для операционных бизнес-процессов.

 

Манифест анализа процессов

Растущий интерес к анализу процессов по протоколам событий стимулировал образование в 1999 году соответствующего комитета IEEE, содействующего исследованиям, разработке и пониманию принципов анализа процессов. В комитет входят представители компаний, работающих на рынке BPM, включая Software AG, HP, IBM и Fujitsu, а также аналитики из Gartner и Deloitte и специалисты из более 20 университетов.

Недавно комитет опубликовал «Манифест анализа процессов», в котором излагаются 6 руководящих принципов и 11 проблем. Манифест поддержали 53 организации, а в его составлении приняли участие 77 экспертов в области анализа процессов. Большой интерес со стороны пользователей, разработчиков, консультантов, аналитиков и исследователей подчеркивает растущую важность анализа процессов как моста между бизнес-анализом и управлением бизнес-процессами.

Руководящие принципы манифеста перечисляют оптимальные методы анализа процессов. Например, четвертый принцип гласит, что события должны относиться к элементам модели. Распознавание процесса — это лишь начальный этап анализа и усовершенствования процесса. Инструменты анализа процессов способны заново «проигрывать» протокол событий для выявления расхождений с моделью — например, некоторые события в протоколе, согласно модели, могут быть невозможны. По отметкам времени в протоколе событий автоматизированные инструменты могут анализировать временные характеристики процесса. Благодаря выявлению узких мест аналитики могут усовершенствовать процесс или подготовить прогноз по текущим прецедентам.

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

 

Для каждого процесса в любое время должна быть доступна его актуальная «карта», которую аналитики могли бы легко масштабировать. Как в Google Maps, при уменьшении масштаба менее важные элементы и маршруты должны исчезать или сливаться в агрегаты. Должна быть также возможность отражать на карте процессов информацию реального времени, чтобы информационные системы могли визуализировать «заторы» в процессах и предлагать альтернативные маршруты для прецедентов, отстающих от графика.

***

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

Вил ван дер Аалст (w.m.p.v.d.aalst@tue.nl ) — профессор Эйндховенского технического университета (Голландия) и Квинслендского технического университета (Австралия). Вил ван дер Аалст — автор 135 научных работ и 17 книг, оказавших значительное влияние на развитие индустрии процессно-ориентированных информационных систем. Среди оригинальных разработок, выполненных под руководством Аалста, язык описания бизнес-процессов YAWL, инструментарий ProM для извлечения исторических данных об исполнении процесса, средства описания и анализа бизнес-процессов Declare, Woflan и XRL. Особое внимание в работах Аалста уделяется проблеме извлечения исторических данных об исполнении процесса для их использования при выявлении ошибок моделирования и для улучшения способов исполнения работ. 

Wil van der Aalst, Using Process Mining to Bridge the Gap between BI and BPM. IEEE Computer, December 2011, IEEE Computer Society. All rights reserved. Reprinted with permission.