Qu'est-ce qui a inspiré cette demande de liste de souhaits ?
Les groupes de contrôle des processus de mes entreprises utilisent de plus en plus la plateforme Process Screening et le taux d'alarme devient une mesure clé pour nous. De plus, nous utilisons de plus en plus de diagrammes à trois voies, et il est tout aussi important sur les diagrammes à trois voies de suivre et de comprendre le taux d'alarme sur les diagrammes intérieurs que sur les diagrammes moyens.En essayant de comparer les résultats entre les plateformes ainsi que les résultats attendus, nous avons constaté des écarts.
J'ai travaillé avec @PatrickGiuliano au support technique JMP pour déterminer comment la plate-forme a été conçue pour fonctionner par rapport aux objectifs demandés.
Quelle est l’amélioration que vous souhaiteriez voir ?
La section de taux d'alarme de la plateforme Process Screening (PS) est un excellent moyen de déterminer quel processus attaquer en premier ainsi que de suivre les changements de performances au fil du temps tout en étant capable de visualiser rapidement les tendances.J'aimerais voir ce qui suit :
- Les colonnes « Colonne de taux d'alarme » et « Toute alarme » doivent respecter tous les taux d'alarme sélectionnés tels que calculés à partir des limites de contrôle supérieure et inférieure.Actuellement, ils calculent uniquement les deux limites de contrôle pour le graphique moyen (ainsi que tout autre test), mais uniquement la limite de contrôle supérieure pour la « Limite de plage dépassée » lorsqu'un graphique à trois voies est sélectionné.
- Le non-respect de la LCL entraîne des taux d'alarme différents lors de la visualisation d'un processus dans le générateur PS vs Control Chart.Cela crée également des cartes de contrôle d'apparence différente de celle du générateur de cartes de contrôle lorsque vous utilisez "Afficher la carte telle que sélectionnée" dans le PS et que vous ajoutez la carte de dispersion car seule l'UCL est affichée.
- Les noms des graphiques de dispersion devraient être modifiés pour être plus clairs.« Limite de plage dépassée » doit aller à « Limite d'affichage dépassée » et être utilisée avec les cartes MR/-R/-S/trois voies S/R et « 3W MR Limite dépassée » doit être utilisée pour les cartes MR sur les cartes à trois voies.
- Les taux d'alarme et le nombre d'alarmes ne doivent pas être la somme des taux d'alarme pour chaque colonne « Test » et trois voies « Limite de plage dépassée ».Ils ne doivent résumer qu'à travers un sous-groupe (donc si un sous-groupe échoue à un "test" sur le graphique moyen ou si le graphique de dispersion du sous-groupe dépasse une limite de contrôle, cela ne devrait que +1 la valeur de la colonne "Toute alarme" et ajouter uniquement + 1 au numérateur dans la colonne "Taux d'alarme".Par exemple, si le sous-groupe 2 (sur 10) échoue pour la moyenne et les 3 voies dans les diagrammes de dispersion UCL et qu'il est le seul sous-groupe à échouer, le « taux d'alarme » doit être de 10 % et « toute alarme » doit être de 1. Actuellement cela donnerait 20 % et 2, ce qui donne une idée trompeuse du processus.
- Étant donné que l'objectif de Process Screening est d'être une sorte de guichet unique pour une vue d'ensemble de tous vos processus, il serait avantageux pour les utilisateurs que la plateforme ait le taux d'alarme global reflétant tous les types d'alarme sélectionnés par l'utilisateur.(Donc, j'aimerais voir un taux d'alarme de moyens, un taux d'alarme MR, un taux d'alarme Range Within et un taux d'alarme global qui signale tous les tests sélectionnés par les utilisateurs pour signaler un sous-groupe comme défectueux {MR pour un I- Le graphique MR peut être exclu ici car il s'étend sur "deux sous-groupes}).
À quoi cela pourrait ressembler :
Remarque : restez cohérent avec Control Chart Builder en utilisant « Tester tout au-delà des limites - Tous » plutôt que « Activer tous les tests » pourrait mieux fonctionner.J'ai remarqué cela après avoir fait cette photo ci-dessus.
Dans l'image ci-dessous, vous pouvez voir les deux problèmes pour les éléments 1 et 3 :
- Il n'y a pas de limites de contrôle inférieures sur aucune des cartes de dispersion et la plateforme ne respecte aucune violation de la LCL (ce qui pose problème pour -R ou -S ou pour les cartes intérieures dans les cartes à trois voies) et conduit ainsi à une taux d'alarme incorrect.
- Pour le sous-groupe électricité, il est hors de contrôle à la fois pour la barre X et la plage dans les graphiques et est donc compté comme deux alarmes, alors qu'il ne devrait être compté que pour une (puisque le dénominateur est le nombre de sous-groupes).Ainsi, le taux d’alarme devrait être de 3/17 et non de 4/17.
Si, pour une raison quelconque, l'élément 1 ci-dessus ne peut pas être ajouté, à tout le moins, alors les noms doivent être remplacés par « » Supérieur limite de plage de déplacement dépassée » et « Supérieur limite de plage dépassée » afin que l'utilisateur ne suppose pas qu'ils incluent les deux en raison de la convention de dénomination actuelle.
Pourquoi cette idée est-elle importante ?Ceci est important pour les raisons suivantes :
- Vous devriez obtenir les mêmes résultats à la fois avec Control Chart Builder et Process Screening, d'autant plus que Process Screening vous enverra au Control Chart Builder en tant que fonctionnalité disponible dans la plate-forme.
- Le suivi et la compréhension des variations au sein du processus sont tout aussi importants que les variations entre les moyennes et sont particulièrement critiques lors de l'utilisation de diagrammes à trois voies.
- Différentes entreprises auront des priorités différentes quant à l'importance des taux d'alarme et le groupe d'utilisateurs devrait donc être en mesure de contrôler ce qui doit être affiché dans la plateforme Process Screening (par exemple, s'il faut activer ou désactiver les LCL dans les graphiques MR et R).
Ouf, j'espère que cela a été clair.S'il vous plaît laissez-moi savoir si j'ai besoin de clarifier quelque chose !
Steve
Merci pour votre engagement @shampton82 !
J'ai quelques commentaires mineurs.
Concernant votre discussion sur le calcul du taux d'alarme. Je pense que cela doit être clarifié directement pour l'utilisateur de la plate-forme, sous forme d'info-bulle, de bouton de divulgation ou similaire ; comment il est calculé.Je ne suis pas non plus en désaccord avec vos réflexions sur le calcul - et je suis d'accord qu'il devrait s'aligner sur Control Chart Builder, surtout si la plate-forme est conçue pour pouvoir contrôler Chart Builder à partir de celle-ci.
Dans la figure décrivant les taux d'alarme, l'annotation pour le calcul est légèrement erronée (juste une faute de frappe). 4/17 est 0,235 2 9 et non 0,2359. Suggérez également de mettre quelques mots directement sur l'image pour décrire pleinement vos attentes par rapport à ce que JMP rapporte.Un peu redondant mais utile, je pense, pour les autres qui consultent/interprètent votre demande, en particulier pour les personnes qui ne sont pas aussi familières avec la plate-forme PS ou les graphiques SPC en général.
