ISO 9001:2015. 8 Функционирование 8.3 Процесс проектирования и разработки. Аудит

1. Введение

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

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

Часто Организации неправомерно исключают п. 8.3. Сначала нужно определиться с терминами. Проектирование и разработка продуктов и услуг - это набор процессов для преобразования требования к продуктам и услугам (например, спецификации, технические условия, конкретные или подразумеваемые требования клиентов) в характеристики определенного продукта / услуги («отличительные особенности продукта»). ISO 9000, пункт 3.10.1, дает следующие примеры характеристик:

- физические (например, механические, электрические, химические или биологические характеристики);

- сенсорные (например, связанные с запахом, прикосновением, вкусом, зрением, слухом);

- поведенческие (например, вежливость, честность, достоверность);

- временные (например, пунктуальность, надежность, доступность, непрерывность);

- эргономическая (например, физиологическая характеристика или связанная с безопасностью человека);

- функциональный (например, максимальная скорость автомобиля).

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

Как правило, процесс проектирования и разработки состоит из этапов, показанных ниже.

8.3.1.Потребность в определенных продуктах, услугах, процессах

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

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

8.3.4 Меры управления проектированием и разработкой (следует применять на всех этапах)

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

8.3.6 Изменения при проектировании и разработке

Завершенный проект или разработка

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

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

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

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

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

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

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

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

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

При аудите функционирования Планирования следует учитывать следующие вопросы:

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

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

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

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

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

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

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

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

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

• доступна информация о завершении этапа проектирования и разработки;
• завершен процесс проектирования и разработки для этапа контроля (меры управления);
• результаты проектирования и разработки были подтверждены

6. Меры управления проектированием и разработкой

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

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

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

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

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

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

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

Верификация может быть выполнена как:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7. Аудит Изменения при проектировании и разработке

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

Аудиторам следует учитывать следующее:

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

А. Прилипко, ведущий аудитор Бюро Веритас Сертификейшн Украина

Консультант по разработке и внедрению СМК

Oleksii.prylypko@gmail.com