Построение модели IDEF0

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

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

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

Цель моделирования определяется из ответов на следующие вопросы:

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

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

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

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

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

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

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

Результат описания модели можно получить в отчете Model Report. Диалог настройки отчета по модели вызывается из пункта меню Tools/Reports/Model Report.

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

Работы (Activity) обозначают поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Работы изображаются в виде прямоугольников. Все работы должны быть названы и определены. Имя работы должно быть выражено отглагольным существительным, обозначающим действие (например, «Деятельность компании», «Прием заказа» и т.д.). При создании новой модели (меню File/New) автоматически создается контекстная диаграмма с единственной работой, изображающей систему в целом. Для внесения имени работы следует щелкнуть по работе правой кнопкой мыши, выбрать в меню Name Editor и в появившемся диалоге внести имя работы. Для описания других свойств работы служит диалог Activity Properties.

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

Стрелки (Arrow) описывают взаимодействие работ и представляют собой некую информацию, выраженную существительными. (Например, «Звонки клиентов», «Правила и процедуры», «Бухгалтерская система».)

В IDEF0 различают пять типов стрелок: Вход (Input), Управление (Control), Выход (Output), Механизм (Mechanism), Вызов (Call).

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

ICOM-коды. (аббревиатура от Input, Control, Output и Mechanism) – коды, предназначенные для идентификации граничных стрелок. Код ICOM содержит префикс, соответствующий типу стрелки (I, С, О или М), и порядковый номер. BPwin вносит ICOM-коды автоматически. Для отображения ICOM-кодов следует включить опцию ICOM codes на закладке Display диалога Model Properties (меню Model/Model Properties).

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

Явные стрелки. Явная стрелка имеет источником одну единственную работу и назначением тоже одну единственную работу.

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

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

Нумерация работ и диаграмм. Номер состоит из префикса и числа. Может быть использован префикс любой длины, но обычно используют префикс А. Контекстная (корневая) работа дерева имеет номер А0. Работы имеют номера Аi, начиная с А1. Работы декомпозиции нижнего уровня будут иметь номера А31, А32, АЗЗ, А34 и т. д. Такое дерево работ называют называют деревом узлов, а вышеописанную нумерацию – нумерацией по узлам.

Для создания диаграммы дерева узлов следует выбрать в меню пункт Diagram/Add Node Tree. Возникает диалог формирования диаграммы дерева узлов Node Tree Definition, где следует указать глубину дерева – Number of Levels и корень дерева.

Каркас диаграммы содержит заголовок (верхняя часть рамки) и подвал (нижняя часть). Заголовок каркаса используется для отслеживания диаграммы в процессе моделирования. Нижняя часть используется для идентификации и позиционирования в иерархии диаграммы.

Значения полей каркаса задаются в диалоге Diagram Properties (меню Diagram /Diagram Properties).

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

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

Разделение моделей производится аналогично. Для отщепления ветви от модели следует щелкнуть правой кнопкой мыши по декомпозированной работе и выбрать во всплывающем меню пункт Split Model. В появившемся диалоге Split Options следует указать имя создаваемой модели.

Создание отчетов в BPwin вызываются из пункта меню Report.

Диаграммы потоков данных (Data Flow Diagramming) являются основным средством моделирования функциональных требований к проектируемой системе. Требования представляются в виде иерархии процессов, связанных потоками данных. Диаграммы потоков данных показывают, как каждый процесс преобразует свои входные данные в выходные, и выявляют отношения между этими процессами. Они успешно используются для описания документооборота и обработки информации.

В BPwin для построения диаграмм потоков данных используется нотация Гейна-Сарсона.

Для того чтобы дополнить модель IDEF0 диаграммой DFD, нужно в процессе декомпозиции в диалоге Activity Box Count «кликнуть» по радио-кнопке DFD. В палитре инструментов на новой диаграмме DFD появляются новые кнопки:

• (External Reference) – добавить в диаграмму внешнюю ссылку;

• (Data store) – добавить в диаграмму хранилище данных;

• Diagram Dictionary Editor – ссылка на другую страницу.

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

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

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

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

Диаграмма является основной единицей описания в IDEF3. Единицы работы – Unit of Work (UOW) – также называемые работами (activity), являются центральными компонентами модели. В IDEF3 работы изображаются прямоугольниками с прямыми углами и имеют имя, выраженное отглагольным существительным, обозначающим процесс действия, одиночным или в составе фразы, и номер (идентификатор); другое имя существительное в составе той же фразы обычно отображает основной выход (результат) работы (например, «Изготовление изделия»).

Связи показывают взаимоотношения работ. Все связи в IDEF3 одно-направлены и могут быть направлены куда угодно, но обычно диаграммы IDEF3 стараются построить так, чтобы связи были направлены слева направо. В IDEF3 различают три типа стрелок, изображающих связи, стиль которых устанавливается через меню Edit/Arrow Style: Старшая (Precedence), Отношения (Relational Link), Потоки объектов (Object Flow).

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

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

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

Одним из наиболее эффективных инструментов имитационного моделирования является система ARENA, разработанная фирмой System Modeling Corporation. Система позволяет строить имитационные модели, проигрывать их и анализировать результаты.

Имитационная модель включает следующие основные элементы:

• Источники и стоки (Create и Dispose). Источники – это элементы, от которых в модель поступает информация или объекты. По смыслу они близки к понятиям «внешняя ссылка» или «объект ссылки».

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

• Процессы (Process) – это аналог работ в модели процессов. В имитационной модели может быть задана производительность процессов.

Построение модели производится путем переноса из панели инструментов в рабочее пространство модулей Create, Dispose и Process. Связи между модулями устанавливаются автоматически, но могут быть переопределены вручную. Далее модулям назначаются свойства. Для контроля проигрывания модели необходимо в модель добавить модуль Simulate и задать для него параметры. Результаты проигрывания модели отображаются в автоматически генерируемых отчетах.

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