Respecter les normes même sans processus de développement ?

Depuis la norme ISO 9001:2015, les exclusions des exigences de la norme ne sont plus possibles. Mais que faire si l'exigence standard n'est pas applicable après un processus de développement dans l'entreprise ? Cela dépend des détails.

Respecter les normes même sans processus de développement ?

 

 

 

Avec la révision de l'ISO 9001:2015, l'exigence d'un processus de développement (chapitre 8.3) a également été révisée. Alors que les sections "Planification", "Intrants", "Résultats" et "Modifications" - telles qu'elles figuraient précédemment dans la norme 9001:2008 - sont maintenues, les sections "Vérification", "Validation" et "Évaluation" ont été regroupées en une seule section "Contrôle du développement".

Plus d'exclusions générales
L'exigence générale d'un processus de développement existe toujours selon le chapitre 8.3.1. Ceci dans le but d'assurer que la fourniture ultérieure d'un produit ou d'un service est fondamentalement garantie. Après la révision de la norme, cependant, avec la différence essentielle que les exclusions globales ne sont plus autorisées. On voit ici comment l'approche fondée sur le risque est imbriquée dans le processus de développement.

 

Alors que jusqu'à présent, une entreprise qui n'avait pas de processus de développement - par exemple une société commerciale typique - pouvait exclure la section concernée, cela ne sera plus permis à l'avenir. Dans les entreprises qui ne réalisent pas elles-mêmes tous les processus, cela soulève des questions et conduit à l'incertitude.

Qu'est-ce qui s'applique maintenant ?
La solution à ces questions se trouve dans les premiers chapitres de la norme révisée. Dans la section 4.3, les exclusions de l'ensemble des exigences sont exclues, mais des sections spécifiques peuvent être déterminées comme "non applicables".

 

La différence entre "exclusion" et la disposition "non applicable" est la suivante :

 

- La mention "Non applicable" s'applique aux exigences qui ne s'appliquent pas à une organisation en premier lieu, z. Par exemple, si une technologie n'est pas utilisée pour un composant, les exigences concernant cette technologie ne sont pas non plus applicables.

 

- Exclusions (qui ne sont de toute façon plus applicables après la révision de la norme), d'autre part, signifiait que les exigences étaient applicables et pertinentes, mais qu'il n'était pas possible pour l'organisme était libre d'exclure l'exigence, c'est-à-dire de ne pas la remplir.

 

Pour l'application de la mention "non applicable", la norme précise également la condition suivante : " La conformité s'applique uniquement si les exigences qui ont été déterminées comme n'étant pas applicables,

 

- n'affectent pas la capacité ou la responsabilité de l'organisation,

 

- la conformité de leurs produits et services, et

 

- assurer l'augmentation de la satisfaction des clients.

Responsabilité dans l'organisation
Avec les conditions ci-dessus, la norme prévoit donc que l'entreprise qui veut appliquer ce processus comme "non applicable" prend des mesures pour maintenir néanmoins la capacité de ses produits et/ou services intacte. Cela signifie que la responsabilité des conditions susmentionnées incombe à l'organisation. Par conséquent, il faut veiller à ce que les travaux de développement nécessaires à cette fin aient effectivement lieu de manière systématique (soient spécifiés, initiés, mis en service et exploités). Il s'agit de contrer le risque ou le danger que le produit ou le service soit altéré et que la conformité aux règlements, règles et lois ne soit pas assurée. Cela peut avoir un impact négatif sur la satisfaction des clients et les attentes des parties prenantes à moyen et long terme.

 

"L'exigence générale d'un processus de développement existe toujours selon le chapitre 8.3.1."

 

Et comme on peut s'y attendre, lors de l'application des cas "non applicables", la norme exige que la condition ci-dessus soit justifiées, documentées et donc vérifiables.

 

Inversement, l'obligation de fournir des preuves signifie également : si les preuves ne peuvent pas être fournies malgré l'application de la classification "non applicable", l'exigence standard n'est pas remplie. Les conséquences peuvent alors être : Élimination de la déviation par l'introduction d'un processus de développement, documentation/preuve ultérieure de l'exigence ou, dans le cas peu probable, abandon de la fourniture du produit ou du service.

Questions d'orientation pour la pratique
Ceux qui trouvent encore trop technocratique la décision d'appliquer la mention "sans objet" peuvent alternativement être guidés par les deux questions suivantes :

 

- – L'exigence d'établir, d'élaborer, de mettre en œuvre et de maintenir un processus de développement est-elle pertinente et applicable ?

 

- – Cette exigence (ou non-conformité) affecte-t-elle la capacité ou la responsabilité de garantir la conformité de vos produits et l'amélioration de la satisfaction continue des clients ?

 

Seulement si les deux questions reçoivent une réponse négativela classification "non applicable" pour le processus de développement est justifiée. Même si seule la deuxième question reçoit une réponse affirmative, un processus de développement doit être établi. Ceci est indépendant de la manière dont ce critère de norme est évalué par l'organisation elle-même.

 

En ce qui concerne la mise en œuvre de l'obligation de vérification, l'organisation peut, par exemple, exiger des documents de vérification pertinents de la part des partenaires commerciaux tels que les franchiseurs, les fournisseurs ou les partenaires de développement. Il peut s'agir, par exemple, de plans de développement ou de résultats sur des spécifications antérieures, qui sont ensuite également audités, par exemple dans le sens du suivi et du contrôle (rapports d'audits de fournisseurs). Des descriptions précises et étendues de l'objectif visé peuvent également être élaborées ensemble. Outre les risques/dangers du produit ou du service, il en résulte également une liste de mesures préventives à mettre en œuvre à titre de preuve.

 

Les documents doivent pouvoir montrer que l'organisation est responsable de la béton des produits et des services de manière à disposer de toutes les informations, compétences et ressources nécessaires pour assumer ses responsabilités, sans que la satisfaction des clients en soit affectée. En particulier dans l'industrie manufacturière et les normes industrielles pertinentes, cette exigence est déjà une pratique courante. Les modèles de processus dits "waterfall", "V-models" ou "agile" sont souvent utilisés à cette fin.

Tenir compte de l'évolution de l'environnement
Plus l'horizon de planification d'un produit ou d'un service est long, plus tôt un changement de produit ou de service doit être envisagé (réévaluation continue). C'est un autre principe. Plus il est probable que les facteurs d'influence changent, plus il est nécessaire de réévaluer le produit ou le service et, si nécessaire, de l'aligner sur les nouveaux facteurs d'influence. Il est - ceci en guise de conclusion - bon de se demander si les deux questions principales doivent vraiment recevoir une réponse négative et être prouvées en conséquence.

 

Étant donné que les développements dans un environnement en mutation non seulement préviennent les risques/dangers, mais représentent également un facteur de différenciation à long terme, leur omission peut signifier la dépréciation de la capacité et de la responsabilité de l'organisation. Par conséquent, les entreprises qui réussissent n'attendent pas que cette question se pose pour la première fois. Ils investissent dans le développement à un stade précoce et avec des partenaires, ou profitent de l'occasion pour le faire maintenant au plus tard.

 

 

(Visité 2 118 fois, 1 visite aujourd'hui)

Plus d'articles sur le sujet