Toutes mes réponses sur les forums
-
Messages
-
Bonjour Henri,
J’ai dans l’intention de répondre à Matthias et de lui permettre de progresser sans passer trop de temps en anicroches ou comptage du nombre de posts… parti comme cela : vous pourrez en profiter pour gagner en compréhension des normes que vous commentez régulièrement
Plus par “utilité” que par nécessité de couverture des exigences (mais cela ne fera pas de mal “aux exigence” de la norme), vous pouvez aussi intégrer :
– l’identification claire des validations de type GO / NO GO
– les risques initiaux (et révisables)
– les données de sorties et/ou livrables
Bonjour,
Cela dépend des métriques qui sont définis ou peuvent être définis dans votre système.
Pouvez-vous nous en dire plus sur votre contexte s’il vous plait ? (type de prestation / production, quantités, domaine…origine de cette question et, si besoin, explication du “pourquoi” cette définition n’existe pas de manière simple et accessible dans votre organisme).
En effet, un taux de rebut est tout à fait la définition qui en a été faite précédemment.
Un taux de non-conformités peut avoir une définition variable selon votre contexte…
Bonjour Matthias,
Progressons pas à pas… à commencer par le paragraphe 4. Je vous vous propose de vous détailler le formalisme minimum et/ou nécessaire et vous m’interrogerez sur ce que vous n’avez pas compris.
Nous passerons au paragraphe suivant ensuite.4.1 Compréhension de l’organisme et de son contexte
Les informations relatives au enjeux internes et externes sont à surveiller et à revoir. Difficile de le faire, et encore plus de le prouver, sans un formalisme basic (à minima en revue de Direction). Ces enjeux sont donc à formaliser, par exemple par une approche PESTEL (une bonne réflexion de base pour commencer, mais ce n’est qu’une approche parmi tant d’autres), un tableau simple fera amplement l’affaire et doit, en premier lieu, être un support de réflexion de/avec la Direction afin d’assurer la cohérence des objectifs et des actions du système de management avec les stratégies de l’entreprise (sur les thématiques identifiées, notamment, avec cet exemple d’approche).
4.2 Compréhension des besoins et des attentes des parties intéressées
Les parties intéressées sont, afin d’en comprendre les attentes, à déterminer (leurs exigences aussi). Là encore : pas évident de le faire, d’avoir une réflexion, d’identifier des besoins d’actions ou non et de démontrer ces dispositions sans un minimum de formalisme. Plutôt que des mots, je vous propose de regarder ceci : http://www.youtube.com/watch?v=HMdWrxUU6vM
4.3 Détermination du domaine d’application du système de management de la qualité
Cela est aussi simple que stratégique, il vous faut définir clairement le périmètre de votre organisme sur lequel vous déployez un système de management conforme à votre norme de référence. C’est très souvent le « texte » qui se trouvera en toutes lettres sur votre certificat une fois la certification obtenue. Si vous optez pour un manuel qualité (voir nos précédents échanges à ce sujet sur ce forum) : ce sera le meilleur endroit pour formaliser « la chose » sans devoir créer un document qui se balade…
4.4 Système de management de la qualité et ses processus
Vous devez déterminer les processus (ils sont donc formalisés et ce formalisme est tenu à jour tant que nécessaire) en accompagnant cette détermination par des données spécifiques, tout est décrit ici : http://www.youtube.com/watch?v=cGZv_zwalSc
Le système est à tenir à jour, c’est tout ce qui est nécessaire à conserver de ces exigences. Concernant le 4.4.2 sur les « informations documentées pour avoir l’assurance… », tout cela est largement redemandé plus loin dans la norme.
Jusque là : avez-vous des questions ?
Bonjour,
Vous aurez à justifier, lors de votre prochain audit (triennal ou visite de surveillance) de l’analyse et de la correction de ce constat.
En l’absence de réponse : il sera, cette fois, surclassé en non conformité mineure avec les conséquences connues.
Bonsoir,
Matthias : ne vous attardez pas trop sur la liste ci-dessus. Je comprends Henri dans la réponse nécessaire à apporter, mais il y a quelques bugs dans ce qui est listé et une présentation qui ne vous fera pas comprendre ce qui est requis.
Je prendrais un moment samedi pour vous établir une liste, bien que… “avez-vous” et “avez-vous lu la norme ISO 9001:2015” Matthias ?
Bonjour,
Oui, régulièrement, mais au travers de l’ISO 27001 (ce qui, de fait, interdit toute communication de contenu).
En revanche, un premier pas peut être de vous pencher sur les déploiements de telles normes (et leur contenu) au sein de ces entreprises. En sachant que, quels que soient les secteurs, les principes de sécurisation et de maîtrise des données sont globalement les mêmes.
Bonjour,
Questions intéressantes… nous avons pour habitude de dire qu’une démarche de déploiement et de maintien de système de management c’est, pour plus de la moitié des efforts ou des investissements : une démarche de communication avant tout…
Oui, elle semble tout à fait possible. Cependant, avec si peu d’éléments de contexte, c’est un “oui” de principe.
Il m’intéresserait cependant de comprendre pourquoi vous pensiez que cela n’était pas possible. Est-ce qu’il y a un paramètre particulier de votre environnement qui vous apparaît rendre cette démarche “compliquée” ?
Il est plus facile d’intégrer un système (deux en l’occurrence) que de les concevoir séparément. Plus facile dans la construction, dans la gestion et dans le maintien.
Quelles sont les raisons vous faisant penser que cela n’est pas possible ?
Bonjour,
Quel est, plus précisément, votre contexte (nombre de collaborateurs, typologie de prestations et de clients…) ?
Bonjour,
En premier lieu, vous pouvez déjà faire un croisement entre ces deux normes et identifier (dans un tableau à deux entrées par exemple) les exigences communes (politique, maîtrise des informations, audit, revue de Direction…).
Cela vous permettra de faire des choix dans la manière de construire un système commun (intégré) et vous donnera les premières pistes de l’extension “aux processus” de votre système de management.
Bonjour,
A priori, les exigences n’ayant pas pour vocation à devenir des processus : vous n’avez pas de raison de créer un processus (il n’en serait pas de même si vous étiez, par exemple, un centre de recherche et développement dont la part de conception serait la majorité de votre activité).
Et dans ce cas, oui : une fiche projet sera amplement suffisante.
Alors… oui sur le principe.
A retenir : hormis les procédures obligatoires qui ne le sont plus, les exigences de cette norme ont de tout temps (et sont toujours) de formaliser ce qui, en l’absence de formalisme, peut représenter un risque (risque de transmission de l’information, de compréhension, de mise à jour…). Aussi, il est important de retenir le fait que les choses ne s’apprécient pas en termes de “minimums”, mais en termes de “nécessaire”. Ce nécessaire est cadré par des contextes, dimensions, compétences, complexités…
A maîtriser : les informations documentées sont donc, sans exception, à établir. Mais en cas de défaillance (incomplétude ou non disponibilité), le risque d’écart et les impacts sont plus compliqués lorsqu’il n’y a pas de procédure pour encadrer une information documentée que lorsqu’il y en a une.
