このウィッシュ リスト リクエストのきっかけは何ですか?
私の会社のプロセス管理グループは、ますますプロセス スクリーナー プラットフォームを使用しており、アラーム レートは私たちにとって重要な指標になりつつあります。また、スリーウェイ チャートをますます使用しており、スリーウェイ チャートでは、平均チャートと同様に、チャート内のアラーム レートを追跡して理解することが重要です。プラットフォーム間での結果と予想される結果を比較しようとすると、不一致が見つかりました。
私は一緒に働いてきました@パトリックジュリアーノJMPカスタマーサービスで、プラットフォームがどのように機能するように設計されているか、このリクエストの目標と比較して作業します。
あなたが見たいと思う改善は何ですか?
Process Screener (PS) プラットフォームのアラーム レート セクションは、どのプロセスを最初に攻撃するかを特定し、時間の経過に伴うパフォーマンスの変化を追跡しながら、傾向をすばやく視覚化できる優れた方法です。以下をご覧ください。
- 「警報率列」および「任意の警報」列は、選択されたすべての警報率を、管理限界の上限と下限の両方から計算されたものとして尊重する必要があります。現在、平均管理図 (およびその他の検定) の両方の管理限界のみを計算しますが、三元管理図が選択されている場合は、「範囲限界超過」の上限管理限界のみを計算します。
- LCL を尊重しないと、PS ビルダーと管理図ビルダーでプロセスを表示するときに異なるアラーム レートが発生します。これにより、PS で [選択したチャートを表示] を使用し、UCL のみが表示されるように分散チャートを追加すると、管理図ビルダーとは異なる外観の管理図も作成されます。
- 分散チャートの名前は、より明確にするために変更する必要があります。"Range Limit Exceeded" は "Disp Limit Exceeded" に移動し、MR/-R/-S/three way S/R 管理図で使用し、"3W MR Limit exceeded" は三元管理図の MR 管理図で使用する必要があります。
- アラーム レートとアラーム カウントは、各「テスト」列と 3 つの「範囲制限超過」のアラーム レートの合計であってはなりません。それらはサブグループ全体でのみ合計する必要があります(したがって、サブグループが平均チャートの「テスト」に失敗した場合、またはサブグループ分散チャートが管理限界を超えた場合は、「すべてのアラーム」列の値を+1し、+を追加するだけです「アラームレート」列の分子に1。たとえば、サブグループ 2 (10 個中) が分散チャート UCL 内の平均および 3 方向で失敗し、失敗する唯一のサブグループである場合、「アラーム率」は 10% で、「任意のアラーム」は 1 である必要があります。現在これは 20% と 2 として表示され、プロセスの誤解を招きます。
- プロセス スクリーナーの目標は、すべてのプロセスの概要をワンストップ ショッピングすることであるため、ユーザーが選択したすべてのアラーム タイプをプラットフォーム全体のアラーム レートに反映させることは、ユーザーにとって付加価値となります。 .(したがって、平均アラーム率、MR アラーム率、範囲内アラーム率、およびサブグループに欠陥があるとフラグを付けるためにユーザーによって選択されたすべてのテストにフラグを付ける全体的なアラーム率を確認したいと思います {I-MR の MR char は「2 つのサブグループ」にまたがるため、ここでは除外できます})。
これがどのように見えるか:


「限界を超えたすべてのテスト - すべて」と「すべてのテストを有効にする」を使用して、管理図ビルダーとの一貫性を保つ方がうまくいく可能性があります。この絵を描いてから気がつきました。
以下の図では、アイテム 1 と 3 の両方の問題を確認できます。
- どちらの分散管理図にも下側管理限界はなく、プラットフォームは LCL の違反 (-R または -S、または三元管理図の管理図内の問題) を考慮しないため、誤ったアラームが発生します。割合。
- 電力サブグループの場合、チャート内の X バーと範囲の両方で管理外であるため、1 つだけとしてカウントされるべきところを 2 つのアラームとしてカウントされます (分母はサブグループの数であるため)。したがって、ラーム率は 4/17 ではなく 3/17 である必要があります。

何らかの理由で上記の項目 1 がリース時に実行できない場合は、名前を次のように変更する必要があります。アッパー移動範囲の制限を超えました」と「アッパー現在の命名規則により、ユーザーが両方を含むと想定しないようにします。
なぜこの考え方が重要なのですか?これは、次の理由から重要です。
- 管理図ビルダーとプロセス スクリーナーの両方から同じ結果が得られるはずです。特に、プロセス スクリーナーは管理図ビルダーに移動するためです。
- プロセス変動内の追跡と理解は、平均間の変動と同じくらい重要であり、三元チャートを使用する場合は特に重要です。
- 異なる企業は、どのアラーム レートが重要かについて異なる優先順位を持っているため、ユーザー グループはプロセス スクリーナー プラットフォームに何を表示するかを制御できる必要があります。
ふう、うまくいけば、それは明らかになりました。何かをクリアする必要がある場合はお知らせください。
スティーブ