что такое нотации описания бизнес процессов

Использование нотации eEPC для графического описания бизнес-процессов

Всякая вещь есть форма проявления беспредельного разнообразия.
Козьма Прутков

Введение в нотацию eEPC

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

Главный «стержень» нотации eEPC

Как я уже упоминал, в дословном переводе аббревиатуры eEPC кроется понятие событийности. Это очень важный момент, на котором и строится весь принцип построения схемы. Итак, есть два ключевых понятие: «Событие» и «Функция». Когда кто-то первый раз попытаетесь нарисовать свой процесс в виде диаграммы eEPC, то часто возникает вопрос, а чем отличается событие от функции? Это надо четко себе уяснить, иначе получится непредсказуемый результат. Так вот: событие – это факт свершения чего-либо, причем не имеющий продолжительности во времени, либо это время стремиться к нулю (или не имеет значения). Причем событие всегда вызывает необходимость исполнения функции, и исполнение функции всегда заканчивается событием Поясню на примере. Звонит телефон. Менеджер взял трубку для телефонного разговора. В данном случае «Звонит телефон» — это событие. Телефонный разговор – это функция. Разговор завершен (повесил трубку) –снова событие. Таким образом, наблюдается событийная цепочка: Звонок – разговор – завершение звонка. А завершении звонка наверняка потребует выполнение новой функции: запись результата звонка и т.д.
Давайте попробуем это нарисовать. Для начала надо выяснить, как отображаются элементы «Событие» и «Функция».

Вот такие два простых элемента составляют основу правил описания бизнес процессов в нотации eEPC. Думаю, надо сказать пару слов об используемых цветах. Если Вы сталкивались с описание процессов в других нотациях, как правило они были черно-белые. И это правильно, явной зависимости содержания от цвета быть не должно, т.к. схема может быть нарисована карандашом на бумаге, распечатана на черно-белом принтере и пр. В данном случае (в нтации eEPC) так исторически сложилось, что элементы имеют определенные цвета. Не сказать, чтобы это было обязательно, но привычка вырабатывается, да и восприятие в электронном виде лучше – сразу видно что есть что. Эти цвета можно рассматривать как рекомендацию. Почему они такие? Точно не уверен, но мне кажется от того, что компания ARIS, когда сделала в своем продукте поддержку нотации eEPC, дала им такие цвета, они и «прижились». Кстати, иногда эту нотацию еще называют «ARIS», «ARIS EPC», что является не совсем верным, т.к. компания ARIS не изобретала эту нотацию, а сделала ее поддержку в своей программе моделирования бизнес-процессов. В общем, рекомендую использовать цвета. Главное, чтобы сама форма элементов не была одинаковой (т.е. отличаться лишь цветом), т.к. в черно-белом варианте это может вызвать путаницу. Существуют и другие правила, которые позволяют придать «стройность» диаграмме eEPC, мы будем о них говорить.
Итак, есть событие, есть функция. Как они связаны?
Мы видим, что событие1 привело к необходимости выполнять некую функцию, которая завершилась событием2. Если применительно к примеру с телефонным звонком, то будет так:

Связку событие – функция — событие принято отображать сверху вниз в одну линию либо слева направо. Направление цепочки указывается связывающими линиями со стрелками.

Мы видим, что оператор выполняет обработку входящего звонка, действуя в соответствии с правилами обработки входящих звонков и использует для этого программу «CRM». Ни входящих, ни исходящих документов при этом не используется.
Как я уже упоминал, одной из сильных сторон нотации являются элементы логики. Одновременно это и один из самых сложных для понимания моментов. Поэтому, сначала я приведу пример, а потом мы отдельно будем разбираться с элементами логики.
Пусть в нашем примере будет так: в случае заинтересованности клиента дальнейшую работу с ним проводит менеджер по продажам и выставляет коммерческое предложение, которое отправляет по почте с использованием почтового клиента «MS Outlook». Если заинтересованности нет, то обработка звонка завершена. В реальной жизни хорошо бы использовать и правила завершения звонка, но это я так, к слову, пока это упростим. Вот что получится:

Элементы логики в схемах нотации eEPC

Как видите, существует два варианта графического представления элементов логики. Они ничем не отличаются, совершенно альтернативные. Я привел их оба, т.к. на практике в различных источниках можно увидеть оба варианта. Какой из них использовать, решать Вам. Мне больше нравится первый.
Теперь необходимо разобраться с применением элементов логики. Сначала рассмотрим встречающиеся варианты, затем перейдем к примеру. Разберем каждый элемент в отдельности.
Логический элемент «И».

Когда для выполнения функции требуется одновременное выполнение нескольких событий:

Пример: Если закрыт отчетный период (событие 1) и наступил срок подачи отчета руководителю (событие 2), сотрудник готовит ежемесячный отчет.

Соединение элементов, если при выполнении функции, возникает несколько событий:

Пример: Завершена некоторая работа с заказчиком. Одновременно зафиксировано два события: взаиморасчеты сверены (событие 1), акт подписан (событие 2).

На практике такое применение встречается не часто. Как правило, если в одной функции объединено много действий.

Соединение элементов, если при выполнении нескольких функций, возникает событие:

Пример: Кладовщик собрал заказ (функция 1), оператор выписал документы (функция 2), товар готов к отгрузке (событие).

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

Пример: Поступила партия товара (событие). Одновременно начинается отгрузка ранее заказанного клиентами товара и размещение оставшегося на складе.

Логический элемент «ИЛИ».
Соединение элементов, если одно из событий может вызвать выполнение функции:

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

Пример: Подготовлен и отправлен товар счет для отправки клиенту. Счет мог быть отправлен по почте (событие 1), по факсу (событие 2).

Соединение элементов, когда выполнение нескольких функций вызовет событие:

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

Логический элемент «ИСКЛЮЧАЮЩЕЕ ИЛИ».

Соединение элементов, когда для выполнения функции необходимо одно и только одно из событий:

Пример: Клиент приехал в магазин лично (событие 1) или совершил заказ через интернет (событие 2). Необходимо выполнить отгрузку товара (функция 1).

Соединение элементов, если в результате выполнения функции происходит максимум одно из событий:

Пример: Решение либо принято либо нет.

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

Пример: Доставка товара осуществлена (событие 1) либо собственным транспортом (Функция 1), либо транспортной компанией (функция 2)

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

Попробуйте применить элементы логики на практике. Если будут трудности, напишите мне, постараюсь помочь.

Расширение нотации собственными элементами

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

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

Соглашения о правилах размещения фигур на схеме

Сама по себе нотация eEPC не предъявляет жестких требованиях в расположении элементов друг относительно друга, хотя принято рисовать схему сверху вниз или слева направо. Есл это не унифицировать в случае работы нескольких специалистов, то может получиться своеобразный «винегрет». Что бы этого избежать, рекомендуется выработать и утвердить свои правила расположения элементов.

Я придерживаюсь (и рекомендую) следующих правил:

Идентификация элементов на диаграмме

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

Отображение обратной связи

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

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

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

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

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

Источник

Краткий путеводитель по методологиям и нотациям описания и моделирования бизнес-процессов. Часть 1

Аналитики скорее всего не раз задавались вопросами – почему нотаций и методологий так много, какую из них выбрать, какая из них будет правильной…?

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

ОСНОВНЫЕ ОПРЕДЕЛЕНИЯ И ТЕРМИНЫ

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

Описание бизнес-процессов – это документирование процесса в свободной форме, например, простое текстовое описание пользовательских сценариев (Use Case).

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

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

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

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

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

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

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

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

Или если более кратко – это способ достижения какой-либо цели, а способом будет нотация моделирования процессов.

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

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

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

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

1. СТРУКТУРНОЕ МОДЕЛИРОВАНИЕ

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

1.1. ФУНКЦИОНАЛЬНОЕ МОДЕЛИРОВАНИЕ

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

1.2. ИМИТАЦИОННОЕ МОДЕЛИРОВАНИЕ

Имитационное моделирование (или моделирование проведения) – представление поведения системы во времени, описание поведения бизнес-процессов при различных внешних и внутренних условиях с анализом как динамических характеристик процессов, так и с распределением ресурсов.

CPN (Цветные сети Петри)

1.3. ИНФОРМАЦИОННОЕ МОДЕЛИРОВАНИЕ

Информационное моделирование дает представление объектов предметной области, их свойств и отношений между ними.

Нотация Баркера (Barker Notation)

Нотации IDEF1 и IDEF1X (Integration Definition for Information Modeling)

2. ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ МОДЕЛИРОВАНИЕ

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

Язык графического описания

Метод Джеймса Румбаха ( OMT)

Метод Айвара Джекобсона (OOSE)

3. ИНТЕГРИРОВАННОЕ МОДЕЛИРОВАНИЕ

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

КРАТКОЕ ОПИСАНИЕ МЕТОДОЛОГИЙ И МЕТОДОВ

Методология структурного анализа и проектирования SADT (Structured analysis and design technique) – представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта (производимые им действия и связи между этими действиями) какой-либо предметной области. Разработана Дугласом Россом в 1969-1973 годах. Эта методология возникла под сильным влиянием PLEX, концепции клеточной модели человек-ориентированных функций Хори, общей теории систем технологии программирования и кибернетики. Она изначально создавалась для проектирования систем более общего назначения по сравнению с другими структурными методами, выросшими из проектирования программного обеспечения.

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

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

Элементы методологии SADT (синтаксис):

Самая распространенная нотация методологии SADT: IDEF0 (для функционального моделирования бизнес-процессов).

Диаграмма потоков данных DFD (Data Flow Diagrams) – это методология (стандарт) описания бизнес-процессов верхнего уровня или макропроцессов. На диаграммах потоков данных показываются работы, которые входят в состав описываемого бизнес-процесса, а также показываются входы и выходы каждой из работ. Данные входы и выходы представляют из себя информационные, либо материальные потоки. При этом выходы одной работы могут являться входами для других.

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

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

Основными элементами диаграмм потоков данных являются:

Нотации данной методологии DFD:

Диаграмма потоков работ WFD (Work Flow Diagram) – представляет собой диаграмму потоков работ, которая используется для описания бизнес-процессов нижнего уровня, где возникает необходимость показывать временную последовательность выполнения работ в зависимости от получающихся результатов и событий, возникающих в ходе выполнения процесса. Здесь главным объектом описания становятся действия (работы), а не потоки данных (как в методологии DFD).

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

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

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

Нотация, разработанная в данной методологии: IDEF3 (PFDD – Process Flow Description Diagrams), т.е. диаграмма описания последовательности этапов процесса, с помощью которой моделируется последовательность действий, реализуемых в рамках бизнес-процесса.

Архитектура интегрированных информационных систем ARIS (Architecture of Integrated Information Systems) — это архитектура, концепция, методология, инструментальная среда (тиражируемый программный продукт), нотация, а также это система взглядов на деятельность организации, которая позволяет проектировать, проводить анализ, оптимизацию и внедрение бизнес-процессов.

Методология ARIS был разработана Августом-Вильгельмом Шеером в 1990х, сегодня права принадлежат немецкой компании Software AG.

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

При этом каждая из этих точек зрения разделяется ещё на три подуровня:

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

Продукты линейки ARIS Design Platform включают в себя программы различной направленности, например, для моделирования архитектуры предприятия ARIS Business Architect и ARIS IT Architect или для имитационного моделирования и анализа бизнес-процессов – ARIS Business Simulator. Кроме того, доступна бесплатная программа ARIS Express с несколько урезанной функциональностью.

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

К числу наиболее значимых и практически используемых нотаций ARIS можно отнести:

Диаграмма перехода состояний для проектирования систем реального времени STD (State Transition Diagram) – демонстрируют поведение разрабатываемой программной системы при получении управляющих воздействий (извне). Такие диаграммы позволяют осуществить декомпозицию управляющих процессов, происходящих в системе, и описать отношение между управляющими потоками.

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

STD состоит из следующих объектов:

К самым распространенным нотациям и языкам моделирования STD можно отнести:

Модель «сущность-связь» (ERM, Entity-Relationship Model или ER-модель) – модель данных, позволяющая описывать концептуальные схемы предметной области.

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

В основе ER-модели лежат понятия:

ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств ее визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена диаграмма «сущность-связь» (ERD, Entity-Relationship Diagram, ER-диаграмма).

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

Используемые нотации (графические модели):

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

Источник