Аудит менеджмента качества (стр. 4 из 9)

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 модели. В каком-то смысле эта цель определяет, как будет использоваться модель. Таким образом, как только завершено создание модели с требуемым уровнем детализации и модель проверена, она может применяться для достижения поставленной цели.