貴社の品質管理データテンプレート
貴社の品質管理データテンプレート
- 包括的な分析のために収集を推奨する`属性`
- 追跡すべき主な品質管理活動
- SAP S/4HANA品質管理からのデータ抽出に関するガイダンス
品質管理属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ
ActivityName
|
品質管理プロセス内で発生した特定のビジネスイベントまたはタスクの名称です。 | ||
|
説明
この属性は、品質イベントのライフサイクルにおける単一のステップやマイルストーンを記述します。例えば『通知作成済み』、『原因分析完了』、『使用決定済み』などです。これらの活動は、システムステータスの変更、関連文書の作成、または変更ログに記録された特定のユーザーアクションから派生します。 これらの活動の順序とタイミングを分析することがプロセスマイニングの核心です。これにより、実際のプロセスフローの発見、ステップ間のボトルネックの特定、および標準作業手順への適合性の測定が可能になります。活動の粒度が、プロセス分析の詳細レベルを決定します。
その重要性
この属性はプロセスのステップを定義し、プロセスフローの可視化と分析、逸脱の特定、および活動間のパフォーマンス測定を可能にします。
取得元
JESTおよびJSTOテーブルのステータス変更、またはQMSM(タスク)などのテーブルの活動レコードから導出されます。イベントログは、変更文書テーブルCDHDRおよびCDPOSからも構築できます。
例
品質通知作成済み調査タスク割り当て済み是正処置実施済み通知クローズ済み
|
|||
|
品質イベント
QualityEvent
|
品質通知の一意の識別子であり、品質問題の開始から完了までを追跡するための主要なケースIDとして機能します。 | ||
|
説明
品質イベントは、単一の品質問題に関連するすべての活動、タスク、意思決定を紐づける中心的なケース識別子です。SAPにおいては、これは通常、品質通知番号(QMNUM)に対応します。 プロセスマイニングでは、この識別子でイベントを分析することにより、各品質ケースのエンドツーエンドのプロセスフローを再構築できます。これは、プロセスフローの可視化、ケース全体のサイクルタイム計算、および問題解決プロセスにおける共通経路や逸脱経路の特定に不可欠です。品質管理におけるほぼすべての分析の基盤となります。
その重要性
すべての関連活動を単一のまとまったプロセスインスタンスに連携させ、品質問題がどのように処理されるかについてのエンドツーエンド分析を可能にする、不可欠な要素です。
取得元
これは品質通知番号で、
例
200000018200000019200000020
|
|||
|
開始時刻
EventTimestamp
|
特定のアクティビティまたはイベントが発生した正確な日時。 | ||
|
説明
開始時間、すなわちイベントタイムスタンプは、活動が発生した正確な時刻を記録します。これは、イベントを時系列で整理し、活動間の期間を計算するために極めて重要です。例えば、通知が作成された時刻、タスクが完了した時刻、またはステータスが変更された時刻などを捉えます。 プロセスマイニング分析において、この属性はサイクルタイム、処理時間、待機時間など、時間ベースのあらゆる指標を計算するための基盤となります。ボトルネックの特定、スループットの分析、そして時間ベースのSLAや目標に対するパフォーマンス監視を可能にします。正確なタイムスタンプは、プロセスモデル全体の整合性にとって不可欠です。
その重要性
このタイムスタンプは、イベントの順序付け、サイクルタイムや待機時間などのすべてのパフォーマンス指標の計算、およびプロセスダイナミクスを理解するために不可欠です。
取得元
通常、ステータス変更または文書作成に関連付けられた日付と時刻フィールドから取得されます。例としては、
例
2023-04-15T09:00:12Z2023-04-18T14:35:00Z2023-05-01T11:21:45Z
|
|||
|
プロダクト
MaterialNumber
|
品質イベントの影響を受ける製品または品目の一意の識別子です。 | ||
|
説明
この属性は、品質イベントを特定の製品または品目に関連付けます。この連携は、繰り返し発生する問題や高い欠陥率を持つ製品を特定するのに役立つため、品質保証にとって不可欠です。 プロセスマイニングにおいて、製品別に分析することで、特定の製品が解決に時間がかかるか、または特定の根本原因に関連しているかといったパターンを検出できます。これにより、製品と品質問題を相関させ、『再発問題パターン検出』ダッシュボードをサポートし、ターゲットを絞った品質改善イニシアチブにとって極めて重要となります。
その重要性
品質問題を特定の製品に関連付け、製品ごとの欠陥率、根本原因、解決パターンを分析できます。
取得元
品質通知明細テーブルQMFEのMATNRフィールドにあります。
例
FIN-1001RAW-205ASEMI-303B
|
|||
|
ユーザー
ChangedBy
|
活動を実行した、または最後に変更を行ったユーザーのIDです。 | ||
|
説明
この属性は、特定のプロセスステップの実行を担当するユーザーを特定します。SAPでは、多くの場合、『変更者』(AENAM)や『作成者』(ERNAM)フィールドに対応します。 ユーザー別に分析することで、ワークロードの配分を理解し、トレーニングニーズを特定し、ユーザー固有のプロセス逸脱を特定するのに役立ちます。特定のユーザーの処理時間が長い理由や、標準的ではない経路をたどる傾向がある理由を調査するなど、リソースベースの分析の基盤となります。
その重要性
ユーザーのパフォーマンス、ワークロードの配分、標準手順の遵守状況を分析できるため、リソース最適化に不可欠です。
取得元
QMEL-ERNAM(作成者)などのヘッダーおよび明細テーブル、または変更ログ(CDHDR-USERNAME)から導出されます。
例
SMITHJWILSONAPROCESS_AUTOMATION_BOT
|
|||
|
優先度
NotificationPriority
|
品質通知に割り当てられた優先度レベルであり、その緊急度を示します。 | ||
|
説明
優先度は、品質イベントへの対応の緊急度を定義します。これにより、チームは業務を効率的に組織し、最も重要な問題から優先的に処理できます。SAPでは、目標応答時間に影響を与える可能性のある複数の優先度タイプを設定可能です。 この属性は、優先度の高い項目が優先度の低い項目よりも実際に迅速に処理されているかを分析するために利用されます。高優先度のケースがプロセスで滞るような非効率性を明らかにすることができ、『品質イベントスループット分析』のようなダッシュボードにとって重要な分析軸となります。
その重要性
プロセスのパフォーマンスがビジネスの緊急性と一致しているかを分析するのに役立ち、優先度の高い問題がより迅速に解決されることを確実にします。
取得元
QMELテーブルのQMPRIフィールドにあります。説明はTQ05テーブルにあります。
例
1234
|
|||
|
品質通知タイプ
QualityNotificationType
|
顧客からのクレーム、社内問題、サプライヤー起因の欠陥など、品質通知の分類です。 | ||
|
説明
この属性は、品質イベントの発生元と性質に基づいてイベントを分類します。標準的なSAPの通知タイプには、顧客クレーム、社内問題レポート、サプライヤー関連の欠陥などが含まれ、この分類がその後のプロセスフローや必要な文書を決定します。 通知タイプ別にプロセスを分析することは、異なる種類の問題が異なる方法で処理されているか、あるいは効率性に差があるかを理解するために不可欠です。『品質イベントスループット分析』のようなダッシュボードをサポートし、異なる問題カテゴリにおけるサイクルタイムやプロセス経路のフィルターおよび比較を可能にします。
その重要性
これにより、品質問題の種類ごとにプロセス経路やパフォーマンス特性が異なるかどうかをセグメント化して分析することが可能です。
取得元
QMELテーブルのQMARTフィールドにあります。
例
Q1Q2F2
|
|||
|
担当部署
ResponsibleDepartment
|
特定のタスクの実行や品質イベントの管理を担当する部門、または機能領域を指します。 | ||
|
説明
この属性は、活動または品質イベント全体に割り当てられた組織単位を示します。これは、品質保証チーム、エンジニアリング部門、または生産部門などである可能性があります。 これは部門間の連携や引き継ぎを分析するための重要な分析軸です。責任が部門間で移行する際に発生する遅延を特定するのに役立ち、『部門間引き継ぎ遅延』ダッシュボードのサポートにもなります。また、特定の部門がどのように業務を遂行しているかを理解するために、プロセスビューをフィルタリングすることも可能です。
その重要性
部門間の引き継ぎを分析し、組織的なボトルネックを特定し、異なるチームがプロセスにどのように貢献しているかを理解するために不可欠です。
取得元
通知やタスクに関連するパートナー機能、または人事マスタデータにおけるユーザーの組織上の割り当てから派生することが一般的です。直接的なフィールドではない場合があります。
例
品質保証生産ライン3サプライヤー品質エンジニアリング
|
|||
|
根本原因
RootCauseCode
|
品質問題の特定された根本原因を識別するコードまたはテキストです。 | ||
|
説明
根本原因属性は、品質上の欠陥や不適合の根底にある理由を捉えます。正確な根本原因を特定することは、効果的な是正措置や予防措置を定義する基礎となるため、品質管理プロセスにおける極めて重要なステップです。 この属性は、『根本原因分析サイクルタイム』および『再発問題パターン検出』ダッシュボードに不可欠です。根本原因別に分析することで、システム的な問題の特定に役立ちます。例えば、特定の根本原因でプロセスマップをフィルタリングすることにより、それが独自のプロセス経路につながるのか、あるいは解決時間が長くなるのかを確認することができます。
その重要性
根本原因と製品、部署、プロセス非効率性を関連付けることで、システム的な問題の分析を可能にし、予防処置を導きます。
取得元
通常、
例
OPERATOR_ERRORDEFECTIVE_MATERIALMACHINE_MALFUNCTION
|
|||
|
目標解決日
TargetResolutionDate
|
品質イベントの計画された完了日、または必須完了日です。 | ||
|
説明
この日付は、品質イベントが完全に解決され、完了されると予想される期限を表します。パフォーマンス測定やサービスレベル契約(SLA)の遵守状況を評価するためのベンチマークとして頻繁に用いられます。 この属性は、期限内完了率の計算や期限切れケースの特定にとって不可欠です。『品質イベント期限内完了』ダッシュボードや『品質アクション期限内完了率』KPIは、実際の完了日とこの目標日との比較に直接依存しています。これにより、作業の優先順位付けとリソースの効率的な管理を支援します。
その重要性
期限内パフォーマンスを測定するための基準を提供します。これは、プロセス効率とSLA遵守を評価する上で不可欠なKPIとなります。
取得元
QMEL-QMDAT(必須終了日)またはQMSM-PSTERのタスクレベルで見つけることができます。
例
2023-05-302023-06-152023-07-01
|
|||
|
アクティビティ処理時間
ProcessingTime
|
単一の活動に実際に費やされた時間の期間です。 | ||
|
説明
処理時間(サイクルタイムとも呼ばれます)は、単一の活動の開始から終了までの経過時間を指します。これは、活動と活動の間に費やされる待機時間とは異なります。活動の開始タイムスタンプと終了タイムスタンプの差分として計算されます。 この指標は、どのタスクが最も時間を要しているかを特定する上で極めて重要です。『プロセスボトルネック特定』ダッシュボードでは、特定の活動の処理時間が長い場合、その活動が複雑である、リソースが不足している、または手順が非効率である可能性を示唆します。これにより、プロセス改善の取り組みをどこに集中すべきかを正確に特定するのに役立ちます。
その重要性
付加価値活動に費やされた時間を測定し、プロセス内で最も時間を要するステップを特定することで、最適化の優先候補を明らかにします。
取得元
イベントログ内の各活動の開始および終了タイムスタンプから導出される計算フィールドです。(終了時間 - 開始時間)。
例
2時間15分3日4時間30分
|
|||
|
ソースシステム
SourceSystem
|
データが抽出されたソースシステム(特定のSAP S/4HANAインスタンスなど)を識別します。 | ||
|
説明
この属性は、品質管理データの発生元を指定します。複数のERPや統合システムが存在する環境では、このフィールドはデータソースを区別し、データ整合性を確保するために不可欠です。 分析においては、異なるシステムや組織単位間でプロセスをフィルタリングしたり比較したりすることを可能にします。特定のデータセットでは常に同じ値であることも多いですが、データガバナンスとコンテキストの観点から必須の項目です。
その重要性
データの発生元に関する重要なコンテキストを提供します。これはデータガバナンスにとって、また複数のシステムが連携する環境では不可欠です。
取得元
これは通常、データ抽出プロセス中にSAP S/4HANAクライアントおよびシステムIDを識別するために追加される静的な値です。
例
S4H_PROD_100SAP_QM_EUS4HANA_QAS_200
|
|||
|
最終データ更新
LastDataUpdate
|
このレコードのデータがソースシステムから最後に更新された日時を示すタイムスタンプ。 | ||
|
説明
この属性は、ソースシステムからの最新のデータ抽出または更新のタイムスタンプを提供します。これにより、ユーザーは分析しているデータの鮮度を把握できます。 あらゆる分析ダッシュボードやレポートにおいて、この情報を表示することは、データの鮮度に関するユーザーの期待を管理する上で重要です。最近のプロセス変更と古いデータによる影響とを区別するのに役立ちます。
その重要性
データの鮮度をユーザーに知らせ、プロセスマイニング分析に基づいたタイムリーかつ正確な意思決定を行う上で不可欠です。
取得元
これはデータ更新時にデータ抽出ツールまたはパイプラインによって生成され、入力されるメタデータフィールドです。
例
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
処置の有効性
EffectivenessEvaluation
|
実施された措置が効果的であったかを確認する検証チェックの結果です。 | ||
|
説明
この属性は、品質管理サイクルにおける重要な最終ステップである、有効性チェックの結果を記録します。実施された是正措置や予防措置が根本原因を解決し、再発を防止できたかどうかを確認するものです。 これは、『アクション有効性検証』ダッシュボードおよび『アクション有効性検証率』KPIの主要な属性です。問題解決プロセスそのものの品質に関する直接的なインサイトを提供します。効果の低い措置の割合が高い場合、根本原因分析や措置計画段階の改善が必要であることを示唆します。
その重要性
問題解決プロセスの成功を直接測定し、処置が問題の再発を真に防いでいるかどうかを示します。
取得元
この情報は、多くの場合、品質通知内のフォローアップ処置や特定のタスクステータスに保存されます。カスタムフィールドであるか、特定のステータスコードに基づいている場合があります。
例
有効効果なし監視が必要
|
|||
|
工場
Plant
|
品質イベントが発生した、または管理されている製造プラント、あるいは場所を指します。 | ||
|
説明
プラント属性は、品質イベントに関連する工場や倉庫といった物理的な場所を指定します。これは、品質問題が発生した場所の地理的または組織的なコンテキストを提供します。 この属性は、比較分析において非常に強力な分析軸となります。プラント別にフィルターやグループ化を行うことで、経営層は異なる拠点のパフォーマンスを比較し、サイト固有の問題を特定し、パフォーマンスの高いプラントのベストプラクティスを共有できます。『どのプラントで原因分析のサイクルタイムが最も長いか?』といった問いに答えるのに役立ちます。
その重要性
異なる運用拠点間でのパフォーマンス比較を可能にし、拠点固有の問題やベストプラクティスを特定するのに役立ちます。
取得元
通知ヘッダーに関連付けられたプラントはQMEL-WERKSにあります。特定の品目に関連する場合、明細レベルでも見つけることができます。
例
100017102000
|
|||
|
手戻り
IsRework
|
アクティビティ、またはその一連の流れが手戻り(rework)に該当するかを示すブール型フラグ。 | ||
|
説明
あるケースが特定のステップを繰り返す場合、このフラグは真となり、最初の作業が不十分であったことを示唆します。例えば、『原因分析』活動の後に、同じケースに対して再度『調査タスク割り当て』が続く場合、それは手戻りループを示します。 この属性は、『是正措置手戻り率』KPIを直接サポートします。手戻りの特定と定量化はプロセスマイニングの主要な目標であり、手戻りは無駄な労力とプロセスの非効率性を意味します。プロセスマップで手戻りループを可視化することで、品質と効率性の改善における重要な機会を明らかにできます。
その重要性
ステップが繰り返される箇所を特定することでプロセスの非効率性を定量化し、無駄な作業や初回正解率を向上させる機会を明確にします。
取得元
これは算出される属性です。プロセスマイニング分析中に、単一ケース内で繰り返される活動シーケンスを検出することで導き出されます。
例
truefalse
|
|||
|
期限内完了
IsOnTimeCompletion
|
品質イベントが目標解決日までに完了したかどうかを示すブールフラグです。 | ||
|
説明
この計算フラグは、品質イベントの実際の完了タイムスタンプを『目標解決日』と比較します。目標日またはそれ以前にイベントが完了した場合は真、それ以外の場合は偽となります。 この属性は、パフォーマンス監視のためのシンプルかつ直接的な指標であり、『品質イベント期限内完了』ダッシュボードや『品質アクション期限内完了率』KPIの基礎となります。部門、製品、通知タイプなど、様々な軸で期限内パフォーマンスを容易にフィルター・集計して理解することを可能にします。
その重要性
期限に対するパフォーマンス追跡において明確な二者択一の結果を提供し、SLA遵守状況の測定と報告を容易にします。
取得元
最終的な完了活動のタイムスタンプと「TargetResolutionDate」属性を比較して導出される計算属性です。
例
truefalse
|
|||
|
通知ステータス
SystemStatus
|
『未処理』や『完了済み』など、品質通知の現在の処理ステータスです。 | ||
|
説明
システムステータスは、品質イベントのライフサイクルにおける現在の状態を示します。SAPでは、OSNO(未処理通知)、NOPR(処理中通知)、NOCO(完了通知)などのステータスが進行状況を反映するステータス管理システムを採用しています。 この属性は、イベントログ内の活動を抽出するためによく利用されます。また、未処理または最近完了した品質イベントのみを分析するなど、ケースをフィルタリングするための重要な分析軸でもあります。ステータス遷移を理解することは、正確なプロセスモデルを構築するための鍵となります。
その重要性
ケースの現在の状態を示し、アクティブなケースとクローズされたケースをフィルタリングし、プロセス活動自体を導出するのに役立ちます。
取得元
さまざまなSAPオブジェクトのステータス情報を保存するJESTおよびJSTOテーブルから導出されます。リンクはQMEL-OBJNRからです。
例
OSNO NOPRNOCOTSCO
|
|||
|
顧客
CustomerNumber
|
該当する場合、品質イベントに関連付けられた顧客の識別子です。 | ||
|
説明
この属性は、品質イベントを特定の顧客に関連付けます。これは『顧客クレーム』のような通知タイプに最も関連性が高い情報です。この情報を追跡することは、顧客関係管理において、また品質問題が顧客に与える影響を理解するために不可欠です。 顧客別に分析することで、特定の顧客が他の顧客よりも多くの品質問題を経験しているか、あるいは解決時間が顧客によって異なるかを企業が特定できます。これにより、影響分析に顧客という側面を追加し、『重大度と影響別の品質イベント』ダッシュボードをサポートします。
その重要性
品質イベントを顧客に結び付け、顧客固有の問題を分析し、高価値顧客が優先的なサポートを受けられるようにします。
取得元
通常、通知のパートナ機能にあります。販売オーダーからのクレームである場合は、
例
CUST-10045CUST-20399CUST-80110
|
|||
品質管理活動
| アクティビティ | 説明 | ||
|---|---|---|---|
|
使用決定済み
|
検査ロットからの製品品質に関する正式な決定(例えば、合格または不合格)を指します。これは検査に起因する品質問題における明確なイベントであり、使用決定が保存された時点で記録されます。 | ||
|
その重要性
検査駆動型プロセスにとって、これは資材のブロックやリリースなどのその後の処置を決定する重要なマイルストーンです。そのタイミングと結果を分析することは、製品品質管理の効率を理解するための鍵となります。
取得元
これは使用決定テーブル
取得
イベントタイプ
explicit
|
|||
|
処置の有効性が検証済み
|
実施された是正処置または予防処置が成功し、品質問題が再発することなく解決されたことを確認します。これは、有効性チェックタスクの完了または最終的な品質レビュー時に取得されます。 | ||
|
その重要性
これは解決プロセス全体を検証するための重要なマイルストーンです。高い検証成功率は、効果的な品質管理システムを示し、再発問題の削減をサポートします。
取得元
通常、
取得
QMSMにおける有効性検証タスクの完了タイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
品質通知作成済み
|
この活動は、品質関連の問題、欠陥、またはクレームが正式に記録される、品質管理プロセスの公式な開始を意味します。SAP S/4HANAで品質通知が作成されることで、初期の詳細が捕捉され、一意の識別子が割り当てられ、ケースが開始されます。 | ||
|
その重要性
主要な開始イベントとして、この活動は品質解決プロセスのエンドツーエンドのサイクルタイムを測定するために不可欠です。品質イベントへの対処と完了にかかる時間を追跡するためのベースラインを提供します。
取得元
これは品質通知ヘッダテーブル
取得
指定された通知について、
イベントタイプ
explicit
|
|||
|
是正処置実施済み
|
是正措置計画で定義された作業の完了を示します。これは通常、品質通知内で割り当てられた是正措置タスクが完了とマークされた際に記録されます。 | ||
|
その重要性
これは品質問題の解決に向けた措置が取られたことを示す重要なマイルストーンです。処置の期限内完了率と解決フェーズ全体の効率を測定するために不可欠です。
取得元
QMSMテーブルでの是正処置タスクの完了から推測されます。完了日はERLDTフィールドまたはJEST/JCDSテーブルでの「完了」ステータス変更を介して記録されます。
取得
QMSMテーブル内の是正処置タスクの完了タイムスタンプ(ERLDT)を特定します。
イベントタイプ
inferred
|
|||
|
根本原因分析完了
|
品質問題の根本原因が特定された調査フェーズの完了を示します。これは一般的に、通知内の特定の『原因分析』タスクが完了したことから推測されます。 | ||
|
その重要性
これは調査プロセスの期間と効率を測定するための重要なマイルストーンです。このステップより前に遅延を特定することで、問題分析と意思決定におけるボトルネックを明確にできます。
取得元
QMSMテーブルでの調査またはRCA固有のタスクの完了から推測されます。完了は、ステータス変更またはタスク完了日フィールド(ERLDT)の入力によって識別されます。
取得
QMSMテーブル内の関連する根本原因分析タスクの完了タイムスタンプ(ERLDT)を特定します。
イベントタイプ
inferred
|
|||
|
通知完了済み
|
品質通知の業務完了を示し、必要なすべての処置が取られ、運用上の観点から問題が解決されたことを意味します。これはシステム内の正式なステータス変更です。 | ||
|
その重要性
この活動は、ビジネス上の解決時間を測定するための主要な終点となります。プロセスオーナーの視点から見て、技術的なクローズが保留中であっても、ケースが完了していることを確認するものです。
取得元
品質通知オブジェクトのステータス変更から推測されます。これは、JCDSテーブルで「NOCO」(通知完了)のようなステータスが設定されたときのタイムスタンプを特定することで取得されます。
取得
JCDSテーブルで「通知完了」ステータスが設定されたときのタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
予防措置実施済み
|
計画された予防措置が正常に実行されたことを示します。これは、システム内で対応する予防措置タスクが完了したことを記録することで取得されます。 | ||
|
その重要性
予防措置の完了は、成熟した品質プロセスにおいて極めて重要なステップです。この活動を追跡することで、将来の問題を未然に防ぎ、再発を減少させるというコミットメントの度合いを測ることができます。
取得元
QMSMテーブルでの予防処置タスクの完了から推測され、ERLDTフィールドまたは「完了」ステータス変更によって示されます。
取得
QMSMテーブル内の予防処置タスクの完了タイムスタンプ(ERLDT)を特定します。
イベントタイプ
inferred
|
|||
|
予防措置提案済み
|
この活動は、品質問題の再発防止計画が作成された際に発生します。是正措置と同様に、多くの場合、『予防措置』タスクの作成によって記録されます。 | ||
|
その重要性
このイベントは、組織が対症療法的な修正だけでなく、プロアクティブな品質改善にどれだけ注力しているかを評価する上で重要です。長期的な問題解決への取り組みの開始を意味します。
取得元
このイベントは、特定の品質通知に対するQMSMテーブルに『予防措置』コードを持つタスクが作成された際に記録されます。
取得
予防処置タイプのタスクについて、
イベントタイプ
explicit
|
|||
|
処置計画承認済み
|
提案された是正措置または予防措置計画がレビューされ、実施へと進むことが承認されたことを示します。このステップは明確なイベントとして記録されることは少なく、処理のためのタスクがリリースされたことから推測される場合があります。 | ||
|
その重要性
この承認段階で長期的な遅延が発生すると、解決プロセス全体が大幅に滞る可能性があります。この期間を分析することで、管理上のボトルネックを特定し、ガバナンスを効率化する機会を見つけることができます。
取得元
これは通常、テーブル
取得
是正処置または予防処置タスクに「リリース済み」ステータスが設定されたときのタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
是正処置を提案
|
この活動は、特定された問題を是正するための計画が正式に文書化される時点を指します。SAPでは、多くの場合、品質通知内で『是正措置』タスクが作成されることで記録されます。 | ||
|
その重要性
このイベントは、プロセスの解決フェーズを開始します。原因分析からこのステップまでの時間を測定することで、措置計画における遅延が明らかになる可能性があります。
取得元
このイベントは、関連する品質通知に対するQMSMテーブルに『是正措置』コードを持つタスクが作成された際に記録されます。
取得
是正処置タイプのタスクについて、
イベントタイプ
explicit
|
|||
|
有効性チェック要
|
実施された処置が問題を正常に解決したことを確認するために、フォローアップ検証が必要であることを示します。これは、多くの場合、通知の特定のステータスまたは専用の検証タスクの作成によって表されます。 | ||
|
その重要性
この活動は、品質管理プロセスにおいて重要な検証ループを確保します。それは、措置の実施と、その成功の確認を分けて行います。
取得元
品質通知のステータス変更(JEST/JCDS経由)またはQMSMテーブルでの特定の「有効性チェック」タスクの作成から推測できます。
取得
QMSMにおけるステータス変更または検証タスク作成のタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
調査タスク割り当て済み
|
このイベントは、根本原因の調査といった特定のタスクが正式に作成され、担当者または部門に割り当てられた際に発生します。品質通知内にタスクレコードが作成された時点で記録されます。 | ||
|
その重要性
タスク割り当ての追跡は、ワークロード配分を理解し、リソース配分におけるボトルネックを特定するために不可欠です。これは調査フェーズの開始を示し、根本原因分析のサイクルタイムを測定するための重要なインプットとなります。
取得元
品質通知にリンクされたタスク管理テーブルQMSMから取得されます。調査など、関連するコードを持つタスクの作成日(ERDAT)がこのイベントを示します。
取得
調査に関連するタスクについて、
イベントタイプ
explicit
|
|||
|
通知クローズ済み
|
システムにおける品質通知の最終的な技術的なクローズを表します。この時点以降、通知に対してそれ以上の変更は不可能となり、レコードのライフサイクルの完全な終了を意味します。 | ||
|
その重要性
この活動は、プロセスにおける最終的な終了イベントとなります。『通知完了』と『通知クローズ』の間の時間を分析することで、管理上のクローズ手順における遅延が明らかになる可能性があります。
取得元
品質通知のステータス変更、特にアーカイブまたは最終完了ステータスが設定されたときに推測されます。この変更は、JCDSテーブルにタイムスタンプとともに記録されます。
取得
JCDSテーブルで通知の最終的な「完了」ステータスが設定されたときのタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
通知処理開始
|
新しく作成された通知が、品質チームによって処理のために実際に取り上げられる瞬間を表します。これは通常、作業が開始されたことを示すシステムステータスの変更から推測されるイベントです。 | ||
|
その重要性
この活動は、問題の単なる記録と実際の作業開始を区別するのに役立ちます。作成からこのステップまでの時間差を分析することで、問題の認識やリソース割り当てにおける潜在的な遅延が明らかになります。
取得元
品質通知オブジェクトのステータス変更から推測されます。これは、JESTおよびJCDSテーブルのステータス変更ログを分析して、「NOPO」(処理中の通知)のようなステータスを追跡することで可能です。
取得
JCDSテーブルで通知の「処理中」ステータスが設定されたときのタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
関係者への通知
|
顧客や社内部門などの関係者へ、解決策を伝達するフェーズを指します。これはシステムによる自動イベントであることは稀で、多くは手動で行われるステップです。 | ||
|
その重要性
タイムリーな関係者とのコミュニケーションは、顧客満足度と透明性にとって極めて重要です。完了から通知までの遅延を測定することで、コミュニケーションプロセスのギャップを浮き彫りにできます。
取得元
この活動はSAPから直接捕捉することは困難です。『関係者への通知』とラベル付けされたQMSM内の手動タスクの完了から推測されるか、あるいはメールログのような外部システムの分析が必要となる場合があります。
取得
手動のコミュニケーションタスクが使用されている場合、その完了を特定します。そうでない場合、これは通常利用できません。
イベントタイプ
inferred
|
|||