品質管理データテンプレート
品質管理データテンプレート
- 詳細な分析に向けて収集する推奨属性
- 追跡すべき品質管理の主要アクティビティ
- SAP S/4HANA品質管理からデータを抽出する方法
品質管理の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ
ActivityName
|
品質管理プロセス内で発生した特定の業務イベントまたはタスクの名称です。 | ||
|
説明
品質イベントのライフサイクルにおける1つのステップまたはマイルストーンを示す属性です。「Notification Created」「Root Cause Analysis Completed」「Usage Decision Made」などが該当します。システムステータスの変更、関連文書の作成、変更ログに記録された特定のユーザー操作から導出します。 これらのアクティビティの順序とタイミングを分析することが、プロセスマイニングの中心です。実際のプロセスフローの発見、ステップ間のボトルネックの特定、標準業務手順への適合度の測定が可能になります。アクティビティの粒度によって、プロセス分析で把握できる詳細度が決まります。
重要な理由
この属性によってプロセスのステップを定義できるため、プロセスフローの可視化と分析、逸脱の特定、アクティビティ間のパフォーマンス測定が可能になります。
入手先
JESTおよびJSTOテーブルのステータス変更、またはQMSM(Tasks)などのテーブルに記録されたアクティビティから導出します。CDHDRおよびCDPOSの変更文書テーブルからイベントログを構成することもできます。
例
品質通知の作成調査タスクの割り当て是正措置の実施通知のクローズ
|
|||
|
品質イベント
QualityEvent
|
品質通知を一意に識別する識別子です。品質問題の開始から完了までを追跡する主要なケースIDとして機能します。 | ||
|
説明
品質イベントは、1件の品質問題に関連するすべてのアクティビティ、タスク、意思決定を結び付ける中心的なケース識別子です。SAPでは通常、品質通知番号(QMNUM)に相当します。 プロセスマイニングでは、この識別子でイベントを分析することで、各品質ケースのエンドツーエンドの経過を再構成できます。これは、プロセスフローの可視化、ケース全体のサイクルタイムの計算、解決プロセスにおける一般的な経路や逸脱経路の特定に欠かせません。ほぼすべての品質管理分析を支える基盤になります。
重要な理由
関連するすべてのアクティビティを1つの一貫したプロセスインスタンスに結び付けるための必須キーです。品質問題への対応をエンドツーエンドで分析できます。
入手先
QMELテーブルのQMNUMフィールドに記録されている品質通知番号です。
例
200000018200000019200000020
|
|||
|
開始時刻
EventTimestamp
|
特定のアクティビティまたはイベントが発生した正確な日時です。 | ||
|
説明
開始時刻、つまりイベントのタイムスタンプは、アクティビティが実行された正確な時点を記録します。イベントを時系列に並べ、イベント間の所要時間を計算するうえで欠かせません。たとえば、通知の作成、タスクの完了、ステータスの変更が発生した時点を記録します。 プロセスマイニング分析では、サイクルタイム、処理時間、待機時間など、時間に基づくすべての指標を計算する基盤になります。ボトルネックの特定、スループットの分析、時間ベースのSLAや目標に対するパフォーマンスの監視が可能になります。正確なタイムスタンプは、プロセスモデル全体の信頼性を保つうえで重要です。
重要な理由
このタイムスタンプは、イベントの順序付け、サイクルタイムや待機時間などすべてのパフォーマンス指標の計算、プロセスの動態把握に欠かせません。
入手先
通常は、ステータス変更または文書作成に関連する日付・時刻フィールドから取得します。QMELのERDAT/ERZEIT(作成日/作成時刻)や、CDHDRの変更タイムスタンプなどが例です。
例
2023-04-15T09:00:12Z2023-04-18T14:35:00Z2023-05-01T11:21:45Z
|
|||
|
ユーザー
ChangedBy
|
アクティビティを実行した、または最後に変更を行った担当者のユーザーIDです。 | ||
|
説明
特定のプロセスステップを実行した担当ユーザーを識別する属性です。SAPでは、「Changed By」(AENAM)または「Created By」(ERNAM)フィールドに相当することが多いです。 ユーザー別に分析することで、作業負荷の分布、トレーニングの必要性、ユーザー固有のプロセス逸脱を把握できます。特定のユーザーの処理時間が長い理由や、標準外の経路を選びやすい理由を調査するなど、リソースに基づく分析の基盤になります。
重要な理由
ユーザーのパフォーマンス、作業負荷の分布、標準手順の遵守状況を分析できます。リソースの最適化に欠かせない情報です。
入手先
QMEL-ERNAM(作成者)などのヘッダーテーブルおよび明細テーブルから取得するか、変更ログ(CDHDR-USERNAME)から導出します。
例
SMITHJWILSONAPROCESS_AUTOMATION_BOT
|
|||
|
優先度
NotificationPriority
|
品質通知に割り当てられた優先度で、対応の緊急性を示します。 | ||
|
説明
優先度は、品質イベントへの対応の緊急性を定義します。チームが作業を整理し、重要度の高い問題から対応できるようにします。SAPでは複数の優先度タイプを設定でき、目標応答時間に影響する場合があります。 この属性を使うと、高優先度の項目が低優先度の項目より実際に早く処理されているかを分析できます。高優先度のケースがプロセス内で滞留しているなど、非効率な状況も明らかにできます。「品質イベント処理量分析」などのダッシュボードで重要な分析軸となります。
重要な理由
プロセスのパフォーマンスが業務上の緊急性に沿っているかを分析し、優先度の高い問題をより早く解決できているかを確認できます。
入手先
QMELテーブルのQMPRI項目にあります。説明はTQ05テーブルにあります。
例
1234
|
|||
|
品質通知タイプ
QualityNotificationType
|
顧客苦情、社内問題、仕入先不良など、品質通知の分類です。 | ||
|
説明
この属性は、品質イベントの発生源と性質に基づいて分類します。SAPの標準タイプには、顧客苦情、社内問題報告、仕入先関連の不良などがあります。この分類によって、その後のプロセスフローと必要な文書が決まります。 通知タイプ別にプロセスを分析すると、問題の種類によって対応方法や効率が異なるかどうかを把握できます。「品質イベント処理量分析」などのダッシュボードで、問題カテゴリごとのサイクルタイムやプロセス経路を絞り込み、比較する際にも役立ちます。
重要な理由
プロセスを分割して分析できるため、品質問題の種類によって異なる経路をたどるか、パフォーマンス特性が異なるかを確認できます。
入手先
QMELテーブルのQMART項目にあります。
例
Q1Q2F2
|
|||
|
担当部門
ResponsibleDepartment
|
特定のタスクの実行または品質イベントの管理を担当する部門または機能領域です。 | ||
|
説明
この属性は、アクティビティまたは品質イベント全体に割り当てられた組織単位を示します。品質保証チーム、エンジニアリング部門、生産部門などが該当します。 部門間の連携や引き継ぎを分析するうえで重要な項目です。担当が別の部門へ移る際に発生する遅延を特定し、「部門間引き継ぎ遅延」ダッシュボードでの分析に役立ちます。また、プロセスビューを部門別に絞り込み、各部門の業務の進め方を確認できます。
重要な理由
部門間の引き継ぎを分析し、組織上のボトルネックを特定するとともに、各チームがプロセスにどのように関与しているかを把握するために欠かせません。
入手先
通常は、通知またはタスクに関連付けられたパートナー機能、あるいは人事マスターデータに登録されたユーザーの組織上の所属から取得します。直接の項目ではない場合があります。
例
品質保証生産ライン3仕入先品質エンジニアリング
|
|||
|
根本原因
RootCauseCode
|
品質問題の特定された根本原因を示すコードまたはテキストです。 | ||
|
説明
根本原因属性は、品質不良または不適合の背景にある理由を記録します。正しい根本原因を特定することは、効果的な是正処置と予防処置を定義する基礎となるため、品質管理プロセスの重要な段階です。 この属性は、「根本原因分析サイクルタイム」および「繰り返し問題パターン検出」ダッシュボードに欠かせません。根本原因別に分析すると、組織的な問題を特定できます。たとえば、特定の根本原因でプロセスマップを絞り込むことで、固有のプロセス経路や長い解決時間につながっているかを確認できます。
重要な理由
根本原因を製品、部門、プロセスの非効率性と関連付けて分析し、組織的な問題を明らかにできます。予防処置の検討にも役立ちます。
入手先
通常はQMURテーブル(通知原因)のURCOD項目に格納されます。
例
オペレーターエラー材料不良機械故障
|
|||
|
目標解決日
TargetResolutionDate
|
品質イベントの計画上または要求される完了日です。 | ||
|
説明
品質イベントを完全に解決してクローズする期限を表します。パフォーマンスやサービスレベル合意(SLA)の遵守状況を測定する基準としてよく使われます。 この属性は、期限内完了率の計算や期限超過ケースの特定に欠かせません。「品質イベント期限内完了」ダッシュボードと「品質アクション期限内率」KPIは、実際の完了日とこの目標日を比較して算出します。作業の優先順位付けやリソース管理にも役立ちます。
重要な理由
期限内のパフォーマンスを測定する基準となり、プロセス効率とSLAのコンプライアンスを評価する重要なKPIです。
入手先
QMEL-QMDAT(要求終了日)またはタスクレベルのQMSM-PSTERにあります。
例
2023-05-302023-06-152023-07-01
|
|||
|
製品
MaterialNumber
|
品質イベントの対象となった製品または品目を一意に識別する値です。 | ||
|
説明
この属性は、品質イベントを特定の製品または品目に関連付けます。品質保証において重要な関連付けであり、問題が繰り返し発生する製品や不良率の高い製品を特定できます。 プロセスマイニングで製品別に分析すると、特定の製品の解決時間が長いか、特定の根本原因と関連しているかなどのパターンを検出できます。「繰り返し問題パターン検出」ダッシュボードでは、製品と品質問題を関連付けて分析でき、対象を絞った品質改善の取り組みに役立ちます。
重要な理由
品質問題を特定の製品に関連付け、製品別の不良率、根本原因、解決パターンを分析できます。
入手先
品質通知明細テーブルQMFEのMATNR項目にあります。
例
FIN-1001RAW-205ASEMI-303B
|
|||
|
アクションの有効性
EffectivenessEvaluation
|
実施したアクションが有効だったかを判定する検証結果です。 | ||
|
説明
この属性は、有効性確認の結果を記録します。品質管理のサイクルを完了する重要な最終段階であり、実施した是正処置または予防処置によって根本原因を解消し、再発を防止できたかを確認します。 「アクション有効性検証」ダッシュボードと「アクション有効性検証率」KPIの主要な属性です。問題解決プロセスそのものを直接把握できます。無効なアクションの割合が高い場合は、根本原因分析またはアクション計画の段階を改善する必要があります。
重要な理由
問題解決プロセスの成果を直接測定し、アクションによって問題の再発を実際に防止できているかを示します。
入手先
通常は、品質通知内のフォローアップアクションまたは特定のタスクステータスに格納されます。カスタム項目、または特定のステータスコードに基づく値の場合もあります。
例
有効無効監視が必要
|
|||
|
ソースシステム
SourceSystem
|
SAP S/4HANAの特定のインスタンスなど、データの抽出元となったソースシステムを識別します。 | ||
|
説明
品質管理データの出所を示す属性です。複数のERPや統合システムがある環境では、データソースを区別し、データの整合性を確保するうえで欠かせません。 分析では、異なるシステムや組織単位をまたいだプロセスのフィルタリングや比較に利用できます。特定のデータセットでは固定値になることが多い一方、データガバナンスとコンテキストの把握には必須です。
重要な理由
データの出所に関する重要なコンテキストを提供します。データガバナンスや、複数の相互接続されたシステムがある環境で欠かせません。
入手先
通常は、データ抽出時に追加する固定値で、SAP S/4HANAのクライアントとシステムIDを識別します。
例
S4H_PROD_100SAP_QM_EUS4HANA_QAS_200
|
|||
|
プラント
Plant
|
品質イベントが発生した、または管理されている製造拠点や場所です。 | ||
|
説明
プラント属性は、品質イベントに関連する工場や倉庫などの物理的な場所を示します。品質問題が発生した場所について、地理的または組織的な背景を提供します。 比較分析に有効な分析軸です。プラント別に絞り込みまたはグループ化することで、各拠点のパフォーマンスを比較し、拠点固有の問題を特定できます。また、パフォーマンスの高い拠点のベストプラクティスを共有できます。「根本原因分析のサイクルタイムが最も長いプラントはどこか」といった問いにも答えられます。
重要な理由
異なる業務拠点のパフォーマンスを比較し、拠点固有の問題やベストプラクティスを特定できます。
入手先
通知ヘッダーに関連付けられたプラントはQMEL-WERKSにあります。特定の品目に関連する場合は、明細レベルにもあります。
例
100017102000
|
|||
|
最終データ更新
LastDataUpdate
|
このレコードのデータがソースシステムから最後に更新された日時を示すタイムスタンプです。 | ||
|
説明
ソースシステムから最後にデータを抽出または更新した時点のタイムスタンプを示す属性です。分析対象データがどの程度新しいかを利用者に伝えます。 分析用のダッシュボードやレポートでは、データの最新性に関する期待値を適切に管理するうえで、この情報の表示が欠かせません。最近のプロセス変更と、古いデータによる見かけ上の結果を区別するのに役立ちます。
重要な理由
データの最新性を利用者に伝えます。プロセスマイニング分析に基づいて、適時かつ正確に意思決定するうえで重要です。
入手先
データ更新時に、データ抽出ツールまたはパイプラインが生成して入力するメタデータフィールドです。
例
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
手戻りかどうか
IsRework
|
アクティビティまたは一連のアクティビティが手戻りを表すかどうかを示すブール値です。 | ||
|
説明
ケース内で特定の手順が繰り返された場合にtrueとなり、最初の作業が不十分だったことを示します。たとえば、同じケースで「根本原因分析」の後に「調査タスク割り当て」が再度実行された場合、手戻りループが発生していると判断できます。 この属性は「是正処置手戻り率」KPIを直接支えます。手戻りは無駄な作業とプロセスの非効率性を表すため、特定して定量化することはプロセスマイニングの主要な目的です。プロセスマップで手戻りループを強調表示すると、品質と効率を改善できる大きな機会を見つけられます。
重要な理由
手順の繰り返しを特定してプロセスの非効率性を定量化し、無駄な作業と初回で正しく完了する割合を改善する機会を明らかにします。
入手先
計算属性です。1つのケース内でアクティビティの並びが繰り返されていることを検出し、プロセスマイニング分析中に導出します。
例
truefalse
|
|||
|
期限内完了
IsOnTimeCompletion
|
品質イベントが目標解決日までに完了したかどうかを示すブール値です。 | ||
|
説明
この計算フラグは、品質イベントの実際の完了タイムスタンプと「目標解決日」を比較します。目標日以前にイベントがクローズされていればtrue、それ以外はfalseです。 パフォーマンス監視のための明確で直接的な指標であり、「品質イベント期限内完了」ダッシュボードと「品質アクション期限内率」KPIの基礎となります。部門、製品、通知タイプなどの軸で、期限内のパフォーマンスを簡単に絞り込み、集計できます。
重要な理由
期限に対するパフォーマンスを二値で明確に示すため、SLAのコンプライアンスを簡単に測定して報告できます。
入手先
最終クローズアクティビティのタイムスタンプと「TargetResolutionDate」属性を比較して算出する計算属性です。
例
truefalse
|
|||
|
通知ステータス
SystemStatus
|
「未処理」や「完了」など、品質通知の現在の処理状況です。 | ||
|
説明
システムステータスは、ライフサイクル上の品質イベントの現在の状態を示します。SAPではステータス管理システムを使用しており、OSNO(未処理通知)、NOPR(処理中の通知)、NOCO(完了通知)などのステータスで進捗を表します。 この属性は、イベントログのアクティビティを導出するためによく使われます。また、ケースを絞り込むための項目としても有用です。たとえば、未完了または最近完了した品質イベントだけを分析できます。正確なプロセスモデルを作成するには、ステータスの遷移を把握することが重要です。
重要な理由
ケースの現在の状態を示します。アクティブなケースと完了したケースを絞り込めるほか、プロセスのアクティビティ自体を導出する際にも役立ちます。
入手先
さまざまなSAPオブジェクトのステータス情報を格納するJESTテーブルおよびJSTOテーブルから取得します。QMEL-OBJNRで関連付けます。
例
OSNO NOPRNOCOTSCO
|
|||
|
顧客
CustomerNumber
|
該当する場合に、品質イベントに関連付けられた顧客を識別する値です。 | ||
|
説明
この属性は、品質イベントを特定の顧客に関連付けます。「顧客苦情」などの通知タイプで特に重要です。この情報を追跡することで、顧客関係を管理し、品質問題が顧客に与える影響を把握できます。 顧客別に分析すると、特定の顧客で品質問題が多く発生しているか、顧客によって解決時間が異なるかを確認できます。「品質イベントの重大度と影響」ダッシュボードでは、顧客の属性を影響分析に加えられます。
重要な理由
品質イベントを顧客に関連付け、顧客別の問題を分析できます。重要顧客への優先的なサポートにも役立ちます。
入手先
通常は通知のパートナー機能にあります。販売注文に関する苦情の場合は、QMEL-KUNUMに格納されていることもあります。
例
CUST-10045CUST-20399CUST-80110
|
|||
品質管理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
アクションの効果を検証済み
|
実施した是正措置または予防措置が成功し、品質問題が再発せずに解決されたことを確認します。効果確認タスクまたは最終品質レビューの完了時に取得します。 | ||
|
重要な理由
解決プロセス全体を検証する重要なマイルストーンです。検証の成功率が高いことは、品質管理システムが効果的に機能し、問題の再発削減につながっていることを示します。
入手先
通常は、QMSMテーブルの「Effectiveness Check」タスクの完了から推定します(完了日ERLDTを使用)。
取得
QMSMで、効果検証タスクの完了タイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
使用決定
|
検査ロットの品目を受け入れるか拒否するかなど、品目の品質に関する正式な決定を示します。検査に起因する品質問題における独立したイベントで、使用決定が保存された時点で取得します。 | ||
|
重要な理由
検査主導のプロセスでは、品目のブロックやリリースなど、その後のアクションを決める主要なマイルストーンです。タイミングと結果を分析することで、製品品質管理の効率を把握できます。
入手先
使用決定テーブルQAVEに記録される明示的なイベントです。検査ロット(PRUEFLOS)に関連付けられたレコードの作成タイムスタンプが、このアクティビティを示します。
取得
QAVEテーブルで、対象検査ロットの作成タイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
品質通知の作成
|
このアクティビティは、品質に関する問題、不具合、苦情が正式に記録される品質管理プロセスの開始を示します。SAP S/4HANAで品質通知を作成すると、初期情報が記録され、一意の識別子が割り当てられて、ケースが開始されます。 | ||
|
重要な理由
主要な開始イベントであるこのアクティビティは、品質問題の解決プロセスにおけるエンドツーエンドのサイクルタイムを測定するうえで欠かせません。品質イベントへの対応から完了までにかかる時間を追跡する基準点になります。
入手先
QMELの品質通知ヘッダーテーブルから取得する明示的なイベントです。作成タイムスタンプは通常、該当する通知番号QMNUMのERDATフィールドに記録されています。
取得
QMELテーブルから、対象通知の作成タイムスタンプ(ERDAT)を使用します。
イベントタイプ
explicit
|
|||
|
是正措置の実施
|
是正措置計画で定義された作業が完了したことを示します。通常は、品質通知内の担当是正措置タスクが完了として設定された時点で取得します。 | ||
|
重要な理由
品質問題の解決に向けた対応が実施されたことを示す重要なマイルストーンです。アクションの期限内完了率と、解決フェーズ全体の効率を測定するうえで欠かせません。
入手先
QMSMテーブルの是正措置タスクの完了から推定します。完了日はERLDTフィールド、またはJEST/JCDSテーブルの「Completed」ステータス変更に記録されます。
取得
QMSMテーブルで、是正措置タスクの完了タイムスタンプ(ERLDT)を特定します。
イベントタイプ
inferred
|
|||
|
根本原因分析の完了
|
品質問題の根本原因が特定され、調査フェーズが完了したことを示します。通常は、通知内の「Root Cause Analysis」タスクの完了から推定します。 | ||
|
重要な理由
調査プロセスの所要時間と効率を測定する重要なマイルストーンです。このステップまでの遅延を特定することで、問題分析や意思決定におけるボトルネックを把握できます。
入手先
QMSMテーブルの調査タスクまたはRCA固有タスクの完了から推定します。ステータス変更、またはタスク完了日フィールド(ERLDT)の入力によって完了を特定します。
取得
QMSMテーブルで、該当する根本原因分析タスクの完了タイムスタンプ(ERLDT)を特定します。
イベントタイプ
inferred
|
|||
|
通知の完了
|
品質通知に必要なすべてのアクションが実施され、業務上の観点で問題が解決したことを示します。システム上の正式なステータス変更です。 | ||
|
重要な理由
業務上の解決時間を測定する主要な終了点です。技術的なクローズが保留中であっても、プロセス所有者の観点ではケースが完了したことを確認できます。
入手先
品質通知オブジェクトのステータス変更から推定します。JCDSテーブルで「NOCO」(通知完了)などのステータスが設定された時点のタイムスタンプを特定します。
取得
JCDSテーブルで、「Notification completed」ステータスが設定された時点のタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
アクション計画の承認
|
提案された是正措置計画または予防措置計画が審査され、実施に進む承認を得たことを示します。このステップは独立したイベントとして記録されないことが多く、処理のためにタスクがリリースされた時点から推定します。 | ||
|
重要な理由
この承認段階で長い遅延が発生すると、解決プロセス全体が大幅に遅れます。所要時間を分析することで、管理上のボトルネックとガバナンスを効率化できる機会を特定できます。
入手先
通常は、QMSMテーブルのタスクにおける「Released」などのステータス変更から推定します。このステータス変更のタイムスタンプは、タスクオブジェクトに紐づくJCDSテーブルから取得します。
取得
是正措置または予防措置タスクに「Released」ステータスが設定された時点のタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
予防措置の実施
|
計画した予防措置が正常に実施されたことを示します。システムで該当する予防措置タスクの完了を記録することで取得します。 | ||
|
重要な理由
予防措置の完了は、成熟した品質プロセスにおける重要なステップです。このアクティビティを追跡することで、将来の問題を防ぎ、再発を減らす取り組みの実行状況を測定できます。
入手先
QMSMテーブルの予防措置タスクの完了から推定します。ERLDTフィールド、または「Completed」ステータスの変更によって示されます。
取得
QMSMテーブルで、予防措置タスクの完了タイムスタンプ(ERLDT)を特定します。
イベントタイプ
inferred
|
|||
|
予防措置の提案
|
品質問題の再発を防ぐ計画が作成されたときに発生するアクティビティです。是正措置と同様に、「Preventive Action」タスクの作成によって記録することが多いです。 | ||
|
重要な理由
このイベントは、発生後の対処だけでなく、予防的な品質改善を重視しているかを評価するうえで重要です。長期的な解決に向けた取り組みの開始を示します。
入手先
対象の品質通知について、QMSMテーブルに「Preventive Action」コードのタスクが作成された時点で取得します。
取得
予防措置タイプのタスクについて、QMSMテーブルの作成タイムスタンプ(ERDAT)を使用します。
イベントタイプ
explicit
|
|||
|
効果確認の実施要
|
実施したアクションによって問題が正常に解決されたことを確認するため、フォローアップ検証が必要であることを示します。通常は、通知に設定された特定のステータス、または専用の検証タスクの作成によって表されます。 | ||
|
重要な理由
このアクティビティにより、品質管理プロセスに重要な検証ループを組み込めます。アクションの実施と、その成功の確認を区別できます。
入手先
品質通知のステータス変更(JEST/JCDS経由)、またはQMSMテーブルでの「Effectiveness Check」タスクの作成から推定できます。
取得
ステータス変更、またはQMSMでの検証タスク作成のタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
是正措置の提案
|
特定された問題を是正する計画が正式に記録された時点を示します。SAPでは通常、品質通知内に「Corrective Action」タスクを作成することで記録します。 | ||
|
重要な理由
このイベントから問題解決フェーズが始まります。根本原因分析からこのステップまでの時間を測定すると、アクション計画の策定における遅延を把握できます。
入手先
対象の品質通知について、QMSMテーブルに「Corrective Action」コードのタスクが作成された時点で取得します。
取得
是正措置タイプのタスクについて、QMSMテーブルの作成タイムスタンプ(ERDAT)を使用します。
イベントタイプ
explicit
|
|||
|
調査タスクの割り当て
|
根本原因の調査など、特定のタスクが正式に作成され、担当者または部門に割り当てられたときに発生するイベントです。品質通知内にタスクレコードが作成された時点で取得します。 | ||
|
重要な理由
タスクの割り当てを追跡することで、作業負荷の分布を把握し、リソース配分におけるボトルネックを特定できます。調査フェーズの開始を示すため、根本原因分析のサイクルタイムを測定する重要な入力になります。
入手先
品質通知に紐づくタスク管理テーブルQMSMから取得します。調査用など、関連するコードを持つタスクの作成日(ERDAT)がこのイベントを示します。
取得
調査に関連するタスクについて、QMSMテーブルの作成タイムスタンプ(ERDAT)を使用します。
イベントタイプ
explicit
|
|||
|
通知のクローズ
|
システム上で品質通知を技術的に最終クローズしたことを示します。この時点以降は通知を変更できず、レコードのライフサイクルが完全に終了します。 | ||
|
重要な理由
プロセスの最終終了イベントです。「通知の完了」から「通知のクローズ」までの時間を分析することで、管理上のクローズ手続きにおける遅延を把握できます。
入手先
品質通知のステータス変更、具体的にはアーカイブまたは最終クローズのステータスが設定された時点から推定します。この変更はJCDSテーブルにタイムスタンプ付きで記録されます。
取得
JCDSテーブルで、通知に最終的な「Closed」ステータスが設定された時点のタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
通知を処理中に設定
|
新しく作成された通知が品質チームによって処理対象として取り上げられ、実際の処理が始まった時点を示します。通常は、作業開始を示すシステムステータスの変更から推定するイベントです。 | ||
|
重要な理由
このアクティビティにより、問題を記録しただけの状態と、実際に作業を開始した状態を区別できます。作成からこのステップまでの時間差を分析すると、問題の受領確認やリソース割り当ての遅れを把握できます。
入手先
品質通知オブジェクトのステータス変更から推定します。JESTおよびJCDSテーブルのステータス変更ログを分析し、「NOPO」(通知を処理中)などのステータスを追跡します。
取得
JCDSテーブルで、通知に「処理中」ステータスが設定された時点のタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
関係者への通知
|
顧客や社内部門など、関係するステークホルダーに解決内容を伝えることを示します。システムで自動化されたイベントであることは少なく、手作業のステップになることが多いです。 | ||
|
重要な理由
関係者への迅速な連絡は、顧客満足度と透明性に直結します。完了から通知までの遅延を測定することで、コミュニケーションプロセスの不足を把握できます。
入手先
このアクティビティをSAPから直接取得するのは困難です。QMSMで「Notify Stakeholder」と記載された手動タスクの完了から推定するか、メールログなど外部システムを分析する必要があります。
取得
手動の連絡タスクを使用している場合は、その完了を特定します。それ以外の場合、通常は利用できません。
イベントタイプ
inferred
|
|||
抽出ガイド
始める準備はできていますか?
このテンプレートを使ってデータをすばやく準備し、品質管理プロセスの最適化を始めてください。SAP S/4HANAで新たな気づきを得て、効率を高められます。
品質マネジメントを強化:サイクルタイムをすぐに30%短縮
SAP S/4HANAのボトルネックを特定し、QMのサイクルタイムを30%短縮
クレジットカードは不要です。数分で設定できます。