Étant donné un tableau de contrôle qui montre la moyenne et les limites de contrôle supérieures / inférieures, comment puis-je savoir si la cause des points hors contrôle est attribuable ou non?


8

Examen de pratique IEEE CSDA - Statistiques d'ingénierie - Carte de contrôle

On me donne 15 points. Les limites de contrôle sont à +/- 3 . Les points 1, 4, 5, 6, 7, 8, 9, 10, 11, 13 et 15 se situent dans les limites de contrôle. Les points 2, 3, 12 et 14 sont en dehors des limites de contrôle, 2 étant en dessous de la limite de contrôle inférieure et 3, 12 et 14 au-dessus de la limite de contrôle supérieure.σ

Comment savoir si les points 2, 3, 12 et 14 sont hors de contrôle causés par des causes fortuites ou par des causes attribuables?


1
Si quelqu'un veut que je le fasse, je peux produire un graphique similaire à celui qui m'a été donné et le lier ici. Cette question est venue d'un examen d'associé de développement logiciel certifié IEEE - la bonne réponse est apparemment "hors de contrôle causée par des causes attribuables". Malheureusement, je ne sais pas pourquoi c'est la réponse - j'ai dit "hors de contrôle causé par des causes fortuites" car il n'y a pas une série de points hors de contrôle.
Thomas Owens

Oui, le graphique serait utile. Comme indiqué dans ma réponse, l'aspect du graphique est également important, non seulement les points qui sont en dehors des limites de contrôle.
Carlos Accioly

Je viens d'ajouter une image de la question, graphique inclus. J'ai également marqué la bonne réponse.
Thomas Owens

Réponses:


6

Oui, vous devez trouver et attribuer une cause pour chaque point hors des limites. Mais les choses sont un peu plus compliquées.

Vous devez d'abord déterminer si le processus est sous contrôle, puisqu'un tableau de contrôle n'a pas de sens lorsque le processus est hors de contrôle. Près d'un quart de vos observations dépassant les limites est un signe fort que le processus peut être hors de contrôle. Il serait utile de consulter le graphique pour déterminer si le processus est maîtrisé ou non.

Outre le fait de tomber en dehors des limites de contrôle, il existe d'autres raisons potentielles de devoir rechercher des causes attribuables à certaines observations. Par exemple, si vous avez plusieurs observations consécutives tombant du même côté de la moyenne - en particulier si elles sont proches de la limite de contrôle - elles peuvent avoir besoin d'attribuer une cause spéciale.

Je pourrais peut-être être plus précis si vous publiez le graphique lui-même.

Si vous souhaitez en savoir plus sur les cartes de contrôle, SPC Press dispose d'un certain nombre de ressources gratuites utiles. Vous pouvez également consulter ce livre : il est court, concis et très instructif.

(Éditer:)

J'ai supposé que nous parlions de données réelles, pas d'une question d'examen. Dans ce cas, la bonne réponse est vraiment la première: les points en dehors des limites de contrôle sont (probablement) causés par des causes attribuables.

L'examen est un peu bâclé dans sa terminologie, cependant: vous ne pouvez pas réellement dire avec 100% de certitude que les points en dehors des limites de contrôle ne sont pas causés par hasard. Vous pouvez seulement dire qu'il y a une probabilité de 99,7% qu'un point particulier en dehors des limites ne soit pas causé par hasard.


J'ai ajouté une photo qui comprend la question et le graphique d'origine.
Thomas Owens

5

Ma compréhension des cartes de contrôle est un peu différente ... Après le premier signal à l'observation 2, le processus ne serait-il pas arrêté et vérifié pour des problèmes, puis redémarré?

Dans tous les cas, vous pouvez utiliser un argument de valeur p. La probabilité d'observer 4 observations ou plus (sur 15) au-delà de leurs limites de contrôle est TRÈS faible si le processus est réellement sous contrôle. Disons que la probabilité qu'une observation sorte des limites de contrôle alors que le processus est réellement sous contrôle est d'environ 0,01 (cette probabilité exacte dépend de la distribution sous contrôle des données), donc si le processus est sous contrôle, nous nous attendons à une fausse alarme (c.-à-d. un signal hors de contrôle causé par un hasard) toutes les 100 observations environ. La probabilité d'observer au moins 4 signaux hors de contrôle (sur 15) pendant que le processus est sous contrôle est d'environ 0,000012, il est donc très peu probable que les signaux soient dus à un hasard.

Alors qu'un diagnostic réel vous obligerait à consulter le tableau et éventuellement à enquêter sur le processus physique, car les points hors contrôle sont à la fois inférieurs et supérieurs aux limites de contrôle, je parie qu'il y a eu un changement d'échelle (c'est-à-dire une augmentation de la variance). )


Je n'ai suivi qu'un seul cours en statistiques d'ingénierie, mais je semble me souvenir que vous n'arrêtez pas le processus tant que vous n'avez pas 3 (peut-être 2) points qui sont hors de contrôle. Cependant, votre deuxième argument a du sens, où un processus vraiment sous contrôle n'aurait pas 4/15 observations en dehors de +/- 3 std dev. Malheureusement, je n'ai pas mon livre EngStats à la maison pour le vérifier. Au moins, c'est plausible. +1 pour l'instant, jusqu'à ce que je puisse en savoir plus. Mais au moins, c'est un point de départ.
Thomas Owens

(+1) Bonne réponse. Alternativement, en supposant que l'écart-type a été précédemment estimé à partir d'une très longue série de données, on pourrait s'interroger sur la normalité de la distribution. De plus, ces 15 points n'étaient probablement pas une sélection aléatoire: ils doivent avoir été choisis comme une courte séquence dans laquelle un nombre inhabituel de mesures OOC est apparu. Le premier suggère que le risque d'un seul OOC peut être un peu plus grand que 0,01 tandis que le second indique que le calcul binomial est trompeur. Après tout, il est pratiquement certain qu'une telle séquence finira par se produire par hasard!
whuber

J'ai ajouté une photo qui comprend la question et le graphique d'origine.
Thomas Owens

3
@Thomas Cela me semble toujours être une mauvaise question. Il tente de mesurer deux concepts (comment lire une carte de contrôle et la distinction entre les causes "attribuables" et "aléatoires"), ce qui est une erreur, et il punit le candidat réfléchi qui sait que beaucoup plus d'informations sont nécessaires pour interpréter les points OOC qui sont donnés ici, ce qui est l'erreur la plus flagrante.
whuber

4

(Désolé d'avoir posté une nouvelle réponse, je ne peux pas encore répondre directement aux commentaires)

Je ne suis pas vraiment d'accord avec la déclaration:

"Apparemment, si vous traversez l'UCL ou LCL, il doit y avoir une cause attribuable"

Pour simplifier les choses, si votre distribution sous contrôle est N (0,1), vous obtiendrez toujours de fausses alarmes une fois toutes les 370 observations, en moyenne, en utilisant un UCL de 3 et un LCL de -3. Lorsque le graphique signale, le processus doit être étudié. Ce n'est qu'alors qu'une raison pour le signal peut être attribuée (c.-à-d. Changement de processus ou erreur aléatoire.) Le réglage de l'UCL et du LCL nécessite que l'utilisateur équilibre le taux de fausse alarme / détection manquée souhaité (analogue au compromis d'erreur de type I / type II dans tests d'hypothèses.)

Vous pouvez également attendre jusqu'à ce que quelques signaux s'arrêtent réellement et enquêter sur le processus, mais dans ce cas, vous pouvez détecter le décalage trop tard s'il s'est réellement produit au premier signal. Encore une fois, vous ne pouvez pas avoir quelque chose pour rien et l'utilisateur doit utiliser son jugement pour décider comment configurer la carte de contrôle et surveiller le processus.


2

J'ai trouvé quelque chose d'intéressant caché dans un document d'étude de l'IEEE orienté vers cet examen:

  • Les points de données compris dans la plage UCL et LCL sont considérés comme étant contrôlés et causés par des causes fortuites.
  • Les valeurs aberrantes tombant au-dessus de l'UCL ou en dessous de la LCL sont considérées comme hors de contrôle et causées par des causes attribuables.
  • Si un certain nombre de points tombent systématiquement au-dessus ou au-dessous de la moyenne (mais sont dans l'UCL et LCL), cela peut indiquer un état hors contrôle non aléatoire.
  • Le but d'une carte de contrôle est de détecter rapidement les états hors de contrôle.
  • Le graphique, à lui seul, n'indiquera pas les causes profondes de l'événement, mais il fournira des pistes d'enquête.

Apparemment, si vous traversez l'UCL ou le LCL, il doit y avoir une cause attribuable.

Cela a du sens, étant donné la définition de Wikipédia des caractéristiques de la cause (spéciale) attribuable :

  • Phénomènes nouveaux, imprévus, émergents ou précédemment négligés dans le système;
  • Variation intrinsèquement imprévisible, même probabiliste;
  • Variation en dehors de la base d'expérience historique; et
  • Preuve d'un changement inhérent au système ou de notre connaissance de celui-ci.

OK, merci pour la clarification: cela résout votre question d'origine. «Assignable» semble signifier «non attribuable au hasard», ce qui est conforme à la dichotomie de la question. Ce avec quoi je me bats, c'est l'hypothèse que les événements OOC ne peuvent pas être dus au hasard. C'est clairement une erreur, comme l'a noté @HairyBeast. Un autre aspect frappant du document d'étude est à quel point il semble informel, non quantitatif et ad hoc , comme dans "un certain nombre de points" (combien?) Et "systématiquement" (ce qui signifie quoi?). Il semble se référer à CUSUM ou exécuter des graphiques sans fournir de directives appropriées pour leur utilisation.
whuber

2
@whuber, je suis entièrement d'accord. Étant donné que cela est publié et maintenu par l'IEEE, je m'attendais à beaucoup mieux. Je me demande simplement s'ils font un tas de trucs parce que c'est une certification en génie logiciel, et ils ne veulent pas approfondir d'autres choses. Mais ce n'est pas une excuse pour une partie de cette confusion.
Thomas Owens du
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.