Qu'est-ce qui a inspiré cette demande de liste de souhaits ?
Les groupes de contrôle de processus de mes entreprises utilisent de plus en plus la plate-forme de filtrage de processus et le taux d'alarme devient une mesure clé pour nous. De plus, nous utilisons de plus en plus le graphique à trois voies et il est tout aussi important sur les graphiques à trois voies de suivre et de comprendre le taux d'alarme sur les graphiques internes que sur les graphiques moyens.En essayant de comparer les résultats entre les plates-formes ainsi que les résultats attendus, nous avons trouvé des écarts.
j'ai travaillé avec @PatrickGiuliano au service client de JMP pour déterminer comment la plate-forme a été conçue pour fonctionner par rapport aux objectifs de cette demande.
Quelle est l'amélioration que vous aimeriez voir?
La section de taux d'alarme de la plate-forme Process Screener (PS) est un excellent moyen de déterminer quel processus attaquer en premier et 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, calculés à partir des limites de contrôle supérieure et inférieure.Actuellement, ils ne calculent que les deux limites de contrôle pour le graphique moyen (ainsi que tous les autres tests), 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 l'affichage d'un processus dans PS vs Control Chart builder.Cela crée également des cartes de contrôle qui sont différentes de celles du générateur de carte de contrôle lors de l'utilisation de "afficher la carte comme sélectionnée" dans le PS et de l'ajout dans la carte de dispersion car seule l'UCL est affichée.
- Les noms des diagrammes de dispersion devraient être modifiés pour être plus clairs.« Limite de plage dépassée » doit passer à « Limite d'affichage dépassée » et être utilisé avec les cartes MR/-R/-S/S/R à trois voies et « Limite MR 3 W dépassée » doit être utilisé 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 "Limite de plage dépassée" à trois voies.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 la voie 3 dans les UCL du diagramme de dispersion, et est le seul sous-groupe à échouer, le « taux d'alarme » doit être de 10 % et la « toute alarme » doit être de 1. Actuellement cela montrerait 20% et 2, ce qui est un regard trompeur sur le processus
- Étant donné que l'objectif du filtre de processus est d'être une sorte de guichet unique pour un aperçu de tous vos processus, il serait utile pour les utilisateurs que la plate-forme 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 moyen, un taux d'alarme MR, un taux d'alarme dans la plage 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-MR char peut être exclu ici car il couvre "deux sous-groupes"}).
À quoi cela pourrait ressembler :
Pris rester cohérent avec Control Chart Builder en utilisant "Test All Beyond Limits - All" vs "Enable all tests" pourrait mieux fonctionner.Je l'ai remarqué après avoir fait cette photo.
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 l'un ou l'autre des diagrammes de dispersion et la plate-forme ne respecte aucune violation de la LCL (ce qui est un problème pour -R ou -S ou les diagrammes à l'intérieur des diagrammes à trois voies) et conduit donc à une alarme incorrecte fréquence.
- Pour le sous-groupe d'é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 (car 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 mis en œuvre au moment même du bail, les noms doivent être soit changés en " Supérieur limite de plage mobile 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 Screener, d'autant plus que Process Screener vous enverra au générateur de cartes de contrôle.
- Le suivi et la compréhension au sein de la variation du processus sont tout aussi importants que la variation entre les moyennes, et sont particulièrement critiques lors de l'utilisation de graphiques à trois voies.
- Différentes entreprises auront des priorités différentes sur les taux d'alarme importants et, par conséquent, le groupe d'utilisateurs devrait être en mesure de contrôler ce qu'il faut afficher dans la plate-forme Process Screener.
Ouf, j'espère que c'est ressorti clair.S'il vous plaît laissez-moi savoir si j'ai besoin d'éclaircir quelque chose!
Steve
