Процессы жизненного цикла продукции. СМК: Входные и выходные данные для проектирования и разработки

Вы здесь: Как заработать деньги

Входные данные для проектирования и разработки

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

a) функциональные и эксплуатационные требования;

b) соответствующие законодательные и обязательные требования;

c) там, где это целесообразно, информацию, взятую из предыдущих аналогичных проектов;

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

Выходные данные проектирования и разработки

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

Выходные данные проектирования и разработки должны:

a) отвечать входным требованиям к проектированию и разработке;

b) обеспечивать соответствующей информацией по закупкам, производству и обслуживанию;

d) определять характеристики продукции, существенные для ее безопасного и правильного использования.

История работ в области качества в России.

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

Какие концепции повышения качества существовали в нашей стране?

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

2. Концепция КАНАРСПИ (Качество, Надежность, Ресурс с Первых Изделий) Была внедрена на Горьковском авиационном заводе. Признанная лучшей в стране, система базировалась на следующих принципах:

· универсальность (возможность использования в других отраслях промышленности)

· комплексное обеспечение качества продукции

· проведение исследований, направленных на повышение качества продукции и развитие опытно-конструкторских служб предприятия

· организация всестороннего учета качества выпускаемой продукции

· концентрация внимания на качестве продукции на стадии ее разработки

· привлечение к совершенствованию продукции потребителей

1. Концепция НОРМ В середине 1960-х гг. на Ярославском моторном заводе «Автодизель» была внедрена система НОРМ, в которой за критерий качества был принят один из важнейших технических параметров - ресурс до первого капитального ремонта. Особое внимание уделялось разработке конструкции и технологии, обеспечивающих повышение технического уровня и качества двигателя. В системе НОРМ были использованы и развиты основные элементы Саратовской и Горьковской систем управления качеством выпускаемой продукции.

2. Концепция КСУКП (Комплексная система управления качеством продукции)

В первой половине 1970-х гг. в результате совместного научно-производственного эксперимента предприятий Львовской области, ВНИИ стандартизации Госстандарта СССР и научно-производственного объединения «Система» была разработана и прошла апробацию комплексная система управления качеством продукции.

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

· создания и освоения новых высококачественных видов продукции;

· своевременной постановки на производство новой продукции;

· снятия с производства морально устаревшей продукции;

· улучшения показателей качества выпускаемой продукции путем ее совершенствования и модернизации.

В чем заключалась специфика Российского опыта управления качеством?

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

СМК: Управление несоответствующей продукцией.

Методика управления несоответствующей продукцией.

1) определяем продукцию, включаемую в область применения СМК,2) определяем, что такое соответствующая продукция,3) определяем, какие механизмы управления применимы к какой продукции (можно в виде таблицы),4) подробно описываем эти механизмы в применении к конкретной продукции: кто за что отвечает, какими полномочиями обладает, что делает.

Пока продукция у нас.

Что мы можем сделать для обеспечения соответствия продукции, когда обнаружено несоответствие?

Первое очевидно: исправить. т.е. в терминах ISO 9000 осуществить коррекцию. Но это не всегда возможно.

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

Если ни первое, ни второе невозможно, то остается третий вариант: изменить первоначальное применение или вообще отказаться от применения продукции.

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

 не определена сама продукция, качеством которой управляем в рамках СМК,

 не определено, что такое соответствующая продукция, ибо это равносильно тому, что не определена несоответствующая продукция.

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

Механизмы управления в каждом из трех случаев:

Изменить продукцию (коррекция)

 указать способ идентификации несоответствующей продукции и ответственного за эту идентификацию,

 указать ответственного за предотвращение выпуска и поставки идентифицированной несоответствующей продукции и его полномочия,

 указать ответственного за коррекцию,

 установить процедуру повторного контроля и ответственного за ее выполнение,

 установить, в какой форме делается запись о характере несоответствия и решении о коррекции.

Изменить требования

 указать уполномоченного на дачу разрешения на отклонение и его полномочия, а также установить процедуру такого разрешения, включая установление лица, уполномоченного потребителем давать разрешение на отклонение,

 установить, в какой форме делается запись о характере несоответствия и разрешении на отклонение.

Изменить применение

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

 установить, в какой форме делается запись о характере несоответствия и действиях по предотвращению первоначального применения.

Продукция у потребителя.

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

Группа по практике проведения аудита на соответствие ИСО 9001

1. Введение

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

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

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

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

Проектирование и разработка продукции являются совокупностью процессов, превращающих требования к продукции (например требования спецификаций, законодательные требования и требования, установленные или предполагаемые потребителем) в конкретные характеристики продукции («внутренне присущие характеристики продукции»). ИСО 9000 в разделе 3.5.1 дает следующие примеры характеристик продукции:

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

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

(Заметим: это относится как к исходному проекту, так и к последующим его изменениям.)

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

Рис. 1. Схема процесса проектирования и разработки

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

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

2. Аудитирование потребностей в проектировании и разработке

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

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

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

3. Аудитирование планирования проектирования и разработки

При аудите планирования проектирования и разработки следует рассмотреть нижеперечисленные вопросы:

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

4. Аудитирование исходных данных для проектирования и разработки

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

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

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

5. Аудитирование процесса проектирования и разработки и анализа результатов проектирования

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

Аудиторам при проведении проверки деятельности по анализу результатов проектирования следует рассмотреть следующее:

Осуществляется ли в ходе процесса проектирования анализ его результатов на запланированных этапах?

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

Учитываются ли при этом все первоначальные и новые исходные данные?

Остаются ли полученные выходные данные приемлемыми или идентифицированы ли те выходные данные, которые должны быть пересмотрены?

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

Демонстрируют ли выходные данные пригодность, адекватность и результативность разработанной продукции?

Достигнуты ли соответствующие цели проектирования?

Адекватны ли записи о результатах анализа?

6. Аудитирование результатов проектирования и разработки

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

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

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

Аудиторам в ходе анализа выбранных проектов следует получить доказательства, необходимые для подтверждения того, что:

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

7. Аудит верификации результатов проектирования и разработки

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

Рис. 2. Взаимосвязь различных этапов проектирования

Верификация может включать в себя такие виды деятельности, как:

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

Аудиторам следует установить, что деятельность по верификации результатов проектирования и разработки обеспечивает уверенность в том, что:

необходимые действия по верификации запланированы и осуществляются должным образом в ходе процесса проектирования и разработки;

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

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

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

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

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

8. Аудитирование валидации проекта или разработки

Валидация проекта и разработки является подтверждением (путем исследования и предоставления доказательств) того, что специфические требования, касающиеся конкретного (предназначенного) применения, выполнены. Другими словами, процесс валидации должен быть способен проверить, удовлетворяет или нет конечная продукция и/или услуга потребности потребителя, когда он начнет ее использовать?

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

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

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

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

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

Аудиторам следует убедиться, что:

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

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

9. Аудитирование внесения изменений в проект или разработку

Изменения, вносимые в проект в ходе проектирования, должны находиться под управлением. Аудиторам следует рассмотреть:

Контакты

Секретариат:

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

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

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

Выходные данные проектирования и разработки

Выходные данные проектирования и разработки должны:

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

Анализ проекта и разработки

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

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

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

Верификация проекта и разработки

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

Валидация проекта и разработки

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

Управление изменениями проекта и разработки

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

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

Процесс закупок

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

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

Информация по закупкам

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

а) требования к утверждению продукции, процедур, процессов и оборудования;
b) требования к квалификации персонала;
с) требования к системе менеджмента качества.

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

Верификация закупленной продукции

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

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

7.3.1. Планирование проектирования и разработки

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

В ходе планирования проектирования и разработки организация должна устанавливать:

а) стадии проектирования и разработки;

б) проведение анализа, верификацию и валидацию, соответствующие каждой стадии проектирования и разработки;

в) ответственность и полномочия в области проектирования и разработки.

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

Результаты планирования должны актуализироваться, если это необходимо, по ходу проектирования и разработки.

7.3.2. Входные данные для проектирования и разработки

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

Входные данные должны включать:

а) функциональные и эксплуатационные требования;

б) соответствующие законодательные и другие обязательные требования;

в) там, где это возможно, информацию, взятую из предыдущих аналогичных проектов;

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