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

7.3.1 Общие методические указания

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

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

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

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

7.3 Проектирование и разработка

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

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

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

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

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

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

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

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

Примерами являются:

а) внешние входные данные, такие, как:

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

b) внутренние входные данные, такие, как:

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

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

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

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

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

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

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

ИСО 9001:2000. Системы менеджмента качества. Требования

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

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

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

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

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

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

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

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

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

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

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

Объектами таких анализов являются:

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

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

Примерами деятельности по верификации выходов процесса проектирования и разработки являются:

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

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

Участие сторон позволяет фактическим пользователям оценивать выходы с помощью таких средств, как:

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

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

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

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

ИСО 9001:2000. Системы менеджмента качества. Требования

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

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

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

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

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

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

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

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

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

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

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

По вопросам : klubok@сайт

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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