![\"Soddisfare](\"https:\/\/www.m-q.ch\/wp-content\/uploads\/2021\/02\/Norm-erfuellen-auch-ohne-Entwicklungsprozesse.jpg\")
<\/p>\n<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
Con la revisione della ISO 9001:2015, \u00e8 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\".<\/p>\n
Niente pi\u00f9 esclusioni a tappeto <\/strong> <\/p>\n Mentre in precedenza una societ\u00e0 che non aveva un processo di sviluppo - ad esempio una tipica societ\u00e0 commerciale - poteva escludere la sezione pertinente, questo non sar\u00e0 pi\u00f9 ammissibile in futuro. Nelle aziende che non eseguono tutti i processi da sole, questo solleva domande e porta all'incertezza.<\/p>\n Qual \u00e8 il punteggio? <\/strong> <\/p>\n La differenza tra \"esclusione\" e la disposizione \"non applicabile\" \u00e8:<\/strong><\/em><\/p>\n <\/p>\n - \"Non applicabile\" si applica ai requisiti che non si applicano ad un'organizzazione in primo luogo,<\/strong><\/em> z. Ad esempio, se una tecnologia non viene utilizzata per un componente, allora anche i requisiti relativi a questa tecnologia non sono applicabili.<\/p>\n <\/p>\n - eccezioni<\/strong><\/em> (che comunque non sono pi\u00f9 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\u00e8 di non soddisfarlo.<\/strong><\/em><\/p>\n <\/p>\n Per l'applicazione di \"non applicabile\" la norma specifica anche la seguente condizione: \"La conformit\u00e0 si applica solo se i requisiti determinati non sono applicabili,<\/strong><\/em><\/p>\n <\/p>\n - non influenzano la capacit\u00e0 o la responsabilit\u00e0 dell'organizzazione, <\/strong><\/em><\/p>\n <\/p>\n - la conformit\u00e0 dei loro prodotti e servizi, e <\/strong><\/em><\/p>\n <\/p>\n - garantire l'aumento della soddisfazione del cliente.<\/strong><\/em><\/p>\n Responsabilit\u00e0 nell'organizzazione<\/strong> <\/p>\n \"Il requisito generale di un processo di sviluppo esiste ancora come da sezione 8.3.1\".<\/strong><\/em><\/p>\n <\/p>\n E, come ci si pu\u00f2 aspettare, quando si applicano i casi \"non applicabili\", la norma richiede che la condizione di cui sopra sia \u00e8 giustificato, documentato e quindi verificabile.<\/strong><\/em><\/p>\n <\/p>\n 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 \u00e8 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.<\/p>\n Domande guida per la pratica <\/strong> <\/p>\n - \u2013<\/strong> <\/em>Il requisito di stabilire, formulare, implementare e mantenere un processo di sviluppo \u00e8 pertinente e applicabile?<\/p>\n <\/p>\n - \u2013<\/strong> <\/em>Questo requisito (o la non conformit\u00e0) influisce sulla vostra capacit\u00e0 o responsabilit\u00e0 di assicurare la conformit\u00e0 dei vostri prodotti e il miglioramento della soddisfazione continua del cliente?<\/p>\n <\/p>\n Solo se entrambe le domande hanno una risposta negativa<\/strong><\/em>la classificazione \"non applicabile\" per il processo di sviluppo \u00e8 giustificata. Anche se solo la seconda domanda ha una risposta affermativa, bisogna stabilire un processo di sviluppo. Questo \u00e8 indipendente da come questo criterio di norma \u00e8 valutato dall'organizzazione stessa.<\/p>\n <\/p>\n Per quanto riguarda l'attuazione dell'obbligo di fornire prove, l'organizzazione pu\u00f2, 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.<\/p>\n <\/p>\n I documenti devono essere in grado di dimostrare che l'organizzazione \u00e8 responsabile del specifico<\/strong> <\/em>prodotti e servizi in modo da avere tutte le informazioni, le competenze e le risorse per adempiere alle proprie responsabilit\u00e0 e la soddisfazione del cliente rimane inalterata. Soprattutto nell'industria manifatturiera e nei relativi standard industriali, questo requisito \u00e8 gi\u00e0 una pratica comune. I cosiddetti modelli a cascata, modelli V o modelli di processo agile sono spesso usati per questo scopo.<\/p>\n Considerando l'ambiente che cambia <\/strong> <\/p>\n 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\u00f2 significare la compromissione della capacit\u00e0 e della responsabilit\u00e0 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\u00e0 di farlo ora al pi\u00f9 tardi.<\/p>\n <\/p>\n <\/p>","protected":false},"excerpt":{"rendered":" Mit der Normrevision ISO 9001:2015 hat auch die Forderung nach einem Entwicklungsprozess (Kapitel 8.3) eine \u00dcberarbeitung erfahren. W\u00e4hrend die \u2013 wie bisher in 9001:2008 enthaltenen \u2013 Abschnitte \u00abPlanung\u00bb, \u00abEingaben \u00bb, \u00abErgebnisse\u00bb und \u00ab\u00c4nderungen\u00bb erhalten bleiben, wurden die Abschnitte \u00abVerifizierung \u00bb, \u00abValidierung\u00bb sowie \u00abBewertung\u00bb in einem Abschnitt \u00abEntwicklungssteuerung\u00bb zusammengefasst. Keine pauschalen Ausschl\u00fcsse mehr […]<\/p>\n","protected":false},"author":62,"featured_media":11618,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[5],"tags":[4780],"class_list":["post-11592","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-business_excellence","tag-10-2017"],"acf":[],"yoast_head":"\n
\nIl 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\u00f2, con la differenza essenziale che non sono pi\u00f9 ammesse esclusioni a tappeto. Qui diventa visibile come l'approccio basato sul rischio si intreccia con il processo di sviluppo.<\/p>\n
\nLa 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\".<\/p>\n
\nCon le condizioni di cui sopra, la norma intende quindi che l'azienda, che vuole applicare questo processo come \"non applicabile\", fondamentalmente prende attivit\u00e0 per mantenere la capacit\u00e0 dei suoi prodotti e\/o servizi non compromessa comunque. Cio\u00e8, la responsabilit\u00e0 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\u00e0 con i regolamenti, le norme e le leggi. Questo pu\u00f2 anche avere un impatto negativo sulla soddisfazione dei clienti e sulle aspettative degli stakeholder a medio e lungo termine.<\/p>\n
\nSe la decisione di applicare \"non applicabile\" sembra ancora troppo tecnocratica, potete in alternativa farvi guidare dalle due domande seguenti:<\/p>\n
\nPi\u00f9 lungo \u00e8 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\u00f9 \u00e8 probabile che i fattori di influenza cambino, pi\u00f9 \u00e8 necessario rivalutare il prodotto o servizio e, se necessario, allinearlo con i nuovi fattori di influenza. \u00c8 - questo come conclusione - bene soppesare se alle due domande principali si debba davvero rispondere con un no e provare di conseguenza.<\/p>\n