Акции IT-компаний

Apple - $236.87

Google - $185.43

Facebook - $725.38

Amazon - $228.93

Microsoft - $409.04

Yandex - $48.44

Netflix - $1027.31

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

03.09.2021 13:00

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

Часто Организации неправомерно исключают п. 8.3. Сначала нужно определиться с терминами. Проектирование и разработка продуктов и услуг - это набор процессов для преобразования требования к продуктам и услугам (например, спецификации, технические условия, конкретные или подразумеваемые требования клиентов) в характеристики определенного продукта / услуги («отличительные особенности продукта»). ISO 9000, пункт 3.10.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. Аудит Изменения при проектировании и разработке

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

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

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

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

Консультант по разработке и внедрению СМК
e-mail: oleksii.prylypko@gmail.com, +380 50 414 4045


В помощь аудитору систем менеджмента качества (Серия из 21 статьи). Каждая статья посвящена отдельному пункту стандарта и дает подсказку, в каких документах, которые обычно ведут Организации для осуществления своей деятельности, аудитор может найти подтверждение, что требования стандарта ISO 9001:2015 выполняются. Или, можно ли составить несоответствие по тому или иному разделу стандарта, даже если аудитор считает, что Организация не выполняет требования стандарта.

Космические новости

Транспорт и концепты

Роботы и нейросети

Наука и мир ученых

Программное обеспечение

Железо и комплектующие

Смартфоны и гаджеты

Игровая индустрия и спорт

Интернет и новости

Вверх