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

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

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

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

Нотация моделирования бизнес-процессов 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 и То-Ве
	Получение статистики и сводной информации по результатам симуляции моделей в режиме реального времени
	Возможность проведения сценарного анализа «Что, если» для определения степени зависимости результата и показателей процессов от определенных факторов и групп факторов
Моделирование бизнес-правил	Возможность определения логики бизнес-правил и связывания сформированных с их помощью структурированных моделей с электронными таблицами (например, для анализа стоимости процесса)
Управление оптимизацией	Интеграция информации о структуре и значениях ключевых показателей эффективности процессов, моделях бизнес-процессов, информации о центрах затрат для поддержки принятия стратегических решений

12.10.2011 Игорь Федоров

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

Cпоры о выборе нотации для моделирования бизнес-процессов по-прежнему не утихают. Анализу подвергаются возможности нотаций EPC (Event-driven Process Chains) и BPMN (Business Process Modeling Notation), синтаксис, набор примитивов языка описания и т. д. Однако сравнивать нотации и языки описания бизнес-процесса путем анализа их функциональности некорректно - является ли модель функциональной или процессной, определяет не только нотация, но и методология. Часто методология моделирования подменяется нотацией, что приводит к серьезным ошибкам в проектировании бизнес-процессов и появлению некачественных моделей.

Модели и перспективы

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

Функциональная: «Что делают участники?». Описывает состав выполняемых работ.

Поведенческая: «Как работают участники?». Описывает очередность, расписание выполнения, бизнес-правила.

Информационная: «Что обрабатывают участники?». Описывает бизнес-сущности предметной области процесса.

Организационная: «Кто выполняет работу?». Описывает состав и структуру исполнителей.

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

Функциональная перспектива

Функциональная модель описывает систему в статическом состоянии, помогает ответить на вопрос «что надо делать для достижения поставленной цели?». Ответом является перечень всех действий, которые необходимо выполнить, чтобы добиться запланированного результата. В управлении проектами широко применяется структурная декомпозиция работ (Work Breakdown Structure) - перечисленные в ней действия не связаны временной последовательностью. Аналогично, при моделировании процессов очень полезно создать структурную декомпозицию, которая поможет понять логику процесса и не забыть выполнить какую-либо важную функцию. Если две разные организации выполняют один и тот же процесс, то функциональная декомпозиция работ у них будет одинаковой, хотя очередность исполнения работ может меняться с учетом отличий их организационной структуры. Таким образом, функциональная модель слабо зависит от организационной структуры и может рассматриваться как справочная.

Часто функциональную модель ошибочно называют картой процессов; например, модели SCOR (The Supply-Chain Operations Reference-model) и ETOM (Enhanced Telecom Operations Map) содержат иерархии функций и цепочки создания ценности, но отнюдь не процессы . Даже руководящие документы TeleManagement Forum призывают различать процесс как последовательность выполняемых действий и процесс как направление деятельности компании.

Аспекты поведенческой перспективы

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

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

Бизнес-логика процесса

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

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

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

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

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

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

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

Расписание исполнения

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

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

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

Степень детализации бизнес-логики

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

Руководящий документ Госстандарта России, «Методология функционального моделирования IDEF0» вводит понятия «действие» и «операция». Действие определяется как «преобразование какого-либо свойства материального или информационного объекта в другое свойство», а операция - как «совокупность последовательно или/и параллельно выполняемых действий».

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

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

Степень полноты бизнес-логики процесса

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

Сравнительный анализ нотаций EPC и BPMN

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

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

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

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

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

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

Интерес к BPM и BPMS (Business Process Management Suite) достиг той степени зрелости, когда уже не приходится говорить о моде. Кроме этого, закончилась война стандартов и нотация BPMN получила признание всех крупных игроков, став стандартом де-факто. Это событие по значимости можно сравнить с появлением SQL, ставшего основой современных информационных систем.

BPMS окончательно сформировался как класс программного обеспечения для поддержки графического моделирования бизнес-процессов, исполнения модели бизнеспроцессов, мониторинга и анализа (Business Activity Monitoring, BAM). Однако разные продукты реализуют эту функциональность по-разному, и при выборе конкретной BPMS в первую очередь следует обращать внимание на следующее.

Поддержка BPMN. Какая версия BPMN поддерживается (1.x или 2.0)? Насколько полна реализация: поддерживаются ли сообщения, сигналы, транзакционные подпроцессы?

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

Не следует забывать, что BPMS – это только одна из составляющих BPM, и для успеха проекта создания системы управления бизнес-процессами необходимы также компетенции в методологии и в управлении agile-проектами.

Анатолий Белайчук ([email protected]) – президент компании «Бизнес-Консоль» (Москва).

Проблемы трансляции диаграммы EPC в исполняемый формат

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

Перечислим типовые ошибки моделирования.

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

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

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

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

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

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

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

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

Литература

B. Curtis, M. Kellner, J. Over. Process Modeling, 1992.
eTOM, Representative process flows. ITU. s.l.: Telecommunication Standardization Sector Of ITU, 2004.
R. Ross. Principles of the Business Rule Approach. Addison-Wesley Professional (2003).
C. Pedrinaci, Domingue, A. Alves de Medeiros. A Core Ontology for Business Process Analysis, Proceedings of the 5th European semantic web conference on The semantic web: research and applications, Springer-Verlag Berlin, Heidelberg, 2008.
Методология функционального моделирования IDEF0. Москва: Госстандарт России, 2000.
N. Russell, A. ter Hofstede, W. M. P. van der Aalst, N. Mulyar, Workflow control-flow patterns.
Methods ARIS 7.0. Saarbrucken: IDS Scheer AG, 2005.
B. Silver, BPMN Method & Style. Cody-Cassidy Press, 2009.

Игорь Федоров ([email protected]) – директор Центра компетенции процессного управления МЭСИ (Москва).

Моделирование бизнес-процессов, перспектива моделирования, функциональное и процессное моделирование

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 и более нотаций.

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

Одной из главных стадий при проектировании ИС является описание бизнес-процессов, для чего необходимо выбрать нотацию, в которой оно будет выполнено. На данный момент существует ряд наиболее распространенных языков графического описания бизнес-процессов: 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.