Процесс Проектирования и разработка для организаций, предоставляющих услуги, будет рассмотрен отдельно.
Часто Организации неправомерно исключают п. 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 выполняются. Или, можно ли составить несоответствие по тому или иному разделу стандарта, даже если аудитор считает, что Организация не выполняет требования стандарта.