您的质量管理数据模板
您的质量管理数据模板
- 建议收集的属性
- 需要追踪的关键活动
- MasterControl 提取指南
质量管理属性
| 名称 | 描述 | ||
|---|---|---|---|
|
质量 event
QualityEvent
|
单个质量 event 的唯一标识符,如不合格、偏差或投诉。此 ID 将所有相关的 activities 和文档链接在一起。 | ||
|
描述
Quality Event ID 是整个质量管理流程的首要 case 标识符。它通常是 MasterControl 在启动新质量 event 时生成的字母数字值。 在 Process Mining 中,此属性是重建每个质量问题端到端旅程的基础。通过将所有相关 activities 归组在单个 Quality Event ID 下,分析师可以可视化完整的流程流,衡量从创建到关闭的 cycle times,并识别特定 case 的变异或瓶颈。
为何重要
这是连接所有流程步骤的关键 case 标识符,支持对每个质量问题从启动到解决的完整生命周期进行分析。
获取方式
这是质量 event 记录的主键。具体表名和字段名请参考 MasterControl 文档或系统配置。
示例
QE-2023-00123NC-2023-0456CAPA-2023-0078
|
|||
|
Event 时间
EventTime
|
特定 activity 或 event 发生的精确日期和时间。这作为每个 activity 的开始时间。 | ||
|
描述
此 timestamp 标记了质量流程中特定任务的完成或 event 的发生。它提供了重建每个 case 流程流所需的按时间排序的顺序。 Timestamps 对于所有基于时间的 Process Mining 分析都至关重要。它们用于计算 activities 之间的 cycle times、processing times 和等待时间。这些 data 是构建用于分析解决时间、识别瓶颈以及衡量部门间交接延迟的 dashboards 的基础。
为何重要
此 timestamp 提供了 events 的时间顺序,这对于计算流程时长、识别瓶颈以及理解流程绩效至关重要。
获取方式
这是 MasterControl 质量 event 记录审计追踪或历史日志中的标准字段,用于捕捉每项操作的记录时间。
示例
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:15:00Z
|
|||
|
活动名称
ActivityName
|
在质量 event 生命周期中发生的特定任务或 event 的名称,例如“已启动调查”或“已实施纠正措施”。 | ||
|
描述
Activity Name 描述了质量管理流程中的一个独立步骤或里程碑。这些 activities 随 timestamp 一起记录,构成了每个质量 event 流程流的 event 序列。 分析这些 activities 是 Process Mining 的核心。它支持发现实际流程图、识别常见路径、偏离标准程序的行为以及瓶颈。诸如“根本原因分析已执行”等 activities 的顺序和频率对于关注返工和合规性的 dashboard 而言至关重要。
为何重要
此属性定义了流程中的步骤,支持流程图可视化、偏差检测以及流程流分析。
获取方式
此信息通常记录在与 MasterControl 中每个质量 event 记录关联的审计追踪或历史表中。
示例
质量 event 已创建根本原因分析已执行纠正措施计划已批准措施有效性已验证
|
|||
|
有效性状态
EffectivenessStatus
|
确定已实施的纠正和预防措施是否有效的验证检查结果。 | ||
|
描述
此属性记录有效性验证的结果,这是 CAPA 流程中关键的最后一步。该状态指示所采取的行动是否已成功解决问题并防止其再次发生。 此 data 是“CAPA 有效性监控”dashboard 和“CAPA 有效性率”KPI 的主要输入。分析这一结果有助于组织了解其问题解决工作的成功率,并识别纠正措施失败的领域。
为何重要
衡量已实施措施的成功与否,这对于计算 CAPA 有效率和驱动持续改进至关重要。
获取方式
这是 CAPA 表单“有效性验证”或“关闭”部分中的一个结果字段,该表单通常与 MasterControl 中的质量 event 关联。
示例
有效无效需要监控
|
|||
|
根因类别
RootCauseCategory
|
已识别的质量 event 根本原因分类,例如“人为错误”、“设备故障”或“流程缺陷”。 | ||
|
描述
根本原因分析执行后,发现的结果通常会被分类。该属性存储该分类,为分析问题发生的原因提供结构化数据。 这是战略性质量改进的关键属性。“根本原因分析一致性”仪表板利用此数据将根本原因类别与纠正措施的有效性及返工率关联起来。这有助于确定某些类型的根本原因是否更难解决,或者分析过程本身是否存在不一致。
为何重要
对质量问题的根本原因进行分类,实现有针对性的分析,以防止再次发生并提高纠正措施的有效性。
获取方式
此字段通常是 MasterControl 质量 event 表单中“根本原因分析”或“调查”部分的一部分。
示例
设备故障培训不足材料缺陷未遵循程序
|
|||
|
用户名称
UserName
|
执行该活动的用户或资源的名称。 | ||
|
描述
此属性识别负责执行流程中特定 task 的人员,例如批准纠正措施计划或关闭质量 event。 按用户分析流程有助于理解工作量分布、识别培训需求并发现流程执行中因人而异的差异。它可以用来查看某些特定人员是否与返工或延迟相关联,从而为绩效管理和资源分配提供洞察。
为何重要
将活动归因于特定人员,从而能够分析工作量、绩效以及与资源相关的瓶颈。
获取方式
此信息是 MasterControl 中任何质量 event 审计追踪或历史日志的标准部分,通常被记录为“用户”或“执行者”。
示例
j.does.smithr.williams
|
|||
|
目标解决日期
TargetResolutionDate
|
质量 event 应关闭的计划日期或要求日期。 | ||
|
描述
此属性定义质量 event 的预期完成日期,通常由其类型、严重程度或相关监管要求决定。它作为解决流程的截止日期。 此日期用于衡量准时绩效以及对服务水平协议 (SLA) 的合规性。它对于计算“合规执行率”KPI 以及创建计算得出的“SLA 状态”属性(例如“准时”、“延迟”)至关重要。这有助于分析哪些类型的 events 或部门最容易错过截止日期。
为何重要
设定解决截止日期,从而支持准时率衡量以及 SLA 合规率计算。
获取方式
这很可能是 MasterControl 主质量 event 表单上的一个日期字段,可能是自动计算或手动输入的。
示例
2023-11-302024-01-152023-12-22
|
|||
|
结束时间
EndTime
|
指示 activity 何时完成的 timestamp。对于原子 event,它通常与 StartTime 相同。 | ||
|
描述
EndTime(结束时间)标志着一项活动的完成。对于审计追踪中记录的许多事件,开始和结束时间是相同的,代表事件发生的单一时间点。然而,对于具有可衡量持续时间的活动,该字段可以捕获该信息。 该属性与 StartTime 结合使用,以计算单个活动的流转时间。这对于识别流程中哪些步骤最耗时至关重要,为“质量流程瓶颈识别”仪表板提供支持。
为何重要
能够计算精确的活动持续时间,有助于精准定位质量管理流程中哪些特定任务最耗时。
获取方式
可能存在于 MasterControl 审计追踪或历史日志中。如果不可用,可以将其推导为序列中下一个活动的 StartTime。
示例
2023-10-26T10:05:12Z2023-10-27T15:00:00Z2023-11-05T11:20:30Z
|
|||
|
负责部门
ResponsibleDepartment
|
负责该质量 event 或当前 activity 的部门或职能领域。 | ||
|
描述
此属性指示哪个部门(如“制造”、“质量保证”或“工程”)被分配了质量 event 的所有权,或者正在执行特定 task。 这是分析的一个关键维度,因为它允许过滤和比较不同业务单元的流程绩效。它对于 Handoff Delay Analysis dashboard 至关重要,因为 activities 之间此属性的变化意味着交接。分析这些交接处的时间间隙可以揭示部门之间的沟通或协作问题。
为何重要
有助于识别跨部门瓶颈,并按职能区域分析流程绩效,这对于了解交接延迟至关重要。
获取方式
此信息通常存储在 MasterControl 的主质量 event 表单上,并可能随着 event 在其生命周期中的推进而更新。
示例
质量保证制造业研发法规事务
|
|||
|
质量 event 状态
QualityEventStatus
|
质量 event 在其生命周期中的当前状态,例如“开启”、“调查中”、“待批准”或“已关闭”。 | ||
|
描述
此属性提供了质量 event 在任何给定时间的快照。它通常随着 case 推进到主要里程碑而更新。 在 Process Mining 中,状态可用于过滤开启或关闭的 cases,这对于“质量 event 吞吐量与积压”dashboard 至关重要。分析在每个状态中停留的时间也有助于识别 events 容易停滞的阶段。
为何重要
指示质量事件的当前状态,从而能够分析待办积压、吞吐量以及在生命周期不同阶段所花费的时间。
获取方式
这是 MasterControl 主质量 event 记录上的标准状态字段。
示例
未结进行中等待 CAPA 批准已结案已取消
|
|||
|
质量 event 类型
QualityEventType
|
质量 event 的分类,例如“不合格”、“客户投诉”、“审计发现”或“偏差”。 | ||
|
描述
此属性根据质量 event 的性质对其进行分类。不同类型的 events 可能遵循不同的流程路径,或具有不同的合规要求和目标解决时间。 按质量 event 类型分析流程是理解绩效差异的基础。诸如“质量 event 解决时间分析”之类的 dashboards 依赖此属性来比较不同类别的 cycle times,从而帮助识别哪些类型的问题更复杂或需要更长时间来解决。
为何重要
对质量事件进行分类,以便对不同问题类型的流程流、周期时间和结果进行对比分析。
获取方式
这是 MasterControl 质量 event 启动表单上的主要分类字段。
示例
不合格报告 (NCR)客户投诉内部审计发现项供应商纠正措施请求 (SCAR)
|
|||
|
SLA 状态
SlaStatus
|
指示质量事件是否在目标解决日期内关闭。 | ||
|
描述
此属性通过对比质量 event 的实际关闭日期与其“目标解决日期”得出。状态通常设为“准时”或“延迟”。 这提供了一个清晰、直观的指标来衡量截止日期的完成情况。它是“合规执行率”KPI 的基础,并允许对延迟的 cases 进行轻松过滤和分析。了解导致延迟解决的驱动因素是提高整体流程及时性和实现合规目标的关键。
为何重要
提供了一个简单的指标来衡量 case 是否在截止日期前完成,这对于衡量和提高准时率至关重要。
获取方式
这是在 data 转换过程中通过比较每个 case 的“质量 event 已关闭”activity 的 timestamp 与“TargetResolutionDate”字段计算得出的。
示例
准时逾期存在风险
|
|||
|
交接等待时间
HandoffWaitTime
|
由不同部门或团队执行的两个连续 activities 之间的闲置时间。 | ||
|
描述
此指标计算一个 case 在一个部门完成 task 后到下一个部门开始 task 之前的等待时长。它通过识别“负责部门”发生变化的连续 activities 并测量它们之间的时间差来计算。 这一计算指标是“Handoff Delay Analysis”dashboard 和“平均交接等待时间”KPI 的核心。它将协调或沟通问题导致的等待时间与实际处理时间分离开来,有助于精准定位那些延长整体 cycle time 的特定跨职能瓶颈。
为何重要
隔离并量化部门之间的等待时间,直接揭示流程中的沟通鸿沟和协作瓶颈。
获取方式
这是在 data 转换过程中通过分析每个 case 内连续 activities 的 timestamps 和“ResponsibleDepartment”值计算得出的。
示例
172800259200604800
|
|||
|
关联法规
AssociatedRegulationStandard
|
适用于该质量 event 的特定法规或质量标准,如 ISO 13485 或 21 CFR Part 820。 | ||
|
描述
此属性将质量 event 与特定的外部法规或内部质量标准联系起来。这对于生命科学或制造业等受监管行业的公司尤为重要。 对于“质量流程合规执行”dashboard,此属性至关重要。它允许分析师过滤与特定法规相关的 events,并验证是否遵循了要求的流程步骤。偏差可以被标记为潜在合规风险,使其成为审计和风险管理目的的关键属性。
为何重要
将质量事件与特定的合规要求联系起来,从而能够分析对监管标准和内部政策的遵循情况。
获取方式
这可能是 MasterControl 质量 event 表单上的一个可选项字段,允许用户为 events 标记适用的法规。
示例
ISO 1348521 CFR Part 820ICH Q10SOP-QA-001
|
|||
|
最后数据更新
LastDataUpdate
|
指示最后一次从 MasterControl 提取或刷新 data 的 timestamp。 | ||
|
描述
此属性记录最近一次从源系统提取 data 的日期和时间。它是一个元数据字段,适用于整个数据集而非单个 events。 此信息对于了解所分析 data 的新鲜度至关重要。它向业务用户提供了流程 dashboards 和 KPI 实时程度的透明度,确保决策是基于已知时效的 data 做出的。
为何重要
提供有关 data 新鲜度的关键背景信息,确保用户了解分析的实时程度以及预计下一次 data 刷新的时间。
获取方式
此 timestamp 是在从 MasterControl 进行 data 提取、转换和加载 (ETL) 过程中生成并添加的。
示例
2024-05-20T02:00:00Z2024-05-21T02:00:00Z
|
|||
|
受影响产品
ProductAffected
|
作为质量 event 主体的产品、产品线或组件。 | ||
|
描述
此属性识别与质量问题相关的特定产品或物料。这为理解质量 event 的影响提供了必不可少的背景。 按产品分析流程 data 有助于识别存在重复性质量问题的产品。这可以帮助确定改进工作的优先级、为产品设计变更提供信息,并评估不同生产线或供应商的绩效。
为何重要
提供关键业务背景,支持按产品线分析质量问题,从而识别重复出现的问题和趋势。
获取方式
这通常是质量 event 表单上的一个字段,用户可以在其中指定产品,通常是通过从预定义列表中选择或输入零件编号。
示例
产品 A - 批次 54321组件 XYZAPI-001
|
|||
|
处理时间
ProcessingTime
|
在一项活动上实际投入工作的时间长度。 | ||
|
描述
Processing Time(也称为活动持续时间)是指 activity 从开始到结束所经过的时间。它代表了实际的工作时间,而非步骤之间的等待时间。 这一计算指标是瓶颈分析的基石。通过汇总每个 activity 的 processing times,“Quality Process Bottleneck Identification” dashboard 可以清晰地显示哪些步骤最耗时。这有助于将优化工作集中在耗费时间最多的流程环节。
为何重要
量化每个 task 的实际工作时长,直接凸显最耗时的步骤以及提高效率的关键领域。
获取方式
这是在 data 转换过程中通过从 activity 的 EndTime 中减去 StartTime 计算得出的。这要求两个 timestamps 均可用。
示例
864003600604800
|
|||
|
是否返工
IsRework
|
一个布尔标志,用于指示某个活动或活动序列是否代表返工。 | ||
|
描述
当一个 activity 在同一个 case 中重复出现,或者流程循环回到较早阶段时,此标记会被设为“true”。例如,如果同一个质量 event 发生了两次“根本原因分析已执行”,则第二次出现将被标记为返工。 此属性直接支持“返工与重新调查概览”dashboard 和“根本原因重新调查率”KPI。它简化了返工的量化过程,使过滤和分析流程流低效的 cases 变得更加容易。
为何重要
显式标记正在重复的活动,从而可以轻松量化和分析返工的频率、原因和影响。
获取方式
此标记是在 data 转换期间通过分析每个 case 的 activities 序列来检测重复步骤或流程循环而得出的。
示例
truefalse
|
|||
|
源系统
SourceSystem
|
标识提取数据的系统,在此案例中为 MasterControl。 | ||
|
描述
此属性提供有关 data 来源的背景。对于此流程,它将始终持有一个指示“MasterControl”的值。 虽然它看起来是静态的,但在可能结合来自多个系统的 data 进行更广泛分析的企业环境中,此属性至关重要。它确保了 data 血缘,并有助于隔离特定系统的行为或 data 质量问题。
为何重要
清晰地将数据归因于其源系统(本例中为 MasterControl),这对于数据治理以及整合多个应用程序数据的分析至关重要。
获取方式
这通常是在 data 提取、转换和加载 (ETL) 过程中添加的静态值,用于标记数据集的来源。
示例
MasterControlMasterControl QMS
|
|||
|
站点位置
SiteLocation
|
产生该质量 event 的制造基地、工厂或设施。 | ||
|
描述
此属性指定与质量 event 关联的物理位置或站点。它为问题提供了地理或组织层面的背景。 这是一个有价值的对比分析维度。通过按站点进行过滤或分组,管理层可以比较不同地点的质量管理流程绩效。这可以凸显表现优异且能分享最佳实践的站点,以及可能需要额外支持或流程改进的站点。
为何重要
允许对不同生产基地或设施的绩效进行比较,有助于识别特定地点的特有问或最佳实践。
获取方式
此信息通常在质量 event 启动表单中捕捉,通常以公司站点的下拉列表形式呈现。
示例
Austin, TXDublin, Ireland新加坡工厂A 站点
|
|||
|
纠正措施 ID
CorrectiveActionId
|
与质量 event 关联的纠正措施计划 (CAPA) 的唯一标识符。 | ||
|
描述
此属性在质量 event 与为解决其根本原因而创建的特定纠正措施之间提供直接联系。一个质量 event 可能会链接到一个或多个纠正措施。 拥有此 ID 支持更详细的分析,可以将质量 event data 与来自 CAPA 模块的 data 结合起来。这使得能够针对不同根本原因所采取的行动类型及其后续有效性进行更深入的调查,从而支持 CAPA 有效性监控 dashboard。
为何重要
将质量事件与其特定的纠正措施联系起来,实现对措施有效性和解决策略的更细粒度分析。
获取方式
这通常存储在 MasterControl 质量 event 表单的相关记录或链接对象部分。
示例
CA-2023-0199CA-2023-0204CA-2023-0210
|
|||
|
预防措施 ID
PreventiveActionId
|
与质量 event 关联的预防措施计划 (PAPA) 的唯一标识符。 | ||
|
描述
与纠正措施 ID 类似,此属性将质量 event 链接到创建的所有预防措施。预防措施是旨在防止其他领域出现类似潜在问题的预防性手段。 此 ID 对于“预防措施优化”dashboard 和“预防措施率”KPI 至关重要。它支持跟踪质量 event 促成主动改进的频率,并分析这些预防措施随时间推移产生的影响。
为何重要
将质量事件与主动预防措施联系起来,以便分析组织从问题中学习并防止未来再次发生的能力。
获取方式
这可以在 MasterControl 质量 event 或 CAPA 表单的相关记录部分找到,链接到预防措施对象。
示例
PA-2023-0051PA-2023-0052PA-2023-0053
|
|||
质量管理活动
| 活动 | 描述 | ||
|---|---|---|---|
|
措施有效性已验证
|
标志着验证步骤的完成,即收集并审查证据以确认执行的措施是有效的。通常在完成有效性检查任务(通常带有电子签名)时捕获。 | ||
|
为何重要
此 activity 对于计算 CAPA 有效性率和平均行动验证时间至关重要。它能确认解决方案是否生效,从而防止问题再次发生。
获取方式
这可以是通过电子签名捕捉到的验证步骤明确 event,也可以从 workflow 中“有效性检查”task 的完成情况推断得出。
捕获
从验证步骤的电子签名日志或任务完成时间戳中捕获。
事件类型
explicit
|
|||
|
纠正措施计划已批准
|
表示提议的 CAPA 计划已由相关利益相关者正式审核并批准。这是一个关键里程碑,通常通过 MasterControl 审计追踪中的明确电子签名 event 来捕捉。 | ||
|
为何重要
审批步骤是常见的瓶颈。分析该活动所用的时间有助于识别审批流程中的延迟,并为“交接延迟分析”仪表板提供支持。
获取方式
这是当具有审批权限的用户对 CAPA 计划或相关 workflow 步骤进行电子签名时,在审计追踪中捕捉到的明确 event。
捕获
从与审批工作流步骤关联的电子签名日志中捕获。
事件类型
explicit
|
|||
|
调查已启动
|
标志着调查阶段的正式开始,以确定质量事件的范围和直接影响。通常在事件正式分配给调查员且状态更新为“调查中”时捕获。 | ||
|
为何重要
这是跟踪调查阶段时长的关键里程碑。此处的延迟可能严重影响整体解决时间和合规截止日期。
获取方式
推断自质量事件记录中状态变更为“调查中”等状态。此变更记录在 MasterControl 审计追踪中。
捕获
从事件状态更改为“调查中”的时间戳推断。
事件类型
inferred
|
|||
|
质量 event 已关闭
|
这是最后的 activity,标志着 MasterControl 中质量 event 的成功解决和正式关闭。当记录状态更改为“已关闭”时即可捕捉此 event,并带 timestamp 记录在审计追踪中。 | ||
|
为何重要
此 activity 标志着流程的结束,对于计算整体周期时间和吞吐量至关重要。它确认了质量管理 case 的成功完成。
获取方式
这是从质量 event 记录的最终状态更改为“已关闭”中推断出的明确 event。此状态更改的 timestamp 记录在审计日志中。
捕获
从事件状态更新为“已关闭”的时间戳推断。
事件类型
inferred
|
|||
|
质量 event 已创建
|
这是质量管理流程的起点,即在 MasterControl 中首次记录新的质量 event(如偏差、不合格或投诉)。当用户创建新的质量 event 记录时,通常会明确捕捉到此 activity,并生成带有 timestamp 的审计追踪条目。 | ||
|
为何重要
此 activity 标志着 case 生命周期的开始,对于衡量整体质量 event 周转时间 (Cycle Time) 和分析 event 提交量必不可少。
获取方式
这是记录在质量 event 模块审计追踪表中的明确 event。它对应于质量 event 记录的创建 timestamp。
捕获
在创建新的质量 event 对象时记录在审计追踪中。
事件类型
explicit
|
|||
|
最终审核已执行
|
表示质量保证经理已完成对整个质量 event 记录(包括所有文档和行动)的最终审核。在 case 关闭前,通常通过明确的电子签名 event 来捕捉此环节。 | ||
|
为何重要
这是关闭前的最后一道质量关卡。此阶段的延迟可能导致 events 不必要地保持开启状态,从而影响吞吐量指标。
获取方式
当用户在工作流中为“最终审核”或“QA 批准”步骤应用电子签名时,从审计追踪中显式捕获。
捕获
从最终审批工作流步骤的电子签名日志中捕获。
事件类型
explicit
|
|||
|
初始分类评估完成
|
代表初始评估的完成,包括对质量 event 进行分类、分配严重级别和确定优先级。这通常根据系统中的状态更改推断,例如,当 event 状态从“新建”变为“评估中”或“调查中”时。 | ||
|
为何重要
分析分类评估所用的时间有助于识别质量问题初始响应中的延迟。这是决定后续工作流和资源分配的关键步骤。
获取方式
推断自审计追踪,即当事件的状态字段更新为分类后状态,或当所需的分类字段(如“严重程度”和“优先级”)首次填充并保存时。
捕获
源自事件状态字段的变更,例如从“已提交”更改为“已分配”。
事件类型
inferred
|
|||
|
利益相关者已通知
|
代表将质量 event 的解决结果正式传达给所有相关利益相关者。这可以是一个明确记录的动作,也可以从 workflow 中“最终通知”task 的完成情况推断得出。 | ||
|
为何重要
分析此步骤有助于了解沟通效率。它也是计算“最终审核与关闭时间”KPI 的关键标记。
获取方式
这可以是系统中记录的明确通知 event,也可以从最终关闭前“通知利益相关者”task 的完成情况推断得出。
捕获
从工作流中特定通知任务的完成情况推断。
事件类型
inferred
|
|||
|
有效性被视为无效
|
此 activity 代表验证步骤的负面结果,即发现已实施的行动无效。此 event 会触发返工,并在验证步骤失败时被推断出来,导致状态更改,从而重新开启调查或 CAPA 规划。 | ||
|
为何重要
此 event 对于识别返工循环和计算首检解决率至关重要。它凸显了问题解决流程中需要解决的失败环节。
获取方式
推断自指示验证失败的状态变更,例如“有效性检查失败”或流转回“调查中”。
捕获
源自工作流流转,即在验证后将案例退回到较早的阶段。
事件类型
inferred
|
|||
|
根本原因分析已执行
|
此 activity 表示根本原因分析 (RCA) 的完成以及发现结果的文档化。当“根本原因”或相关分析字段已填写且关联 task 被标记为完成时,可以推断出此 activity。 | ||
|
为何重要
跟踪此 activity 有助于衡量 RCA 阶段的时间和质量。这对于识别返工的 KPI(如根本原因重新调查率)至关重要。
获取方式
推断自审计追踪条目,该条目显示根本原因分析 (RCA) 任务已完成,或质量事件表单中的根本原因类别字段已填充并定稿。
捕获
从“根本原因分析”工作流步骤或任务的完成情况推断。
事件类型
inferred
|
|||
|
纠正措施已执行
|
指示已批准的纠正措施计划中定义的任务已执行并完成。通常在负责该措施的用户将系统中的执行任务标记为“完成”时捕获。 | ||
|
为何重要
这是跟踪“平均行动验证时间”KPI 开始的关键里程碑。实施时长反映了纠正措施的复杂性和效率。
获取方式
推断自审计追踪,即当分配的纠正措施任务的状态更改为“已完成”或“已执行”时。
捕获
源自关联 CAPA 执行任务的完成时间戳。
事件类型
inferred
|
|||
|
纠正措施计划已提议
|
代表创建并提交纠正和预防措施 (CAPA) 计划以供审核。当 CAPA 记录正式关联到质量 event 且其状态设为“待批准”时,通常会捕捉到此 event。 | ||
|
为何重要
此 activity 标志着从调查向解决规划的过渡。RCA 与此步骤之间的时间间隔可以反映规划效率。
获取方式
可能推断自关联 CAPA 对象的创建,或质量事件中状态变更为“CAPA 计划已提议”或“等待计划批准”。
捕获
源自关联 CAPA 计划记录的创建或父级事件的状态变更。
事件类型
inferred
|
|||
|
质量 event 已取消
|
代表一种替代的结束状态,即质量 event 被视为无效、重复或录入错误而被取消。这可以通过状态更改为“已取消”或“无效”来捕捉。 | ||
|
为何重要
区分已关闭和已取消的事件对于准确报告流程结果非常重要。高取消率可能表明事件报告或分类评估过程中存在问题。
获取方式
推断自记录在审计追踪中的终结状态变更,例如“已取消”或“已作废”。
捕获
从事件状态更新为“已取消”的时间戳推断。
事件类型
inferred
|
|||
|
预防措施已执行
|
代表预防措施计划中定义的 task 已完成,旨在防止未来再次发生。当系统中分配的预防措施 task 被标记为完成时,即可捕捉此项。 | ||
|
为何重要
跟踪此 activity 对于“预防措施率”KPI 至关重要,有助于评估组织在应对未来潜在问题方面的主动程度。
获取方式
从 CAPA 计划中专门指定为“预防措施”的任务的完成时间戳推断。
捕获
源自关联预防措施任务的完成时间戳。
事件类型
inferred
|
|||