Методологии IDQF

Понятие «моделирование бизнес-процессов» стало использо-аться аналитиками после появления сложных программных про-

Интегрированные автоматизированные системы управления предприятием ЧАС ТЬ III дуктов, предназначенных для комплексной автоматизации управ­ления предприятием. Подобные системы всегда подразумевают проведение глубокого предпроектного обследования деятельности компании или предприятия. Результатом этого обследования является экспертное заключение, в котором отдельными пунктами выносятся рекомендации по устранению «узких мест» в управлении. На осно­вании этого заключения непосредственно перед проектом внедрения системы автоматизации проводится так называемая реорганизация бизнес-процессов, иногда достаточно серьезная и болезненная. Для решения подобных задач моделирования сложных систем существуют хорошо отработанные методологии и стандарты. К таким стандартам относятся методологии семейства IDEF, являющиеся государственным стандартом в США.

IDEF-методологии создавались в рамках предложенной ВВС США программы компьютеризации промышленности, в ходе реализации ко­торой выявилась потребность в разработке методов анализа процес­сов взаимодействия в производственных (промышленных) системах.

Особенностью рассматриваемого семейства методологий является:

• уникальная способность задавать вопросы в процессе модели­рования;

• неразрывная связь графических средств (нотации), методологии и технологии.

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

Перечислим наиболее распространенные стандарты семейства IDEF:

• IDEF0. Методология функционального моделирования, позволя­ющая с помощью наглядного графического языка предоставить бизнес-систему в виде набора взаимосвязанных функций (функ­циональных блоков);

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

• IDEF1X (IDEF1 Extended). Методология построения реляционных структур, которая относится к типу методологий «сущность-вза­имосвязь» и, как правило, используется для моделирования ре-

p-rj^~26___________________________ Моделирование бизнес-процессов

ляционных баз данных, имеющих отношение к рассматриваемой бизнес-системе;

• IDEF2. Методология динамического моделирования развития си­стем. Компьютерные алгоритмы позволяют превращать набор статических диаграмм IDEF0 в динамические модели, построен­ные на базе «раскрашенных сетей Петри» (Color Petri Nets);

• IDEF3. Методология документирования процессов, позволяющая описывать сценарий и последовательность операций для каждо­го процесса. IDEF3 имеет прямую взаимосвязь с методологией IDEF0 - каждая функция может быть представлена в виде отдель­ного процесса средствами IDEF3;

• IDEF4. Методология построения объектно-ориентированных си­стем, средства которой позволяют наглядно отображать структу­ру объектов и заложенные принципы их взаимодействия;

• IDEF5. Методология онтологического исследования сложных си­стем, позволяющая описать с помощью определенного словаря терминов и правил состояние бизнес- системы в некоторый мо­мент времени.

IDEFO

Основные понятия

Так как на практике наиболее часто используется методология IDEFO, то более подробно остановимся на ее представлении. Эту ме­тодологию принято считать последовательницей графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique). IDEFO как стандарт был разработан в 1981 году в рамках программы автоматизации промышленных предприятий ICAM (Integ­rated Computer Aided Manufacturing) и, как уже упоминалось выше, предлагался для ВВС. С 1981 года IDEFO претерпела несколько не­значительных изменений, и последняя его редакция была выпущена в конце 1993 года.

Основу методологии IDEFO составляют четыре основных понятия:

• функциональный блок. Графически изображается в виде прямо­
угольника и определяет конкретную функцию для рассматрива­
емой системы. При этом каждый функциональный блок должен
иметь свой уникальный идентификационный номер. Каждая из
четырех сторон функционального блока имеет своё определен­
ное значение. Верхняя сторона имеет значение «Управление»

Ц27

Интегрированные автоматизированные системы управления предприятием ЧАСТЬ III

(Control), левая сторона - «Вход» (Input), правая сторона - «Выход» (Output) и нижняя сторона - «Механизм» (Mechanism) (рис. 26.1);

Рис. 26.1. Функциональный блок

интерфейсная дуга [потоки, стрелки). С помощью интерфейс­ных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе. Такими объ­ектами могут быть элементы реального мира (детали, сотрудники и т. д.) или потоки данных и информации (документы, данные и т. д.). Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование, которое, по требованию стандарта, должно быть оборотом существительного. В зависи­мости от того, к какой из сторон функционального блока подхо­дит данная интерфейсная дуга, она носит название «входящей», «исходящей» или «управляющей». Кроме того, «источником» (началом) и «приемником» (концом) каждой функциональной дуги могут быть только функциональные блоки, при этом «источ­ником» - может быть только выходная сторона блока, а «прием­ником» любая из трех оставшихся. Любой функциональный блок по требованиям стандарта должен иметь, по крайней мере, одну управляющую интерфейсную дугу и одну исходящую; декомпозиция. Принцип декомпозиции применяется при раз­биении сложного процесса на составляющие его функции (рис. 26.2). Декомпозиция позволяет постепенно и структуриро­вано представлять модель системы в виде иерархической струк­туры отдельных диаграмм. В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения

Гяава26_

Моделирование бизнес-процессов

диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint). Цель определяет соответствующие области в исследуемой системе, на которых необходимо фокусировать­ся в первую очередь, а точка зрения - основное направление развития модели и уровень необходимой детализации. Для того, чтобы не перегружать диаграммы и не делать их сложными для восприятия, в 1DEF0 предусмотрено туннелирование, которое обозначается в виде двух круглых скобок вокруг начала интер­фейсной дуги. Это указывает на то, что обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из «туннеля») только на этой диаграмме;

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

Дата добавления: 2015-12-08