Модель процесса в нотации bpmn. Нотации основных методологий моделирования

В сети Интернет можно встретить множество обзоров и обсуждений нотаций для моделирования бизнес-процессов. Консультанты и бизнес-аналитики ведут длительные дискуссии о том, какую же нотацию лучше применять при моделировании бизнес-процессов предприятия. С нашей точки зрения обсуждение нотаций без привязки к программному продукту не имеет смысла. Ведь графическая схема – это только вершина айсберга, вся бизнес-логика и связи хранятся «внутри» блоков нотации и не видны на схеме.

Например, популярная сейчас нотация BPMN по-настоящему раскроет свои преимущества только в связке с BPM-системой, которая может «понимать» и «исполнять» нарисованную схему бизнес-процесса в реальном времени. То есть при помощи этой нотации можно автоматизировать и контролировать выполнение процесса. Если же вы просто нарисуете процесс в нотации BPMN в Visio и сохраните его как картинку, то при этом вы потеряете практически все преимущества данной нотации перед любой другой.

Сейчас на рынке появилось множество программных продуктов, которые якобы поддерживают сразу несколько нотаций, но дело в том, что на самом деле логика работы у этих программ одинаковая для любой из этих нотаций. Как правило, ответственность и документы закрепляются внутри блока, а затем, для визуального соответствия требованиям одной из нотаций, на схему можно добавить графические блоки, наличие которых никак на функционал не влияет. То есть по сути вы строите две модели: одну по логике работы программы, а вторую – для соответствия требованиям нотации и при этом эти модели могут не совпадать (то, что мы видим не соответствует тому что сохранилось в базу данных).

Ниже приведён пример системы бизнес-моделирования, которая на бумаге поддерживает нотацию ARIS eEPC, но, на самом деле, ответственность закрепляется в карточке на функцию, а графические блоки используются «для красоты».

Но давайте не будем критиковать чужие разработки, а последовательно рассмотрим самые популярные на рынке нотации для моделирования бизнес-процессов, а также их реализацию в программе Fox Manager.

Процессы верхнего уровня

Самые распространённые нотации для построения процессов верхнего уровня на сегодняшний день это IDEF0 (методология функционального моделирования) и ARIS VAD (цепочка создания ценности).

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

В чём же отличие нашей схемы от IDEF0? В первую очередь в том, что в IDEF0 есть требования к тому к какой стороне блока какая стрелка должна подходить:

• стрелка входа приходит всегда в левую кромку активности
• стрелка управления - в верхнюю кромку
• стрелка механизма - нижняя кромка
• стрелка выхода - правая кромка

Является ли это важным отличием, которое даёт преимущества данной нотации перед нашим подходом? С нашей точки зрения – нет, но при желании, вы можете привести схему взаимодействий в Fox Manager в чёткое соответствие с требованиями этой нотации (сверху – оригинальная схема в IDEF0, снизу – её аналог в Fox Manager).

Как видите, при желании, вы можете моделировать схемы IDEF0 и в Fox Manager.

Есть у нотации IDEF0 и другие требования, (которые, впрочем, обычно не соблюдаются бизнес-аналитиками) – это ограничение на количество блоков на схеме (6-8) и принцип доминирования (наиболее важная функция должна находится в верхнем левом углу). Опять же, не существует никаких преград к тому, чтобы расположить блоки по этому принципу и в нашей программе.

Что касается нотации ARIS VAD – то тут всё ещё проще: достаточно выстроить процессы по цепочке создания ценности и при желании показать ответственных и взаимодействия.

На картинке приведён пример такой схемы в нашей программе (сверху – оригинальная диаграмма ARIS VAD, снизу – её аналог в Fox Manager). Конечно, можно придраться в форме блоков, стрелок или подсветке, но в целом, не возникает сомнений, что в нашей программе, при желании, можно строить диаграммы в соответствии с требованиями нотации ARIS VAD.

Процессы нижнего уровня

В программе Fox Manage мы используем простую, наглядную и очень гибкую нотацию для моделирования процессов нижнего уровня. Ознакомиться с её возможностями можно из видеоролика.

Существует множество нотаций для моделирования бизнес-процессов нижнего уровня: Basic Flowchart, Cross Functional Flowchart, EPC и другие. Большинство из них имеют незначительные отличия друг от друга.

Например, если в программе Fox Manager на диаграмме свернуть блоки ответственных, документов и ресурсов, то мы получим аналог нотации Basic Flowchart (справа – оригинальный процесс, слева – аналог в Fox Manager).

Если же все блоки на диаграмме развернуть – то мы получим аналог процесса в нотации EPC . Самое замечательное то, что при использовании нотации Fox Manager блоки можно сворачивать и разворачивать динамически, и при этом не нужно создавать новую версию процесса в другой нотации. На картинке справа изображен оригинальный процесс, а слева – аналог в Fox Manager.

Да, конечно, имеются и различия, например, в качестве отображения события мы использовали контрольную функцию, также у нас нет отдельных блоков «Логические И» и «Логическое ИЛИ», но их можно легко заменить другим блоком (ромбиком) с буквой «Х» или «V» внутри.

Поддержка нотации Cross Functional Flowchart была добавлена в программу в одном из наших бесплатных обновлений . Данная нотация отличается от уже рассмотренных выше нотаций тем, что на ней можно показывать ответственных дорожками, а не рядом с блоком. К сожалению, у этого способа есть свои недостатки, когда ответственных очень много – то процесс становится ненаглядным и трудночитаемым. Также возникают проблемы, когда необходимо распределить ответственность за функцию сразу двум и более должностям. Ниже приведён пример такого процесса в Fox Manager.

Что касается нотации BPMN , то мы считаем, что её возможности слишком избыточны для целей описания, анализа и регламентации бизнес-процессов. В этой нотации представлено около 100 различных блоков и их подвидов, которые используются при автоматизации процессов, но они бесполезны для систем бизнес-моделирования, которые не умеют «исполнять» процессы в реальном времени, а берут из них информацию для формирования регламентирующих документов.

Конечно, наверное, можно сократить набор элементов этой нотации до необходимого минимума и попытаться приспособить её для целей регламентации, но при этом мы потеряем её главное преимущество – возможность исполнения процессов BPM-движком. При этом, если оставить только 5-10 необходимых блоков, то, скорее всего, внешний вид таких процессов будет очень походить на уже рассмотренные нами нотации.

Вывод

Мы считаем, что в программе Fox Manager подобраны оптимальные нотации для моделирования бизнес-процессов, которые одновременно легки для восприятия и обладают и высоким функционалом.

Поддержка нотации реализована на базе ядра программы, мы не используем Visio и другие сторонние компоненты, поэтому скорость обработки данных из таких блок схем очень высокая.

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

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

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

Но мы отдаём себе отчёт в том, что некоторые бизнес-аналитики не доверяют новым разработкам и предпочитают пользоваться старыми, знакомыми им нотациями. Цель данной статьи – показать гибкость программы Fox Manager и возможность настройки внешнего вида схем под требования большинства имеющихся на рынке нотаций. Стройте модели бизнес-процессов так, как удобно именно вам!

Бесплатный BPMN инструмент

Cawemo - это бесплатный онлайн-инструмент для разработки, обсуждения и обмена диаграммами BPMN с вашей командой.

Бесплатный BPMN инструмент

Обзор

Мы преподавали BPMN тысячам людей, и мы применяем обозначения в нашей ежедневной проектной работе с 2007 года. Ниже вы можете найти множество примеров BPMN общих проблем моделирования. Независимо от вашего конкретного проекта или вашей отрасли, есть много общих вопросов об использовании BPMN. По нашему опыту, большинство приведенных ниже примеров BPMN полезны для любого пользователя BPMN.

Мы присоединились к OMG в 2009 году как влиятельный член. С тех пор мы участвуем в разработке BPMN 2.0.

BPMN Примеры

Бизнес-правила и BPMN

Сценарий моделированияo

Предположим, мы хотим моделировать процесс в BPMN, и процесс вызывает некоторые бизнес-правила. Мы будем использовать пример создания счета. Чтобы создать счет, необходимо рассчитать скидку. Сумма заказа и тип клиента являются соответствующими критериями для расчета скидки.

Это очень простой пример, который покажет нам, где применять BPMN, а где нет.

Роли двигателя Создать счет Запрос счета Вычислить скидку Создать счет Счет создан

Объяснение

Во время моделирования мы фокусируемся на потоке процесса. В этом примере процесс имеет два шага. Скидка рассчитывается до создания счета. Результат - очень простой процесс.

Не имеет смысла моделировать расчет самой скидки в модели BPMN (см. Пример ниже). Для дерева решений правил, для каждого дополнительного критерия, мощности будут расти экспоненциально. Это не то, что мы хотим в модели BPMN.

Поэтому имеет смысл разделить процессы и бизнес-правила.

Создать счет Сделать 2% скидку добавить 1% скидки Кто покупатель? Запрос счета Сумма заявки? Тип покупателя? Создать счет Счет создан Сделать 3% скидку Сделать 4% скидку Кто покупатель? добавить 1% скидки добавить 1% скидки 1000 - 1500 500 - 999 >2000 < 500 Тип A Тип A Тип A обычный обычный обычный

Зависимые экземпляры

Сценарий моделирования

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

Причиной может быть то, что общее количество проведенных кредитных проверок влияет на результат проверки.

Предположим, что мы выполняем кредитную проверку для клиента, и мы получаем второй запрос для одного и того же клиента одновременно.

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

Решение с сигнальным событием

Creditworthiness Check Посмотреть запросы Посмотреть запущеные события (с ними) запуск экземпляров одного и того же клиента? и того же клиента? Првоерить кредит Проверка выполнена Проверка выполнена Запись в базуданных нет да

Объяснение

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

Решение с событием Message

Проверка кредитоспособности Проверить запросы Проверить запущенные процессы тот же клиент) запущенные экземпляры одного клиента? проверить кредит кредит подтвержден ожидать события покупателя? проверить на ожидание случаев (из тот же клиент) запуск экземпляра завершен проинформировать ожидание экземпляра База Данных База Данных нет нет да да

Объяснение

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

Решение с таймером и циклом

Creditworthiness Check Проверить запросы проверить запущенные процессы (одного пользователя) запущенные экземпляры одного клиента? perform credit check подождать немного времени проверить кредит База Данных нет да

Объяснение

В этом примере нам не нужна связь между экземплярами. Сам экземпляр проверяет периодичность, если он может перейти к проверке кредита. Недостатком является то, что это может вызвать задержки и накладные расходы из-за цикла.

Принцип четырех глаз

Сценарий моделирования

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

Случаи использования

Варианты использования для этого шаблона многочисленны. Вот некоторые примеры:

• Утверждение оплаты
• Утверждение счета
• Утверждение контракта

Решение как диаграмма BPMN 2.0

1й согласователь Согласование запрошено Оценить запрос прочитать и прокомментировать Задача завершена Процеесы в двигателе Подтвердить запрос подтвердить или согласовать (1я линия) Подтвердили? Запрос отклонен (1я линия) отклонить или подтвердить (2я линия) Подтвердили? Запрос отклонен (2я линия) Запрос подтвержден 2й согласователь подтвердить запрос оценить запрос прочитать и прокомментировать задача завершена нет да да нет

Объяснение

Мы используем отдельные пулы для Process Engine, для первого утверждающего и для второго утверждающего. Таким образом, мы можем четко определить, кто контролирует какой процесс.

В пуле двигателей используются пользовательские задачи. Эти пользовательские задачи соответствуют задачам, которые показаны в списке задач 1-го и 2-го утвердителей.

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

Сам список задач не моделируется, чтобы уменьшить сложность.

Вариации

Утверждение в качестве сбитых пулов

1й согласователь 2й согласователь Движок процесса подтвердить запрос отклонить или подтвердить (1я линия) Подтвердили? Запрос отклонен (1я линия) отклонить или подтвердить (2я линия) Подтвердили? Запрос отклонен (2я линия) Запрос подтвержден нет да да нет

Определение приемника с помощью LDAP

1й согласователь подтвердить запрос оценить запрос прочитать и прокомментировать задача завершена LDAP Движок процесса подтвердить запрос отклонить или подтвердить (1я линия) Подтвердили? Запрос отклонен (1я линия) отклонить или подтвердить (2я линия) Подтвердили? Запрос отклонен (2я линия) Запрос подтвержден determine 1st and 2nd approver 2й согласователь подтвердить запрос оценить запрос прочитать и прокомментировать задача завершена нет да да нет

Ежемесячное выставление счетов

Сценарий моделирования

В этом примере объясняется очень распространенная борьба со структурированием диаграмм BPMN 2.0. Допустим, есть адвокат, который предлагает юридические консультации своим клиентам. Услуга работает следующим образом: клиенты могут обращаться за юридической консультацией, когда им это нужно. Адвокат предоставляет запрошенный совет и ставит оплачиваемые часы на лист времени клиента. Когда месяц закончился, бухгалтер-юрист определяет оплачиваемые часы на основе расписания и создает счет-фактуру.

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

Решение как диаграмма BPMN 2.0

Адвокат Консультация Консультация запрос Предоставить совет Зарегистрировать время Запрос отработал Счетчик клиента Клиент Учет месячного дохода 1й день в месяце Определить оплачиваемые часы создать и отправить счет получить деньги Счет исполнен 14 дней Отправить напоминание Только один в месяц Несколько за месяц

Объяснение

Наиболее важным аспектом диаграммы является ее структура.

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

Конечно, эти два пула не полностью независимы друг от друга. Зачем? Они работают над одними и теми же данными - листом времени клиента. Наша способность моделировать такое связанное с данным соединение очень ограничена в BPMN. Это связано с тем, что BPMN ориентирован скорее на поток управления, чем на поток данных.

Однако мы можем использовать элемент хранилища данных для моделирования этого соединения на уровне данных.

Неправильный способ моделирования

Адвокат Консультация Консультация запрос Предоставить совет Зарегистрировать время 1 в следующем месяце определить оплачиваемые часы создать и отправить счет Получить деньги Счет исполнен 14 дней Отправить напоминание Клиент

Объяснение, почему это неправильно

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

Дополнительная информация, необходимая после задачи пользователя

Сценарий моделирования

Предположим, мы хотим моделировать следующий сценарий: мы хотим выполнить пользовательскую задачу, которая выполняется пользователем на портале. После завершения пользовательской задачи может потребоваться дополнительная информация. В этом случае процессор процесса отправляет запрос информации другому пользователю (решение 1) или технической службе (решение 2).

Решение 1. Запросить информацию от другого пользователя

Пользоваель зашел Пользоваель зашел Движок процесса Задание для пользователя Нужна доп. информация? Запрос информации (от пользователя) ... нет да

Решение 2. Запросить информацию у технической службы

Пользоваель зашел Some Technical Service Движок процесса Задание для пользователя Нужна доп. информация? Отправить запрос Информация получена... нет да

Обработка партии заказов с рынка

Ситуация

Мы хотим моделировать следующий сценарий с использованием BPMN 2.0: предположим, что компания получает заказы от разных каналов распространения. Один из этих каналов - это рынок. В определенные промежутки времени заказы с рынка принимаются в виде партии. Каждый заказ в этой партии должен быть проверен перед ввозом в систему ERP.

Решение как диаграмма BPMN 2.0

ERP Система Рынок Импортирова заказы в ERP Каждые 10 минут Собрать все заказы с рынка Процесс заказа Новый одиночный заказ Проверить данные заказа данные корректны? Импорт заказа в ERP систему Один заказ в процессе Дата заказа некорректна Все заказы в процессе отдельные Заказ нет да

Объяснение

В этом примере показан очень общий сценарий моделирования. Иногда мы называем это проблемой 1-к-n. Один экземпляр процесса (Import of Orders) приводит к множеству отдельных экземпляров процесса другого процесса (ERP-системы). Типичными конструкциями являются несколько экземпляров или циклов, которые запускают другие процессы, используя сообщения (потоки сообщений).

Переназначение пользовательских задач

Сценарий моделирования

Предположим, что нам нужно убедиться, что определенная пользовательская задача определенно выполнена. Поэтому задачи пользователя должны быть переназначены, как только текущий правопреемник недоступен, например, из-за отпуска или болезни.

Решение 1: Услуга передачи сообщений и переназначение

Заметка

Это имеет смысл, если движок вызывает службу для определения нового правопреемника.

Решение 2: Правила передачи сообщений и правила переназначения

Пользоваель зашел Движок процесса определить правопреемник задача пользователя... правопреемник недоступен

Заметка

Это имеет смысл, если движок вызывает механизм правил для определения нового правопреемника.

Решение 3. Событие границы сообщения и неявное переназначение

Пользоваель зашел Движок процесса задача пользователя... правопреемник недоступен

Заметка

Это имеет смысл, если движок определяет самого нового цессионария, например, используя выражение.

Двухэтапная эскалация

Сценарий моделирования

Мы будем использовать следующий пример, чтобы проиллюстрировать, как моделировать двухэтапную эскалацию с использованием BPMN 2.0. Когда мы хотим пиццу, мы заказываем ее. Иногда доставка пиццы поднимается, и доставка занимает больше 20 минут. Затем мы жалуемся на службу доставки. После этого мы даем им еще 30 минут, чтобы доставить пиццу. Если они не сделают это своевременно, мы откажемся и отменим наш заказ.

Решение 1. Два шлюза на основе событий

Пицца разыскивается Заказать пиццу Пицца доставлен Есть пиццу Пицца съедена 30 минут Жаловаться в сервис доставки Пицца доставлен 20 минут Заказ отменен Заказ отменен

Преимущества этого решения

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

Недостатки этого решения

Шлюз, основанный на событиях, не является интуитивным символом BPMN стандарта BPMN, необходим опыт.

Использование двух шлюзов, основанных на событиях, делает модель более крупной и приводит к дублированию сообщения о событии «Пицца».

Решение 2: Принять задание с включенными таймерами

Пицца разыскивается Заказать пиццу Есть пиццу Пицца съедена Жаловаться в сервис доставки Заказ отменен Заказ отменен Ждать пиццу Жаловаться на заказ 50 минут 30 минут

Преимущества этого решения

Эта модель меньше, чем первое решение и, вероятно, способ, которым большинство разработчиков решат проблему на движке. Поскольку мы используем неперерывное присоединенное событие таймера, это решение является более гибким, когда речь идет о многочисленных жалобах (например, мы хотим жаловаться каждые 5 минут до истечения 50 минут).

Недостатки этого решения

Задача получения обычно не интуитивно понятна для «деловых парней», которые предпочли бы использовать события приема сообщений для такого состояния ожидания.

То, как работает прерывающий и не прерывающий таймер, требует глубокого понимания приложенных событий.

Решение 3. Один шлюз на основе событий с общим таймером

Пицца разыскивается Заказать пиццу Пицца доставлен Есть пиццу Съесть пиццу Время вышло! Жаловаться на доставку Заказ отменен Заказ отменен Выполнено задание? Таймер показал больше да нет

Преимущества этого решения

Эта модель представляет собой компактное и общее решение проблемы. Если речь идет о n-ступенчатой эскалации, вам понадобится этот общий подход, чтобы избежать огромных диаграмм.

Недостатки этого решения

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

Для быстрого понимания двухэтапной эскалации этот метод моделирования не подходит.

BPMN Modeling Styles

Старайтесь избегать пересечения потоков как можно больше. Это повысит понимание моделей процессов BPMN - как для опытных, так и для неопытных пользователей BPMN.

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

Приведенные ниже примеры иллюстрируют проблему абстрактным примером.

Хороший пример обработки потоков

Процесс запущен выполнить первуюу задачу Обязательное действие? выполнить задачу два Процесс завершен выполнять задачу три ok? да План A План B нет

Встречный пример

Процесс запущен Задание первое Обязательное действие? perform task two Процесс завершен Задание третье Ок? да План A План Б нет

Самое главное: каждый символ BPMN должен иметь ярлык.

События должны быть помечены с использованием причастия «объект + прошлое». Начальные события всегда должны маркироваться указанием триггера процесса. Конечные события должны быть помечены конечным состоянием процесса.

Сам процесс (пул) также должен всегда маркироваться. Этот ярлык должен указывать имя процесса и роль, которая его выполняет.

Задачи должны быть помечены с помощью объекта + глагол. Это заставляет модельного человека сосредоточиться на том, что действительно сделано во время задания.

Шлюзы X-OR должны быть помечены вопросом. Потоки исходящей последовательности должны быть помечены возможными ответами на эти вопросы (условия).

Хороший пример наименования

Проверить дату заказаa Сервис Заказа Заказ получен Проверить заказ Проверить заказ Дата заказа корректна Дата заказа корректна? Дата заказа некорректна да нет

Общая версия

Имя процесса Роль, выполняющая процесс Триггер oпроцесса Объект + глагол Объект + Причастие Первое конечное состояние после окончания процесса Вопросы? Второе конечное состояние после окончания процесса ответ 1 ответ 2

Пример счетчика

Заказ сделан Старт Проверить Записать статус в БД Конец Ошибка Ок

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

Мы определили, что симметричные структуры повышают понимание моделей процессов BPMN - как для опытных, так и для неопытных пользователей BPMN.

Хороший пример симметричной модели

Готовить салат Появился голод Выбрать рецепт Какое блюдо? Готовить макароны Есть еду Голод утален Готовить стейк Какие компоненты? Выбрать: - Салат - Макароны - Стейк Стейк Макароны Салат Теплая еда

Встречный пример

Готовить салат Голод появился Выбрать рецепт Какое блюдо? Готовить макароны Съесть еду Голод утален приготовить стейкk Какие компоненты? Выбрать: - Салат - Макароны - Стейк Стейк Макароны Салат теплая еда

Хороший пример симметричной модели 2

Свежий товар Заказ доставлен использован старый товар Сумма заказа более 25.000 €? Процесс заказа Организовать доставку Package goods Доставить заказ Процесс заказа да нет

Встречный пример 2

Свежая продукция Закад доставлен старый товар на складе Сумма заказа больше 25.000 €? Заказать Сделать доставку Товар Доставка заказаr Процесс заказа да нет

Причина проста. Люди склонны интерпретировать размеры задач, хотя они не имеют семантики в стандарте BPMN.

Некоторые считают, что более крупные задачи важнее небольших задач - согласно BPMN, это неправильно.

Некоторые считают, что большие задачи занимают больше времени, чем меньшие задачи - по данным BPMN это неверно.

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

Хороший пример равных размеров задач

1й согласователь подтвердить запрос оценить запрос прочитать и прокомментировать задача завершена

Встречный пример

1й согласователь Подтвердите запрос Сделан запрос документ и комментарий удалены задача завершена

до EPC

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

Business Studio — это простота и удобство

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

Используемые нотации моделирования

В программе используются самые популярные нотации моделирования бизнес-процессов, понятные сотрудникам без дополнительной подготовки:

1. Нотация IDEF0

Наиболее популярная нотация моделирования бизнес-процессов, основанная на методологии структурного анализа SADT.

Методология IDEF0 - это методология моделирования, позволяющая создать функциональную модель, отображающую структуру и функции системы. А также — потоки информации и материальных объектов, связывающие эти функции. На рисунке ниже представлена графическая диаграмма в нотации IDEF0 - пример реализован в системе Business Studio.

Бизнес-процессы в нотации IDEF0 представляются в форме прямоугольника, а стрелки отражают связь с другими процессами и внешней средой.

Особенностями нотации являются:

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

Нотация IDEF0 используется для создания верхнего уровня модели бизнес-процессов. Построение IDEF0-диаграммы верхнего уровня обеспечивает наиболее общее или абстрактное описание объекта моделирования. На нижнем уровне для описания алгоритма (сценария) выполнения процесса допустимо сменить стандарт IDEF0 на нотацию Процесс, Процедура, EPC или BPMN 2.0.

С методологией SADT можно подробно ознакомиться в монографии Дэвида А. Марка и Клемента МакГоуэна «Методология структурного анализа и проектирования SADT».

2. Нотация Процесс (Basic Flowchart B Visio)

Данная нотация Используются графические элементы: событие, процесс, решение, два типа стрелок - стрелки предшествования и стрелки «Поток объектов».

Нотация Процесс поддерживает декомпозицию на подпроцессы.

Нотацию Процесс можно применять для моделирования отдельных процессов компании, а также на нижнем уровне модели бизнес-процессов, созданной в нотации IDEF0.

3. Нотация Процедура (Cross-Functional Flowchart B Visio)

Эта нотация используется для представления алгоритма выполнения процесса (нотация класса workflow). Дополнительно к графическим элементам, применяемым в нотации Процесс, используются дорожки (Swim Lanes), обозначающие организационные единицы - исполнителей действий процесса.

Нотация Процедура поддерживает декомпозицию на подпроцессы.

Нотацию Процедура можно применять для моделирования отдельных процессов компании, а также на нижнем уровне модели бизнес-процессов, созданной в нотации IDEF0.

4. Нотация BPMN 2.0

Используется для представления алгоритма выполнения процесса (нотация класса workflow).

Особенность нотации BPMN 2.0, появившейся в качестве стандарта моделирования в 2011 году, в том, что она предназначена как для моделирования бизнес-процессов, так и для их исполнения.

Она доступна для понимания и удобна как бизнес-аналитикам, так и разработчикам, которые занимаются автоматизацией исполнения процессов. Для экспорта схемы процесса в BPMS-систему в Business Studio используется стандарт XPDL.

В Business Studio представлено 2 типа диаграмм BPMN 2.0 - диаграммы процессов и диаграммы взаимодействия процессов.

Используются следующие графические элементы:

• процессы;
• события;
• шлюзы;

3 типа стрелок:

• поток управления;
• поток сообщений;
• ассоциации;

• документы;
• информация;
• сообщения;базы данных.

Важно, что в Business Studio все элементы диаграмм BPMN являются объектами репозитория.

В Business Studio в нотации BPMN можно строить иерархическое дерево процессов, то есть поддерживается декомпозиция.

Для процесса BPMN можно автоматически сформировать регламент и другие отчеты, эта нотация применяется преимущественно для описания процессов нижнего уровня, особенно со сложной логикой исполнения.

5. Нотация EPC (Event-Driven Process Chain)

Используется для представления алгоритма выполнения процесса (нотация класса workflow).

Диаграмма, описанная в нотации EPC (событийная цепочка процессов), представляет собой упорядоченную комбинацию событий и функций.

Для каждой функции могут быть определены начальные и конечные события, участники, исполнители, материальные и документальные потоки, сопровождающие её. В нотации EPC ветвление стрелок осуществляется с использованием операторов.

Нотация EPC поддерживает декомпозицию на более низкие уровни. Диаграмма декомпозируемой функции EPC может быть описана только в нотациях EPC или BPMN 2.0.

Нотацию EPC можно применять для моделирования отдельных процессов компании, а также на нижнем уровне модели бизнес-процессов, созданной в нотации IDEF0.

А какие нотации используете в своей деятельности Вы?

Модель AS-IS или модель «как есть» представляет собой модель бизнес-процессов на момент обследования предприятия и строится с целью понять, как функционирует данное предприятие с позиций системного анализа. Эта модель строится с целью выявления ошибок и узких мест, а также формулировки предложений по улучшению ситуации.

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

Контекстная модель:

Название: Реализация готовой продукции со склада.

Цель: Увеличение продаж.

Точка зрения: Начальник отдела продаж.

Входные данные: копия накладной, копия договора, заказ.

Выходные данные: требование, счет, выписка из журнала, отчет, отказ от выполнения заказа.

Управление: номенклатура крепежных изделий, текущая цена крепежных изделий, устав предприятия, положение об отделе продаж.

Механизмы: сотрудник отдела продаж.

Контекстная модель представлена на рисунке 18.

Рис.18. Контекстная диаграмма

Перейдем к построению диаграммы декомпозиции. Обработав анкеты, мы можем идентифицировать основные функции: проверка готовности заказа, организация оплаты, организация выдачи, подготовка отчетов. Диаграмма декомпозиции представлена на рисунке 19.

Рис.19. Диаграмма декомпозиции

Проанализируем интервью и рассмотрим реальную технологию работ сотрудника отдела продаж. На основании этих данных можно декомпозировать основные функции. Основная функция «Проверка готовности заказа» может быть декомпозирована на следующие действия: выборка договоров на текущую дату, прием заказов на текущую дату, сверка с журналом готовой продукции. Декомпозиция представлена на рисунке 20.

Основную функцию «Организация оплаты» можно декомпозировать на следующие действия: подсчет суммы оплаты, выставление счета, оплата счета. Основную функцию «Организация выдачи» декомпозируем так: выписка требования, сообщение на склад о подготовке товара, подготовка выписки для отдела договоров, изменение в журнале продаж. Основную функцию «Подготовка отчетов» декомпозируем на такие действия: анализ данных, выборка данных, печать отчетов. Соответствующие диаграммы представлены на рисунке 21, 22, 23.

Рис.20. Диаграмма декомпозиции A1

Рис.21. Диаграмма декомпозиции A2

Рис.22. Диаграмма декомпозиции A3

Рис.23. Диаграмма декомпозиции A4

Поскольку перед проектировщиками поставлена цель автоматизации документооборота, то, прежде чем декомпозировать процессы, имеет смысл рассмотреть модель документооборота. При этом, можно пойти двумя путями: рассмотреть отдельную модель документооборота и декомпозировать отдельные бизнес-процессы с помощью построения DFD-диаграмм.

⇐ Предыдущая567891011121314Следующая ⇒

Похожая информация:

Поиск на сайте:

Нотация ARIS Value-added Chain Diagram (ARIS VAD)

На рис. 2.30 представлена одна из важнейших нотаций ARIS - нотация ARIS VAD. Диаграмма цепочки процесса, добавляющего ценность, использует­ся при описании бизнес-процессов организации на верхнем уровне. Как прави­ло, консультанты, использующие ARIS, рекомендуют выделять шесть-восемь бизнес-процессов верхнего уровня и описывать их в нотации ARIS VAD. За­тем выполняется декомпозиция полученных процессов верхнего уровня в но­тации ARIS VAD или ARIS еЕРС.

Модели AS-IS и ТО-ВЕ

Рассмотрим объекты нотации ARIS VAD, представленные на рис. 2.30.

Основным объектом нотации ARIS VAD является Value-added chain - процесс или некоторая группа функций организации, которая служит для получения добав­ленной ценности. Объекты соединяются между собой пунктирной стрелкой, кото­рая имеет тип is predecessor of («является предшественником»). Этот тип связи по­казывает, что один процесс - предшественник другого. Очевидно, однако, что на практике все основные процессы цикличны. Кроме того, они имеют обратные свя­зи. Поэтому термин is predecessor of, на наш взгляд, является неудачным.

Между процессами, приведенными на рис. 2.30, могут быть отображены пото­ки материальных ресурсов и информации, для описания которых можно вос­пользоваться объектами типа Cluster и Technical term, соответственно. Для опи­сания инфраструктуры, необходимой для выполнения процесса, в данном приме­ре выбраны типы объектов Product/Service и Information service. Выбор типов объек­тов для отображения реальных потоков является в достаточной степени услов­ным. Очень важно в начале работ по моделированию процессов определиться, какие именно типы объектов будут использованы и какие объекты реального мира они будут отображать. Так, в случае примера, приведенного на рис. 2.30, можно было бы показать все потоки (информационные и материальные) при помощи объектов типа Technical term.

На рис. 2.30 показаны также объекты Organizational unit, отображающие под­разделения, выполняющие соответствующие процессы.

Объекты соединяются между собой при помощи связей определенного типа (см. рис. 2.30). Например, информационный поток, отображаемый объектом Cluster, является входящим для первого процесса и связан с ним при помощи стрелки типа is input for («является входом для»). Другой пример - тип связи executes («исполняет») между объектами Value-added chain и Organizational unit. Тип связи is used by показывает, что Product/Service используется процессом и т.д. Таким образом, в методологии ARIS важнейшим требованием является корректный выбор и дальнейшее использование связей и объектов определенного типа.

На рис. 2.31 представлен пример модели верхнего уровня, выполненный в нотации ARIS VAD. Вы уже знакомы с этим процессов. Выше, на рис. 2.16, этот же процесс представлен в нотации IDEF0.

88____________________________ ВВ. Репин, В.Г. Елиферов

Глава 2 Выбор методологии описания бизнес-процессов________________________________ 89

Принципы построения диаграммы процесса верхнего уровня в нотации ARIS VAD существенно отличаются от нотации IDEF0. Так. в нотации ARIS VAD стрелки могут входить в любую сторону объекта Value-added chain. (Напомним, что в нотации IDEF0 каждая сторона объекта Activity (функция) имеет глубоки и смысл). На рис. 2.32 представлена ситуация, возможная в нотации ARIS VAD. когда на диаграмме процесса приводится множество обратных связей, которые понятны только аналитику, создавшему модель.

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

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

90 В.В. Репин, В.Г. Елиферов. Процессный подход к управлению

2.7.2. Нотация ARIS еЕРС - расширение нотации IDEF3

Нотация ARIS еЕРС (extended Event Driven Process Chain) - расширенная цепочка процесса, управляемого событиями.

Нотация разработана специалис­тами компании IDS Scheer AG, Германия, в частности, профессором Шеером. В табл. 2.2 приводятся основные объекты, используемые в рамках нотации.

Таблица 2,2 Основные объекты, используемые при построении диаграмм еЕРС

Помимо основных объектов, указанных в табл. 2.2, при построении диаграм­мы еЕРС могут быть использованы многие другие объекты. На практике приме­нение большого числа объектов различных типов нецелесообразно, так как это значительно увеличивает размер модели и затрудняет ее прочтение.

91

Для понимания смысла нотации ARJS сЕРС рассмотрим основные используе­мые типы объектов и связей (рис. 2.34-2.38). На рис. 2.34 представлена простей­шая модель ARIS еЕРС, описывающая фрагмент бизнес-процесса предприятия.

Из рис. 2.34 видно, что связи между объектами имеют определенный смысл и отражают последовательность выполнения функций в рамках процесса. Стрел­ка, соединяющая Событие 1 и Функцию 1, «активирует» (activates) или иници­ирует выполнение Функции 1. Функция 1 «создает» (creates) Событие 2, за которым следует символ логического оператора «И», «запускающий» выпол­нение Функций 2 и 3.

Внимательный анализ нотации ARIS еЕРС показывает, что она практически не отличается от нотации IDEF3. Важнейшим отличием ARIS еЕРС является наличие объекта «событие» (event). Этот объект служит для отображения в модели возможных результатов выполнения функций, в зависимости от которых выпол­няется та или иная последующая ветвь процесса. Нотация ARIS еЕРС называет­ся, очевидно, расширенной именно вследствие наличия в ней объекта «событие» (в IDEF3 такого объекта нет). На рис. 2.35 приводятся примеры применения символов логики и событий при построении моделей в нотации ARIS еЕРС.

При построении моделей в ARIS еЕРС необходимо соблюдать следующие правила:

1. Каждая функция должна быть инициирована событием и завершаться
событием;

2. В каждую функцию не может входить более одной стрелки, «запускаю­
щей» ее выполнение, и выходить не более одной стрелки, описывающей
завершение выполнения функции.

Кроме этих правил, существуют и другие важные требования к формирова­нию моделей в ARIS. Их можно изучить с помощью методического материала «Методы ARIS». который устанавливается на компьютер одновременно с демо-версией продукта, а также в .

На рис. 2.36 показано применение различных объектов нотации ARIS еЕРС при создании модели бизнес-процесса.

92____________________________ ВВ. Репин, В.Г. Елиферов. Процессный подход к управлению

Из рис. 2.35 и 2.36 видно, что бизнес-процесс в нотации ARIS еЕРС представ­ляет собой последовательность процедур, расположенных в порядке их выполне­ния. Следует отметить, что реальная длительность выполнения процедур в ARIS еЕРС визуально отражена быть не может. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено вы-

Глава 2 Выбор методологии описания бизнес-процессов___________________________________ 93

полнение двух задач одновременно. Используемые при построении модели СИМ-ЮЛЫ логики позволяют отразить ветачение и слияние бизнес-процесса. Для по­лучения информации о реальной длительности процессов и визуального отобра­жения загруженности персонала в процессе можно использовать другие инстру­менты описания, например диаграммы Гантта в системе MS Project.

Рассмотрим примеры применения нотации ARIS еЕРС для описания биз­нес-процессов. На рис. 2.37. представлен бизнес-процесс обработки заказа кли­ента. Этот же процесс изображен в нотации IDEF3 на рис. 2.23.

Процесс начинается с события «Поступил заказ клиента». Это событие ини­циирует функцию «Выполнить учет заказа в системе», которую выполняет менед­жер Отдела сбыта. Для выполнения работы он использует «Систему учета зака­зов». Результат выполнения функции отображается событием «Учет заказа вы­полнен». После этого менеджер Отдела сбыта выполняет функцию «Выполнить анализ на соответствие номенклатуре». Результатом выполнения функции явля­ются два альтернативных события «Заказ соответствует номенклатуре» и «Заказ не соответствует номенклатуре». Процесс ветвится. Для отображения ветвления процесса используется символ логического оператора - исключающее «ИЛИ».

Функция «Уведомить клиента о невозможности выполнения заказа» может выполняться в двух случаях: 1) заказ не соответствует номенклатуре и 2) произ­водство невозможно. Для отображения на схеме процесса этих вариантов ис­пользуется символ логического оператора «ИЛИ» и т.д.

Как видно из рис. 2.37, схема процесса в ARIS еЕРС отличается от схемы в IDEF3 наличием объектов: событий, документов, прикладных систем и долж­ностей. Схема в ARIS eEPS визуально предстаатяется более информативной и воспринимается лучше, однако размер этой схемы существенно превышает раз­мер схемы в IDEF3.

Рассмотренный выше процесс может быть представлен также в нотации ARIS PCD (Process Chain Diagram) - разновидности ARIS еЕРС. На рис. 2.38 показан бизнес-процесс обработки заявки клиента в нотации ARIS PCD. При описании этого процесса использованы все объекты, которые составляют процесс, по­казанный на рис. 2.37, но расположены они в виде столбцов таблицы. В пер­вом столбце представлены события и некоторые символы логики, во втором - функции, в третьем - входящие и исходящие документы, в четвертом - виды прикладного программного обеспечения, в пятом - должности сотрудников, задействованных в процессе. Такое представление процесса является более «стан­дартным». Оно лучше подходит для целей документирования процессов. Одна­ко представление в нотации ARIS PCD обладает существенным недостатком - его можно эффективно применять для простых (не более пяти-восьми функ­ций), желательно линейных, процессов. Сложные процессы с разветвленной логикой отображать при помощи нотаций ARIS PCD неудобно, что наглядно видно на рис. 2.38.

94_________________________________ ВВ. Репин. В.Г. Елиферов. Процессный подход к управлению

Рис. 2.37. Пример модели процесса

Глава 2 Выбор методологии описания бизнес-процессов_______________________________ 95

в нотации AR1S eEPC.

96____________________________ В.В, Репин, В.Г. Елиферов. Проц ессный подход к управлению

Рис. 2.38. Пример обработки

Глава 2 Выбор методологии описания бизнес-процессов 9 7

заявки и нотации AR1S PCD.

98 В.В. Репин, В Г. Елиферов Процессный подход к управлению

Нотация AR1S Organizational Chart

Нотация ARIS Organizational Chan яа!яется одной ИЗ основных нотаций ARIS и предназначена для построения схем организационной структуры предприя­тия. Как правило, эта модель строится в начале проекта по моделированию бизнес-процессов. В модели отражаются существующие подразделения пред­приятия в виде иерархической структуры, как показано на рис.

Модель строится из объектов Organizational unit, Position, Internal person и др.

Заложенные в нотацию типы связей позволяют отразить различные виды от­ношений между объектами организационной структуры. В представленном на рис. 2.39 примере Предприятие управляется Директором, при этом используется тип связи is Organization Manager for. Иерархия подразделений строится при по­мощи связей типа is composed of. Кроме того, могут быть указаны должности - Position и фамилии реальных сотрудников, их занимающие - Internal person, тип связи occupies.

Кроме моделей иерархии подразделений, могут быть построены модели иерар­хии подчиненности в проектных командах, группах и т.д. Все отраженные в моделях объекты можно использовать в дальнейшем при формировании моде­лей бизнес-процессов. При построении сложных иерархических структур может быть применена декомпозиция, например, структуру подразделения возможно представить более детально.

Глава 2 Выбор методологии описания бизнес-процессов_________________________________ 99

Предыдущая78910111213141516171819202122Следующая

Модель AS-IS – это модель «как есть», т.е. модель уже существующего процесса/функции. Обследование процессов является обязательной частью любого проекта создания или развития системы. Построение функциональной модели AS-IS позволяет четко зафиксировать, какие процессы осуществляются на предприятии, какие информационные объекты используются при выполнении функций различного уровня детализации.
На основе модели AS-IS достигается консенсус между различными этапами процесса по тому, «кто что сделал» и что каждый этап добавляет в процесс. Функциональная модель AS-IS является отправной точкой для анализа потребностей предприятия , выявления проблем и “узких” мест и разработки проекта совершенствования деловых процессов. Модель AS-IS позволяет выяснить, «что и как мы делаем сейчас» перед тем, как определить то, «что и как будет делаться завтра». Анализ функциональной модели AS-IS позволяет понять, где находится проблемная ситуация, в чем будут состоять преимущества новых процессов и каким изменениям подвергнется существующая структура организации процесса. Исследование необходимости реструктуризации (выявление и ликвидация недостатков) в существующих процессах достигается за счет применения декомпозиции (анализа), производящаяся даже там, где функциональность на первый взгляд является очевидной.

Функциональная модель AS-IS

Так, например, признаками неэффективности существующих процессов могут быть:

• бесполезные, неуправляемые и дублирующиеся функции;
• неэффективный документооборот (нужный документ не оказывается в нужном месте в нужное время);
• отсутствие обратных связей по управлению (на проведение функции не оказывает влияния ее результат), входу (объекты или информация используются нерационально) и т. д.

При создании модели AS-IS неопытным аналитиком может возникать достаточно распространенная ошибка — это создание идеализированной модели, особенно в том случае, когда модель создается под влиянием знаний (точки зрения) руководителя. Обычно руководитель знаком с тем, как предполагается выполнение функции по руководствам и должностным инструкциям и часто не знает, как на самом деле подчиненные выполняют требуемые функции. Поэтому могут создаваться модели, называемые SHOULD BE (как должно бы быть), и несущие ложную информацию и которую невозможно в дальнейшем использовать для анализа.

Нотация моделирования бизнес-процессов BPMN (Business Process Modeling Notation) была впервые представлена публике еще в 2004 г. и описана консорциумом Object Management Group. В основе управления процессами в BPMN лежит идея, что сама стратегия управления опирается на три основные методологии: моделирования бизнес-процессов, анализа и оптимизации. В свою очередь, их поддерживает ряд инструментальных средств, служащих:

• для разработки стратегии, описания, анализа, документирования;
• информационной поддержки бизнес-процессов;
• поддержки потока работ (Workflow management).

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

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

• диаграммы активности UML;
• диаграмма потоков активностей и принятия решений ADF (activity decision flow);
• диаграмма событийных цепочек процесса ЕРС (event-driven process chain);
• нотация функционального моделирования IDEF (Icam DEFinition for functional modeling);
• другие модели (UMLEDOC Business Processes, RosettaNet, LOVeM).

В 2010 г. была опубликована версия BPMN 2.0, созданная при сотрудничестве многих исследовательских групп, в том числе консорциума OMG, Института Хассо Платтнера (Hasso Plattner Institut, Потсдам, Германия), университета Гумбольдта (Берлин, Германия), университетской инициативы Signavio.

В 2013 г. версия BPMN 2.0.1 была принята как международный стандарт IS0/1 ЕС 19510:2013 Информационные технологии. Модель и нотация процесса менеджмента объекта в групповом бизнесе.

Основные понятия и группы объектов в BPMN приведены в табл. 4.6.

Таблица 4.6

Основные понятия и группы объектов в BPMN

объектов	Описание
Действия	При помощи объектов Действия описываются задачи (бизнес-правила, сценарии, задачи-сервисы, задачи отправки сообщений и др.). Задачи затем детализируются, в том числе за счет маркеров действий (сценариев действий) и определения потоков (порядка и условий выполнения действий)
	События в BPMN, как и в некоторых других нотациях, относятся к категориям начальных, промежуточных и завершающих. К событиям относятся: отправка и получение сообщений, таймеры, ошибки, сигналы, остановы и другие виды событий. По сути, событие является индикатором происшествия, требующего дальнейшего участия пользователя, что возможно организовать, НЕ прерывая процесса (в отличие от предыдущих версий нотации)
Логические операторы	Логические операторы определяют порядок наступления событий процесса при ветвлении, слиянии или синхронизации
	Стандартные объекты данных (сообщения, хранилища, коллекции объектов), которые могут использоваться различными действиями
Хореография	Понятие, впервые появившееся именно во второй версии нотации BPMN. Его основная идея в отражении задач взаимодействия (обмена сообщения) между участниками (двумя и более)
Диалоги и взаимодействия	Определение характера информационных взаимодействий: один-к- одному либо один-ко-многим. Отличие от хореографии - в выделении нескольких пулов действий (swimlanes ) и детальном описании каждого из них (пример таких пулов приведен на рис. 4.17)
	Благодаря группе объектов Роли определяются: распределение обязанностей участников процесса; информационные потоки между ними; порядок обмена сообщениями

Нотация еЕРС (Extended Event-driven Process Chain, расширенная событийная цепочка процессов) предполагает описание алгоритма действий, выполняемых отдельными организационными единицами, что позволяет сформировать общий сценарий процесса как последовательность отдельных шагов.

Рис. 4.17.

Основными объектами диаграммы еЕРС являются элементы, приведенные в табл. 4.7.

Таблица 4.7

Объекты и нотация диаграмм еЕРС

Тип объекта	Описание	Графическое обозначение
	Состояние внешней и внутренней среды, являющееся также обязательным условием начала и окончания выполнения функции. Конечные события могут также быть начальными событиями для другого процесса
Логическое	Правила выполнения функции (если наступает только одно из событий или обязательно оба события) и правила наступления событий при выполнении функций (по сути, правила слияния и разделения ветвей процесса)
	Описание элемента работы, который представляет собой один этап процесса
Интерфейс процесса	Внешний (по отношению к текущей диаграмме) процесс или функция. Используется для указания взаимосвязи процессов (как для логической последовательности «следу- ющий/предыдущий процесс», так и для обозначения направления передачи объекта)
Объекты организационной схемы	Обозначение организационных единиц (должностей, подразделений, ролей) - исполнителей, владельцев или участников функций. Бизнес-роли в данном случае рассматриваются как требующие полномочий для управления функциями

еЕРС нс случайна названа «расширенной» диаграммой - на практике в модели такого вида могут также включаться другие объекты, например:

• товарно-материальные ценности;
• бумажные и электронные документы;
• продукты (используемые и производимые);
• объекты информации;
• информационные системы и их отдельные модули и функции;
• базы данных;
• цели (которые поддерживаются конкретной функцией);
• места выполнения (например, производственный цех № 4);
• другие элементы описания.

Между всеми объектами в обязательном порядке определяются связи, например, «создает» (документ), «распределяет» (задание между сотрудниками), «использует» (информационную систему 1C), «выполняет» (функцию выполняет менеджер), «принимает решение», «обеспечивает», «является владельцем» и многие другие.

Пример

Текстовое описание

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

Графическое описание

Рис. 4.18.

Как видно из рисунка 4.18, графическое описание алгоритма позволяет составить интегрированную картину процесса. Она, в свою очередь, может в дальнейшем использоваться либо как основа для «As-^-анализа, либо для последующей доработки и автоматизации как самого процесса, так и управления им с точки зрения достижения целевых показателей эффективности.

Архитектура интегрированных программных систем ARIS - инструментальная система моделирования бизнеса, разработанная компанией IDS Scheer AG и ныне принадлежащая Software AG.

ARIS и как методология, и как платформа обеспечивает проектирование, внедрение и управление бизнес-процессами как в процессе повседневной работы, так и для целей анализа, оптимизации и реинжиниринга бизнес-процессов.

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

Рис. 4.19.

Таким образом, ARIS как методология позволяет моделировать такие подсистемы предприятия, как организационная, функциональная, информационная, процессная и подсистема входов/выходов. Они формируются на трех уровнях описания, иерархически идущих от анализа проблем бизнеса к конкретной реализации при помощи ИТ:

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

Для каждого из представлений программный продукт ARIS предусматривает различные виды диаграмм:

• организационная диаграмма;
• диаграмма данных ERM;
• диаграммы BPMN 2.0;
• процессный ландшафт (цепочка добавленной стоимости VACD);
• системный ландшафт (диаграмма компонентов);
• иерархическая диаграмма активностей (whiteboard );
• диаграмма бизнес-процессов ЕРС;
• диаграмма ИТ-инфраструктуры (сети);
• диаграмма общего вида.

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

Расширения ARIS

Таблица 4.8

Дополнительные инструменты	Предоставляемые возможности
Процессная аналитика	Визуализация проблем производительности
	Получение отчетов/оповещений о достижении критических отметок показателей процессов
	Мониторинг данных, процессов и их ключевых индикаторов (например, функционально-стоимостной анализ затрат)
Управление	Управление бизнес-операциями, рисками и требованиями, контроль исключений
Управление политиками и соответствием требованиям регуляторов	Формирование карт политик в бизнес-контексте с разграничением зон ответственности
	Сочетание политик управления требованиями, рисками и процессами
	Ведение журнала аудита с возможностью формирования сложных отчетов (в том числе по контрольным панелям)
Управление взаимодействием: создание рабо- чей платформы коллаборации	Организация общих обсуждений процессов/приложений/данных
	Представление моделей процессов в формате web-страниц
	Публикация моделей процессов в интранет-сети компании
	Возможность для специалистов компании предложить свои улучшения в процессах
Симуляция	Возможность «прогона» (симуляции) моделей BPMN 2.0 и ЕРС для выявления различий моделей As-Is и То-Ве
	Получение статистики и сводной информации по результатам симуляции моделей в режиме реального времени
	Возможность проведения сценарного анализа «Что, если» для определения степени зависимости результата и показателей процессов от определенных факторов и групп факторов
Моделирование бизнес-правил	Возможность определения логики бизнес-правил и связывания сформированных с их помощью структурированных моделей с электронными таблицами (например, для анализа стоимости процесса)
Управление оптимизацией	Интеграция информации о структуре и значениях ключевых показателей эффективности процессов, моделях бизнес-процессов, информации о центрах затрат для поддержки принятия стратегических решений