I dati di input relativi ai requisiti del prodotto devono essere definiti e le registrazioni devono essere mantenute. Questi dati dovrebbero includere:

a) requisiti funzionali e operativi;
b) requisiti di legge e regolamentari pertinenti;
c) ove applicabile, informazioni desunte da precedenti progetti analoghi;
d) altri requisiti importanti per la progettazione e lo sviluppo.

Questi input dovrebbero essere analizzati per verificarne l'adeguatezza. I requisiti devono essere completi, univoci e coerenti.

Output di progettazione e sviluppo

Gli output di progettazione e sviluppo devono essere in una forma che possa essere verificata rispetto agli input di progettazione e sviluppo e devono essere convalidati prima del rilascio.

Gli output di progettazione e sviluppo dovrebbero:

a) soddisfare i requisiti di input di progettazione e sviluppo;
b) fornire informazioni pertinenti su approvvigionamento, produzione e servizio;
c) contenere o fare riferimento a criteri di accettazione del prodotto;
d) determinare le caratteristiche del prodotto essenziali per la sua sicurezza e per il suo corretto utilizzo.

Analisi di progettazione e sviluppo

Nelle fasi appropriate, dovrebbe essere effettuata una revisione sistematica della progettazione e dello sviluppo in conformità con le attività pianificate al fine di:

a) valutare la capacità dei risultati della progettazione e dello sviluppo di soddisfare i requisiti;
b) identificare eventuali problemi e suggerire le azioni necessarie.

I partecipanti a tale revisione dovrebbero includere rappresentanti dei dipartimenti rilevanti per le fasi di progettazione e sviluppo in esame. Devono essere mantenute le registrazioni dei risultati dell'analisi e di tutte le azioni necessarie.

Verifica della progettazione e dello sviluppo

La verifica deve essere effettuata in conformità con le attività pianificate per garantire che gli output di progettazione e sviluppo soddisfino i requisiti di input di progettazione e sviluppo. Devono essere conservate le registrazioni dei risultati della verifica e di tutte le azioni necessarie.

Convalida della progettazione e dello sviluppo

La convalida della progettazione e dello sviluppo deve essere effettuata in conformità con le modalità pianificate per garantire che il prodotto risultante sia in grado di soddisfare i requisiti per l'uso previsto o l'uso previsto, ove noto. Ove possibile, la convalida dovrebbe essere completata prima della consegna o della vendita del prodotto. Devono essere conservate le registrazioni dei risultati della convalida e di tutte le azioni necessarie.

Gestione delle modifiche di progetto e sviluppo

Le modifiche alla progettazione e allo sviluppo devono essere identificate e le registrazioni mantenute. Le modifiche devono essere riviste, verificate e approvate, se del caso, e approvate prima dell'implementazione. L'analisi delle modifiche di progettazione e sviluppo deve includere una valutazione dell'impatto delle modifiche sulle parti costitutive e sui prodotti consegnati.

Devono essere mantenute le registrazioni dei risultati dell'analisi del cambiamento e di qualsiasi azione necessaria.

Processo di acquisto

L'organizzazione deve garantire che il prodotto acquistato sia conforme ai requisiti di acquisto. Il tipo e l'estensione del controllo applicato al fornitore e al prodotto acquistato dovrebbero dipendere dall'impatto del prodotto acquistato sulla successiva produzione del prodotto o del prodotto finito.

L'organizzazione deve valutare e selezionare i fornitori in base alla loro capacità di fornire prodotti conformi ai requisiti dell'organizzazione. Dovrebbero essere sviluppati criteri per la selezione, la valutazione e la rivalutazione. Devono essere conservate le registrazioni dei risultati della valutazione e di tutte le azioni necessarie derivanti dalla valutazione.

Informazioni sull'acquisto

Le informazioni sull'acquisto devono descrivere i prodotti ordinati, includendo, se del caso:

a) requisiti di approvazione per prodotti, procedure, processi e attrezzature;
b) requisiti di qualificazione del personale;
c) requisiti per il sistema di gestione della qualità.

L'organizzazione deve garantire che i requisiti di acquisto specificati siano adeguati prima che vengano comunicati al fornitore.

Verifica dei prodotti acquistati

L'organizzazione deve stabilire e attuare controlli o altre attività necessarie per garantire che il prodotto acquistato sia conforme a requisiti stabiliti agli acquisti.

Se l'organizzazione o il suo cliente intende svolgere attività di verifica presso la struttura del fornitore, l'organizzazione deve indicare nelle informazioni di acquisto le misure di verifica previste e il metodo di rilascio dal fornitore.

I dati di input devono essere identificati al fine di fornire una base per la formulazione dei requisiti utilizzati per verificare e validare i dati di output. I dati di input possono essere esterni e interni.

Al fine di garantire che le esigenze e le aspettative di tutte le parti interessate in relazione a un processo e/o servizio, processo o sistema siano soddisfatte, gli input di progettazione e/o sviluppo devono essere accurati e completi. La risoluzione di input ambigui o contrastanti dovrebbe essere effettuata con il coinvolgimento delle parti esterne e interne interessate.

Gli input esterni possono includere le esigenze e le aspettative dei clienti o del mercato, le specifiche delle parti interessate, i requisiti contrattuali, i requisiti normativi, gli standard internazionali o nazionali, i codici e i regolamenti del settore.

Gli input interni possono includere politiche, standard e specifiche, requisiti di qualificazione, documentazione e dati per prodotti e/o servizi esistenti e risultati di altri processi.

Nel caso di progettazione e/o sviluppo di software o servizi, gli input derivati ​​dai requisiti dell'utente finale (così come i requisiti diretti del cliente) possono essere particolarmente importanti. Tali input dovrebbero essere formulati in modo tale da poter essere efficacemente controllati per la successiva verifica e convalida. Tali input dovrebbero essere formulati in modo tale da poter essere efficacemente controllati per la successiva verifica e convalida.

I dati di input possono anche verificarsi durante la fase di sviluppo in attività che non sono nemmeno completamente valutate. Inoltre, i dati di input dovrebbero essere oggetto di valutazione per successive revisioni e attività di verifica e validazione.

Altri input identificano quelle caratteristiche di progettazione e/o sviluppo che sono fondamentali per la sicurezza e il corretto funzionamento del prodotto e/o del servizio, o identificano processi come il flusso di lavoro, lo stoccaggio, la manipolazione, il funzionamento e i requisiti di stoccaggio.

Esempi tipici di attività legate allo sviluppo includono:

materiali modificati

componenti del prodotto modificati,

nuove tecnologie per la fornitura di servizi,

risultati dell'analisi di mercato.

Gli input critici per il prodotto e/o il servizio o il processo devono essere identificati al fine di assegnare responsabilità e risorse appropriate.

ISO 9001:2000 - Sistemi di gestione per la qualità - Requisiti 7.3.2 Input di progettazione e sviluppo. I requisiti per il prodotto e/o il servizio dovrebbero essere definiti e registrati (vedere 5.6.7). Questi requisiti dovrebbero includere: requisiti prestazionali del cliente o del mercato; requisiti normativi e legali applicabili; requisiti applicabili per ambiente requisiti derivanti da precedenti progetti simili; qualsiasi altro requisito essenziale per la progettazione e lo sviluppo. Questi input devono essere rivisti per verificarne l'adeguatezza o l'incoerenza rispetto ai requisiti da soddisfare.

"GOST R 57189-2016 / ISO / TS 9002: 2016. Standard nazionale della Federazione Russa. Sistemi di gestione della qualità. Linee guida per l'applicazione di ISO 9001: 2015 (ISO / TS 9002: 2016, IDT)" (approvato dall'Ordine di Rosstandart del 25 ottobre 2016 N 1499-st)

8.3.3 Input di progettazione e sviluppo

Determinare gli input per un particolare progetto di progettazione e sviluppo è una delle attività che dovrebbero essere incluse nel piano di progettazione e sviluppo. Tali input devono essere univoci, completi e coerenti con i requisiti che definiscono le caratteristiche del prodotto o servizio. Dovrebbero includere:

a) requisiti funzionali e prestazionali definiti dai clienti, dalle esigenze del mercato o dall'organizzazione;

b) informazioni da precedenti attività simili di progettazione e sviluppo (che possono migliorare le prestazioni e consentire all'organizzazione di sviluppare buone pratiche o evitare errori);

c) requisiti legali e normativi che si riferiscono direttamente al prodotto o servizio (ad es. norme di sicurezza, leggi sull'igiene alimentare) o alla produzione di tale prodotto o servizio (ad es. pratiche all'interno del processo di produzione, trasporto o altre tecniche di consegna);

d) norme volontarie o codici di condotta che l'organizzazione ha adottato (ad es. codici di settore, codici di salute e sicurezza);

e) le potenziali conseguenze del fallimento dovute alla natura dei prodotti e dei servizi; tali guasti possono variare da quelli potenzialmente fatali (ad esempio, scarsa pianificazione della sicurezza traffico occasionalmente può portare a incidenti) a fattori che portano a una perdita di soddisfazione del cliente (ad esempio, l'inchiostro instabile sul tessuto porta a scolorimento o macchie).

Input per la progettazione e lo sviluppo

Gli input relativi ai requisiti del prodotto dovrebbero essere definiti e le registrazioni mantenute (4.2.4). Questi dati dovrebbero includere:

a) requisiti funzionali e prestazionali;

b) legislazione pertinente e Requisiti obbligatori;

c) se del caso, informazioni tratte da precedenti progetti simili;

d) altri requisiti importanti per la progettazione e lo sviluppo. Questi input dovrebbero essere analizzati per verificarne l'adeguatezza. I requisiti devono essere completi, univoci e coerenti.

Output di progettazione e sviluppo

Gli output di progettazione e sviluppo devono essere in una forma che possa essere verificata rispetto agli input di progettazione e sviluppo e devono essere convalidati prima del rilascio.

Gli output di progettazione e sviluppo dovrebbero:

a) soddisfare i requisiti di input di progettazione e sviluppo;

b) fornire informazioni pertinenti su approvvigionamento, produzione e servizio;

d) determinare le caratteristiche del prodotto essenziali per il suo uso sicuro e corretto.

Storia del lavoro nel campo della qualità in Russia.

Parlando delle migliori pratiche nel campo della gestione della qualità, non si può non ricordare la pratica domestica del miglioramento della qualità.

Quali concetti di miglioramento della qualità esistevano nel nostro paese?

1. Concetto di PIF(Fabbricazione di prodotti senza difetti) La base di questo sistema era il meccanismo di attivazione dei partecipanti processo produttivo, stimolandoli a identificare ed eliminare non i difetti del prodotto, ma le loro cause. Dopo la reiterata presentazione del prodotto, il lavoratore è stato privato del premio.

2. Il concetto di CANARSPI(Qualità, affidabilità, risorse dai primi prodotti) È stato introdotto nello stabilimento di Gorky Aviation. Riconosciuto come il migliore del paese, il sistema si basava sui seguenti principi:

versatilità (può essere utilizzato in altri settori)

Garanzia completa della qualità del prodotto

condurre ricerche volte a migliorare la qualità dei prodotti e lo sviluppo di servizi di progettazione sperimentale dell'impresa

organizzazione di una contabilità completa della qualità dei prodotti

Concentrazione sulla qualità del prodotto nella fase del suo sviluppo

Coinvolgimento dei consumatori nel miglioramento dei prodotti

1. Concetto di NORMALE A metà degli anni '60. a Yaroslavl impianto motori"Avtodiesel" ha introdotto il sistema NORM, in cui uno dei più importanti parametri tecnici- risorsa al primo revisione. Particolare attenzione è stata posta allo sviluppo del design e della tecnologia per migliorare il livello tecnico e la qualità del motore. Nel sistema NORM sono stati utilizzati e sviluppati gli elementi principali dei sistemi di gestione della qualità della produzione Saratov e Gorky.

2. Il concetto di KSUKP(Sistema completo di gestione della qualità del prodotto)

Nella prima metà degli anni '70. a seguito di un esperimento scientifico e produttivo congiunto delle imprese della regione di Lviv, dell'Istituto di ricerca tutto russo per la standardizzazione dello standard statale dell'URSS e dell'associazione scientifica e produttiva Sistema, è stato sviluppato un sistema integrato di gestione della qualità del prodotto e testato.

l'obiettivo principale del sistema era quello di garantire tassi di crescita elevati e sostenibili della qualità dei prodotti fabbricati dall'impresa, grazie a:

· creazione e sviluppo di nuovi prodotti di alta qualità;

lancio tempestivo di nuovi prodotti;

rimozione dalla produzione di prodotti obsoleti;

· miglioramento degli indicatori di qualità della produzione affittata mediante il suo miglioramento e ammodernamento.

Qual era lo specifico esperienza russa gestione della qualità?

La specificità della gestione della qualità in Russia era che nelle imprese del complesso militare-industriale (MIC) venivano creati efficaci sistemi di gestione della qualità. Fu nel complesso militare-industriale che i metodi di garanzia della qualità erano diffusi nelle fasi di ricerca e progettazione di nuovi prodotti, controllo statistico della qualità mediante carte di controllo e standard speciali. Nelle viscere del complesso militare-industriale nacque il KSUKP ( sistemi complessi gestione della qualità del prodotto, anche automatizzata).

SGQ: Gestione dei prodotti non conformi.

Metodologia per la gestione dei prodotti non conformi.

1) determinare i prodotti inclusi nel campo di applicazione del SGQ, 2) determinare quali sono i prodotti rilevanti, 3) determinare quali meccanismi di controllo sono applicabili a quali prodotti (può essere sotto forma di tabella), 4) descrivere questi meccanismi in dettaglio applicato a prodotti specifici: chi è responsabile di cosa, quali poteri ha, cosa fa.

Mentre abbiamo prodotti.

Cosa possiamo fare per garantire la conformità del prodotto quando viene rilevata una non conformità?

Il primo è ovvio: correggere. quelli. in termini di ISO 9000 per eseguire la correzione. Ma questo non è sempre possibile.

Quindi il secondo è valutare in che modo la non conformità interferisce con l'uso previsto del prodotto e, se accettabile, quindi risolvere la deviazione. Se possibile, al consumatore viene richiesto anche il permesso di discostarsi, se è d'accordo. Il cliente, dopo aver analizzato quali funzionalità mancheranno, può considerarlo del tutto accettabile e dare il permesso.

Se né la prima né la seconda sono possibili, rimane una terza opzione: modificare l'applicazione originale o rifiutare del tutto di utilizzare il prodotto.

È ovvio che la procedura per la gestione dei prodotti non conformi non può essere completamente sviluppata se

 i prodotti stessi non sono definiti, la cui qualità è controllata nell'ambito del SGQ,

 non è definito cosa sia il prodotto conforme, perché ciò equivale al fatto che il prodotto non conforme non è definito.

Dall'esperienza dell'audit: se non riesco a capire dal manuale della qualità quali prodotti specifici sono inclusi nel campo di applicazione del SGQ, allora non posso nemmeno guardare la procedura per la gestione dei prodotti non conformi, assicurandomi in anticipo che sia formale.

Meccanismi di controllo in ciascuno dei tre casi:

Cambia prodotti (correzione)

 indicare il metodo di identificazione dei prodotti non conformi e la persona responsabile di tale identificazione,

 indicare la persona responsabile di impedire il rilascio e la fornitura di prodotti non conformi identificati e la sua autorità,

 indicare la persona responsabile della correzione,

 Stabilire una procedura di ricontrollo e una persona responsabile della sua attuazione,

 stabilire la forma in cui viene effettuata la registrazione della natura della non conformità e la decisione di correggerla.

Requisiti di modifica

 identificare la rinuncia autorizzata e i suoi poteri e stabilire la procedura per tale rinuncia, compresa l'identificazione della persona autorizzata dal consumatore a concedere la rinuncia,

 Determinare la forma in cui registrare la natura della non conformità e la concessione.

Cambia applicazione

 istituire una persona responsabile per impedire il primo utilizzo di prodotti non conformi da parte del consumatore e la sua autorità, nonché una procedura per tale prevenzione,

 stabilire la forma in cui viene registrata la natura della non conformità e le azioni intraprese per impedirne la prima applicazione.

Il prodotto del consumatore.

Ovviamente, in questa situazione, nessuno dei meccanismi sopra descritti è applicabile: il prodotto è fuori dal nostro controllo. Tutto ciò che possiamo fare in questo caso è intraprendere azioni che riducano le conseguenze negative o il rischio di tali conseguenze per il consumatore. Ad esempio, qui puoi dare a tutti aziende famose per i richiami di veicoli.

7.3.1 Linee guida generali

L'alta direzione dovrebbe garantire che l'organizzazione abbia definito, implementato e mantenuto processi necessari progettare e sviluppare per rispondere in modo efficace ed efficiente alle esigenze e alle aspettative dei propri clienti e delle altre parti interessate.

Durante la progettazione e lo sviluppo di prodotti o processi, la direzione deve garantire che l'organizzazione sia in grado di tenere conto non solo del suo core business e delle sue funzioni, ma anche di tutti i fattori che contribuiscono alle prestazioni di prodotti e processi che soddisfano le aspettative dei clienti e di altri interessati feste. Ad esempio, un'organizzazione deve considerare il ciclo di vita del prodotto, la salute e la sicurezza, la testabilità, l'idoneità, la facilità d'uso, l'affidabilità, la durata, l'ergonomia, l'ambiente, lo smaltimento del prodotto e alcuni rischi.

La direzione è anche responsabile di intraprendere azioni per identificare e mitigare il rischio potenziale per gli utenti dei prodotti e dei processi dell'organizzazione. La valutazione del rischio dovrebbe essere effettuata per valutare la possibilità del loro verificarsi e le conseguenze di possibili guasti o carenze nei prodotti o nei processi. I risultati della valutazione dovrebbero essere utilizzati per determinare e attuare azioni preventive per mitigare i rischi identificati. Esempi di strumenti di valutazione del rischio di progettazione e sviluppo includono:

Analisi delle cause e delle conseguenze dei fallimenti progettuali;
- analisi dell'albero dei guasti;
- previsione di affidabilità;
- diagrammi di dipendenza;
- metodi di classificazione;
- metodi di modellazione.

7.3 Progettazione e sviluppo 7.3.1 Progettazione e pianificazione dello sviluppo L'organizzazione deve pianificare e gestire la progettazione e lo sviluppo dei prodotti. Durante la progettazione e la pianificazione dello sviluppo, l'organizzazione deve determinare: a) fasi di progettazione e sviluppo; b) effettuare l'analisi, la verifica e la validazione adeguate a ciascuna fase di progettazione e sviluppo; c) responsabilità e autorità per la progettazione e lo sviluppo. L'organizzazione deve gestire l'interazione dei vari gruppi coinvolti nella progettazione e nello sviluppo al fine di garantire una comunicazione efficace e una chiara divisione delle responsabilità. La pianificazione della fuga dovrebbe essere aggiornata, se del caso, man mano che la progettazione e lo sviluppo progrediscono.

7.3.2 Input e output per la progettazione e lo sviluppo

L'organizzazione deve identificare gli input al processo che influenzano la progettazione e lo sviluppo del prodotto e contribuiscono all'efficacia e lavoro efficace processo per soddisfare le esigenze e le aspettative dei clienti e delle altre parti interessate. Queste esigenze e aspettative esterne, combinate con le richieste interne dell'organizzazione, devono essere adatte per essere tradotte in requisiti di input per i processi di progettazione e sviluppo.

Esempi sono:

a) input esterni quali:

I bisogni e le aspettative dei consumatori o del mercato;
— le esigenze e le aspettative delle altre parti interessate;
- il contributo dei fornitori;
- input dell'utente finalizzato alla creazione di un progetto stabile e di sviluppo;
— modifiche ai pertinenti requisiti legali e regolamentari;
- norme internazionali o nazionali;
- codici di condotta industriale;

b) input interni quali:

Politica e obiettivi;
— le esigenze e le aspettative delle persone nell'organizzazione, comprese quelle che ricevono i risultati del processo;
- sviluppi tecnologici;
- requisiti per la competenza di progettisti e sviluppatori;
- feedback sull'esperienza passata;
- record e dati su processi esistenti e prodotti;
- output di altri processi;

c) input che definiscono quelle caratteristiche di processi o prodotti che sono fondamentali per la loro sicurezza, il corretto funzionamento e la manutenzione, come i dati su:

Lavoro, installazione e applicazione;
- operazioni di deposito, carico e scarico e consegna;
- parametri fisici e ambiente esterno;
- requisiti per lo smaltimento dei prodotti.

Gli input relativi al prodotto basati su una valutazione delle esigenze e delle aspettative degli utenti finali e dei consumatori diretti possono essere essenziali. Questi input devono essere formulati in modo che il prodotto possa essere verificato e convalidato in modo efficace ed efficiente.

L'output include informazioni che consentono la verifica e la convalida rispetto ai requisiti pianificati. Esempi di output di progettazione e sviluppo includono:

Dati che confermano il confronto degli input al processo con gli output del processo;
— specifiche del prodotto, compresi i criteri di accettazione;
- specifiche per il processo;
- specifiche per i materiali;
- specifiche di prova;
- requisiti per la formazione del personale;
- informazioni sull'utente e sul consumatore;
- requisiti di appalto;
- protocolli per il controllo del rispetto delle specifiche.

Gli output di progettazione e sviluppo dovrebbero essere analizzati rispetto agli input per fornire prove oggettive che gli output soddisfino in modo efficace ed efficiente i requisiti di processo e di prodotto.

ISO 9001:2000. Sistemi di gestione della qualità. Requisiti 7.3.2 Input di progettazione e sviluppo I dati di input relativi ai requisiti del prodotto devono essere definiti e le registrazioni devono essere mantenute. Questi dati dovrebbero includere: a) requisiti funzionali e operativi; b) requisiti di legge e regolamentari pertinenti; c) ove applicabile, informazioni desunte da precedenti progetti analoghi; d) altri requisiti importanti per la progettazione e lo sviluppo. Questi input dovrebbero essere analizzati per verificarne l'adeguatezza. I requisiti devono essere completi, univoci e coerenti. 7.3.3 Output di progettazione e sviluppo Gli output di progettazione e sviluppo devono essere in una forma che possa essere verificata rispetto agli input di progettazione e sviluppo e devono essere convalidati prima del rilascio. Gli output di progettazione e sviluppo dovrebbero: a) soddisfare i requisiti di input di progettazione e sviluppo; b) fornire informazioni pertinenti su approvvigionamento, produzione e servizio; c) contenere o fare riferimento a criteri di accettazione del prodotto; d) determinare le caratteristiche del prodotto essenziali per la sua sicurezza e per il suo corretto utilizzo.

7.3.3 Revisione della progettazione e dello sviluppo

L'alta direzione deve garantire che le persone appropriate siano assegnate per gestire e condurre revisioni sistematiche per stabilire che gli obiettivi di progettazione e sviluppo siano stati raggiunti.

Tali revisioni possono essere effettuate in punti selezionati del processo di progettazione e sviluppo, nonché dopo che è stato completato.

Gli oggetti di tali analisi sono:

Adeguatezza degli input per completare le attività di progettazione e sviluppo;
— lo stato di avanzamento del processo di progettazione e sviluppo pianificato;
— rispetto degli obiettivi di verifica e validazione;
- valutazione di potenziali rischi o cause di malfunzionamenti nell'utilizzo dei prodotti;
- dati ciclo vitale relative alle caratteristiche del prodotto;
— gestire il cambiamento e le sue conseguenze durante la progettazione e lo sviluppo;
- identificazione e correzione dei problemi;
— opportunità per migliorare il processo di progettazione e sviluppo;
- il potenziale impatto del prodotto sull'ambiente.

Nelle fasi appropriate, l'organizzazione dovrebbe anche condurre analisi degli output e dei processi di progettazione e sviluppo per soddisfare le esigenze e le aspettative dei clienti e quelle dell'organizzazione che riceve gli output dei processi. Occorre inoltre tenere conto delle esigenze e delle aspettative degli altri soggetti interessati.

Esempi di attività per verificare gli output del processo di progettazione e sviluppo sono:

Confronto dei requisiti di input rispetto all'output del processo;
- applicazione di metodi comparativi, come calcoli alternativi nella progettazione e nello sviluppo;
- valutazione in relazione agli analoghi;
- verifica, simulazione e collaudo per controllare il rispetto di requisiti specifici per i dati di input;
— valutazione delle lezioni apprese dall'esperienza passata, come incoerenze e carenze di processo.

La convalida degli output dei processi di progettazione e sviluppo è importante per la loro corretta acquisizione e utilizzo da parte di clienti, fornitori, dipendenti dell'organizzazione e altre parti interessate.

La partecipazione del partito consente agli utenti effettivi di valutare i risultati attraverso mezzi quali:

Convalida tecnica del progetto prima della costruzione, installazione o applicazione;
— convalida dei risultati del software prima dell'installazione o dell'uso;
- Convalida dei servizi prima che vengano ampiamente introdotti.

Potrebbe essere necessaria una convalida parziale degli output di progettazione e sviluppo per fornire fiducia nella loro futura applicazione.

La verifica e la convalida dovrebbero raccogliere dati sufficienti per consentire l'analisi dei metodi di progettazione e sviluppo e decisioni prese. L'analisi del metodo include:

Miglioramento di processi e prodotti;
- dati di output sull'applicabilità;
— adeguatezza delle registrazioni e delle analisi dei processi;
— attività di indagine sui guasti;
- esigenze future del processo di progettazione e sviluppo.

ISO 9001:2000. Sistemi di gestione della qualità. Requisiti 7.3.4 Revisione della progettazione e dello sviluppo Nelle fasi appropriate, dovrebbe essere effettuata una revisione sistematica della progettazione e dello sviluppo in conformità con le attività pianificate al fine di: a) valutare la capacità dei risultati della progettazione e dello sviluppo di soddisfare i requisiti; b) identificare eventuali problemi e suggerire le azioni necessarie. I partecipanti a tale revisione dovrebbero includere rappresentanti dei dipartimenti rilevanti per le fasi di progettazione e sviluppo in esame. Devono essere mantenute le registrazioni dei risultati dell'analisi e di tutte le azioni necessarie. 7.3.5 Verifica della progettazione e dello sviluppo La verifica deve essere effettuata in conformità con le attività pianificate per garantire che gli output di progettazione e sviluppo soddisfino i requisiti di input di progettazione e sviluppo. Devono essere conservate le registrazioni dei risultati della verifica e di tutte le azioni necessarie. 7.3.6 Convalida della progettazione e dello sviluppo La convalida della progettazione e dello sviluppo deve essere effettuata in conformità con le modalità pianificate per garantire che il prodotto risultante sia in grado di soddisfare i requisiti per l'uso previsto o l'uso previsto, ove noto. Ove possibile, la convalida dovrebbe essere completata prima della consegna o della vendita del prodotto. Devono essere conservate le registrazioni dei risultati della convalida e di tutte le azioni necessarie. 7.3.7 Controllo delle modifiche di progettazione e sviluppo Le modifiche alla progettazione e allo sviluppo devono essere identificate e le registrazioni mantenute. Le modifiche devono essere riviste, verificate e approvate, se del caso, e approvate prima dell'implementazione. L'analisi delle modifiche di progettazione e sviluppo deve includere una valutazione dell'impatto delle modifiche sulle parti costitutive e sui prodotti consegnati. Devono essere mantenute le registrazioni dei risultati dell'analisi del cambiamento e di qualsiasi azione necessaria.