Методика описания деловых процессов в рамках системы менеджмента качества

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

История возникновения методологии IDEF

Для описания процессов в мире разработано большое количество различных подходов и методов. В начале 70-х годов Д. Росс в США предложил метод структурного проектирования и анализа систем SADT (Structured Analysis and Design Techniques) [1]. В основе этого подхода лежит графический язык описания (моделирования) систем.

В середине 70-х ВВС США реализовали программу интегрированной компьютеризации производства ICAM (Integrated Computer Aided Manufacturing). В рамках этой программы были разработаны методы проектирования и анализа сложных производственных систем, а также способы обмена информацией между специалистами, занимающимися такими проблемами. Для удовлетворения этих потребностей в рамках программы ICAM была разработана методология IDEF (ICAM Definitions), позволяющая представить и исследовать структуру, параметры и характеристики производственно-технических и организационно-экономических систем. Процессы, описывающие деятельность организации, относятся именно к этому классу систем.

В настоящее время общая методология IDEF включает ряд частных методологий для моделирования систем, в том числе:

– IDEF0 – функциональное моделирование;

– IDEF1 – информационное моделирование;

– IDEF1X – моделирование данных;

– IDEF3 – моделирование «потока» процессов;

– IDEF4 – объектно-ориентированное проектирование и анализ;

– IDEF5 – определение онтологий (словарей);

– IDEF9 – моделирование требований.

 

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

Основу IDEF0 методологии по [2] и [3] составляет простой и понятный графический язык описания деловых процессов, который базируется на двух основных понятиях и трех принципах:

  • Функциональный блок

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

глагол + объект действия + [дополнение]. Например, «Производить продукцию», «Обрабатывать записи качества» и т.д.

 

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

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

– левая сторона обозначает входы, т.е. что поступает на вход процесса (функции) и будет преобразовано;

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

– верхняя сторона – управление, т.е. при каких условиях процесс исполняется;

– нижняя сторона – механизм, т.е. какие ресурсы необходимы для исполнения процесса (функции).

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

  • Взаимодействия между процессами (интерфейсные дуги)

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

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

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

  • Принцип декомпозиции

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

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

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

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

На рис. 2 представлен пример декомпозиции процесса.

 

Диаграмма самого верхнего уровня иерархии – А-0, описывает наиболее общее представление моделируемой системы. Она является родителем для диаграммы А0.

Диаграмма А0 является декомпозицией (диаграммой-потомком)  для А-0 и дает более детальное представление функции в блоке 0.

 

Декомпозированный блок 3 является родительским для диаграммы А3.

Диаграмма А3 является декомпозицией блока 3 диаграммы А0 и иллюстрирует внутреннее содержание блока на родительской диаграмме.

Декомпозированный на диаграмме А3   блок 1 является родительским для диаграммы А31.

Диаграмма А31, являясь декомпозицией блока 1 диаграммы А3, наиболее детально описывает содержание функции, представленной на родительской диаграмме, учитывая при этом контекст всей модели.

Рис.2 – Декомпозиция функциональных блоков

 

  • Принцип ограничения сложности

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

  • Принцип контекстной диаграммы.

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

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

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