comtemichel (comtemichel) wrote,
comtemichel
comtemichel

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

Манифест Анализа Процессов
Даешь реальную Бизнес-Аналитику!
По материалам работ Вила Ван дер Аалста
Исследования в области Анализа процессов (Process Mining), начатые в конце 90-х, лишь недавно попали в поле зрения практиков бизнес-анализа (Business Intelligence). Анализ процессов позволяет пользователям и менеджерам увидеть процессы изнутри, предоставляя ценную информацию для их совершенствования и обеспечивая контроль соблюдения требований нормативных документов. 7 октября 2011 года, Рабочая группа IEEE по Анализу процессов (IEEE Task Force on Process Mining) выпустила Манифест анализа процессов (Process Mining Manifesto). Пятьдесят три организации поддержали данный манифест, 77 экспертов по Анализу процессов внесли в него свой вклад. Активное участие конечных пользователей, поставщиков инструментов анализа, консультантов, аналитиков и исследователей показывает растущее значение анализа в качестве моста между анализом данных (Data Mining) и моделирования бизнес-процессов (Business Process Modeling).

Термин бизнес-анализ (Business Intelligence, BI) соотносится с обширным набором инструментов и методов, использующих данные для поддержки принятия решений. Форрестер [1] определяет BI, как «набор методик, процессов, архитектур и технологий, которые используют выходную информацию процессов управления для анализа, отчетности и управления эффективностью деятельности, и представления информации». Вместе с тем Бизнес-Анализ (как мы помним, в английском тексте используется термин Intelligence, вызывающий ассоциацию с разведкой – но и с интеллектом) – это, к сожалению, оксюморон, поскольку во многих компаниях для контроля и анализа процессов используются достаточно примитивные инструменты. Кроме того, большинство поставщиков решений в области BI предлагают продукты, ориентированные на данные и концентрирующие внимание пользователя внимание на довольно примитивных формах анализа типа «приборных панелей» (dashboard) или «оценочных листов» (scorecard). Как правило, инструменты BI не столь «умны», как это следует из смысла термина, что вызывает недоумение у конечных пользователей, введенных в заблуждение маркировкой BI, используемой поставщиками решений для своих продуктов. Тем не менее, рынок BI-продуктов неуклонно растет, демонстрируя практическую значимость подхода. Поэтому нам необходимо выработать по-настоящему умные подходы к BI, а одним из способов решения данной задачи является использование Анализа процессов (Process Mining). Данный текст представляет собой обобщение недавно выпущенного Рабочей группой IEEE по анализу процессов Манифеста анализа процессов, разъясняя его практическое значение для бизнес-анализа.

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

Анализ процессов представляет собой сравнительно молодую научную дисциплину, занимающую промежуточную позицию между вычислительным интеллектом (computational intelligence) и интеллектуальным анализом данных (data mining) с одной стороны, и моделированием и анализом бизнес-процессов (process modeling and analysis) – с другой. Идея Анализа процессов заключается в том, чтобы выявить, отследить и произвести улучшение реальных (а не предполагаемых) процессов путем извлечения знаний из журналов событий, легко доступных в современных информационных системах [2]. Анализ процессов включает в себя:
•    Автоматизированную идентификацию (выявление) процессов (извлечение моделей процесса из журналов событий),
•    проверка соответствия (мониторинг отклонений путем сравнения моделей и журналов событий),
•    интеллектуальный анализ социальных сетей и организаций,
•    автоматизированное построение имитационных моделей,
•    расширение и пересмотр моделей,
•    ситуационный прогноз и
•    выработку рекомендаций на основе предшествующего опыта организации.
[Прочитать полностью:]Рисунок 1 иллюстрирует рамки Анализа процессов. Отправной точкой для Анализа процессов является журнал событий. Все методы анализа процессов предполагают, что возможно произвести последовательную запись событий таким образом, чтобы каждое событие было сопоставлено с операцией (четко определенным шагом в процессе) и относилось к конкретной ситуации, или экземпляру процесса. Журналы событий могут также хранить дополнительную информацию о событиях. На практике при любом удобном случае методы анализа процессов используют дополнительную информацию, такую как сведения о ресурсе (человеке или машине), выполняющем или инициирующем операцию, дате и времени события, элементах данных, записанных в связи с данным событием (например, о размере заказа).
ProcessMining-fig1
Рис. 1. Методы анализа процессов позволяют извлечь знания из журналов событий для мониторинга и улучшения процессов.

Журналы событий могут быть использованы для проведения трех типов мероприятий по анализу процессов [2, 3]. Первый тип – это структурная идентификация (в английском тексте используется термин discover, дословно – открытие). Метод структурной идентификации создает модели на основе журнала событий, без использования какой-либо априорной информации о процессе. Структурная идентификация процесса – самый известный метод анализа процессов. У многих вызывает удивление факт существования методов, позволяющих выявить структуру реальных процессов на основании одной лишь информации, содержащейся в журналах событий. Второй тип анализа процессов – оценка соответствия процесса. Метод заключается в сравнении существующей модели процесса с журналом событий этого же самого процесса. Например, существуют алгоритмы, позволяющие рассчитать долю событий, которые можно объяснить с помощью модели. Оценка соответствия позволяет оценить, насколько соответствуют друг другу реальное функционирование процесса, описанное журналом событий, и формальная модель этого процесса. К третьему типу мероприятий по анализу процессов относятся действия по повышению эффективности. Идея действий этого типа в том, чтобы расширить или улучшить существующую модель процесса на основании использования информации о процессе, содержащейся в журналах событий. Учитывая, что оценка соответствия процесса направлена на сглаживание противоречий между моделью процесса и его реальным состоянием, этот третий тип анализа процессов направлен на изменение или расширение априорно описанной формальной модели. Например, используя метки в журналах событий, можно расширить модель, таким образом, чтобы увидеть узкие места, уровни обслуживания, производительность и времена выполнения операций, частоты наступления событий.
Рисунок 1 показывает порядок идентификации полной сквозной модели процесса. Модель представлена в нотации BPMN (Business Process Modeling Notation), но встроенные алгоритмы анализа часто используют более формальные способы описания, таких как сети Петри, C-сетей и диаграммы переходов состояний. Воспроизводя события из журнала по модели бизнес-процесса  можно выявить в модели узкие места, правила принятия решений, описать используемые в процессе роли и ресурсы.
Рабочая группа IEEE по Анализу процессов
Растущий интерес к анализу процессов на основе журналов событий вызвал создание Рабочей группы IEEE по Анализу процессов. Задача этой целевой группы заключается в содействии исследовании, развитии, образовании и понимании Анализа процессов. Рабочая группа была учреждена в 2009 году в контексте Технического комитета по интеллектуальному анализу данных (Data Mining Technical Committee) Общества по вычислительному интеллекту (Computational Intelligence Society) IEEE. В состав рабочей группы входят представители более десятка поставщиков коммерческого программного обеспечения (в том числе Pallas Athena, Software AG, Futura Process Intelligence, HP, IBM, Fujitsu, Infosys и Fluxicon), 10 консалтинговых фирм (таких как Gartner и Deloitte), и более чем 20 университетов.
В состав задач рабочей группы входят:
  • Обеспечить распространение в среде конечных пользователей, разработчиков, консультантов, менеджеров и исследователей информации о состоянии дел в области Анализа процессов;
  • содействие использованию методов и инструментов Анализа процессов;
  • стимулировать появление новых приложений Анализа процессов;
  • играть роль в деятельности по стандартизации подходов к протоколированию событий;
  • вести организационную работу в области разработки учебников, проведению специальных занятий, семинаров и групп;
  • публиковать статьи, книги, видео, и специальные выпуски журналов.
  • Например, в 2010 году рабочая группа стандартизировала XES, расширяемый формат регистрации, поддерживающийся библиотекой OpenXES и такими инструментами, как ProM, XESame, и Nitro. Более детально с последними результатами рабочей группы можно ознакомиться на сайте www.win.tue.nl/ieeetfpm.
Манифест Анализа процессов
Манифест Анализа процессов Рабочей группы IEEE по Анализу процессов призван служить ориентиром для разработчиков программного обеспечения, ученых, консультантов, и конечных пользователей, а также для увеличения популярности Анализа процессов как нового инструмента улучшения и пересмотра моделей процессов, управления и поддержки операционных бизнес-процессов. В качестве введения в состояние дел в области Анализа процессов предлагается краткое резюме и основные выводы Манифест [3].
Руководящие Принципы
Как это происходит с любой новой  технологией, применение Анализа процессов в условиях реальной практики грозит очевидными ошибками. Шесть руководящих принципов (Guiding Principles, GP), представленных в Таблице 1, направлены на то, чтобы удержать пользователей и аналитиков от таких ошибок.
Таблица 1. Руководящие принципы Анализа процессов, представленные в Манифесте

GP1: К информации о событиях следует относиться как к «гражданам первого сорта». nbsp; 
События должны быть надежными, то есть, следует предположить, что событие, записанное в журнал произошло на самом деле и что атрибуты событий являются правильными. Журналы событий должны быть полными и полностью видимыми на определенном временном горизонте, ситуация при которой часть событий отсутствует недопустима. Любое событие должно иметь хорошо определенную семантику. Кроме того, должны быть обеспечены условия ограничения доступа и сохранения целостности данных.
GP2: Анализ данных, содержащихся в журналах, должен строиться на вопросах.
Без конкретных вопросов извлечение значимых событий затруднено. Например, при анализе тысяч таблиц в базе данных ERP-системы (таких как SAP) не имея конкретных вопросов вы не будете знать, с какой стороны подступиться к задаче.
GP3: Методы Анализа процессов должны поддерживать возможность анализа ситуаций параллельного выполнения операций, выбора развития процесса по одному из взаимоисключающих вариантов и другие базовые конструкции управления потоком работ.
Основные структуры описания потоков работ, поддерживающиеся во всех основных нотациях моделирования (например, BPMN, ARIS EPC, сети Петри, BPEL и диаграммы деятельности в UML) – последовательность, параллельная маршрутизация (перекрестки типа «И»), выбор (перекрестки типа «исключающее ИЛИ») и петли. Очевидно, что методы Анализа процессов должны поддерживать эти структуры.
GP4: События должны быть сопоставлены с элементами модели.
Для выполнения задач анализа соответствия моделей и повышения эффективности процессов необходимо быть уверенным в надежности сопоставлении отношения между элементами в модели и событиями в журнале. Инструменты анализа процессов могут использовать эти отношения для «проигрывания» журнал событий на модели. Такой прогон может выявить несоответствия между журналом событий и моделью (например, некоторые события в журнале не возможно выполнить при заданной топологии модели). Он также может обогатить модель дополнительной информацией из журнала событий (например, при помощи временных меток указать на узкие места).
GP5: Модели должны рассматриваться как целенаправленная абстракции реальности.
Модель полученная из данных событий позволяет получить представление о реальности. Такой взгляд, должны служить в качестве целенаправленной абстракция поведения, извлеченной из журнала событий. Возможна ситуация когда одному и тому же журналу событий может соответствовать несколько вариантов моделей.
GS6: Анализ процессов должен представлять собой постоянную деятельность.
Учитывая динамичный характер процессов, мы не должны рассматривать Анализ процессов как разовое мероприятие. Целью здесь должно быть не создание раз и навсегда фиксированной модели, а оживление модели процесса, создание стимулов для пользователей и аналитиков на ее пересмотр на ежедневной основе.

Как пример, рассмотрим принцип GP4: «События должны быть сопоставлены с элементами модели». Является заблуждением считать, что Анализ процессов ограничен задачами идентификации структуры модели бизнес-процессов, потока управления. Не менее важны и другие точки зрения, такие как организационный аспект, данные о временах выполнения операций. Однако описание потоков управления (порядка действий) служит тем слоем, к которому подключаются описания прочих аспектов – организационных, временных, ресурсных. Таким образом, этот аспект особенно важен для того, чтобы сопоставить события в журнале с операциями модели бизнес-процесса. После того, как сопоставление событий журнала с элементами модели выполнено, можно «прогнать» журнал событий по модели [2]. Именно после решения этой задачи появляется возможность использования временных меток в журнале событий для анализа зависящего от времени поведения (динамики) модели, а затем, используя временные интервалы между событиями, находящимися в причино-следственной связи, рассчитать параметры распределений, описывающих различные времена модели – выполнения операций, подготовительно-заключительные, ожидания. Эти примеры иллюстрируют важность руководящего принципа, декларирующего необходимость сопоставления событий в журнале и элементов бизнес-модели, как отправной точки для различных видов анализа.

Вызовы
Анализ процесса является важным инструментом для современных организаций, нуждающихся в управлении нетривиальными операционными процессами. С одной стороны, для исследования становится всё больший объем данных о событиях процессах. С другой стороны, процессы и информация должны быть выровнены, идеально подготовлены для того, чтобы выполнялись требования анализа удовлетворенности клиентов, адекватности модели, эффективности процесса и выполнения уровней обслуживания клиентов. Несмотря на применимость анализа процессов, мы по-прежнему находимся перед необходимостью решения важных проблем, что является следствием новизны анализа процессов как научной дисциплины. В таблице 2 перечислены 11 задач (в Манифесте употребляется термин «Вызовы» – Challenges), представленных в Манифесте анализа данных [3].

Таблица 2. Наиболее важные задачи Анализа процессов, определенные в «Манифесте».

C1: Поиск, объединение и очистка данных о событиях
При извлечении данных о событиях, пригодные для анализа процессов, мы должны решить несколько проблем: данные могут быть распределены по разным источникам, данные о событии могут быть неполными, журнал событий может содержать «выпадающие» данные, случайные выбросы, журналы могут содержать мероприятия на различных уровнях детализации, и так далее.
C2: Обработка  сложных журналов событий, имеющих различные характеристики
Журналы событий могут иметь совершенно разные характеристики. Некоторые журналы событий могут быть очень большими, что затрудняет их обработку, в то время как другие – настолько малы, что они не обеспечивают достаточно данных для того, чтобы сделать надежные выводы.
C3: Создание надёжных оценок
Для получения надежных оценок показателей необходимы репрезентативные выборки данных и критерии качества для сравнения и совершенствования различных инструментов и алгоритмов.
C4: Работа с концептуальным дрейфом.
Процесс может успеть измениться за то время, пока идет сбор данных для анализа. Понятие концептуального дрейфа как показателей так и структуры процесса имеет первостепенное значение для управления процессами.
C5: Совершенствование предположений представления.
Точный и аккуратный выбор предположений при формальном описании системы необходим для того, чтобы обеспечить высокое качество анализа процессов.
C6: Сбалансированность для модели таких критериев качества как полезность, простота, точность и уровень абстракции.
Для моделей существует четыре конкурирующих качества: полезность, простота, точность и уровень абстракции. Задача в том, чтобы найти модели, обеспечивающие баланс всех четырех аспектов.
C7: Анализ сквозных процессов нескольких организаций.
В некоторых случаях исследователям доступны журналы событий из нескольких организаций. Некоторые организации, например те, что участвуют в партнерских отношениях цепочек поставок, работают совместно над одним экземпляром процесса; другие организации, выполнять, по сути, тот же процесс, и при этом производят обмен опытом, знаниями, или общей инфраструктурой. Однако, традиционные методы анализа процессов как правило, рассматривают один журнал событий для одной организации.
C8: Предоставление оперативной поддержки
Анализ процессов как правило не может быть выполнен дистанционно, эта работа должна включать также и действия, выполняемые непосредственно и интерактивно. Пример таких действий – структурная идентификация, прогнозирование и рекомендации по улучшению.
C9: Сочетание анализа процессов с другими видами анализа 
Проблема заключается в объединении автоматизированных методов анализа процессов с другими подходами к анализу (методами оптимизации, методами интеллектуального анализа данных, моделирования и визуального анализа и так далее) с целью извлечения большего объема информации из данных о событиях.
C10: Улучшение удобства для пользователей – неспециалистов
Проблема состоит в том, чтобы скрыть сложные алгоритмы анализа процессов за удобным для пользователя интерфейсом, который автоматически установит параметры и предложит соответствующие задаче типы анализа.
C11: Улучшение понятности для неспециалистов
Пользователь может иметь проблемы с пониманием выходных результатов анализа процессов или соблазн сделать ошибочные выводы. Чтобы избежать подобных проблем, инструменты анализа процессов должны использовать соответствующее задаче представление результатов с четкой индикацией достоверности результатов.

Как пример, рассмотрим Задачу C4: «Работа с концептуальным дрейфом значений показателей». Термин «концептуальный дрейф» относится к ситуации, в которой процесс успевает измениться за то время, пока мы его анализируем. Например, в начале журнала событий, два вида деятельности могут совпадать, а позже в журнале, они становятся последовательными. Процессы могут измениться из-за периодических и сезонных изменений (например, «в декабре, больше спрос» или «в пятницу днем, меньше сотрудников доступны») или из-за изменения условий («рынок становится все более конкурентным»). Такие изменения влияют на протекание процессов, и их выявление и анализ жизненно необходимы. Однако, большинство методов анализа процессов рассматривают процессы так, как будто они находятся в устойчивом, стационарном состоянии.

Примеры
В 2004 мы в Эйнховенском Технологическом Университете (Eindhoven University of Technology) начали разработку открытого (open-source) инструмента анализа процессов ProM. В разработке были учтен опыт ранее разрабатываемых инструментов подобного назначения таких, как MiMo, EMiT, и Little Thumb. ProM обеспечивает высокопроизводительную расширяемую архитектуру и общую основу для всех видов анализа процессов. Продукт содержит сотни плагинов, к примеру в виде плагинов представлены десятки алгоритмов структурной идентификации процессов. ProM доступен для скачивания с http://prom.sf.net nbsp; и http://www.processmining.org.
Методы анализа процессов (и, в частности, ProM) были применены более чем в 100 организациях, в том числе:
  • в муниципалитетах, например Алкмаар, Хейсден, и Хардервейк;
  • в государственных учреждениях, например Rijkswaterstaat, Centraal Justitieel Incasso бюро, и голландское Министерство Юстиции
  • в страховых учреждениях, например UWV;
  • в банках, например ING;
  • в больницах, например AMC и госпиталь Катарины;
  • в многонациональных корпорациях, например DSM и Deloitte;
  • в компаниях – производителях высокотехнологичных систем, например Philips Healthcare, ASML, Ricoh, и Thales, и у их клиентов;
  • в медиа-компаниях, таких как Winkwaves.
Список иллюстрирует широкий спектр ситуаций, к которым можно применить анализ процессов. Для того, чтобы проиллюстрировать эти возможности более подробно приведем два примера по структурной идентификации процессов, анализу соответствия процессов и улучшению бизнес-процессов [2].
Больница представляет собой особенно сложный объект с точки зрения идентификации структуры процессов: объем регистрируемых в больницах данных очень велик, но при этом рабочие процессы, как правило, весьма нестабильны. Мы провели несколько экспериментов по анализу процессов, основанные на данных о событиях в больнице AMC в Амстердаме. На рисунке 2 показан пример модели процесса, построенной для больницы с помощью ProM. Модель была идентифицирована на основе данных событий группы 627 гинекологических онкологических больных, проходивших лечение в 2005 и 2006 годах. Лапшеподобная диаграмма хода процесса показывает, что существующие процессы оказания услуг весьма слабо структурированы. Более подробный анализ модели на Рис. 2 позволил выделить «магистральные пути» в процессе диагностики и лечения больных. Зачастую приходилось сталкиваться с тем, что пресловутое правило  «20/80» действительно работает, то есть, 80% случаев следуют магистральным путями в процессе и составляют лишь 20% от сложности модели.
ProcessMining-fig2
Рис. 2. Лапшеподобный процесс, идентифицированный на основе журнала событий, содержащего 24,331 событие, связанных с лечением 627 гинекологических больных с онкологическими заболеваниями и включающий 376 технологических операций.

Также, на сегодняшний день, анализ процессов применялся примерно в десяти муниципалитетах. Кроме того, в прошлом году был начат новый проект: CoSeLoG (Настраиваемые Услуги для Местного Самоуправления). Десять муниципалитетов участвуют в CoSeLog, и все они заинтересованы в перекрёстном анализе процессов, в исследовании различий между однотипными процессами в разных муниципалитетах. Процессы в рамках муниципалитетов, как правило, структурированы, но интересно было выяснить, что муниципалитеты, как правило, делают по-разному (пресловутый «местный колорит»). Решение этой задачи могло бы помочь в объяснении больших различий в параметрах эффективности процессов (время реакции на обращение, численность вовлеченного в процесс персонала и так далее).
 
ProcessMining-fig3
Рис. 3. Анализ производительности на основе модели процесса, построенной для голландских муниципалитетов.

На рисунке 3 показана модель «Процесса оценки недвижимости», идентифицированная для голландского муниципального образования на основе журнала событий, содержащий информацию о 745 претензиях против актов оценки недвижимого имущества (в оригинале используется голландский термин WOZ – WaarderingOnroerendeZaken). Голландские муниципалитеты используют оценку недвижимости – стоимости домов и квартир – в качестве базы для расчета налога на имущество. Чем выше сумма оценки недвижимости, тем больше сумма налога на владельца. Таким образом, голландские муниципалитеты должны обрабатывать множество заявлений и претензий от граждан, которые утверждают, что значения стоимости их недвижимости завышены при оценке.
Рисунок 3 показывает, ход обработки таких претензий. Прямоугольники представляют собой работу (задачу), а дуги описывают причинно-следственную связь. С помощью меток в журнале событий на модели отображаются различные показатели. Идентифицированная модель процесса имеет высокий показатель качества, равный 0.98876214, что говорит о том, что модель объясняет практически все зарегистрированные в журнале события. Средний расход времени на обработку претензии составляет примерно 178 дней, стандартное отклонение составляет около 53 дней. На рис. 3 показаны еще несколько метрик, связанных с производительностью процесса, вычисленных в процессе просмотра журнала событий, дополненных временными метками.
ProM также визуализирует цветом узкие места в сети потоков работ. В позициях, помеченных фиолетовым цветом, задания как правило задерживаются надолго. Например, через интервал между событиями «OZ16 Uitspraak Start» и «OZ16 Uitspraak Complete» процесс прошел 436 раз. Среднее время,  затраченное одним заданием в этом интервале составляет 7.84 дня. Это означает, что деятельность «OZ16 Uitspraak» (окончательное решение) займет около недели. Позиция перед «OZ16 Uitspraak Start», также маркировано фиолетовый; в среднем интервал времени от начала обработки претензии до этого события занимает 138 дней. Как показано на Рисунке 3, можно просто выбрать две задачи и измерить время, которое проходит между ними. В среднем между завершением операции «OZ02 Voorbereiden» (подготовка) и завершением операции «OZ16 Uitspraak» (окончательное решение) проходят 202.73 дня. Стоит обратить внимание на тот факт, что это больше, чем общий средний расход времени на обработку претензии, поскольку лишь 416 возражений (около 56 процентов) следуют по этому маршруту, а в остальных случаях процесс идет по ветви «OZ15 Zelfuitspraak», среднее время выполнения для которой короче.
Рисунок 3 показывает, как анализ процесса помогает организации увидеть свои процессы изнутри. Такой подход резко контрастирует с реализованными в современных инструментах бизнес-анализа, в которых внимание, по-видимому, сосредоточено на отчетности и забавных панельках.
Как получить больше информации об анализе процессов?
Манифест анализа процессов доступен на www.win.tue.nl/ieeetfpm и переводится на китайский, немецкий, французский, испанский, греческий, итальянский, корейский, голландский, португальский, турецкий и японский языки. Другие хорошие ресурсы на по анализу процессов: последние книги В. Ван дер Аалста  «Анализ процессов: Идентификация, Анализ соответствия и Улучшение Бизнес-процессов», и сайт  www.processmining.org, на котором выложены бразцы журналов событий, видеофильмы, презентационные материалы, статьи, и программа ProM.

Ссылки
  1. Forrester, «The Forrester Wave: Enterprise Platform Business Intelligence» www.forrester.com, 4 квартал 2010 года.
  2. W. van der Aalst, Process Mining: Discovery, Conformance and Enhancement of Business Processes, Springer-Verlag, 2011., Springer-Verlag, 2011 г.
  3. W. van der Aalst et al., “Process Mining Manifesto,” Business Process Management Workshops, LNBIP 99, F. Daniel, K. Barkaoui and S. Dustdar, eds., Springer-Verlag, 2011.
Tags: бизнес-процессы, консалтинг, управление
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 0 comments