Моделирование бизнеспроцессов средствами BPWin. стандарта IDEFO. декомпозиция и глоссарий.

Методология IDEF0 является развитием хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique).

IDEFO как стандарт был разработан в 1981 г. в рамках обширной программы автоматизации промышленных предприятий Integrated Computer Aided Manufacturing (ICAM) предложенной департаментом военно-воздушных сил США.

Со времени появления стандарт 1DEF0 претерпел несколько незначительных изменений, в основном, ограничивающего характера; последняя его редакция была выпущена в декабре 1993 г. Национальным институтом по стандартам и технологиям США (NIST).

Графический язык IDEF0 прост и гармоничен. В основе методологии лежат четыре основных понятия, первым из которых является понятие функционального блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника (рис. 2.7) и представляет собой некоторую конкре. функционального блока должно быть сформулировано в глагольном наклонении (например, «производить услуги», а не «производство услуг»).

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

• верхняя сторона имеет значение «Управление» (Control);

• левая сторона имеет значение «Вход» (Input);

• правая сторона имеет значение «Выход» (Output);

• нижняя сторона имеет значение «Механизм» (Mechanism).

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.

Третье основное понятие стандарта 1DEF0 — это декомпозиция (Decomposition). Декомпозиция применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

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

Модель IDEF0 всегда начинается с представления системы как единого целого — одного функционального блока с интер-фейсными дугами, входящими и выходящими за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой и обозначается идентификатором «АО». В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).

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

Диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы, и называется дочерней (Child diagram) по отношению к нему. Каждый из функциональных блоков, принадлежащих дочерней диаграмме, соответственно называется дочерним блоком — Child Box.

В свою очередь, функциональный блок «предок» называется родительским блоком (Parent Box) по отношению к дочерней диаграмме, а диаграмма, к которой он принадлежит, — родительской диаграммой (Parent Diagram).

Каждая из подфункций дочерней диаграммы может затем детализироваться с помощью аналогичной декомпозиции соответствующего ей функционального блока. В каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок или исходящие из него, фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEFO-модели. Наглядно принцип декомпозиции представлен на рис. 2.10 [3, 5, 7, 8, 11, 13]. Следует обратить внимание на взаимосвязь нумерации функциональных блоков и диаграмм — каждый блок имеет свой уникальный порядковый номер на диаграмме (цифра в правом нижнем углу прямоугольника), а обозначение под ним указывает на номер дочерней для этого блока диаграммы. Отсутствие этого обозначения говорит о том, что декомпозиция для данного блока не существует.

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

Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования. Обозначение «туннеля» (Arrow Tunnel) в виде двух круглых скобок у начала интерфейсной дуги означает, что эта дуга не была унаследована от функционального родительского блока и появилась (из «туннеля») только на этой диаграмме. В свою очередь, такое же обозначение у конца (стрелки) интерфейсной дуги рядом с блоком-приемником означает, что в дочерней по отношению к этому блоку диаграмме эта дуга не будет отображаться и рассматриваться. Чаще всего отдельные объекты и соответствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных уровнях иерархии, т. е. они сначала «погружаются в туннель», а затем при необходимости «возвращаются из туннеля».

Четвертое базовое понятие стандарта IDEF0 — глоссарий (Glossary). Для каждого из элементов IDEF0 (диаграмм, функциональных блоков, интерфейсных дуг) существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т. д., которые характеризуют объект, отображенный данным элементом. Такой набор называется глоссарием и является описанием сущности данного элемента. Например, для управляющей интерфейсной дуги «распоряжение об оплате» глоссарий может содержать перечень полей соответствующего дуге документа, необходимый набор виз и т. д. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой поясняющей информацией.

Обычно IDEFO-модели несут в себе сложную и концентрированную информацию, и для того, чтобы не перегружать их и сделать удобочитаемыми, в соответствующем стандарте приняты следующие принципиальные ограничения сложности:

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

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

 

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

Стандарт IDEF0 содержит набор процедур, позволяющих разрабатывать и согласовывать модель большим коллективом специалистов — профессионштов в разных областях деятельности. Обычно процесс разработки является итерационным и состоит из следующих условных этапов [3, 5, 7, 8, 11, 13|.

1. Создание модели группой специалистов из разных сфер деятельности предприятия. Эта группа в терминах IDEF0 называется авторами (Authors). Построение первоначальной модели является динамическим процессом, в течение которого авторы опрашивают компетентных лиц о структуре различных процессов. На основе имеющихся положений, документов и результатов опросов создается черновик (Model Draft) модели.

2. Распространение черновика для рассмотрения, согласований и комментариев. На этой стадии происходит обсуждение черновика модели с широким спектром компетентных лиц (в терминах IDEF0 — читателей) на предприятии. При этом каждая из диаграмм черновой модели письменно критикуется и комментируется, а затем передается автору. Автор, в свою очередь, также письменно соглашается с критикой или отвергает ее с изложением логики принятия решения и вновь возвращает откорректированный черновик на дальнейшее рассмотрение. Этот цикл продолжается до тех пор, пока авторы и читатели не придут к единому мнению.

3. 3. Официальное утверждение модели. Утверждение согласованной модели происходит руководителем рабочей группы в том случае, если у авторов модели и читателей отсутствуют разногласия по поводу ее адекватности. Окончательная модель представляет собой согласованное представление о предприятии (системе) с заданной точки зрения и для заданной цели.

4. Наглядность графического языка IDEF0 делает модель вполне читаемой и для лиц, не принимавших участия в ее создании, и эффективной для проведения показов и презентаций. В дальнейшем, на базе построенной модели могут быть организованы новые проекты, нацеленные на производство изменений на предприятии (в системе) [5].