Проектирование и разработка

7.2.2 Ревю требований Способность процессов организации удовлетворять требования заинтересованных сторон должна быть оценена для того, чтобы:

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

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

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

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

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

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

информации о продукте и/или услуге;
обращению запросов и заказов, включая поправки;
жалобам заказчика и действиям, относящимся к несоответствующей продукции и/или услуге (см. 8.3 и 8.5.2);
реакции заказчика, относящейся к изготовлению продукта и/или оказанию услуги (см.7.3.2 и 8.2.1.1).

Проектирование и разработка

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

Организация должна рассматривать возможность упрощения продукта и/или услуги, процессов или систем для уменьшения времени, затрат и риска.
Для того чтобы создать структуру деятельностей по проектированию и/или разработки, организация должна спланировать задачи, деятельности, ресурсы, входные и выходные элементы и ревю процесса проектирования и/или разработки процесса или проекта.
Организации могут установить партнерский подход, так чтобы, как внутренние и внешние ресурсы использовались на общие цели.
Когда речь идет о проектировании продуктов и/или услуг или процессов, организация должна принимать во внимание жизненный цикл, безопасность, надежность, долговечность, ремонтопригодность, риск и размещение, для того, чтобы обеспечить возможность удовлетворения нужд всех заинтересованных сторон. Также должно быть уделено внимание воздействию от использования материалов и других натуральных ресурсов.
Задачи и ожидаемые выходные данные должны быть распространены для двух целей; для обеспечения их понимания заинтересованными сторонами и для сбалансированного использования ресурсов.
Оценка риска должна быть предпринята для того, чтобы осознать возможные неудачи в продукте и/или услуге или процессе.
Методы для оценки риска могут включать:

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

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

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

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

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

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

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

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

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

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

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

адекватность выходных данных проекта и/или разработки,
позиции, по которым имеются спорные решения,
проблемные сферы и потенциальные слабые места.

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

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

7.3.4 Ревю проекта и разработки
На подходящих этапах должны проводиться систематические ревю проекта и/или разработки для:

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

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

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

7.3.5 Верификация проекта и разработки
Верификация проекта и/или разработки должна быть спланирована и выполнена таким образом, чтобы обеспечить уверенность о соответствии результатов и входных требований. Результаты верификации и последующие действия по выполнению принятых решений должны быть зарегистрированы (см.5.6.7.).
7.3.6. Утверждение проекта и разработки
Утверждение должно принимать в расчет ожидаемый диапазон рабочих условий и ситуаций использования для того, чтобы гарантировать совпадение между фактическими нуждами и транслирование этих нужд в виде входных требований.
Частичное утверждение выходных данных проектирования и /или разработки может оказаться необходимым для получения уверенности в их будущей применимости.
Примерами частичного утверждения могут служить:

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

Действия по утверждению могут включать:

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

Достаточное количество данных должно быть выработано для того, чтобы дать возможность в дальнейшем перепроверить решения и методы проектирования и/или разработки для улучшения продукта и/или услуги, исследований недостатков и для целей будущих проектов и/или разработки. 7.3.6 Утверждение проекта и разработки
Утверждение проекта и/или разработки должно проводиться для подтверждения того, что, полученный в результате продукт и/или услуга, способны соответствовать детальным требованиям для характерных заданных условий использования заказчиком.
Во всех случая применения, утверждение должно быть спланировано и выполнено до начала поставки или внедрения продукта и/или услуги.
Там, где невозможно осуществить полное утверждение до начала поставки или внедрения, должно быть предпринято частичное утверждение результатов проекта или разработки с максимальным приближением к практическому применению. Результаты утверждения и последующих действий по выполнению принятых решений должны быть зарегистрированы (см.5.6.7).
7.3.7 Управление изменениями
Организация должна ввести в действие техническую и административную дисциплину для того, чтобы управлять изменениями во время процессов проектирования и/или разработки. Такие изменения должны быть определены, задокументированы, подвергнуты ревю и утверждены уполномоченными людьми до их введения.
Должно быть принято во внимание как изменения в проектировании и/или разработке продукта и/или услуги могут воздействовать на процессы и эксплуатационные свойства оборудования, используемого в процессах.
Размеры принятых мер должны быть соизмеримы с величиной и сложностью проекта или процесса и зависеть от потенциального воздействия на качество из-за недостатков управления изменениями.
7.3.7 Управление изменениями Изменения проекта и/или разработки или модификаций должны быть утверждены уполномоченным персоналом и зарегистрированы до их внедрения.
Организация должна определить эффект от воздействия изменений на:

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

Результаты ревю изменений и последующего выполнения принятых решений должны быть зарегистрированы (см.5.6.7.). 7.3.8 Конечный продукт и/или услуга Организация должна предпринять документирование ревю требований заинтересованных сторон для того, чтобы обеспечить осуществимость реализации продукта и/или услуги и того, что конечный продукт и/или услуга будут соответствовать заданным целям.
Весь жизненный цикл продукта и/или услуги должен быть проанализирован, чтобы идентифицировать любые воздействия на заинтересованные стороны, включая здоровье и безопасность, размещение и воздействие на окружающую среду.
Организация должна сохранять записи о верификации и утверждении продукта и/или услуги в течение жизненного цикла, в зависимости от критичности их использования.
7.3.9 Проектирование и разработка процессов
Проектирование и/или разработка процессов должны учитывать характер желаемого результата и обеспечить сбалансирование соответствующих ресурсов, чтобы достичь целей и политики качества и удовлетворить нужды заинтересованных сторон.
Примерами таких процессов могут быть:

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

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

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

Роль людей внутри процессов должна быть идентифицирована для того, чтобы:

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

Закупки

7.4.1 Общие положения 7.4.1.1. Идентификация необходимости.
Организация должна идентифицировать необходимые ресурсы, которые не могут быть получены из внутренних источников, для определения стратегии закупок.
Закупочная стратегия должна идентифицировать цели и задачи для закупочных деятельностей, включая оценку, размещение заказа, верификацию закупочной продукции и/или услуги и развития поставщика, чтобы обеспечить балансировку с задачами и политикой качества организации.
Для того чтобы обеспечить оптимальную ценность для заинтересованных сторон должна быть оценена общая стоимость закупки, включая качество, наличие, сроки поставки и цены.
7.4.1.2. Спецификация
Организация должна определить процедуры для того, чтобы иметь гарантии, что спецификации для закупленного продукта и/или услуги отвечают требованиям организации и заинтересованных сторон.
Спецификации на заказываемый продукт и/или услугу могут разрабатываться с участием поставщиков для того, чтобы успешно использовать знания их специалистов. Поставщики могут также быть вовлечены в спецификацию требований системы менеджмента качества.
7.4.1 Общие требования
Организация должна управлять своими процессами закупки для обеспечения соответствия закупленных продуктов и/или услуг требованиям, установленным организацией. Тип и объем методов управления этими процессами должен быть определен на основе воздействия закупленного продукта и/или услуги на окончательный продукт и/или услугу.
7.4.1.3 Оценка поставщиков
Организация должна выбрать поставщиков продуктов и/или услуг таким образом, чтобы обеспечить соответствующее качество и надежное снабжение.
Типичные системы оценки поставщика используют такие объективные измерения:

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

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

Результаты оценки и последующие действия должны быть зарегистрированы (см.5.6.7).
7.4.2. Информация о закупках

Содержание раздела