您的质量管理 data 模板
您的质量管理 data 模板
- 全面采集数据的推荐属性
- 提升流程可见性需跟踪的关键活动
- ETQ Reliance data 提取逐步指南
质量管理属性
| 名称 | 描述 | ||
|---|---|---|---|
|
事件timestamp
EventTimestamp
|
特定 Activity 发生的精确日期和时间。 | ||
|
描述
event timestamp 记录了活动在系统中记录的确切时刻。质量事件生命周期中的每个活动都有自己的 timestamp,从而形成按时间顺序排列的 event 序列。 此属性是 Process Mining 中所有基于时间的分析的基础。它用于计算活动之间的周期时间,识别等待时间和瓶颈,并衡量质量事件的总持续时间。它还能实现随时间变化的性能趋势分析。
为何重要
此属性对于计算持续时间、按时间顺序排列 event 以及执行任何基于时间的分析(如识别瓶颈)至关重要。
获取方式
这通常存在于审计轨迹表中,或者是与 ETQ Reliance 中每个活动或 workflow 步骤关联的“上次修改”或“状态变更”日期字段。
示例
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:15:00Z
|
|||
|
活动名称
ActivityName
|
质量管理流程中发生的特定任务或 event 的名称。 | ||
|
描述
此属性描述了质量事件生命周期中的单个步骤或里程碑,例如“问题已分类并划分优先级”或“已执行根本原因分析”。每个活动代表为推动质量事件解决而采取的独特动作。 分析活动是 Process Mining 的核心。此属性用于构建流程图,展示工作流向。它能识别瓶颈、偏离标准流程的情况以及返工循环,这些对流程改进至关重要。
为何重要
它定义了流程的各个步骤,这对于可视化流程流向、发现瓶颈 (Bottleneck) 和分析偏差必不可少。
获取方式
此类信息通常源自 ETQ Reliance 模块中的事件日志、workflow 状态变更或审计轨迹。
示例
调查已启动已执行根本原因分析纠正措施计划已批准
|
|||
|
质量事件
QualityEvent
|
单个质量事件的唯一标识符,将从识别到关闭的所有相关活动联系起来。 | ||
|
描述
质量事件是质量管理流程的主要 case 标识符。它代表一个单一且独特的质量问题(如不合格、客户投诉或偏差),贯穿调查和解决的全过程。 在 Process Mining 分析中,此属性对于重建每个质量事件的端到端路径至关重要。它允许分析人员可视化流程图、衡量从开始到结束的周期时间,并分析变体以了解不同 event 的处理方式。所有活动和 data 点都按此标识符分组,以提供 case 的全景视图。
为何重要
这是 Process Mining 的基础属性,因为它将所有相关的流程步骤连接成一个单一的 case,从而实现对质量解决生命周期的端到端分析。
获取方式
这是 ETQ Reliance 中主质量事件或不合格模块的主键。请查阅 ETQ Reliance 文档以获取具体的表名和字段名。
示例
QE-2023-00123NC-2023-0456CAPA-2023-7890
|
|||
|
严重性级别
SeverityLevel
|
质量事件影响的分类,例如:严重、重大或轻微。 | ||
|
描述
严重程度是对质量问题对客户、产品或法规合规性潜在影响的评估。它用于分配资源的优先级并确定响应的紧急程度。 此属性对于“问题分类与优先级划分”以及“高严重性事件解决”仪表板至关重要。通过对质量事件进行细分,可以分析高严重性问题的解决速度是否快于低严重性问题,并确保关键问题得到立即关注。
为何重要
它支持案例的优先级排序和细分,以确保最关键的质量问题得到相应的紧急处理。
获取方式
这是 ETQ Reliance 大多数质量管理模块中的标准字段,通常是初始问题录入表单的一部分。
示例
严重重大次要
|
|||
|
事件结束时间
EventEndTime
|
活动完成的日期和时间,用于计算其处理时间。 | ||
|
描述
event 结束时间标志着一项活动的完成。它与 event timestamp(开始时间)配对,定义了单个流程步骤的持续时间。并非所有系统都会显式记录每个 event 的结束时间,在这种情况下,可以从后续 event 的开始时间中推导出来。 此属性对于计算单个活动的处理时间至关重要,处理时间与活动之间的等待时间不同。它有助于识别哪些特定任务耗时较长,从而进行针对性改进以提高流程效率。
为何重要
它支持计算单个活动的执行时间,有助于区分实际工作时间和等待时间。
获取方式
某些 ETQ Reliance 模块可能会记录特定任务的开始和结束时间。如果不可用,可以在 data 准备期间进行派生。
示例
2023-10-26T11:30:00Z2023-10-27T15:00:10Z2023-11-05T10:00:00Z
|
|||
|
操作执行人
ActionPerformedBy
|
执行特定活动的个人或资源。 | ||
|
描述
此属性识别负责完成质量事件生命周期内某项任务的个人或系统用户。它将流程活动与执行它们的个人或团队联系起来。 按用户分析绩效有助于了解工作负载分布、识别培训需求并表彰高绩效个人或团队。对于合规和审计而言,提供谁执行了每项操作的清晰记录也必不可少。
为何重要
此属性可用于分析人员绩效、工作负载平衡并识别培训机会。
获取方式
此类信息通常存储在审计轨迹日志或事务详情中,通常链接到 ETQ Reliance 中的用户 ID 字段。
示例
j.doeasmithqa_manager
|
|||
|
根因类别
RootCauseCategory
|
对已识别的质量事件根本原因的分类。 | ||
|
描述
在执行根本原因分析 (RCA) 后,通常会对问题的底层原因进行分类。例如:“设备故障”、“人为错误”、“流程缺陷”或“供应商问题”。 此属性对于“根本原因类别趋势仪表板 (Dashboard)”至关重要。通过分析不同原因类别随时间变化的频率,企业可以识别系统性问题,并将优化精力集中在最常见的质量问题源头。它有助于从被动解决问题转向主动预防。
为何重要
它支持对重复性问题进行战略分析,有助于识别系统性缺陷,并优先安排长期的纠正和预防措施。
获取方式
这通常是在 ETQ Reliance 工作流的根本原因分析阶段填写的字段。
示例
流程缺陷材料缺陷人为错误设备故障
|
|||
|
责任部门
ResponsibleDepartment
|
负责质量事件或特定活动的部门或职能区域。 | ||
|
描述
此属性指示被分配管理质量事件或执行某些步骤的组织单元,例如“质量保证”、“工程”或“生产”。这可以在 case 级别分配,也可以随着 case 在部门间流转而改变。 此属性是“部门绩效分析”仪表板的关键。它支持对不同部门的流程绩效(如周期时间和 event 量)进行过滤和比较。这有助于识别部门瓶颈、资源限制或卓越领域。
为何重要
它支持跨业务单元的绩效对比和瓶颈 (Bottleneck) 分析,有助于优化资源分配。
获取方式
这通常是 ETQ Reliance 主质量事件表单上的一个字段,指示负责人或负责小组。
示例
质量保证制造业研发
|
|||
|
验证结果
EffectivenessVerificationOutcome
|
检查纠正措施是否有效的结论。 | ||
|
描述
在实施纠正措施后,通常会执行验证步骤以确认该措施是否真正解决了问题。此属性记录验证结果,通常为“有效”或“无效”。 该属性是“纠正措施有效性仪表板 (Dashboard)”和“CAPA 有效性验证率 KPI”的核心。它直接衡量解决流程的成功率,有助于识别重复发生的问题并提升纠正措施计划的质量。
为何重要
这直接衡量纠正措施的成功与否,有助于减少返工并防止质量问题再次发生。
获取方式
这将是 ETQ Reliance 中 CAPA 或质量事件模块有效性验证部分的一个字段。
示例
有效无效挂起
|
|||
|
CAP 状态
CorrectiveActionPlanStatus
|
纠正措施计划的状态,例如已提议、已批准或已驳回。 | ||
|
描述
此属性追踪纠正措施计划 (CAP) 本身的状态,这是整个质量事件中的关键里程碑。它展示了提议的解决方案是否已被审查和接受。 分析此属性可以揭示审批流程中的瓶颈。大量被驳回的计划或“已提议”与“已批准”状态之间的长期延迟可能表明根本原因分析的质量有问题,或利益相关者之间存在分歧。
为何重要
它有助于识别纠正措施审批周期中的延迟和低效,这是质量管理中常见的瓶颈 (Bottleneck)。
获取方式
这将是 ETQ Reliance 的纠正和预防措施 (CAPA) 部分或模块中的一个状态字段。
示例
建议中已批准已驳回待实施
|
|||
|
RCA 时长
RootCauseAnalysisDuration
|
从调查开始到根本原因分析完成所花费的时间。 | ||
|
描述
此指标衡量质量流程中特定阶段的持续时间。它是通过计算“调查已启动”活动与“已执行根本原因分析”活动之间的时间差得出的。 此属性对于“平均根本原因分析时间”KPI 和“根本原因分析瓶颈”仪表板至关重要。它有助于精准定位流程分析阶段的延迟,该阶段通常是导致总周期时间过长的主要原因。
为何重要
它能隔离关键子流程的绩效,有助于识别并解决问题分析和调查中的延迟。
获取方式
源系统中没有此属性。它是在 data 转换期间通过查找特定活动 timestamp 之间的时间差计算得出的。
示例
8640001209600432000
|
|||
|
SLA 状态
SLAState
|
指示质量事件是否处于定义的放服务水平协议 (SLA) 范围内、存在违约风险或已经违约。 | ||
|
描述
此属性是一个计算字段,用于将质量事件的当前或总周期时间与预定义目标进行比较。例如,关键问题可能要求在 15 天内解决。状态可能是“正常”、“有风险”或“已逾期”。 这对于“质量合规概览”仪表板非常有价值,因为它提供了及时性和合规性的直观指示。它能帮助管理人员主动处理有逾期风险的 event,而不是在违规发生后才做出反应。
为何重要
它提供了针对及时性目标的清晰绩效概览,使管理者能够主动应对存在延迟风险的案例。
获取方式
此属性在 data 转换期间计算,通过根据严重程度等属性将 case 的已用时间与 SLA 业务规则进行对比得出。
示例
正常推进存在风险已超期
|
|||
|
业务单元
BusinessUnit
|
质量事件起源的较大利益部门或业务单元。 | ||
|
描述
此属性将质量事件分配给组织内的特定业务单元,例如“消费电子”或“医疗器械”。它比部门提供了更高层级的组织上下文。 通过此属性,可以对不同业务部门的绩效进行高层级比较。它能帮助高级领导层了解哪些业务单元面临最严峻的质量挑战,并据此分配资源。
为何重要
它支持对公司不同部门的质量流程绩效进行高层级对比。
获取方式
此类信息可能是质量事件表单上的一个字段,或者是根据责任部门或产品等其他属性派生出来的。
示例
医疗器械汽车零部件工业解决方案
|
|||
|
最后数据更新
LastDataUpdate
|
指示流程 data 上次刷新的 timestamp。 | ||
|
描述
此属性记录从源系统进行最近一次 data 提取的日期和时间。这是一个元数据字段,适用于整个数据集,而非单个 event。 在任何流程分析中,了解 data 的实时性至关重要。此属性可帮助用户了解分析的时效性,确保决策基于最新信息,并管理对 data 延迟的预期。
为何重要
它指示了数据的时效性,这对于理解分析结果和洞察的及时性至关重要。
获取方式
此值在 data 提取、转换和加载 (ETL) 过程中生成,记录任务运行的 timestamp。
示例
2024-05-20T08:00:00Z
|
|||
|
受影响产品
AffectedProduct
|
作为质量事件主题的产品、材料或组件。 | ||
|
描述
此属性识别与质量问题相关的特定产品或零件号。它将流程 data 与产品主数据联系起来。 按产品分析质量事件,可让企业识别某些产品是否具有较高的质量问题发生率,从而指向潜在的设计或制造问题。它有助于将改进精力集中在最需要的产品上。
为何重要
它将质量流程与特定产品联系起来,支持分析哪些产品最容易出现问题。
获取方式
这通常是质量事件表单上的关键字段,通常链接到 ETQ Reliance 内部或集成 ERP 系统中的产品主 data 表。
示例
PROD-1001-APROD-2050-BRAW-MAT-55
|
|||
|
是否返工
IsRework
|
用于标记某个活动或一系列活动是否代表返工的标识。 | ||
|
描述
此布尔属性是派生出来的,用于识别流程循环何时发生。例如,当有效性验证失败并触发新调查时,或者当纠正措施计划被驳回并退回修订时。它标记了重复之前步骤的活动。 此属性用于计算“纠正措施返工率”KPI。突出显示返工对于了解流程低效至关重要,因为返工会消耗资源并延长周期时间,而不会推动 case 向解决方向发展。
为何重要
它通过标记重复劳动来量化流程低效情况,有助于识别流程失败的根本原因并减少浪费。
获取方式
源系统中没有此属性。它是在 data 转换期间根据 case 内的活动序列计算得出的。
示例
truefalse
|
|||
|
源系统
SourceSystem
|
数据提取来源系统。 | ||
|
描述
此属性识别质量管理 data 的来源。对于此流程视图,该值是恒定的,表明 data 来自 ETQ Reliance。 虽然在单个数据集中它可能不会变化,但此属性对于 data 治理以及合并多个系统 data 的场景至关重要。它能确保 data 来源清晰,有助于管理 data 集成工作。
为何重要
它提供了关于数据来源的基础背景,这对于数据治理、验证以及与其他系统的集成非常重要。
获取方式
这通常是在 data 提取、转换和加载 (ETL) 过程中添加的静态值,用于标记 data 来源。
示例
ETQ Reliance
|
|||
|
相关法规
AssociatedRegulationStandard
|
与质量事件相关的特定法规或质量标准。 | ||
|
描述
此属性将质量事件链接到特定的监管要求或行业标准,如 ISO 9001、FDA 21 CFR Part 820 或内部公司政策。这在受监管行业尤为重要。 这是“质量合规概览”仪表板的关键属性。按相关标准分析 event 有助于监控合规情况,识别偏差频发的领域,并确保所有监管要求得到及时满足。
为何重要
它支持在合规背景下分析质量事件,有助于确保符合特定的行业法规和标准。
获取方式
这可能是 ETQ Reliance 质量事件表单上的专用字段或可选列表,尤其是在注重合规性的模块中。
示例
ISO 9001:201521 CFR Part 820IATF 16949
|
|||
|
质量事件周期时间
QualityEventCycleTime
|
从识别质量问题到最终结案所经过的总时间。 | ||
|
描述
这是一个计算指标,代表单个质量事件的端到端持续时间。它是通过计算第一个活动(如“已识别质量问题”)与最后一个活动(如“质量事件已关闭”)的 timestamp 差值得到的。 此属性直接支持“平均质量事件周期时间”KPI,是衡量流程整体效率的主要指标。它用于仪表板中追踪周期时间缩短目标的完成情况,并比较不同类别 event 的持续时间。
为何重要
这是一项关键绩效指标,用于衡量质量管理流程从头到尾的整体效率。
获取方式
此属性在 ETQ Reliance 中不直接可用。它是在 Process Mining 工具中或在 ETL 过程中通过计算每个 case 最后一个 event timestamp 与第一个 event timestamp 的差值得到的。
示例
25920006048008640000
|
|||
|
质量事件状态
QualityEventStatus
|
质量事件当前的总体状态,例如开启、关闭或取消。 | ||
|
描述
此属性提供了质量事件在其生命周期中所处位置的高层级摘要。它指示 case 是在活跃处理中、已成功解决,还是因某种原因被取消。 在流程分析中,这用于过滤活跃 case 与已完成 case。它是计算未结质量事件积压量以及确保分析(如周期时间)仅在已达到确定终态的 case 上运行的基础。
为何重要
它允许在进行中和已关闭案例之间进行过滤,这对于计算积压工作和准确分析已完成的流程流向至关重要。
获取方式
这是 ETQ Reliance 中主质量事件对象上的一个主要状态字段。
示例
未结已结案已取消待审批
|
|||
|
问题描述
IssueDescription
|
对已识别质量问题的自由文本描述。 | ||
|
描述
此属性包含对质量问题的详细叙述性说明。它提供了结构化 data 字段无法捕获的定性上下文。 虽然在流程流可视化中不常直接使用,但问题描述对于详细的 case 复盘极具价值。它还可以配合文本挖掘技术,识别与特定类型的流程偏差或延迟相关的共同主题或关键词。
为何重要
它为理解质量事件的具体细节提供了关键的定性背景,有助于对单个案例进行深入分析。
获取方式
这是 ETQ Reliance 初始质量事件报告表单上的标准文本框或备注字段。
示例
组件 XYZ 在 4 号站压力测试失败。客户报告 789 批次存在外观缺陷。在 A 机上发现错误的校准设置。
|
|||
|
预防措施 ID
PreventiveActionId
|
针对该质量事件所创建的任何预防措施的唯一标识符。 | ||
|
描述
此属性将质量事件链接到为解决根本原因并防止在其他领域再次发生而创建的一个或多个预防措施。单个质量事件可能会产生多个预防措施。 此 ID 对于“预防措施管理”仪表板非常重要。它有助于追踪已识别预防措施的实施率,并可用于识别重复或多余的工作,确保主动改进措施得到高效管理。
为何重要
它将反应式的质量事件与主动的优化举措联系起来,从而分析企业在预防未来问题方面的成效。
获取方式
这将是 ETQ Reliance 中 CAPA 模块预防措施部分的一个相关记录或字段。
示例
PA-2023-0088PA-2023-0089PA-2023-0090
|
|||
质量管理活动
| 活动 | 描述 | ||
|---|---|---|---|
|
已执行根本原因分析
|
表示调查结束,已识别并记录根本原因。当完成并保存 RCA 表单部分时,系统通常会捕获此 event。 | ||
|
为何重要
标记调查阶段的结束。从“调查启动”到此活动之间的时长是识别分析流程中瓶颈 (Bottleneck) 的关键指标。
获取方式
推断自“根本原因类别”字段的填充日期,或者是审计追踪中 RCA 工作流 (Workflow) 步骤的完成时间戳。
捕获
推断自“根本原因”字段的填充,或变更为“RCA 已完成”的状态。
事件类型
inferred
|
|||
|
措施有效性已验证
|
此活动确认所实施的纠正措施已成功解决根本原因并防止再次发生。这是一个正式的验证步骤,通常在设定的监测期后进行。 | ||
|
为何重要
这是完成质量闭环的关键步骤,与 CAPA 有效性 KPI 直接相关。它确保解决方案是永久且有效的。
获取方式
从“有效性验证”工作流 (Workflow) 步骤或表单部分的完成日期获取。这通常是一个带有时间戳的独立活动。
捕获
源自“有效性检查”表单或任务的完成日期。
事件类型
inferred
|
|||
|
纠正措施已实施
|
表示完成了批准的纠正措施计划中概述的任务。通常在执行人员将分配的操作项标记为完成时记录。 | ||
|
为何重要
衡量实施阶段的时长,这可以揭示资源限制或执行纠正措施时的实际困难。
获取方式
推断自最后一个相关纠正措施任务的完成日期,或者是手动变更为“措施已实施”的状态。
捕获
推断自最后一个相关 CAPA 任务的完成日期。
事件类型
inferred
|
|||
|
纠正措施计划已批准
|
标记提议的纠正措施计划已获得指定权限部门的正式批准,允许开始实施。这通常是工作流 (Workflow) 中一个带有时间戳的明确审批操作。 | ||
|
为何重要
这是一个重大的里程碑,也是一个关键的审批关口。此阶段的延迟会显著延长整体解决周期时间。
获取方式
从事件的电子签名或工作流 (Workflow) 历史日志中的审批时间戳获取。ETQ Reliance 广泛使用审批工作流。
捕获
源自工作流历史记录中审批步骤的时间戳。
事件类型
explicit
|
|||
|
调查已启动
|
标志着为确定质量问题根本原因而进行的调查阶段正式开始。通常由状态变更为“调查中”或分配调查人员来判定。 | ||
|
为何重要
此活动是启动根本原因分析计时的一个关键里程碑。它有助于识别问题评估与正式调查开始之间的延迟。
获取方式
推断自事件历史日志中与状态变更为“调查”相关的时间戳,或者是首席调查员角色的分派日期。
捕获
推断自变更为“调查中”的状态。
事件类型
inferred
|
|||
|
质量事件已关闭
|
最后的活动,标志着质量事件记录的成功解决和行政结案。这是流程的主要终点。 | ||
|
为何重要
定义了计算整体周期时间 (Cycle Time) 的流程终点。分析已关闭事件对于衡量吞吐量和整体绩效至关重要。
获取方式
推断自事件历史日志中变更为“已关闭”或“已完成”的状态,此类变更几乎总是带有时间戳。
捕获
推断自状态变更为“已关闭”的时间戳。
事件类型
inferred
|
|||
|
质量问题已识别
|
标记新质量事件记录的创建,这是流程的起点。通常在用户在 ETQ Reliance 中提交新的质量问题表单时捕获。 | ||
|
为何重要
确立案例开始时间,这对于计算端到端周期时间 (Cycle Time) 以及分析新质量事件的到达率至关重要。
获取方式
通常派生自源质量事件表中的质量事件记录创建 timestamp,或其相关的审计轨迹。
捕获
源自质量事件记录的创建时间戳。
事件类型
explicit
|
|||
|
最终复核已执行
|
在关闭前对整个质量事件记录进行最终检查,以确保所有文档完整且已遵循所有程序步骤。这通常是一个明确的审批步骤。 | ||
|
为何重要
这代表流程结束前的最后一道质量关卡,确保合规性和 data 完整性。此处的瓶颈会拖慢最终结案的速度。
获取方式
从工作流 (Workflow) 历史日志中“最终复核”或“准备关闭”审批步骤的时间戳获取。
捕获
源自工作流 (Workflow) 中“最终复核”审批步骤的时间戳。
事件类型
explicit
|
|||
|
初始评估已执行
|
表示对新发现的质量问题进行初步审查或分类,以收集基本事实并确定其有效性。通常通过填写初始评估表单或状态从“新建”转为“评估中”来判定。 | ||
|
为何重要
有助于分析初始分诊流程的效率,并衡量问题从上报到进入主动评估阶段所需的时间。
获取方式
推断自状态变更(例如:从“新建”到“评估中”)或事件工作流 (Workflow) 日志中初始评估任务的完成日期。
捕获
推断自变更为“评估中”或“分诊中”的状态。
事件类型
inferred
|
|||
|
已通知利益相关者
|
指正式向相关利益相关者传达质量事件解决情况的行为。这通常通过专门的 workflow 步骤或记录的沟通记录进行追踪。 | ||
|
为何重要
对于衡量沟通效率至关重要,并为“利益相关者通知及时性仪表板 (Dashboard)”提供支持。此处的延迟可能会影响客户满意度。
获取方式
需要系统分析,因为这通常是一个手动步骤。如果配置了“通知利益相关者”任务,则可以从该任务的完成情况中判定。
捕获
推断自手动“通知利益相关者”任务的完成日期。
事件类型
inferred
|
|||
|
有效性验证失败
|
表示所实施的纠正措施未能解决问题,通常会触发新的调查或 CAPA 周期。此事件标志着重大的流程失败和返工循环。 | ||
|
为何重要
突出显示失败的解决方案,这些方案直接影响返工率和成本。分析这些实例是改进根本原因分析 (RCA) 和 CAPA 规划流程的关键。
获取方式
推断自状态变更为“有效性检查失败”,或创建了链接到原始事件的后续质量事件。
捕获
推断自“验证失败”等状态变更,或验证记录中的标识。
事件类型
inferred
|
|||
|
纠正措施计划已拒绝
|
表示提议的纠正措施计划已被审查并拒绝,需要修改后重新提交。此活动在流程中产生了一个返工循环。 | ||
|
为何重要
此活动对于识别返工循环、了解驳回原因以及衡量计划流程的首检合格率至关重要。
获取方式
从工作流 (Workflow) 历史日志中的拒绝时间戳获取。这是工作流中审批操作的对应项。
捕获
源自工作流历史记录中拒绝步骤的时间戳。
事件类型
explicit
|
|||
|
纠正措施计划已提议
|
当正式的根本原因处理计划被记录并提交审批时发生此活动。通常在填写表单的“纠正措施计划”部分且状态推进时捕获。 | ||
|
为何重要
分析从 RCA 完成到此步骤所需的时间,有助于发现纠正措施规划中的延误,这是质量流程中常见的瓶颈 (Bottleneck)。
获取方式
推断自状态变更为“待 CAPA 审批”,或质量事件记录中纠正措施计划表单的提交时间戳。
捕获
推断自变更为“待审批”的状态,或 CAPA 计划的提交日期。
事件类型
inferred
|
|||
|
质量事件已取消
|
流程的一个备选终点,表示质量事件未完全解决即终止,原因可能是重复录入或无效条目。 | ||
|
为何重要
有助于区分成功解决的案例与提前终止的案例。分析取消情况可以揭示初始报告和分诊阶段存在的问题。
获取方式
推断自事件历史日志中变更为“已取消”、“作废”或“撤回”的状态。
捕获
推断自状态变更为“已取消”的时间戳。
事件类型
inferred
|
|||
|
问题已分类并排序
|
标记问题已按类型、严重程度和优先级完成分类的时间点,这通常决定了后续的工作流 (Workflow) 走向。该活动在分类和优先级字段被填充且记录保存时捕获。 | ||
|
为何重要
这是一个关键的决策点。分析到达这一步的时间对于“问题分类与优先级划分”仪表板以及了解流程路由至关重要。
获取方式
推断自系统审计追踪中所记录的“严重程度”和“质量事件类型”等必填字段首次填充的时间戳。
捕获
推断自“严重程度”或“优先级”字段首次填充的时间戳。
事件类型
inferred
|
|||
|
预防措施已实施
|
标记与已识别预防措施相关的任务已完成,表示主动性手段已经落实到位。 | ||
|
为何重要
此活动是衡量“预防措施实施率”KPI 的关键,确保预防性的质量改进措施得到真正执行。
获取方式
需要系统分析。通常由关联的预防措施记录或其相关任务的完成日期判定。
捕获
源自关联预防措施记录的完成日期。
事件类型
inferred
|
|||
|
预防措施已识别
|
表示识别出旨在消除潜在不符合项原因的预防措施 (PA)。这可以作为与原始质量事件关联的独立记录进行管理。 | ||
|
为何重要
对于分析企业在质量管理中的主动性至关重要,通过追踪预防措施的启动时间,为“预防措施管理仪表板 (Dashboard)”提供支持。
获取方式
需要系统分析。通常派生自链接回源质量事件记录的预防措施记录的创建日期。
捕获
源自关联预防措施记录的创建日期。
事件类型
inferred
|
|||