Файл: Моделирование и описание бизнеспроцессов автор Э. А. Новосёлова Методы моделирования бизнеспроцессов.pptx

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

Основные методы:

метод функционального моделирования SADT/IDEF0;
метод моделирования процессов IDEF3;
моделирование потоков данных DFD;
нотация моделирования потоков работ BPMN;
метод ARIS;
метод моделирования, используемый в технологии Rational Unified Process

Обзор основных нотаций, используемых при моделировании бизнеса: BPMN, IDEF0/IDEF3, ARIS, UML

Business Process Modeling Notation (BPMN) представляет собой графическую нотацию для отображения бизнес-процессов при моделировании потоков работ, происходящих в исследуемой системе. Нотация BPMN была разработана организацией Business Process Management Initiative (BPMI), в настоящее время разработка BPMN ведётся консорциумом OMG (Object Management Group).
Целью проекта BPMN является создание общей нотации разработки моделей бизнес-процессов для различных категорий специалистов: от аналитиков и экспертов, моделирующих бизнес-процессы, технических разработчиков, которые создают системы для выполнения этих процессов, до менеджеров различных уровней, которые должны понимать процессные диаграммы, чтобы принимать деловые решения. BPMN призвана служить связующим звеном между фазой дизайна бизнес-процесса и фазой его реализации.
Благодаря абстрактному представлению модели нотация BPMN позволяет наглядным образом описывать модели бизнес-процессов независимо от среды их функционирования. Для реализации нотации модели используются языки исполнения бизнес-процессов — BPML (Business Process Modeling Language) и BPEL (Business Process Execution Language).

IDEF0. Краткое описание

Одной из самых известных и распространенных методологий бизнес-анализа и функционального проектирования информационных систем является методология SADT (Structured Analysisand Design Technique), введенная в 1973 году Дугласом Россом. SADT успешно использовался и используется в военных, промышленных и коммерческих организациях для решения широкого спектра задач. Подмножеством SADT является стандарт IDEF0, который, обладая автоматизированной поддержкой, является доступным и простым в употреблении. Согласно этой методологии анализируемый процесс представляется в виде совокупности взаимосвязанных действий, которые имеют четко определенные вход и выход и взаимодействуют между собой на основе определенных правил и с учетом потребляемых информационных, человеческих и производственных ресурсов.

Описание особенностей

Функциональная модель системы описывает совокупность выполняемых системой функций и характеризует морфологию системы – состав подсистем, их взаимосвязи. Такая модель рассматривает систему как набор действий, каждое из которых преобразует некоторый объект или набор объектов. Функциональные модели выделяют действия посредством представления в виде специального элемента – функционального блока. Блок, изображающий некоторую бизнес-функцию (англ. Activity, говорят также «действие» или «работа»), является центральным элементом нотации IDEF0.

Блок имеет четыре стороны:

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

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

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

Принцип декомпозиции в IDEF0

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

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

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

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

Шаг 1. Построение модели «как есть». Построение функциональной модели «как есть» позволяет четко определить, какие бизнес-процессы имеют место в компании и какие информационные объекты используются при выполнении процессов и отдельных операций.
Шаг 2. Определение бизнес-правил. Функциональная модель бизнес-процессов позволяет выявить и точно сформулировать бизнес-правила, используемые в деятельности компании.

Шаг 3. Построение модели «как должно быть». Данная модель описывает бизнес-процессы, полученные в результате реинжиниринга или скорректированные в ответ на изменения условий работы компании или выполнения отдельных операций.
Шаг 4. Распределение ресурсов. Функциональная модель позволяет четко определить распределение ресурсов между операциями бизнес-процесса, что дает возможность оценить эффективность использования ресурсов. Особенно эта задача актуальна при создании новых бизнес-процессов на предприятии.

Пример бизнес-процесса документооборота

Преимущества и недостатки IDEF0

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

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

Методология IDEF0 успешно применялась и применяется в различных отраслях экономики как эффективное средство анализа, проектирования и представления бизнес-процессов.
Она принята в качестве стандарта в ряде международных организаций, в том числе в НАТО и МВФ. В России IDEF0 нашла свое применение в государственных учреждениях, в ЦБ РФ и коммерческих банках, на предприятиях нефтегазовой промышленности и других отраслей.
В настоящее время существует целый ряд программных инструментов, поддерживающих функциональное моделирование в стандарте IDEF0. В России получили распространение такие системы, как BPwin и ERwin, функции которых теперь объединены в продукте ERwin Process Modeler компании Computer Associates, IDEF0. EMTool (ИП Ориентсофт), Design/IDEF (Meta Software).

Методология ARIS – архитектура интегрированных информационных систем (Нотация EPC)

Нотация EPC (Event-Driven Process Chain – цепочка процессов, управляемая событиями) была разработана в 1992 г. Институтом информационных систем при Саарском университете (Германия) в рамках научно-исследовательского проекта, финансировавшегося компанией SAPAG.

EPC по своей сути является расширением методологии IDEF3 за счет использования такого понятия, как событие (англ. event). Под событием мы будем понимать тот факт, что информационный объект (например, заказ) получает связанный с бизнес-процессом статус (например, «получен»), который управляет или воздействует на дальнейшее выполнение бизнес-процесса. События могут «переключать» бизнес-функции, т.е. передавать управление от одной функции к другой, а также быть результатом выполнения функций. В отличие от бизнес-функций, которые имеют некоторую продолжительность, события происходят моментально.

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

Одно событие может инициировать выполнение одновременно нескольких бизнес-функций, и наоборот, в результате выполнения функции могут наступить нескольких событий. Такие ветвления и циклы обработки отображаются на диаграмме EPC с помощью операторов, показанных на рис. 3.2.
Например, на рис. 3.1 используются два оператора «И», первый из которых соединяет функции и говорит о том, что событие «Заявка зарегистрирована» вызывает исполнение сразу двух функций: «Оформить договор» и «Организовать подключение».
Второй оператор «И» соединяет события и означает, что функция «Начать предоставление услуги» не начнет выполняться, пока не произойдут оба входящих события: «Договор оформлен» и «Подключение организовано».
Операторы не только отображают графические связи между элементами модели, но и определяют логические связи между соответствующими объектами. Использование того или иного оператора не всегда допустимо: события, в отличие от функций, не могут принимать решения, поэтому переключающее событие не должно быть связано срезультирующими бизнес-функциями операторами «ИЛИ» или «исключающее ИЛИ».

Для построения диаграмм бизнес-процессов в методологии ARIS применяется расширение нотации EPC – extendedEPC (eEPC), хотя сегодня под EPC нередко подразумевают уже расширенную нотацию.
В eEPC помимо рассмотренных нами объектов – функций, событий, связей (стрелок) и операторов – используются следующие объекты:
 организационная единица (англ. organizationalunit) служит для обозначения различных организационных звеньев компании;
 документ (англ. document) отражает реальные носители информации, например бумажный документ;
 прикладная система (англ. applicationsystem) обозначает реальную прикладную систему, используемую при выполнении функции;
 кластер информации (англ. cluster) используется для создания моделей данных и характеризует данные как набор сущностей и связей между ними.

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