貴社の品質管理データテンプレート
貴社の品質管理データテンプレート
- 収集を推奨する項目
- 追跡すべき主要アクティビティ
- 抽出の手引き
品質マネジメント属性
| 名前 | 説明 | ||
|---|---|---|---|
|
品質イベント
QualityEvent
|
単一の「品質イベント」(逸脱、不適合、CAPAなど)の一意の識別子。 | ||
|
説明
「品質イベント」は、特定の品質問題に関連するすべての「活動」、調査、および解決を結び付ける主要なケース識別子として機能します。これは、インシデントの最初の報告から最終クローズまでのライフサイクル全体を接続する中心的な役割を果たします。\n\n「プロセスマイニング」において、この「属性」は、各「品質イベント」のエンドツーエンドの軌跡を再構築するために不可欠です。これにより、さまざまなタイプの「イベント」にわたる「プロセス」のバリエーション、「サイクルタイム」、およびコンプライアンスを分析し、個々の品質インシデントがどのように管理、調査、解決されるかについての包括的なビューを提供します。
その重要性
これは、関連するすべての「活動」を単一の「プロセス」インスタンスにグループ化し、エンドツーエンド分析を可能にする不可欠なケースIDです。
取得元
これは、Veeva Vault Qualityにおける「品質イベント」レコードの主要な識別子であり、しばしば「名前」または「品質イベント」オブジェクト上の一意のIDフィールドとして参照されます。
例
QE-2023-00123CAPA-2023-00456DEV-2023-00789
|
|||
|
アクティビティ名
ActivityName
|
「品質イベント」ライフサイクル内で発生した特定のタスクまたはステップの名前。 | ||
|
説明
この「属性」は、「品質イベント」の管理中に発生する個別のビジネス「活動」または「イベント」を説明します。「調査開始」や「是正処置計画承認済み」など、「プロセス」内のステップです。\n\nこれらの「活動」の順序と頻度を分析することは、「プロセスマイニング」の核です。これにより、実際の「プロセスフロー」を発見し、ステップ間の
その重要性
プロセスのステップを定義し、プロセスフローの可視化と分析を可能にします。
取得元
これは通常、Veeva Vault Quality内のワークフロータスク名、ステータス変更、または監査証跡エントリから導出されます。
例
初期トリアージ完了根本原因分析の実施最終レビューとクローズ
|
|||
|
イベント日時
EventTime
|
特定のアクティビティが開始または発生した日時を示すタイムスタンプ。 | ||
|
説明
この「属性」は、「活動」が実行された正確な日時をキャプチャします。これにより、ケース内のすべての「イベント」の時系列コンテキストが提供されます。\n\nこの
その重要性
この
取得元
これは、タスクの作成日または完了日、あるいは「品質イベント」オブジェクトの監査証跡における「イベント」の
例
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:21:05Z
|
|||
|
ソースシステム
SourceSystem
|
「品質マネジメントデータ」が抽出されたシステム。 | ||
|
説明
この「属性」は、「データ」の発生源を識別します。このケースではVeeva Vault Qualityです。「データガバナンス」に役立ち、特に複数のシステムからの「データ」が結合される場合にコンテキストを提供します。\n\n分析では、フィルタリングと「データ」リネージの確保に使用されます。ソースシステムを理解することは、「データ」を正しく解釈し、データ品質の問題をトラブルシューティングするのに役立ちます。
その重要性
「データ」の発生源に関する重要なコンテキストを提供します。これは、「データガバナンス」、トレーサビリティ、およびマルチシステム分析にとって不可欠です。
取得元
これは静的な値であり、「データ変換」プロセス中にこのソースからのすべてのレコードにラベルを付けるために追加されるべきです。
例
Veeva Vault Quality
|
|||
|
最終データ更新
LastDataUpdate
|
ソースシステムからの最終データ更新または抽出のタイムスタンプです。 | ||
|
説明
この「属性」は、分析対象の「データ」の鮮度を示します。Veeva Vault Qualityから「データ」が最後に抽出され、「プロセスマイニングツール」にロードされた日時が表示されます。\n\nこの情報は、ユーザーが分析の適時性を理解し、
その重要性
データがどれだけ最新で関連性があるかについてユーザーに情報を提供し、プロセス分析の現状を理解できるようにします。
取得元
この
例
2024-05-20T08:00:00Z2024-05-21T08:00:00Z
|
|||
|
アクティビティ所要時間
ActivityDuration
|
単一の「活動」の処理時間。 | ||
|
説明
この指標は、タスクに積極的に作業している時間を測定します。「活動」のEndTimeとStartTimeの差として計算されます。\n\n「活動」期間を分析することは、「プロセス」内のどの特定のステップが最も時間のかかるものかを正確に特定するのに役立ちます。これは待機時間とは異なり、実際の作業量を反映します。個々のタスク内の非効率性を特定し、リソースのキャパシティプランニングを行うための主要な指標です。
その重要性
タスクの実際の作業時間を測定し、非効率な「活動」や自動化・簡素化の機会を特定するのに役立ちます。
取得元
これは、各アクティビティの「EndTime」から「EventTime」(StartTime)を差し引くことによって導き出される計算メトリックです。
例
2時間30分45 minutes8時間15分
|
|||
|
割り当てられた調査員
AssignedInvestigator
|
調査または特定のタスクを実行するために割り当てられたユーザーまたはリソース。 | ||
|
説明
この「属性」は、「品質イベント」ライフサイクル内で特定の「活動」を実行する責任を負う人物、役割、またはチームを識別します。これは、「品質イベント」自体の所有者、または特定のワークフロータスクの割り当て先である可能性があります。\n\nこの「属性」を分析することは、業務負荷の分散、リソースパフォーマンスを理解し、過負荷のチームや個人を特定するのに役立ちます。「調査担当者の業務負荷分散」ダッシュボードにとって不可欠であり、効率を向上させるためのリソース割り当ての最適化にも役立ちます。
その重要性
誰が作業を実行したかを追跡し、業務負荷、リソース効率、トレーニングニーズの分析を可能にします。
取得元
Veeva Vault QualityのQuality Eventオブジェクトまたはその関連ワークフロータスクオブジェクトの所有者または割り当て済みユーザーフィールドにあります。
例
Alice JohnsonBob WilliamsQA調査チーム
|
|||
|
品質イベントステータス
QualityEventStatus
|
「品質イベント」の現在のライフサイクル状態。 | ||
|
説明
この「属性」は、「品質イベント」の現在のステータス(「オープン」、「調査中」、「承認保留中」、「クローズ済み」など)を示します。各ケースがライフサイクルのどこにあるかのスナップショットを提供します。\n\nこれは、「品質イベント進捗概要」ダッシュボードにとって不可欠であり、進行中のケースのリアルタイム監視を可能にします。これにより、マネージャーは進捗を追跡し、停滞している「イベント」を特定し、全体の業務負荷を効果的に管理できます。
その重要性
ケースの現在の状態のスナップショットを提供します。これは、進行中の作業を監視し、停滞している「イベント」を特定するために不可欠です。
取得元
これは、Veeva Vault Qualityの「品質イベント」オブジェクト上の標準フィールドであり、ライフサイクルにおけるその位置を反映します。
例
トリアージ中調査中CAPA提案済みクローズ
|
|||
|
品質イベントタイプ
QualityEventType
|
「品質イベント」の分類(CAPA、逸脱、苦情など)。 | ||
|
説明
この「属性」は、「品質イベント」をその性質に基づいて分類します。異なるタイプの「品質イベント」は、しばしば異なる「プロセスパス」をたどり、異なるコンプライアンス要件と解決タイムラインを持っています。\n\n「イベント」タイプによる分析は、「プロセス」のバリエーションを理解する上で不可欠です。例えば、逸脱とCAPAの処理パフォーマンスと効率を比較でき、特定の「プロセス」コンテキストに合わせて改善イニシアティブを調整するのに役立ちます。
その重要性
さまざまな種類の品質プロセスを区別し、それぞれ独自のワークフロー、SLA、およびコンプライアンスルールを持つことがよくあります。
取得元
これは、Veeva Vault Qualityの「品質イベント」オブジェクト上の標準的な分類フィールドであり、多くの場合、選択リストです。
例
逸脱是正・予防措置(CAPA)不適合クレーム
|
|||
|
担当部門
AssignedDepartment
|
「品質イベント」または「活動」を担当する部門または機能領域。 | ||
|
説明
この「属性」は、「品質イベント」または特定のタスクの処理を担当するビジネスユニットまたは部門(品質保証、製造、研究開発など)を特定します。これは、多くの場合、割り当てられたユーザーのプロファイルから導出されます。\n\nこの次元は、高レベルのパフォーマンス分析にとって重要です。組織のさまざまな部分間で「プロセス」効率とコンプライアンスを比較でき、特定の部門内のシステム的問題を正確に特定し、「調査担当者の業務負荷分散」
その重要性
異なる事業部門間でプロセスパフォーマンスをフィルタリングし比較することで、部門間のボトルネックやベストプラクティスを明らかにできます。
取得元
この情報は、通常、「割り当てられた調査担当者」にリンクされたユーザープロファイル「データ」に保存されるか、「品質イベント」オブジェクト自体に直接フィールドとして存在します。
例
品質保証製造オペレーション研究開発
|
|||
|
目標解決日
TargetResolutionDate
|
「品質イベント」の最終クローズの計画または必須の日付。 | ||
|
説明
この「属性」は、「品質イベント」を解決するためのサービスレベル契約(SLA)または目標期限を定義します。多くの場合、「イベント」の作成日と重大度または種類に基づいて計算されます。\n\nこの日付は、実際のパフォーマンスが測定されるベンチマークです。「オンタイム解決パフォーマンス」ダッシュボードと「オンタイム解決率」KPIにとって不可欠であり、「イベント」が期限内に解決されているかどうか、および遅延に寄与する要因を特定するのに役立ちます。
その重要性
ケース解決のSLAを定義し、期日内パフォーマンスの測定と遅延分析を可能にします。
取得元
これは「品質イベント」オブジェクト上の日付フィールドである可能性が高く、手動で入力されるか、システムによって自動的に計算されます。
例
2024-01-15T23:59:59Z2024-02-28T23:59:59Z2024-03-10T23:59:59Z
|
|||
|
終了日時
EndTime
|
アクティビティの完了時刻を示すタイムスタンプ。 | ||
|
説明
この「属性」は、特定の「活動」またはタスクが完了した日時をキャプチャします。これはStartTime(EventTime)とは異なり、「プロセス」の個々のステップの期間を理解するために不可欠です。\n\n「プロセスマイニング」において、EndTimeはStartTimeと組み合わせて「活動」の処理時間を計算するために使用されます。これは、どの特定のタスクが最も時間がかかっており、全体的な「サイクルタイム」と潜在的な遅延に寄与しているかを特定するために不可欠です。
その重要性
活動処理時間の計算を可能にし、タスクレベルでのボトルネック特定に不可欠です。
取得元
この
例
2023-10-26T11:30:00Z2023-11-01T18:00:10Z2023-11-15T09:45:00Z
|
|||
|
重大度レベル
SeverityLevel
|
「品質イベント」の評価された重大度またはリスクレベル(高、中、低など)。 | ||
|
説明
この「属性」は、「品質イベント」を製品品質、患者安全、または規制コンプライアンスへの潜在的な影響に基づいて分類します。重大度は、多くの場合、調査の緊急性と必要な深さを決定します。\n\n重大度レベルによる分析は、改善努力の優先順位付けの鍵となります。重大度が高い「イベント」の解決に時間がかかるか、異なる「プロセスパス」をたどるか、または手戻り率が高いかを理解するのに役立ち、最も重要な問題が最大の注意を払われることを確実にします。
その重要性
イベントを影響度別に分類し、リスクベースの分析と高リスク領域におけるプロセス改善活動の優先順位付けを可能にします。
取得元
これは、「品質イベント」オブジェクト上の標準的な分類フィールドであり、多くの場合、リスクマトリックスから導出された選択リストです。
例
高中低
|
|||
|
`サイト`
Site
|
「品質イベント」が発生または特定された製造サイト、工場、または場所。 | ||
|
説明
この「属性」は、「品質イベント」に関連する製造工場や研究所などの物理的な場所を特定します。問題の地理的または組織的なコンテキストを提供します。\n\nこれは比較分析にとって強力な次元であり、経営陣が異なるサイト間で「プロセス」パフォーマンス、問題の種類、および解決時間を比較できます。サイト固有の問題を特定したり、高パフォーマンスの場所からベストプラクティスを共有したりするのに役立ちます。
その重要性
分析のための地理的または組織的な側面を提供し、パフォーマンスの比較やサイト固有の問題特定に役立ちます。
取得元
これはしばしば、「品質イベント」オブジェクト上の標準フィールドであり、会社サイトまたは場所のリストにリンクされています。
例
サイトA - ニュージャージーサイトB - アイルランドサイトC - スイス
|
|||
|
サイクルタイム
CycleTime
|
「品質イベント」の作成から最終クローズまでの経過時間の合計。 | ||
|
説明
この指標は、「品質イベント」を解決するためのエンドツーエンドの期間を表します。最初の「活動」(例:「品質イベント作成済み」)と最後の「活動」(例:「最終レビューとクローズ」)の間の時間差として計算されます。\n\n「サイクルタイム」は、全体的な「プロセス」効率の主要な重要業績評価指標です。「品質イベント解決時間」
その重要性
エンドツーエンドの「プロセス」効率を測定し、全体的なパフォーマンスと改善イニシアティブの影響を追跡するための重要なKPIを提供します。
取得元
これは計算された指標です。ケースレベルで、最初の「イベント」の
例
30日12時間65日4時間15 days 2 hours
|
|||
|
プロダクト
Product
|
「品質イベント」に関連する製品または材料。 | ||
|
説明
この「属性」は、「品質イベント」を特定の製品、材料、またはバッチにリンクします。この関連付けは、規制産業におけるトレーサビリティと影響分析にとって不可欠です。\n\n製品ごとの「品質イベント」分析は、特定の製品が問題を起こしやすいかどうかを特定するのに役立ち、製品の改善や製造「プロセス」の調整を導きます。特定の製品ラインのパフォーマンスを確認するために
その重要性
「品質イベント」を特定の「製品」に紐付け、製品固有の問題やトレンドを特定するための分析を可能にします。
取得元
これは通常、「品質イベント」オブジェクト上の参照フィールドであり、Veeva Vaultの製品または材料オブジェクトにリンクされています。
例
製品A-100製品B-200原材料C-300
|
|||
|
再発か
IsRecurrence
|
この品質イベントが以前に特定された問題の再発であるかどうかを示すフラグです。 | ||
|
説明
このブール型「属性」は、「品質イベント」が新規の独自の問題ではなく、以前に発生した問題の繰り返しであることを示します。これは、以前の「是正処置」の失敗を示す重要な指標です。\n\nこのフラグは、「CAPA有効性および再発率」
その重要性
是正措置の失敗を浮き彫りにし、問題がなぜ繰り返されるのか、長期的な解決策をどのように改善するかを分析できるようにします。
取得元
これは、「品質イベント」オブジェクトのチェックボックスフィールドであるか、以前の類似の「イベント」へのリンクに基づいて導出されたフィールドである可能性があります。
例
truefalse
|
|||
|
手戻り
IsRework
|
手戻りを表す活動やケースを識別する計算済みのフラグです。 | ||
|
説明
この「属性」は、特定の「活動」または一連の「活動」が手戻り(調査の繰り返しやクローズされたCAPAの再開など)を表すブールフラグです。これは標準フィールドではなく、「プロセスフロー」パターンに基づいて計算されます。\n\n「プロセスマイニング」において、このフラグは「プロセス」における無駄な労力とコストの量を定量化するために使用されます。「手戻り分析」
その重要性
繰り返し発生する作業にフラグを立てることで「プロセス」の非効率性を定量化し、品質問題の根本原因や無駄な労力を特定するのに役立ちます。
取得元
この「属性」は直接取得されません。特定のケースの「プロセス」内で繰り返される「活動」名やループを検出することで、「データ変換」中に計算されます。
例
truefalse
|
|||
|
承認時間
ApprovalTime
|
特定の承認「活動」が完了するまでにかかった時間。 | ||
|
説明
この指標は、「是正処置計画承認済み」などの承認ステップの期間を測定します。承認が要求されてから承認または却下されるまでの時間として計算されます。\n\nこの「属性」は、「承認ワークフロー
その重要性
重要な意思決定ステップにおける遅延を特定し、承認ワークフローの合理化と全体のサイクルタイム短縮に役立てます。
取得元
この指標は、「イベントログ」内の承認関連「活動」の開始と終了の間の時間差を見つけることによって計算されます。
例
3日4時間1日0時間7 days 8 hours
|
|||
|
有効性チェック結果
EffectivenessCheckResult
|
「是正処置」が効果的であったかを確認するための検証ステップの結果。 | ||
|
説明
この「属性」は、「是正処置」が実施された後に実行される有効性チェックの結果を記録します。結果は通常、「有効」または「無効」です。\n\nこれはCAPA「プロセス」の成功を直接測定するものであり、「CAPA有効性および再発率」
その重要性
是正措置の成功を直接測定し、問題解決プロセスの改善に不可欠なフィードバックを提供します。
取得元
これは、主要な「品質イベント」に関連するCAPAアクションまたは有効性チェックオブジェクト上のフィールドであり、おそらく選択リストです。
例
有効効果なし検証保留中
|
|||
|
期限内解決
IsOnTimeResolution
|
品質イベントが目標日までにクローズされたかどうかを示す計算済みのフラグです。 | ||
|
説明
このブール型「属性」は、「品質イベント」の実際のクローズ日と「目標解決日」を比較することで導出されます。これは、オンタイムパフォーマンスに関する単純な二進数の結果を提供します。\n\nこのフラグは、「オンタイム解決パフォーマンス」
その重要性
期限達成に関する明確な成功/失敗指標を提供し、パフォーマンス分析とレポーティングを簡素化します。
取得元
「最終レビューとクローズ」活動のタイムスタンプを「TargetResolutionDate」属性と比較して計算されます。数式:クローズ時間 <= TargetResolutionDate。
例
truefalse
|
|||
|
根本原因
RootCause
|
「品質イベント」の特定された根本原因。 | ||
|
説明
この「属性」には、根本原因分析(RCA)調査の最終的な結論が含まれています。設備故障、人的ミス、手順の不備など、「品質問題」の根本的な理由を分類します。\n\n根本原因の分析は、効果的な問題解決に不可欠です。是正処置と予防処置を通じて対処する必要がある、繰り返しのシステム的な問題を特定するのに役立ちます。この「属性」は、「根本原因分析サイクルタイム」と「CAPA有効性」ダッシュボードを直接サポートします。
その重要性
品質問題の根本的な原因を分類し、将来の再発防止のための戦略的分析を可能にします。
取得元
これは通常、「品質イベント」オブジェクトまたは関連する根本原因分析オブジェクトのテキストフィールドまたは選択リストです。
例
設備故障手順エラー不適切なトレーニング材料欠陥
|
|||
品質マネジメント活動
| アクティビティ | 説明 | ||
|---|---|---|---|
|
最終レビューとクローズ
|
「品質イベント」レコードが正式にクローズされる前の最終的な管理レビューを表します。このステップは、すべての文書が完全であり、すべての「プロセス」ステップが実行されたことを確認します。この「活動」は、ケースが解決済みと見なされる前の最終ステップです。 | ||
|
その重要性
この最終「活動」は、総「品質イベントサイクルタイム」を計算するために不可欠です。すべての作業の完了を意味し、その
取得元
Quality Eventオブジェクトのライフサイクルステータスが「クローズ済み」、「解決済み」、または同様の最終ステータスに変更されたことから推測されます。
取得
「クローズ済み」への最終ステータス変更のタイムスタンプから。
イベントタイプ
inferred
|
|||
|
品質イベント作成済み
|
これは、「プロセス」の開始点であり、Veevaにおける「品質イベント」レコードの正式な作成を表します。この「活動」は通常、新しい品質問題、不適合、または苦情が特定され、システムにログとして記録されたときにトリガーされます。 | ||
|
その重要性
この「活動」はケースのライフサイクルの開始を示し、総「品質イベントサイクルタイム」の計算や、調査開始までの時間など、初期「プロセス」フェーズの期間を測定するために不可欠です。
取得元
これは、Veeva Vaultの「品質イベント」オブジェクトの作成
取得
主要な「品質イベント」レコードの作成
イベントタイプ
explicit
|
|||
|
措置の有効性が確認済み
|
この「活動」は、実施された「是正処置」が問題の再発防止に成功したことを確認します。正式な検証が完了し、文書化されます。CAPAまたは「品質イベント」のステータスが「有効性検証済み」に更新されたときに記録されます。 | ||
|
その重要性
これは、解決策の成功の最終検証であり、「CAPA有効性率」を計算するために不可欠です。この段階での失敗は、しばしば手戻りや調査の再開につながります。
取得元
Quality EventまたはCAPAオブジェクトのライフサイクルステータスが「確認済み」または「クローズ済み - 有効」のようなステータスに変更されたことから推測されます。
取得
正常な検証を示すステータス変更のタイムスタンプから。
イベントタイプ
inferred
|
|||
|
是正措置実施済み
|
承認された「是正処置」計画で定義されたすべてのタスクの完了を表します。この「活動」は、根本原因に対処するために必要な処置が取られたことを確認します。CAPAレコードのステータスが「実装完了」に更新されたときに記録されます。 | ||
|
その重要性
これは、計画から実行への移行を示す主要なマイルストーンです。この時点からCAPA承認までの時間は、実装フェーズの効率を明らかにします。
取得元
関連するCAPAオブジェクトのライフサイクルステータスが「実施済み」または「有効性チェック保留中」のようなステータスに変更されたことから推測されます。
取得
リンクされたCAPAオブジェクトのステータス変更のタイムスタンプから。
イベントタイプ
inferred
|
|||
|
是正措置計画承認済み
|
品質レビューボードなどの関係者による、提案された「是正処置」計画の正式な承認を示します。これは、「是正処置」が実施される前の重要なゲートウェイです。CAPA計画レコードが「承認済み」状態に移行したときに記録されます。 | ||
|
その重要性
この承認ステップは、しばしば主要な
取得元
関連するCAPA計画オブジェクトのライフサイクルステータスが「承認済み」に変更されたタイムスタンプから推測されます。このイベントは、親となるQuality Eventのステータス変更として反映される場合があります。
取得
リンクされたCAPA計画オブジェクトのステータス変更のタイムスタンプから。
イベントタイプ
inferred
|
|||
|
根本原因分析の実施
|
根本原因分析(RCA)フェーズの完了を表します。この段階で、「品質イベント」の根本原因が特定されます。これは、調査担当者がRCAタスクを完了したとき、または「イベント」を「CAPA保留中」の状態に移行したときにしばしば記録されます。 | ||
|
その重要性
この「活動」は、「平均根本原因分析時間」KPIを測定するために不可欠です。その期間を分析することで、分析「プロセス」における
取得元
通常、「品質イベント」オブジェクトのライフサイクル状態の変更(「RCA完了」または「アクション計画保留中」への移行など)から推測されます。また、特定のワークフロータスクの完了に対応する場合もあります。
取得
ステータス変更のタイムスタンプ、またはRCA関連タスクの完了から。
イベントタイプ
inferred
|
|||
|
調査開始
|
「品質イベント」の根本原因調査の正式な開始を示します。通常、調査担当者またはチームが割り当てられ、「イベント」は活発な調査フェーズに移行します。これは、「品質イベント」のライフサイクル状態が「調査中」に変わったときに記録されます。 | ||
|
その重要性
これは、「問題特定から調査開始までの時間」KPIを測定するための重要なマイルストーンです。この時点までの遅延は、リソース割り当てや重要な分析の開始における滞留を示します。
取得元
Quality Eventオブジェクトのライフサイクルステータスが「調査中」または同様のステータスに更新されたタイムスタンプから推測されます。調査員の割り当てもトリガーとなることがあります。
取得
状態変更の
イベントタイプ
inferred
|
|||
|
予防処置を特定
|
この「活動」は、多くの場合、調査の結果として、将来の潜在的な再発に対処するための「予防処置」が特定されたときに発生します。「品質イベント」にリンクされた「予防処置」(PA)レコードの作成によって記録されます。 | ||
|
その重要性
全てのケースに該当するわけではありませんが、この活動を追跡することで、品質プロセスがどれほど積極的であるかを理解できます。これにより、組織が長期的な予防と一時的な修正のどちらに重点を置いているかについて、深い洞察が得られます。
取得元
Veeva Vault内のリンクされた予防措置レコードの作成タイムスタンプから推測されます。
取得
リンクされた予防処置レコードの作成
イベントタイプ
inferred
|
|||
|
初期トリアージ完了
|
「品質イベント」の初期レビューと評価の完了を表します。この段階で、イベントの有効性と即時の影響を判断するために基本的な情報が収集され、検証されます。これは、レコードのステータスが「新規」から「評価中」または類似の状態に変わったときにしばしば記録されます。 | ||
|
その重要性
トリアージに費やされた時間を分析することは、品質イベントの初期処理における遅延を特定するのに役立ちます。これにより、プロセスの最初期におけるワークロードとリソース配分に関するインサイトが得られます。
取得元
Quality Eventオブジェクトのライフサイクルステータスが、トリアージが完了したことを反映するように更新されたタイムスタンプから推測されます。例えば、「新規」から「評価中」または「トリアージ済み」に移行する場合があります。
取得
Quality Eventオブジェクトのステータス変更のタイムスタンプから。
イベントタイプ
inferred
|
|||
|
問題分類および優先順位付け済み
|
この「活動」は、「品質イベント」が種類、重大度レベル、優先度によって正式に分類された時点を示します。これは、その後の調査パスとタイムラインを決定する重要なステップです。通常、この分類の完了を示すステータス変更によって記録されます。 | ||
|
その重要性
この「イベント」は、イベントの重大度または種類によって「プロセス」分析をセグメント化するために重要です。優先度の高い問題が優先度の低い問題よりも早く処理されるかを理解し、リソースが効果的に割り当てられることを確実にします。
取得元
Quality Eventオブジェクトのライフサイクルステータスが「分類済み」や「調査保留中」のような状態に移行したことから推測されます。主要な分類フィールドが入力されたタイムスタンプからも推測できます。
取得
「重大度」や「優先度」のようなフィールドのステータス変更または入力から推測されます。
イベントタイプ
inferred
|
|||
|
是正措置計画提案済み
|
この「活動」は、特定された根本原因を是正するための正式な計画が立案され、レビューのために提出されるときに発生します。多くの場合、「品質イベント」にリンクされた関連するCAPA(是正処置および予防処置)レコードの作成を伴います。「イベント」は、CAPAレコードが作成されたとき、または「品質イベント」ステータスが更新されたときに記録されます。 | ||
|
その重要性
このステップを追跡することは、分析から解決策設計への移行にかかる時間を分析するのに役立ちます。これは、RCA完了からCAPA提案までの「根本原因分析サイクルタイム」を理解するための重要な入力です。
取得元
これは、「品質イベント」オブジェクトのライフサイクル状態が「CAPA承認保留中」に変更されたこと、またはリンクされたCAPA計画レコードの作成
取得
リンクされたCAPAレコードの作成
イベントタイプ
inferred
|
|||
|
有効性チェック開始
|
実施された「是正処置」の有効性が監視される期間の開始を示します。これは特定の時点の「イベント」ではなく、検証フェーズの開始です。「品質イベント」またはCAPAレコードが「監視中」または「有効性検証保留中」の状態になったときに記録されます。 | ||
|
その重要性
この「活動」は最終的な検証ループを開始します。有効性チェックフェーズの期間は、解決策の成功を確認するのにかかる時間を理解するために重要です。
取得元
Quality EventまたはCAPAオブジェクトのライフサイクルステータスが「有効性レビュー中」のようなステータスに変更されたことから推測されます。
取得
監視関連のステータスへの変更のタイムスタンプから。
イベントタイプ
inferred
|
|||
|
関係者に解決を通知済み
|
この「活動」は、「品質イベント」の解決を関係者に通知するために送信されるコミュニケーションを表します。これは、最終クローズステップによってトリガーされる自動電子メール通知、または手動でログに記録されたコミュニケーションタスクである可能性があります。 | ||
|
その重要性
タイムリーなコミュニケーションは、関係者の満足度と透明性の鍵です。この「活動」は、「関係者通知遅延時間」KPIを測定し、コミュニケーションの遅延を強調するのに役立ちます。
取得元
これは、Veeva Vaultがログに記録される自動通知を送信する場合、明示的な「イベント」である可能性があります。あるいは、手動の「関係者へ通知」ワークフロータスクの完了から推測することもできます。
取得
システム通知ログ、またはコミュニケーションタスクの完了タイムスタンプから。
イベントタイプ
explicit
|
|||