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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Закупки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(Измененная редакция. Изм. № 1).

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

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

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

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

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

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

(Измененная редакция. Изм. № 1).

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

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

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

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

(Измененная редакция. Изм. № 1).

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

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

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

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

(Измененная редакция. Изм. № 1).

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

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

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

(Измененная редакция. Изм. № 1).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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-х лет.