Методическое пособие для студентов СПО по предмету "Инструментальные средства разработки ПО"

Создание моделей бизнес-процессов

1. Принципы построения моделей бизнес-процессов

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

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

Наиболее удобным языком моделирования бизнес-процессов является IDEF0, предложенный Дугласом Россом. Подробные описания стандартов IDEF можно найти на сайте http://www.idef.com .

В IDEF0 модель предметной области представляется как совокупность взаимодействующих работ (=функций). Такая функциональная ориентация является принципиальной, так как позволяет более четко смоделировать логику и взаимодействие процессов, происходящих в организации. Саму предметную область и происходящие в ней процессы называют системой (система ≠ КИС).

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

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

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

2) Цель моделирования (Purpose). Модель не может быть построена без четко сформулированной цели. Цель должна отвечать на следующие вопросы:

• Почему эта система должна быть замоделирована?

• Что должна показывать модель?

• Какую информацию может получить человек, который видит созданную модель?

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

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

IDEF0-модель предполагает наличие единственного субъекта моделирования, четко сформулированной цели, и одной точки зрения. Для внесения области, цели и точки зрения в модели IDEF0 в BPwin следует выбрать в главном меню пункт Model – Model Properties, вызывающий диалог Model Properties (рис. 1). В закладке Purpose следует внести цель и точку зрения, а в закладку Definition - определение модели и описание области.

Рис. 1. Диалог задания свойств модели

В закладке Status того же диалога можно описать статус модели (черновой вариант, рабочий, окончательный и т. д.), время создания и последнего редактирования (отслеживается в дальнейшем автоматически по системной дате). В закладке Source описываются источники информации для построения модели (например, "Опрос экспертов предметной области и анализ документации"). Закладка General служит для внесения имени модели, имени и инициалов автора и временных рамок модели – необходимо выбрать AS-IS или ТО-ВЕ (то есть как есть или как будет).

В процессе моделирования системы в IDEF0 важную роль играют временные рамки AS-IS и ТО-ВЕ.

Обычно сначала строится модель существующей организации работы - AS-IS (как есть). Модель AS-IS позволяет выяснить, "что мы делаем сегодня" перед тем, как перепрыгнуть на то, "что мы будем делать завтра". Анализ модели AS-IS позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура деятельности организации. Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где на первый взгляд их нет. Признаками неэффективной деятельности могут быть:

• бесполезные, неуправляемые и дублирующиеся работы,

• неэффективный документооборот (нужный документ не оказывается в нужном месте в нужное время),

• отсутствие обратных связей по управлению (на проведение работы не оказывает влияния ее результат) и т.д.

Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как будет) - модели нового построения бизнес-процессов. Модель ТО-ВЕ нужна для анализа альтернативных путей выполнения работы и документирования того, как компания будет строить деятельность в будущем.

Распространенной ошибкой при создании модели AS-IS является создание идеализированной модели. Примером может служить создание модели на основе знаний руководителя, а не конкретного исполнителя работ. Руководитель знаком с тем, как предполагается выполнение работы по руководствам и должностным инструкциям и часто не знает, как на самом деле подчиненные выполняют рутинные работы. В результате получается приукрашенная, искаженная модель, которая несет ложную информацию и которую невозможно в дальнейшем использовать для анализа. Такая модель называется SHOULD_BE (как должно бы быть).

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

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

2. Графический язык описания бизнес-процессов

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

Модель может содержать четыре типа диаграмм:

• контекстную диаграмму (в каждой модели может быть только одна контекстная диаграмма);

• диаграммы декомпозиции;

• диаграммы дерева узлов;

• диаграммы только для экспозиции (FEO).

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

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

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

3. Работы (Activity)

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

Рис. 2. Контекстная диаграмма в момент создания новой модели

Для внесения имени работы следует щелкнуть по работе правой кнопкой мыши, выбрать в контекстном меню пункт Name и в появившемся диалоге Activity Properties внести имя работы. В этом же диалоге можно указать другие свойства работы (рис. 3).

Рис.3. Диалог Activity Properties.

Рис. 4. Контекстная диаграмма в результате наименования работы

4. Стрелки (Arrow)

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

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

Рис. 5. Изображение стрелок на контекстной диаграмме

1) Вход (Input) - материал или информация, которые используются или преобразуется работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Стрелка входа рисуется как входящая в левую грань работы. При описании технологических процессов (для этого и был придуман IDEF0) не возникает проблем определения входов. Действительно, "Сырье" на рис. 5 - это нечто, что перерабатывается в процессе "Изготовление изделия" для получения результата. При моделировании ИС, когда стрелками являются не физические объекты, а данные, не все так очевидно. Например, при "Приеме пациента" карта пациента может быть и на входе и на выходе, между тем качество этих данных меняется. Другими словами, в нашем примере для того, чтобы оправдать свое назначение, стрелки входа и выхода должны быть точно определены с тем, чтобы указать на то, что данные действительно были переработаны (например, на выходе - "Заполненная карта пациента"). Очень часто сложно определить, являются ли данные входом или управлением. В этом случае подсказкой может служить то, перерабатываются (=изменяются) ли данные в работе или нет. Если изменяются, то, скорее всего, это вход, если нет - управление.

2) Управление (Control) - правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы. На рис. 5 стрелки "Задание" и "Чертеж" - управление для работы "Изготовление изделия". Управление влияет на работу, но не преобразуется работой.

3) Выход (Output) - материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка выхода рисуется как исходящая из правой грани работы. На рис. 2 стрелка "Готовое изделие" является выходом для работы "Изготовление изделия".

4) Механизм (Mechanism) - ресурсы, которые выполняют работу, например персонал предприятия, станки, устройства и т. д. Стрелка механизма рисуется как входящая в нижнюю грань работы. На рис.2 стрелка "Персонал предприятия" является механизмом для работы "Изготовление изделия". По усмотрению аналитика стрелки механизма могут не изображаться в модели.

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

• щелкнуть по кнопке с символом стрелки в палитре инструментов, перенести курсор к левой стороне экрана, пока не появится начальная черная полоска;

• щелкнуть один раз по полоске (откуда выходит стрелка) и еще раз в левой части работы со стороны входа (где заканчивается стрелка);

• вернуться в палитру инструментов и выбрать инструмент указания ;

• щелкнуть правой кнопкой мыши на линии стрелки, в контекстном меню выбрать пункт Name и написать имя стрелки в закладке Name диалога Arrow Properties.

Стрелки управления, механизма и выхода строятся аналогично (см рис. 6).

Рис.6. Диалог Arrow Properties

Для идентификации граничных стрелок предназначены коды ICOM (аббревиатура от Input, Control, Output и Mechanism). Код ICOM содержит префикс, соответствующий типу стрелки (I, С, О или М), и порядковый номер, например, I1, M1, C1, C2 (рис.7).

BPwin вносит ICOM-коды автоматически. Для отображения ICOM-кодов следует выбрать в основном меню пункт Model – Model Properties, в появившемся диалоге Model Properties перейти на закладку Display и включить опцию ICOM codes (рис. 7).

Рис. 7. Закладка Display диалога Model Properties.

На контекстной диаграмме ICOM коды не отображаются. Отображение их происходит на диаграммах декомпозиции.

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

Для создания диаграммы декомпозиции следует щелкнуть по кнопке . Возникает диалог Activity Box Count (рис. 8), в котором следует указать нотацию новой диаграммы и количество работ на ней. Работ может быть от 2 до 8.

Рис. 8. Диалог Activity Box Count.

Остановимся пока на нотации IDEF0, число работ равно 4 и щелкнем на ОК. Появляется диаграмма декомпозиции (рис. 9).

Рис. 9. Диаграмма декомпозиции.

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

Если оказывается, что количество работ недостаточно, то работу можно добавить в диаграмму, щелкнув сначала по кнопке на палитре инструментов, а затем по свободному месту на диаграмме.

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

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

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

На рис. 10 представлена диаграмма декомпозиции с ICOM –кодами.

Рис. 10. Диаграмма декомпозиции с ICOM -кодами

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

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

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

1) Связь по входу (output-input), когда стрелка выхода вышестоящей работы (далее - просто выход) направляется на вход нижестоящей (например, на рис. 11 стрелка "Детали" связывает работы "Изготовление деталей" и "Сборка изделия").

Рис. 11. Связь по входу

2) Связь по управлению (output-control), когда выход вышестоящей работы направляется на управление нижестоящей. Связь по управлению показывает доминирование вышестоящей работы. Данные или объекты выхода вышестоящей работы не меняются в нижестоящей. На рис. 12 стрелка "Чертеж" связывает работы "Создание чертежа детали" и "Изготовление детали"), при этом чертеж не претерпевает изменений в процессе изготовления деталей.

Рис. 12. Связь по управлению

3) Обратная связь по входу (output-input feedback), когда выход нижестоящей работы направляется на вход вышестоящей. Такая связь, как правило, используется для описания циклов. На рис. 13 стрелка "Брак" связывает работы "Переработка сырья" и "Контроль качества", при этом выявленный на контроле брак направляется на вторичную переработку.

Рис. 13. Обратная связь по входу

4) Обратная связь по управлению (output-control feedback), когда выход нижестоящей работы направляется на управление вышестоящей. Обратная связь по управлению часто свидетельствует об эффективности бизнес - процесса. На рис. 14 качество изделия может быть повышено путем непосредственного регулирования процессами изготовления деталей и сборки изделия в зависимости от результата (выхода) работы "Контроль качества" (стрелка "Рекомендации").

Рис. 14. Обратная связь по управлению

5) Связь выход-механизм (output-mechanism), когда выход одной работы направляется на механизм другой. Эта взаимосвязь используется реже остальных и показывает, что одна работа подготавливает ресурсы, необходимые для проведения другой работы (рис. 15).

Рис. 15. Связь выход-механизм

Рассмотрим вопросы разветвления и слияния стрелок.

Разветвление стрелок возможно, если одни и те же данные или объекты могут использоваться сразу в нескольких работах. Разветвлению подлежат стрелки входа, управления и механизмов. На рис. 16 разветвлению подвергнута стрелка «Изделие», которая является входом работ «Упаковка в коробки» и «Упаковка в ящики».

Слияния стрелок происходит в случае, если стрелки, порожденные в разных работах, представляют собой одинаковые или однородные данные или объекты, которые в дальнейшем используются или перерабатываются в одной работе. Слиянию подлежат только стрелки выхода каких-либо работ (рис. 16). На примере слиянию подлежат стрелки выхода работ «Упаковка в коробки» и «Упаковка в ящики». В результате получается изделие однотипное – оно упакованное.

Рис. 16. Разветвление стрелки «Изделие».

Для моделирования таких ситуаций в IDEF0 используются разветвляющиеся и сливающиеся стрелки. Для разветвления стрелки нужно в режиме редактирования стрелки щелкнуть по фрагменту стрелки и по соответствующей грани работы. Для слияния двух стрелок выхода нужно в режиме редактирования стрелки сначала щелкнуть по сегменту выхода работы, а затем по соответствующему фрагменту стрелки. Предварительно надо переименовать название стрелки, выходящей из работы «Упаковка в ящики», затем удалить эту переименованную стрелку, потом провести слияние указанным путем: щелкнуть по сегменту выхода работы «Упаковка в ящики», а затем по стрелке «Упакованное изделие» (рис. 17).

Рис. 17. Слияние стрелок «Упакованное изделие»

Смысл разветвляющихся и сливающихся стрелок передается именованием каждой ветви стрелок. Существуют определенные правила именования таких стрелок. Рассмотрим их на примере разветвляющихся стрелок. Если стрелка именована до разветвления, а после разветвления ни одна из ветвей не именована, то подразумевается, что каждая ветвь моделирует те же данные или объекты, что и ветвь до разветвления (рис. 18, а).

Рис. 18 (а). Пример именования разветвляющейся стрелки

Если стрелка именована до разветвления, но при этом какая-либо ветвь после разветвления осталась неименованной, то подразумевается, что она моделирует те же данные или объекты, что и ветвь до разветвления (рис. 18, б).

Рис. 18 (б). Другой пример именования разветвляющейся стрелки

Недопустима ситуация, когда стрелка до разветвления не именована, а после разветвления не именована какая-либо из ветвей. BPwin определяет такую стрелку как синтаксическую ошибку (рис.18, в ).

Рис. 18 (в). Пример неверного именования разветвляющейся стрелки

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

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

Иногда в процессе моделирования предметной области возникает необходимость добавления новых граничных стрелок на диаграмму декомпозиции нижнего уровня. Такие граничные стрелки изображаются в квадратных скобках и автоматически не появляются на диаграмме верхнего уровня. Эти стрелки называют “неразрешенными” (unresolved) (рис.19).

Рис. 19. Неразрешенная (unresolved) стрелка

Для того чтобы “неразрешенная” стрелка появилась на диаграмме верхнего уровня, необходимо щелкнуть правой кнопкой мыши на конце стрелки, заключенном в квадратные скобки, и в появившемся контекстном меню выбрать пункт Arrow Tunnel. В результате появится диалог Border Arrow Editor (рис.20).

Рис.20. Диалог Border Arrow Editor

Если в диалоге Border Arrow Editor выбрать вариант Resolve it to border arrow, стрелка мигрирует на диаграмму верхнего уровня. Если выбрать вариант Change it to resolved rounded tunnel, то стрелка будет “затоннелирована” и не попадет на диаграмму верхнего уровня. Такая “тоннельная” стрелка изображается с круглыми скобками на конце (рис.21).

Рис. 21. Тоннельная стрелка.

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

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

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

Такое тоннелирование называется "не-в-дочерней-работе".

5. Нумерации диаграмм и работ

В процессе декомпозиции создаются новые диаграммы и входящие в них работы. Рассмотрим вопросы нумерации диаграмм и работ.

Все работы модели нумеруются. Номер состоит из префикса и числа. Может быть использован префикс любой длины, но обычно используют префикс А. Контекстная (корневая) работа дерева имеет номер А0. Работы декомпозиции А0 имеют номера А1, А2, A3 и т. д. Работы декомпозиции нижнего уровня имеют номер родительской работы и очередной порядковый номер, например работы декомпозиции A3 будут иметь номера А31, А32, АЗЗ, А34 и т. д. Работы образуют иерархию, где каждая работа может иметь одну родительскую и несколько дочерних работ, образуя дерево. Такое дерево называют деревом узлов, а вышеописанную нумерацию - нумерацией по узлам. Для настройки нумерации и отображения номеров необходимо в главном меню BPwin выбрать пункт Model – Model Properties и в появившемся диалоге Model Properties перейти на закладку Numbering. Для отображения на диаграммах описанной нумерации работ следует в разделе Activity установить галочку у параметра Show Prefix и выбрать параметр Use diagram numbering format (рис. 22).

Рис. 22. Закладка Numbering диалога Model Properties.

6. Диаграмма дерева узлов

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

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

Сама среда BPwin имеет инструмент навигации по модели - Model Explorer (рис. 23), который позволяет представить иерархию работ и диаграмм в удобном и компактном виде, однако этот инструмент не является составляющей стандарта IDEF0.

Рис. 23. Инструмент Model Explorer среды BPwin.

Для создания диаграммы дерева узлов следует выбрать в главном меню пункт Diagram – Add Node Tree. Возникает диалог мастера формирования диаграммы дерева узлов Node Tree Wizard. На первом шаге работы мастера (рис. 24) необходимо указать название диаграммы дерева узлов (Node Tree Name), работу верхнего уровня (Top Level Activity), с которой начнется построение диаграммы, и глубину дерева (Number of Levels). Глубина дерева определяет, какое количество уровней декомпозиции будет отражено на диаграмме дерева узлов.

Рис. 24. Первый шаг работы мастера создания диаграммы дерева узлов.

После нажатия кнопки Далее на втором шаге работы мастера предлагается установить параметры создаваемой диаграммы (рис.25). Эти параметры можно не менять и сразу нажать кнопку Готово.

Рис. 25. Второй работы мастера создания диаграммы дерева узлов.

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

Рис. 26. Диаграмма дерева узлов

Удаление диаграммы дерева узлов может быть выполнено из диалога Diagram Manager (рис. 27), который вызывается путем выбора пункта основного меню Diagram – Diagram Manager.

Рис. 27. Диалог Diagram Manager

7. Слияние и расщепление моделей

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

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

Для слияния необходимо выполнить следующие условия:

• Обе сливаемые модели должны быть открыты в одном экземпляре приложения BPwin;

• Имя модели-источника, которое присоединяют к модели-цели, должно совпадать с именем стрелки вызова работы в модели-цели;

• Стрелка вызова должна исходить из недекомпозируемой работы (работа должна иметь диагональную черту в левом верхнем углу);

• Имя контекстной работы подсоединяемой модели-источника должно совпадать с именем работы на модели-цели, к которой мы подсоединяем разработанную модель-источник;

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

Для слияния моделей нужно щелкнуть правой кнопкой мыши по работе со стрелкой вызова в модели-цели и во всплывающем меню выбрать пункт Merge Model (рис. 28).

Рис. 28. Стрелка вызова и контекстное меню для выполнения слияния.

В результате появляется диалог, в котором следует указать опции слияния модели (рис. 29). В случае одинаковых определений возможна перезапись определений или принятие определений из модели-источника. То же относится к именам стрелок.

Рис. 29. Диалог слияния моделей Continue with merge?.

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

Разделение моделей производится аналогично. Для “отщепления” ветви от модели следует щелкнуть правой кнопкой мыши по декомпозированной работе (работа не должна иметь диагональной черты в левом верхнем углу) и выбрать во всплывающем меню пункт Split Model. В появившемся диалоге Split Options (рис. 30) следует указать имя создаваемой модели. После подтверждения расщепления в старой модели работа станет недекомпозированной (признак - диагональная черта в левом верхнем углу), будет создана стрелка вызова, причем ее имя будет совпадать с именем новой модели, и, наконец, будет создана новая модель, причем имя контекстной работы будет совпадать с именем работы, от которой была "оторвана" декомпозиция.

Рис.30. Диалог Split Options

7. Общие рекомендации по разработке диаграмм бизнес-процессов

В реальных диаграммах к каждой работе может подходить и от каждой может отходить около десятка стрелок. Если диаграмма содержит 6-8 работ, то она может содержать 30-40 стрелок, причем они могут сливаться, разветвляться и пресекаться. Такие диаграммы могут стать очень плохо читаемыми. В IDEF0 существуют соглашения по разработке диаграмм, которые призваны облегчить чтение и экспертизу модели. Некоторые из этих правил BPwin поддерживает автоматически, выполнение других следует обеспечить вручную.

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

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

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

Обратные связи по входу необходимо изображать "нижней" петлей, обратные связи по управлению - "верхней".

Если нужно изобразить связь по входу, необходимо избегать "нависания" работ друг над другом.

33