Вхідні дані, що відносяться до вимог продукції, повинні бути визначені, а записи повинні підтримуватися в робочому стані (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). Ці дані повинні включати:
a) функціональні та експлуатаційні вимоги;
b) відповідні законодавчі та обов'язкові вимоги;
c) там, де це є доцільним, інформацію, взяту з попередніх аналогічних проектів;
d) інші вимоги, важливі для проектування та розробки. Ці вхідні дані мають аналізуватись на адекватність. Вимоги мають бути повними, недвозначними та несуперечливими.
Вихідні дані проектування та розробки
Вихідні дані проектування та розробки мають бути подані у формі, що дозволяє провести верифікацію щодо вхідних вимог до проектування та розробки, а також мають бути затверджені до їх випуску.
Вихідні дані проектування та розробки повинні:
a) відповідати вхідним вимогам до проектування та розробки;
b) забезпечувати відповідною інформацією щодо закупівель, виробництва та обслуговування;
d) визначати характеристики продукції, суттєві для її безпечного та правильного використання.
Історія робіт у галузі якості в Росії.
Говорячи про передовий досвід у галузі управління якістю, не можна не згадати про вітчизняну практику вдосконалення якості.
Які концепції підвищення якості існували у нашій країні?
1. Концепція БІП(Бездефектного Виготовлення Продукції) В основу цієї системи було покладено механізм активізації учасників виробничого процесу, що стимулює їх до виявлення та усунення не дефектів продукції, а їх причин. Після повторного пред'явлення продукції робітник позбавлявся премії.
2. Концепція КАНАРСПІ(Якість, Надійність, Ресурс із Перших Виробів) Була впроваджена на Горьковському авіаційному заводі. Визнана найкращою в країні система базувалася на наступних принципах:
· Універсальність (можливість використання в інших галузях промисловості)
· Комплексне забезпечення якості продукції
· Проведення досліджень, спрямованих на підвищення якості продукції та розвиток дослідно-конструкторських служб підприємства
· Організація всебічного обліку якості продукції, що випускається
· Концентрація уваги на якості продукції на стадії її розробки
· Залучення до вдосконалення продукції споживачів
1. Концепція НОРМУ середині 1960-х років. на Ярославському моторному заводі «Автодизель» було впроваджено систему НОРМ, у якій за критерій якості було прийнято одне з найважливіших технічних параметрів- ресурс до першого капітального ремонту. Особлива увага приділялася розробці конструкції та технології, що забезпечують підвищення технічного рівня та якості двигуна. У системі НОРМ були використані та розвинені основні елементи Саратовської та Горьківської систем управління якістю продукції, що випускається.
2. Концепція КСУКП(Комплексна система управління якістю продукції)
У першій половині 1970-х років. в результаті спільного науково-виробничого експерименту підприємств Львівської області, ВНДІ стандартизації Держстандарту СРСР та науково-виробничого об'єднання «Система» було розроблено та пройшла апробацію комплексна система управління якістю продукції.
Головна мета системи полягала у забезпеченні високих та стійких темпів зростання якості продукції, що випускається підприємством, за рахунок:
· Створення та освоєння нових високоякісних видів продукції;
· Своєчасної постановки на виробництво нової продукції;
· Зняття з виробництва морально застарілої продукції;
· Поліпшення показників якості продукції, що випускається шляхом її вдосконалення та модернізації.
У чому полягала специфіка Російського досвідууправління якістю?
Специфіка управління якістю у Росії у тому, що ефективні системи управління якістю створювалися на підприємствах військово-промислового комплексу (ВПК). Саме у ВПК були поширені методи забезпечення якості на стадіях дослідження та проектування нової продукції, статистичний контроль якості із застосуванням контрольних карток, спеціальні стандарти. У надрах ВПК народилися КСУКП (комплексні системи управління якістю продукції, зокрема автоматизовані).
Управління невідповідною продукцією.
Методика керування невідповідною продукцією.
1) визначаємо продукцію, що включається в область застосування СМЯ,2) визначаємо, що таке відповідна продукція,3) визначаємо, які механізми управління застосовні до якої продукції (можна у вигляді таблиці),4) докладно описуємо ці механізми у застосуванні до конкретної продукції: хто за що відповідає, які повноваження має, що робить.
Поки що продукція у нас.
Що ми можемо зробити для забезпечення відповідності продукції, коли виявлено невідповідність?
Перше очевидно: виправити. тобто. у термінах ISO 9000 здійснити корекцію. Але це завжди можливо.
Тоді друге: оцінити, наскільки невідповідність перешкоджає навмисному використанню продукції, і, якщо прийнятно, дозволити відхилення. Якщо можливо, дозвіл на відхилення запитується ще й у споживача, чи згоден він. Замовник, проаналізувавши, які саме функції будуть відсутні, може вважати це цілком прийнятним і дозволити.
Якщо ні перше, ні друге неможливо, залишається третій варіант: змінити первісне застосування або взагалі відмовитися від застосування продукції.
Очевидно, що процедуру управління невідповідною продукцією неможливо повноцінно розробити, якщо
не визначено саму продукцію, якістю якої керуємо в рамках СМЯ,
не визначено, що таке відповідна продукція, бо це рівнозначно тому, що не визначено невідповідну продукцію.
З досвіду аудіювання: якщо я з керівництва якості не можу зрозуміти, яка конкретно продукція включена в область застосування СМЯ, то я можу навіть не дивитися процедуру управління невідповідною продукцією, заздалегідь гарантуючи, що вона формальна.
Механізми управління у кожному із трьох випадків:
Змінити продукцію (корекція)
вказати спосіб ідентифікації невідповідної продукції та відповідального за цю ідентифікацію,
вказати відповідального за запобігання випуску та постачанню ідентифікованої невідповідної продукції та його повноваження,
вказати відповідального за корекцію,
встановити процедуру повторного контролю та відповідального за її виконання,
встановити, у якій формі робиться запис про характер невідповідності та рішення про корекцію.
Змінити вимоги
вказати уповноваженого на дачу дозволу на відхилення та його повноваження, а також встановити процедуру такого дозволу, включаючи встановлення особи, уповноваженої споживачем надавати дозвіл на відхилення,
встановити, у якій формі робиться запис про характер невідповідності та дозвіл на відхилення.
Змінити застосування
встановити відповідального за запобігання первісному застосуванню споживачем невідповідної продукції та його повноваження, а також процедуру такого запобігання,
встановити, в якій формі робиться запис про характер невідповідності та дії щодо запобігання початковому застосуванню.
Продукція споживача.
Очевидно, що в цій ситуації жоден із описаних вище механізмів не застосовується: продукція вийшла з-під нашого контролю. Все, що ми можемо в даному випадку, це зробити дії, що знижують негативні наслідкиабо ризик таких наслідків споживача. Як приклад тут можна навести всім відомі компанії з відкликання автомобілів.
7.3.1 Загальні методичні вказівки
Вищому керівництву слід переконатися, що організація визначила, впровадила та підтримує у робочому стані необхідні процеси проектування та розробки для результативного та ефективного реагування на потреби та очікування своїх споживачів та інших зацікавлених сторін.
При проектуванні та розробці продукції або процесів керівництву необхідно забезпечити, щоб організація не тільки була здатна враховувати свою основну діяльність та свої функції, але й усі фактори, що сприяють тому, щоб характеристики продукції та процесів відповідали очікуванням споживачів та інших зацікавлених сторін. Наприклад, організація повинна брати до уваги життєвий цикл продукції, охорону праці, можливість проведення випробувань, придатність, простоту використання, надійність, довговічність, ергономіку, зовнішнє середовище, утилізацію продукції, і навіть певні ризики.
Керівництво також несе відповідальність за вжиття заходів щодо ідентифікації та зменшення потенційного ризику для користувачів продукції та процесів організації. Слід проводити оцінювання ризиків, щоб оцінити можливість їх появи та наслідки ймовірних відмов чи недоліків продукції чи процесів. Результати оцінки треба використовувати для визначення та здійснення запобіжних дій з метою зменшення ідентифікованих ризиків. Приклади засобів оцінювання ризиків проектування та розробки включають:
Аналіз причин та наслідків відмов проекту;
- аналіз дерева відмов;
- прогноз безвідмовності;
- діаграми залежності;
- методи класифікації;
- Методи моделювання.
7.3 Проектування та розробка7.3.1 Планування проектування та розробки Організація повинна планувати та керувати проектуванням та розробкою продукції. У ході планування проектування та розробки організація повинна встановлювати:
Організація повинна керувати взаємодією різних груп, зайнятих проектуванням та розробкою, з метою забезпечення ефективного зв'язку та чіткого розподілу відповідальності. Планування виходу має актуалізуватися, якщо це доцільно, у міру розвитку проектування та розробки. |
7.3.2 Вхідні та вихідні дані для проектування та розробки
Організації необхідно визначити вхідні дані для процесу, що впливають на проектування та розробку продукції та сприяють результативній та ефективної роботипроцесу з метою задоволення потреб та очікувань споживачів, а також інших зацікавлених сторін. Ці зовнішні потреби та очікування у поєднанні з внутрішніми запитами організації повинні бути придатними для переведення у вхідні вимоги до процесів проектування та розробки.
Прикладами є:
а) зовнішні вхідні дані, такі, як:
Потреби та очікування споживачів або ринку;
- потреби та очікування інших зацікавлених сторін;
- Внесок постачальників;
- Вхідні дані користувача, спрямовані на створення стабільного проекту та розробки;
- зміни у відповідні законодавчі та регламентуючі вимоги;
- міжнародні або національні стандарти;
- Промислові кодекси практики, що встановилася;b) внутрішні вхідні дані, такі як:
Політика та цілі;
- потреби та очікування працівників організації, включаючи осіб, які отримують вихідні дані процесів;
- технологічні розробки;
- вимоги до компетентності проектувальників та розробників;
- Зворотна інформація про минулий досвід;
- записи та дані про існуючих процесахта продукції;
- Виходи інших процесів;c) вхідні дані, що визначають ті характеристики процесів або продукції, які є критичними для їх безпеки, правильного функціонування та обслуговування, такі як дані про:
Роботі, монтажі та застосуванні;
- зберігання, вантажно-розвантажувальних роботах та постачання;
- фізичних параметрах та зовнішньому середовищі;
- Вимоги до утилізації продукції.
Істотне значення можуть мати вхідні дані, пов'язані з продукцією, що ґрунтуються на оцінці потреб та очікувань кінцевих користувачів, а також безпосередніх споживачів. Ці вхідні дані необхідно сформулювати так, щоб продукцію можна було результативно та ефективно верифікувати та затвердити.
Вихідні дані включають інформацію, що дозволяє провести верифікацію та валідацію порівняно із запланованими вимогами. Приклади виходу проектування та розробки включають:
Дані, що підтверджують порівняння входів процесу з виходами процесу;
- специфікації продукції, зокрема критерії приймання;
- Специфікації на процес;
- Специфікації на матеріали;
- Специфікації на випробування;
- Вимоги до підготовки кадрів;
- інформацію про користувача та споживача;
- вимоги до закупівель;
- Протоколи перевірки відповідності технічним умовам.
Виходи проектування та розробки слід проаналізувати стосовно входів з метою забезпечення об'єктивного свідчення того, що виходи результативно та ефективно відповідають вимогам до процесу та продукції.
ISO 9001:2000. Системи управління якістю. Вимоги 7.3.2 Вхідні дані для проектування та розробкиВхідні дані, що стосуються вимог продукції, повинні бути визначені, а записи повинні підтримуватися в робочому стані. Ці дані повинні включати:
Ці вхідні дані мають аналізуватись на адекватність. Вимоги мають бути повними, недвозначними та несуперечливими. 7.3.3 Вихідні дані проектування та розробкиВихідні дані проектування та розробки мають бути подані у формі, що дозволяє провести верифікацію щодо вхідних вимог до проектування та розробки, а також мають бути затверджені до їх випуску. Вихідні дані проектування та розробки повинні:
|
7.3.3 Аналіз проекту та розробки
Вищому керівництву необхідно забезпечити, щоб відповідні працівники були призначені для управління та проведення систематичного аналізу, щоб встановити досягнення цілей у галузі проектування та розробки.
Такі аналізи можуть проводитися у вибраних точках процесу проектування та розробки, а також після його завершення.
Об'єктами таких аналізів є:
Адекватність входів для виконання завдань з проектування та розробки;
- хід запланованого процесу проектування та розробки;
- відповідність цілям верифікації та валідації;
- Оцінка потенційних ризиків або причин відмов при використанні продукції;
- дані життєвого циклу, Що стосується показників продукції;
- управління змінами та їх наслідки в ході проектування та розробки;
- визначення та коригування проблем;
- можливості для покращення процесу проектування та розробки;
- Потенційний вплив продукції на навколишнє середовище.
На відповідних стадіях організації слід також проводити аналізи виходів проектування та розробки та процесів для задоволення потреб та очікувань споживачів, а також працівників організації, які отримують вихідні дані процесу. Потрібно також приділяти увагу потребам та очікуванням інших зацікавлених сторін.
Прикладами діяльності з верифікації виходів процесу проектування та розробки є:
Порівняння вимог до входу до виходу процесу;
- застосування порівняльних методів, таких, як альтернативні розрахунки під час проектування та розробки;
- Оцінка по відношенню до аналогів;
- перевірка, моделювання та випробування з метою контролю відповідності конкретним вимогам до вхідних даних;
- оцінка уроків, що були зроблені з минулого досвіду, таких, як невідповідності та недоліки процесу.
Валідація виходів процесів проектування та розробки важлива для успішного їх отримання та використання споживачами, постачальниками, працівниками організації та іншими заінтересованими сторонами.
Участь сторін дозволяє фактичним користувачам оцінювати виходи за допомогою таких засобів, як:
Валідація технічного дизайну до конструювання, монтажу чи застосування;
- валідація виходів програмного засобу до монтажу чи використання;
- валідація послуг до їх широкого запровадження.
Може знадобитися часткова валідація вихідних даних проектування та розробки з метою забезпечення впевненості у їхньому майбутньому застосуванні.
У ході верифікації та валідації необхідно зібрати достатньо даних, що дозволяють проаналізувати методи проектування та розробки, а також прийняті рішення. Аналіз методів включає:
Поліпшення процесів та продукції;
- вихідні дані щодо застосовності;
- адекватність записів процесу та аналізу;
- Діяльність з дослідження відмов;
- Майбутні потреби процесу проектування та розробки.
ISO 9001:2000. Системи управління якістю. Вимоги 7.3.4 Аналіз проекту та розробкиНа відповідних стадіях повинен проводитися систематичний аналіз проекту та розробки відповідно до планових заходів з метою:
До складу учасників такого аналізу повинні включатися представники підрозділів, що мають відношення до аналізованої стадії проектування та розробки. Записи результатів аналізу та всіх необхідних дій мають підтримуватись у робочому стані. 7.3.5 Верифікація проекту та розробкиВерифікація повинна здійснюватися відповідно до планових заходів, щоб переконатися, що вихідні дані проектування та розробки відповідають вимогам до вхідних даних проектування та розробки. Записи результатів верифікації та всіх необхідних дій мають підтримуватись у робочому стані. 7.3.6 Валідація проекту та розробкиВалідація проекту та розробки повинна здійснюватися відповідно до планових заходів, щоб переконатися, що отримана в результаті продукція здатна відповідати вимогам до встановленого застосування або передбачуваного використання там, де це відомо. Де це практично доцільно, валідація має бути завершена до постачання чи реалізації продукції. Записи результатів валідації та всіх необхідних дій мають підтримуватись у робочому стані. 7.3.7 Управління змінами проекту та розробкиЗміни проекту та розробки мають бути ідентифіковані, а записи мають підтримуватись у робочому стані. Зміни мають бути проаналізовані, верифіковані та затверджені, якщо це доцільно, а також схвалені до внесення. Аналіз змін проекту та розробки повинен включати оцінку впливу змін на складові та поставлену продукцію. Записи результатів аналізу змін та будь-яких необхідних дій мають підтримуватись у робочому стані. |
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).
Вхідні дані, що відносяться до вимог продукції, повинні бути визначені, а записи повинні підтримуватися в робочому стані (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) до системи управління якістю.
Організація має забезпечувати достатність встановлених вимогдо закупівель до повідомлення постачальнику.