Как реализуется соглашение по рисованию диаграмм

Обновлено: 04.07.2024

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

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

Функциональный блок

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

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

Верхняя сторона – управление.
Нижняя сторона – механизм.
Правая сторона – выход.
Левая сторона – вход.

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

Интерфейсная дуга

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

Имя стрелки указывает ее роль (совокупность возможных ролей обозначается – ICOM):

Управление – Control .

Выход функционального блока – Output .

Механизм – Mechanism .

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

Часто сложно определить, являются ли данные входом или управлением. Если данные в работе изменяются или перерабатываются, то это, скорее всего, вход, а если нет – управление. Если определить статус стрелки сложно, рекомендуется рисовать стрелку управления.

Выход (Output) – материал или информация, которые производятся работой. Обязательна хотя бы одна стрелка выхода, исходящая из правой грани работы.

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

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

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

Создание диаграмм в технологии IDEF0

При разработке модели деятельности организации следует использовать три типа диаграмм:

I тип диаграммы – Контекстная диаграмма (может быть только одна) – вершина древовидной структуры, которая представляет собой наиболее абстрактный уровень описания системы и ее взаимодействие с внешней средой. В ней определена контекстная функция;
IIтип диаграммы – Диаграмма декомпозиции.

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

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

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

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

III тип диаграммы – Диаграмма дерева узлов показывает иерархическую зависимость работ, но не взаимосвязи между работами (этих диаграмм может быть сколько угодно, т. к. дерево может быть построено на любую глубину и не обязательно с корня).

4.2. Технологический процесс IDEF0-моделирования:

Рис. 2.2

CASE-средство BPWin имеет простой и понятный пользовательский интерфейс для построения требуемых функциональных моделей и сценариев. Он зависит от используемой технологии. На рис. 2.2 показано окно BPWin ( Computer Associates BPWin ).

Основная панель инструментов окна Computer Associates BPwin содержит следующие кнопки:

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

Событийно-процессные нотации бизнес-моделирования: основы диаграмм BPMN, EPC и UML activity

Методы описания бизнес-процессов (IDEF, DFD, BPMN, EPC, UML)

Код курса

Ближайшая дата курса

Длительность обучения

8 ак.часов

Стоимость обучения

15 000 руб.

Шаги бизнес-процесса, их участники и артефакты

Если в процессе задействованы несколько участников, каждый из которых отвечает за отдельный шаг или выполняет его, это можно показать с помощью дорожек в UML activity и BPMN. На диаграмме EPC для этого следует соединить функцию с организационной единицей или внешним субъектом. Справедливости ради стоит отметить, что дорожки – это не единственный способ показать ответственность за выполнение задач в нотации BPMN – также можно сделать это с помощью групп, объединив несколько задач рамкой с штриховой границей. Подробнее об этом читайте в следующей статье.

Немного булевой алгебры: логические операторы и шлюзы

Поскольку диаграммы UML activity, EPC и BPMN позволяют описать логику выполнения бизнес-процесса, в отличие от просто структуры, которую лучше всего показывать в IDEF0, неудивительно что в событийно-процессных нотациях появляются логические операторы. В бизнес-логике их 3: логическое И (AND), логическое ИЛИ (OR) и исключающее ИЛИ (XOR). Первые два (AND и OR) отражают смысл конъюнкции и дизъюнкции в таблицах истинности, описывающих поведение функций над переменными в булевой алгебре. Чтобы не углубляться в дебри дискретной математики, отметим самое главное свойство логических операторов в контексте описания бизнес-процессов: они позволяют показать ветвления потока управления в зависимости от условий. Например, если условия коммерческого предложения не подошли клиенту, он может сообщить о желании их изменить ИЛИ отказаться от заключения договора. В этом случае один исход исключает другой, поэтому используется оператор XOR – исключающее ИЛИ. А если один поток не противоречит другому, например, позвонить по телефону или написать письмо, или сделать и то, и другое, подойдет оператор OR. Наконец, если запускаются/сливаются несколько потоков управления, каждый из которых должен дождаться остальных, используется AND.

Как описать бизнес-процесс в BPMN, EPC, UML activity: практический пример

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

Старт процесса начинается с момента, когда клиент оставил заявку на сайте.
На основании заявки, где указан курс, даты и другие вопросы, интересующие клиента, менеджер формирует коммерческое предложение и озвучивает его по телефону или направляет на email, или же делает и то и другое – в зависимости от пожеланий клиента и указанных в заявке контактных данных.
Узнав подробности коммерческого предложения, клиент принимает решение: будет обучаться или нет по каким-то причинам, например, не подошли условия (время или формат проведения занятий, оплата и пр.). Если клиент не решил обучаться, на этом процесс работы с ним заканчивается.
Если клиента устраивают все условия, он сообщает менеджеру о намерении заключить договор об обучении и передает данные для договора.
Менеджер формирует проект договора и отправляет его на согласование клиенту.
При отсутствии возражений клиент подписывает договор, договор считается заключенным и на этом бизнес-процесс заканчивается и запускает процесс оплаты, описанный на отдельной диаграмме.
В случае возражений к проекту договора клиент вносит в него изменения и направляет менеджеру.
Менеджер формирует новый проект договора и снова отправляет клиенту на согласование, т.е. идет возврат к шагу 5.

Диаграмма BPMN для этого примера выглядит довольно просто и понятно.

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

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

А подробно освоить все эти нотации моделирования бизнес-процессов вам помогут мои авторские курсы в Школе прикладного бизнес-анализа на базе нашего лицензированного учебного центра обучения и повышения квалификации системных и бизнес-аналитиков в Москве:

Читайте также: