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

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 Управление изменениями проекта и разработки

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

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

Входные данные, относящиеся к требованиям к продукции, должны быть определены, а записи должны поддерживаться в рабочем состоянии (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).

Закупки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Руководство ТюмГУ планирует и управляет проектированием и разработкой в соответствии с процедурами «Подготовка учебного процесса» ОП 01.02, «Обеспечение учебно-методическим обеспечением» ПП 01.03.

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

Кадровый состав;

Материально-техническая база;

Информационная база;

Научно-методическое обеспечение;

Финансовые ресурсы;

Управление системой и ее отдельными элементами.

В ТюмГУ обычно осуществляется проектирование и разработка следующих документов:

4. Учет стратегического и среднесрочного плана развития ТюмГУ.

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

1. Проектирование курса. Определение результатов обучения.

2. Самоанализ ППС и построение собственной системы педагогической деятельности.

3. Аттестация и технология самообследования университета.

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

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

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

Разработка и проектирование выполняется ТюмГУ самостоятельно или с привлечением сторонних организаций и/или специалистов.

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

ЦИТ – организация и поддержка электронной среды университета;

ИБЦ – использование (комплектование, выдача) учебно-методической и научной литературы ;

Издательство – издание учебно-методической и научной литературы;

Факультеты и кафедры – создание и подготовка к опубликованию научной и учебно-методической литературы.

Технические задания для соисполнителей разрабатываются ответственным исполнителем с участием, при необходимости, привлекаемых организаций и/или специалистов. Содержание технического задания определяется ТюмГУ. Техническое задание утверждает ректор.

Договор (контракт) с соисполнителем согласовывают следующие лица (в порядке получения виз):

· Соисполнитель;

· Руководитель структурного подразделения;

· Главный бухгалтер;

· Представитель руководства по качеству;

· Ректор и/или проректор.

Входные данные, относящиеся к требованиям учебного процесса в ТюмГУ, включают:

1. Требования к учебно-организационной документации;

2. Требования к информационному и учебно-методическому обеспечению;

3. Требования к ППС, административно-управленческому и учебно-вспомогательному персоналу;

4. Требования к материально-техническому оснащению;

5. Требования к уровню подготовки абитуриентов;

6. Информацию из стратегического и среднесрочного плана развития ТюмГУ.

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

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

Образовательные программы;

Учебно-методические пособия;

Словари.

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

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

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

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

Комплектность документации по проектированию и разработке определяется техническим заданием. Как правило, комплект документов включает в себя версию на бумажном носителе и электронную версию на CD-ROM.

Ответственным за подготовку документов является ответственный исполнитель.

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

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

Выходные данные организационно-методической работы:

§ подготовленные методические разработки,

§ составленные учебно-методические комплексы дисциплин,

§ система расчетов учебной нагрузки,

§ расписание экзаменов,

§ организация системы делопроизводства,

§ составление планов кафедр,

§ подготовка кафедры к самоаттестации и аккредитации.

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

В процессе проектирования и разработки осуществляется систематический анализ для установления соответствия требований к результатам проектирования и разработки, то есть анализируется качество разработки (п. п. 3.1.1, 3.8.7 ГОСТ Р ИСО 9000 – 2001).

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

· внутренний анализ, осуществляемый ТюмГУ в процессе подготовки предварительной и окончательной версий документов проектирования и разработки;

· внутренний анализ, осуществляемый ТюмГУ в процессе доработки (корректировки) документации по замечаниям и/или предложениям Потребителя;

· внешний анализ органами госэкспертизы (при необходимости);

· внешний анализ, осуществляемый Потребителем.

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

Число уровней анализа зависит от условий проектирования и разработки и может варьироваться.

I уровень анализа

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

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

Подтверждением проведенного анализа и приемки работ является подпись ответственного исполнителя.

II уровень анализа

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

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

III уровень анализа

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

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

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

IV уровень анализа

Анализ с привлечением сторонних организаций и/или специалистов. Решение о привлечении для анализа сторонних организаций и/или специалистов принимает Представитель руководства по качеству.

Подтверждением проведенного анализа является визирование ответственным исполнителем работ по договору (контракту) акта сдачи-приемки работ с привлеченными для анализа сторонними организациями и/или специалистами.

V уровень анализа

Анализ со стороны Потребителя.

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

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

Материалы по анализу проекта и разработки хранятся в подразделении-разработчике и/или у ответственного исполнителя работ в течение 3-х лет.

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

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

Ответственным исполнителем;

Специально назначенным сотрудником;

При нормоконтроле.

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

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

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

Заведующим кафедрой;

Деканом или начальником института;

Проректором;

Представителем руководства по качеству;

Ректором.

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

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

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

Изменения разработанной документации могут происходить:

· при обнаружении ошибок;

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

· при изменении требований Потребителей.

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

Тексты изменений разрабатывает инициатор изменения в соответствии с принятым порядком разработки и утверждения. Внесение изменений в разработанную документацию осуществляется специалистами, выполняющими или выполнившими соответствующую работу, под контролем ответственного специалиста (форма извещения об изменении приведена в приложении к процедуре 01.04.02/ПП 01.04 «Управление документацией и записями»).

Изменения, вносимые в разработанную документацию, анализируются с точки зрения их влияния на другую разработанную документацию по проекту, верифицируются, подвергаются валидации и согласованию в том же порядке, что и разрабатываемая документация (п. п. 7.3.3 – 7.3.6 Руководства по качеству).

Изъятая документация хранится в течение 3-х лет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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