Лекция
Привет, сегодня поговорим про средства анализа процессов , обещаю рассказать все что знаю. Для того чтобы лучше понимать что такое средства анализа процессов , process mining , настоятельно рекомендую прочитать все из категории Интеллектуальный анализ данных.
Рассмотренные средства автоматизации бизнес-процессов (бизнес-процессы, формализация бизнес-процессов, Workflow-системы, сервисно-ориентированная архитектура, проектирование бизнес-процессов). выполненный анализ процессов (технология Process Mining, анализ протоколов, стандарт записи
протоколов MXML, задачи Process Mining, проблемы анализа протоколов).
Сравниваются методы Process Mining (первые вероятностные методы Process Mining, метод построения дизъюнктивной Workflow-схемы, (-алгоритмы, ме
тоды на основе генетических алгоритмов). Описанная библиотека алгоритмов Process Mining-Pro (архитектура Pro, Pro Import Framework).
ПЛАН
1 Автоматизация выполнения бизнес-процессов (бизнес-процессы, формализация бизнес-процессов, Workflow-системы, сервисно-ориентированная архитектура, проектирование бизнес-процессов).
2 Анализ процессов (технология Process Mining, анализ протоколов, стандарт записи протоколов MXML, задачи Process Mining, проблемы анализу протоколов).
3 Методы Process Mining (первые вероятностные методы Process Mining, метод построения дизъюнктивной Workflow-схемы, -алгоритмы, методы на
основе генетических алгоритмов) .
4 Библиотека алгоритмов Process Mining- Pro (архитектура Pro, Pro Import Framework).
Бизнес на сегодняшний день представляет собой достаточно сложный процесс, включающий в себя разного рода связанных друг с другом активностей, в том числе взаимодействующих с другими участниками бизнеса. Двести лет назад Адам Смит предложил разбивать индустриальное производство на простейшие и базовые операции. Он показал, что разделение труда способствует росту его производительности. Современные экономисты предлагают для облегчения понимания и управления бизнесом объединять разрозненные операции в единые процессы, называемые бизнес-процессами.
Впервые понятие бизнес-процесса было введено Майклом Хаммером и Джеймсом Чампи в работе "Реинжиниринг корпорации: Манифест революции в бизнесе" [123]. Они дали следующее определение:
Бизнес-процесс — это совокупность различных видов деятельности, в рамках которой "на входе" используются один или более видов ресурсов, и в результате этой деятельности на "выходе" создается продукт, представляющий ценность для потребителя.
Существует достаточно много определений данного термина, отличающихся тонкостями, но совпадающих в главном:
Бизнес-процесс (БП) — последовательность операций, в ходе выполнения которых получается значимый для организации результат (продукты, услуги).
Примерами таких бизнес-процессов являются: кредитные запросы, требования по страховке, электронная коммерция и др.
Автоматизация выполнения бизнес-процессов и привлечение информационных систем для их поддержки привели к тесной интеграции информационных технологий и бизнеса. В настоящее время широкую популярность получили следующие технологии:
Представление БП в виде последовательности связанных друг с другом операций упростило задачу автоматизации бизнеса. Соответствующие информационные системы стали рассматривать бизнес-процессы как строго заданный поток работы. Системы такого класса получили название системы Workflow.
Согласно определению, данному некоммерческой коалицией WfMC (Workflow Management Coalition), объединяющей более 300 компаний Workflow, — это автоматизация всего или части бизнес-процесса, в течение которого документы, информация или задачи передаются от одного участника к другому для их обработки в соответствии с набором процедурных правил.
Сложность автоматизации бизнес-процесса связана с тем, что не все действия, выполняющиеся в его рамках, можно описать формально и, как следствие, автоматизировать. По степени формализуемости бизнес-процессы можно классифицировать на:
Структурированные процессы предопределены заранее, и процесс их выполнения никогда не отклоняется от установленного порядка. Противоположностью данного типа процессов являются неструктурированные процессы, которые фокусируются на совместном использовании информации, и те, которые управляются данными. Их структура не может быть определена заранее, поэтому они не подходят для автоматического выполнения. С другой стороны, они дают больше свободы пользователям. Слабоструктурированные процессы находятся в промежутке между предыдущими двумя крайностями. Они имеют большую гибкость, чем структурированные процессы, т. к. их выполнение более неопределенно и им приходится иметь дело с исключе-
ниями и изменениями. Однако, в отличие от неструктурированных, они могут быть описаны с достаточной степенью формализации. Структура таких процессов моделируется заранее и скорее служит рекомендациями пользователям, но не строгим регламентом.
Можно сформулировать следующие требования, которые предъявляются к бизнес-процессу, чтобы его было возможно автоматизировать:
процесс можно выделить из всей массы выполняемых на предприятии работ, заданий и действий;
процесс должен иметь структуру — не быть вырожденным, состоящим из одной-единственной операции;
должны быть правила выполнения процесса, которые можно сформулировать и формально описать, которые касаются последовательности выполнения операций, условий и предусмотренной реакции на внешние события;
процесс должен быть периодическим — он должен повторяться на предприятии, иначе его не имеет смысл автоматизировать.
Если процесс удовлетворяет первым трем требованиям, то его можно формализовать. Последнее требование обеспечивает целесообразность автоматизации процесса.
Как уже говорилось, поток работ (Workflow) — это формальное описание бизнес-процесса, которое используется для его автоматизации.
Организация WfMC выделяет следующие основные понятия, составляющие Workflow:
В зависимости от того, какие из перечисленных сущностей рассматривать как базовые — бизнес-процесс можно анализировать с разных точек зрения — перспектив:
На практике в настоящее время широко используется только перспектива управления потоком. Рассмотрим ее более подробно.
Перспективу управления потоком можно представить как направленный граф. Узлы графа могут соответствовать двум сущностям бизнес-процесса: шагу процесса или маршрутному узлу. Узлы графа соединяются дугами, соответствующими переходам бизнес-процесса. По переходам перемещается точка управления (указатель на активный узел процесса), руководствуясь правилами в маршрутных узлах.
В узле, соответствующем шагу процесса, происходит выдача задания исполнителю (человеку или информационной системе) и ожидание ответа (сообщения о том, что работа выполнена). К узлу, соответствующему шагу процесса, может примыкать только один входящий и один исходящий переход.
Маршрутный узел соответствует разветвлению/слиянию точек управления.
Втаких узлах на основании содержащихся в маршрутных узлах правил выбирается следующий узел (узлы), в который будет передано управление. Поэтому с ними обязательно связано более одного входящего или исходящего перехода.
Ввыполняющемся бизнес-процессе одновременно может быть несколько точек управления. В соответствии с бизнес-логикой процесса точка управления в маршрутном узле может разделиться на несколько точек управления. Кроме того, точки управления могут ожидать друг друга в маршрутном узле и объединяться в нем в одну точку.
Описанный граф обычно представляется в виде сети Петри. Пример перспективы управления потоком в формализме сетей Петри изображен на рис. 15.1.
Рис. 15.1. Пример перспективы управления потоком бизнес-процесса:
1, 2, 4, 5, 6 — узлы, соответствующие шагам бизнес-процесса; 3 — маршрутный узел, в котором по определенным правилам принимается решение о переходе к узлу 4 или узлу 6.
Узел 2 в текущий момент времени является активным, т. к. в нем расположена точка управления
Workflow-системы работают по одному общему принципу. Они получают на вход описание бизнес-процесса на формальном языке. Такое описание называется схемой. Как правило, схема представляется в графическом виде и является направленным графом (рис. 15.2).
Рис. 15.2. Пример Workflow-схемы
По описанной схеме система переводит процесс из одного узла в другой. В зависимости от действий, выполняемых исполнителями системы, значения переменных процесса могут быть разными, следовательно, переходы в узлах маршрутизации будут отличаться. Таким образом, реальное выполнение процесса будет охватывать не все узлы схемы.
Узлы схемы, участвующие в выполнении реального процесса, называются экземпляром процесса. Системы класса Workflow обеспечивают выполнение множества экземпляров процесса, в том числе и одновременное. На рис. 15.3 представлен пример экземпляров процесса, отмеченных на схеме серыми и черными линиями.
Рис. 15.3. Пример экземпляров процесса
В настоящее время все более популярной становится сервисно-ориенти- рованная архитектура (service-oriented architecture — SOA). Основные принципы, лежащие в ее основе, во многом совпадают с принципами Workflowсистем. По этой причине последние все больше вытесняются системами, построенными на принципах SOA.
Сервисно-ориентированная архитектура — подход к разработке программного обеспечения, основанный на использовании сервисов (служб) со стандартизированными интерфейсами.
Компоненты систем могут быть распределены по разным узлам сети и предлагаются как независимые, слабо связанные, заменяемые сервис-приложе- ниями.
Наиболее широко компоненты таких систем реализуются как Web-сервисы. Web-сервис (web service) — программная система, идентифицируемая строкой URI, чьи публичные интерфейсы и привязки определены и описаны языком XML. Описание этой программной системы может быть найдено другими программными системами, которые могут взаимодействовать с ней согласно этому описанию посредством сообщений, основанных на XML и передаваемых с помощью интернет-протоколов.
Концепция сервис-ориентированной архитектуры подразумевает, что отдельные Web-сервисы обладают определенной ограниченной функциональностью. А для решения более-менее сложных задач требуется использовать функциональность нескольких сервисов. Поэтому для описания взаимодействия сервисов и последовательности их выполнения используют оркестровки (Web Service Choreography).
Для описания систем и приложений, построенных по принципам сервисноориентированной архитектуры, на уровне модели бизнес-процесса ведущими IT-компаниями предлагались различные проекты стандартов:
и др.
Кнастоящему моменту наибольший вес имеют:
Оба этих проекта были приняты в организации, стандартизирующей технологии архитектуры Web-сервисов. WSCI с 2002 г. развивается рабочей группой консорциума W3C (организована рабочая группа Web Services Choreography Working Group). Для развития BPEL4WS в 2003 г. в консорциуме OASIS был создан технический комитет — OASIS Web Services Business Process Execution Language TC (WS-BPEL TC).
Стандарты оркестровки опираются на стандартизованное описание Webсервисов — WSDL. Web-сервисы, участвующие во взаимодействии, представлены своими интерфейсами.
Независимо от средств автоматизации бизнес-процессов (Workflow-системы или SOA) процесс постановки бизнес-процесса без привлечения автоматизированных средств достаточно трудоемок.
Жизненный цикл бизнес-процесса состоит из четырех этапов:
1.Проектирование процесса.
2.Конфигурирование процесса.
3.Выполнение процесса.
4.Диагностика процесса.
За проектирование процесса отвечает бизнес-эксперт. Он на основании своих знаний о предметной области и процессах, протекающих в ней, строит модель бизнес-процесса.
На этапе конфигурирования выполняется настройка построенной на предыдущем этапе модели для конкурентных условий эксплуатации. При этом учитываются ограничения и особенности системы, автоматизирующей данную модель.
Во время выполнения процесса его исполнители, взаимодействуя с информационной системой, решают автоматизированные задачи. При этом все экземпляры реально протекающих процессов сохраняются информационной системой.
Используя эту информацию, можно на этапе диагностики выполнить анализ реальных процессов в сравнении с построенной моделью. Такой анализ может позволить выявить отклонение модели от реальных процессов, пути улучшения или оптимизации модели и т. п.
На основании результатов анализа в модель могут быть внесены изменения. Таким образом, опять начинается этап проектирования и весь цикл повторяется.
В программных средствах, автоматизирующих бизнес-процессы, вся информация о выполненных экземплярах процесса записывается в протоколы работы.
За все время работы программных средств протоколы работы накапливают большой объем информации о реальных процессах, выполняемых в компании. Безусловно, данная информация является ценной, а ее анализ позволяет извлечь новые знания о бизнес-процессах. Для этого к регистрационным журналам применяются адаптированные методы Data Mining.
Применение методов Data Mining для анализа информации о реальных процессах, выполняемых системами, автоматизирующими бизнес-процессы, получило в литературе название Process Mining. Часто в литературе также встречается и понятие Workflow Mining. Многие авторы сходятся во мнении, что эти два термина являются синонимами. Однако существуют и те, кто вкладывает в эти термины разный смысл. Они дают следующие определения:
Workflow Mining — технология выявления часто встречающихся экземпляров процессов (шаблонов) из протоколов работы систем;
Process Mining — технология построения формальных моделей экземпляров процессов по протоколам работы систем.
Как видно, данные определения действительно очень близки по смыслу. В обоих случаях требуется построение формального описания реального процесса, выполненного системой, по информации, представленной в ее протоколе работы. Это более близко к понятию Process Mining, поэтому в дальнейшем мы будем пользоваться данным термином.
Основная идея методов Process Mining изображена на рис. 15.4. Методы Process Mining применяются к протоколам работы информационных систем. В них отражается реальное выполнение бизнес-процессов через взаимодействие их исполнителей с информационными системами. Применение к ним методов Process Mining позволяет автоматически построить модели бизнеспроцессов.
Построенные таким образом модели бизнес-процессов отражают реальность и доступны для восприятия и анализа человеку. На основании их анализа могут приниматься решения о внесении изменений в бизнес-процессы и/или о модернизации и настройке информационной системы.
Process Mining находит широкое применение во многих областях бизнеса и управления, т. к., в отличие от обычного моделирования, получаемые с помощью алгоритмов Process Mining модели строятся на основе записей о реально происходивших событиях, поэтому более адекватно отображают действительность и несут информацию о том, что происходило в реальности, а не о том, что было запланировано. Кроме того, в некоторых областях моделирование может быть затруднено или очень трудоемко, тогда как Process Mining позволяет автоматизировать процесс.
Рис. 15.4. Применение Process Mining
Как видно из предыдущего раздела, источником информации для технологии Process Mining является протокол работы информационных систем. Однако для анализа может быть использован не каждый протокол. Нужно, чтобы в нем была информация, достаточная для применения методов Process Mining. К необходимым требованиям можно отнести следующее:
все события, записанные в протоколе, должны быть идентифицированы с экземплярами процессов;
все события должны быть упорядочены по времени их выполнения;
разнотипные события должны различаться.
Втабл. 15.1 приведен пример протокола работы информационной системы.
Внем о каждом событии записана следующая информация: описание действия, шаг процесса, пользователь, инициировавший событие, время записи события. Кроме того, все действия сгруппированы по экземплярам процессов.
Вданном протоколе все требования выполнены. Однако часто не требуется столь подробная информация. Для методов Process Mining, как правило, не имеет значения, кто выполнил те или иные действия. В табл. 15.2 представлен пример более простого протокола, к которому применимы методы Process Mining.
Вданном протоколе также выполнены все перечисленные ранее требования.
Врезультате по нему может быть построена модель процесса, представленная на рис. 15.5.
Для закрепления требований и унификации протоколов, обрабатываемых алгоритмами Process Mining, был предложен стандарт записи протоколов MXML (Mining XML).
MXML — это расширяемый формат, основанный на языке разметки XML (eXtensible Markup Language). Он используется для представления и хранения информации в виде логов событий. Формат фокусируется на ключевой информации, необходимой для применения методов Process Mining, однако существует возможность расширения формата для записи дополнительной информации.
Структура MXML-формата изображена на рис. 15.6 в виде диаграммы классов.
Рис. 15.6. UML-диаграмма MXML-формата
Корневым узлом каждого MXML-документа является WorkflowLog, представляющий лог-файл. Каждый WorkflowLog может содержать произвольное количество узлов Process. Каждый элемент типа Process является группой событий, которые произошли в течение выполнения какого-либо процесса. Однократные выполнения этого процесса представлены элементами типа ProcessInstance. Таким образом, каждый ProcessInstance представляет собой однократное протекание процесса. Каждый ProcessInstance содержит группу из произвольного количества элементов типа AuditTrailEntry (контрольные записи), каждая из которых соответствует уникальному событию в логе. Каждая контрольная запись должна содержать как минимум два элемента:
WorkflowModelElement (название задачи, которая была выполнена) и EventType (тип события, который описывает стадию выполнения задачи). Формат также поддерживает два необязательных, но, тем не менее, часто встречающихся поля. Timestamp содержит точную дату и время, когда событие произошло, а Originator идентифицирует ресурс, т. е. человека или информационную систему, которые являлись инициатором события. Расширяемое поле Data может содержать произвольное количество атрибутов, которые являются парами строк <название-значение>.
Главной целью Process Mining является автоматизированное выявление перспектив бизнес-процессов, и их представление в виде понятных человеку моделей. Это позволяет облегчить решение следующих задач, встающих в области автоматизации бизнес-процессов:
построение модели процесса на основании имеющегося лога событий работающей информационной системы;
проверка соответствия реального экземпляра процесса базовому;
автоматическое восстановление систем после сбоев;
улучшения и расширение процессов.
Построение модели бизнес-процесса позволяет упростить задачу формализации процессов и их автоматизации. При проектировании и создании Workflow-систем описание потока работ возлагается на эксперта в данной предметной области. Это достаточно сложная задача, и от качества ее решения во многом зависит успешность внедрения системы. Человек, описывающий процесс, должен не только очень хорошо представлять его себе, но и суметь его формализовать. Задача усложняется тем, что такие автоматизируемые процессы охватывают разные виды деятельности, в которых экспертами являются несколько человек.
Кроме сложности построения модели потока работ, возникает проблема, связанная с ее неактуальностью. Дело в том, что при описании модели, как правило, описывается то, "как должно работать", а не "как работает на самом деле".
При проверке процесса модель уже существует, требуется сравнить ее с логом событий и выявить различия. Проверка соответствия позволяет выявить отклонения, определить их местоположение в модели и оценить степень их серьезности.
Выявление отклонений реальных процессов может быть использовано для восстановления информационных систем после аварийных остановок. Анализ протоколов позволяет определить, что выполнялось системой до ее ава-
рийного завершения. Выявленные отклонения могут помочь в определении причин сбоя, а также восстановить результаты работы системы после ее восстановления.
Улучшение и расширение процессов также предполагает, что модель уже существует, требуется дополнить ее другими аспектами, или перспективами. Выявление шаблонных подпроцессов в реальных процессах может помочь в оптимизации как бизнес-процессов, так и модели. Например, работы, выполняемые, как правило, друг за другом, могут быть объединены внутри одного отдела или даже поручены одному человеку, что сократит время на коммуникацию и повысит эффективность управления. Также можно спроецировать на модель данные о производительности, что позволит выявить "узкие места" модели. Другим хорошим примером является алгоритм построения деревьев решений, который анализирует каждую точку выбора на заданной модели, просматривая лог и определяя, какая информация обычно известна на момент выбора. После этого используются классические методы Data Mining для определения того, какие именно элементы информации влияют на выбор. В результате строится дерево решений процесса.
Анализ протоколов работы представляет собой достаточно сложный процесс. Во-первых, необходимо наличие полезной информации в протоколе, которая впоследствии извлекается.
Во-вторых, определенную сложность представляет разнообразие типов элементов схем потоков работ. Выделяют следующие типы элементов схемы:
последовательности — представляют собой ситуации, когда задачи выполняются в заранее установленном порядке, одна за другой. Например, для модели на рис. 15.7 задачи "Открыть сайт" и "Просмотреть товары" образуют последовательность;
параллелизм — означает, что выполнение двух и более задач независимо друг от друга и происходит параллельно (задача "Заполнить форму" может быть выполнена независимо от задач "Аутентификация" и "Создать учетную запись" для модели на рис. 15.7);
выбор — это ситуация, когда выполняется только одна из задач, которые имеют такую возможность (задачи "Совершить покупку" и "Отменить покупку" на рис. 15.7);
циклы — показывают, что некоторые части процессов повторяются много раз. Один из таких блоков образуют задачи "Просмотреть товары", "Добавить товар в корзину", "Вычислить сумму" на рис. 15.7;
Рис. 15.7. Пример сети Петри, содержащей все типовые конструкции управления потоком, которые могут встретиться в бизнес-процессах
принудительный выбор — это смесь синхронизации и выбора, под данную категорию подпадает, например, конструкция из "Вычислить сумму" и "Вычислить сумму с бонусом";
невидимые задачи — это переходы, используемые для преодоления ограничений формализма сетей Петри, они не имеют соответствующих им событий в логе (черные прямоугольники на модели);
дублируемые задачи — относятся к ситуациям, когда несколько задач имеют одинаковые метки (задача "Вычислить сумму" на модели).
В настоящее время ни один алгоритм Process Mining не обрабатывает все конструкции одинаково полноценно.
Еще одной проблемой, затрудняющей работу методов Process Mining, является шум, имеющийся в протоколах. Шум может появиться в двух ситуациях: события по каким-либо причинам были некорректно зарегистрированы (например, из-за временных сбоев в системе) или по причине возникновения исключительных ситуаций и записи о них в протокол. Присутствие шума может препятствовать корректному анализу протокола.
Первые работы по Process Mining появились в 1995 г. Их авторами были Джонатан Кук (Jonathan E. Cook) и Александр Вольф (Alexander L. Wolf). Они были направлены на извлечение моделей процессов работы из протоколов работы в контексте программной инженерии. Данную технологию они назвали исследование процессов (process discovery).
Их основной целью было не построить полную и корректную модель процесса, а извлечь из протоколов работы наиболее часто встречаемые шаблоны. Извлекаемые шаблоны описывались как конечный автомат. В своих работах [124—128] они представили три алгоритма: RNet, KTail и Markov.
Из них только алгоритм Markov полностью разработан Куком и Вольфом, остальные являются адаптацией известных технологий к анализу протоколов работы. Алгоритм RNet использует нейронные сети. KTail реализует алгоритмический подход. Markov основывается на статическом и алгоритмическом подходах. Алгоритм Markov превосходит оба алгоритма. Наихудшие результаты показал алгоритм RNet.
Марковский алгоритм (Markov) использует теорию Марковских дискретных случайных процессов для нахождения наиболее вероятных последовательностей событий, после чего алгоритмически преобразует эти вероятности в состояния и переходы между состояниями. В итоге он строит граф состояний в виде конечного детерминированного автомата.
Основная идея алгоритма Маркова заключается в использовании вероятностей последовательностей событий. В процессе выполнения алгоритма создаются таблицы вероятностей для последовательностей событий путем подсчета числа появлений одинаковых последовательностей в потоке событий. Далее те последовательности, вероятность и число появлений которых ниже установленного пользователем порога, отсекаются, а оставшиеся используются для создания конечного автомата.
Алгоритм включает следующую последовательность шагов.
Шаг 1. На первом шаге строятся таблицы вероятностей последовательностей событий путем прохода по потоку событий. При этом для каждой последовательности событий подсчитывается частота и число ее появлений в потоке событий.
Пример таблицы вероятностей для последовательности из двух событий приведен в табл. 15.3, для трех событий — в табл. 15.4. Последовательность соответствует комбинации строки и колонки, на пересечении в таблице указывается частота ее появления в протоколе. Так, для последовательности RC частота равна 0.5, а для последовательности RCE — 1.
Шаг 2. На основе таблиц вероятностей создается направленный граф, именуемый графом событий. Он строится следующим образом: каждому типу событий сопоставляется своя вершина, далее для каждой последовательности событий, вероятность и число появлений которой превышают заданный
пользователем порог, создается уникально именуемое ребро от одного элемента последовательности до непосредственно следующего за ним элемента в этой последовательности.
Для последовательностей, приведенных в табл. 15.3, граф событий будет выглядеть так, как он изображен на рис. 15.8. Дуги помечены цифрами.
Рис. 15.8. Пример графа событий
Шаг 3. Предыдущий шаг может привести к появлению вершин с лишними ребрами, показывающими реально несуществующие пути. Для решения этой проблемы подобные вершины разбиваются на две или более вершин. Это делается путем поиска непересекающихся наборов входящих и выходящих ребер, которые имеют ненулевую вероятность, после чего вершина разбивается на набор вершин, количество которых соответствует количеству наборов.
Внашем примере после предыдущего шага на графе лишними несуществующими путями являются RCR, CRC, ERE, ECE. Для них в таблице вероятности значения равны 0, однако на графе они присутствуют. Чтобы устранить это несоответствие, вершины C и R разбиваются на две новых вершины.
Врезультате, например, для новых вершин C к одной отходит ребро С-Е, а к другой Е-С, что в свою очередь убирает путь E-C-E с графа (рис. 15.9).
Шаг 4. Имеющийся граф событий G преобразуется в граф G′ путем совершения следующих действий: каждому ребру в графе G сопоставляется вершина в графе G′ . Вершине присваивается уникальная метка, которая соответствовала ребру в графе G . Для каждой последовательности входящее ребро — вершина — исходящее ребро в графе G создается ребро в графе G′ от вершины, соответствующей входящему ребру, до вершины, соответствующей исходящему ребру. Полученному ребру присваивается метка типа события, которому соответствовала вершина между входящим/исходящим ребрами в графе G (рис. 15.10).
В нашем примере вершина 5 и прилегающие к ней ребра создаются из ребра с меткой "5" в графе событий, которое соединяет вершины C и E.
Рис. 15.9. Пример графа событий после преобразования
Рис. 15.10. Конечный детерминированный автомат, полученный
в результате работы алгоритма Маркова
Вработах [125, 128] авторы расширили алгоритм Маркова, чтобы извлекать параллельные элементы процессов. Было предложено идентифицировать элементы разделения и соединения потоков. Для этого проверяется таблица частот для непосредственного предшественника и следующего анализируе-
мого события. Кроме того, авторы описали четыре статических
продолжение следует...
Часть 1 5 Средства анализа процессов - Process Mining
Часть 2 Метод построения дизъюнктивной Workflow-схемы - 5 Средства анализа процессов -
Часть 3 Методы на основе генетических алгоритмов - 5 Средства анализа процессов
Часть 4 ProM Import Framework - 5 Средства анализа процессов - Process
Комментарии
Оставить комментарий
Интеллектуальный анализ данных
Термины: Интеллектуальный анализ данных