Для построения моделей с помощью описанных выше методологий используются специальные методики моделирования – нотации.
Модель процесса – это визуальное представление последовательного потока и логики управления набором взаимосвязанных мероприятий или действий.
Нотация – система условных обозначений (знаков) и правил их использования для построения моделей, принятая в конкретной методологии.
В зависимости от типа модели бизнес-процесса, которую необходимо создать, используются соответствующие нотации.
Структурные модели – нотация IDEF
Модель состава представляет информацию о внутреннем содержании системы, описывает, из каких подсистем и элементов она состоит. Построение модели состава выполняется поэтапно на разных уровнях детализации системы. Сначала выделяются наиболее крупные подсистемы, потом их функциональные составляющие – элементы подсистем и т. д. Разбиение системы на части при определении состава соответствует принимаемой точке зрения и цели использования модели.
Для построения структурных моделей лучше всего подходит нотация IDEF (сокр. от англ. Integrated DEFinition) – стандартизированная система бизнес-моделирования, представленная целым семейством методик. Если вам интересно, можете отдельно почитать о семействе нотаций IDEF и месте в нем нотации IDEF0: с ней вам придется работать с вероятностью 99 %.
IDEF0 – это методология и графическая нотация для описания функций системы. Этот метод определяет некоторую единицу деятельности в качестве функции, характеризуя ее следующими атрибутами.
1. Вход (Input) – ресурсы, данные и прочие составляющие, поступающие на вход функции, которые необходимы для успешного выполнения функции и получения результата ее выполнения – выхода.
2. Управление (Control) – правила и лимиты, в которых существует процесс, или правила применения функции преобразования входов в выходы.
3. Механизм (Mechanism) – некоторый исполняющий ресурс. То, что фактически применяет к входу функцию для получения выхода.
4. Выход (Output) – результаты выполнения функции при наличии и подаче необходимых входов, с учетом накладываемых ограничений и на основе применения указанного механизма.
Основное предназначение этой методологии – формализация и описание бизнес-процессов организации как логических соотношений между работами с акцентом на соподчиненность объектов. То есть в IDEF0 рассматриваются главным образом составы функций организации и их взаимосвязь, а не временная последовательность.
Одна из важных особенностей нотации – минималистичный набор характеристик-элементов, которые используются для построения диаграмм. Он помогает наилучшим образом описать процесс или некую деятельность организации без необходимости представления прочих деталей, хотя нотация позволяет декомпозировать любой функциональный блок с помощью дочерней диаграммы более низкого уровня детализации. Можно сосредоточиться на описании функции как некоего «черного ящика»: на оценке ресурсов, необходимых для его работы, результатов, которые можно получить, а также условиях их получения. IDEF0 позволяет хорошо справиться с одной из главных задач бизнес-аналитика – отделить важные описательные характеристики какой-либо системы или процесса от деталей реализации и представить только необходимую информацию об исследуемой функции.
Другая особенность моделей IDEF0 – с помощью этой методологии можно наглядно представить систему или организацию как единое целое, рассматриваемое с определенной точки зрения или с определенной целью: один функциональный блок на диаграмме верхнего уровня – контекстной диаграмме, на которой в виде краткого описания и должны быть зафиксированы контекст и точка зрения на рассматриваемую организацию или систему. Определение и формализация цели разработки модели IDEF0 – это важные моменты, так как закрепленная цель определяет соответствующие области в исследуемой системе, на которых необходимо фокусироваться в первую очередь.
Например, если мы моделируем всю деятельность предприятия, чтобы использовать диаграмму для последующей разработки информационной системы этой организации, то такая модель будет существенно отличаться от той, которую мы разрабатывали бы для того же самого предприятия, но с целью оптимизации процессов согласования документации. Точка зрения же определяет основное направление развития модели и уровень необходимой детализации. Четкое фиксирование точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования неинтересных сфер ее деятельности.
Ну и третья особенность методологии моделирования IDEF0 – на удивление удобная возможность для того, чтобы представить иерархию процессов на любом количестве уровней детализации с помощью декомпозиции функциональных блоков. Она сочетается с сохранением сквозного появления входов, механизмов и управления на разных уровнях детализации. Такой единообразный подход к формированию представления о деятельности организации позволяет сохранять целостное восприятие ее потока преобразования входов в выходы и не забывать о главных правилах и ограничениях при рассмотрении отдельных сфер деятельности компании, которые в отрыве от общей картины деятельности организации на первый взгляд никак не подвержены этим ограничениям.
Эта методология довольно быстро получила известность и широкое применение в различных сферах, где требовалось моделирование комплексного процесса или системы. IDEF0 стала одной из наиболее часто используемых нотаций.
Как и положено графической нотации, IDEF0 имеет свой простой, но очень емкий набор символов, которые используются для построения диаграмм. Собственно, эта методология моделирования тем и хороша, что наиболее доступна для изображения процессов, поскольку имеет минимальный набор элементов.
Функциональный блок (функция или процесс) – это составная или простая функция, которая обозначается прямоугольным блоком. Внутри каждого блока помещается его наименование, которое должно емко отражать суть выполняемой функции. Название должно быть выражено активным глаголом, глагольным оборотом или отглагольным существительным. Также блоку может быть присвоен номер для упрощения идентификации на диаграмме и в описательных документах.
Стрелка (интерфейсная дуга) – стрелка, несущая стандартное значение с точки зрения связи блок-стрелка. В зависимости от стороны блока, к которой присоединена стрелка, однозначно определяется ее роль:
• стрелки, входящие в левую сторону блока, – входы;
• стрелки, входящие в блок сверху, – управления;
• стрелки, покидающие процесс справа, – выходы;
• стрелки, подключенные к нижней стороне блока, – механизмы.
Ниже приведен пример описания функции в нотации IDEF0.
Декомпозиция – разделение целого на части. Также декомпозиция – это научный метод, использующий структуру задачи и позволяющий заменить решение одной большой задачи решением серии меньших задач, пусть и взаимосвязанных, но более простых.
В рамках методологии IDEF0 декомпозиция носит ключевой характер, так как позволяет не только представить процесс на верхнем уровне, но и «прокачать» определенную или все его части до любого уровня детализации, который удовлетворял бы потребностям анализа для достижения поставленной цели моделирования.
В IDEF0 с точки зрения декомпозиции как приема есть всего два типа диаграмм: диаграмма с одним функциональным блоком – контекстная диаграмма и диаграммы декомпозиции, на которых в зависимости от детализации и разделения на сферы или подпроцессы может быть один или множество функциональных блоков. Основное отличие контекстной (также называемой А‐0) диаграммы – в создаваемой модели бизнес-процесса она представляет наиболее укрупненное ви´дение исследуемой системы, организации или процесса. Диаграммы декомпозиции являются дочерними по отношению к этой диаграмме и всегда представляют собой более детализированный разрез, в котором рассматриваются составляющие процесса.
В IDEF0 диаграммы разных уровней детализации должны идти последовательно, они словно вкладываются друг в друга, как матрешка. При этом есть рекомендации к шагу углубления: при переходе с одного уровня на другой детализация должна способствовать пониманию усложнения исследуемого объекта, а не вызывать диссонанс. В связи с этим есть рекомендации относительно количества функциональных блоков, а также входов, выходов, механизмов и управлений, упоминаемых на одной диаграмме.
1. На одной диаграмме IDEF0 не рекомендуется приводить более 5–7 функциональных блоков. Если аналитику для полного перечисления всех компонентов процесса необходимо добавить большее количество подпроцессов, рекомендуется вернуться к родительской диаграмме на уровень выше и переоценить состав функциональных блоков на ней. Возможно, стоит разработать промежуточную диаграмму между родительской и дочерней с уровнем детализации, который позволит разделить блоки моделируемой дочерней диаграммы на две или более разных диаграмм.
2. К каждому функциональному блоку рекомендуется приводить не более 2–3 входов, выходов, механизмов и управлений. В противном случае следует проверить, действительно ли все дуги соответствуют данному уровню детализации, и при необходимости создать дополнительный «слой» модели, включающий неподходящие дуги.
3. На дочерних диаграммах подпроцессы должны представлять некоторую связь, основанную на потреблении выходов одного функционального блока на вход другого. Наиболее важные и ключевые для анализа блоки распределяют в поле диаграммы ближе к левому верхнему углу, а остальные – ближе к правому нижнему углу, по убыванию значимости.
4. На дочерней диаграмме декомпозиции функции необходимо использовать стрелки входов и выходов, механизмов и управлений, которые были упомянуты на родительской диаграмме.
5. Чтобы использовать стрелки входа, управления и механизма для нескольких функциональных блоков на одной диаграмме, необходимо разветвлять их между блоками. При входе в диаграмму стрелка имеет один конец, а затем делится на столько окончаний, сколько блоков используют данную стрелку.
6. Все интерфейсные дуги (стрелки) на диаграмме должны иметь своего потребителя или производителя, то есть соединяться с функциональным блоком.
Пример контекстной диаграммы А‐0
Пример диаграммы декомпозиции процесса «Изготовление детали»
Модель процесса в IDEF0 начинается с определения контекста моделирования и цели, с которой будет использована диаграмма.
После определения контекста моделирования сначала изображается первый уровень модели бизнес-процесса – диаграмма с одним-единственным функциональным блоком, который описывает в целом текущий процесс. На этом уровне приводятся основные входные ресурсы, общими словами описываются механизмы, выполняющие процесс, контроли и регламенты процесса, а также выходные результаты, которые имеют значение при анализе и рассмотрении процесса на этом уровне.
В случае необходимости детализации создается диаграмма второго уровня, декомпозирующая основной процесс на функциональные блоки, которые в целом описывают общие направления процесса. Хорошим тоном считается приводить на диаграмме второго уровня все сферы процесса, которые могут быть декомпозированы далее на подпроцессы. Однако решение за аналитиком. Допустимо оставить и один функциональный блок, который будет ссылаться на то направление общего процесса, которое нужно описать в деталях.
Далее для сфер процесса, которые остаются в фокусе проводимого анализа, создаются отдельные диаграммы третьего уровня. Шаг декомпозиции желательно делать таким же, с которым была создана вторая диаграмма. Если она сохраняла высокоуровневое деление процесса на несколько составляющих его сфер, то не стоит пытаться на третьей диаграмме описать одну выбранную сферу в разрезе всех мелких задач, которые в ней могут выполняться.
Таким образом, нужно продолжить создавать детализацию каждого из необходимых функциональных блоков до тех пор, пока получившийся набор диаграмм не покроет всю сферу исследования в достаточной степени, чтобы достичь цели построения модели.
Создавая модель бизнес-процесса, всегда руководствуйтесь не только правилами используемой графической нотации, но и примерами, лучшими практиками, советами профессионалов и, конечно же, собственной логикой, пониманием потребностей людей, которые будут читать диаграммы, и даже чувством стиля.
Кроме основного набора элементов моделирования и его правил, следует также знать дополнительные элементы, которые можно встретить на диаграммах в IDEF0.
Туннелированная стрелка – стрелка-вход, означающая, что передаваемые с ее помощью данные не рассматриваются на родительской и/или дочерней диаграмме. То есть ресурс, поставляемый ей на вход функции, либо не критичен, либо важен для описания только на выбранном уровне рассмотрения процесса.
Стрелка, помещенная в туннель там, где она присоединяется к блоку, означает, что вы4 раженные ею данные не обязательны для следующего уровня декомпозиции.
Стрелка, помещаемая в туннель на свободном конце, означает, что выраженные ею данные отсутствуют на родитель2 ской диаграмме.
Внешняя ссылка обозначает место, сущность или субъект, которые находятся за границами моделируемой системы. Внешние ссылки используются для обозначения источника или приемника стрелки вне модели. На диаграммах внешняя ссылка изображается в виде квадрата, рядом с которым показано наименование внешней ссылки.
Междиаграммная ссылка – элемент, обозначающий другую диаграмму. При использовании иерархических моделей междиаграммная ссылка 5 служит для обозначения перехода стрелки на диаграмму другого процесса без отображения стрелки на вышележащей диаграмме.
Процесс-ссылка ведет на типовую модель процесса, наиболее часто повторяющиеся действия в рамках бизнес-дея1 тельности.
Сноска или комментарий – выносной элемент, предназначенный для подписи комментариев в формате свободного текста с четким отношением к какому-либо элементу диаграммы.
Текст или описание – свободный текстовый комментарий к одному из элементов или диаграмме в целом без сноски.
Используя дополнительные элементы на диаграмме, не переусердствуйте. Минимализм нотации IDEF0 сделал ее популярной, а прозрачность и читаемость модели, которую создадите вы как бизнес-аналитик, сделает успешным вас.
Главные достоинства нотации IDEF0.
1. Возможность наглядно отразить функциональную структуру исследуемого объекта: действия, которые производятся, и связи между ними. Для анализа организации как системы становится легко проследить логику и взаимодействие ее процессов.
2. Возможность получить достаточную информацию о каждой функции благодаря жестко регламентированной структуре их описания.
3. Благодаря четко определяемым для каждого процесса входам, выходам, механизмам и управлениям можно выявить все недостатки, касающиеся самого процесса и того, с помощью чего он реализуется: дублирование функций, отсутствие или перегруженность механизмов, недостаток правил, регламентирующих процесс, производство бесполезных выходов, не использующихся в других функциях, и т. д.
Слабые стороны нотации как инструмента для описания процесса.
1. Невозможно четко выявить все работы, выполняющиеся каким-либо механизмом или руководствующиеся определенными правилами и контролями, в случае если описана только отдельная область процесса или процесс описан на неглубоком уровне детализации.
2. Необходимо создать как минимум две диаграммы для представления хотя бы одного бизнес-процесса на достаточно детальном уровне по правилам методологии, обязательно нужны вложенность и иерархия уровней детализации, которые могут затруднять использование моделей.
3. Невозможно описать процесс как четкую последовательность действий и расширить модель достаточным количеством деталей, добавить контрольные точки процесса и т. д.
Модели потоков работ – нотация eEPC
Нотация eEPC – «расширенная цепочка процесса, управляемого событиями» – это одна из частей общей методологии ARIS, подход, используемый для представления организации с позиции состава ее бизнес-процессов.
eEPC (extended Event-driven Process Chain – «расширенная событийная процессная цепочка») – нотация, основывающаяся на использовании событий в качестве состояний процесса и функций в качестве шагов процесса. Процессно-событийная модель в нотации еЕРС предназначена для описания процессов, выполняемых в рамках одного подразделения, несколькими подразделениями или конкретными сотрудниками. Она описывает некий бизнес-процесс низкого уровня в формате workflow (последовательность задач).
Расширенная событийная процессная цепочка позволяет выявлять взаимосвязи между организационной, функциональной моделями и моделью потоков данных организации, если они создаются для описания организации во всех ее аспектах. Главная же задача диаграммы в нотации eEPC – детализированное описание бизнес-процесса и всех его состояний и шагов выполнения, а также возможных вариантов его выполнения.
Нотация eEPC создавалась с целью получить возможность описывать процессы таким образом, чтобы выполняемые внутри них функции имели глобальную семантику в рамках исследуемой диаграммы. Это означает, что выполнение функции на диаграммах eEPC не обязательно должно быть четко прописанным. Оно может быть зависимым от состояния других узлов диаграммы, порой очень далеко отстоящих друг от друга. Таким образом, предназначение нотации – отображать процесс со всеми вариациями его исполнения для реализации имитационного анализа процесса после создания модели. Также нотация предоставляет более широкие возможности для оптимизации и реинжиниринга процессов.
Нотация ARIS eEPC содержит большое количество графических элементов. Базовыми являются лишь некоторые из них, остальные вносят в основную цепочку процесса дополнительную информацию. Поэтому часто в рамках проекта или команды создается так называемый методический фильтр – проще говоря, это фиксированный набор, ограничивающий множество элементов, которыми аналитики будут пользоваться при создании схем процессов. В некоторых моделерах нотация eEPC изначально содержит лишь минимально необходимый набор элементов, но сама платформа ARIS предлагает великое множество допустимых объектов для создания модели бизнес-процесса.
Функция – элемент, который служит для описания функции или набора действий (процедур, работ), выполняемых подразделениями или сотрудниками организации над исходным объектом и ведущих к получению промежуточного или финального результата или события. Внутри этого элемента помещается наименование функции в начальной форме глагола. Временная последовательность выполнения действий-функций задается их расположением на диаграмме процесса: процесс «записывается» от начала к его окончанию сверху вниз.
Событие – состояние, которое является существенным и оказывает влияние на дальнейший ход бизнес-процесса или контролирует его. На диаграмме этот элемент отображает события, активизирующие функции или порождаемые функциями. Название события помещается внутри самого блока.
Стрелка отображает связи элементов диаграммы процесса. Связь может быть направленной или ненаправленной, в зависимости от соединяемых элементов и типа связи. Ненаправленная связь обозначается не стрелкой с треугольником-направлением, а просто соединительной дугой.
Многие программные средства для моделирования в нотации eEPC предлагают различные форматы и уточнения-комментарии для стрелки, в зависимости от объектов диаграммы, которые она связывает, их отношения друг к другу и особенностей этих отношений. На рисунке ниже приведены примеры различных отношений между объектами диаграммы в зависимости от их значения. Аналитик может использовать предложенное форматирование и подписи к стрелкам модели либо применить наиболее удобные в рамках локального набора используемых элементов.
Оператор «И» используется на диаграмме для обозначения слияния или ветвления функций и событий. Например, если завершение выполнения какой-то функции должно инициировать одновременно несколько событий, то это обозначается с поAND мощью оператора «И», следующего после функции и перед событиями.
Оператор «ИЛИ» – элемент, который используется для обозначения слияния или ветвления функций и только для слияния у событий. Например, если завершение выполнения функции может инициировать одно или сразу несколько событий, то это обозначается с помощью оператора «ИЛИ», следующего после функции и перед событиями.
Оператор «Исключающее ИЛИ» используетcя аналогично оператору «ИЛИ»: для обозначения слияния или ветвления функций и только для слияния событий, однако при помощи этого оператора указывается, что при выполнении процесса может быть использована только одна ветвь. Например, если завершение выполнения функции может инициировать только одно из событий в зависимости от условия, это обозначается с помощью оператора «Исключающее ИЛИ».
Нотация eEPC имеет приставку e – extended именно благодаря тому, что помимо основных элементов нотации, составляющих ее базу, аналитику предоставляется возможность использовать множество других элементов, которые могут пояснять и детализировать функции и события, описывающие основные шаги процесса. Часто набор элементов ограничен самим ПО, которое используется для изображения процесса, как, например, моделер ARIS Express. Но при использовании инструментов, не осуществляющих автоматизированных проверок на разрабатываемую модель и дающих возможность использовать любые элементы, аналитик сам может выбрать необходимое. Ниже представлены лишь некоторые элементы, которые чаще всего используются при описании процессов в eEPC, и их обозначения для модели БП.
Интерфейс – элемент, обозначающий внешний (по отношению к текущей диаграмме) бизнес-процесс или функцию. Наименование внешнего процесса записывается внутри самого элемента.
Субъект (организационная единица) используется для отображения на диаграмме организационных единиц, являющихся исполнителями, владельцами или участниками функции, с которой связывается субъект: должностей, подразделений, ролей или позиций, внешних субъектов. Необходимо учитывать, что от типа организационной единицы, упоминающейся на диаграмме, зависит форма элемента – прямоугольник или овал. Характерный для субъектов цвет элемента – желтый.
Документ используется для отображения на диаграмме документов, сопровождающих выполнение функции. В зависимости от типа документа (бумажный или электронный) форма элемента диаграммы будет различаться. При этом важно учитывать, что все документы и информационные блоки в нотации eEPC обычно отмечаются элементами серого цвета.
Информационная система используется для отображения на диаграмме некоторой информационной системы, ее модуля или даже отдельной функции, поддерживающей выполнение функции, с которой ее связывают в модели. В зависимости от этого рекомендуется выбирать элементы с разным количеством продольных линий внутри блока или уточнять это в названии элемента. Обычно в нотации eEPC такие элементы имеют оранжевую или коричневую заливку.
База данных используется для отображения на диаграмме какой-либо конкретной базы данных, сопровождающей выполнение функции, с которой ее связывают в модели. Как и другие элементы, содержащие какую-либо информацию, БД отмечается на диаграмме eEPC элементом серого цвета.
Методология ARIS позиционирует себя как конструктор, из которого команда может выбрать набор элементов, наиболее понятный и уместный для конкретного проекта в зависимости от его целей и задач. Формируя модель процесса в eEPC, вы сами можете разработать определенную локальную методологию на базе объектов нотации, которая будет соответствовать подходу и требованиям к результату анализа.
Нотация eEPC более сложная и требует от аналитика знания правил корректного построения модели. Однако, как уже было сказано выше, при использовании расширенного набора элементов она предоставляет прекрасные возможности для подробного изображения бизнес-процесса и уточнения важных деталей его выполнения на каждом шаге.
В основе eEPC-процесса лежит описание последовательности функций (действий), которые пользователи выполняют в системе. При этом каждой функции должно предшествовать событие, которое можно интерпретировать как некое «происшествие», например звонок клиента или получение письма, событие, происходящее по расписанию, или результат выполнения другого действия в процессной цепочке. Однако наиболее точно событие в нотации eEPC можно определить как состояние процесса, при котором должно быть выполнено действие. То есть событие или комбинация событий – это необходимое и достаточное условие выполнения некоторого действия: если это событие еще не наступило, то функция не может быть выполнена, а при наступлении события или комбинации событий для выполнения функции ничего другого не требуется.
Именно поэтому основа моделирования в нотации eEPC при описании шагов бизнес-процесса – соблюдение последовательности «событие – функция». Каждая функция должна также завершаться событием, которое указывает новое состояние системы после выполнения функции, то есть фактически оно указывает результат выполнения функции.
➤ Оператор «И»
Оператор «И» обозначает слияние или ветвление функций и событий в процессе. Поэтому по правилам он используется:
• после функции и перед событиями, если завершение выполнения функции должно инициировать одновременно несколько событий;
• после функций и перед одиночным событием, если событие происходит только после обязательного завершения выполнения нескольких функций;
• после событий и перед функцией, если функция может начать выполняться только после того, как произойдут несколько событий;
• после события и перед функциями, если одно событие может инициировать одновременное выполнение нескольких функций.
Таким образом, корректным будет использование оператора «И» в следующих случаях:
➤ Оператор «ИЛИ»
Оператор «ИЛИ» используется для обозначения слияния или ветвления функций и только для слияния событий. Соответственно, по правилам он будет использоваться:
• после функции и перед событиями, если завершение выполнения функции может инициировать одно или несколько событий;
• после функций и перед одиночным событием, если событие происходит после завершения выполнения одной или нескольких функций;
• после событий и перед функцией, если функция может начать выполняться после того, как произойдет одно или несколько событий.
Оператор «ИЛИ» не может следовать после одиночного события.
Таким образом, корректно будет использовать оператор «ИЛИ» в следующих случаях:
➤ Оператор «Исключающее ИЛИ»
Оператор «Исключающее ИЛИ», как и оператор «ИЛИ», используется для обозначения слияния и ветвления функций и только для слияния событий. Он позволяет учесть, что при ветвлении функций в рамках одного выполнения всего процесса может быть задействована лишь одна из предлагаемых ветвей. Соответственно, по правилам он будет использоваться:
• за функцией и перед событиями, если завершение выполнения функции может инициировать только одно из событий в зависимости от какого-то условия;
• после функций и перед одиночным событием, если событие происходит сразу после завершения выполнения либо одной функции, либо другой;
• после нескольких событий и перед функцией, если функция может начать выполняться сразу после того, как произойдет либо одно событие, либо другое.
Таким образом, корректно будет использовать оператор «исключающее ИЛИ» в подобных случаях:
Оператор «Исключающее ИЛИ» не может следовать после одиночного события
➤ Исполнители
Для обозначения исполнителя – департамента, команды или конкретной позиции в организации – необходимо использовать элементы типа «Субъект», соблюдая следующие правила.
1. Элементы субъектов должны соотноситься с помощью ненаправленного отношения (дуги) с конкретной функцией, которую они выполняют. Если используемая программа для моделирования позволяет выбрать определенный тип связи, необходимо выбрать связь типа «Выполняет».
2. Если аналитик считает важным изобразить на диаграмме всех исполнителей каждой функции бизнес-процесса, то каждой функции с помощью такого отношения назначается субъект, который ее выполняет.
3. Если у нескольких функций одного бизнес-процесса один и тот же исполнитель, то на диаграмме процесса он отображается отдельно в качестве субъекта для каждой из выполняемых им функций.
4. Принято изображать элементы субъектов-исполнителей справа от процессной цепочки, то есть выполняемых функций.
5. Любые другие отношения или взаимодействия между субъектами на диаграмме бизнес-процесса в нотации eEPC изображаться не должны (обмен документами или данными, подчинение и т. д.).
6. В случае моделирования всей организации, включая организационную структуру, в модели бизнес-процесса должны использоваться только такие субъекты, которые упоминаются в организационной структуре описываемого предприятия. Такой подход позволяет соотнести две разные диаграммы и связать организационный аспект с функциональным.
➤ Данные и документы
В зависимости от задач моделирования на диаграмме процесса могут быть приведены данные, документы, информация и другие элементы, которые используются функцией в качестве входного ресурса и являются результирующими артефактами ее выполнения. Правила их использования следующие.
1. Если нужно добавить данные, которые перемещаются между функциями, то рекомендуется последовательно отобразить на диаграмме:
a. Данные, которые нужны для каждой функции, чтобы ее выполнить. В этом случае элемент будет соединен с функцией стрелкой, имеющей направление от элемента данных к функции, а сам он должен по возможности располагаться слева или выше самой функции.
b. Данные, которые создаются функцией. В этом случае элемент будет соединен с функцией стрелкой, имеющей направление от функции к элементу данных. При этом сам элемент должен располагаться также слева или ниже функции и будет использоваться в качестве входного элемента для последующей функции процесса.
2. Так как документы или данные всегда используются в функции, либо ею создаются или дополняются, документ или информация всегда будут связаны с функцией стрелкой, имеющей конкретное направление.
3. Если на вход функции поступает документ, который уже был обработан и лишь дополняется новой информацией, то разницу или добавленную ценность к нему необходимо отразить в названии результирующего документа.
4. В зависимости от типа носителя информации следует выбирать элемент, позволяющий однозначно определить, что бумажный/электронный документ или информация хранится на конкретном носителе.
5. При описании документооборота поток документов отображается на диаграмме отдельно от потоков работ. Именно этот подход позволяет целостно описать в одной схеме как причинно-следственные связи, так и сам документооборот.
➤ Другие дополнительные элементы
Помимо документов распространены следующие дополнительные элементы диаграмм eEPC.
1. Информационные системы, их модули и функции обычно изображаются слева от потока работ и соединяются с функцией, которую реализуют, дугой без направления.
2. Базы данных изображаются слева или справа от функции, выполнение которой сопровождают. Так как использование данных БД в рамках выполнения одной функции обычно бывает двунаправленным (чтение из БД и запись в нее), отношение БД к функции также описывается ненаправленной дугой, соединяющей элемент и функцию.
3. Прочее может изображаться как слева, так и справа от функции, в зависимости от значения самого элемента в рамках изображаемого бизнес-процесса.
Особым образом следует использовать элемент «Интерфейс» для указания взаимосвязи процессов. Так как интерфейс отображает на текущей диаграмме другой процесс, отличный от рассматриваемого, по правилам нотации его можно использовать так:
• в качестве обозначения предыдущего или следующего процесса по отношению к рассматриваемому на диаграмме, то есть для указания горизонтальной связи между текущим процессом и другими;
• в качестве обозначения процесса, откуда поступил или куда передается некоторый объект, имеющий значение в текущем процессе.
Нотация eEPC достаточно требовательна к построению модели. Однако, освоив ее основные принципы и правила, любой аналитик оценит преимущества детализации и последовательного описания процесса, а также возможность читать его сверху вниз, словно описательный текст.
Пример части диаграммы бизнес-процесса в нотации eEPC на стр. 123.
Как мы уже упоминали, главный способ связи изображаемых бизнес-процессов в нотации eEPC – использование элемента интерфейса процесса. На диаграмме одного бизнес-процесса элемент интерфейса отображает образ другого бизнес-процесса, который может генерировать ресурсы для использования в первом, предшествовать ему или следовать после него. Создание подобной связи позволяет дробить процессы, соблюдая при этом необходимую наглядность моделей процессов, на которых необходимо упоминание других важных для анализа событийных цепочек. И наоборот: если аналитик концентрируется на моделировании только одного-двух самых важных для анализа процессов, все другие соотносящиеся с ними он может представить на диаграмме с помощью элемента, не разрабатывая и не прилагая моделей этих процессов.
Однако помимо непосредственной связи бизнес-процессов как процессных цепочек (в горизонтальном отношении), которые представляют собой более масштабный полноценный путь преобразования каких-либо входных данных или ресурсов в конечный продукт, существует связь бизнес-процессов в части их объединения по основным функциям, выполняемым организацией (в вертикальном отношении).
Для наилучшего структурного описания всех функций организации и полноценного представления ее функционала в методологии ARIS предусмотрена последовательная декомпозиция функций организации: начиная с их представления на верхнем уровне, где приводится классификация бизнес-процессов и их объединение в группы, с переходом через дерево функций к разбивке этих групп на уровне перечней бизнес-процессов как таковых, и заканчивая уже детальным описанием каждого бизнес-процесса с помощью нотации eEPC. Таким образом, методология предусматривает полноценное описание организации в аспекте осуществляемой ею деятельности аналогично IDEF0. Однако воспроизводится подобное описание не с помощью одной-единственной нотации и одного типа диаграмм, а с помощью трех типов диаграмм.
Пример диаграммы процессов верхнего уровня.
Пример части диаграммы бизнес-процесса в нотации eEPC
Пример диаграммы функционального дерева – иерархической структуры процессов одного типа на стр. 125.
Как уже упоминалось, нотация eEPC достаточно сложна для использования при моделировании и дальнейшего анализа бизнес-процессов. Такой эффект возникает из-за нескольких факторов.
1. Использование большого количества дополнительных описательных элементов.
2. Отсутствие комментариев или описания диаграммы с легендой.
3. Множество возникающих при выполнении процесса ветвлений.
4. Необходимость формального использования логических операторов для следования правилам нотации.
В результате появляется формально правильная, но громоздкая, трудно воспринимаемая схема, зачастую полностью лишенная смысла, которая не может решить задач моделирования – создания прозрачного и доступного для анализа описания бизнес-процесса. Такая проблема типична почти для всех нотаций типа Workflow, поэтому существует ряд рекомендаций для специалистов, которым нужно создать описание бизнес-процессов организации в нотации eEPC.
1. В зависимости от задач моделирования необходимо определить набор элементов, который вы будете использовать для диаграмм. Он должен содержать минимум элементов, но при этом достаточно полно отображать все необходимые особенности бизнес-процесса.
2. При создании полноценного описательного портфолио бизнес-процессов организации следует формировать пояснительные документы или хотя бы краткие перечни созданных диаграмм с историей их изменений, а также с описанием «легенды» – набора элементов, используемых для моделирования.
Пример диаграммы функционального дерева
3. В зависимости от задач моделирования следует создавать детализированное описание только тех бизнес-процессов организации, которые потребуется анализировать в дальнейшем.
4. Если вам необходимо отобразить общую картину деятельности организации, то следует прибегнуть к созданию диаграмм процессов верхнего уровня и функционального дерева для тех функций, для которых важно отразить состав бизнес-процессов.
5. При моделировании сложного процесса с большим количеством ветвей нужно стараться распределять ветви на диаграмме таким образом, чтобы избежать пересечений и слишком близкого расположения каких-либо элементов, в особенности операторов.
6. Для одного типа дополнительных элементов следует использовать один рекомендованный цвет.
Один и тот же дополнительный или основной элемент, повторяющийся на диаграмме, должен иметь одно и то же название, поскольку различие в наименовании элементов на диаграмме всегда интерпретируется как различие в самой их сути.
Сравним две нотации моделирования бизнес-процессов организации – IDEF0 и eEPC, чтобы понять, что их объединяет, в чем их различия и для какой задачи анализа какая модель будет более наглядной.
Один из важнейших аспектов описания моделей бизнес-процессов – отражение на модели управляющих воздействий и обратных связей по контролю над процедурой и управлению ею. В нотации ARIS eEPC управление процессом может быть отражено только при помощи указания входящих документов, которые регламентируют выполнение процедуры. При этом документы – вторичный элемент диаграммы и последовательности выполнения функций БП во времени. Функцией в таком случае будет управлять предшествующее бизнес-процессу событие или их совокупность.
В отличие от eEPC, в нотации IDEF0 каждая процедура должна иметь хотя бы одно управляющее воздействие (вход управления – стрелка сверху). Так, если при создании модели процесса в eEPC указывать только последовательность выполнения его процедур без описания событий, документов и информации, то с высокой вероятностью полученная модель будет крайне поверхностной и непригодной для достаточного анализа.
Таким образом, в отличие от IDEF0, синтаксис которой обязывает наполнить модель наиболее важными деталями, eEPC при своей достаточной сложности предоставляет аналитику возможность самостоятельно решить, насколько детализированной будет модель. В свою очередь, это часто ведет к ошибке, которая заключается в чрезмерном упрощении процесса.
В то же время на моделях в IDEF0 не предусмотрено использование символов, представляющих логику выполнения процесса: операторов «И», «ИЛИ», «Исключающее ИЛИ». Это существенно ограничивает возможность наполнить картину процесса четким ветвлением, которое позволяет отразить влияние различных условий на выполнение процесса. Процесс в IDEF0 выглядит очень плоско и зачастую трудно читается, если аналитик постарался отразить все связи и множественные контроли и механизмы, используемые разными функциями.
Еще одна слабая сторона IDEF0 по сравнению с eEPC – неочевидность последовательности выполнения функций. Их расположение на диаграммах, а также ограничение по количеству функциональных блоков на одной диаграмме заставляет аналитиков создавать множество диаграмм, изощряться с аллокацией блоков, что делает общую картину процесса менее наглядной. Легко читать процесс сверху вниз, как это доступно при моделировании в eEPC, не получится. Соответственно, и наглядно воспроизвести имитационное моделирование с помощью IDEF0-моделей будет невозможно.
С точки зрения методологического подхода к полноценному многоуровневому описанию процессов организации, IDEF0 и ARIS примерно одинаковы по своей эффективности и наглядности. Однако необходимо учитывать, что создание всех уровней (от верхнего до наиболее детализированного) в методологии ARIS потребует знания как минимум трех нотаций (подходов к созданию диаграмм), в зависимости от уровня их детализации, и eEPC будет использоваться только на этапе максимальной детализации описываемых процессов. При этом IDEF0 в описании всех уровней детализации использует одну и ту же нотацию. Единый подход помогает снизить количество ошибок и упростить чтение диаграмм процессов.
Варианты для выбора нотаций IDEF или eEPC.
1. Если перед аналитиком стоит задача максимально детально проработать сложные и длинные процессы, то подойдет eEPC.
2. Если необходимо описать общую структуру процессов организации, сделать диаграммы наиболее прозрачными и изобразить на них только основные этапы процессов так, чтобы было понятно даже топ-менеджменту, то выбор будет в пользу IDEF0.
3. Если требуется описать лишь несколько несвязанных процессов, но сразу детально, то сделать это поможет eEPC.
4. Если нужно создать у читателя общее представление об организации как о системе, несущей определенную основную функцию, и при этом достаточно детально описать все функциональные направления деятельности компании, для этого может лучше подойти IDEF0.
5. Если моделирующий аналитик не имеет опыта моделирования и может запутаться в логике процесса из-за его сложности и отсутствия глубокого понимания сферы деятельности описываемой организации, лучше воспользоваться IDEF0.
6. Если аналитик опытен, внимателен к мелочам, усидчив и готов приложить усилия для того, чтобы изобразить каждую составляющую компоненту процесса, то подходящим выбором будет eEPC.
После первых практических применений нотации eEPC аналитик с опытом моделирования бизнес-процессов в какой-либо другой нотации легко может выделить сильные и слабые стороны обеих нотаций.
Преимущества нотации eEPC.
1. Относится к классу нотаций Workflow (поток работ), поэтому проста и удобна для изображения длинного, многошагового процесса от начала до конца, а также последующего анализа для выявления слабых мест.
2. Позволяет добавлять собственные авторские элементы и определять закрепленный набор используемых элементов. В этой нотации отсутствует не только жесткий набор элементов моделирования, но и правила использования большинства из них.
3. Предлагает использование логических операторов, применение которых дает эффективно и прозрачно изобразить все вариации исполнения процесса.
4. Направлена на детальное и точное описание бизнес-процесса, отражение на диаграмме в графическом виде всех исполнителей, ресурсов, объектов. Набор элементов и правила их использования позволяют расширить модель бизнес-процесса от минималистичного вида до полной картины событий.
У eEPC есть и ряд недостатков, которые аналитику нужно учитывать при выборе нотации для моделирования процесса и в целом при выборе методологии ARIS для описания организации.
1. Необходимость предварительной подготовки команды аналитиков к чтению и построению моделей бизнес-процесса. Возможность вводить авторские элементы и использовать достаточно широкую библиотеку дополнительных детализирующих элементов приводит к необходимости предварительной договоренности внутри команды по поводу набора дополнительных элементов для моделирования, подготовки описания, обучения и т. д.
2. Понимание необходимой детализации у аналитика и заказчика проекта может не совпадать. Это усложняет представление разработанной модели и ее согласование с участниками, не знакомыми с правилами и компонентами этой нотации.
3. Существенное ограничение диаграмм, созданных в нотации eEPC ARIS, состоит в невозможности указать длительность процесса. Эта модель позволяет отобразить только логическую последовательность действий, поэтому по диаграмме eEPC нельзя выявить, что сотрудник должен одновременно выполнять несколько задач либо не может выполнить весь предписанный ему объем работ за заданный интервал времени, например за один рабочий день. Если необходимо указать длительность процесса, то как вариант можно использовать диаграмму Ганта.
4. Простая модель типа Workflow может не отражать многих управляющих воздействий, что зачастую приводит к потере реальных процессов контроля рассматриваемого бизнес-процесса или к их неполному описанию. При последующем анализе процесса может оказаться, что какие-то точки контроля забыли учесть в модели, и это изменило процесс в ущерб его сути и логике.
Поскольку нотация eEPC имеет ряд правил, но допускает некоторые вариации ее использования, то оба этих фактора увеличивают возможность возникновения синтаксических и смысловых ошибок при построении модели бизнес-процесса. Специалисты подчеркивают, что аналитикам необходимо в обязательном порядке ознакомиться со всеми правилами нотации, прежде чем начинать работать в ней. Риск допустить критические ошибки моделирования особенно высок для тех, кто ранее не имел практики работы или давно не использовал свои знания по моделированию в eEPC.
При подготовке к моделированию бизнес-процесса и проверке модели после ее создания необходимо помнить, что ошибки в модели приводят к непониманию реальной ситуации в организации и неспособности корректно определить возможности как процесса AS-IS, так и TO-BE.
Рассмотрим самые распространенные ошибки при работе в этой нотации.
Некорректное изображение самой цепочки работ.
1. Использование двух функций друг за другом. Основное правило синтаксиса при моделировании в eEPC требует, чтобы каждое действие заканчивалось каким-то состоянием системы (организации) и каждое состояние было обусловлено определенным действием.
2. Перечисление в одной функции нескольких действий, которые на самом деле выполняются по отдельности, но на одном этапе работ, без уточнения последовательности их выполнения. В этом случае аналитик может выстроить функции в любом порядке или самостоятельно определить порядок, если владелец процесса подтвердит, что активности выполняются в любой последовательности. Однако каждая их них принципиально должна быть изображена как отдельная функция со своим результирующим состоянием. Именно это гарантирует, что в ходе анализа БП можно будет легко выявить повторяющиеся активности, отсутствующие зависимости, ненужные шаги и потерянные документы.
Некорректное использование операторов.
1. Использование операторов «ИЛИ» и «Исключающее ИЛИ» после события. Обе ситуации запрещены, так как событие само по себе не принимает решение, какое действие выполняется. В таком случае нужно использовать оператор «И» либо добавлять два состояния на диаграмме.
2. Пропуск логических операторов в том случае, когда событие имеет две исходящие связи, или функция – две входящие связи. Это, пожалуй, самая распространенная ошибка, возникающая в ряде нотаций моделирования бизнес-процессов, где используются операторы. Для любых входящих или исходящих связей в случаях, когда их больше одной, обязательно использование одного из операторов: «И» (единственно допустимое, когда событие имеет две исходящие связи на функции), «ИЛИ», «Исключающее ИЛИ». К этой же ошибке относится и нарушение отображения обратной связи, когда из какого-либо шага n+k необходимо вернуться на шаг n, образуя цикл. В таких случаях перед функцией n для слияния связей допустимо использование только оператора «Исключающее ИЛИ».
Некорректное использование дополнительных элементов.
1. Отсутствие изображения потоков документов в схеме или только частичное их изображение, что ведет к потере управляющих контролей процесса. Еще одна плохая ситуация – такой подход к изображению передаваемой документации, когда документооборот не отделен от потока работ и подписывается на переходах между функцией и событием, вместо того чтобы быть выделенным отдельными, переходящими от функции к функции элементами с явными отношениями.
2. Смешение понятий результирующего состояния (события) и исходящего документа. У каждой функции всегда будет событие на выходе, обозначающее состояние самого процесса. Если в результате выполнения функции был подготовлен еще и документ или какая-то другая информация, это должно быть отражено отдельно от самого потока процесса.
Иногда идет отображение всех условий и ограничений, входящих и исходящих документов и информации, всех систем и модулей, в которых выполняется та или иная функция, представление на одной диаграмме процессов слишком длинной цепочки (неиспользованная потенциальная возможность декомпозиции процесса при создании дерева процессов). В таких случаях модель становится слишком сложной, громоздкой или очень длинной. Ее трудно читать, поэтому аналитики лишаются возможности эффективно работать с моделью.
Модели исполняемых процессов – нотация BPMN
Методология BPM и нотация BPMN основаны на понятии бизнес-процесса и процессном подходе.
Управление процессом в методологии BPM – это управление целым (организацией) через управление его частями (процессами).
Чтобы исключить путаницу в терминологии, необходимо пояснить следующее.
Методология BPM (Business Process Management) – концепция процессного управления организацией при помощи управления бизнес-процессами.
Нотация BPMN (Business Process Model and Notation) – нотация (система условных обозначений) для построения моделей процессов на основе методологии BPM, а также исполняемых с помощью систем BPMS.
Система BPMS (Business Process Management System) – IT-система для моделирования в методологии BPM, а также автоматизации исполняемых экземпляров процессов на основе построенных BPMN-моделей.
Если проводить аналогию с наукой,
BPM – это прежде всего подход, своего рода мировоззрение.
BPMN – методы и алгоритмы решения конкретных задач. Например, набор методов для создания проекта обеспечения электричеством производства или многоквартирного дома.
А BPMS – это уже готовые прикладные решения, которые можно «включить», и они заработают. Для математики это готовые решения задач, имеющих практическое значение. Для физики – непосредственная реализация электропроводки и подключение объектов. Для сферы IT – готовый программный код.
BPMS-системы реализуют следующие возможности:
• создание, изменение, воспроизведение моделей процессов организации;
• быстрое и легкое управление последовательностью действий внутри процесса и их оптимизация;
• управления взаимодействиями между разными этапами и операциями;
• полноценный реинжиниринг процессов в организации при необходимости коренных изменений;
• сбор статистики по выполнению процессов для последующего анализа;
• выявление отклонений и задержек при исполнении процессов;
• анализ текущей деятельности организации в соответствии с поставленными для нее KPI.
Еще один важный факт, который поможет понять, что же такое на самом деле управление бизнес-процессом.
Управление – это создание такой последовательности действий в процессе, при которой каждый сотрудник выполняет заданные по инструкции задачи, а автоматизированная система работает определенным образом.
Существует два подхода к управлению организацией.
При этом необходимо знать:
• для стратегического планирования и оценки работы компании в целом лучше использовать функциональное моделирование и соответствующие нотации, например IDEF0. Здесь мы исходим из желаемого результата и выстраиваем последовательность функций каждого «черного ящика», необходимую для достижения результата;
• для управления последовательностью действий и оптимизации того, что происходит внутри каждого «черного ящика», а также улучшения взаимодействия между ними необходим процессный подход BPM. В данном случае мы изучаем сами действия, отслеживаем скорость и трудоемкость достижения результатов, оптимизируем и стандартизируем действия.
При внесении изменений в бизнес-процесс, мы всегда отталкиваемся не от целого, а от части. То есть мы меняем алгоритм работы программы и/или корректируем должностную инструкцию сотрудника, выполняющего определенные функции. В результате меняется один из элементов бизнес-процесса и, как следствие, бизнес-процесс в целом.
Необходимо понимать следующее.
1. Создание описания бизнес-процесса начинается «в целом», после чего каждый процесс делится на подпроцессы и детализируется до определенного предела.
2. Изменение бизнес-процесса, наоборот, начинается с нижних уровней – максимальной детализации. И по пути от частностей к целому вносятся все необходимые правки.
a. Если при функциональном подходе очень важны объекты на входе и выходе, то в самой функции, «черном ящике», важна обработка объектов для получения необходимого результата. И здесь управление бизнесом ориентировано на «Что именно мы хотим получить?», то есть подход скорее стратегический.
b. При процессном подходе мы получаем ответ на вопрос «Как это лучше выполнить?», то есть концентрируемся на тактическом, оперативном управлении. А потому здесь при изменении отдельных элементов между «входом и «выходом» меняется весь процесс.
Также важно при детализации определить оптимальный уровень: не слишком общий, но и не детализированный вплоть до действий каждого сотрудника, если речь идет о крупном процессе.
По этим причинам при работе с бизнес-процессами используется многоуровневая декомпозиция, когда детализация каждого «черного ящика» выделяется в отдельный процесс.
В нотации BPMN выделяют пять главных категорий элементов.
Основные:
• элементы потока: события, процессы и шлюзы;
• соединяющие элементы: потоки управления, потоки сообщений и ассоциации;
• данные: объекты данных и базы данных.
Дополнительные:
• зоны ответственности: пулы и дорожки;
• артефакты: сноски.
Рассмотрим существующие в BPMN виды диаграмм.
1. Процесс (Process Diagram)
2. Взаимодействие (Collaboration Diagram)
3. Хореография (Choreography Diagram)
4. Диалог (Conversation Diagram)
Первые три вида диаграмм основные, а четвертый – дополнительный: он появился лишь в BPMN2.0. На практике чаще всего используют два вида: «Процесс» и «Взаимодействие». Рассмотрим назначение всех видов диаграмм.
1. Процесс (Process Diagram) описывает содержание и логику бизнес-процесса BPMN в виде потока задач, условий и событий. Это самый распространенный вид диаграмм, он применяется чаще других и является основой нотации BPMN. Пример диаграммы «Процесс»:
2. Взаимодействие (Collaboration Diagram) позволяет моделировать взаимодействие (обмен данными) между двумя или более бизнес-процессами BPMN. Для графического отображения такого взаимодействия используются потоки сообщений (message flow). Пример диаграммы «Взаимодействие»: на стр. 154.
3. Хореография (Choreography Diagram). Иногда диаграммы «Взаимодействие» оказываются слишком сложными для восприятия и требуют более наглядного представления. В этом случае применяют диаграммы «Хореография». Они описывают последовательность взаимодействий участников при выполнении бизнес-процессов.
4. Диалог (Conversation Diagram) – еще один вариант диаграммы для визуализации взаимодействий бизнес-процессов BPMN и их участников. Диаграмма «Диалог» описывает процессный ландшафт и взаимодействия верхнего уровня между вовлеченными сторонами. Пример диаграммы «Диалог»: на с. 155.
Пример диаграммы «Взаимодействие»
Пример диаграммы «Хореография»
Пример диаграммы «Диалог»
Типы связей, которые могут быть наведены между элементами на диаграмме BPMN, перечислены в таблицах ниже.
Нередко даже в профессиональной среде путают два понятия – декомпозицию и подпроцесс. Важно понимать разницу между ними.
Декомпозиция – это разложение задачи на более простые элементы. Может использоваться как в функциональном, так и в процессном моделировании.
В этом случае для простоты понимания сути нотации вводится элемент типа «черный ящик» с названием функции или процесса. При необходимости его детализация выполняется отдельно. Декомпозировать можно по-разному, например декомпозиция функцией может быть полноценным процессом.
Пример декомпозиции сущности А:
Для понимания работы компании в целом вы используете функциональную модель в IDEF0, где вводите понятие функции «Продажа». Для изучения работы бизнеса в целом лишние подробности не нужны: они только усложнят поиск решений.
На следующем этапе, когда вы переходите от общего к частностям, вам понадобится декомпозировать функцию «Продажи». И здесь вы уже используете инструменты процессного подхода и подробно описываете последовательность действий.
В итоге в вашей модели создается уровень функций и отдельно детализация важных функций, которая и называется декомпозицией.
Подпроцесс (используется в BPMN) – это отдельный процесс внутри процесса. То есть вы создаете какой-то процесс, в котором применяете блоки без детализации. Их обычно так и называют в нотации. Например, «Подпроцесс продажи».
Подпроцесс не может выходить за рамки графической нотации, его рисуют на той же диаграмме, но внутри очерченных границ подпроцесса.
Подпроцесс А внутри процесса:
Основное различие: декомпозиция допускает больше свобод, здесь вы можете совмещать различные подходы к изучению бизнеса. А подпроцесс – неотъемлемая часть BPMN-нотации. В нем еще на уровне процесса жестко заданы все точки входа, выхода, исполнители, инструменты, и вы не можете выйти за эти рамки.
Использование подпроцессов позволяет, с одной стороны, не перегружать диаграмму на высоком уровне подробностями, что облегчает ее восприятие. С другой стороны, при работе с подпроцессами система BPMN помогает вам избежать ошибок, так как вы работаете внутри нотации, а не с отдельной диаграммой. Важно понимать, что подпроцесс используется для исполняемых процессов. Для неисполняемых процессов мы рекомендуем использовать декомпозицию, так как подпроцесс сложнее для восприятия.
В практике описания бизнес-процессов элемент нотации BPMN «Подпроцессы» используется в основном в двух случаях.
1. Для декомпозиции и повышения читаемости и наглядности схем (диаграмм).
2. Для описания повторяющихся действий. Единожды описанный подпроцесс может многократно вызываться (использоваться) внутри различных процессов.
Рассмотрим первый случай использования подпроцессов – декомпозицию процесса. Довольно часто при описании бизнес-процессов компании для наглядности используют схемы (диаграммы), отражающие верхние уровни организации работы. В этом случае диаграмма отображает суть процессов и нацелена на понимание логики процесса без знания деталей. Примером такого бизнес-процесса верхнего уровня может служить процесс «Наем персонала». На верхнем уровне этот процесс будет выглядеть так:
Такая прорисовка процесса легка для восприятия любого бизнес-пользователя, так как отображает только последовательность основных действий в рамках процесса без утяжеления какой-либо информацией. Любая схема (диаграмма) процесса – это последовательность функциональных блоков, декомпозиция которых позволяет создать процесс нижнего уровня. При этом каждый подпроцесс на более низком уровне описывается с полной детализацией элементов BPMN: активностей, условий и исполнителей.
Подпроцессы – комплексные задачи в рамках основного процесса. Однако стоит отметить, что подпроцессы как элемент BPMN – это не самостоятельные задачи, а лишь отсылки к другому процессу.
Чаще всего встречается свернутый тип подпроцессов, то есть процесс со скрытыми деталями, который позволяет облегчить визуализацию бизнес-процессов.
Свернутый подпроцесс графически изображается в виде прямоугольника с маркером «+».
Графическое изображение задачи – свернутый подпроцесс
Декомпозиция процесса (разбивка на подпроцессы) позволяет моделировать и вносить изменения в рамках каждого подпроцесса, не изменяя весь основный процесс целиком.
При детализации каждого отдельного подпроцесса описываются необходимые условия выполнения: участники, активности, бизнес-правила и т. д. Такой процесс описывается в рамках одной оркестровки, что позволяет облегчить чтение и внесение изменений в процесс.
При детализации подпроцессов приведенного примера – процесса «Наем персонала» – получим следующие процессы.
1. Поиск кандидатов на вакансию.
2. Оформление документов нового сотрудника.
3. Обучение нового сотрудника.
Рассмотрим каждый подпроцесс отдельно.
Подпроцесс «Поиск кандидатов на вакансию»
Подпроцесс «Оформление документов»
Подпроцесс «Обучение нового сотрудника»
Таким образом можно описать довольно большой бизнес-процесс компании. А теперь представьте, что все активности и исполнители процесса «Наем персонала» будут отображены в рамках одной оркестровки. Сделать это сложно, а читать процесс будет еще сложнее. Используя декомпозицию при описании сложных, но важных процессов компании, вы получаете продукт (процесс), который будет понятен любому бизнес-пользователю. Такой продукт будет легко изменять при моделировании и совершенствовании в будущем.
Для примера возьмем бизнес-процесс обеспечения заявки на потребность. Результатом будет считаться получение сотрудником заказанных товаров.
Бизнес-процесс в компании выстроен так.
1. Сотрудник на портале организации заполняет заявку на потребность, где указывает номенклатуру и необходимое ему количество товара.
2. Заявка проверяется на необходимость менеджером в системе.
3. Если потребность подтверждена, менеджер проверяет, есть ли заказанный товар на складе. При наличии товара менеджер резервирует его, а если товара на складе нет – отправляет заявку на согласование.
4. Если заявка согласована, сотрудник отдела закупок создает заказ для поставщика. В противном случае бизнес-процесс закупки завершается.
5. После получения товаров от поставщика кладовщик приходует их и выдает сотруднику со склада заказанные наименования.
Не все процессы нужно детализировать при описании с помощью нотации BPMN. Что-то можно опустить. Например, мы не рассматриваем в примере описание процесса оплаты товара, согласование цены и количества позиций в заказе поставщика. Первоначальная задача – показать процесс крупными мазками, не углубляясь в детализацию. При необходимости любой подпроцесс можно расписать детальнее.
Нотация BPMN при моделировании бизнес-процессов позволяет самому аналитику регулировать глубину детализации в описании бизнес-процесса и выносить отдельные вещи за пределы описания.
Начало процесса, точка входа – получение заявки на потребность от сотрудника на портале организации. Точка выхода – получение заказанных товаров сотрудником. В схеме мы используем как развилки, так и подпроцессы. Например, использование подпроцесса «Зарезервировать товар» после развилки «Есть на складе» позволяет отдельно детализировать последовательность действий, которые выполняет менеджер в этом процессе.
Какие преимущества дает такое описание бизнес-процесса?
1. Можно наглядно продемонстрировать бизнес-клиентам функциональную связь между подразделениями в части максимального покрытия внутренних потребностей компании.
2. На схеме видны бизнес-процесс, последовательность выполнения, источники информации, а также показано, доступом к каким процессам или документам должен обладать пользователь.
Ошибки в BPMN бывают трех видов.
1. Формальные – когда диаграмма не соответствует правилам BPMN.
2. Ошибки стиля – когда схема формально правильная, но читать или редактировать ее неудобно. Предпочтения в оформлении у всех свои, но если в вашей команде выработан определенный порядок и правила, необходимо им следовать.
3. Ошибки логики – это когда схема формально правильная, со стилем все в порядке, но есть проблемы в сути того, что изображено, или имеется несоответствие реальному положению дел. Для исправления таких ошибок важно хорошо разбираться в предметной области.
Рассмотрим наиболее распространенные ошибки при моделировании.
➤ События используются неправильно
Прежде чем использовать в своей схеме какое-либо событие, убедитесь, что вы правильно поняли его смысл и функцию. Если вы сомневаетесь в уместности какого-то события в описываемом процессе, то лучше его не использовать.
Например, события, обозначающие обмен сообщениями – то есть взаимодействия между разными процессами, – из-за символа в виде конверта могут быть приняты за задачи оповещений по e-mail.
На схеме на стр. 166 изображено большинство событий, используемых в схемах BPMN.
➤ Элементы ничем не заканчиваются
Формально в BPMN могут использоваться брошенные элементы:
Но обычно это вызывает путаницу и недопонимание, так как на схеме отсутствует завершение процесса. Непонятно, так должно быть или его забыли нарисовать.
Поэтому лучше, чтобы из задачи всегда был выход или какой-то переход из процесса в последующие блоки основного потока управления. Как правило, можно найти следующее действие исполнителя, который ответственен за процесс.
События, используемые в схемах BPMN
➤ Перепутаны типы потоков
Иногда бывает так, что в рамках одной дорожки процесса мы видим изменение типов потоков, например:
Потоки управления можно использовать только внутри пула или дорожки: они не могут выходить за границы пула.
НО: потоки сообщений можно использовать только за пределами пула или дорожки: они не могут находиться внутри одного пула или дорожки.
(Поток ассоциаций вообще используется только для улучшения читаемости и определяет поведение процесса.)
➤ Не сходится количество потоков на входе и на выходе
Мы можем исправить это, добавив эксклюзивный шлюз перед вторым параллельным:
➤ Не учитывается скорость выполнения зависимых процессов
В изображенной здесь ситуации задача 2 может выполниться быстрее, чем задача 1. В таком случае нижний процесс не сможет отправить сообщение, так как верхний еще не готов его принять.
Поэтому в подобных случаях важно обозначать обязательное условие выполнения задачи:
➤ Разный уровень задач в процессе
Это ситуация, когда на одной схеме находятся задачи абсолютно разных уровней:
➤ Использование условных потоков (conditional flow)
Достигнув определенного уровня и уверенности, специалисты часто начинают везде использовать одни и те же привычные инструменты и забывают о возможности упростить свою схему с помощью других типов задач и обозначений:
Вместо того чтобы усложнять основную диаграмму, такие схемы можно отрисовывать, создавая подпроцессы. Также можно излагать логику выполнения сложного шага в его описании, а не на самой модели:
BPMN используется для моделирования бизнес-процессов, а не инструкций для сотрудников. Здесь важно наличие задачи, а не способ выполнения:
Такие задачи лучше рисовать с помощью одного события:
То же самое касается технических процессов:
Не представляйте действие бизнеса как технологическое, пишите явно, что происходит:
➤ Одна задача для множественной обработки
В BPMN есть элементы, которые показывают итерирование по набору сущностей. Аналитики создают задачу, в названии которой пишут массовую операцию:
Это нормально, но при обработке исключительных случаев внутри обработки запроса могут возникнуть проблемы. Поэтому такую задачу лучше развернуть как подпроцесс, работающий со всем массивом:
➤ Переход в межпроцессное взаимодействие там, где это не нужно
Эта ошибка BPMN характерна для аналитиков, которые уже некоторое время изучают тему. Они знают, что межпроцессное взаимодействие можно организовать с помощью сообщений:
Такое отображение только усложняет схему и не отличается от такого:
➤ Приведение всех вариантов завершения процесса к одному завершающему событию
Во-первых, такая схема чаще всего трудно читается. Во-вторых, подобное изображение усложнит сбор статистики о самых частых вариантах окончания процесса.
Лучше изобразить схему так:
➤ Не учитывается скорость выполнения зависимых процессов («Гонка» сигналов)
Изображение взаимодействия процессов, которые могут не выполниться:
Задача 2 может выполниться быстрее, чем задача 1. В таком случае нижний процесс не сможет отправить сообщение, так как верхний еще не готов его принять.
Чтобы свести к минимуму количество ошибок при моделировании процесса, можно использовать следующий чек-лист.
1. Тип модели процесса определяемый и соответствует поставленной задаче моделирования.
Можно условно выделить три типа моделей процессов:
• аналитическая – показывает общую логику процесса. Она нужна для анализа и регламентации, зачастую содержит некоторые упрощения из расчета, что человек сможет додумать, как надо выполнять работу, с учетом своего опыта и компетенции;
• имитационная – позволяет выполнять имитационное моделирование процесса для определения времени выполнения, загрузки исполнителей, стоимости результатов выполнения процесса;
• исполняемая – может быть экспортирована для автоматизации в системе класса BPMS или запущена на выполнение прямо из среды моделирования.
2. Соответствие стандартам нотации моделирования.
Необходимо проверить соответствие схемы общепринятым нотациям моделирования. Вариантов немного: IDEF0, eECP, BPMN. По-хорошему, в компании должен быть стандарт, в котором установлены требования к графическим моделям процессов. Его часто называют соглашением по моделированию. Если стандарт есть, то в данном и последующих пунктах необходимо учесть его требования.
3. Корректность формулировок названий объектов на схеме.
Объекты схемы – это документы, информация, операции процесса, субъекты (должности, роли), логические операторы (шлюзы) и прочее. Следует обратить внимание на соответствие названий стандарту моделирования. Если в нем нет требований к названиям объектов, то стоит их внести. Пример некорректной формулировки процесса: «Разработка и утверждение плана работ в случае согласования руководителем не позднее второй недели третьего месяца квартала». Думаем, не нужно объяснять, что здесь не так.
4. Корректность описания входящих и выходящих дополнительных элементов.
Входящие и исходящие дополнительные элементы могут быть информационными и материальными.
Важно, чтобы дополнительные элементы были описаны корректно и не повисали в воздухе. Это означает, например, что для любого входящего документа должен быть указан в виде ссылки процесс – поставщик входа, и т. п.
5. Корректность описания событий.
События могут быть инициирующими (стартовыми), промежуточными и завершающими процесс. Ошибки при описании событий бывают как формальными, так и содержательными. Пример: название стартового события «Возникла потребность в сырье». Потребность не может возникнуть из ниоткуда. При такой формулировке исполнителю будут непонятны реальные условия, в которых должен стартовать процесс.
6. Отсутствие логических и содержательных ошибок.
Это самый важный раздел в чек-листе. В первую очередь здесь нужно указать логические ошибки, например некорректное использование в паре логических операторов «И» и «ИЛИ». Но главное – это содержательный анализ схемы. Необходимо продумать стратегию выполнения процесса, основываясь на его графической схеме, оценить его выполнимость, результативность и эффективность. При проведении содержательного анализа схемы целесообразно привлечь эксперта в предметной области, узкоспециализированного отраслевого специалиста.
7. Аккуратность исполнения схемы. Визуальная наглядность.
Стоит обратить внимание на такие моменты:
• наличие объектов одного типа, но разного размера;
• выход надписей за границы объектов;
• наложение стрелок, надписей друг на друга;
• чрезмерное количество элементов на схеме.
8. Отсутствие физической нереализуемости.
Физическая нереализуемость может возникнуть, например, когда схема процесса предполагает одновременное выполнение двух операций одним и тем же исполнителем.
9. Отсутствие возвратов (переделок работы).
Довольно часто на схемах рисуют возвраты на предыдущую операцию или какую-то другую – по смыслу. Это, как правило, означает, что документ не согласован и нуждается в доработке. Теоретически несоответствия возможны при выполнении каждой операции процесса. Но тогда придется везде рисовать возвраты на предыдущий шаг, и схема станет чрезмерно сложной. Поэтому надо определить правила, когда рисовать возвраты, а когда нет. Для аналитических схем возвраты стоит показывать только в случае наиболее существенных отклонений. Это отклонения, при которых невозможна дальнейшая работа и требуется запуск дополнительных операций процесса. В любом случае, чем меньше возвратов, тем эффективнее бизнес-процесс.
10. Отсутствие дублирования операций (прямого или косвенного).
Как это ни странно, иногда на схеме процесса можно увидеть дублирование операций. Стоит обратить внимание на схожие по смыслу или почти одинаковые названия операций процесса. Иногда дублирование можно выявить, анализируя содержание операций и их результаты.
11. Выявление пропущенных важных операций.
Чтобы выявить пропущенные важные операции процесса, надо внимательно посмотреть на него с содержательной точки зрения. Например, мы описываем процесс выполнения работы на каком-то агрегате, но не показываем, что для этого нужно получить сырье на складе и т. п. Другой пример: перед помещением товара на склад его нужно упаковать и идентифицировать (приклеить ярлык со штрих-кодом), но эта операция пропущена.
12. Отсутствие чрезмерного контроля.
Это относительная вещь. Но если в процессе начальник слишком часто перепроверяет (согласует) работу подчиненных, это повод задуматься, насколько хорошо продуман процесс.
13. Отсутствие узких мест («бутылочные горлышки»).
«Бутылочное горлышко» – это ситуация, когда какая-то операция тормозит весь процесс. Визуально это можно обнаружить, когда несколько параллельных потоков сходятся на одной операции. При этом надо понять, есть ли ограничение по пропускной способности на этой операции. Иногда визуально выявить узкое место сложно. Нужен содержательный анализ на основе конкретных данных.
14. Отсутствие возвратов в прошлое.
Возвраты в прошлое или переходы в ненаступившее будущее означают, что на схеме показан возврат на операцию, которую уже нельзя выполнить физически. Ситуацию можно выявить только путем содержательного анализа. Пример: мы не можем вернуться и повторить процесс заливки опалубки бетоном, если фундамент дал трещину. Нужно ломать и переделывать.
15. Отсутствие смешения единичного потока и накопления (объектов обработки).
Это довольно распространенная ошибка. Например, процесс инициируется единичным событием (предоставить заявку на оплату), после чего выполняется формирование графика платежей и оплата. Если строго следовать схеме, которая не была разработана специальным образом, мы получим график платежей, состоящий из одного пункта.
16. Отсутствие «процессной грыжи».
«Процессная грыжа» – это ситуация, когда внутри процесса, который представлен одной операцией, появляется другой большой и сложный процесс, требующий значительных ресурсов и времени для выполнения. Например, в процессе получения информации об оплате счета возникает операция «Ведение бухгалтерского учета».
17. Отсутствие неоднородности масштаба операций.
Это выявляется довольно просто. Например, на одной схеме процесса представлены операции под названиями «Получить сменное задание у начальника» и «Изготовить продукцию». Первую делает мастер, а вторую выполняет весь цех численностью 30 человек.
Обратите внимание, что определенные проблемы, выявленные в чек-листе, могут явно указывать на необходимость дополнительной проработки самого процесса для повышения его эффективности. В этом случае рассматривается только графическая схема, а не бизнес-процесс в целом.
Плюсы использования BPM.
1. Возможность максимально детализировать действия людей и систем, необходимые для получения результата.
2. Графические нотации наглядны, что позволяет понять особенности процессов в компании и увидеть их слабые места.
3. Нотации прекрасно подходят в качестве инструкции для исполнителя, который получит четкую и однозначную последовательность действий, оформленную удобным для восприятия образом.
4. При использовании процессного подхода результат выполнения процесса будет соответствовать ожидаемому. Это позволит снизить влияние человеческого фактора на уровень сервиса или выполнения любых других видов работ.
5. Методология BPM прекрасно проработана и стандартизирована благодаря BPMN. Наличие стандартов и правил позволяет избегать ошибок при разработке и создавать в системе BPMS исполняемые нотации – готовые элементы автоматизации бизнеса.
Минусы BPM, как это часто бывает, находятся рядом с плюсами.
1. Высокая степень детализации процессов мешает восприятию работы бизнеса для стратегического планирования.
2. На разработчиках процессной модели лежит очень большая ответственность. Любая ошибка может привести к печальным результатам. Например, при разработке функциональной модели есть данные на входе, результат на выходе, инструменты, которые предоставляет компания исполнителю, и сам исполнитель. Пока исполнитель на выходе выдает ожидаемый результат, он может самостоятельно выбирать оптимальный метод достижения цели в рамках этой функции. При процессном подходе исполнитель лишается «свободы маневра». У него появляется четко заданная последовательность действий, учитывающая все возможные условия. И он не имеет права отступать от нее, даже если полученный результат отличается от ожидаемого.
3. Бизнес-процесс статичен и практически не подлежит корректировкам «изнутри». Исполнитель получает четкую последовательность действий и не может проявлять инициативу. В результате любую ошибку исполнители будут повторять из раза в раз, пока разработчики не исправят ее в самом бизнес-процессе.
Модели потоков данных – нотация DFD
В отличие от IDEF0, предназначенной для проектирования систем в целом, DFD создана для проектирования информационных систем. Ориентированность этой методологии на проектирование автоматизированных систем делает ее удобным и более выгодным инструментом для построения функциональной модели TO-BE. Это может быть полезно:
• при разработке информационной системы;
• при интеграции системы;
• при миграции данных и функционала с одной системы на другую;
• в проектах, связанных с Data Management;
• в процессе построения аналитического хранилища, BI-решения.
Диаграмма позволяет визуализировать как движение данных между объектами системы, так и преобразование данных, которые могут применяться на разных шагах процесса.
В диаграмме выделяют четыре элемента.
1. Процесс.
Процессы, при осуществлении которых происходит изменение потока данных (обработка, трансформация и др. изменения). Как и в других диаграммах, процесс обычно прописывается с помощью глагола, например: «Отправка заполненной формы».
2. Внешняя сущность.
Сущность (объект), которая получает или отправляет данные при взаимодействии с описанным процессом.
3. Хранилище данных.
Все хранилища данных или отдельные файлы, которые хранят исходные или выходные данные, а также все промежуточные хранилища.
4. Поток данных.
Поток данных, отображающий направление и сами данные, которые перемещаются между внешними сущностями и хранилищами данных с помощью процессов.
Несколько правил построения диаграмм:
• процесс должен иметь входной и выходной поток данных;
• хранилища данных также должны иметь входные и выходные потоки данных;
• данные с внешних сущностей должны пройти через процесс, чтобы попасть в хранилище.
Исторически синтаксис этой нотации применяется в двух вариантах – Гейна-Сарсона (Gane-Sarson) и Йордана (Yourdon). Различия между ними – на рисунке ниже:
В зависимости от цели использования диаграммы можно отображать различные уровни детализации процесса. К примеру, при разговоре и презентации процесса до бизнес-пользователей и заказчиков необходимо донести контекст и логику самого процесса, но нет смысла погружать их в технические моменты реализации. В то же время при разговоре с технической командой важно сделать акцент на реализации решения с технической точки зрения.
Подобно ER-диаграммам для моделей данных, которые включают в себя несколько слоев отображения (концептуальный, логический, физический), DFD-диаграммы также можно разделить на подобные уровни.
• Концептуальный (или контекстный)
Показывает общее описание процесса, который реализуется при потоке данных. Абстрактно отображает потоки данных, связанные с разными внешними сущностями.
• Логический
Отображает логику преобразования данных каждого процесса в системе, описывает их. Видны входные, промежуточные, выходные данные в каждом процессе, который протекает от внешней сущности до хранилищ данных. В большей степени отвечает на вопрос «Что включает в себя процесс потока и обмена данными со стороны бизнеса?»
• Физический
Включает точное отображение хранилищ данных, названий сущностей данных. Диаграмма физического уровня должна отвечать на вопрос «Как будет реализован процесс передачи и потока данных?»
Также в других источниках часто можно увидеть разделение уровней диаграммы на 0,1, 2, 3 и так далее, в зависимости от уровня детализации.
Если мы говорим про разработку нового решения, то важно понять, что мы имеем сейчас (AS-IS) и что желаем получить (TO-BE). Другими словами, мы разделяем наше текущее состояние и желаемое, которое хотим получить с помощью нашего решения.
➤ AS-IS
Описываем текущую логическую диаграмму.
➤ TO-BE
Описываем желаемую логическую диаграмму с новой логикой и требованиями от бизнеса. Затем из желаемой логической диаграммы описываем физическую диаграмму с новым техническим решением.
Модели потоков данных – нотация UML
Объектно-ориентированный (далее – ОО) анализ – метод анализа, который исследует требования к системе с точки зрения классов и объектов, относящихся к словарю предметной области. Определение дано в соответствии с трудами Г. Буча.
Анализ заключается в создании моделей, отображающих основные требования и характеристики целевой системы. Аналитическое моделирование стратегически важно при разработке информационных систем.
В одной из основополагающих книг «Объектно-ориентированный анализ и проектирование» (1991 г.) Майкл Блаха и Джеймс Рамбо определяют ОО-подход как метод, при котором мы рассматриваем систему в виде набора отдельных объектов, включающих в себя одновременно структуру данных и «поведение» (операции).
Основное отличие от функционального (структурного) подхода к программированию состоит в том, что данные и операции слабо связаны между собой. Основными элементами теперь являются классы и объекты, а не алгоритмы.
Переход к объектно-ориентированному подходу стал необходимым условием для проектирования больших сложных систем, в том числе благодаря возможности построения абстрактных классов.
Различие структурного и объектно-ориентированного подходов
Авторы выделяют стадии моделирования, на которых применяется ОО-подход.
1. Анализ. На этой стадии объекты относятся к области применения, а не к информационным системам. Модель не зависит от конкретного внедряемого решения.
2. Дизайн системы. Выстраивается высокоуровневая архитектура решения, целевая система разбивается на подсистемы, определяются требования к производительности.
3. Дизайн объектов. В качестве основы используется аналитическая модель. На этой стадии добавляются детали внедряемого решения, определяются структура данных и алгоритмы поведения объектов.
4. Внедрение. На этом этапе модель приводится в соответствие с конкретным языком программирования, выбранной БД и инфраструктурой.
Модели OO-анализа в дальнейшем преобразуются в объектно-ориентированный проект. Г. Буч дает следующее определение объектно-ориентированного проектирования (дизайна): это методология проектирования, соединяющая в себе процесс объектной декомпозиции и приемы представления логической (структуры классов) и физической (архитектура модулей и процессов), а также статической и динамической моделей проектируемой системы.
Цель ОО-проектирования – правильно и эффективно структурировать сложную систему для последующей разработки.
Одна из основных задач, решаемых на этапе ОО-анализа и ранних стадиях проектирования, – выявление ключевых сущностей (абстракций), то есть классов и объектов, присущих предметной области. Для этого сначала необходимо сформировать логический каркас системы – выделить классы, а затем описать атрибуты (свойства) этих классов, связи и взаимодействия между ними.
Сущности определяют границы решаемой проблемы. От того, насколько качественно проведен первичный анализ, зависит дальнейшая согласованность модели и, в конечном счете, ее реализация.
Конечно, не все объекты, существующие в информационной системе, имеют свои аналоги в реальном мире. При проектировании появляется достаточно много вспомогательных объектов, которые создают среду для объектов бизнес-логики и служат для обозначения части системы, моделирующей предметную область или задачу.
Необходимо четко понимать, чем объект отличается от класса. Объект (или экземпляр класса) обладает состоянием, поведением и идентичностью, а структуру и поведение схожих объектов определяет общий для них класс.
Получив документ с требованиями, для начала выделите в нем все существительные. Выпишите их и подумайте, какие из них можно рассмотреть как классы. Далее посмотрите на глаголы: они помогут выстроить связи между сущностями.
Более подробно о понятии объекта и о том, как выделять сущности, читайте у основоположников. Вы найдете ссылку на материал в «Используемых источниках» – Буч, Рамбо, Блаха.
1. Абстрагирование – способ выделить набор значимых характеристик объекта методом исключения из рассмотрения незначимых.
2. Инкапсуляция – свойство системы, позволяющее объединить данные и методы, работающие с ними, в классы и скрыть детали реализации от пользователя.
3. Полиморфизм – свойство системы использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре объекта.
4. Наследование – свойство системы, позволяющее описать новый класс на основе уже существующего с частично или полностью заимствующейся функциональностью. Класс, от которого производится наследование, называется базовым или родительским. Новый класс – потомком, наследником или производным классом.
Далее мы еще поговорим о классах и отношениях между ними.
Унифицированный язык моделирования (Unified Modeling Language) – язык визуального моделирования (чаще всего для ОО-анализа). Основная идея UML – возможность моделировать программное обеспечение и другие системы, такие как наборы взаимодействующих объектов.
UML – это язык, первичным же остается процесс ОО-анализа и моделирования. Используя доступные на рынке CASE-средства, позволяющие работать на языке UML, вы можете создавать модели. UML служит для «сверки часов», чтобы разные аналитики понимали друг друга.
1. Эскизное моделирование. В процессе разработки с помощью UML очень удобно делать наброски отдельных элементов системы. С помощью эскизов можно облегчить обмен идеями и вариантами с другими членами команды. Команда обсуждает не всю систему или проект, а только самые важные моменты или разделы проекта, которые необходимо визуализировать до начала разработки. Сила эскизов заключается в избирательности передачи информации, а не в полноте описания.
2. Язык UML как средство проектирования нацелен на полноту. Задача – построить детальную модель для программиста. Такая модель должна быть достаточно полной в части заложенных проектных решений, чтобы программист мог следовать им прямо, не особо задумываясь над дополнительными аспектами. Детальное проектирование можно использовать только для части системы или проекта, если это необходимо. При разработке моделей необходимо учитывать:
a. выбранный инструментарий: контроль версий, репозиторий объектов, связь между диаграммами;
b. глубину проработки модели и ее полноту: цель – минимизировать программирование, свести его к простым действиям.
3. Еще более глубоких знаний и больших усилий требуют проекты, в которых UML используется в качестве языка программирования. Существуют инструменты, позволяющие на основе диаграмм скомпилировать исполняемый код (программу), например Visual Paradigm. Часто в этом контексте упоминают термин MDA (Model Driven Architecture – архитектура, управляемая моделью). Этот стандарт находится под управлением группы OMG, как и сам UML.
MDA разделяет процесс разработки на две основные части. Сначала аналитики создают PIM (Platform Independent Model – модель, не зависящая от платформы). PIM – это модель UML, не зависящая от какой-то конкретной технологии. Затем инструменты могут превратить PIM в PSM (Platform Specific Model – модель, зависящая от платформы). PSM – это модель системы, нацеленная на определенную среду выполнения. Другие инструменты берут PSM и генерируют код для этой платформы. В качестве PSM можно использовать UML, но это не обязательно.
На практике, несмотря на достаточно продвинутые инструменты, перейти к этому процессу очень сложно. Нужно гарантировать полноту и непротиворечивость модели, на что, безусловно, нужно много временны´х ресурсов. Гораздо проще отделить непосредственно программирование от моделирования. Аналогичные идеи можно проследить в графических языках программирования. Постоянно возникает достаточно много ограничений, которые не позволяют повсеместно применять подобный подход.
Язык UML в своем нынешнем состоянии определяет нотацию и метамодель.
Нотация – это совокупность графических элементов, которые применяются в моделях. Она и является синтаксисом этого языка моделирования. Например, нотация диаграммы классов определяет способ представления таких элементов и понятий, как класс, ассоциация и кратность.
В настоящее время многие люди, вовлеченные в разработку UML, интересуются в основном метамоделью – описанием языка построения модели – в частности потому, что она важна при использовании UML и языка программирования. Метамодель определяет абстрактный синтаксис и семантику понятий объектного моделирования на языке UML. Погрузившись в изучение UML глубже, вы поймете, что вам требуется значительно больше, чем просто графическая нотация. Вот почему инструменты UML так сложны.
UML 2.0 описывает типы диаграмм. Давайте рассмотрим основные.
➤ Структурные диаграммы
Структурные диаграммы – статический аспект системы.
Эти статические части представлены классами, интерфейсами, объектами, компонентами и узлами.
1. Диаграмма классов (Class diagram).
2. Диаграмма объектов (Object diagram).
3. Диаграмма компонентов (Component diagram).
4. Диаграмма развертывания (Deployment diagram).
➤ Поведенческие диаграммы
Поведенческие диаграммы в основном отражают динамический аспект системы. Он может быть далее описан как изменяющиеся или движущиеся части системы.
В UML есть следующие типы поведенческих диаграмм.
1. Диаграмма вариантов использования (прецедентов) (Use case diagram).
2. Диаграмма последовательности (Sequence diagram).
3. Диаграмма сотрудничества (Collaboration diagram).
4. Диаграмма состояний (State diagram).
5. Диаграмма деятельности (Activity diagram).
Когда говорят о UML, часто упоминают RUP (Rational Unified Process – унифицированный процесс, созданный компанией Rational). Он не имеет особого отношения к UML, хотя тоже создавался сотрудниками фирмы Rational и в его названии есть слово «унифицированный». Язык UML можно использовать с любыми процессами, которые не рассматриваются в этом уроке. RUP – это коммерческий продукт, расширяющий UP.
Унифицированный процесс разработки ПО (Unified Software Development Process, USDP) – это SEP, процесс производства ПО (Software Engineering Process) от авторов UML. Обычно его называют унифицированным процессом, или UP. Это универсальный процесс разработки ПО, который должен настраиваться для определенной организации и для каждого конкретного проекта.
Следует заметить, что UML был стандартизован OMG, а UP – нет, поэтому до сих пор не существует стандартного процесса для UML.
UP базируется на трех аксиомах. Он:
• управляется требованиями и риском;
• архитектуроцентричный;
• итеративный и инкрементный.
В каждой итерации пять основных рабочих потоков определяют, что должно быть сделано и какие навыки для этого необходимы. В других методологиях это, по сути, стадии разработки ПО. Наряду с ними есть и другие, такие как планирование, оценка и все, что характерно для этой конкретной итерации. Однако эти этапы не выделены в UP. К пяти основным рабочим потокам относятся:
• определение требований – сбор данных о том, что должна делать система;
• анализ – уточнение и структурирование требований;
• проектирование – реализация требований в архитектуре системы;
• реализация – построение программного обеспечения;
• тестирование – проверка, в результате которой выявляется, отвечает ли реализация предъявляемым требованиям.
Структура UP
Рассмотрим основные рекомендации для ОО-проектирования на UML. Этот список можно расширять бесконечно. Но это именно то, из чего постепенно складывается ваш опыт проектирования на UML.
1. Не спешите строить диаграмму классов. Сначала поймите проблему, которую необходимо решить.
2. Старайтесь делать модель простой, без излишних усложнений.
3. Осторожно выбирайте названия классов, атрибутов и ассоциаций.
4. Не спешите выбирать отношение генерализации, потому как зачастую его можно представить другим способом, декомпозировав задачу.
5. Не старайтесь сразу обозначить множественность для ассоциаций.
6. Используйте квалификатор для ассоциаций между классами, где это возможно.
7. Используйте абстрактные классы для возможности повторного использования кода.
8. Обращайтесь к паттернам проектирования.
9. Проводите ревизию модели. Уточнения могут возникать на любом этапе проекта.
10. Документируйте свою модель. Пояснения позволяют объяснить причины выбора конкретного пути решения задачи и прояснить смысл выделенных классов.
11. Старайтесь создать гибкое решение и модель для повышения устойчивости к изменениям.
➤ Классы и отношения между ними
Как было обозначено выше, на начальных этапах анализа и проектирования необходимо определить логическую структуру системы. Это очень удобно сделать с помощью диаграммы классов.
Диаграмма классов описывает типы объектов системы и различного рода статические отношения между ними. На диаграммах классов отображаются также их свойства, операции и ограничения, которые накладываются на связи между объектами.
В общем случае пакет статической структурной модели можно представить в виде одной или нескольких диаграмм классов. Декомпозиция некоторого представления на отдельные диаграммы выполняется с целью удобства и графической визуализации структурных взаимосвязей предметной области.
Класс (class) служит для обозначения множества объектов, обладающих одинаковой структурой, поведением и отношениями с объектами из других классов. Обязательный элемент обозначения класса – его имя. Оно должно быть уникальным в пределах пакета объектов, который описывается совокупностью диаграмм классов (или одной диаграммой).
На начальных этапах разработки диаграммы отдельные классы могут обозначаться простым прямоугольником с указанием только имени соответствующего класса. По мере проработки отдельных компонентов описания классов дополняются атрибутами и операциями. Предполагается, что окончательный вариант диаграммы содержит наиболее полное описание классов.
Класс может не иметь экземпляров или объектов. В этом случае он называется абстрактным классом, а для обозначения его имени используется наклонный шрифт (курсив). В языке UML принято общее соглашение о том, что любой текст, относящийся к абстрактному элементу, записывается курсивом.
Пример диаграммы классов
Каждому атрибуту класса соответствует отдельная строка текста, которая состоит из квантора видимости атрибута, имени атрибута, его кратности, типа значений и, возможно, его исходного значения.
1. Символ «+» обозначает атрибут с областью видимости типа «общедоступный» (public). Атрибут с этой областью видимости доступен или виден из любого другого класса пакета, в котором определена диаграмма.
2. Символ «#» обозначает атрибут с областью видимости типа «защищенный» (protected). Атрибут с такой областью видимости недоступен или не виден для всех других классов, за исключением подклассов этого класса.
3. И, наконец, знак «-» обозначает атрибут с областью видимости типа «закрытый» (private). Атрибут с этой областью видимости недоступен или не виден для всех классов без исключения.
Если квантор видимости не указан, это означает, что видимость атрибута не указывается.
Рассмотрим варианты задания кратности атрибутов.
1. [0..1] означает, что кратность атрибута может принимать значение 0 или 1. При этом 0 означает отсутствие значения для данного атрибута.
2. [0..*] означает, что кратность атрибута может принимать любое положительное целое значение, большее или равное 0. Эта кратность может записываться в более короткой форме – в виде простого символа [*].
3. [1.:*] означает, что кратность атрибута может принимать любое положительное целое значение, большее или равное 1.
Тип атрибута – это выражение, семантика которого определяется языком спецификации соответствующей модели. В нотации UML тип атрибута иногда определяется в зависимости от языка программирования, который собираются использовать для реализации этой модели.
Операция (operation) – это сервис, предоставляющий каждый экземпляр класса по определенному требованию. Совокупность операций характеризует функциональный аспект поведения класса. Запись операций класса в языке UML также стандартизована и подчиняется определенным синтаксическим правилам. При этом каждой операции класса соответствует отдельная строка, которая состоит из квантора видимости операции, имени операции, выражения типа возвращаемого операцией значения и, возможно, строки-свойства этой операции.
Кроме внутреннего устройства или структуры классов, на соответствующей диаграмме указываются различные отношения между классами. Совокупность типов таких отношений зафиксирована в языке UML и предопределена семантикой этих типов отношений.
Базовые отношения (связи) в языке UML:
• отношение зависимости (dependency relationship);
• отношение ассоциации (association relationship);
• отношение обобщения (generalization relationship);
• отношение реализации (realization relationship).
Для начала, пока вы не определили детали, используйте отношение ассоциации.
Отношение ассоциации соответствует наличию некоторого отношения между классами. Оно связывает в точности два класса и, как исключение, может связывать класс с самим собой.
Отдельный класс ассоциации играет определенную роль в соответствующем отношении, которую можно изобразить графически на диаграмме классов. С этой целью в языке UML вводится в рассмотрение специальный элемент – конец ассоциации (Association End), который графически соответствует точке соединения линии ассоциации с отдельным классом. Конец ассоциации – часть ассоциации, но не класса. У каждой ассоциации два или больше концов. Наиболее важные свойства ассоциации указываются на диаграмме рядом с этими элементами и должны перемещаться вместе с ними.
Для любого отношения, кроме зависимости, принято указывать кратность отдельного класса. Кратность обозначается в виде интервала целых чисел, аналогично кратности атрибутов и операций классов. Интервал записывается рядом с концом ассоциации и для N-арной ассоциации означает потенциальное число отдельных экземпляров или значений кортежей этой ассоциации, которые могут иметь место, когда остальные N‐1 экземпляров или значений классов фиксированы. Кратность для отношения определяется аналогично кратности атрибутов (см. выше).
Отношение агрегации имеет место между несколькими классами в том случае, если один из классов имеет некоторую сущность, включающую в себя в качестве составных частей другие сущности.
Отношение композиции – частный случай отношения агрегации. Это отношение служит для выделения специальной формы отношения «часть – целое», при которой составляющие части находятся внутри целого. Специфика взаимосвязи между ними заключается в том, что части не могут выступать в отрыве от целого; с уничтожением целого уничтожаются и все его составные части.
Отношение обобщения (генерализации) – обычное таксономическое отношение между более общим элементом (родителем, или предком) и более частным или специальным элементом (дочерним, или потомком).
Отношение зависимости в общем случае – семантическое отношение между двумя элементами модели или двумя множествами элементов, которое не является отношением ассоциации, обобщения или реализации. Оно касается только самих элементов модели и не требует множества отдельных примеров для пояснения своего смысла. Отношение зависимости используется в ситуации, когда некоторое изменение одного элемента модели может потребовать изменить другой зависимый от него элемент.
Диаграммы последовательностей (sequence diagram) описывают отношения объектов в различных условиях. Это разновидность диаграмм взаимодействия языка UML, которая широко используется в качестве эскизов: например, на рабочих встречах при обсуждении задач по разработке информационных систем.
Можно использовать диаграммы последовательностей при проектировании новых или при анализе и рефакторинге старых систем.
На диаграмме последовательности неявно присутствует ось времени, что позволяет визуализировать временные отношения между передаваемыми сообщениями.
Каждый объект графически изображается в виде прямоугольника и располагается в верхней части своей линии жизни. Внутри прямоугольника записываются собственное имя объекта со строчной буквы и имя класса, между собой они разделяются двоеточием.
Крайним слева на диаграмме изображается объект-инициатор моделируемого процесса взаимодействия. Правее – другой объект, который непосредственно взаимодействует с первым, и так далее.
Общая схема диаграммы последовательности
Сообщения изображаются в виде горизонтальных стрелок с именем сообщения и образуют определенный порядок относительно времени своей инициализации. Другими словами, сообщения, расположенные на диаграмме последовательности выше, передаются раньше тех, которые расположены ниже. При этом масштаб на оси времени не указывается, поскольку диаграмма последовательности моделирует лишь временную упорядоченность взаимодействий типа «раньше/позже».
Линия жизни объекта (object lifeline) – вертикальная линия на диаграмме последовательности, которая представляет существование объекта в течение определенного периода времени.
Линия жизни объекта изображается пунктирной вертикальной линией, ассоциированной с единственным объектом на диаграмме последовательности. Линия жизни служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях.
Фокус управления – вытянутый прямоугольник на линии жизни, указывающий период времени, в течение которого объект выполняет некоторое действие, находясь в активном состоянии.
В отдельных случаях инициатором взаимодействия в системе может быть внешний пользователь. При этом он изображается на диаграмме последовательности самым первым объектом слева и имеет свой фокус управления.
В отдельных случаях объект может посылать сообщения самому себе, инициируя так называемые рефлексивные сообщения. Они изображаются в форме сообщения, начало и конец которого соприкасаются с линией жизни или фокусом управления одного и того же объекта. Подобные ситуации возникают, например, при обработке нажатий на клавиши клавиатуры при вводе текста в редактируемый документ.
На диаграммах последовательности могут присутствовать три разновидности сообщений, у каждого из которых свое графическое изображение.
➤ Типы сообщений
1. Синхронные сообщения используются для вызова процедур, выполнения операций или обозначения отдельных вложенных потоков управления. Отправитель сообщения не может совершать действий, пока не получит ответ на отправленное сообщение.
2. Асинхронные сообщения – передача такого сообщения обычно не сопровождается получением фокуса управления объектом-получателем.
3. Ответное сообщение (reply) используется для возврата из вызова процедуры. Примером может служить простое сообщение о завершении вычислений без предоставления результата расчетов объекту-клиенту. В процедурных потоках управления эта стрелка может быть опущена, поскольку ее наличие неявно предполагается в конце активизации объекта. В то же время считается, что каждый вызов процедуры имеет свою пару – возврат вызова.
4. Найденное сообщение (found message) – у первого сообщения нет участника, который его послал, поскольку оно приходит из неизвестного источника.
5. Потерянное сообщение (lost message) – сообщение, для которого существует событие передачи и отсутствует событие приема. Изображается в форме небольшого черного круга на конце стрелки сообщения. Оно интерпретируется как сообщение, которое никогда не достигнет своего места назначения.
➤ Правила построения диаграмм последовательностей
1. Для начала выделите все объекты, участвующие во взаимодействии, расположите их в порядке инициации, а после этого переходите к визуализации сообщений между объектами.
2. Помните, что диаграмма должна оставаться читаемой.
3. Чрезмерное ветвление использовать не рекомендуется, так как для изображения деталей алгоритмов в языке UML есть диаграммы деятельности. Общее правило – визуализировать каждый поток управления на отдельной диаграмме последовательности.
На рисунке ниже отображен более сложный вариант диаграммы последовательностей, на котором показаны фреймы взаимодействия. Каждый фрейм – область диаграммы, разделенная на несколько фрагментов; у нее есть оператор для обозначения условной логики.
Пример отображения фреймов взаимодействия
1. alt – несколько альтернативных фрагментов (alternative). Выполняется только тот фрагмент, условие которого истинно.
2. opt – необязательный (optional) фрагмент. Выполняется, только если условие истинно. Эквивалентен alt с одной веткой.
3. par – параллельный (parallel). Все фрагменты выполняются параллельно. Например, система уведомляет параллельно всех трех подписчиков, и все они параллельно и независимо друг от друга начинают работать.
4. loop – цикл (loop). Фрагмент может выполняться несколько раз.
5. region – критическая область (critical region). Фрагмент может иметь только один поток, выполняющийся за один прием.
6. neg – отрицательный (negative) фрагмент. Обозначает неверное взаимодействие.
7.ref – ссылка (reference). Ссылается на взаимодействие, определенное на другой диаграмме. Фрейм рисуют, чтобы охватить линии жизни, вовлеченные во взаимодействие. Позволяет определять параметры и возвращать значение. Фрейм ref может показывать предусловия, то есть требования, которые необходимо выполнить перед началом выполнения действий.
8. sd – диаграмма последовательности (sequence diagram). Используется для очерчивания всей диаграммы последовательности, если это необходимо.
Пример построения диаграммы последовательностей
Use case-диаграмма (диаграмма вариантов использования, прецедентов) описывает функциональную модель системы. Она позволяет на первоначальном этапе определения требований сформировать представление о том, что должно получиться в результате, а также уточнить концепцию системы.
Безусловно, не только use case-диаграмма используется для определения требований. В частности, описание вариантов использования не относится к нефункциональным ограничениям: производительности, надежности и т. п.
Прецеденты – лучший выбор для фиксирования требований в тех случаях, когда:
• в системе преобладают функциональные требования;
• в системе много типов пользователей, которым она предоставляет разные функциональные возможности (много акторов);
• в системе много интерфейсов.
Диаграммы вариантов использования позволяют:
• определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы;
• сформулировать общие требования к функциональному поведению проектируемой системы;
• разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей;
• подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями.
➤ Элементы диаграммы прецедентов
Прежде всего необходимо определить границы системы и ее части. Это поможет избежать большого количества проблем при выявлении требований.
Далее следует определить акторов (кто или что использует систему) и функции, которые предоставляет для них система (варианты использования или прецеденты).
Актор определяет роль, которую при непосредственном взаимодействии с этой системой выполняет внешняя сущность: пользователь, другая система или часть аппаратной платформы, а также отдельный класс. Сущности могут выполнять несколько ролей одновременно, роль определяется именно по отношению к системе.
Прецедент – то, что должна делать система. Это «вариант использования» системы конкретным актором:
• прецеденты всегда инициируются актером;
• прецеденты всегда описываются с точки зрения актеров.
Моделирование прецедентов, как и системы в целом, – это итеративный процесс. Вначале описывается концепция в целом, затем добавляются детали.
У каждого прецедента есть основной поток, и может быть множество альтернативных потоков, например перехват ошибок, ответвления функционала и прерывания основного потока.
Один прецедент может охватывать множество отдельных функциональных требований, и одно функциональное требование может появляться в нескольких разных прецедентах. CASE-средства для моделирования на UML позволяют ассоциировать список требований с каждым прецедентом, и наоборот.
Акторы взаимодействуют с системой посредством сообщений, которые не отображаются на диаграмме прецедентов. Давайте рассмотрим взаимодействие между отдельными акторами и вариантами использования или классами.
➤ Виды отношений между акторами и вариантами использования
Пример построения диаграммы прецедентов
Диаграмма деятельности позволяет детализировать особенности алгоритмической и логической реализации операций, выполняемых системой. Также она используется для моделирования бизнес-процессов.
Эта диаграмма очень похожа на диаграмму состояний (state diagram), но имеет немного другую семантику. По сути, это блок-схема. Каждое состояние на диаграмме деятельности соответствует выполнению некоторой элементарной операции, а переход в следующее состояние срабатывает только при завершении этой операции в предыдущем состоянии.
Диаграммы деятельности позволяют представить процесс и результат его выполнения на ранних этапах анализа, когда еще сложно полностью описать структуру классов и объектов.
Не забывайте, что не стоит чрезмерно усложнять любую диаграмму, в том числе диаграмму деятельности, если вы хотите, чтобы она легко воспринималась всеми заинтересованными лицами.
➤ Элементы диаграммы деятельности
В диаграмме деятельности для представления параллельных процессов используется специальная конструкция – дорожки (swimlanes). При этом все состояния действия на диаграмме деятельности разбиваются на группы, которые отделяются друг от друга вертикальными линиями. Например, так можно отображать процесс, выполняемый разными подразделениями компании.
Для ОО-анализа и проектирования используются и нисходящий, и восходящий процесс анализа. На начальных этапах диаграмма деятельности может содержать укрупненные состояния в виде поддеятельностей, которые в дальнейшем детализируются на отдельных диаграммах. Уже готовые отлаженные диаграммы отдельных частей системы или процессов можно вложить в диаграммы деятельности при проектировании новых систем.
Пример построения диаграммы деятельности
Диаграмма компонентов относится к физическому уровню представления системы и позволяет определить архитектуру разрабатываемой системы. Программный код системы реализуется в форме исполняемых модулей, библиотек классов и процедур, стандартных графических интерфейсов, файлов баз данных. Эти компоненты – необходимые элементы физического представления системы. Таким образом, полный проект программной системы – совокупность моделей логического и физического представлений, которые должны быть согласованы между собой.
На диаграмме компонентов можно показать компоненты, зависимости между ними и то, как компонентам назначаются классификаторы.
Диаграмму компонентов разрабатывают для следующих целей.
1. Визуализация общей структуры исходного кода программной системы.
2. Спецификация исполняемого варианта программной системы.
3. Обеспечение многократного использования отдельных фрагментов программного кода.
4. Представление концептуальной и физической схем баз данных.
Компонент – это модульная часть системы, которая инкапсулирует ее содержимое. Реализацию компонента можно изменить, не нарушая взаимодействие с другими элементами системы.
Компоненты могут иметь атрибуты и операции, участвовать в отношениях ассоциации и обобщения.
Пример внутренней структуры компонента
В языке UML для компонентов определены различные стереотипы.
1. Библиотека (<
2. Таблица (<