Принципы построения модели IDEF0

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

Наиболее удобным языком моделирования бизнес-процессов является
IDEF0, предложенный более 20 лет назад Дугласом Россом (SoftTech, Inc.)
и называвшийся первоначально SADT - Structured Analysis and Design Tech-
nique. (Подробно методология SADT излагается в книге Дэвида А. Марка
и Клемента Мак-Гоуэна "Методология структурного анализа и проектиро-
вания SADT" (М.: Метатехнология, 1993.) В начале 70-х годов вооруженные
силы США применили подмножество SADT, касающееся моделирования
процессов, для реализации проектов в рамках программы ICAM (Integrated
Computer-Aided Manufacturing). В дальнейшем это подмножество SADT бы-
ло принято в качестве федерального стандарта США под наименованием
IDEF0. Подробные спецификации на стандарты IDEF можно найти на сайте
http: //www. idef. com.

В IDEF0 система представляется как совокупность взаимодействующих
работ или функций. Такая чисто функциональная ориентация является
принципиальной - функции системы анализируются независимо от объек-

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

Под моделью в IDEF0 понимают описание системы (текстовое и графичес-
кое), которое должно дать ответ на некоторые заранее определенные вопросы.

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

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

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

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

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

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

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

• Что может получить читатель?

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

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

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

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

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

источников. Полученная модель AS-IS служит для выявления неуправляе-
мых работ, работ не обеспеченных ресурсами, ненужных и неэффективных
работ, дублирующихся работ и других недостатков в организации деятель-
ности предприятия. Исправление недостатков, перенаправление информа-
ционных и материальных потоков приводит к созданию модели ТО-ВЕ
(Как будет) - модели идеальной организации бизнес-процессов. Как прави-
ло, строится несколько моделей ТО-ВЕ, среди которых определяют наи-
лучший вариант (см. 1. 2. 2). Выбор оптимальной модели может осуществ-
ляться, например, с помощью метрик BPwin (см. 1. 3).

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

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

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

Результат описания модели можно получить в отчете Model Report. Диа-
лог настройки отчета по модели вызывается из пункта меню Tools/Re-
ports/Model Report. В диалоге настройки следует выбрать необходимые
поля, при этом автоматически отображается очередность вывода информа-
ции в отчете (рис. 1. 2. 3).

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

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

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

диаграмма);

• декомпозиции;

• дерева узлов;

• только для экспозиции (FEO).

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

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

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