貴社の品質管理データテンプレート
貴社の品質管理データテンプレート
- 収集を推奨する項目
- 追跡すべき主要アクティビティ
- 抽出の手引き
品質管理属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ名
ActivityName
|
品質管理プロセス内で発生した特定のタスクまたはステップの名前。 | ||
|
説明
この属性は、品質イベントの管理の一環として取られた単一のイベントまたはアクションを記述します。これらのアクティビティのシーケンスは、それぞれのタイムスタンプによって順序付けられ、各ケースのプロセスフローを形成します。 アクティビティ名の分析はプロセスマイニングの中心です。これにより、実際のプロセスモデルの発見、コンフォーマンスチェックのための目的のモデルとの比較、および特定の
その重要性
この属性は、プロセスフローのマッピング、逸脱の特定、および作業が実際にどのように実行されているかを理解するための基本です。
取得元
この情報は通常、Oracle Quality Managementモジュール内のイベントログ、ステータス変更レコード、またはアクション履歴テーブルから派生します。
例
品質問題特定済み調査開始是正処置計画承認済み最終レビューとクローズ
|
|||
|
イベント開始時刻
EventStartTime
|
アクティビティまたはイベントの開始時点を示すタイムスタンプ。 | ||
|
説明
この属性は、特定のプロセスステップが開始された正確な日付と時刻を提供します。これは、イベントを時系列で順序付けし、各品質イベントケースのプロセスシーケンスを構築するために使用される主要な時間要素です。 分析において、イベント開始時刻はサイクルタイム、期間、およびアクティビティ間の待機時間を計算するために極めて重要です。連続するステップ間の長い遅延を強調表示することでボトルネックの特定を可能にし、根本原因分析リードタイムなどの時間ベースのKPIに対するパフォーマンスを追跡するために使用されます。
その重要性
このタイムスタンプはプロセス分析のバックボーンであり、すべての時間ベースの計算とアクティビティの正しい順序付けを可能にします。
取得元
このタイムスタンプは通常、品質アクションおよび収集計画に関連付けられたトランザクションログまたは履歴テーブルで発見され、しばしばCREATION_DATEなどの名前が付けられています。
例
2023-04-15T09:00:12Z2023-04-16T11:30:00Z2023-05-01T14:22:45Z
|
|||
|
品質イベント
QualityEventId
|
不適合、苦情、逸脱など、単一の品質イベントに対する一意の識別子。 | ||
|
説明
品質イベントIDは、最初の報告から最終クローズまでの関連するすべての プロセスマイニング分析において、この属性は各品質イベントのエンドツーエンドのジャーニーを再構築するための基本です。これにより、全体のサイクルタイムの計算、プロセスバリアントの特定、および異なるタイプのイベントがどのように処理されるかの分析が可能になります。すべてのアクティビティログを特定のQuality Event IDにリンクすることで、アナリストは完全なプロセスフローを可視化し、システム的なボトルネックやコンプライアンスの問題を特定できます。
その重要性
このIDは、単一のケースのスコープを定義するため不可欠であり、品質イベントの正確な追跡とエンドツーエンドのパフォーマンスメトリックの計算を可能にします。
取得元
これは通常、Oracle Quality Management内の主要な品質イベントまたは収集計画テーブル(例: QA_RESULTS)における主キーです。
例
NC-2023-00123CAPA-45892QE-500-A
|
|||
|
イベントの終了時刻
EventEndTime
|
アクティビティまたはイベントが完了した時点を示すタイムスタンプ。 | ||
|
説明
イベント終了時刻は、特定のアクティビティの完了を示します。イベント開始時刻と組み合わされることで、そのアクティビティの処理時間を定義します。一部のシステムでは、アクティビティが瞬時に完了する場合があり、その場合、開始時刻と終了時刻は同じになります。 この属性は、詳細な期間分析に不可欠です。これにより、アナリストはアクティブな処理時間(開始時刻と終了時刻の間の期間)と待機時間(あるアクティビティの終了から次のアクティビティの開始までの期間)を区別できます。これは、リソースが積極的に関与している場所と、引き継ぎによって遅延が発生している場所を特定するための鍵となります。
その重要性
アクティビティの処理時間を正確に算出できるため、非効率なタスクと長い待機期間を特定するのに役立ちます。
取得元
これは、開始時間と同じトランザクションまたは履歴テーブルで利用できる場合があります。LAST_UPDATE_DATEまたは特定の完了タイムスタンプとして提供されることもあります。また、後続のイベントの開始時間から推測されることもあります。
例
2023-04-15T09:15:30Z2023-04-16T12:00:00Z2023-05-02T10:00:00Z
|
|||
|
処理時間
ProcessingTime
|
アクティビティに実作業として費やした時間。 | ||
|
説明
処理時間は、単一のアクティビティについてイベント開始時刻とイベント終了時刻の間で計算される期間です。これは、アクティビティ間の待機時間とは対照的に、アクティブな作業時間を表します。 この指標は、詳細なパフォーマンス分析のコアコンポーネントです。あるケース内のすべてのアクティビティの処理時間を合計することで、総接触時間を理解できます。総接触時間と全体のケースサイクルタイムを比較することで、プロセスにおける付加価値作業とアイドル状態の待機時間の割合が明らかになり、リーンやシックスシグマの改善活動にとって重要な洞察が得られます。
その重要性
実際の作業時間とアイドル状態の待機時間を分離し、どのタスクが時間を消費しているかを特定するのに役立ちます。
取得元
このメトリックは、データ変換中にEventStartTimeおよびEventEndTime属性から計算されます。
例
PT15M30SPT2HP1D
|
|||
|
担当ユーザー
AssignedUser
|
アクティビティを実行するか、品質イベントを所有するように割り当てられた個々のユーザー。 | ||
|
説明
この属性は、特定のタスクまたは品質イベント全体の管理を担当する人物を指定します。これは、担当部門よりも詳細なレベルの情報を提供します。 ユーザー別に分析することは、個人の業務量を理解し、研修の必要性を特定し、優秀な人材を認識するのに役立ちます。また、作業が常に再割り当てされたり、特定の個人でタスクが停滞したりするパターンも明らかにできます。この詳細レベルは、パフォーマンス管理と詳細なリソース最適化に役立ちます。
その重要性
個々の業務量やパフォーマンスを詳細に分析できるため、リソースの制約や研修の機会を特定するのに役立ちます。
取得元
Oracle品質管理のドキュメントを参照してください。ユーザー割り当て情報は、通常、品質イベントに関連付けられたアクションまたはワークフローテーブルに保存されます。
例
j.smitha.jonesr.williams
|
|||
|
担当部署
ResponsibleDepartment
|
品質イベントまたは現在のアクティビティを担当する部門または機能領域。 | ||
|
説明
この属性は、品質イベントを処理するために割り当てられたチームまたは部門を特定します。これは、品質保証、エンジニアリング、生産、または他のグループである可能性があり、イベントのライフサイクルが進むにつれて変更されることがあります。 プロセスマイニングにおいて、担当部門ごとに分析することは、業務量の配分を理解し、部門ボトルネックを特定し、異なるチーム間のパフォーマンスを比較するために重要です。「品質イベントリソース配分」ダッシュボードをサポートし、どの部門がどのタイプのアクティビティに関与しているかを示し、リソース管理の最適化に役立ちます。
その重要性
部門ごとの業務量、パフォーマンス、ボトルネックの分析を可能にし、リソース計画と組織改善に不可欠な情報を提供します。
取得元
Oracle品質管理のドキュメントを参照してください。これは、品質イベントにリンクされた品質アクションまたは割り当てに関連するテーブルに保存されている可能性があります。
例
品質工学製造オペレーションサプライヤー品質設計工学
|
|||
|
根本原因カテゴリ
RootCauseCategory
|
品質問題の特定された根本原因の分類。 | ||
|
説明
根本原因分析が実行された後、その結果はしばしば「設備故障」、「人的エラー」、「設計上の欠陥」といった事前定義されたグループに分類されます。この属性は、その最終分類を保存します。 根本原因カテゴリ別にプロセスを分析することは非常に強力です。個々の症状を修正することから、根底にあるシステム的な問題に対処することへと焦点を移すのに役立ちます。例えば、「トレーニング問題」を根本原因とするイベントの数が多い場合、より良い従業員トレーニングプログラムの必要性を示唆し、予防処置の主要な目標となります。
その重要性
この属性は、不具合の根本原因を分析することを可能にすることで、受動的な品質管理から能動的な品質管理への移行の鍵となります。
取得元
Oracle品質管理のドキュメントを参照してください。これは、コレクション計画におけるユーザー定義要素であり、「根本原因分析実行済み」アクティビティ後に設定される可能性が高いです。
例
設備故障材料欠陥ヒューマンエラー手順が守られていない
|
|||
|
現在のステータス
CurrentStatus
|
品質イベントケースの現在のステータス。 | ||
|
説明
この属性は、品質イベントのライフサイクルにおける現在の状態を示し、「オープン」、「調査中」、「承認保留中」、「クローズ済み」などがあります。データ抽出時におけるケースのプロセス上の位置のスナップショットを提供します。 これは運用モニタリングにとって重要な属性であり、「オープン品質イベント&ステータス概要」ダッシュボードを直接サポートします。これにより、管理者は品質問題の現在のパイプラインを迅速に把握し、リソースの優先順位付けを行うことができます。プロセスマイニングでは、最終ステータスでフィルタリングすることで、異なるプロセスパスの結果を分析するのに役立ちます。
その重要性
品質イベントのパイプラインをリアルタイムで可視化し、効果的な運用管理と進行中のケースの優先順位付けを可能にします。
取得元
この情報は通常、品質イベントの主要なヘッダーテーブルで利用可能であり、イベントの最後の既知の状態を反映しています。
例
オープン進行中承認待ちクローズ
|
|||
|
目標解決日
TargetResolutionDate
|
品質イベントの最終クローズの計画または予定日。 | ||
|
説明
この属性は、品質イベントが完全に解決されると予想される期限を表します。これは、サービスレベル契約(SLA)または内部目標として機能し、しばしばイベントの重大度またはタイプに基づいて決定されます。 この日付はパフォーマンス監視にとって基本であり、「CAPA実施期限内達成率」KPIの計算に直接使用されます。アクティビティの実際の完了日付をこのターゲットと比較することで、アナリストは適時性を測定し、遅延のリスクがあるイベントを特定し、期限内パフォーマンスの傾向を追跡できます。これは、解決サイクルタイムの削減に向けた取り組みを支援します。
その重要性
期限内完了のパフォーマンスを測定するためのベンチマークを提供し、適時性KPIの算出やSLA管理に不可欠です。
取得元
Oracle品質管理のドキュメントを参照してください。これは、標準の日付フィールドであるか、品質コレクション計画におけるユーザー定義要素である可能性があります。
例
2023-05-302023-06-152024-01-10
|
|||
|
重大度レベル
SeverityLevel
|
品質イベントの影響度を示す分類です(重大、主要、軽微など)。 | ||
|
説明
重大度レベルは、通常トリアージ中に行われる、品質問題が顧客、コンプライアンス、または事業運営に与える潜在的な影響の評価です。この分類は、リソースの優先順位付けと、必要な対応の緊急度を定義するのに役立ちます。 プロセスマイニングにおいて、この属性はセグメンテーションにとって極めて重要です。アナリストは、重大度の高いイベントと低いイベントでプロセスフロー、サイクルタイム、および結果を比較できます。これにより、「品質イベントトリアージの一貫性」ダッシュボードと「重大度ベースの解決率」KPIがサポートされ、重要な問題が実際に迅速かつ効果的に処理されているかどうかが明らかになります。
その重要性
分析の優先順位付けとセグメンテーションが可能になり、影響の大きい品質イベントが効果的かつ効率的に管理されるようになります。
取得元
Oracle品質管理のドキュメントを参照してください。これは、品質コレクション計画内で設定可能な要素であることが多いです。
例
1 - Critical2 - Major3 - Minor4 - Informational
|
|||
|
`製品識別子`
ProductIdentifier
|
品質イベントに関連付けられた製品の識別子。 | ||
|
説明
この属性は、品質イベントを特定の製品、材料、またはサービスにリンクします。これは、製品コード、SKU、または部品番号である可能性があります。 このリンクは製品品質分析にとって極めて重要です。プロセスマイニングは、異なる製品ライン間での品質管理プロセスを比較したり、品質問題と頻繁に関連付けられる製品を特定したりするために使用できます。これにより、最も必要とされる場所でのエンジニアリングまたは製造改善の取り組みを優先するのに役立ちます。
その重要性
品質イベントを特定の製品と紐付けることで、製品に関連する品質トレンドやプロセスのばらつきを分析できます。
取得元
この情報は、品質収集計画内のフィールドに保存され、しばしばOracle 在庫品目マスターにリンクされます。
例
SKU-100-A-REDPN-987654CHEM-X2
|
|||
|
クローズコード
ClosureCode
|
品質イベントのクローズ理由または結果を示すコードです。 | ||
|
説明
品質イベントがクローズされると、最終結果を分類するためにクローズコードがしばしば割り当てられます。例としては、「アクション有効」、「対応不要」、または「重複問題」などがあります。 この属性は結果分析に非常に役立ちます。異なるクローズコードでフィルタリングすることで、アナリストは成功した結果につながるプロセスパスとそうでないものを研究できます。「重複としてクローズされた問題のプロセスはどのようになっていますか?」といった質問に答えるのに役立ち、トリアージプロセスにおける非効率性を特定できます。
その重要性
ケースの最終結果に関する重要な情報を提供し、どのプロセスパスが成功した解決に繋がったかを分析できるようにします。
取得元
Oracle品質管理のドキュメントを参照してください。これは、最終的なクローズアクティビティ中に設定されるフィールドである可能性が高いです。
例
EFFECTIVENO_ACTIONDUPLICATERISK_ACCEPTED
|
|||
|
ソースシステム
SourceSystem
|
データが抽出された記録システムを特定します。 | ||
|
説明
この属性は、イベントデータの発生元となるアプリケーションまたはシステムを指定します。エンタープライズ環境では、品質イベントデータは、コアとなるOracle Qualityモジュール、個別のCAPAシステム、または顧客クレームポータルなど、複数のソースから来る可能性があります。 分析のために、このフィールドはデータリネージュを理解するのに役立ち、発生元システムに基づいてプロセスをセグメント化するために使用できます。これはデータガバナンスおよびデータ統合問題のトラブルシューティングにとって極めて重要であり、プロセスビューが結合されたデータランドスケープを正確に反映していることを保証します。
その重要性
データ元に関する重要なコンテキストを提供し、データの検証、ガバナンス、および異なるシステム間でのプロセス変動の分析に不可欠です。
取得元
これは通常、データ抽出、変換、ロード(ETL)プロセス中に、データセットの発生源を識別するために追加される静的な値です。
例
Oracle Quality Management R12Oracle EBS QualityQM-PROD
|
|||
|
ビジネスユニット
BusinessUnit
|
品質イベントが発生した、または管理されている組織の事業部門または部署。 | ||
|
説明
この属性は、品質イベントを事業構造の特定の部分に割り当てます。これにより、異なる組織単位間での品質パフォーマンスを分析し、比較するのに役立ちます。 事業単位ごとのプロセス分析のセグメンテーションは、大企業にとって一般的な要件です。これにより、BU固有のダッシュボードが可能になり、特定の部門がより効率的な品質プロセスを持っているか、または固有の課題に直面しているかを特定するのに役立ちます。これは、企業ガバナンスおよび組織全体でのベストプラクティス共有にとって価値があります。
その重要性
組織全体でのパフォーマンス比較と分析を可能にし、全社的な品質管理を支援します。
取得元
これは通常、トランザクションに関連付けられた組織のコンテキストデータの一部であり、しばしばユーザーまたは部門のマスターデータから派生します。
例
医療機器家電製品自動車部品
|
|||
|
最終データ更新
LastDataUpdate
|
ソースシステムからの最新データ更新またはリフレッシュのタイムスタンプ。 | ||
|
説明
この属性は、このイベントのデータがプロセスマイニングデータセットで最後に更新された日時を示します。これはデータの鮮度を反映し、ユーザーが分析の適時性を理解するのに役立ちます。 ダッシュボードやレポートにおいて、このタイムスタンプはユーザーにコンテキストを提供する上で極めて重要です。これにより、リアルタイムデータを見ているのか、特定の時点のスナップショットを見ているのかが明確になり、情報に基づいた運用上の意思決定を行う上で不可欠です。データの最新性に関する透明性を確保します。
その重要性
このタイムスタンプはデータの鮮度に関する透明性を提供し、ユーザーがプロセス分析の最新性を理解できるようにします。
取得元
この値は、データETLプロセス中に生成および保存され、通常はデータパイプラインが最後に正常に実行されたタイムスタンプを表します。
例
2023-10-27T04:00:00Z2023-10-26T04:00:00Z
|
|||
|
合計サイクルタイム
TotalCycleTime
|
品質問題の特定から最終的なクローズまでの総経過時間。 | ||
|
説明
この属性は、単一の品質イベントケースのエンドツーエンドの全期間を測定します。これは、最初のアクティビティ(「品質問題特定済み」)のタイムスタンプと最後のアクティビティ(「最終レビューとクローズ」)のタイムスタンプの差として計算されます。 これは、品質管理プロセス全体の効率性を示す主要な重要業績評価指標(KPI)です。「品質イベントのエンドツーエンドサイクルタイム」ダッシュボードの主要メトリックです。このメトリックを時間ごとに追跡し、重大度や課題カテゴリなどの属性でセグメンテーションすることで、プロセス健全性の概要と改善イニシアチブの影響に関する高レベルのビューが得られます。
その重要性
これは、品質管理プロセス全体の最初から最後まで全体の速度と効率を測定する重要なKPIです。
取得元
これは、プロセスマイニングのデータ処理中にケースレベルで計算されます。各QualityEventIdについて、最初のイベントの開始時間と最後のイベントの終了時間が必要です。
例
P30DT12HP15DP92D
|
|||
|
手戻り
IsRework
|
あるアクティビティが、同じケース内で以前のステップの繰り返しまたは手直しであるかどうかを示すフラグです。 | ||
|
説明
この属性は、特定の 手戻りの特定はプロセスマイニングの主要な機能です。このフラグは、そのような非効率性の定量化を簡素化し、「アクティビティ手戻り頻度」KPIを直接サポートします。どのステップが最も手戻りしやすいか、どのような条件下で手戻りが発生するかを分析することで、研修、データ品質、または承認基準に関する問題を明らかにし、プロセスをより効率的にするための機会を強調表示できます。
その重要性
プロセスの非効率性やループを特定し、無駄を定量化して手戻りの根本原因を突き止めるのに役立ちます。
取得元
これは、データ準備中にイベントログに対するウィンドウ関数またはシーケンシャル分析を使用して計算されます。同じアクティビティ名が同じケースで複数回出現する場合を特定します。
例
truefalse
|
|||
|
是正処置計画ID
CorrectiveActionPlanId
|
品質イベントに対処するために作成された是正措置計画(CAPA)の一意の識別子。 | ||
|
説明
この属性は、品質イベントと、それを解決するために設計された特定の是正予防措置計画との間の直接的なリンクを提供します。これはしばしば、独自のライフサイクルを持つシステム内の別のオブジェクトです。 分析では、このIDを使用して、品質イベントプロセスからのデータとCAPA管理プロセスからのデータを結合し、よりホリスティックなビューを作成できます。これにより、CAPAを必要とするすべてのイベントにCAPAが割り当てられているかどうかを追跡し、それらのアクションの有効性を分析するのに役立ちます。
その重要性
問題(品質イベント)と解決策(是正予防措置、CAPA)を結びつけ、品質管理システムのエンドツーエンド分析をより包括的に実施できるようにします。
取得元
これは、品質イベントレコード上の参照フィールドであり、CAPA専用テーブルまたはモジュール内のレコードを指します。
例
CAPA-2023-088CAPA-2023-091
|
|||
|
期限内である
IsOnTime
|
是正処置が目標解決日までに実施されたかどうかを示すフラグです。 | ||
|
説明
このブール値の属性は、「是正措置実施済み」アクティビティの完了タイムスタンプを、そのケースの「目標解決日付」と比較することで導出されます。アクションが目標日付またはそれ以前に完了した場合にtrueとなり、それ以外の場合はfalseとなります。 この属性は、「CAPA実施期限内達成率」KPIを直接サポートします。各ケースの適時性について明確なバイナリ分類を提供することで、分析とダッシュボード作成を簡素化します。サービスレベルへの順守を監視し、遅延の根本原因を特定するための容易なフィルタリングと集計を可能にします。
その重要性
目標に対する期限内完了のパフォーマンス追跡を簡素化し、この重要なKPIの測定と報告を容易にします。
取得元
これは、データ変換中に計算される派生フラグです。これにはTargetResolutionDateと関連する完了アクティビティのタイムスタンプが必要です。
例
truefalse
|
|||
|
課題カテゴリ
IssueCategory
|
「製品欠陥」や「プロセス逸脱」など、品質問題のカテゴリまたはタイプ。 | ||
|
説明
この属性は、品質イベントの分類を提供し、同様の問題を分析のためにグループ化するのに役立ちます。カテゴリは通常、組織の特定の運用コンテキストを反映するように定義されます。 課題カテゴリ別にプロセスを分析することで、特定のタイプの問題に関連するパターンを特定できます。例えば、「供給元材料」の問題は「内部プロセス」の問題よりもサイクルタイムが大幅に長いことが明らかになる場合があります。このセグメンテーションは、ターゲットを絞ったプロセス改善イニシアチブにとって価値があります。
その重要性
課題を分類することで、特定の課題領域における傾向と根本原因を特定するためのターゲット分析が可能になります。
取得元
Oracle品質管理のドキュメントを参照してください。これは、品質コレクション計画内のユーザー定義要素である可能性が高いです。
例
製品欠陥プロセス逸脱供給元材料顧客クレーム
|
|||
品質管理アクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
最終レビューとクローズ
|
すべての関連アクションが完了し、親品質問題が正式にクローズされる最終ステップです。これは、プライマリレコードのステータスが「クローズ済み」または「解決済み」に最終変更されることで記録されます。 | ||
|
その重要性
これはプロセスの主要な終了イベントです。「平均イベントサイクルタイム」KPIの計算と、全体のプロセススループットの測定に不可欠です。
取得元
親品質課題レコードの最終ステータスが「クローズ済み」に変更されたことから推測されます。この変更のタイムスタンプがイベント時間として使用されます。
取得
主要な品質課題レコードのステータスが「クローズ済み」に変更されたことから推測されます。
イベントタイプ
inferred
|
|||
|
処置の有効性検証済み
|
実施された是正処置が根本原因を成功裡に解決し、再発を防いだことを確認します。これは、ユーザーが検証ステップを完了し、レコードのステータスを更新したときに記録されます。 | ||
|
その重要性
これは重要な結果ベースのマイルストーンであり、「有効性検証率」KPIの基礎となります。是正措置サイクルのループを閉じ、問題が真に解決されていることを保証します。
取得元
CAPAレコードのステータスが「検証完了」または「有効」に変更されたことから推測されます。これには、特定の検証結果フィールドを設定することも含まれる場合があります。
取得
ステータスが「検証完了」または「有効」に変更されたことから推測されます。
イベントタイプ
inferred
|
|||
|
品質問題特定済み
|
このアクティビティは、不適合、逸脱、顧客からの苦情など、新しい品質イベントレコードの作成を示します。ユーザーがOracleで新しい品質問題または品質アクションレコードを作成した際に明示的に記録されます。 | ||
|
その重要性
開始イベントとして、品質管理プロセスの総サイクルタイムを計算し、流入する品質イベントの量を理解するために不可欠です。
取得元
このイベントは、品質問題または品質アクションレコードの作成タイムスタンプから記録されます。これは、QAM_QUALITY_ISSUESやQAM_QUALITY_ACTIONSのようなテーブルで発見される可能性が高いです。
取得
新しい品質課題またはアクションレコードの作成時に記録されるイベントです。
イベントタイプ
explicit
|
|||
|
是正処置計画承認済み
|
指定された権限者による提案された是正措置計画の正式な承認を示します。これは重要な管理ポイントであり、通常は明示的な承認アクションまたは「承認済み」へのステータス変更によって記録されます。 | ||
|
その重要性
この承認は重要なマイルストーンであり、頻繁なボトルネックでもあります。承認時間を分析することで、プロセスを合理化し、手順へのコンプライアンスを確保するのに役立ちます。
取得元
品質アクションまたはCAPAレコードのステータスが「承認済み」に変更されたことから推測されます。承認ワークフローを持つOracleシステムは、多くの場合、この変更を監査テーブルに明示的に記録します。
取得
ステータスが「承認済み」に変更されたことから推測されます。
イベントタイプ
inferred
|
|||
|
課題を分類し優先順位付け済み
|
このアクティビティは、アナリストが最初の評価を完了し、重大度、優先度、問題タイプなどの主要な属性を割り当てたときに発生します。これは通常、問題が「新規」ステータスから「評価済み」または「トリアージ中」ステータスに移行したときに記録されます。 | ||
|
その重要性
このマイルストーンは、「平均トリアージ処理時間」KPIにとって極めて重要です。ここでの遅延は、特に重要な問題に関して、解決プロセス全体を遅らせる可能性があります。
取得元
品質課題レコードのステータス変更、例えば「新規」から「評価中」への変更、または「重大度」や「優先度」のようなフィールドが最初に設定されたことから推測されます。
取得
ステータス変更、または重大度や優先度フィールドの初回設定から推測されます。
イベントタイプ
inferred
|
|||
|
調査開始
|
品質問題の根本原因を特定するための調査フェーズの正式な開始を示します。これは通常、「調査中」への移行など、システム内のステータス変更によって表されます。 | ||
|
その重要性
これは、「根本原因分析リードタイム」KPIを測定するための開始点として機能し、正式な調査が開始されるまでに問題がどれだけ待機するかを特定するのに役立ちます。
取得元
品質課題または関連する品質アクションレコードのステータスが「調査中」に変更されたことから推測されます。このステータス変更のタイムスタンプがイベント時間を提供します。
取得
ステータスが「調査中」または類似の状態に変更されたことから推測されます。
イベントタイプ
inferred
|
|||
|
予防措置実施済み
|
システム全体のリスクを軽減するための予防措置計画に定義されたタスクの完了を示します。これは、ユーザーが予防措置レコードのステータスを「実施済み」または「完了」に更新した際に記録されます。 | ||
|
その重要性
組織がプロアクティブな品質改善を実行する能力を測定します。ここでの遅延は、組織全体でシステム変更を実施する上での課題を示唆する可能性があります。
取得元
関連する予防処置レコードのステータスが「実施済み」または「完了」に変更されたことから推測されます。これは是正処置の追跡方法に似ています。
取得
予防処置レコードのステータスが「実施済み」に変更されたことから推測されます。
イベントタイプ
inferred
|
|||
|
予防措置特定済み
|
システム的な問題に対処し、同様の品質イベントの発生を防ぐための予防措置(PA)の作成を示します。これはしばしば、元の問題にリンクされた新しい予防措置レコードの作成として記録されます。 | ||
|
その重要性
このアクティビティは、単一の問題を修正するだけでなく、将来の問題を未然に防ぐ成熟した品質プロセスを示します。これを追跡することで、プロアクティブな品質改善を測定するのに役立ちます。
取得元
新しい品質アクションレコードが「予防処置」のタイプで作成された際に記録されます。これは多くの場合、元の品質問題または是正処置にリンクされています。
取得
「予防措置」タイプの品質アクションレコード作成時に記録されます。
イベントタイプ
explicit
|
|||
|
是正処置実施済み
|
承認された是正措置計画に示されたタスクの完了を示します。これは通常、ユーザーが是正措置レコードのステータスを「実施済み」または「完了」に更新した際に記録されます。 | ||
|
その重要性
このアクティビティは、「CAPA実施期限内達成率」KPIにとって極めて重要です。なぜなら、計画された修正が実行されたことを示し、目標日付との比較を可能にするからです。
取得元
このイベントは、関連する品質アクションまたはCAPAレコードのステータスが「実施済み」または「完了」に変更されたことから推測されます。
取得
ステータスが「実施済み」または「完了」に変更されたことから推測されます。
イベントタイプ
inferred
|
|||
|
是正処置計画提案済み
|
是正措置が定義され、品質問題にリンクされて、問題解決の手順が概説された場合に発生します。これは、関連する是正措置レコードの作成、または計画がレビュー準備完了であることを示すステータス変更によって記録されます。 | ||
|
その重要性
これは、問題分析から解決策の設計への移行を追跡します。このステップを伴う手戻りは、手戻りKPIで測定され、要件の不明確さや非効果的な計画を示唆する可能性があります。
取得元
これは、CAPAオブジェクト内で新しい是正措置レコードを作成する明示的なイベントであるか、「計画提案済み」または「承認保留中」へのステータス変更から推測されるイベントである可能性があります。
取得
ステータスが「承認待ち」に変更された、または関連する是正処置が作成されたことから推測されます。
イベントタイプ
inferred
|
|||
|
有効性チェックが必要
|
実施されたアクションが有効であったことを確認するためにフォローアップ検証が必要であると、システムまたはユーザーがフラグを立てることを示します。これはしばしば、実施後に発生する自動または手動のステータス変更です。 | ||
|
その重要性
このステップは、重要な検証フェーズを開始します。実施とこのアクティビティの間の時間を理解することで、必要なフォローアップを開始する際の遅延を浮き彫りにできます。
取得元
このイベントは、品質アクションのステータスが「有効性確認保留中」またはワークフロー内の類似の状態に変更されたことから推測されます。
取得
ステータスが「有効性チェック待ち」に変更されたことから推測されます。
イベントタイプ
inferred
|
|||
|
根本原因分析の実施
|
根本原因分析(RCA)の完了と調査結果の文書化を示します。これは通常、調査チームが特定された根本原因で品質問題を更新し、そのステータスを変更した際に記録されます。 | ||
|
その重要性
このアクティビティは、「根本原因分析リードタイム」KPIのエンドポイントです。このステップに至るまでの期間を分析することで、問題解決フェーズにおけるボトルネックを特定するのに役立ちます。
取得元
ステータスが「RCA完了」に変更された、または根本原因カテゴリフィールドが設定され、レコードが保存されたことから推測されます。この更新のタイムスタンプが使用されます。
取得
ステータスが「RCA完了」に変更された、または根本原因フィールドが設定されたことから推測されます。
イベントタイプ
inferred
|
|||
|
課題をトリアージ担当に割り当て済み
|
新たに作成された品質問題を、初期レビューと評価のために特定のユーザーまたはチームに割り当てることを示します。このイベントは、品質問題レコードの担当者または所有者フィールドへの変更を追跡することで推測されることがよくあります。 | ||
|
その重要性
この最初のハンドオフを追跡することは、評価が開始される前の遅延を特定するのに役立ちます。この状態で費やされた時間を分析することで、トリアージキューにおける潜在的なバックログが明らかになります。
取得元
品質課題レコード内の所有者または担当者フィールドの変更から推測されます。これは監査証跡テーブルから、または割り当てワークフローに関連付けられたステータス変更を追跡することで取得される場合があります。
取得
品質課題の「担当者」または「所有者」フィールドの変更から推測されます。
イベントタイプ
inferred
|
|||
|
関係者に解決を通知済み
|
品質イベントの解決を報告者や影響を受けた顧客などの関係者に伝達することを示します。これは捕捉が難しく、クローズ後のステータス変更や記録されたコメントから推測される場合があります。 | ||
|
その重要性
「ステークホルダー通知遅延」KPIにとって重要です。タイムリーなコミュニケーションは、問題が解決された後でも顧客満足度と内部透明性にとって重要です。
取得元
これは自動的にキャプチャするのが困難な場合が多いです。「通知送信済み」のようなステータスから推測されるか、アクティビティまたはコメントフィールドに記録されることがあり、抽出には特別なロジックが必要です。
取得
特定のステータス変更、またはアクティビティログのテキストマイニングから推測されます。
イベントタイプ
inferred
|
|||