Пример моделирования бизнес-процесса: умножение задач
При моделировании бизнес-процессов часто возникают ситуации, когда корректные варианты моделирования или неизвестны, или их несколько и необходимо выбрать только один из них. В данной статье мы рассмотрим один процесс и различные варианты его исполнения и моделирования в сервисе БП Симулятор.
Моделирование базовой процедуры анализа биоматериала
В качестве демонстрационного процесса возьмем упрощенную процедуру анализа биоматериала в медицинской лаборатории. Для получения результата анализа пациент должен сдать кровь, а сотрудник лаборатории провести её анализ и уведомить пациента. Смоделируем эту процедуру, разместив на модели следующие объекты модели бизнес-процесса:
- Генератор задач "Обращение пациента" - каждый обратившийся за анализом клиент формирует задачу для лаборатории. Обратите внимание, сам пациент не является исполнителем бизнес-процесса, поэтому он не наносится на модель.
- Функция "Забор биоматериала" - лаборанту необходимо произвести забор крови пациента в пробирку.
- Функция "Анализ крови" - помещение образца биоматериала в анализатор и проведение исследования. Несмотря на то, что исполнитель у этой и предыдущей функции может быть один и тот же, совмещать эти функции нельзя, поскольку между ними может быть время ожидания/подготовки прибора или исполнитель может смениться.
- Функция "Уведомление пациента" - по окончании анализа лаборант посылает пациенту результат анализа. По аналогичной причине мы не будем совмещать эту функцию с предыдущей.
Вариант №1: 1 клиент и 2 обязательные параллельные задачи
Рассмотрим возможность моделирования таких случаев, когда экземпляр процесса один (один клиент запустил один процесс), а параллельных задач для завершения процедуры несколько. Например, пациенту необходимо сделать два разных анализа крови. Вариант с последовательным забором и анализом мы рассматривать в этой статье не будем, хотя часто это может быть хорошим вариантом моделирования, но в данном случае добавим новое условие, влияющее на длительность выполнения функции:
- Анализ №1 длится 1 час
- Анализ №2 длится 2 часа
Плюсы на входе функции "Уведомление пациента" означают, что функция должна ожидать результаты обоих анализов, а не рассылать каждый раз новое уведомление с результатом. Подробнее о свойстве Правило распределения задач от поставщиков.
Вариант №2: 1 клиент и 2 исключающие параллельные задачи
Теперь рассмотрим пример, когда пациенту надо сделать не два анализа, а только один из них. Изменим Правило распределения задач к потребителям функции "Забор биоматериала" на ИЛИ с вероятностью 50%. Это означает, что пациенту с одинаковой вероятностью будет сделан либо Анализ №1 либо Анализ №2.
Вариант №3: 1 клиент и 2 неисключающие параллельные задачи
А как смоделировать вариант, когда врач может назначить проведение анализов №1 и №2 с независимой вероятностью относительно друг друга? Такое правило распределения называется неисключающее ИЛИ (OR) и не реализовано функционалом сервиса. Но реализовать дизъюнктор можно с помощью комбинации правил XOR и дополнительного объекта модели, как показано на следующем рисунке.
Здесь в качестве получателя неиспользуемого маршрута применяется объект типа Контрольная точка, но может быть применён любой из объектов, участвующих в маршрутизации, например Событие.
Вариант №4: соответствие нотации EPC
Приведём эту модель, скорректированную для проведения имитационного моделирования, к нотации моделирования бизнес-процессов EPC. Для этого необходимо добавить:
- События, запускающие либо завершающие каждую функцию
- Входная информация или документ, необходимые для выполнения функции
- Выходная информация или документ, являющиеся результатом выполнения функции
- Должность или роль исполнителя функции
- Ресурс - материал, информационная система, которые расходуются на выполнение функции
