Методологии idef ( integrated definitions ) для анализа и реинжиниринга бизнес-процессов ( BPR )

Применение методологий IDEF в BPR

Стандарты IDEF0 и IDEF1X, регламентирующие функциональное и информационное описание больших систем, были разработаны Министерством обороны США для собственных нужд, а уже впоследствии стали достоянием гражданских отраслей, также нуждающихся в методах анализа маркетинга, проектирования, производства и эксплуатации в их взаимосвязи. При этом стандарты моделирования IDEF/0/1X продолжают развиваться и использоваться как для проектирования, так и для анализа и реинжиниринга больших организационных структур, корпораций, финансово-промышленных групп, вовлеченных в поддержку жизненного цикла некоторого продукта или изделия.

Другой причиной развития данного подхода стали требования стандартов ISO 9000, касающиеся качества продукции и услуг и их международной сертификации, которые также нуждаются в сертификации «производственных» процессов. Таким образом, электронное документирование процессов в организации стало необходимым условием ее конкурентоспособности на рынке.

Модель IDEF представляет собой структурированное изображение функций производственной системы или среды, информации и объектов, связывающих эти функции (рис. 3). Модель отражает деятельность организации и дает ясное представление об информации, перерабатываемой каждой функцией, о том, как и почему это делается, сообщает об ограничениях. Модель строится методом декомпозиции от крупных составных структур к более мелким конкретным. Выделяют уровни декомпозиции: уровень задач — уровень функций — уровень подфункций — уровень операций — уровень переходов. Каждый уровень содержит одноименные элементы декомпозиции (уровень задач — задачи, уровень функций — функции и т. д.). Элементу декомпозиции (узлу модели)*соответствуют четыре характеристики: вход — выход — условие — используемые ресурсы (обозначаемые в терминах как IDEF-механизмы (М)).

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

На основе функциональной модели и технологии АВС-анализа (Activity Based Costing) множеству действий (переходов, операций, подфункций, функций) ставится в соответствие множество значений затрат. Таким образом, совокупность моделей IDEF0 и ABC представляет собой бизнес-описание производственной деятельности, в котором для каждой функции, подфункции или операции указываются затраты на ее выполнение.

Рис. 3 Представление декомпозиции бизнес-процесса в виде IDEF-диаграммы

 

Основы методологии IDEF 1

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

— выяснить структуру и содержание существующих потоков информации на предприятии;

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

—выявить информационные потоки, требующие дополнительного управления для эффективной реализации модели.

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

—определения самой информации и структуры ее потоков, имеющих отношение к деятельности предприятия;

—определение существующих правил и законов, по которым осуществляется движение информационных потоков, а также принципов управления ими;

—выяснение взаимосвязей между существующими информационными потоками в рамках предприятия;

—выявление.проблем, возникающих вследствие недостатка качественного информационного менеджмента.

Результаты анализа информационных потоков могут быть использованы для стратегического и тактического планирования деятельности предприятия и улучшения информационного менеджмента.

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

Методология IDEF1 позволяет на основе простых графических изображений моделировать информационные взаимосвязи и различия между:

реальными объектами;

физическими и абстрактными зависимостями, существующими среди реальных объектов;

информацией, относящейся к реальным объектам; структурой данных, используемой для приобретения, накопления, применения и управления информацией.

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

При построении информационной модели проектировщик всегда оперирует двумя основными глобальными областями, каждой из которых соответствует множество характерных объектов. Первой из этих областей является реальный мир, т.е. совокупность физических и интеллектуальных объектов, таких как люди, места, вещи, идеи и т. д., а также все свойства этих объектов и зависимости между ними. Вторая область — информационная — включает в себя существующие информационные отображения объектов первой области и их свойств. Информационное отображение, по существу, не относится к объектам реального мира, однако изменение его, как правило, является следствием некоторого изменения соответствующего ему реального объекта. Методология IDEF1 разработана как инструмент для исследования статического соответствия вышеуказанных областей и установления строгих правил и механизмов изменения объектов информационной области при изменении соответствующих им объектов реального мира.

Методология IDEF1 разделяет элементы структуры информационной области, их свойства и взаимосвязи на классы. Центральным понятием в ней служит понятие сущности. Класс сущностей представляет собой совокупность информации, накопленной и хранящейся в рамках предприятия и соответствующей определенному объекту или группе объектов реального мира. К основным концептуальным свойствам сущностей в IDEF1 относятся:

Устойчивость. Информация, имеющая отношение к той или иной сущности, постоянно накапливается.

Уникальность. Любая сущность может быть однозначно идентифицирована из другой сущности.

Каждая сущность имеет свое имя и атрибуты. Атрибуты представляют собой характерные свойства и признаки объектов реального мира, относящихся к определенной сущности. Класс атрибутов — это набор пар, состоящих из имени атрибута и его значения для определенной сущности. Атрибуты, по которым можно однозначно отличить одну сущность от другой, называются ключевыми. Каждая сущность может характеризоваться несколькими ключевыми атрибутами. Класс взаимосвязей в IDEF1 представляет собой совокупность взаимосвязей между сущностями. Взаимосвязь между двумя отдельными сущностями считается существующей в том случае, если класс атрибутов одной сущности содержит ключевые атрибуты другой сущности. Каждый из описанных классов имеет свое условное графическое отображение согласно методологии IDEF1.

В заключение отметим, что стандарт IDEF1 является методом изучения и анализа, в отличие от очень сходного по терминологии и семантике стандарта IDEF1X.

Основы методологии IDEF 1 X

IDEF1X является методом для разработки реляционных баз данных и использует условный синтаксис, специально разработанный для удобного построения концептуальной схемы. Концептуальной схемой называют универсальное представление структуры данных в рамках коммерческого предприятия, независимое от конечной реализации базы данных и аппаратной платформы. Будучи статическим методом разработки, IDEF1X изначально не предназначен для динамического анализа по принципу «AS IS». Тем не менее он иногда применяется в этом качестве как альтернатива методу IDEF1, особенно при построении логической структуры базы данных после того, как все информационные ресурсы исследованы (скажем, с помощью метода IDEF1) и принято решение о внедрении реляционной базы данных как части корпоративной информационной системы. Однако не стоит забывать, что средства моделирования IDEF1X специально разработаны для построения реляционных информационных систем и для проектирования другой системы, скажем, объектно-ориентированной, лучше избрать другие методы моделирования.

Известно несколько очевидных причин, по которым IDEF1X не следует применять в случае построения нереляционных систем. Во-первых, IDEF1X требует от проектировщика определить ключевые атрибуты для того, чтобы отличить одну сущность от другой, в то время как объектно-ориентированные системы не требуют этого. Во-вторых, в тех случаях, когда сущность однозначно идентифицируется не одним атрибутом, а несколькими, проектировщик должен определить один из этих атрибутов первичным ключом, а все остальные — вторичными. Построенная проектировщиком и переданная для окончательной реализации программисту IDEFIX-модель является некорректной для применения методов объектно-ориентированной реализации и предназначена для построения реляционной системы.

Хотя терминология IDEF1X практически совпадает с терминологией IDEF1, в теоретических концепциях этих методологий имеет место ряд фундаментальных отличий. В IDEF1X сущность описывает совокупность или набор экземпляров, похожих по свойствам, но однозначно отличаемых по одному или нескольким признакам. Каждый экземпляр является реализацией сущности. Таким образом, сущности в IDEF1X соответствует конкретный набор экземпляров реального мира, в отличие от сущности в IDEF1, которая представляет собой абстрактный набор информационных отображений реального мира. Примером сущности IDEF1X может быть сущность «сотрудник», которая представляет собой всех сотрудников предприятия, а один из них, скажем, Иванов Петр Сергеевич, является конкретной реализацией этой сущности. Каждый экземпляр сущности «сотрудник» содержит следующую информацию: ID сотрудника, имя сотрудника, адрес сотрудника и т. п. В IDEFlX-модели эти свойства называются атрибутами сущности. Каждый атрибут содержит только часть информации о сущности.

Связи между сущностями. Связи в IDEF1X представляют собой ссылки, соединения и ассоциации между сущностями. Связи — это суть глаголы, которые показывают, как соотносятся сущности между собой. Приведем ряд примеров связи между сущностями:

Отдел <состоит из> нескольких сотрудников.

Самолет <перевозит> нескольких пассажиров.

Сотрудник <пишет> разные отчеты.

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

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

Сущность описывается в диаграмме IDEF1X графическим объектом в виде прямоугольника. Каждый прямоугольник, отображающий собой сущность, разделяется горизонтальной линией на часть, в которой расположены ключевые поля, и часть, где расположены неключевые поля. Верхняя часть называется ключевой областью, а нижняя часть — областью данных. В ключевой области объекта «сотрудник» находится поле «Уникальный идентификатор (ID) сотрудника», в области данных — поля «Имя сотрудника», «Адрес сотрудника», «Телефон сотрудника» и т. д.

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

При создании сущности в IDEFlX-модели одним из главных вопросов, на который нужно ответить, является: «Как можно идентифицировать уникальную запись?». Чтобы правильно создать логическую модель данных, требуется уникальная идентификация каждой записи. Напомним, что сущности в IDEF1X всегда имеют ключевую область и поэтому для каждой из них должны быть определены ключевые атрибуты.

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

Например, для того, чтобы корректно использовать сущность «сотрудник» в IDEFlX-модели данных (а позже в базе данных), необходимо иметь возможность уникально идентифицировать записи. Правила, по которым выбирается первичный ключ из списка предполагаемых ключей, очень строги, однако они могут бить применены ко всем типам.баз данных и информации. Правила устанавливают, что атрибуты и группы атрибутов должны:

—уникальным образом идентифицировать экземпляр сущности;

—не использовать нулевых значений;

—не изменяться со временем. Экземпляр идентифицируется при помощи ключа. При изменении ключа соответственно меняется экземпляр;

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

Для наглядного представления о том, как целесообразно выбирать первичные ключи, рассмотрим этот процесс для знакомой нам сущности «сотрудник»:

—атрибут «ID сотрудника» является потенциальным ключом, так как он уникален для всех экземпляров сущности «сотрудник»;

—атрибут «Имя сотрудника» не очень хорош для потенциального ключа, так как среди служащих на предприятии могут быть, к примеру, два Петровых;

—атрибут «Номер страхового полиса сотрудника» уникален, но проблема в том, что сотрудник может не иметь такового;

—комбинация атрибутов «имя сотрудника» и «дата рождения сотрудника» может оказаться удачной для наших целей и стать искомым потенциальным ключом.

После проведенного анализа можно назвать два потенциальных ключа — это «Номер сотрудника» и комбинация, включающая поля «Имя сотрудника» и «Дата рождения сотрудника». Так как атрибут «Номер сотрудника» имеет самые короткие и уникальные значения, то он лучше других подходит для первичного ключа.

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

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

Если сущности в IDEFlX-диаграмме связаны, связь передает ключ (или набор ключевых атрибутов) дочерней сущности. Эти атрибуты, называемые внешними ключами, определяются как атрибуты первичных ключей родительского объекта, переданные дочернему объекту через их связь. Передаваемые атрибуты называются мигрирующими.

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

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

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

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

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

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

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

Тем не менее взаимосвязь может отражать зависимость существования, если внешний ключ не может принимать значение нуль. Если внешний ключ должен существовать, то это означает, что запись в дочерней сущности может быть только при наличии ассоциированной с ним родительской записи.

Основным преимуществом IDEF1X, по сравнению с другими многочисленными методами разработки реляционных баз данных, такими как ER и ENALIM, является жесткая и строгая стандартизация моделирования. Установленные стандарты позволяют избежать различной трактовки построенной модели, которая, несомненно, считается значительным недостатком ER.

Основы методологии IDEF 3

IDEF3 — стандарт документирования технологических процессов, происходящих на предприятии, и предоставляет инструментарий для наглядного исследования и моделирования их сценариев. Сценарием (Scenario) мы называем описание последовательности изменений свойств объекта в рамках рассматриваемого процесса (например, описание последовательности этапов обработки детали

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

—документировать имеющиеся данные о технологии процесса, выявленные, скажем, в процессе опроса компетентных сотрудников, ответственных за организацию рассматриваемого процесса;

—определять и анализировать точки влияния потоков сопутствующего документооборота на сценарий технологических процессов;

—определять ситуации, в которых требуется принятие решения, влияющего на жизненный цикл процесса, например измененить конструктивные, технологические или эксплуатационные свойства конечного продукта;

—содействовать принятию оптимальных решений при реорганизации технологических процессов;

—разрабатывать имитационные модели технологических процессов по принципу «как будет, если...».

В стандарте IDEF3 существуют два типа диаграмм, представляющих описание одного и того же сценария технологического процесса в разных ракурсах. Относящиеся к первому типу называются диаграммами описания последовательности этапов процесса (Process Flow Description Diagrams, PFDD), а ко второму — диаграммами состояния объекта и его трансформаций в процессе (Object State Transition Network, OSTN). Предположим, требуется описать процесс окраски детали в производственном цехе на предприятии. С помощью диаграмм PFDD документируются последовательность и описание стадий обработки детали в рамках исследуемого технологического процесса. Диаграммы OSTN используются для иллюстрации трансформаций детали на каждой стадии обработки.

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

Каждый функциональный блок UOB может иметь последовательность декомпозиций и, следовательно, может быть детализирован с любой необходимой точностью. Под декомпозицией понимают представление каждого UOB с помощью отдельной IDEF-диаграммы. Например, можно декомпозировать UOB «окрасить деталь», представив его отдельным процессом и построив для него свою PFDD-диаграмму, которая будет называться дочерней по отношению к изображенной на рис. 9.13, а та, соответственно, родительской. UOB дочерних диаграмм имеют сквозную нумерацию, т. е. если родительский UOB имеет номер 1, то блоки UOB на его декомпозиции будут, соответственно, иметь номера 1.1, 1.2 и т. д. Применение принципа декомпозиции в IDEF3 позволяет структурировано описывать процессы с любым требуемым уровнем детализации.

Если диаграммы PFDD позволяют рассматривать технологический процесс «с точки зрения наблюдателя», то другой класс диаграмм IDEF3—OSTN — позволяет рассматривать тот же самый процесс «с точки зрения объекта». На рис. 9.14 представлено отображение процесса окраски с точки зрения OSTN-диаграммы. Состояния объекта (в нашем случае детали) и изменения состояния являются ключевыми. Состояния объекта отображаются окружностями, а их изменения — направленными линиями. Каждая линия имеет ссылку на соответствующий функциональный блок UOB, в результате которого произошло отображаемое ею изменение состояния объекта.