что такое процесс смк

Процессы системы менеджмента качества

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

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

Стандарт ISO 9001:2008 не регламентирует обязательное количество процессов СМК. Каждая организация самостоятельно определяет количество и состав процессов, исходя из особенностей своего бизнеса. Но если изначально было сформировано 10 процессов СМК, это не означает, что нельзя добавить еще 2 или 3 процесса, если в будущем возникнет такая необходимость.

Каждый процесс СМК имеет:

Если показатели не выполняются (возникают несоответствия), стандарт ISO 9001:2008 требует разработать корректирующие действия (КД) и предупреждающие действия (ПД). Заводится лист несоответствий, в котором разбираются причины несоответствия, предлагаются способы устранения этих причин (обратите внимание, устраняться должны именно причины, а не последствия), назначаются сроки исполнения и назначается ответственный.

Хочется дополнительно остановиться на процессе СМК «Анализ данных». В каждой компании, внедрившей СМК, обязательно должен быть налажен сбор информации о факторах, влияющих на работу системы:

Ну и самое главное. В процесс поддержания и развития СМК обязательно должно быть вовлечен весь персонал компании — от высшего руководство или владельцев компании до рядового рабочего. И тогда ваша СМК обречена на успех!

Источник

СМК на предприятии: определение, содержание и реализация

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

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

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

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

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

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

Для разработки СМК предприятия на основе системного подхода придётся решать следующие конкретные задачи:

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

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

Любой процесс из СМК можно отнести к одной из трёх групп:

В соответствии с разработанной процессной моделью СМК организации выявляются недостающие документы СМК, в частности, процедурные – ПСМК:

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

На сегодняшний день EMAS являются наиболее совершенным и эффективным стандартом в мире. ISO 14000 – это всего лишь его часть, хотя неотъемлемая и существенная. И тот, и другой стандарты являются добровольными. Зачем они нужны и в чем разница?

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

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

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

Источник

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

Процессы, их выделение и описание

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

Процессы, их выделение и описание

Директор по качеству «Челябинского тракторного завода – УРАЛТРАК»

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

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

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

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

Кроме того, в 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»). В справочниках и энциклопедиях деятельность определена так:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Процессы ответственности руководства

1.1. Управление системой менеджмента качества

1.2. Управление изменениями и улучшениями

1.3. Управление проектами

2. Процессы жизненного цикла продукции

2.1. Управление маркетингом

2.2. Управление подготовкой производства

2.3. Управление производством

2.4. Управление закупками

2.5. Управление продажами

2.6. Управление сервисом

3. Процессы обеспечения

3.1. Управление технологическим оборудованием

3.2. Управление контрольным, измерительным и испытательным оборудованием

3.3. Управление производственной средой

3.4. Управление финансами и экономикой

3.5. Управление персоналом

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

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

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

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

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

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

Директор по менеджменту качества

Зам. ГД по маркетингу

Зам. ГД по производству

Директор по обеспечению

Зам. ГД по продажам

Директор по сервису

Зам. ГД по работе с персоналом и соц. прог.

Зам. ГД по финансам и экономике

Управление системой менеджмента качества

Управление подготовкой производства

Управление организационной подготовкой производства

Управление конструкторской подготовкой производства

Управление технологической подготовкой производства

Управление технологическим оборудованием

Управление контрольным, измерительным и испытательным оборудованием

Управление производственной средой

Управление финансами и экономикой

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

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

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

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

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

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

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

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

Владелец (руководитель) процесса

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

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

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

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

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

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

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

Источник

Система менеджмента качества: как разобраться в стандартах и запустить процесс их внедрения в компании

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

Стандартизация по ту сторону добра и зла

В 2015 году вышел международный стандарт, регламентирующий управление качеством, – ISO 9001-2015, а в 2016 году на его основе выпустили отечественный стандарт ГОСТ Р ИСО 9001-2015 [1]. Сертификация по этим стандартам даёт много бонусов. Свидетельство соответствия ГОСТ Р ИСО 9001-2015 (ISO 9001:2015) подтверждает клиентам, партнерам, инвесторам, что бизнес управляет качеством. Сертификат ISO 9001 помогает выйти на международный рынок. Кроме того, наличие сертификата ISO обязательно для участия в некоторых государственных тендерах и конкурсах.

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

Много букв, не осилил

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

Для разработчиков программного обеспечения (ПО) и автоматизированных систем (АС) работа в рамках системы менеджмента качества (СМК) непонятна и затруднительна. Правила и требования СМК действительно громоздки. Они насчитывают полтора десятка международных стандартов серии ИСО 9000 и ИСО 10000. Количество отечественных стандартов с учетом отраслевых и сосчитать трудно – их точно не менее сотни. Плюс существуют еще и десятки руководств и учебных пособий [6, 7]. Даже просто прочитать эти тысячи страниц затруднительно, а осмыслить их и сформировать программу конкретных действий для внедрения системы менеджмента качества у себя на предприятии (или даже просто в рамках рабочей проектной группы) еще сложнее.

Источник

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

О жизненном цикле в деталях

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

Чтобы сопоставить и проанализировать большое количество стандартов и нормативных документов, рассмотрим приведенную ниже схему (Рисунок 1). Это попытка классифицировать различные формулировки жизненного цикла (ЖЦ) применительно к разработке программного обеспечения и автоматизированных систем.

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

Два верхних ряда представляют перечень стадий жизненного цикла в рамках нового ГОСТ Р ИСО 9001-2015 (первый ряд) и ГОСТ Р ИСО 9001-2001 (второй ряд). Несмотря на некоторые различия в формулировках, стадии жизненного цикла в указанных стандартах почти идентичны.

Отличия между стандартами проявляются только в подробных разъяснениях к каждому этапу цикла. Отметим, что в новом стандарте появилось понятие «Контекст организации». Его смысл – в изучении того, как внешняя или внутренняя среда влияет на перспективы предприятия. ГОСТ Р ИСО 9001-2015 в пунктах 4.1 и 4.2 требует выявить внешние и внутренние факторы и связанные с ними риски и возможности. Таким образом, смысл глубокого анализа или изучения «контекста» заключается в сборе и анализе данных о внешней среде и текущем состоянии бизнеса, о ключевых факторах успеха (что определяет победу и проигрыш), о состоянии сектора рынка, его структуре, динамике и т.д. Для расшифровки этого понятия и конкретизации деятельности в соответствии с этим требованием нужно тщательно проанализировать все возможные риски, возникающие в процессе. Подробнее о понятии «контекста» можно прочитать в статье Ибрагимова Р. [3].

Третий ряд схемы показывает стадии жизненного цикла при разработке программных средств в трактовке ГОСТ 12207, который создан специально для процессов разработки ПО [4]. Здесь также нет принципиальных отличий трактовок жизненного цикла по сравнению с предыдущими стандартами.

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

Посмотрим на четвертый ряд схемы. Здесь представлены процессы жизненного цикла в трактовке ГОСТов 34-й серии [5], опубликованных в далеком 1990 году. Эта серия стандартов была разработана так конкретно и тщательно, что ею пользуются практически без всяких изменений до сих пор. Многие заказчики при формулировке требований к документации на автоматизированные системы ссылаются в основном на ГОСТы именно этой серии. Поскольку этапы жизненного цикла в трактовках ИСО 9001, ГОСТ 12207 и ГОСТов 34-й серии совпадают, это означает, что, выполняя требования последнего из перечисленных ГОСТов, то есть предъявив заказчику перечисленные документы, мы автоматически работаем в соответствии с системой качества по ИСО 9001.

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

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

К сожалению, это далеко не все. Пока мы разобрались лишь с производственной составляющей, т. е. с процессом разработки ПО или АС.

Бизнес-процессы — основа основ

За кадром остались следующие процессы: контрактная работа, организация и управление проектом и собственно обеспечение качества. Это тоже самостоятельный организационный процесс. Описывать эти процессы в текстовом формате — дело неблагодарное, все описания уже есть в многочисленных руководствах [6, 7]. Поэтому попытаемся отобразить перечисленные бизнес-процессы в виде еще одной схемы (Рисунок 2).

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

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

Исполнителю, пользуясь приведенной схемой, необходимо проанализировать свои конкретные бизнес-процессы и выявить те элементы, которые требуют регламентирования. Например, продукция любой ИТ-компании, очевидно, проходит тестирование. Есть ли в вашей компании регламент, в котором прописано, что относится к критическим багам, а что к некритическим и в какие сроки их требуется устранять? Наверняка, определенные инструкции на этот счет есть. Утвержденный регламент по этой позиции — это и есть система менеджмента качества. Причем тестирование затрагивает одновременно производственное направление и администрирование, так как руководство должно отслеживать своевременное исправление ошибок.

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

Рисунок 2. Бизнес-процессы при разработке автоматизированных систем: документирование по системе качества. Рисунок кликабелен.

Движемся к цели

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

1. Создать подразделение, группу или назначить отдельного исполнителя, чтобы он занимался вопросами СМК.

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

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

4. Регламентировать отчетность и ответственность исполнителей и руководства по каждому этапу жизненного цикла проекта.

5. Представить пакет разработанных документов в консалтинговую фирму, имеющую соответствующую лицензию, для инспектирования документации и выдачи заключения о соответствии работы по СМК в рамках стандарта ГОСТ Р ИСО 9001-2015. Исправить замечания и получить сертификат.

6. Продолжать проектную работу, строго следуя разработанным регламентирующим документам.

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

Литература

1. ГОСТ Р ИСО 9001-2015. Системы менеджмента качества. Требования. — М.: Стандартинформ, 2016.
2. ГОСТ Р ИСО 9001-2001. Системы менеджмента качества. Требования. — М., Стандартинформ, 2001.
3. Ибрагимов Р., ISO 9001:2015 и практический анализ «контекста» и построение стратегий. — Management, № 2 (34), 2015. — С. 13-18.
4. ГОСТ Р ИСО МЭК 12207 Информационная технология. Процессы жизненного цикла программных средств. — М.: Госстандарт России, 1999.
5. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. — М.: Издательство стандартов, 1991.
6. Глудкин О.П., Горбунов Н.М. и др. Всеобщее управление качеством. Учебник для вузов. Под ред. О. П. Глудкина. — М.: Горячая линия — Телеком, 2001. — 600 с.
7. Круглов М.Г. Инновационный проект. Управление качеством и эффективностью. — М.: РАНХиГС, 2011. — 350 с.

Источник

Источник