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

Лекция 4. Создание модели в стандарте IDEF0

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

Работы (Activity)

Стрелки (Arrows)

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

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

Наиболее удобным языком моделирования бизнес-процессов является IDEF0, предложенный Дугласом Россом (SoftTech, Inc.) и называвшийся первоначально SADT - Structured Analysis and Design Technique.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для задания цели моделирования, точки зрения и иных свойств модели предназначен диалог Model Properties (меню Model → Model Properties) (рис. 1).

Рис. 1. Диалог Model Properties

Закладка General служит для внесения имени модели и проекта, имени и инициалов автора и временных рамок модели - AS-IS и ТО-ВЕ.

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

В закладке Numbering задаются правила нумерации функциональных блоков.

В закладке Display задается список элементов отображаемых на диаграммах.

Закладка Layout задает параметры расположения объектов на диаграмме.

Закладка ABC Units задает единицы функционально-стоимостного анализа.

PageSetup – закладка, на которой задаются параметры страницы.

Header /Footer – закладка, на которой задаются опции заголовка и нижнего колонтитула каркаса.

В закладке Shapes устанавливаются виды фигур для объектов диаграмм по умолчанию.

DrawStyle - закладка, на которой задаются опции графического стиля.

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

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

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

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

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

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

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

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

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