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

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

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

Внутрішні вхідні дані можуть включати політики, стандарти та специфікації, вимоги до кваліфікації, документацію та дані на існуючі продукти та/або послуги та вихідні дані від інших процесів.

У разі проектування та/або розробки програмного забезпечення або послуг, вхідні дані, що випливають із вимог кінцевого користувача (також як вимог прямого замовника), можуть бути особливо важливими. Такі вхідні дані повинні бути сформульовані таким чином, щоб вони могли бути ефективно проконтрольовані під час наступної верифікації та затвердження. Такі вхідні дані мають бути сформульовані таким чином, щоб вони могли бути ефектно проконтрольовані за наступної верифікації та затвердження.

Вхідні дані можуть також виникати на етапі розробки в процесі діяльності, які навіть повністю не оцінені. Також вхідні дані повинні бути предметом оцінки наступних ревю та діяльностей з верифікації та затвердження.

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

Типові приклади діяльності, пов'язані з розробкою, включають:

змінені матеріали,

змінені компоненти продукту,

нові технології надання послуг,

результати аналізів ринку.

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

ISO 9001:2000 - Системи менеджменту якості - Вимоги 7.3.2 Вхідні дані для проектування та розробки. Вимоги до продукту та/або послуги повинні бути визначені та зареєстровані (див.5.6.7). Ці вимоги повинні включати: вимоги до виконання від замовника чи ринку; застосовувані нормативні та законодавчі вимоги; вимоги до довкілля вимоги, які з попередніх подібних проектів; будь-які інші вимоги, суттєві для проектування та розробки. Ці вхідні дані повинні бути піддані ревю на адекватність або суперечливості щодо вимог, які мають бути виконані.

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

Вхідні дані, що відносяться до вимог продукції, повинні бути визначені, а записи повинні підтримуватися в робочому стані (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.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).

"ГОСТ Р 57189-2016/ISO/TS 9002:2016. Національний стандарт Російської Федерації. Системи менеджменту якості. Посібник із застосування ІСО 9001:2015 (ISO/TS 9002:2016, IDT)" (утв. Наказом Росстандарта від 25.6 N 1499-ст)

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

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

a) функціональні та експлуатаційні вимоги, визначені споживачами, потребами ринку чи організацією;

b) інформацію з попередньої аналогічної діяльності з проектування та розробки (яка може покращити результативність та дозволити організації розвивати хороші практики або уникати помилок);

c) законодавчі та нормативні правові вимоги, що стосуються безпосередньо продукції або послуги (наприклад, правил техніки безпеки, законів про харчову гігієну) або виробництва цієї продукції або послуги (наприклад, практики в процесі виробництва, транспортування або іншої техніки постачання);

d) добровільні стандарти або практичні правила, які організація ухвалила (наприклад, галузеві кодекси, санітарні норми та норми безпеки);

e) потенційні наслідкиневдач у зв'язку з характером продукції та послуг; такі невдачі можуть перебувати в діапазоні від потенційно фатальних (наприклад, погане планування безпеки дорожнього рухупри нагоді може призводити до аварій) до факторів, які призводять до втрати задоволеності споживачів (наприклад, нестійке чорнило на тканині веде до втрати кольору або фарбування).

Вхідні дані, що відносяться до вимог продукції, повинні бути визначені, а записи повинні підтримуватися в робочому стані (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) до системи управління якістю.

Організація має забезпечувати достатність встановлених вимогдо закупівель до повідомлення постачальнику.