Бесплатный 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й согласователь Подтвердите запрос Сделан запрос документ и комментарий удалены задача завершена

8. Выберите преимущества формального подхода к формиро­ ванию бизнес-модели предприятия:

9. Недостатками гуманитарного подхода к формированию бизнес-модели предприятия являются:

Тема 2. Процессная бизнес-модель предприятия

2.1. Эволюция организации бизнеса

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

2.3. Классификация бизнес-процессов предприятия

2.4. Управление бизнес-процессами предприятия

Ключевые факторы успеха (кфу)

2.5. Оценка эффективности управления бизнес-процессами

Тема 3. Основы моделирования бізнес-процессов

3.1. Сущность и необходимость моделирования бизнес-процессов

3.2. Нотации создания бизнес процессов

3.3. Современные методологии моделирования бизнес-процессов

Бизнес-процессов

Методология sadt

Методология idef3

2. Выберите предметные области моделирования:

Тема 4. Методология управления качеством бизнес-процессов

4.1. Системы концепции совершенствования бизнес-процессов

Система «канбан»

Система «5s»

Система «три»

Система «кружкикачества»

Цикл pdca

Цикла Шухарта-Деминга

Система «шесть сигм»

В концепции Six Sigma

Система «кайдзен»

4.2. Инструменты управления качеством бизнес-процессов

Гистограмма

Контрольные карты

Стра тификация

Диаграмма исикавы

Диаграмма парето

4.3. Методологический инструментарий управления качеством отдельных бизнес-процессов

17. Что представляет собой концепция «Шесть сигм»?

18. Выберите последовательность действий при использова­ нии колеса Деминга:

20. Сколько циклов содержит цикл Шухарта-Деминга?

Тема 5. Ресурсная бизнес-модель предприятия

5.1. Ресурсный подход в управлении предприятием

5.2. Сущность, виды и структура ресурсов предприятия

5.3. Зависимость результативности деятельности предприятия от ресурсов

5.4. Формирование ресурсной бизнес-модели предприятия

5.5. Оптимизация распределения сырьевых ресурсов на предприятии

Тема 6. Информационная бизнес-модель предприятия

6.1. Основные понятия и элементы информационной бизнес-модели

6.2. Информационная среда экономической деятельности предприятий

6.3. Информационные системы: развитие, виды, характеристика

6.4. Облачные вычисления - бизнес платформа XXI века

6.5. Формирование информационной бизнес-модели предприятия

11. Что представляет собой информационная индустрия?

Тема 7. Матричная бизнес-модель предприятия

7.1. Основные понятия и виды матричных моделей в экономике

7.2. Матричные инструменты в системе управления предприятием

Матрица приоритетов

7.3. Экономические матричные модели в оценке эффективности деятельности предприятия

7.4. Формирование матричной бизнес-модели предприятия во внешней среде

1. Что понимают под матричной мо­делью?

2. Что представляет собой матричная диаграмма?

14. На рисунке представлена матрица показателей. Расставьте показатели по степени важности для начала действий по совер­ шенствованию.

Тема 8. Компетентностная («3d») бизнес-модель предприятия

8.1. Сущность и основные элементы компетентностной («3d») бизнес-модели предприятия

Компетенциями

8.2. Методический подход к формированию компетентностной («3d») бизнес-модели

Приложение д

Предприятия

3.2. Нотации создания бизнес процессов

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

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

Модель бизнес-процесса - прикладное представление (в за­данной нотации) исполняемых предприятием работ.

В практике деятельности предприятий применяются модели разной направленности:

модель бизнес-процессов верхнего уровня - агрегирован­ная, наиболее общая модель бизнес-процесса предприятия;

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

модель бизнес-процесса потоковая, отражающая материаль­ные, финансовые и информационные потоки объектов;

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

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

Формы описания бизнес-процесса:

текстовая;

табличная;

алгоритмическая.

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

Применение табличной формы (рис.3.2) делает описание про­цесса четким и упрощает его восприятие. Каждый параметр процесса отражается в отведенном столбце таблицы, а не «размывается» в тек­сте.

Описание бизнес-процесса	Ответствен­ный испол­нитель	Входная ин­формация	Срок ис­полнения	Исходящая документация результат	Потребитель результата бизнес-процесса

Рис. 3.2. Пример табличного представления бизнес-процесса

Использование алгоритмических схем (рис. 3.3; 3.4) целесооб­разно в случаях, когда последовательность выполнения бизнес-процесса (подпроцессов, процедур) допускает вариантность исполне­ния (последовательное выполнение сочетается с параллельным, ветв­ление процесса и т. д.). Алгоритмические схемы призваны отобразить логическую связь процессов, к тому же они более наглядные и «чита­емые».

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

Если применять только алгоритмическую схему, на ней необхо­димо будет указать все существенные параметры процесса - испол­нителей, входы, выходы, поставщиков, клиентов и т. д. В результате схема получится громоздкой и «трудночитаемой», что снизит ее практическую ценность.

Для составления алгоритмических схем используют специаль­ные графические элементы (рис. 3.5), совокупность которых опреде­ляет нотацию моделирования. Наиболее популярными для описания бизнес-процессов являются: алгоритмическая блок-схема, Basic Flowchart, Cross-Functional Flowchart, Event-driven Process Chain,

IDEFO, 1DEF3, Data Flow Diagrams, Work Flow Diagram. Выбор нота­ции моделирования зависит от его целей и от программного продук­та, применяемого для этого. Обычно используют 3^1 и более нота­ций.

Наиболее распространенные нотации детализации (способы описания бизнес-процессов) - это представление процессов как ал­горитмов в виде блок-схем и описание процесса в виде потока объек­тов. Под потоком объектов понимается информация, документы, дру­гие ресурсы.

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

2. Определить какой тип модели бизнес процесса вам необходимо построить и выбрать список методологий, которые могут быть использованы при моделировании (используйте путеводитель, описанный ниже);

3. Сравнить методологии и нотации моделирования для вашего типа модели и выбрать подходящую для вас методологию:

• Методологии моделирования бизнес процессов верхнего уровня и потоков данных;
• Методологии моделирования потоков работ;
• Методологии моделирования структуры информации.

4. Построить модель.

Путеводитель по нотациям и методологиям

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

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

Классические методологии

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

Одной из главных стадий при проектировании ИС является описание бизнес-процессов, для чего необходимо выбрать нотацию, в которой оно будет выполнено. На данный момент существует ряд наиболее распространенных языков графического описания бизнес-процессов: IDEF, UML и ARIS. Для выбора наиболее подходящей для данной работы нотации описания бизнес-процессов, необходимо выполнить анализ каждой из них и оценить достоинства и недостатки.

IDEF - это семейство методов моделирования, состоящее из 15 подходов описания бизнес процессов (от IDEF0 до IDEF14). Данная нотация применяется для построения функциональной модели системы . Несмотря на большое количество нотаций, входящих в эту методологию, наиболее часто применяемыми на практике являются IDEF0 и IDEF3, которые будут рассмотрены в рамках текущего анализа. Пример диаграммы IDEF0 отображающей функции и процедуры, а также потоки информации и материальных средств отображен на рис. 1.2.

Рисунок 1.2. Нотация IDEF0

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

Рисунок 1.3. Нотация IDEF3

При отслеживании потоков документации при использовании методологии IDEF возникает необходимость совместного использования нотации DFD.

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

Рисунок 1.4. Диаграмма языка UML

Для описания бизнес-процессов используется диаграмма деятельности.

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

Рисунок 1.5. Диаграмма ARIS

Методология поддерживает четыре типа моделей, отражающих различные аспекты системы:

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

Каждая нотация предоставляет большое количество возможностей для описания бизнес-процессов. Однако моделирование событий в ARIS позволяет создавать более подробные и корректные описания процессов, но необходимо обратить внимание на сложность и трудоемкость описания по сравнению с другими рассмотренными нотациями (Таблица 1.1 ). Эффективность использования нотаций может варьироваться в зависимости от решаемых задач. Например, отсутствие четких соглашений по моделированию управляющих воздействий в рамках ARIS может привести к созданию моделей, не отвечающих на поставленные вопросы, в то время как нотация IDEF0 позволяет решить эту задачу. С другой стороны, процедура, выполняемая одним сотрудником, может быть более адекватно описана при помощи языка ARIS, чем при помощи IDEF0 или IDEF3.

Таблица 1. 1. Сравнительная таблица нотаций описание бизнес-процессов

	Показатель
	Принцип построения диаграммы	Принцип иерархии		Временная последовательность выполнения процедур	Временная последовательность выполнения процедур
	Входящая информация	Стрелки сверху / слева			Используется отдельный объект
	Исходящая информация	Стрелка справа		В диаграмме активности нет - отображается в отдельной диаграмме	Используется отдельный объект
	Наглядность модели
	Возможность взаимосвязи функциональной и информационной модели
	Основная область применения методологий		Для построения модели бизнес-процессов		Для разработки основы ИС и моделирования БП

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

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

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

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

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

Разрабатываемая ИС удовлетворяет следующие требования:

• · справочный характер ИС - разрабатываемая система в диалоговом режиме предоставляет пользователям необходимую в процессе реализации проектов информацию (советы, извлеченные уроки, шаблоны документов и др.);
• · экспертный характер ИС - при заполнении системы начальными данными, в том числе определение показателей оценок методик и рангов проектов, применены опыт, мнения и советы ведущих экспертов Компании;
• · аналитический характер ИС - для реализации системы были проанализированы методики управления проектами и выбраны наиболее критичные (в рамках данного исследования) данные для включения в систему;
• · база знаний в ИС - при создании в системе нового проекта определение методики его ведения происходит посредствам семантических правил в режиме «вопрос-ответ», расчет и определение которых выполняется в соответствие с рангами методик по показателям (Приложение Б.);
• · база документов в ИС - в системе хранится ряд документов в библиотеках узла: проектные процедуры, шаблоны календарных планов, уставов и т.п.;
• · база данных в ИС - подход реализации узлов на порталах SharePoint можно представить как реляционную базу данных, в которой её таблицами являются списки SharePoint.

Системой управления реализуемых бизнес-процессов является платформа разработки ИС - MS SharePoint 2013.

Разработка информационной системы, описание бизнес-процессов и настройка системы на платформе SharePoint 2013 приведена в Главе 2.

«В какой нотации нам лучше строить свои бизнес-процессы? » — довольно частый и один из самых странных вопросов, которые мне приходилось слышать. Дело в том, что выбор нотации для бизнес-моделирования целиком и полностью зависит от целей и задач предприятия, которое решило перейти к процессному управлению.

Ещё раз об IDEF0

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

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

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

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

BPMN – новый взгляд на процессы

BPMN – относительно новая нотация, первая версия которой появилась в 2005 году. Нотация ориентирована на детальное описание потоков работ, и наилучшим образом подходит для моделирования процессов на нижнем уровне. Нотация BPMN обладает одной ключевой особенностью — все диаграммы, построенные с соблюдением спецификации BPMN могут быть «выполнены» системой в режиме реального времени.

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

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

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

FlowChart – назад к основам

На самом деле нотации с таким названием не существует, имеется множество вариаций на тему обычной блок-схемы, например, Basic FlowChart, Сross Functional Flowchart и т.д.. Все эти нотации позволяют описывать потоки работ и распределять ответственность за выполняемые функции внутри процесса. Множество программных продуктов используют разновидности этих нотаций для описания процессов нижнего уровня в дополнение к описанию процессов верхнего уровня при помощи IDEF0.

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

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

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

eEPC – мы пойдём своим путём

Авторами нотации eEPC является известная немецкая фирма IDS Scheer AG. Как и нотации на базе FlowChart, eEPC предназначена для описания процессов нижнего уровня, вот только в основе неё лежат не функции персонала, а события, которые в свою очередь уже инициируют выполнение какого-либо действия со стороны персонала. Из-за данной особенности стандартные процессы получаются почти в два раза больше по сравнению с их аналогами, описанными в нотации FlowChart.

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

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

Разумеется, данная заметка не презентует на полноту изложения и не раскрывает особенности использования каждой нотации в отдельности, зато надеюсь, что после прочтения данной статьи, вопросов в стиле «Что нам выбрать BPMN или IDEF0? » станет меньше.