Руководство - Методика и порядок работ по определению, классификации и идентификации процессов. Описание процессов на базе методологии IDEF0 - файл n1.doc

приобрести
Руководство - Методика и порядок работ по определению, классификации и идентификации процессов. Описание процессов на базе методологии IDEF0
скачать (738.5 kb.)
Доступные файлы (1):
n1.doc739kb.01.06.2012 11:51скачать

n1.doc

1   2   3   4   5   6   7

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-модели.

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


6ПОРЯДОК ПРОВЕДЕНИЯ РАБОТ ПО ОПРЕДЕЛЕНИЮ, КЛАССИФИКАЦИИ И ИДЕНТИФИКАЦИИ ПРОЦЕССОВ
Учебный материал
© nashaucheba.ru
При копировании укажите ссылку.
обратиться к администрации