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

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

Наиболее удобным языком моделирования бизнес-процессов является IDEF0, предложенный более 20 лет назад Дугласом Россом (Soft Tech, Inc.) и называвшийся первоначально SADТ – Structured Analysis Design Technique. (Подробно методология 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 в BP-win следует выбрать пункт меню Edit\Model Properties, вызывающий диалог Model Properties (рис. 1.3). В закладке Purpose следует внести цель и точку зрения, а в за­кладку Definition - определение модели и описание области.

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

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

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

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

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

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

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

Рис 1.4. Отчет по модели

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

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

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

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

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

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

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

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

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