- Ce sujet contient 10 réponses, 5 participants et a été mis à jour pour la dernière fois par
, le il y a 1 année et 1 mois.
-
Messages
-
Bonjour, je suis actuellement alternant et je travaille dans une entreprise qui souhaiterais obtenir la certification l’ISO 9001 version 2015. Mais il se trouve que certains points de la norme font de ce traitement des non-conformités une tâche plutôt ardu dans le cadre de nos activités. Nous sommes une entreprise réalisant des services plus précisément dans le domaine de la Recherche et du Développement nous réalisons donc:
– des chaînes de traitements,
– des rapports techniques,
– des logiciels.
Il se trouve que dans le cadre de nos activités nous rencontrons plusieurs problèmes qui peuvent entraîner le fait qu’un produit ou service devienne non-conforme. Mais tous ne peuvent pas être qualifié comme non-conformité même si chacun entraîne une action corrective (problèmes informatiques, beug, prestataire en retard, mise à jour logiciel etc…).
Comment puis-je définir mes actions correctives de telle façon qu’elle soit ciblée et permette l’amélioration globale du système, plutôt qu’une surcharge de travail au vu du traitement plus long des actions ?
Hello !
Mes réactions à ton message Marc :
– Il n’est pas très “admissible” de vouloir au fond “redéfinir” ce qu’est une NC du produit en particulier (un de tes exemples : bug dans un logiciel livré si j’ai bien compris) juste pour alléger la charge de travail de gestion des NC si j’ose dire… Chacune de ces NC produits doit bel et être traitée (ISO 9001, article 10.2 Non-conformité et action corrective, sous-article 10.2.1 a) ). D’ailleurs tu dis bien que chaque “problème” ainsi rencontré “entraîne une action correctrice” de ses conséquences, alors je ne perçois pas bien ce que tu entends par “tous les problèmes ne peuvent pas être qualifiés de NC” puisque ton entreprises traite déjà toutes ces(ses) NC de fait…!
– Par contre, dans le sens de ton souci d’optimisation, il faut distinguer le a) ci-dessus (correction de chaque NC) du b) du même sous-article 10.2.1 qui lui te permet “d’évaluer s’il est nécessaire de mener une action pour éliminer la ou les causes de la non-conformité” (il ne s’agit plus de ses conséquences comme en a) ): c’est prendre du recul et voir s’il est pertinent d’agir en amont (disons sur tel processus du système) pour éviter telle NC. Dans ce cadre tu peux bien mettre en place une sélection du prochain(s) type(s) de NC (Paretto ?) méritant une investigation en vue d’un traitement collectifs de leurs causes pour éviter de continuer à devoir corriger leurs conséquences individuelle en mode a), ou au moins réduire leur fréquence.
A+
Bonjour,
Je ne me suis pas bien exprimé, il se trouve qu’aujourd’hui des contrats avec certains clients exigent des fiches de suivi de problème (incidents) ou des fiches de panne de service dans le cas d’un service continu.
Or en interne sur d’autres projets ou le client n’exige aucun support les problèmes sont traités par e-mail, téléphone et un logiciel “Redmine” qui sert à allouer les tâches à chacun ou pour les chefs aussi à notifier les erreurs devant être traités.
Pour les incidents qui touchent le système et réseaux ceux-ci sont gérés par le service informatique qui fait des bilans tous les Trimestres pour voir si des problèmes peuvent être évités ou corriger lorsque qu’ils sont graves ou répétitifs.
Des problèmes rencontrés peuvent aussi être propre à certains projets.
Les Non-conformités sont aujourd’hui traités (par e-mail, Redmine, tickets via GLPI) mais nous n’avons pas de système propre en interne global pour gérer ces Non-conformités.
Est-ce que si aujourd’hui les Non-conformités restent traités de la même façon, mais que chaque chef de projet en cas de NC doit remplir un tableau simple avec la date, son nom, le descriptif de l’anomalie et l’action corrective qui à été choisi pour résoudre ce problème.Ce tableau serait propre à chaque projet et nous permettrait de lister les Non-Conformités, les Actions Correctives mises en oeuvre et de faire toutes les semaines ou tous les mois un bilan avec un plan d’action pour éviter certains dysfonctionnements ou traiter des problèmes récurrents. Celui-ci serait différent du PA établit par le service Informatique.
Car je pensais demander aux personnes de remplir des fiches de Non-conformités car il n’y a pas que les projets des NC peuvent survenir suite à une livraison d’un fournisseurs qui est Non-conforme ou un Audit non réalisé, une efficacité d’action non réalisé, des audits prévus mais non réalisés.
Mais demander à chaque Chef de Projet de remplir des fiches de non-conformité pour suivre les dysfonctionnement des projets serait aujourd’hui pas très adapté et entraînerai des retards…
Merci de prendre le temps de répondre à mes questions.
(suite)
Difficile de te conseiller vraiment comme çà en étant complètement aveugle de ta réalité mais, à part peut-être les NC juste traitées par mail voire par téléphone, et j’imagine alors que ce sont des problèmes mineurs voire négligeables que tu évoques là, si bon an mal an les NC plus significatives de différents types ou sources sont traitées plus ou moins selon le sous-article 10.2.1 (même si c’est avec des cheminements et supports différents) ma foi tu sembles cerner la question.
Encore faut-il peut-être bien identifier ces sous-processus distincts de prise en compte de NC dans ton SMQ. Et si un jour tu en éprouves le besoin (par exemple un auditeur te reprochant la multiplicité de ces sous-processus NC) tu pourras toujours envisager de les rapprocher-marier avec tes fiches de pannes-service-redline “officielles”…
D’autres avis ? A+
Bonjour Marc,
La norme ISO 9001, en version 2015, peut induire quelques erreurs de perception sur les notions de traitement et de correction.
Cependant, pour faire simple : il y a deux typologies d’actions possibles face à une non-conformité (un dysfonctionnement, un constat, un écart…) : l’action corrective immédiate (l’action de “traitement”, parfois nommée action curative) et l’action de correction de la cause.
La première est très souvent gérée, en process informatique (conception, développement…) dans les systèmes de “ticketings”, ce que semble être les applications que vous nommez. Il s’agit alors là d’un suivi de résolution des non-conformité, donc de traitement de ces non-conformités.
En cela, vous êtes raccords aux exigences de la norme.
Mais, dans un second temps, si la norme ne vous oblige pas à recourir systématiquement à une action de correction de la cause (seule action permettant de corriger durablement l’origine d’une non-conformité, ou d’une série de non-conformités), elle vous impose d’en analyser la/les cause(s) et, selon les résultats de cette analyse : d’identifier les besoins de planification d’actions correctives sur la cause.
C’est ce deuxième étage qui, lui, produit réellement l’amélioration (les autres ne sont que des “pansements”, nécessaires, mais n’assurant en rien que les non-conformités ne puissent se reproduire).
A présent : je vais parler en tant que Responsable Qualité convaincu (parce que j’ai de nombreux exemples concrets à l’appui).
Traiter les non-conformités est effectivement une tache ardue, mais nécessaire. Ne serait-ce que pour, par exemple, satisfaire les clients (au hasard…).
Instruire la recherche de cause et déployer les actions correctives réelles peut sembler tout aussi complexe, mais en réalité, elle est le seul vrai levier de l’amélioration. C’est ce seul “levier” qui permet de réduire les non-conformités dans le temps.
Mais il se heurte au moins à 3 difficultés :
– cela nécessite du temps pour, dans un second moment, reprendre ce qui est arrivé et analyser les raisons, puis, investir encore du temps pour en corriger les raisons. Souvent, sur des actions plus fines et plus longues qu’un simple traitement. C’est donc déjà une question de volonté, de stratégie. Il faut oser investir pour que cela rapporte (et cela rapport toujours plus que l’investissement, en tout cas, sur cette approche là).
– cela nécessite une remise en cause. Hé oui, la recherche de cause n’est, curieusement pas donnée à tout le monde… Il faut savoir remettre en cause ses habitudes de “depuis le temps… on sait !” (ben oui… c’est pour cela que l’on trébuche une nouvelle fois sur la même non-conformité gros malins…). il faut oser enfin raisonner en cause et on en responsabilité ou, plus français encore : en culpabilité.
– cela nécessite un certain “jusque-boutisme” dans le sens ou, si un minimum de formalisme n’est pas pris : la mémoire seule et la volonté n’y suffisent pas. La recherche de cause et l’instruction d’actions “fines” dans le temps ne peut se faire sans un minimum de planification et de suivi formel (suivi de la réalisation et, parfois des mois après, suivi de l’efficacité).
Si d’emblée, le programme de base est “comment définir des actions correctives sans surcharge de travail” : tant la communication que le résultats sont souvent destinés à l’échec.
Une démarche qualité n’est pas une surcharge de travail (enfin… si… les démarches peu inspirées peuvent être des gouffres et ont tendance à mourir d’elles-mêmes à grands cris de “c’était pas adapté pour nous” ou “l’ISO c’est de la crotte”), mais une démarche d’une parfaite logique qui consiste, pour les non -conformités, à dire :
– j’ai un pépin, j’en garde une trace et je le corrige (je grade une trace à toutes fins d’analyse ultérieures, statistiques ou unitaires et le je corrige afin que mon client ait toujours envie d’être mon client)
– j’ai eu un pépin, ou des pépins, je cherche à en comprendre la cause
– je connais la ou les causes de mes pépins : je décide de mettre en place une ou des actions correctives afin d’avoir moins de pépins et de faire des choses plus utiles avec le temps que je vais ainsi récupérer
A la deuxième proposition : “Est-ce que si aujourd’hui les Non-conformités restent traités de la même façon, mais que chaque chef de projet en cas de NC doit remplir un tableau simple avec la date, son nom, le descriptif de l’anomalie et l’action corrective qui à été choisi pour résoudre ce problème” cela peut faire avancer les choses ?
Oui s’il s’agit d’actions correctives en regard d’une cause formellement identifiée (et… intelligemment), sinon : non…
A la proposition de demander de remplir des fiches de non-conformités pour les dysfonctionnements projets : ce serait plutôt une bonne chose que d’avoir une levée de boucliers de la part des utilisateurs. En effet, le principe des fiches n’a jamais (sauf peut-être en environnement industriel “lourd”) été réellement efficace.
Mais une base de donnée, un tableau ou un support commun associé à des règles d’aiguillages de “je dois enregistrer / je ne suis pas obligé d’enregistrer” est bien plus efficace.
Hello !
Euh Thaumasia… ta “typologie des actions” possibles face à une NC” est un peu bizarre (tu sembles lier les unes à la rapidité de leur exécution mais les autres à leur cible). Leur différence cohérente c’est essentiellement leur cible : les unes portent leurs conséquences, les autres sur les causes des NC (sans considérer leurs délais d’exécution).
A+
Oui… elle peut effectivement sembler bizarre lorsque l’on zappe de la version 2008 à la version 2015 de l’ISO 9001.
Ce qui était plutôt clair “avant”, l’est un peu moins “aujourd’hui”.
Ce qui me semble essentiel à retenir c’est que :
– les actions pour corriger une situation (les actions immédiates) sont des actions de correction de la non-conformité. C’est bien, c’est nécessaire, mais ce n’est pas l’amélioration. Ce sont les réactions à court terme (ce que tu nommes “celles qui portent sur les conséquences).
– les actions faisant, ultérieurement, suite à l’analyse de cause et permettant de corriger les causes à l’origine de la non-conformité sont des actions, elles, assurant l’amélioration. Dans la grande majorité des cas, il s’agit d’un “second temps”. Elles sont souvent de plus longue haleine tant pour leur réalisation que pour les temps de vérification d’efficacité.
Hello !
Je ne vois pas bien ce qui est bizarre quand on zappe entre les versions 2008 et 2015 de l’ISO 9001 à ce sujet (les définitions de ces actions sont les mêmes). Mais tu continues à introduire une notion de délais* d’élaboration ou de réalisation des actions en question qu’il n’y a pas dans leurs définitions ou exigences ISO. Et comme tu n’utilises pas le vocabulaire ISO 9001, il est assez difficile de te comprendre (exemple : tes “actions pour corriger“, qui sont des “actions de correction” selon toi, sont-elles des “actions correctives” ou plutôt des “corrections” au sens de l’ISO ?).
* mais je suis d’accord, selon leur complexité, l’élaboration ou la réalisation de nos actions prennent plus ou moins de temps.
A+
Merci pour vos retour. J’y vois plus clair.
Je pense que dans le cas de la mise en place d’un système de traitement des non-conformités grâce à des actions d’améliorations une procédure simple ne suffira pas et il faudra sensibiliser le personnel pour réussir à faire fonctionner ce système.
Bonjour,
Je reviens sur le sujet des non conformités.
En effet, l’action corrective n’est pas une obligation.L’entreprise peut décider de pas agir face à une NC.
L’entreprise peut tracer les NC et analyser l’impact et peut décider de ne pas mettre d’action, et d’assumer le choix à la revue de direction.
Vous en pensez quoi ?
bonjour
lolla89
où est-ce qu’il est dit que l’entreprise ” peut décider de ne pas agir”? LE CHAPI 10.2.1 lire le point a ( reagir à la non-conformité) ect .
Si j’ai bien compris la norme nous demande d’identifier toutes les NC et de les traiter sauf dérogation pour acceptation du risque, par contre il n’il n’y a aucune exigence concernant la manière de faire .
salutation
- Vous devez être connecté pour répondre à ce sujet.