Экземпляр процесса (Process Instance)
Экземпляр процесса (Process Instance) — лог реализации одного конкретного случая процесса для получения единичного результата процесса в Process Mining.
Экземпляр процесса маркируется уникальным Process ID. Например, ID может быть номером одной конкретной заявки на кредит, выплаты одного страхового возмещения, приема одного клиентского звонка, лога одного контакта клиента с провайдером услуг и пр.
Фрагмент журнала событий с базовыми полями:
| Process ID | Event | Timestamp |
|---|---|---|
| 1 | Приемка ж/д терминал | 03.06.2021 13:59 |
| 1 | Оформление приходных документов | 03.06.2021 14:05 |
| 1 | Оформление документов контрагентов | 03.06.2021 14:26 |
| 1 | Ввод данных контрагента | 03.06.2021 14:35 |
| 1 | Оформление приходных документов | 04.06.2021 09:47 |
| 1 | Заменить | 04.06.2021 14:05 |
| 1 | Оформление приходных документов | 04.06.2021 14:05 |
| 1 | Заменить | 05.06.2021 08:28 |
| 1 | Определение локации | 05.06.2021 08:28 |
| 1 | Вызов погрузчика | 05.06.2021 08:29 |
| 1 | Размещение груза | 05.06.2021 13:40 |
| 1 | Груз размещен | 05.06.2021 13:41 |
| 2 | Приемка ж/д терминал | 04.06.2021 02:28 |
| 2 | Оформление приходных документов | 04.06.2021 03:54 |
| 2 | Груз размещен | 04.06.2021 05:09 |
| 3 | Приемка | 04.06.2021 03:02 |
| 3 | Ввод данных контрагента | 04.06.2021 04:45 |
В таблице указаны два экземпляра процесса с Process ID — 1 и 2.
Множество логов экземпляров процесса образуют журнал событий. С содержательной точки зрения лог одного экземпляра процесса отображает конкретную реализацию одного процесса, его путь. А совокупный процессный лог описывает выбранный бизнес-процесс.
Экземпляры процесса могут быть завершенными или незавершенными.
Завершенным является экземпляр процесса, при котором получен результат процесса, или, иными словами, когда последним событием процесса является событие из перечня валидных конечных событий. Например, «Груз размещен».
Незавершенным является экземпляр процесса, еще не приведший к результату. То есть процесс завершается на промежуточном событии, например «Оформление приходных документов».
Ситуация неполноты экземпляров процессов, например, возникает при выгрузке лога, когда часть недавно начавшихся процессов еще не успела завершиться. Для отрисовки графа процесса такие экземпляры желательно удалить из журнала событий, так как они вносят искажения в пути процесса. Но решение об отрисовке незавершенных экземпляров процессов на графе должно быть за аналитиком. Для расчета процессных метрик должен использоваться весь лог событий полностью.
Моделирование возникновения экземпляра процесса
Для того чтобы сымитировать выполнение экземпляров процесса, необходимо, в первую очередь, смоделировать условия возникновения экземпляров процесса. Экземпляр процесса возникает в момент возникновения экземпляра стартового события/событий диаграммы процесса. Экземпляр имитирующего стартового события может возникнуть либо по причине передачи управления из экземпляра другого имитирующего процесса, либо в соответствии с правилами возникновения экземпляров этого имитирующего стартового события. Правила возникновения экземпляров имитирующего стартового события задаются в Окне свойств объекта справочника «События» (вкладка Параметры имитации → вкладка Правила возникновения) (Рис.1).
Рисунок 1. Моделирование правил возникновения экземпляров события
Для модели события может быть задано несколько правил возникновения экземпляров события. Генерация экземпляров имитирующего события определяется логическим сложением всех заданных правил. Для моделирования правила возникновения экземпляров события необходимо заполнить следующие параметры на вкладке Правила возникновения:
Тип случайной величины,
Закон распределения,
Количество экземпляров события.
Тип случайной величины
Параметр может принимать значения: Момент времени, Шаг повторения, Таймер.
«Момент времени» выбирается для задания конкретных моментов времени, когда в течение интервала, заданного в параметре «Интервал», возникают экземпляры события.
«Шаг повторения» выбирается для задания шага между моментами возникновения экземпляров события в течение интервала, заданного параметре «Интервал». Примером события, для моделирования возникновения экземпляров которого в качестве типа случайной величины выбирается «Шаг повторения», может служить событие «Поступил звонок от клиента». Экземпляры этого события возникают через определенные интервалы времени в течение дня.
«Таймер» выбирается для задания задержки перед возникновением экземпляра промежуточного события-обработчика, фигура которого расположена на диаграмме процесса в нотации BPMN. Время задержки отсчитывается от момента перехода к модели события во время имитации.
Интервал
Параметр является комплексным и предназначен для задания интервалов времени, в течение которых возникают экземпляры события (Рис.2). Описание параметров комплексного параметра «Интервал» приведено в Табл.1.
| Параметр интервала | Описание |
|---|---|
| Интервал возникновения экземпляров события | Задает шаблон для генерации временных отрезков, в течение которых возникают экземпляры события. Шаблон — это интервал времени, который будет повторяться в соответствии с правилами, заданными в разделе «Повторять»: — Сутки: длительность шаблона — сутки; — Год: длительность шаблона — год. |
| Повторять | Задает правила, по которым интервал возникновения экземпляров события повторяется, например, «Ежедневно», «Ежемесячно». Если в качестве длительности шаблона выбран Год, то частоту повторения шаблона можно выбрать только из двух опций: «Нет» или «Ежегодно». |
| Пределы повторения | Задает либо интервал дат, в течение которого возникают экземпляры события по указанным ранее правилам, либо количество повторений интервала возникновения экземпляров события, если не указано «Нет» в значении параметра «Повторять» . |
Таблица 1. Описание параметров комплексного параметра «Интервал»
На Рис.2 приведен пример следующего интервала возникновения экземпляров события: начало отсчета: 10 октября 2012-го года. Начиная с этой даты, каждый день каждого года с 09:00:00 до 18:00:00, с 1-го января и до 31-го января включительно возникают экземпляры события.
Рисунок 2. Параметры интервала
Для модели события с Типом случайной величины «Шаг повторения» первый экземпляр имитирующего события возникает в момент начала заданного интервала возникновения экземпляров события. Т.е. если задан Интервал возникновения экземпляров события «Сутки → Время возникновения: с 09:00:00 до 18:00:00», первый экземпляр имитирующего события возникнет в 9:00:00.
Для модели события с Типом случайной величины «Таймер» значение параметра «Интервал» не задается.
Закон распределения
Распределение случайной величины, выбранной в параметре «Тип случайной величины», задается законом ее распределения. Для этого выбирается тип закона распределения и задаются параметры этого закона.
В окне Закон распределения можно задать следующие типы закона распределения:
для дискретного распределения:
Дискретный закон распределения;
для непрерывного распределения:
Равномерный,
Нормальный,
Экспоненциальный,
Гамма (Эрланга),
Треугольный.
Для каждого распределения автоматически заполняются значения параметров по умолчанию, которые можно изменить вручную. Если параметры распределения заданы верно, будет построен график плотности распределения случайной величины (Рис.3).
Рисунок 3. Параметры распределения моментов возникновения экземпляров события
В окне Закон распределения (Рис.3) указаны нижняя и верхняя границы интервала возникновения экземпляров события, заданные в параметре «Интервал» (см. Рис.2). Нажатие на гиперссылку Нижняя граница интервала или Верхняя граница интервала копирует значение границы интервала в одноименный параметр закона распределения. Если в параметре «Тип закона распределения» выбрана Константа, то нажатие на одну из гиперссылок скопирует значение соответствующей границы в параметр «Значение». Это сделано для удобства заполнения значений, если аналитик их менял и хочет вернуться к исходным значениям границ интервала.
Внимание! Если область значений распределения выйдет за пределы интервала возникновения экземпляров события: [Нижняя граница интервала; Верхняя граница интервала], то экземпляры имитирующего события, возникшие вне границ интервала, при имитации учтены не будут.
Количество экземпляров события
Задает распределение количества экземпляров события, которое возникает в заданном интервале времени. Параметр задается, если в качестве типа случайной величины выбран «Момент времени» (Момент возникновения экземпляров события).
Задание корректной частоты возникновения экземпляров событий нередко возможно только при непосредственном наблюдении за деятельностью. Для облегчения этой задачи можно использовать модуль Контроллинг процессов ( Главное меню → Анализ процессов → Данные контроллинга ). Подробная информация о модуле приведена в Руководство пользователя, глава Контроллинг процессов.
Тестирование правил возникновения экземпляров имитирующего события
Смоделировав правила возникновения экземпляров события, можно сымитировать их возникновение (Рис.4). Это необходимо для того, чтобы проверить корректность заданных условий, сравнить желаемое поведение системы с реальным. Для этого в Окне свойств объекта справочника «События» (вкладка Параметры имитации → вкладка Правила возникновения) необходимо нажать гиперссылку Смоделировать моменты возникновения.
Рисунок 4. Окно Моменты возникновения экземпляров события
На Рис.4 представлен результат тестовой генерации экземпляров имитирующего события. Начало имитационного периода: 01.01.2020, завершение: 31.12.2020. Один столбец показывает, сколько экземпляров имитирующего события возникает за 15 дней (значение параметра «Шаг группировки»). При этом всего за указанный период возникло 45 экземпляров имитирующего события. В этой форме допустимо менять значения параметров «Начало», «Окончание», «Шаг группировки». Эта возможность позволяет представить отчет в удобной для аналитика форме с нужным ему масштабом отображения данных.
Модели и экземпляры процессов
В управлении бизнес-процессами различают процессные модели и процессные экземпляры. Субъектно-ориентированные модели процесса описывают поведение участников бизнес-процесса: какие действия и кем выполняются для получения результата. Такие модели содержат информацию о том, как протекает бизнес-процесс и как его следует обрабатывать. Субъекты являются абстрактными ресурсами — Актерами, участниками процесса.
Например, модель процесса «Запрос на КЗ» описывает, какие субъекты задействованы, что и в какой последовательности делают люди, ответственные за субъект, и как они общаются друг с другом.
Экземпляр процесса — это конкретная реализация процесса, описанного с помощью модели. Она возникает, когда бизнес-процесс запускается «в продуктив». В случае «Запроса на КЗ» экземпляр процесса создается, когда сотрудник формирует свой запрос [1] .
Все верно, но прежде чем система сама сможет реализовать этот алгоритм, надо создать некоторый фундамент из поля автоматизированных простейших процессов, которые по системным законам должны кон- гломерироваться в структуры все более сложные, постепенно избавляясь от главного источника операционных рисков homo sapience, может не всегда и sapience, но praesentis (присутствующий) всегда.
Экземпляры процессов содержат конкретные данные: участников, действия и затронутые бизнес-объекты, а также информацию и модели, описывающие их.
Модель процесса создается независимо от конкретных организационных единиц или участников. Кроме того, модель не зависит от инструментов и прикладных программ, необходимых для осуществления процесса. Таким образом, «Запрос на КЗ», в принципе, может сделать любой сотрудник организации. Необходимые действия, как правило, для всех одинаковы, они выполняются в ролях/субъектах:
- — «сотрудника» (заявителя);
- — «начальника» (утверждающего);
«ответственного за организацию командировки» (редактора).
Кроме того, возможно использование программной поддержки для одного и того же процесса. Центральное отделение организации может управлять запросами на командировки с помощью ERP системы (типа SAP), а в филиалах могут использоваться собственные разработки или промышленные системы других вендоров.
С одной стороны, модель процесса реализуется в организации много раз, а с другой стороны, возможна ее реализация в различных программных средах. Пусть это и затрудняет стандартизацию и гомогенизацию, к которой стремятся многие организации, однако это соответствует действительности, так как во внимание часто принимаются исторически сложившиеся или возникшие за счет слияний гетерогенные организационные и системные среды. Модель процесса, следовательно, не должна значительно зависеть от таких сред.
Экземпляры процесса могут возникать различными способами. В первом варианте пользователь создает экземпляр через интерфейс с информационной системой. Например, сотрудник делает запрос на командировку, потому что он должен посетить клиента. Этот экземпляр процесса обрабатывается в зависимости от спецификации модели и с использованием конкретных необходимых людей и средств.
Второй вариант — возникновение новых экземпляров через «календарь». Например, каждый четверг делаются автоматические запросы на командировку для регулярных конференций вне организации.
Третья возможность создания экземпляра связана с определенным состоянием данных в базе. Например, если сальдо счет дебиторов превышает определенную сумму, то возникает соответствующий процесс обсуждения. При этом инициирующим может быть определенный уровень биржевого курса: если снижается значение определенной торговой марки и для клиентов банка возникает риск, то автоматически возникает процесс для того, чтобы отреагировать на данную ситуацию с курсом. Это осуществляется с помощью так называемой комплексной системы обработки событий параметры которой настаиваются заранее в соответствии с мнениями экспертов по конкретному вопросу. События, которые рассматриваются системой, могут быть и внутренние, например, снижение производительности конкретного участка процесса за определенный период времени или невыход на работу сотрудника/ов смены, т.с. необходимость оперативной замены.
Следующие разделы посвятим описанию моделей, учету специфики организационной и информационных сред, а также формированию и исполнению экземпляров моделей процесса.
- [1] Можно говорить и о том, что этот процесс начинается тогда, когда возникает объективная, служебная необходимость командирования сотрудника и что самому сотруднику и не надодумать о том, «ехать ли или нет ли» в командировку, начальник или система сама должна егонаправить, и т.д. Но в данном случае авторы предлагают исходить из принципа рациональности.
Что такое экземпляр процесса
Процесс может выполняться несколько раз, и каждый раз ождиается, что все шаги данного Процесса будут выполняться в соответствии с последовательностью их расположения. К примеру, Процесс на фигуре 10.1 повторяется каждую пятницу, а в каждом из его экземпляров сначала выполняется Задача «Receive Issue List», затем Задача «Review Issue List» и т.д., т.е. ожидается последовательность выполнения, отображенная на диаграмме. Также ожидается, что каждый экземпляр этого Процесса является верным для данной модели, однако, некоторые экземпляры таковыми не являются (к примеру, если Процесс содержит Действия для ручного выполнения, а у исполнителей этих Действий нет соответствующей инструкции по их выполнению).
В некоторых программах моделирования для выполнения Процесса предусмотрено использование большего числа Действий и Событий, нежели указано в модели данного Процесса. Это позволяет осуществлять переход к нужному шагу без внесения изменений в саму модель. Например, изображенные на фигуре 10.1 экземпляры Процесса могут выполнять дополнительное Действие на отрезке между Задачами «Receive Issue List» и «Review Issue List». Данные экземляры являются верными для этого Процесса, поскольку они все так же выполняют содержащиеся в нем Действия (в указанном порядке и в указанных условиях).
Существует 2 способа определения того, что в Процессе возможно использование немоделируемых Действий:
- В случае, если значение атрибута isClosed Процесса равно «false», или его значение вообще не установлено, то в экземпляре Процесса МОГУТ присутствовать такие взаимоотношения, как отправка и получения Сообщений и События, при этом модель данного Процесса не содержит соответствующих элементов. Однако в определенном Потоке операций использование немоделируемых взаимоотношений может быть ограничено (см. следующий пункт). В случае, если значение атрибута isClosed Процесса равно «true», то экземпляр Процесса НЕ МОЖЕТ содержать такие взаимоотношения, как отправка и получения Сообщений и События, если в данном Процессе им не соответствуют дополнительные графические элементы. Это ограничение отменяет выполнение любого немоделируемого взаимоотношения, допустимого для какого-либо из описанных ниже Потоков операций.
- В случае, если значение атрибута isImmediate Потока операций Процесса равно «false», то в ходе данного Процесса МОГУТ БЫТЬ выполнены дополнительные немоделируемые Действия и взаимоотношения. Такие Действия входят в состав Потока операций. В случае, если значение атрибута isImmediate равно «true», то немоделируемые Действия НЕ МОГУТ быть выполнены в ходе следования Потока операций. В невыполняемых Процессах (т.е. тех, чей атрибут isExecutable имеет значение «false» в качестве установленного или значения по умолчанию) Поток операций, значение атрибута «isImmediate» которого не установлено, обрабатывается так, как если бы это значение было равно «false». В выполняемых Процессах (т.е. тех, чей атрибут isExecutable имеет значение «true» в качестве установленного или значения по умолчанию) Поток операций, значение атрибута «isImmediate» которого не установлено, обрабатывается так, как если бы это значение было равно «true». Значение атрибута isImmediate выполняемого Процесса не может быть «false».
Ограничение использования немоделируемых Действий, определенное посредством значений атрибутов isClosed и isImmediate, может быть применено только при выполнении Процессов и его экземпляров, содержащих такое ограничение. Немоделируемые Действия МОГУТ встречаться в экземплярах других Процессов.
В случае, если Процессом предусмотрено возможное использование немоделируемых Действий, то такие Действия могут появляться и в моделях других Процессов и их экземплярах, выполнение которых может быть верным для исходного Процесса. Рассмотрим пример Процесса, схожего с Процессом на фигуре 10.1, содержащим дополнительное Действие на отрезке между Задачами «Receive Issue List» и «Review Issue List». Процесс на фигуре 10.1 может содержать атрибут isClosed или isImmediate, что позволяет Действиям появляться на этом отрезке. По мере выполнения Процесса на фигуре 10.1 для него становятся верными экземпляры другого Процесса, содержащего дополнительные шаги на отрезке между Задачами «Receive Issue List» и «Review Issue List»). Разработчики модели могут указать, что все экземпляры одного Процесса становятся верными для другого Процесса, и эта связь осуществляется осредством поддерживающей ассоциации между Процессами. В ходе разработки моделей данных Процессов такая ассоциация может не учитываться, поскольку она является лишь отображением намерений разработчиков.
Как правило, такая поддержка осуществляется между приватным и публичным Процессами (см. Общее представление). Публичный Процесс содержит Действия, видимые для внешних объектов (например, Участников Взаимоотношения), в то время как приватный Процесс содержит остальные Действия, недоступные для внешних объектов. Скрытые Действия приватного Процесса для публичного Процесса не моделируются. Однако предполагается, что экземпляры приватного Процесса будут доступны для внешних объектов, как если бы они были экземплярами публичного Процесса. Это означает, что приватный Процесс поддерживает публичный (ожидается, что все экземпляры приватного Процесса будут верны и для публичного).
Процесс, поддерживающий другой Процесс (как в случае с приватным и публичным Процессами), не должен полностью его копировать. НЕОБХОДИМО лишь, чтобы экземпляры этого Процесса появлялись так же, как если бы они были экземплярам другого. В верхней части фигуры 10.127 отображен публичный Процесс с Задачами Отправка и Получение. Поддерживающий его приватный Процесс отображен в нижней части фигуры. Приватный Процесс отправляет и получает те же сообщения, что и публичный, однако, для выполнения этих операций вместо Задач в нем используются События. В нем также содержатся Действия, не входящие в состав публичного Процесса. При этом все экземпляры приватного Процесса будут появляться так, как если бы они были экземплярами публичного, т.к. сообщения отсылаются и принимаются в ТРЕБУЕМОМ публичным Процессом порядке. В публичном Процессе допускается появление немоделируемых Действий.
Фигура 10.127 – Процесс, поддерживающий другой Процесс
Фактически, публичный Процесс выглядит как недостаточно углубленный приватный. То, что не указано в публичном Процессе, есть в приватном. К примеру, если ни один из Потоков операций, направленных от Эксклюзивного Шлюза, не содержит условного выражения, то в приватном Процессе будет указано то, какое из Действий, служащих целями Потоков операций, появится. Другим примером является Событие Таймер, для которого не указано значение элемента EventDefinition. То, когда выключится таймер, указывается в приватном Процессе.
10.9 Аудирование
Элемент Auditing и его ассоциации позволяют указывать значения атрибутов, связанных с проверкой. Посредством его использования достигается способность BPMN к расширению. Данный элемент используется Элементам потока и Процессами. Однако данный документ не содержит описания атрибутов проверки, т.к. в BPMN 2.0 указан собственный набор атрибутов и семантики для них.
Фигура 10.128 – Диаграмма классов элемента Auditing
10.10 Мониторинг
Элемент Monitoring и его ассоциации позволяют указывать значения атрибутов, связанных с проверкой. Посредством его использования достигается способность BPMN к расширению. Данный элемент использьзуется Элементам потока и Процессами. Однако данный документ не содержит описания атрибутов проверки, т.к. в BPMN 2.0 указан собственный набор атрибутов и семантики для них.
Фигура 10.129 – Диаграмма классов элемента Monitoring
10.11 Представление XML-схемы для пакета Процесса
Таблица 10.136 – XML–схема для элемента Process
Таблица 10.137 – XML–схема для элемента Auditing
Таблица 10.138 – XML–схема для элемента GlobalTask
Таблица 10.139 – XML–схема для элемента Lane
Таблица 10.140 – XML–схема для элемента LaneSet
Таблица 10.141 – XML–схема для элемента Monitoring
Таблица 10.142 – XML–схема для элемента Performer
Данные материалы предназначены исключительно для ознакомления в личных целях.Любое воспроизведение, копирование, а так же коммерческое и некоммерческое использование материалов должно согласовываться с авторами материалов (elma@elewise.ru). Допускается использование материалов сайта без уведомления авторов, но с явным указанием источника.
- Область действия документа
- Соответствие требованиям спецификации
- Нормативные ссылки
- Термины и определения
- Символы
- Дополнительная информация
- Общее представление
- Элементы BPMN
- Типы Диаграмм Бизнес-процессов (BPMN Diagram Types)
- Структура нотации BPMN
- Шлюзы (Gateways)
- Общие элементы (Common Elements)
- Обмен Сообщениями (Conversations)
- Взаимодействие (Collaboration)
- Процесс
- Процесс. Распределение ресурсов
- Процесс. Участие людей
- Процесс. Подпроцесс
- Процесс. Действие Вызов
- Процесс. Представление XML-схемы для Действий
- Процесс.Компоненты и Данные
- Процесс. Семантика исполнения для данных
- Процесс. Событие
- Процесс. Конечное событие
- Процесс. Элементы EventDefinition
- Процесс. Обработка Событий
- Процесс. Представление XML-схемы для пакета События
- Процесс. Шлюзы
- Процесс. Компенсация
- Процесс. Экземпляры Процесса, Немоделируемые Действия и Публичный Процесс
Вам подойдёт синергия BPM+RPA
Ваш бизнес-процесс включает много производственных этапов и занимает значительное количество времени у сотрудников. Кроме того, он линеен и поддается роботизации. Автоматизируйте бизнес-процессы в ELMA365, контролируйте достижение результата и повысьте эффективность компании. А беспланая* интеграция ELMA RPA позволит переложить на роботов выполнение повторяющихся, решаемых вручную задач и освободить сотрудников для более важной работы.
Попробовать ELMA365
Заполните форму, чтобы получить ссылку для скачивания.
Вам подойдёт ELMA RPA
Автоматизация бизнес-задач при помощи программных роботов
Ваш бизнес-процесс линеен и достаточно прост. Его можно автоматизировать с помощью ELMA RPA без больших ресурсных затрат. ELMA RPA избравит сотрудников от рутины, повысит скорость выполнения и эффективность процесса.
Попробовать ELMA RPA
Заполните форму, чтобы получить ссылку для скачивания.