1. Аудит системы менеджмента качества. Виды аудитов. Основные этапы проведения аудита СМК. Определения, относящиеся к аудиту по СТБ ИСО 9000 – 2006.

Определение аудита менеджмента качества

Цели и задачи аудита

Участники аудита

Статус аудита систем менеджмента качества

Этапы аудита

Начальное планирование аудита

Детальное планирование и согласование условий проведения аудита

Открытие аудита

Проверка на местах

Закрытие аудита

Оформление результатов аудита

Структура документации СМК

Структура документации системы менеджмента качества, построенной по стандарту ИСО 9001:2008 (ИСО 9001:2000), представляет собой иерархическую систему взаимосвязанных документов. Часть этих документов в явном виде оговорена в стандарте, другая часть подразумевается. Поэтому структура системы качества имеет «постоянную» составляющую, определенную стандартом и «переменную» составляющую, зависящую от конкретной организации.

«Постоянная» составляющая структуры документации СМК:

— Политика в области качества;

— Цели в области качества;

— Руководство по качеству;

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

— Записи по качеству.

«Переменная» составляющая структуры в стандарте поименована в следующем виде – «документы, необходимые организации для обеспечения эффективного планирования, осуществления процессов и управления ими (п.п. 4.2.1.d ИСО 9001:2008)». Как правило, к этим документам относятся различные планы, карты или схемы процессов, рабочие инструкции, отчетные формы, договора, нормативные документы, накладные и пр. Т.е. можно считать, что под эту «переменную» составляющую подпадает практически вся документация организации.

Некоторые рекомендации по составлению структуры документации СМК и содержанию документов СМК дает стандарт ИСО 10013:2001 «Рекомендации по документированию систем менеджмента качества». Однако, при составлении структуры документации СМК лучше ориентироваться на существующую в организации систему документации, дополняя ее необходимыми уровнями и документами, требуемыми стандартом ИСО 9001:2008.

- Понятия, относящиеся к аудиту (проверке) согласно СТБ ИСО 9000-2006.

Рисунок 1.1- Понятия, относящиеся к аудиту (проверке) (3.9)

2. Порядок работ по определению процессов СМК (ТКП 45 – 1.01 – 80 – 2007).

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

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

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

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

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

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

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

- классификацию процесса в рамках модели;

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 1 - Определение, классификация и идентификация процессов

2.3.3 Построение диаграмм

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

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

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

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

Примечания

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

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

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

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

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

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

Примечания

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Изучить требования и выполнить описание процесса «создание продукции» (СТБ ИСО 9001 – 2009) с помощью методологии IDEFO

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

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

- перечень процессов, относящихся к системе менеджмента качества организации;

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

3.1 Методика описания процессов на базе методологии IDEF0

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

3.1.1 Определение деловых процессов в виде IDEF0-модели

3.1.1.1 Определение делового процесса

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

Примечания

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

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

2 Общей целью моделей в рамках настоящего документа является создание системы менеджмента качества, соответствующей требованиями СТБ ИСО 9000, СТБ ИСО 9001 и СТБ ИСО 9004.

Для того чтобы выявить деловые процессы, необходимо определить следующее:

2. потребителей продукции и/или услуг организации;

3. продукцию и/или услуги, производимые в организации и поставляемые потребителям;

4. виды сырья и их поставщиков.

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

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

Фабрика является закрытым акционерным обществом. Цель построения модели – создание системы менеджмента качества. На основании этой информации в деятельности швейной фабрики можно выделить один деловой процесс – «Производить женские пальто». Входами этого процесса являются: а) внешняя информация, включая требования потребителей (магазинов и компаний); б) сырье и материалы; в) ресурсы. Выходами процесса являются: а) партии готовой продукции, предназначенные для потребителей; б) информация для внешних потребителей. Управление процессом осуществляется на основании нормативных документов, регламентирующих производственные процессы на фабрике. Учитывая, что нас интересует процесс с точки зрения менеджмента качества, то в качестве внешнего управления будем рассматривать нормативные документы, регламентирующие эту сферу, в том числе требования СТБ ИСО 9000. Карта делового процесса на швейной фабрике представлена на рисунке 2.

Рисунок 2- Деловой процесс на швейной фабрике

3.1.1.2 Описание структуры делового процесса

На втором этапе определения делового процесса необходимо описать его внутреннюю структуру. Для этого необходимо определить:

- из каких процессов состоит моделируемый деловой процесс;

- как эти процессы взаимодействуют между собой.

В IDEF0 моделировании для описания внутренней структуры процесса используется механизм декомпозиции (приложение А).

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

Рассмотрим декомпозицию делового процесса «Производить женские пальто» (рисунок 3).

Учитывая цели моделирования – соответствие делового процесса требованиям СТБ ИСО 9001 – декомпозиция делового процесса включает 4 блока процессов, представленных на рисунке 6.

В соответствии с требованиями СТБ ИСО 9000 деловой процесс «Производить женские пальто» включает следующие процессы:

- реализовать ответственность высшего руководства по менеджменту качества;

- осуществлять менеджмент ресурсов;

- реализовать процессы жизненного цикла;

- осуществлять измерения, анализ и улучшения СМК.

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

Рисунок 3 - Декомпозиция процесса «Производить женские пальто»

3.1.1.3 Описание взаимодействий между процессами

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

В методологии IDEF0 допустимыми являются 5 (пять) типов взаимодействий между блоками в пределах одной диаграммы:

-управление;

- выход вход;

-обратная связь по управлению;

-обратная связь по входу;

-выход – механизм.

	Взаимосвязь по управлению: выход одного процесса влияет на выполнение другого процесса, т.е. выходная дуга блока 1 является управляющей для блока 2. В СТБ ИСО 9001 такое взаимодействие определяет функцию управления «ответственность руководства» по отношению к другим процессам
	Взаимосвязь по входу: выход одного процесса является входом для другого, т.е. выходная дуга блока 1 является входной для блока 2. Это взаимодействие характерно для любых процессов в организации, например для процессов жизненного цикла
	Обратная связь по управлению: выходы из одного процесса влияют на выполнение других процессов, выполнение которых в свою очередь влияет на выполнение исходного процесса. Выходная дуга блока 1 является управляющей для блока 2, а выходная дуга блока 2 является управляющей для блока 1. В СТБ ИСО 9001 такое взаимодействие может определять: - функцию управления «ответственность руководства»; - функцию управления «управление процессами жизненного цикла»; - функцию управления «измерение, анализ и улучшение»
	Обратная связь по входу: выход из одного процесса является входом для другого процесса, выход которого является для него входом, т.е. выходная дуга блока 2 является входной для блока 1, выход которого является для него входом. В СТБ ИСО 9001 такое взаимодействие может определять функцию управления «управление процессами жизненного цикла»
	Взаимосвязь «выход – механизм»: выход одного процесса является механизмом для другого, т.е. выходная дуга блока 1 является дугой механизма для блока 2. Такой тип связи относится чаще всего к процессам обеспечения ресурсами. В СТБ ИСО 9001 такое взаимодействие может определять функцию управления «менеджмент ресурсов»

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

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

Примечание - Методология IDEF0 регламентирует, что каждый блок в модели должен содержать хотя бы по одной дуге входа, выхода, управления и механизма. В [6] имеется короткий список исключений из этого правила.

Рассмотрим взаимодействия между процессами, составляющими деловой процесс «Производить женские пальто» (рисунок 4).

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

Процесс «Осуществлять менеджмент ресурсов» имеет связь «выход – механизм» с процессами «Реализовать процессы жизненного цикла» и «Осуществлять измерения, анализ и улучшения СМК».

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

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

Рисунок 4 - Взаимодействия между процессами

3.1.1.4 Декомпозиция процесса

Количество уровней детализации процесса определяется целями моделирования и спецификой деятельности моделируемой организации.

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

На диаграмме А0 деловой процесс «Производить женские пальто» представлен в виде 4 процессов. Диаграмма А0 является первым уровнем декомпозиции (детализации) для этого процесса. Каждый из 4 представленных процессов в свою очередь может быть декомпозирован. На рисунке 5 представлена декомпозиция процесса «Реализовать процессы жизненного цикла».

На диаграмме А3 (рисунок 5) процесс «Реализовать процессы жизненного цикла» представлен в виде шести процессов, включая «Осуществлять закупки», который также может быть декомпозирован (рисунок 6).

Рисунок 5 - Декомпозиция процесса «Реализовать процессы жизненного цикла»

Рисунок 6 - Декомпозиция процесса «Осуществлять закупки»

3.1.1.5 Глоссарий процесса

Глоссарий процесса включает перечень процессов, объектов, обрабатываемых в рамках процессов, а также их определения.

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

Например, для диаграммы А34 (рисунок 6) фрагмент глоссария будет выглядеть следующим образом:

3.2.2 Классификация процессов в рамках IDEF0-модели

В соответствии с методологией IDEF0 модель состоит из двух типов элементов: функциональные блоки, которые представляют процессы, и интерфейсные дуги, которые представляют материальные и информационные объекты, обрабатываемые в рамках процессов.

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

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

3.2.2.1 Классификация интерфейсных дуг

В рамках IDEF0-модели дуги в зависимости от их положения на диаграмме подразделены на 4 категории: входные, выходные, управления и механизма.

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

- материалы, сырье, продукция, ресурсы;

- информация, данные, записи качества, документы;

- распоряжения руководства, планы, графики, распорядительные документы;

- стандарты, нормативные документы;

- ответственные исполнители, сотрудники организации и т.д. (рисунок 7).

Рисунок 7 - Типовые элементы процесса, описываемого по правилам методологии IDEF0

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

Примечание - Соглашения о графических стилях для представления объектов различных типов не являются составной частью стандарта IDEF0. Этот подход был впервые предложен компанией Ориентсофт в 1996 г. и реализован в инструментальном средстве IDEF0/EMTool. Подход успешно применен на ряде предприятий и организаций стран СНГ, а также США и Канады.

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

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

- информацию по качеству представлять с помощью утолщенных (толщина – 2pt) сплошных линий синего цвета;

- распоряжения, планы, графики представлять с помощью утолщенных (толщина – 2pt) сплошных линий красного цвета;

- сырье, материалы, продукцию представлять с помощью утолщенных (толщина – 2pt) сплошных линий коричневого цвета;

- ответственных исполнителей в процессах представлять с помощью утолщенных (толщина – 2pt) сплошных линий черного цвета;

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

Рассмотрим диаграмму, представляющую декомпозицию процесса «Реализовать процессы жизненного цикла» (рисунок 8).

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

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

3.2.2.2 Классификация функциональных блоков

Функциональные блоки в IDEF0-модели могут быть классифицированы в зависимости от типов процессов, которые они представляют. Типы процессов зависят от задач, решаемых с помощью функциональных моделей. В рамках настоящего документа для функциональных моделей следует использовать типы процессов, которые регламентированы в СТБ ИСО 9001 (подраздел 4.2.4), а также в подразделе 5.1, подпункт 2.2 настоящей методики).

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

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

Рассмотрим функциональную модель (описание) процесса «Реализовать процессы жизненного цикла» (рисунок 8). Представленный на диаграмме процесс «Планировать процессы» относится к типу управленческих процессов; в пользу этого вывода свидетельствует также то, что выход процесса «Планировать процессы» является управлением для остальных процессов, представленных на диаграмме.

Процессы «Осуществлять взаимодействие с потребителями», «Разрабатывать новые модели», «Осуществлять закупки», «Шить пальто» и «Осуществлять поставки» относятся к категории процессов жизненного цикла, так как на входах и выходах этих процессов представлены материальные ресурсы, а также требования потребителей и информация для потребителей.

Рисунок 8. Классификация процесса «Реализовать процессы жизненного цикла»

3.2.1 Идентификация процессов в рамках IDEF0-модели

В методологии IDEF0 существует несколько параллельных способов идентификации процессов:

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

Примечание – Подобное кодирование применяется, например, при создании нормативных или методических документов. Документ состоит из разделов 1, 2, 3. … Каждый раздел состоит из подразделов 1.1, 1.2, 2.1, 2.2, 2.3, ….. В свою очередь каждый подраздел можно детализировать (декомпозировать) на параграфы 1.1.1, 1.1.2, 2,1.1, 2.1.2 и т.д.;

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

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

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

Таблица 1 - Идентификация процессов в IDEF0-модели

3.2.4 Документирование процессов в IDEF0-моделях

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

-карту процесса;

-перечень процессов.

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

3.2.4.1 Карта процесса

Для документирования процессов в IDEF0 методологии используются специальные бланки «Карта процесса».

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

Использовано в:	Автор	Дата	Рабочая	Читатель Дата	Контекст
Проект	Рев	Черновая
Рекомендовано
Замечания: 1 2 3 4 5 6 7 8 9 10		Публикация
Вершина	Наименование				С-Номер Стр.
Примечание - Примеры карт процессов представлены на рисунках 8, 9, 11.

Рисунок 9 - Бланк «Карта Процесса»

Бланк включает следующие поля:

- раздел «Рабочая Информация»:

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

- поле «Замечания». В этом поле читатель отмечает замечания, которые он вносит в диаграмму. Каждому замечанию и комментариям к ним присваивается номер от 1 до 10. Соответствующий номер зачеркивается в поле «Замечания». Эта процедура гарантирует, что пользователь и разработчик не пропустят ни одного замечания, сделанного на диаграмме;

- поле «Статус». В этом поле отображается текущее состояние (версию) документа. Документ может иметь на текущий момент одну из следующих версий:

- «РАБОЧАЯ». Диаграмма содержит серьезные изменения, которые требуют повторного утверждения. Новым диаграммам всегда присваивается статус рабочей;

- «ЧЕРНОВАЯ». Диаграмма содержит незначительные изменения по сравнению с предыдущей версией;

- «ПУБЛИКАЦИЯ». После рассмотрения и утверждения рабочей группой диаграмма получает статус «Публикация». После этого в диаграмму запрещено вносить какие-либо изменения без специального решения рабочей группы.

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

- раздел «Идентификационная информация»:

- поле «Вершина». В этом поле содержится код родительского блока, декомпозиция которого представлена на диаграмме;

- поле «Наименование процесса». В этом поле содержится название процесса, представленного на диаграмме;

- поле «С-Номер» («Номер»). В этом поле содержится ссылочный номер процесса, представленного на диаграмме;

- поле «Страница» («Стр.»). В этом поле указывается номер страницы в документе, к которому относится данная диаграмма.

3.2.4.2 Перечень процессов

Для документирования перечня процессов в IDEF0 методологии используется специальный бланк «Перечень процессов» (рисунок 10).

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

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

- «Страница». Номер страницы, на которой находится описание процесса;

- «Вершина». Номер функционального блока в IDEF0-модели, который представляет собой описание процесса;

- «Наименование». Наименование функционального блока, представляющего процесс;

- «C-Номер». Ссылочный (идентификационный) номер, присвоенный данному процессу в организации;

- «Статус». Статус описания процесса. Может быть один из следующих: «Р» – рабочая версия; «П» – публикация.

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

Рисунок 1 0 - Бланк «Перечень Процессов»

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

Рисунок 11 - Пример документа «Перечень процессов на швейной фабрике»

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

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

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

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

Три уровня декомпозиции делового процесса представлены на рисунках А.1 - А.4.

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

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

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

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

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

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

Рисунок А.1 - Деловой процесс на швейной фабрике

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

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

содержание   ..  24  25  26   ..