Методика и порядок работ по определению, классификации и идентификации


с. 1 ... с. 2 с. 3 с. 4 с. 5

6ПОРЯДОК ПРОВЕДЕНИЯ РАБОТ ПО ОПРЕДЕЛЕНИЮ, КЛАССИФИКАЦИИ И ИДЕНТИФИКАЦИИ ПРОЦЕССОВ

6.1Общие положения


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

На Рис. 16 представлена модель процесса определения, классификации и идентификации процессов.

Определение, классификация и идентификация как процесс включает следующие процессы:


  • сбор информации об исследуемом процессе;

  • документирование полученной информации;

  • представление информации в виде модели;

  • классифицировать процессы в рамках модели;

  • уточнение модели посредством итеративного рецензирования, принять и утвердить.

6.2Подготовительный этап


Определение, классификация и идентификация процессов следует начать с подготовительного этапа, который включает:

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

  • Формирование рабочей группы из числа сотрудников организации и/или привлеченных специалистов.

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

6.3Порядок создания модели

6.3.1Сбор информации


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

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


6.3.2Документирование полученной информации


На этом этапе происходит создание моделей процессов. Разработчик документирует полученные им знания об изучаемых процессах, представляя их в виде одной или нескольких IDEF0-диаграмм.

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

Пример диаграммы А-0 представлен на Рис. 5 настоящего документа.

Рис. 16. Определение, классификация и идентификация процессов


6.3.3Построение Диаграмм


Хотя вершиной модели является Диаграмма уровня А-0, настоящей “рабочей вершиной” является Диаграмма А0, поскольку она является уточненным выражением точки зрения модели. Ее содержание показывает, что будет рассматриваться в дальнейшем, ограничивая последующие уровни в рамках цели модели. Нижние уровни уточняют структуру и содержание моделируемого процесса, детализируя его, но не расширяя его границ.

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


Пример диаграммы А0 представлен на Рис. 6 настоящего документа.
При детализации, декомпозируя каждый блок Диаграммы А0, необходимо более подробно отражать то, что представлено на родительском блоке. Это может потребовать дополнительного сбора информации о моделируемой системе. Поэтому, сделав предварительный эскиз диаграммы-потомка, необходимо перечислить все объекты и уточнить перечень процессов, выполнение которых обеспечит выполнение рассматриваемого процесса, описанного родительским блоком.

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

Примечания:

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

2. В глоссарии дается описание терминов и понятий, использованных при построении диаграммы. Наличие глоссария очень важно, поскольку используемые термины могут иметь совершенно другой смысл в другом контексте.

6.3.4Проверка корректности модели


Одной из основных компонент методологии моделирования IDEF0 является итеративное рецензирование, в процессе которого разработчик и эксперт многократно совещаются (устно и письменно) относительно достоверности создаваемой модели. Итеративное рецензирование называется циклом «разработчик/эксперт».

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

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

Примечания:

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

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


6.4Порядок классификации процессов


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

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

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

6.5Порядок идентификации процессов


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

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

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

6.6Порядок утверждения моделей


Следует помнить, что IDEF0-модели создаются с конкретной целью, и эта цель записана на диаграмме А-0 модели. В каком-то смысле эта цель определяет, как будет использоваться модель. Таким образом, как только завершено создание модели с требуемым уровнем детализации, и модель проверена, она может применяться для достижения поставленной цели.

Например, модель «Производить женские пальто» создана для описания деятельности сотрудников швейной фабрики. Если эта модель точно описывает работу персонала на фабрике, но не может служить для анализа и улучшения процесса – она бесполезна.

В процессе IDEF0-моделирования рекомендуется выделить специальную группу людей, ответственных за то, что создаваемая в процессе анализа модель будет точна и используема в дальнейшем. Эта группа отвечает за контроль качества моделей, создаваемых разработчиками проекта. Рабочая группа следит за выполняемой работой и ее соответствием конечным целям всего проекта. Члены рабочей группы обсуждают модель и оценивают, насколько она может быть использована и будет использована соответствующим образом в ходе выполнения проекта для достижения его глобальных целей.

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


7ПЕСПЕКТИВЫ ПРИМЕНЕНИЯ ФУНКЦИОНАЛЬНЫХ МОДЕЛЕЙ В СИСТЕМАХ МЕНЕДЖМЕНТА КАЧЕСТВА

7.1Перспективы IDEF0


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

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


7.2Создание моделей для менеджмента процессов


Для менеджмента процессами в семействе методологий IDEF существует методология моделирования процессов – IDEF3 [11]. Принципиальным отличием методологии IDEF3 является возможность моделирования динамики процессов, т.е. каким образом процессы непосредственно исполняются в организации.

IDEF0 и IDEF3 являются взаимодополняющими методологиями моделирования. IDEF0 модель отвечает на вопрос, что делает организация. Ответ на вопрос, как организация делает то, что она делает, содержится в IDEF3 модели. Это соотносится с различными аспектами процессного подхода в СТБ ИСО серии 9000 версии 2001 года: описание и менеджмент процессов (Рис. 1).

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

Другим достоинством IDEF3 методологии является ее тесная интеграция с остальными методологиями семейства IDEF: IDEF0, IDEF1X, IDEF2, IDEF4, IDEF5, IDEF9. Такая интеграция позволяет описывать, анализировать и управлять деятельностью предприятия с единых методологических позиций.


7.3CASE-средства моделирования процессов


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

Наиболее распространенными CASE-средствами, обеспечивающими поддержку IDEF0 методологии являются следующие продукты:

Программа Design/IDEF американской компании Meta Software.

Программа BPWin американской компании Logic Works.

Программа IDEF0/EMTool белорусско-канадской компании Ориентсофт.

Практически все перечисленные продукты обеспечивают:

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

Проверку правильности (верификацию) функциональной модели;

Генерацию различных отчетов на основании функциональной модели.

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


Приложение А.
(информационное)
Методология функционального моделирования IDEF0


В этом приложении приведены краткие сведения о методологии функционального моделирования IDEF0. Подробнее с методологией IDEF0 можно ознакомиться в [3-5].

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


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

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

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

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

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

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

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

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

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

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


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


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

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


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

глагол + объект действия + [дополнение]



Например, «производить продукцию», «обрабатывать записи качества» и т.д.

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

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

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

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

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

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

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


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


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

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

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

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


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

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

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

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

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




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



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



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

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





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

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


Приложение Б

(информационное)

Пример модели процесса производства женских пальто на швейной фабрике

Данный пример в обобщенном виде представляет модель (описание) делового процесса на швейной фабрике – «Производить женские пальто».

Цель модели – отразить, каким образом в рамках процесса выполняются требования СТБ ИСО 9001-2001.

Точка зрения – руководство фабрики.

Три уровня декомпозиции делового процесса представлены на Рис. 19, 20, 21, 22.

На рис. 20 представлена детализация делового процесса «Производить женские пальто». Анализ соответствия делового процесса «Производить женские пальто» требований СТБ ИСО 9001-2001 приведен в таблице 1. Очевидно, что в представленном описании делового процесса на данном уровне детализации присутствуют все процессы, обязательные с точки зрения требований СТБ ИСО 9001-2001.


Таблица 1. Соответствие делового процесса на фабрике требованиям СТБ ИСО 9001-2001

Требования СТБ ИСО 9001-2001

Реализация требований

Раздел 5. Ответственность руководства

Процесс А1. «Реализовать ответственность высшего руководства по менеджменту качества»

Входы процесса А1. Дуги «Внешняя информация», «Документы, регламентирующие деловой процесс», «Инициативы по улучшению СМК».

Выход процесса А1. Дуга «Политика, Цели, Руководство по качеству, Программы качества»


Раздел 6. Менеджмент ресурсов

Процесс А2. «Осуществлять менеджмент ресурсов».

Входы процесса А2. Дуги «Документы, регламентирующие процессы менеджмента ресурсов», «Политика, Цели, Руководство по качеству, Программы качества», «Ресурсы для организации процессов предприятия».

Выход процесса А2. Дуги «Ресурсы для процессов жизненного цикла и процессов измерения, анализа и улучшения СМК», «Информация по качеству».


Раздел 7. Процессы жизненного цикла

На диаграмме этого уровня детализации этот процесс представлен в неявном виде в рамках процесса А3 «Реализовать процессы жизненного цикла».

Входы А3. «Внешняя информация», «Сырье и материалы для производства продукции», «Политика, Цели, Руководство по качеству, Программы качества», «Документы, регламентирующие процессы жизненного цикла», «Ресурсы для процессов жизненного цикла».

Выходы А3. «Партии готовой к отправке продукции», «Информация для потребителей» (о качестве), «Информация по качеству» (внутренняя информация).


Раздел 8. Измерения, контроль, анализ и улучшение

Процесс А4. «Осуществлять измерения, анализ и улучшения СМК»

Входы процесса А4. Дуги «Политика, Цели, Руководство по качеству, Программы качества», «Документы, регламентирующие процессы измерения, анализа и улучшения СМК», «Информация по качеству», «Ресурсы для процессов измерения, анализа и улучшения СМК».

Выход А4. «Инициативы по улучшению СМК».

На Рис. 21 представлена детализация процесса А3 «Реализовать процессы жизненного цикла». Анализ соответствия делового процесса «Производить женские пальто» требований СТБ ИСО 9001-2001 приведен в таблице 2. На диаграмме присутствуют все процессы, обязательные с точки зрения СТБ ИСО 9001-2001.


Таблица 2. Соответствие процесса «Реализовать процессы жизненного цикла» на фабрике требованиям СТБ ИСО 9001-2001

Требования СТБ ИСО 9001-2001

Реализация требований

Раздел 7.1 Планирование процессов жизненного цикла продукции

Процесс А31. «Планировать процессы».

Входы процесса А31. Дуги «Политика, Цели, Руководство по качеству, Программы качества», «Документы, регламентирующие процессы жизненного цикла», «Внешняя информация».

Выходы процесса А31. Дуги «Программы...», «Информация по качеству».


Раздел 7.2 Процессы, связанные с потребителями

Процесс А32. «Осуществлять взаимодействие с потребителем».

Вход процесса А32. Дуга «Внешняя информация», «Программы маркетинга», «Документы, регламентирующие процессы жизненного цикла».

Выход процесса А32. Дуги «Информация для потребителей», «Требования потребителей», «Информация из подразделений»


Раздел 7.3 Проектирование и разработка

Процесс А33. «Разрабатывать новые модели».

Входы процесса А33. Дуга «Требования потребителей», «Программы...», «Документы, регламентирующие процессы жизненного цикла».

Выходы процесса А33. Дуги «Конструкторская документация», «Информация из подразделений»


Раздел 7.4 Закупки

Процесс А34. «Осуществлять закупки».

Входы процесса А34. Дуги «Сырье и материалы для производства продукции», «Программы закупок», «Документы, регламентирующие процессы жизненного цикла».

Выходы процесса А34. Дуги «Сырье и материалы для производства партий продукции», «Информация из подразделений».


Раздел 7.5 Производство и обслуживание

Процесс А35. «Шить пальто».

Входы процесса А35. Дуги «Сырье и материалы для производства партий продукции», «Конструкторская документация», «Программы производства», «Документы, регламентирующие процессы жизненного цикла».

Выходы процесса А35. Дуги «Партии готовых пальто», «Информация из подразделений».


Раздел 7.5.5. Сохранение соответствия продукции

Процесс А36. «Осуществлять поставки продукции».

Входы процесса А36. «Программы поставок», «Документы, регламентирующие процессы жизненного цикла», «Партии готовых пальто».

Выходы процесса А36. «Партии готовой к отправке продукции», «Информация из подразделений».


Раздел 7.6 Управление контрольными и измерительными приборами

Этот процесс не представлен на диаграмме, так как в рамках модели он отнесен на более низкий уровень иерархии процессов. Он является частью процесса «Освуществлять измерения, анализ и улучшения».

На Рис. 22 представлена детализация процесса «Производить закупки». На этом уровне детализации отражается специфика деятельности швейной фабрике, которая может быть отличной от деятельности других подобных организаций. Тем не менее, в рамках данного описания также присутствуют элементы, обязательные с точки зрения СТБ ИСО 9001-2001. В таблице 3 представлено соответствие процесса “Производить закупки» требованиям СТБ ИСО 9001-2001.

Таблица 3. Соответствие процесса “Производить закупки» требованиям СТБ ИСО 9001-2001


Требования СТБ ИСО 9001-2001

Реализация требований

Раздел 7.4.1. Процесс закупок

Диаграмма (карта процесса), включающая процессы А341 – А343.

Раздел 7.4.2. Информация по закупкам

Вход процесса А341. Дуга «Программы закупок».

Выход процесса А341. Дуга «Планы закупок»,

Выход процесса А341. Дуга «Информация из подразделений»,

Выход процесса А342. Дуга «Графики закупок»,

Выход процессов А342-А343. Дуги «Внутренняя информация службы снабжения».

Выход процесса А341. Дуга «Информация для поставщиков».

Входы процессов А341, А342. Дуги «Информация от поставщиков».


Раздел 7.4.3. Верификация закупленной продукции

Процесс А343. «Осуществлять закупки и их контроль».



Рис. 19. Деловой процесс на швейной фабрике


Рис. 20. Первый уровень детализации делового процесса «Производить женские пальто»


Рис. 21. Детализация процесса «Производить партии продукции»



Рис. 22. Детализация процесса «Осуществлять закупки»


Приложение В
(информационное)
Пример функциональной модели процесса изготовления шасси телевизора

Данный пример показывает возможность использования техники создания фрагментов («эскизов») моделируемых процессов с помощью FEO – диаграмм (For Exposition Only) в рамках IDEF0-модели. Модель делового процесса «Изготовить цветной телевизор» (РУП «Горизонт», Минск) – достаточно сложна и представляет собой сильно разветвленную сеть (систему) процессов всех возможных категорий (разделы 4.2.4, 5.1). Очевидно, что описание процессов в рамках большой сложной модели сразу «на чисто» практически невозможно. FEO – диаграммы, позволяют эскизировать отдельные фрагменты процессов, накапливать «эскизы» проектов диаграмм с целью их возможного использования для модели. Выполняются FEO – диаграммы по упрощенным правилам методологии IDEF0.

На рисунке представлена FEO – диаграмма жизненного цикла шасси цветного телевизора «Горизонт» как «эскиз» фрагмента всего делового процесса. Назначение «эскиза» - попробовать прописать процесс жизненного цикла «Собирать шасси цветного телевизора» по правилам языка функционального моделирования IDEF0. «Эскиз» подлежит обсуждению, необходимому уточнению и детализации. После обсуждения и утверждения он может быть «встроен» путем копирования в основную модель.

Рис. 23. Проект модели процесса «Сборка шасси цветного телевизора»


Приложение Г
(информационное)
Библиография


  1. ISO 9000 Introduction and Support Package: Guidelines on the Process Approach to quality management systems. ISO/TC 176/SC 2/N 544R. 17 May, 2001.

  2. ISO 9000 Introduction and Support Package: Guidance on the Documentation Requirements of ISO 9001:2000. ISO/TC 176/SC 2/N 544R. 13 March, 2001.

  3. Давид Марка, Клемент МакГоуэн. Методология структурного анализа и проектирования. Пер. с англ . М .:1993, 240 с ., ISBN 5-7395-0007-9

  4. INTEGRATION DEFINITION FOR FUNCTION MODELING (IDEF0). Draft Federal Information Processing Standards Publication 183, 1993, December 2

  5. Р50.1.028-2001. Методология функционального моделирования. М.: Госстандарт России, 2001.

  6. Окулесский В.А. Функциональное моделирование – методологическая основа реализации процессного подхода. М.: НИЦ CALS-технологий «Прикладная логистика», 2001.

  7. Менеджмент качества и международные стандарты ИСО 9000 версии 2000 г. Материалы семинара в рамках Программы ИСО для развивающихся стран. Минск, Июль 2001 г. 79 с.

  8. Рахлин К.М. МС ИСО серии 9000 версии 2000 г.: сущность и содержание процессного подхода. М.: Стандарты и Качество, №3, 2001.

  9. Information Integration For Concurrent Engineering (IICE). IDEF3 Process Description Capture Method Report. Knowledge Based Systems, Inc., Texas, USA, 1995.

  10. Хаммер M., Чампи Д. Реинжиниринг корпорации: Манифест революции в бизнесе. - С.-Петербург: С.-Петербург. ун-т, 1999.- 332.




Организация – ответственный исполнитель:

Белорусская государственная политехническая академия


Руководитель организации-разработчика







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




В.Л. СОЛОМАХО










Ответственный исполнитель, к.т.н., доцент




П.С. СЕРЕНКОВ

с. 1 ... с. 2 с. 3 с. 4 с. 5

скачать файл