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

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

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

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

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

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

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

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

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

измененные материалы,

измененные компоненты продукта,

новые технологии представления услуг,

результаты анализов рынка.

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

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

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

Требования, предъявляемые к продукту и/или услуге должны быть определены и зарегистрированы (см.5.6.7). Эти требования должны включать:

требования к выполнению от заказчика или рынка;

применяемые нормативные и законодательные требования;

применяемые требования к окружающей среде

требования, вытекающие из прежних схожих проектов;

любые другие требования, существенные для проектирования и разработки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

d) другие требования, важные для проектирования и разработки.

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

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

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

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

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

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

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

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

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

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

a) оценивания способности результатов проектирования и разработки удовлетворять требованиям;

b) выявления любых проблем и внесения предложений по необходимым действиям.

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

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

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

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

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

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

Закупки

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

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

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

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

a) к официальному одобрению продукции, процедур, процессов и оборудования;

b) к квалификации персонала;

c) к системе менеджмента качества.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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) выявления любых проблем и внесения предложений по необходимым действиям.