このウィッシュリストリクエストのきっかけは何ですか?
私の会社のプロセス管理グループでは、プロセス スクリーニング プラットフォームの使用が増えており、アラーム率が当社にとって重要な指標になりつつあります。また、私たちはスリーウェイ チャートをますます使用していますが、スリーウェイ チャートでは、平均チャートと同様に内部チャートのアラーム レートを追跡して理解することが重要です。プラットフォーム間の結果と期待される結果を比較しようとしたところ、矛盾が見つかりました。
私は一緒に働いてきました@パトリックジュリアーノJMP テクニカル サポートでは、この要求の目標に対してプラットフォームがどのように機能するように設計されているかを確認します。
改善してほしいことは何ですか?
プロセス スクリーニング (PS) プラットフォームのアラーム レート セクションは、最初に攻撃するプロセスをパレート表示したり、時間の経過に伴うパフォーマンスの変化を追跡したり、傾向をすばやく視覚化したりできる優れた方法です。以下をご覧いただきたいと思います。
- 「アラーム レート列」および「任意のアラーム」列は、管理限界の上限と下限の両方から計算された、選択されたすべてのアラーム レートを尊重する必要があります。現在、平均グラフ (およびその他のテスト) の両方の管理限界のみが計算されますが、三元グラフが選択されている場合は「範囲制限超過」の上部管理限界のみが計算されます。
- LCL を尊重しないと、PS vs 管理図ビルダーでプロセスを表示するときに異なるアラーム レートが発生します。これにより、PS で「チャートを選択した状態で表示」を使用し、UCL のみが表示されるように分散チャートを追加した場合に、管理図ビルダーとは異なる外観の管理図も作成されます。
- 分散チャートの名前は、より明確になるように変更する必要があります。「範囲制限を超えました」は「表示制限を超えました」に移動し、MR/-R/-S/3 方向 S/R チャートで使用する必要があり、「3W MR 制限を超えました」は 3 方向チャートの MR チャートに使用する必要があります。
- アラーム レートとアラーム数は、各「テスト」列と 3 つの「範囲制限超過」のアラーム レートの合計であってはなりません。これらはサブグループ全体でのみ合計する必要があります (したがって、サブグループが平均値グラフの「テスト」に失敗した場合、またはサブグループ分散グラフが管理限界を超えた場合は、「任意のアラーム」列の値に +1 のみを加え、+ を追加するだけです。 「アラーム率」列の分子に 1 を加えます。たとえば、サブグループ 2 (10 個中) が分散チャート UCL 内の平均および 3 方向で不合格で、不合格となった唯一のサブグループである場合、「アラーム率」は 10%、「任意のアラーム」は 1 になるはずです。これは 20% と 2 として表示されますが、これはプロセスの誤解を招く見方です。
- プロセス スクリーニングの目標は、すべてのプロセスの概要をワンストップ ショップで提供することであるため、プラットフォームで選択されているすべてのアラーム タイプを全体のアラーム レートに反映させることは、ユーザーにとって付加価値となります。ユーザー。(つまり、平均アラーム レート、MR アラーム レート、範囲内アラーム レート、およびサブグループに欠陥があるとしてフラグを立てるためにユーザーが選択したテストにフラグを立てる全体アラーム レートを確認したいと思います。{MR for an I- MR 図は「2 つのサブグループにまたがる」ため、ここでは除外できます})。
これはどのように見えるか:
注: 「すべてのテストを有効にする」ではなく「限界を超えてすべてテスト - すべて」を使用して、管理図ビルダーとの一貫性を保つ方がうまく機能する可能性があります。上の写真を作った後で気づきました。
下の図では、項目 1 と 3 の両方の問題がわかります。
- どちらの分散チャートにも下限管理限界はなく、プラットフォームは LCL の違反を尊重しません (これは、-R または -S、または三元チャートの範囲内チャートの問題です)。アラームレートが正しくありません。
- 電気サブグループの場合、チャート内の X-Bar と Range の両方が制御不能であるため、1 つとしてのみカウントされるべきアラームが 2 つとしてカウントされます (分母はサブグループの数であるため)。したがって、アラームレートは 4/17 ではなく 3/17 である必要があります。
何らかの理由で上記の項目 1 を追加できない場合は、少なくとも名前を「」に変更する必要があります。アッパー移動範囲制限を超えました」および「アッパー範囲制限を超えています」というメッセージが表示されるため、現在の命名規則により、ユーザーは両方が含まれると想定しなくなります。
この考え方がなぜ重要なのでしょうか?これは次の理由から重要です。
- 特にプロセス スクリーニングでは、プラットフォームで利用可能な機能として管理図ビルダーが表示されるため、管理図ビルダーとプロセス スクリーニングの両方から同じ結果が得られるはずです。
- プロセス変動内での追跡と理解は、平均間の変動と同じくらい重要であり、三元グラフを使用する場合は特に重要です。
- どのアラーム率が重要かについては企業によって優先順位が異なるため、ユーザー グループはプロセス スクリーニング プラットフォームに何を表示するかを制御できる必要があります (たとえば、MR チャートおよび R チャートで LCL をオンまたはオフにするかなど)。
うーん、それがはっきり出ればいいのですが。何かクリアする必要がある場合はお知らせください。
スティーブ
ご契約いただきありがとうございます@sampton82 ！
些細なコメントがいくつかあります。
警報率の計算に関するご議論について。 ツールチップや開示ボタンなどとして、プラットフォーム内のユーザーに対して直接明確にする必要があると思います。どのように計算されているのか。私も計算に関するあなたの考えに同意しません。そして、特にプラットフォームが管理図ビルダーから管理図ビルダーを制御できるように設計されている場合には、管理図ビルダーと一致するべきであることに同意します。
アラーム レートを説明する図では、計算の注釈がわずかにずれています (単なるタイプミス)。 4/17 は 0.235 2 0.2359ではなく9です。また、あなたの期待と JMP の報告内容を完全に説明するために、画像に直接いくつかの言葉を入れることをお勧めします。冗長ではありますが、あなたのリクエストを閲覧/解釈する他の人、特に PS プラットフォームや SPC チャート全般にあまり詳しくない人にとっては役立つと思います。
