Soddisfare gli standard anche senza processi di sviluppo?

Con la revisione della ISO 9001:2015, è stato rivisto anche il requisito di un processo di sviluppo (capitolo 8.3). Mentre le sezioni "Pianificazione", "Input", "Risultati" e "Modifiche" - come precedentemente contenute nella 9001:2008 - sono state mantenute, le sezioni "Verifica", "Validazione" e "Valutazione" sono state combinate in una sezione "Controllo dello sviluppo".

Niente più esclusioni a tappeto
Il requisito generale di un processo di sviluppo esiste ancora secondo il capitolo 8.3.1. Questo allo scopo di assicurare che la successiva fornitura di un prodotto o servizio sia fondamentalmente garantita. Dopo la revisione della norma, però, con la differenza essenziale che non sono più ammesse esclusioni a tappeto. Qui diventa visibile come l'approccio basato sul rischio si intreccia con il processo di sviluppo.

Mentre in precedenza una società che non aveva un processo di sviluppo - ad esempio una tipica società commerciale - poteva escludere la sezione pertinente, questo non sarà più ammissibile in futuro. Nelle aziende che non eseguono tutti i processi da sole, questo solleva domande e porta all'incertezza.

Qual è il punteggio?
La soluzione a queste domande si trova nei primi capitoli della norma rivista. Nella sezione 4.3, le esclusioni di interi requisiti sono escluse, ma sezioni specifiche possono essere determinate come "non applicabili".

La differenza tra "esclusione" e la disposizione "non applicabile" è:

- "Non applicabile" si applica ai requisiti che non si applicano ad un'organizzazione in primo luogo, z. Ad esempio, se una tecnologia non viene utilizzata per un componente, allora anche i requisiti relativi a questa tecnologia non sono applicabili.

- eccezioni (che comunque non sono più applicabili dopo la revisione della norma), invece, significava che i requisiti erano applicabili e pertinenti, ma che non era possibile per l'organizzazione era libero di escludere il requisito, cioè di non soddisfarlo.

Per l'applicazione di "non applicabile" la norma specifica anche la seguente condizione: "La conformità si applica solo se i requisiti determinati non sono applicabili,

- non influenzano la capacità o la responsabilità dell'organizzazione,

- la conformità dei loro prodotti e servizi, e

- garantire l'aumento della soddisfazione del cliente.

Responsabilità nell'organizzazione
Con le condizioni di cui sopra, la norma intende quindi che l'azienda, che vuole applicare questo processo come "non applicabile", fondamentalmente prende attività per mantenere la capacità dei suoi prodotti e/o servizi non compromessa comunque. Cioè, la responsabilità sulle condizioni di cui sopra rimane all'organizzazione. Di conseguenza, bisogna assicurarsi che il lavoro di sviluppo necessario per loro abbia effettivamente luogo in modo sistematico (sia specificato, iniziato, commissionato e gestito). Questo per contrastare il rischio o il pericolo che il prodotto o il servizio sia compromesso e non sia garantita la conformità con i regolamenti, le norme e le leggi. Questo può anche avere un impatto negativo sulla soddisfazione dei clienti e sulle aspettative degli stakeholder a medio e lungo termine.

"Il requisito generale di un processo di sviluppo esiste ancora come da sezione 8.3.1".

E, come ci si può aspettare, quando si applicano i casi "non applicabili", la norma richiede che la condizione di cui sopra sia è giustificato, documentato e quindi verificabile.

Al contrario, l'obbligo di fornire prove significa anche che se le prove non possono essere fornite nonostante l'applicazione della classificazione "non applicabile", il requisito standard non è soddisfatto. Le conseguenze possono quindi essere: Eliminazione della deviazione attraverso l'introduzione di un processo di sviluppo, la successiva documentazione/prova del requisito o, nel caso improbabile, l'abbandono della fornitura del prodotto o servizio.

Domande guida per la pratica
Se la decisione di applicare "non applicabile" sembra ancora troppo tecnocratica, potete in alternativa farvi guidare dalle due domande seguenti:

- – Il requisito di stabilire, formulare, implementare e mantenere un processo di sviluppo è pertinente e applicabile?

- – Questo requisito (o la non conformità) influisce sulla vostra capacità o responsabilità di assicurare la conformità dei vostri prodotti e il miglioramento della soddisfazione continua del cliente?

Solo se entrambe le domande hanno una risposta negativala classificazione "non applicabile" per il processo di sviluppo è giustificata. Anche se solo la seconda domanda ha una risposta affermativa, bisogna stabilire un processo di sviluppo. Questo è indipendente da come questo criterio di norma è valutato dall'organizzazione stessa.

Per quanto riguarda l'attuazione dell'obbligo di fornire prove, l'organizzazione può, per esempio, richiedere documenti di prova pertinenti da partner commerciali come franchisor, fornitori o partner di sviluppo. Questi possono essere, per esempio, piani di sviluppo o risultati su specifiche precedenti, che vengono poi anche verificati, per esempio, nel senso di monitoraggio e controllo (rapporti di audit dei fornitori). Anche le descrizioni precise ed estese dello scopo previsto possono essere elaborate insieme. Oltre ai rischi/pericoli del prodotto o servizio, ne risulta anche una lista di misure preventive da attuare come prova.

I documenti devono essere in grado di dimostrare che l'organizzazione è responsabile del specifico prodotti e servizi in modo da avere tutte le informazioni, le competenze e le risorse per adempiere alle proprie responsabilità e la soddisfazione del cliente rimane inalterata. Soprattutto nell'industria manifatturiera e nei relativi standard industriali, questo requisito è già una pratica comune. I cosiddetti modelli a cascata, modelli V o modelli di processo agile sono spesso usati per questo scopo.

Considerando l'ambiente che cambia
Più lungo è l'orizzonte di pianificazione di un prodotto o servizio, prima deve essere considerato un cambiamento nei prodotti e servizi (rivalutazione continua). Questo afferma un altro principio. Più è probabile che i fattori di influenza cambino, più è necessario rivalutare il prodotto o servizio e, se necessario, allinearlo con i nuovi fattori di influenza. È - questo come conclusione - bene soppesare se alle due domande principali si debba davvero rispondere con un no e provare di conseguenza.

Dato che gli sviluppi in un ambiente mutevole non solo prevengono i rischi/pericoli, ma rappresentano anche un fattore di differenziazione a lungo termine, la loro omissione può significare la compromissione della capacità e della responsabilità dell'organizzazione. Di conseguenza, le aziende di successo non aspettano che questo problema si presenti per la prima volta. Investono nello sviluppo in una fase iniziale e insieme ai partner o sfruttano l'opportunità di farlo ora al più tardi.