Система менеджмента качества в вопросах и ответах.

Что такое процесс?

Начнем с терминов. Существует несколько определений процесса. В стандарте ГОСТ Р ИСО 9000 - 2008 «Системы менеджмента качества. Основные положения и словарь1»: процесс определен так:

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

В PMBOK2 дано другое, более широкое, определение процесса:

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

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

В оригинале международного стандарта менеджмента качества ISO 9000:2005 Quality Management Systems — Fundamentals and Vocabulary процесс определяется как «set of interrelated or interacting activities which transforms inputs into outputs». Неужели понятия «activities» и «виды деятельности» совпадают, тем более что в PMBOK эти «activities» названы «действиями» и «операциями». Даже если согласиться, что «activity» — это деятельность, то «activities» — это «деятельности», но не виды деятельности (что переводится как «kinds of activity» или «types of activity»). В справочниках и энциклопедиях деятельность определена так:

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

Значит в переводе стандарта ISO 9000:2005 налицо противоречие: процесс - это совокупность видов деятельности, но деятельность состоит из процессов. Дальнейшие поиски определений (следует отметить, что разные источники дают различные определения) привели к следующим результатам:

Действие — это осмысленное усилие по выполнению определенной задачи (работы) в течение определенного времени.

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

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

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

Подпроцесс — это группа операций в составе процесса, объединенная технологически или организационно.

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

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

Тогда декомпозиция процесса выглядит следующим образом:

процесс --->  подпроцесс  --->  операция

Применение слов «действие» и « работа4» в документации по процессам, на мой взгляд, неоправдано. Это, скорее, термины другой документации (например, технологических инструкций).

Отметим, что из декомпозиции процесса выпадает понятие «процедура». В оригинале процедура определяется как «specified way to carry out an activity or a process», что следует перевести как «установленный способ осуществления операции или процесса». Установленный путь (way), или способ, говорит о методологии (технологии) выполнения процесса или его части (см. определение процесса в PMBOK). Поэтому понятие «процедура» применяется ко всем элементам декомпозиции (процесс, подпроцесс, операция) в смысле их документирования (в стандарте есть понятие «документированная процедура»).

Рис. 1. Иерархия понятий в рамках СМК  и других понятий, связанных с выполнением деятельности.

Как правильно определить перечень процессов?

Стандарт ISO 9001:20085(и аналогичный ему ГОСТ Р ИСО 9001-2008 «Системы менеджмента качества. Требования»), в отличие, например, от IRIS6, не требует наличия определенных обязательных процессов. Но, по моему мнению, в перечень процессов должны входить все процессы жизненного цикла производства продукции (товаров, услуг) и большинство вспомогательных процессов (финансы, кадры и др.). Мысли разработчиков стандарта в отношении процессов можно проследить в ранних версиях стандарта ISO 9004:

1. Примеры процессов жизненного цикла:

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

2. Примеры вспомогательных процессов:

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

Единственное, что у меня вызывает сомнение в этом списке, — это проверки (пункт f). Проверки — это «check». То есть часть любого процесса, который должен совершенствоваться по циклу PDCA7. Возможно, здесь имелось в виду завершение процесса производства: приемочные испытания перед упаковкой и хранением. Но тогда, это не процесс, а подпроцесс или операция.

Если в названии процесса есть слова «планирование» или «контроль», следует задуматься, не часть ли это процесса? В моей практике был случай, когда в СМК был определен процесс «планирование». Поскольку планирование есть в любом процессе (производственное планирование, финансовое планирование, планирование закупок и т. д.), разработчикам СМК пришлось назначить владельцем этого процесса генерального директора. А так как реально такого процесса не существовало, они придумали промежуточный уровень — руководитель процесса планирования производства, руководитель процесса планирования закупок и т. д.

PDCA — это управленческий цикл операционной деятельности. Поэтому наименование процессов правильно начинать со слова «управление». Например, «Управление производством», «Управление закупками». Очень часто процессом называют бюджетирование. Но верно ли это? Посмотрим из чего состоит эта деятельность:

• формирование БДДС8 — это Plan;
• учет финансово-расчетных и кассовых операций (бухгалтерский учет) — это Do;
• контроль БДДС — это Check;
• внесение изменений, перепланирование - это Act.

А в целом это процесс «Управление финансами». Соответственно, БДР9 —- это этап планирования другого процесса - «Управление экономикой». Но иногда они объединяются и называются «Управление финансами и экономикой».

В качестве типового набора процессов промышленного предприятия можно предложить приведенные в таблице 1. Отметим, что стандарт IRIS предлагает несколько иной набор процессов.

Таблица 1. Типовой набор процессов промышленного предприятия.

Примечание: Процессы 1.2 и 1.3 могут входить в 1.1 как подпроцессы.

 Что делать, если процессы и оргструктура не совпадают?

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

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

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

Таблица 2. Матрица ответственности руководителей высшего звена за процессы (подпроцессы) СМК. 

Как описать процесс?

В стандартах ГОСТ Р ИСО 9001-2008 «Системы менеджмента качества. Требования» и ГОСТ Р ИСО/ТО 10013-2007 «Менеджмент организации. Руководство по документированию системы менеджмента качества» даются самые общие требования к описанию процессов. Более четко требования к описанию процессов даются в СТО ГАЗПРОМ10 . Согласно этому стандарту описание (построение модели) процесса включает в себя:

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

Документирование процесса может быть выполнено любым способом: вербально-описательным, графическим, с использованием таблиц. Графическое изображение модели процесса приведено на рисунке 2. Графическая форма более наглядна, табличная — более компактна, описательная — более привычна. На рис. 3 показано графическое описание процесса в виде IDEF0-диаграммы. Этот вид описания широко распространен и документирован11. Для разработки таких диаграмм существует достаточное количество специализированных и универсальных пакетов программ. Кроме того, эту нотацию понимают все консультанты. В дополнение к графическому описанию можно приложить текстовое или табличное дополнение. Вид табличной формы приведен в таблице 3.

Отмечу, что элементы описания процесса «задание показателей и методов мониторинга процесса, его результативности и эффективности» и «определение критериев результативности и эффективности процесса» (согласно стандарту СТО ГАЗПРОМ) я бы не включал в описание процесса, поскольку политика и цели в области качества могут меняться. Это повлечет за собой изменение показателей, что, в свою очередь, потребует изменения описания процесса. Показатели и методики их измерения лучше утверждать отдельным документом.

 Рис. 2 Графическое изображение модели процесса.

Рис. 3. Графическое описание процесса в виде диаграммы IDEFO.

Таблица 3. Формат табличного описания процессов.

Как описать взаимосвязи процессов?

В стандарте ГОСТ Р ИСО 9001-2008 «Системы менеджмента качества. Требования» говорится, что «организация должна определять последовательность и взаимодействие процессов». Обычно используется графическое описание в виде прямоугольников и стрелок. При этом понятно, что стрелка - это какой-то информационный или материальный поток, либо то и другое сразу. В результате взаимодействие процессов все-таки остается невыясненным. Это происходит потому, что связи эти многообразны и очень сложны.

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

Таблица 4. Описание взаимодействия процессов – информационных потоков (документов).

Кто должен заниматься описанием процессов?

Обычно при описании процессов преследуются две цели: усовершенствовать процессы (перевести из состояния «как есть» в состояние «как будет») или регламентировать процессы (разработать документацию СМК). В первом случае требуется более подробное описание, во втором — менее подробное. Можно предложить несколько способов.

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

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

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

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

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

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

Комментарии 0