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

--PAGE_BREAK--Участники аудита
Аудит это процесс, в выполнении которого всегда задействовано множество участников. В зависимости от того, какие задачи решаются участниками в этом процессе можно выделить несколько основных ролей. Как правило, вне зависимости от того внешний это аудит или внутренний существуют следующие роли участников аудита:

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

— Аудиторы – лица обладающие компетентностью для проведения аудита (ИСО 19011:2002). Качество и результативность проведения аудита во многом зависит от квалификации и подготовки аудиторов. В связи с этим квалификации аудиторов уделяется особое внимание. Общие требования к квалификации аудиторов представлены в стандарте ИСО 19011:2002. Как правило, они применяются к профессиональным аудиторам, работающим в органах по сертификации. Требования к квалификации внутренних аудиторов организация может устанавливать сама, но это не значит, что аудитором может быть назначен любой сотрудник организации. Для того, что сотрудник организации мог результативно и эффективно проводить внутренние аудиты он должен быть обучен методам и техникам проведения аудита, знать требования системы качества, знать, как работает система качества организации и хорошо разбираться в той предметной области деятельности, которую он будет проверять.

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

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

Однако, несмотря на отсутствие законодательных норм, существуют определенные правила, регламентирующие проведение аудитов систем менеджмента качества. Примером таких правил, выступает международный стандарт ИСО 19011:2002 «Руководящие указания по проведению аудита систем менеджмента качества и/или систем экологического менеджмента». Этот стандарт может использоваться как для случая внутреннего аудита, так и для внешнего аудита. Кроме того, для регламентирования работы органов по сертификации, разработаны определенные правила проведения аудитов органами по сертификации, установлены требования к их работе и требования к аудиторам. Эти правила устанавливаются системой сертификации, в которой аккредитована организация, осуществляющая сертификацию систем качества. Для целей внутреннего аудита организация сама разрабатывает свои собственные правила по проведению аудита СМК. Эти правила устанавливаются в одной из обязательных процедур системы качества – процедуре проведения внутренних аудитов.

Виды аудитов

В XX веке аудит разделился на 2 большие группы:

·                     финансовый/инвестиционный аудит;

·                     промышленный аудит.

Финансовый аудит

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

Промышленный аудит

Промышленный аудитболее сложное явление, так как включает в себя элементы финансового (в части формирования себестоимости изделий, подтверждения обоснованности тарифов на услуги — например, услуги ЖКХ) и чисто технического аудита.

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

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

Разновидностями промышленного аудита являются экологический аудит (подтверждение нагрузок на природную среду), энергетический аудит, аудит затрат на эксплуатацию и подтверждение тарифов (применяется в основном для обоснования цен на продукцию естественных и иных монополий) и иные виды специальных аудитов (например — ESD-аудит).
    продолжение
--PAGE_BREAK--Этапы аудита
Аудит системы качества проводится, как правило, в 3 этапа, каждый из которых включает в себя определенную последовательность работ. Основными этапами аудита являются следующие:

— подготовка к аудиту;

— проведение проверок;

— завершающие действия.

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

Начальное планирование аудита включает в себя следующие действия:

— определение необходимых спецификаций или требований, по которым будет проводиться аудит. В зависимости от вида и масштаба аудита такими спецификациями могут быть – стандарт ИСО 9001:2008 (ИСО 9001:2000), документированные процедуры системы качества, документированные требования на процессы или отдельные регламенты и правила работы.

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

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

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

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

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

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

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

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

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

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

— Подготовка вопросника по аудиту. Каждый из аудиторов готовит свой вопросник, по тем подразделениям или области проверки, на которые он назначен аудитором. Вопросник – это документ, в котором аудитор определяет состав вопросов, требующих уточнения в ходе аудита в подразделении.

— Проведение инструктажа аудиторов. Инструктаж проводится в том случае, если аудиторов несколько. Проводит его ведущий аудитор. Как правило, инструктаж касается вопросов взаимодействия между аудиторами по ходу проведения аудита, соблюдения правил техники безопасности в проверяемых подразделениях, а также правил ведения записей по ходу аудита.
    продолжение
--PAGE_BREAK--Открытие аудита
После завершения мероприятий по подготовке аудита начинается этап аудита, связанный с проведением проверок подразделений и сотрудников организации. Проведение проверок начинается с открытия аудита. При внутреннем аудите, в том случае, когда организация большая, открытие аудита проводится в виде собрания представителей проверяемых подразделений, руководства организации и аудиторов. В ситуации внешнего аудита, собрание открывающее аудит, проводится всегда, вне зависимости от размеров организации.

На собрании открывающем аудит, ведущий аудитор напоминает про цели аудита и критерии, по которым будет проводиться аудит. Далее осуществляется краткое представление порядка аудита. Если аудит будет проводить группа аудиторов, то представляется порядок работы группы.

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

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

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

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

При проверке на местах, аудиторам необходимо:

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

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

— Установить соответствие или несоответствие требованиям – установить соответствия или несоответствия можно только на основании ответов сотрудника и их сравнения с выборочной проверкой работы сотрудника или каких-либо документов, записей.

— Записать результаты наблюдений и проверок – это одно из обязательных требований. По ходу аудита, аудитор обязан вести записи аудита и точно фиксировать все результаты проверок.

Если в ходе аудитной беседы и выборочной проверки у сотрудника обнаружены несоответствия, то все выявленные несоответствия необходимо сотруднику сообщить и объяснить, почему эти обнаружения являются несоответствиями, какие требования сотрудником были не выполнены.
Закрытие аудита
Закрытие аудита относится к завершающим действиям этапа проведения проверок и выполняется после завершения всех мероприятий программы аудита, т.е. фактически, когда завершены все аудитные беседы и проверки на рабочих местах сотрудников. Мероприятия по закрытию аудита, как правило, следующие:

— Определение общего количества несоответствий по всем проверенным подразделениям –необходимо посмотреть, что за несоответствия в подразделениях выявлены, есть ли повторяющиеся несоответствия, какое количество несоответствий. Большое количество повторяющихся несоответствий говорит об их системном характере.

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

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

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

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

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

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

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

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

Предложения по улучшению системы качества могут включаться в состав итогового отчета по аудиту.
Структура документации СМК
Структура документации системы менеджмента качества, построенной по стандарту ИСО 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 Подготовительный этап


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

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

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

-                  согласование планов и сроков по проекту среди всех участников, назначение ответственных исполнителей по проекту, а также составление и утверждение сроков и бюджета по проекту.
    продолжение
--PAGE_BREAK--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-модель очень редко создается одним разработчиком. На практике над различными частями модели может совместно работать множество разработчиков, потому что каждый процесс в модели представляет отдельный субъект, который может быть независимо проанализирован и декомпозирован.
    продолжение
--PAGE_BREAK--2.4 Порядок классификации процессов


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

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

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


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

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

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


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

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

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

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

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

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

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

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


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

Примечания

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

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

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

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

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

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

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

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

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

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


Рисунок 2- Деловой процесс на швейной фабрике 
    продолжение
--PAGE_BREAK--3.1.1.2 Описание структуры делового процесса
На втором этапе определения делового процесса необходимо описать его внутреннюю структуру. Для этого необходимо определить:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-выход вход;

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

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

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





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

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

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

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

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

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

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

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

Рисунок 4 — Взаимодействия между процессами
    продолжение
--PAGE_BREAK--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— Типовые элементы процесса, описываемого по правилам методологии IDEF
Для того чтобы выделить в IDEF0-модели элементы определенного типа, при моделировании используются заранее оговоренные соглашения о графическом стиле представления таких объектов. Поскольку дуги на IDEF0-модели представляются прямыми и ломаными линиями, графический стиль для дуг включает соглашение о цвете линии, толщине линии, типе линии (сплошная, пунктирная, штрихпунктирная, и т.д.), а также о типе стрелки на конце дуги.

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

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

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

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

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

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

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

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

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

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

Примечание — Конечная цель «раскрашивания» диаграмм состоит в том, чтобы отнести тот или иной объект на диаграмме к заранее определенной категории объектов, т.е. классифицировать объект. Комбинация графических атрибутов, которая используется для отображения объектов, является одним из способов маркировки объекта. Использование стилей при построении диаграмм существенно повышает «прозрачность» описания процессов при их последующем анализе и улучшении.
    продолжение
--PAGE_BREAK--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-модели
    продолжение
--PAGE_BREAK--3.2.4 Документирование процессов в IDEF0-моделях
Состав документов по процессам, используемых для их дальнейшего менеджмента (планирования, обеспечения, управления, улучшения), включает два типа документов:

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

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

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

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



Рисунок 9— Бланк «Карта Процесса»
Бланк включает следующие поля:

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

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

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

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

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

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

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

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

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

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

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

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

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