Progettazione e Sviluppo, Semplifichiamo

Sembra esserci molta confusione nel riconoscere quando la progettazione e lo sviluppo sono o non sono parte del sistema di gestione e, in relazione a quest'ultimo, se la non applicabilità del requisito può essere giustificata. Posso dire che, per esperienza personale, molti auditor si astengono da questa clausola o semplicemente non lo fanno correttamente, storicamente incluso me stesso! Ma affrontandola in piccoli passi, è davvero così scoraggiante come sembra?

Innanzitutto iniziamo guardiamo i termini e applichiamo il loro significato nel contesto dello standard:

Progettazione

La definizione di progetto è "un piano o un disegno prodotto per mostrare l'aspetto e la funzione o il funzionamento di un edificio o di un altro oggetto prima di essere realizzato". Semplicemente inserito nel contesto; se l'organizzazione sta creando qualcosa, sia esso tangibile (prodotto) o intangibile (servizio), ci sarà quasi certamente un elemento di progetto.

In tali casi, deve essere applicata la clausola 8.3. Anche se il cliente non progetta nulla fisicamente da sé ed esternalizza il processo - le responsabilità non possono essere esternalizzate, l'organizzazione deve applicare i controlli necessari (vedere la clausola 8.4.1-a). Il punto da ricordare è: chi lo paga?

Sviluppo

Ci sono alcuni esempi di "vita reale" che potresti aver riscontrato durante l'audit...Un'organizzazione fornisce un prodotto o un servizio esistente ma è necessario apportare modifiche per migliorare le prestazioni o soddisfare i requisiti specifici di un cliente; questo è lo sviluppo.

Un'altra organizzazione potrebbe definire criteri di accettazione attraverso prove ed errori; ancora, questo è sviluppo. Puoi visitare un'organizzazione che ha un processo consolidato ma che ha bisogno di modificarlo per ottenere un risultato diverso o migliore...Hai indovinato - sviluppo.

Non applicabilità e giustificazione

Inutile dirlo, ma se l'organizzazione sta conducendo una delle attività di cui sopra, non può giustificare la non applicabilità di "Progettazione e sviluppo di prodotti e servizi" nel suo sistema di gestione. La non applicabilità potrebbe essere giustificata se l'organizzazione fornisse un prodotto o un servizio che è ben consolidato o il suo progetto è fisso e non richiede ulteriori modifiche o sviluppi.

Ero ad un audit in cui il cliente aveva escluso la clausola 8.3 dal proprio sistema di gestione. La giustificazione era che stavano "facendo in modo che il prodotto rispondesse alle esigenze del cliente"; stavano modificando le caratteristiche del prodotto per soddisfare le esigenze del cliente per l'applicazione prevista. Anche se il prodotto in sé non è mai stato effettivamente cambiato, stavano prendendo una formula esistente e cambiando le specifiche per soddisfare le esigenze del cliente: suona familiare?

Questo è lo sviluppo. È importante ricordare che tutta la progettazione e lo sviluppo iniziano con un input e solo perché quell'input proviene da una fonte esterna, non significa che l'organizzazione non sia responsabile per il controllo della progettazione e sviluppo del processo di prodotti e servizi.
 
Il processo di auditing è semplice, ci sono cinque passaggi che devono essere considerati:

Pianificazione - semplicemente, l'organizzazione avrà un piano su come faranno la progettazione e lo sviluppo. Un buon esempio di ciò potrebbe essere: un piano di progettazione/sviluppo che dimostri: i tempi del progetto, i risultati, le responsabilità di team/individui, incaricati all'approvazione (interni o esterni), revisioni di progetto nei punti rilevanti del progetto (es. avvio, conferma degli input, verifica, convalida, finitura, ecc.), risorse richieste durante il progetto, comunicazione con i successivi proprietari dei processi e controlli richiesti durante tutto il progetto e uso previsto dell'output.

Input - ci sono una moltitudine di potenziali input per il processo: l'organizzazione ha confermato i requisiti del cliente (cosa vogliono ottenere e quali sono le sue esigenze e aspettative) e ha considerato parametri e vincoli (ad es. materiali, dimensioni, funzionalità, ciclo di vita, sostenibilità, ecc.), sono stati presi in considerazione requisiti di legge o regolamentari o codici di condotta (direttive sul prodotto e sulla sicurezza, regolamenti di costruzione, ecc.), disponibilità di informazioni da progetti precedenti (revisione degli insegnamenti - buoni/cattivi/potenziali miglioramenti, ecc.) che forniscono dati e conoscenze inestimabili per mitigare il rischio e le conseguenze del fallimento.
 
Controlli - Un passaggio fondamentale nel processo: l'organizzazione ha determinato come vengono definiti i risultati da raggiungere: quali sono i risultati del progetto, come saranno raggiunti e come saranno misurati (criteri di accettazione). Sono state condotte revisioni in tutto il progetto come menzionato sopra nei punti rilevanti al fine di soddisfare i requisiti di input?

Verifica - è il prodotto/servizio progettato/sviluppato come previsto in relazione ai requisiti di input, questo può essere verificato attraverso diversi tipi di test (ad esempio prototipo, prova, dimostrazione, ispezione, analisi o accettazione).

Validazione - il prodotto/servizio è stato progettato/sviluppato in modo tale da soddisfare i requisiti del suo uso previsto, molto probabilmente verificato una volta raggiunti i risultati finali. Ad esempio: test in condizioni operative, per verificare che il prodotto/servizio soddisfi i requisiti del cliente e che copra tutti gli output, compresi i potenziali rischi di utilizzo. Condurre le revisioni dopo la verifica e la convalida al fine di appianare eventuali problemi potenziali - questi sono tutti requisiti critici dei controlli di progettazione e sviluppo e devono essere documentati in qualche forma.
 
Output - far sì che l'organizzazione abbia soddisfatto i requisiti di input (raggiunto i risultati attesi), possa avanzare nel progetto utilizzando gli output, aver confermato qualsiasi apparecchiatura necessaria per la misurazione e/o i test e i criteri di accettazione. Esempi tipici di tali risultati includono: progetti concettuali, disegni tecnici/ingegneristici, specifiche di prodotto, istruzioni di fabbricazione, distinte materiali, informazioni per l'acquisto e altri processi successivi.
 
Modifiche - far stabilire all'organizzazione un processo formale per il controllo delle modifiche di progettazione e sviluppo; durante tutto il progetto e durante le revisioni, in che modo sono stati documentati i cambiamenti, sono stati comunicati i risultati delle revisioni di progettazione e sviluppo. Come vengono autorizzate le modifiche (si pensi alle persone incaricate alle autorizzazioni, come sopra), come possono essere identificate le revisioni più aggiornate e mitigare il rischio di utilizzare versioni sostituite? Esempi di ciò sono: controllo versione/revisione/autorizzazione su disegni, un registro progetto/disegno, note di modifica tecnica, ecc.
 
Specifiche informazioni documentate sono richieste dalla norma nelle fasi rilevanti del processo di progettazione e sviluppo al fine di dimostrare la conformità.
 
In sintesi, non tutti devono essere esperti di progettazione e sviluppo concettuale/ingegneristico per comprendere i requisiti e come controllarli efficacemente. Finché seguiremo il nostro processo, come sopra, e applicheremo un'interpretazione competente dello standard, ma flessibile rispetto al contesto dell'organizzazione, questa clausola è in realtà molto più semplice di quello che sembra.
 
Autore Alan Michael Gould - NQA UK Regional Assessor