Создание модели процессов в BPwin (IDEF0)

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

Обычно сначала строится модель существующей организации работы -"AS-IS" (как есть). Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Найденные в модели "AS-IS" недостатки можно исправить при создании модели "TO-BE" (как должно быть) - модели новой организации бизнес-процессов.
Наиболее удобным языком моделирования бизнес- процессов является IDEF0, предложенный более 20 лет назад Дугласом Россом (Ранее назывался SADT - Structured Analysis and Design Technique).

Подробно методология SADT излагается в книге Дэвида А.Марка и Клемента МакГоуэна"Методология структурного анализа и проектирования SADT", издательство Метатехнология, 1993.

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

Основу методологии IDEF0 составляет графический язык описания бизнес- процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Вершина этой древовидной структуры, представляющая собой самое общее описание системы и ее взаимодействия с внешней средой, называется контекстной диаграммой. После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. После декомпозиции контекстной диаграммы проводится декомпозиция каждого большого фрагмента системы на более мелкие и так далее до достижения нужного уровня подробности описания. После каждого сеанса декомпозиции проводятся сеансы экспертизы - эксперты предметной области указывают на соответствие реальных бизнес - процессов созданным диаграммам. Найденные несоответствия исправляются и только после прохождения экспертизы без замечаний можно приступать к следующему сеансу декомпозиции. Таким образом достигается соответствие модели реальным бизнес - процессам на любом и каждом уровне модели. Синтаксис описания системы в целом и каждого ее фрагмента одинаков во всей модели. Работы (Activity), которые означают некие поименованные процессы, функции или задачи, изображаются в виде прямоугольников. Именем работы должен быть глагол или глагольная форма (например "Изготовление детали", "Прием заказа" и т.д.). Взаимодействие работ с внешним миром и между собой описывается в виде стрелок. Стрелки представляют собой некую информацию и именуются существительными (например, "Заготовка", "Изделие", "Заказ"). В IDEF0 различают пять типов стрелок:

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

При создании новой модели (меню File / New) автоматически создается контекстная диаграмма с единственной работой, изображающей систему в целом. Для внесения имени работы следует кликнуть по работе правой кнопкой мыши, выбрать в меню Name Editor и в появившемся диалоге внести имя работы. Для описания других аспектов контекста служит диалог Model Definition Editor (вызывается из меню Edit/Model Definition).

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

  1. кликните на символе стрелки в палитре инструментов
  2. перенесите курсор к левой стороне экрана, пока не появится начальная штриховая полоска
  3. щелкните один раз по полоске (откуда выходит стрелка) и еще раз в левой части работы со стороны входа (где заканчивается стрелка)
  4. вернитесь в палитру инструментов и выберите опцию редактирования стрелки
  5. дважды щелкните на линии стрелки , во всплывающем меню выберите Name Editor
и добавьте имя стрелки.
Стрелки управления, выхода, механизма и выхода изображаются аналогично.
Рис.2 Контекстная диаграмма.

Имена вновь внесенных стрелок автоматически заносятся в словарь (Arrow Dictionary). Словарь стрелок редактируется при помощи специального редактора Arrow Dictionary Editor, в котором определяется стрелка и вносится относящийся к ней комментарий. Словарь стрелок можно распечатать в виде отчета (меню Report / Arrow Report...) и получить тем самым толковый словарь терминов предметной области, использующихся в модели.

Рис.3 Словарь стрелок.

После создания контекстной диаграммы можно приступить к декомпозиции. Для этого нужно кликнуть по кнопке перехода на нижний уровень . Появляется диалог Activity Box Count, в котором необходимо указать количество работ на диаграмме декомпозиции (в дальнейшем можно будет добавить недостающие работы или удалить лишние) и нотацию диаграммы. BPwin позволяет создавать смешанные модели - в рамках одной модели могут сосуществовать и быть связанными модели IDEF0, DFD и IDEF3. Такой подход позволяет описать интересующие нас аспекты каждой подсистемы. Для обеспечения наглядности и лучшего понимания моделируемых процессов рекомендуется использовать от 3-х до 6-ти блоков на одной диаграмме. Остановимся пока на нотации IDEF0 и кликнем на OK. Появляется диаграмма декомпозиции. Работы расположены в так называемом порядке доминирования (по степени важности или в порядке очередности выполнения), начиная с левого верхнего угла и кончая нижним правым углом, что значительно облегчает в дальнейшем чтение диаграммы. Стрелки, которые были внесены на контекстной диаграмме, показываются и на диаграмме декомпозиции (миграция стрелок), но при этом не касаются работ. Такие стрелки называются несвязанными и воспринимаются, как синтаксическая ошибка. Для связывания стрелки необходимо перейти в режим редактирования стрелок, кликнуть по стрелке и кликнуть по соответствующему сегменту работы. Для связи работ между собой используются внутренние стрелки, т.е. стрелки, которые не касаются границы диаграммы, начинаются у одной и кончаются у другой работы.

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

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

  1. прямая связь по входу, когда стрелка выхода вышестоящей (далее просто выход) работы направляется на вход нижестоящей (например, на рисунке стрелка "Детали" связывает работы "Изготовление деталей" и "Сборка деталей");
  2. прямая связь по управлению, когда выход вышестоящей работы направляется на управление нижестоящей;
  3. обратная связь по входу, когда выход нижестоящей работы направляется на вход вышестоящей (стрелка "Брак");
  4. обратная связь по управлению, когда выход нижестоящей работы направляется на управление вышестоящей (стрелка "Рекомендации");
  5. связь выход-механизм, когда выход одной работы направляется на механизм другой.
Вновь внесенные граничные стрелки на диаграмме декомпозиции нижнего уровня изображаются в квадратных скобках и автоматически не появляются на диаграмме верхнего уровня. Для их "перетаскивания" наверх нужно сначала выбрать кнопку на палитре инструментов и кликнуть по квадратным скобкам граничной стрелки. Появляется диалог Border Arrow Editor.
Рис.5 Диалог Border Arrow Editor.
Если кликнуть по кнопке Resolve Border Arrow, стрелка мигрирует на диаграмму верхнего уровня, если по кнопке Change To Tunnel, стрелка будет затуннелирована и не попадет на другую диаграмму. Туннелирование может быть применено для изображения малозначимых стрелок.

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

Список синтаксических ошибок модели можно получить сгенерировав отчет об ошибках (Report / Model Consistency Report...).

Interface Ltd.

Ваши замечания и предложения направляйте по адресу: webmaster@interface.ru
Reklama.Ru. The Banner Network.