Б1 Методология структурного анализа и проектирования IDEF0

Известная методология IDEF0 разработана на основе методологии SADT (Structured Analysis and Design Technique) и представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями.

Принципы моделирования в IDEF0

В IDEF0 реализованы три базовых принципа моделирования процессов:

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

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

- принцип контекстной диаграммы. Моделирование делового процесса начинается с построения контекстной диаграммы. На этой диаграмме отображается только один блок - главная бизнес-функция моделируемой системы. Если речь идет о моделировании целого предприятия или даже крупного подразделения, главная бизнес-функция не может быть сформулирована как, например, “продавать продукцию”. Главная бизнес-функция системы - это “миссия” системы, ее значение в окружающем мире. Нельзя правильно сформулировать главную функцию предприятия, не имея представления о его стратегии. При определении главной бизнес- функции необходимо всегда иметь ввиду цель моделирования и точку зрения на модель. Одно и то же предприятие может быть описано по-разному, в зависимости от того, с какой точки зрения его рассматривают: директор предприятия и налоговой инспектор видят организацию совершенно по-разному. Контекстная диаграмма играет еще одну роль в функциональной модели. Она “фиксирует” границы моделируемой бизнес- системы, определяя то, как моделируемая система взаимодействует со своим окружением. Это достигается за счет описания дуг, соединенных с блоком, представляющим главную бизнес-функцию.

В основе методологии IDEF0 лежат следующие правила:

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

- с дугами связаны надписи (или метки) на естественном языке, описывающие данные, которые они представляют;

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

- выходы одной функции могут быть Входами, Управлением или Исполнителями для другой;

- дуги могут разветвляться и соединяться;

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

Основные элементы и понятия IDEF0

Модель IDF0 состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга.

Диаграммы- главные компоненты модели, все функции информационной системы (ИС) и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса.

Функциональный блок (Activity Box). Функциональный блок графически изображается в виде прямоугольника (рисунок Б1.1) и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, “производить услуги”, а не “производство услуг”).

Рисунок Б1.1 – Функциональный блок

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

- Control (Управление). Стрелки сверху означают на основании чего выполняется данный процесс - законы, стандарты, приказы и т.д.;

- Input(Вход). Стрелки слева - данные или объекты, используемые или изменяемые процессом;

- Output(Выход). Стрелки справа - основные результаты деятельности процесса, конечные продукты;

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

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

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

Существует два вида дуг:

- внутренние (присоединяющиеся) – концы соединяются с блоками диаграмм;

- граничные – один конец которой является внешним.

Граничные дуги кодируются с помощью ICOM-кода (Input, Output, Control, Mechanism).

Входы нумируются сверху вниз в порядке присоединения (I).

Управление кодируется слева направо в порядке присоединения(С).

Выходные дуги кодируются сверху вниз в порядке присоединения(О1).

Механизм кодируется слева направо в порядке присоединения (М).

Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного.

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

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

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

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

Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой,и обозначается идентификатором«А-0».

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

Для глоссариев в конце приписывается буква G. Для текстовых узлов - буква T.

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

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

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

Разработка моделей деятельности предприятия в стандарте IDEF0

При проведении обследования предприятий разработка моделей в стандарте IDEF0 позволяет наглядно и эффективно отобразить деятельность предприятия.

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

- что поступает в подразделение “на входе”?

- какие функции, и в какой последовательности выполняются в рамках подразделения?

- кто является ответственным за выполнение каждой из функций?

- чем руководствуется исполнитель при выполнении каждой из функций?

- что является результатом работы подразделения (на выходе)?

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

Для практического удобства моделирования бизнес-процессов (БП) предприятия может быть предложена следующая интерпретация исходных примитивов стандарта IDEF0 (рисунок Б1.2).

Рисунок Б1.2 – Общая модель БП

Общая модель БП базируется на следующих положениях:

- все "Работы" принадлежат одному классу, т.е. обладают одинаковым набором свойств и поведением;

- все связи между "Работами" относятся к классу "Ресурс". Например, электронное издание "Налогового кодекса РФ" является общедоступным информационным ресурсом;

- для однозначной "привязки" ресурсов к трем возможным входам БП на множестве "Ресурсов" вводится следующая классификация:

- "Ресурсы", подлежащие трансформации в другие виды "Ресурсов";

- нетрансформируемые "Ресурсы":

- неизнашиваемые "Ресурсы". Например, большая часть информационных "Ресурсов" в электронной форме являются неизнашиваемыми;

- изнашиваемые (устаревающие) "Ресурсы". Например, вспомогательные инструменты, персонал;

- признак блокировки "Ресурса" "Работой", исключающий возможность использования "Ресурса" другими "Работами":

- "Ресурсы", которые не могут блокироваться "Работами" ("Ресурсы" общего пользования)

- блокируемые "Ресурсы"

- исполнение "Работы" безусловно инициируется событием "Поступление Ресурса". Это соответствует классическим представлениям о том, что любое воздействие влечет реакцию. Не бывает воздействий без рефлексии на него. Это аксиома. Поэтому поступление любого ресурса является управляющим воздействием;

- необходимым (но не достаточным!) условием завершение "Работы" является свершение полного набора событий "Поступление Ресурса", связанных с интерфейсами "Работы".

Структура предложенной модели БП соответствует современным представлениям о структуре систем, в том числе и систем управления. На рисунке Б1.3 представлена универсальная IDEF0-модель БП, в которой показана сущность интерфейсов «Работы»:

- на вход БП поступают с выходов БП-контрагентов ресурсы, которые преобразуются в БП в другие виды ресурсов, поставляемые БП-контрагентам;

- все БП в организации объединены одной задачей - оказанием услуг друг другу на основе анализа запросов о поставке услуг. В частности услугой может быть изготовление и поставка продукта;

- оказание услуг друг другу БП осуществляют согласно единой для всех БП процедуре.

При декомпозиции БП на составляющие сначала следует создавать промежуточную IDEF0-диаграмму, на которой изображены <Работы> - входные и выходные интерфейсы БП и <Работа>, отражающая сущность БП.

Рисунок Б1.3 – Универсальная модель БП