您的质量管理数据模板
您的质量管理数据模板
- 用于全面分析的建议属性
- 需跟踪的关键质量管理活动
- 从 SAP S/4HANA 质量管理中提取 data 的指南
质量管理属性
| 名称 | 描述 | ||
|---|---|---|---|
|
开始时间
EventTimestamp
|
特定活动或事件发生的准确日期和时间。 | ||
|
描述
“开始时间”(即 Event 时间戳)记录了活动发生的精确时刻。这对于按时间顺序排列 Event 以及计算 Event 之间的时长至关重要。例如,它记录了通知创建、Task 完成或状态更改的时间。 在流程挖掘分析中,该属性是计算所有基于时间的指标(如周期时间、处理时间和等待时间)的基础。它能够识别瓶颈、分析吞吐量,并根据有时限要求的 SLA 或目标监控绩效。准确的时间戳对整个流程模型的完整性至关重要。
为何重要
timestamp 对于事件排序、计算各项绩效指标(如周期时间和等待时间)以及理解流程动态至关重要。
获取方式
通常源自与状态更改或凭证创建相关的日期和时间字段。例如 QMEL 中的 ERDAT/ERZEIT(创建日期/时间)或 CDHDR 中的更改 timestamp。
示例
2023-04-15T09:00:12Z2023-04-18T14:35:00Z2023-05-01T11:21:45Z
|
|||
|
活动
ActivityName
|
质量管理流程中发生的特定业务 Event 或 Task 的名称。 | ||
|
描述
此属性描述了质量事件生命周期中的单个步骤或里程碑,例如“已创建通知”、“已完成根本原因分析”或“已做出使用决策”。这些活动源自系统状态的更改、相关文档的创建或更改日志中记录的特定用户操作。 分析这些活动的顺序和时间是流程挖掘的核心。它能够发现实际的流程流、识别步骤之间的瓶颈,并衡量对标准操作程序的符合性。活动的粒度决定了流程分析的详细程度。
为何重要
此属性定义了流程的步骤,从而可以可视化和分析流程流、识别偏差并衡量活动之间的绩效。
获取方式
派生自表 JEST 和 JSTO 中的状态更改,或派生自 QMSM(任务)等表中的活动记录。事件日志也可以根据变更文档表 CDHDR 和 CDPOS 构建。
示例
已创建质量通知调查任务已分配纠正措施已实施通知已关闭
|
|||
|
质量事件
QualityEvent
|
质量通知的唯一标识符,作为跟踪质量问题从发起、到关闭的主要 Case ID。 | ||
|
描述
“质量事件”是连接与单个质量问题相关的所有活动、Task 和决策的中心案例标识符。在 SAP 中,这通常对应于质量通知编号 (QMNUM)。 在流程挖掘中,按此标识符分析 Event 可以重构每个质量案例的端到端旅程。这对于可视化流程流、计算整个案例的周期时间以及识别解决过程中的常见路径或偏离路径至关重要。它是几乎所有质量管理分析的核心。
为何重要
它是将所有相关活动链接到单个、内聚的流程实例中的关键,能够对质量问题的处理方式进行端到端分析。
获取方式
这是质量通知单编号,位于 QMEL 表的 QMNUM 字段。
示例
200000018200000019200000020
|
|||
|
产品
MaterialNumber
|
受质量事件影响的产品或物料的唯一标识符。 | ||
|
描述
此属性将质量事件与特定产品或物料联系起来。这种连接对于质量保证至关重要,因为它有助于识别具有重复性问题或高缺陷率的产品。 在流程挖掘中,按产品分析能够检测模式,例如某些产品是否具有更长的解决时间或与特定的根本原因相关联。通过将产品与质量问题相关联,它为“重复性问题模式检测”仪表板提供支持,这对于有针对性的质量改进计划至关重要。
为何重要
将质量问题与特定产品关联起来,从而分析特定产品的缺陷率、根本原因和解决模式。
获取方式
在质量通知项目表 QMFE 的 MATNR 字段中找到。
示例
FIN-1001RAW-205ASEMI-303B
|
|||
|
优先级
NotificationPriority
|
分配给质量通知的优先级,指示其紧急程度。 | ||
|
描述
优先级定义了处理质量事件的紧迫性。它帮助团队组织工作,并确保最关键的问题得到优先处理。SAP 允许配置不同的优先级类型,这会影响目标响应时间。 此属性用于分析高优先级事项是否确实比低优先级事项处理得更快。它可以揭示高优先级案例在流程中卡住的低效环节。它是“质量事件吞吐量分析”等仪表板的关键维度。
为何重要
有助于分析流程性能是否与业务紧急程度保持一致,确保高优先级问题能得到更快解决。
获取方式
位于 QMEL 表,字段为 QMPRI。描述信息在 TQ05 表中。
示例
1234
|
|||
|
根因
RootCauseCode
|
用于识别已确定的质量问题根本原因的代码或文本。 | ||
|
描述
“根本原因”属性捕获了质量缺陷或不合格的深层原因。识别正确的根本原因质量管理流程中的关键步骤,因为它是定义有效的纠正和预防措施的基础。 此属性对于“根本原因分析周期时间”和“重复性问题模式检测”仪表板至关重要。按根本原因分析有助于识别系统性问题。例如,通过在流程图中过滤特定的根本原因,可以查看它是否导致了独特的流程路径或更长的解决时间。
为何重要
通过将根本原因与产品、部门和流程效率低下相关联,支持对系统性问题的分析,从而指导预防性措施的制定。
获取方式
通常存储在 QMUR 表(通知原因)的 URCOD 字段中。
示例
OPERATOR_ERRORDEFECTIVE_MATERIALMACHINE_MALFUNCTION
|
|||
|
用户
ChangedBy
|
执行活动或进行最后更改的用户的 ID。 | ||
|
描述
此属性识别负责执行特定流程步骤的具体用户。在 SAP 中,这通常对应于“更改者”(AENAM) 或“创建者”(ERNAM) 字段。 按用户分析有助于了解工作负载分布、识别培训需求并查明特定用户的流程偏差。它是基于资源的分析的基础,例如调查某些用户处理时间较长或倾向于遵循非标准路径的原因。
为何重要
它能够分析人员绩效、工作负载分布以及对标准程序的遵守情况,这是优化资源分配的关键。
获取方式
可在抬头表和项目表中找到,如 QMEL-ERNAM(创建人),或派生自变更日志 (CDHDR-USERNAME)。
示例
SMITHJWILSONAPROCESS_AUTOMATION_BOT
|
|||
|
目标解决日期
TargetResolutionDate
|
质量事件计划或要求的完成日期。 | ||
|
描述
该日期代表预期质量事件得到完全解决并关闭的截止日期。它经常被用作衡量绩效和遵守服务水平协议 (SLA) 的基准。 该属性是计算按时完成率和识别逾期案例的基础。“质量事件按时完成”仪表板和“质量措施按时率”KPI 直接依赖于实际完成日期与此目标日期的对比。它有助于优先处理工作并有效管理资源。
为何重要
为衡量按时完成绩效提供基准,这是评估流程效率和对 SLA 遵守情况的关键 KPI。
获取方式
可在 QMEL-QMDAT(要求完成日期)或任务级别的 QMSM-PSTER 中找到。
示例
2023-05-302023-06-152023-07-01
|
|||
|
负责部门
ResponsibleDepartment
|
负责执行特定 Task 或管理质量事件的部门或职能区域。 | ||
|
描述
此属性指示分配给活动或整个质量事件的组织单位。这可能是一个质量保证团队、一个工程部门或一个生产单位。 这是分析跨部门协作和交接的关键维度。它有助于识别责任从一个部门转移到另一个部门时发生的延迟,为“跨部门交接延迟”仪表板提供支持。它还允许过滤流程视图以了解特定部门的运作方式。
为何重要
对于分析跨部门移交、识别组织瓶颈以及了解不同团队如何为流程做出贡献至关重要。
获取方式
通常源自与通知或 Task 相关的伙伴功能,或者源自 HR 主数据中用户的组织分配。它可能不是一个直接字段。
示例
质量保证3 号生产线供应商质量工程
|
|||
|
质量通知类型
QualityNotificationType
|
质量通知的分类,例如客户投诉、内部问题或供应商缺陷。 | ||
|
描述
此属性根据质量事件的来源和性质对其进行分类。标准的 SAP 类型包括客户投诉、内部问题报告和供应商相关的缺陷。此分类决定了后续的流程流转和所需的文档。 按通知类型分析流程对于理解不同类型的问题是否以不同方式处理或具有不同的效率水平至关重要。通过允许对不同问题类别进行过滤以及对比其周期时间和流程路径,它为“质量事件吞吐量分析”等仪表板提供支持。
为何重要
它支持对流程进行细分,以观察不同类型的质量问题是否遵循不同的路径,或表现出不同的性能特征。
获取方式
位于 QMEL 表,字段为 QMART。
示例
Q1Q2F2
|
|||
|
最后数据更新
LastDataUpdate
|
指示此 record 数据上次从源系统刷新的 timestamp。 | ||
|
描述
此属性提供了从源系统进行最后一次数据提取或更新的时间戳。它告知用户所分析数据的实时性。 在任何分析仪表板或报告中,显示此信息都是管理用户对数据时效性预期的关键。它有助于区分最近的流程变更与陈旧数据的残留。
为何重要
告知用户 data 的新鲜度,这对于基于 Process Mining 分析做出及时、准确的决策至关重要。
获取方式
这是一个元数据字段,由数据提取工具或流水线在数据刷新时生成并填充。
示例
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
客户
CustomerNumber
|
与质量事件相关的客户标识(如果适用)。 | ||
|
描述
此属性将质量事件与特定客户联系起来。这对于“客户投诉”等通知类型最为相关。跟踪此类信息对于客户关系管理以及了解质量问题对客户的影响至关重要。 按客户分析使企业能够识别某些客户是否比其他客户经历更多质量问题,或者解决时间是否因客户而异。通过在影响分析中加入客户维度,它为“按严重程度和影响分类的质量事件”仪表板提供支持。
为何重要
将质量 event 与客户关联,支持对特定客户问题的分析,并确保高价值客户获得优先支持。
获取方式
通常位于通知单的合作伙伴职能中。如果是来自销售订单的投诉,也可能位于 QMEL-KUNUM 中。
示例
CUST-10045CUST-20399CUST-80110
|
|||
|
工厂
Plant
|
质量事件发生或被管理的制造工厂或地点。 | ||
|
描述
“工厂”属性指定了与质量事件相关的物理位置,例如工厂或仓库。它为质量问题发生的地点提供了地理或组织背景。 这是一个用于对比分析的强大维度。通过按工厂进行过滤或分组,管理层可以比较不同地点的绩效,识别特定站点的问题,并分享高效工厂的最佳实践。它有助于回答诸如“哪个工厂的根本原因分析周期最长?”之类的问题。
为何重要
允许对不同运营地点的性能进行比较,有助于识别特定站点的具体问题和最佳实践。
获取方式
与通知抬头相关的工厂位于 QMEL-WERKS 中。如果与特定物料相关,也可以在项目级别找到。
示例
100017102000
|
|||
|
按时完成
IsOnTimeCompletion
|
一个布尔标志,指示质量 event 是否在目标解决日期前完成。 | ||
|
描述
此计算标志将质量事件的实际完成时间戳与其“目标解决日期”进行比较。如果事件在目标日期或之前关闭,则为 true,否则为 false。 此属性为绩效监控提供了一种简单、直接的方法,是“质量事件按时完成”仪表板和“质量措施按时率”KPI 的基础。它允许轻松进行过滤和汇总,以了解不同维度(如部门、产品或通知类型)的按时表现。
为何重要
为根据截止日期进行的绩效跟踪提供清晰的二进制结果,使其易于衡量和报告 SLA 合规性。
获取方式
通过比较最终关闭活动的 timestamp 与“TargetResolutionDate”属性得出的计算属性。
示例
truefalse
|
|||
|
措施有效性
EffectivenessEvaluation
|
验证检查的结果,以确定所实施的措施是否有效。 | ||
|
描述
此属性记录了有效性检查的结果,这是质量管理闭环中至关重要的最后一步。它确认所采取的纠正或预防措施是否成功解决了根本原因并防止了再次发生。 这是“措施有效性验证”仪表板和“措施有效性验证率”KPI 的主要属性。它直接反映了问题解决流程本身的质量。无效措施比例过高表明需要改进根本原因分析或措施计划阶段。
为何重要
直接衡量问题解决流程的成功率,指示所采取的措施是否真正防止了问题再次发生。
获取方式
此类信息通常存储在质量通知单中的后续行动或特定任务状态里。它可能是自定义字段,也可能基于特定的状态代码。
示例
有效无效需要监控
|
|||
|
是否返工
IsRework
|
一个布尔标志,指示一项或一系列活动是否代表返工。 | ||
|
描述
如果某个 Case 重复某些步骤,则该标志设置为 true,表明初始工作不足。例如,如果“根本原因分析”活动之后又为同一 Case 分配了另一个“调查 Task”,则表明存在返工循环。 此属性直接支持“纠正措施返工率”KPI。识别并量化返工是流程挖掘的一个主要目标,因为返工代表了无效劳动和流程低效。在流程图中突出返工循环可以揭示提升质量和效率的重大机会。
为何重要
通过识别重复步骤来量化流程低效,突出无效劳动以及提高“第一次就做对”率的机会。
获取方式
这是一个计算出的属性。它是在 Process Mining 分析过程中,通过检测单个 case 中重复出现的活动序列得出的。
示例
truefalse
|
|||
|
活动处理时间
ProcessingTime
|
积极执行单个活动所花费的时间。 | ||
|
描述
处理时间(Processing Time),也称为周期时间,是指从单个活动的开始到结束所经历的时间。这与等待时间不同,等待时间是指活动之间花费的时间。它的计算方法是获取活动的开始和结束时间戳之差。 该指标对于识别哪些特定 Task 最耗时至关重要。在“流程瓶颈识别”仪表板中,某些活动的处理时间过长可能表明存在复杂性、资源缺乏或程序低效。它有助于精准定位流程改进工作的重点。
为何重要
衡量在增值活动上花费的时间,帮助识别流程中耗时最多的步骤,这些步骤是优化的首选对象。
获取方式
根据事件日志中每个活动的开始和结束 timestamp 计算得出的字段。(结束时间 - 开始时间)。
示例
2小时15分钟3 days 4 hours30 分钟
|
|||
|
源系统
SourceSystem
|
标识提取 data 的源系统,例如特定的 SAP S/4HANA 实例。 | ||
|
描述
此属性指定了质量管理数据的来源。在具有多个 ERP 或集成系统的环境中,此字段对于区分数据源和确保数据完整性至关重要。 对于分析而言,它允许过滤或比较不同系统或组织单位之间的流程。对于给定的数据集,它通常是一个常量值,但对于数据治理和背景信息而言是必需的。
为何重要
提供有关数据来源的基本背景信息,这对于数据治理以及在具有多个互连系统的环境中至关重要。
获取方式
这通常是在数据提取过程中添加的静态值,用于识别 SAP S/4HANA 客户端和系统 ID。
示例
S4H_PROD_100SAP_QM_EUS4HANA_QAS_200
|
|||
|
通知状态
SystemStatus
|
质量通知当前的处理状态,例如“未结”或“已完成”。 | ||
|
描述
系统状态指示了质量事件在其生命周期中的当前状态。SAP 使用状态管理系统,其中 OSNO(未结通知)、NOPR(处理中的通知)和 NOCO(已完成通知)等状态反映了进度。 此属性通常用于推导事件日志中的活动。作为过滤 Case 的维度也非常有用,例如,仅分析未结或最近关闭的质量事件。理解状态转换是构建准确流程模型的关键。
为何重要
指示 case 的当前状态,支持对进行中与已关闭 case 的过滤,并有助于派生流程活动。
获取方式
派生自存储各种 SAP 对象状态信息的 JEST 和 JSTO 表。链接来自 QMEL-OBJNR。
示例
OSNO NOPRNOCOTSCO
|
|||
质量管理活动
| 活动 | 描述 | ||
|---|---|---|---|
|
使用决策已做出
|
代表对检验批货物品质的正式决策,例如接受或拒绝。这是源自检验的质量问题的一个独特 Event,在保存使用决策时捕获。 | ||
|
为何重要
对于检验驱动型流程,这是一个决定后续行动(如物料冻结或发布)的关键里程碑。分析其时间和结果是了解产品质量控制效率的核心。
获取方式
这是记录在判定表 QAVE 中的显式事件。与检验批 (PRUEFLOS) 相关联的记录创建 timestamp 即代表此活动。
捕获
使用 QAVE 表中相关检验批的创建时间戳。
事件类型
explicit
|
|||
|
已创建质量通知
|
此活动标志着质量管理流程的正式启动,即正式记录与质量相关的议题、缺陷或投诉。在 SAP S/4HANA 中创建质量通知会捕获初始细节并分配唯一标识符,从而启动 Case。 | ||
|
为何重要
作为首要的开始 event,此活动对于衡量质量解决流程的端到端周期至关重要。它为追踪处理和关闭质量 event 所需的时间提供了基准。
获取方式
这是从质量通知单抬头表 QMEL 中捕获的显式事件。创建 timestamp 通常位于对应通知单编号 QMNUM 的 ERDAT 字段中。
捕获
使用指定通知单在 QMEL 表中的创建时间戳 (ERDAT)。
事件类型
explicit
|
|||
|
措施有效性已验证
|
确认所实施的纠正或预防措施已生效,且质量问题已解决且未再次发生。这在完成有效性检查任务或最终质量评估后捕获。 | ||
|
为何重要
这是验证整个解决流程的关键里程碑。成功的验证率高表明质量管理体系运行有效,并有助于减少重复性问题的发生。
获取方式
通常是根据 QMSM 表中“有效性检查”任务的完成情况推导出来的(使用完成日期 ERLDT)。
捕获
在 QMSM 中识别有效性验证任务的完成 timestamp。
事件类型
inferred
|
|||
|
根因分析已完成
|
标志着调查阶段的完成,此时已确定质量问题的根本原因。这通常根据通知中特定的“根本原因分析” Task 的完成情况推断得出。 | ||
|
为何重要
这是衡量调查过程持续时间和效率的关键里程碑。在此步骤之前识别延迟有助于发现问题分析和决策过程中的瓶颈。
获取方式
从 QMSM 表中调查或 RCA 特定任务的完成情况推断。完成情况通过状态更改或任务完成日期字段 (ERLDT) 的填充来识别。
捕获
在 QMSM 表中识别相关根本原因分析任务的完成 timestamp (ERLDT)。
事件类型
inferred
|
|||
|
纠正措施已实施
|
标志着纠正措施计划中定义的工作已完成。通常在质量通知中分配的纠正措施 Task 标记为完成时捕获。 | ||
|
为何重要
这是一个关键里程碑,表明已采取措施解决质量问题。它对于衡量措施的按时完成率以及解决阶段的整体效率至关重要。
获取方式
从 QMSM 表中纠正措施任务的完成情况推断。完成日期记录在 ERLDT 字段中,或通过 JEST/JCDS 表中的“已完成”状态更改记录。
捕获
在 QMSM 表中识别纠正措施任务的完成 timestamp (ERLDT)。
事件类型
inferred
|
|||
|
通知已完成
|
表示质量通知在业务上已完成,意味着已采取所有必要措施,且从运营角度看问题已解决。这是系统中的一个正式状态变更。 | ||
|
为何重要
此活动是衡量业务解决时间的主要终点。它证实了从流程所有者的角度来看 Case 已经结束,即使技术关闭尚待处理。
获取方式
从质量通知对象的状态更改中推断。这是通过在 JCDS 表中识别设置为“NOCO”(通知已完成)等状态时的 timestamp 来捕获的。
捕获
在 JCDS 表中识别设置为“通知已完成”状态时的 timestamp。
事件类型
inferred
|
|||
|
已通知利益相关者
|
代表向相关利益相关者(如客户或内部部门)传达解决结果。这很少是自动化的系统 Event,通常是一个手动步骤。 | ||
|
为何重要
及时的利益相关者沟通对客户满意度和透明度至关重要。衡量关闭与通知之间的延迟可以揭示沟通流程中的差距。
获取方式
该活动很难直接从 SAP 中捕获。它可能通过 QMSM 中标记为“通知利益相关者”的手动 Task 完成情况推断得出,或者需要对电子邮件日志等外部系统进行分析。
捕获
识别手动沟通任务的完成情况(如果使用了该任务)。否则,这通常不可用。
事件类型
inferred
|
|||
|
建议预防措施
|
此活动发生在创建防止质量问题再次发生的计划时。与纠正措施类似,通常通过创建“预防措施” Task 来捕获。 | ||
|
为何重要
这一 Event 对于评估组织是对主动质量改进的重视程度,还是仅关注被动补救至关重要。它标志着长期解决工作的开始。
获取方式
当在 QMSM 表中针对特定质量通知创建带有“预防措施”代码的 Task 时,将捕获此 Event。
捕获
对于预防措施类型的任务,使用 QMSM 表中的创建时间戳 (ERDAT)。
事件类型
explicit
|
|||
|
措施计划已批准
|
表示提议的纠正或预防措施计划已通过审核,获准开始实施。这一步通常不是一个独立的 Event,可能通过 Task 下达处理来推断。 | ||
|
为何重要
审批阶段的长延时会显著减慢整个解决流程。分析此环节的时长有助于识别行政瓶颈和精简治理流程的机会。
获取方式
这通常是根据 QMSM 表中任务的状态更改(如“已下达”)推导出来的。该状态更改的 timestamp 可在与任务对象关联的 JCDS 表中找到。
捕获
识别纠正或预防措施任务被设置为“已下达”状态时的 timestamp。
事件类型
inferred
|
|||
|
纠正措施已提出
|
此活动代表正式记录纠正已识别问题计划的时间点。在 SAP 中,通常通过在质量通知中创建“纠正措施” Task 来捕获。 | ||
|
为何重要
该 Event 启动了流程的解决阶段。衡量从根本原因分析到这一步的时间可以揭示措施计划中的延迟。
获取方式
当在 QMSM 表中针对相关质量通知创建带有“纠正措施”代码的 Task 时,将捕获此 Event。
捕获
对于纠正措施类型的任务,使用 QMSM 表中的创建时间戳 (ERDAT)。
事件类型
explicit
|
|||
|
调查任务已分配
|
当正式创建特定 Task(如调查根本原因)并将其分配给个人或部门时,会发生此活动。当在质量通知中创建 Task 记录时,会捕获此信息。 | ||
|
为何重要
追踪任务分配对于了解工作负载分布和识别资源分配瓶颈至关重要。它标志着调查阶段的开始,是衡量根因分析周期时间的关键输入。
获取方式
从链接到质量通知的任务管理表 QMSM 中捕获。带有相关代码(例如调查代码)的任务创建日期 (ERDAT) 标志着此 event 的发生。
捕获
对于调查相关的任务,使用 QMSM 表中的创建时间戳 (ERDAT)。
事件类型
explicit
|
|||
|
通知已关闭
|
代表系统中质量通知的最终技术关闭。此后不能再对通知进行更改,标志着该记录生命周期的绝对结束。 | ||
|
为何重要
此活动为流程提供了最终的结束点。分析“通知已完成”与“通知已关闭”之间的时间,可以揭示行政关闭程序中的延迟。
获取方式
从质量通知的状态更改中推断,特别是当设置了归档或最终关闭状态时。该更改会记录在 JCDS 表中并带有 timestamp。
捕获
在 JCDS 表中识别通知被设置为最终“已关闭”状态时的 timestamp。
事件类型
inferred
|
|||
|
通知已投入处理
|
代表新创建的通知被质量团队实际接手处理的时刻。这通常是一个推断出的 Event,源自指示工作已开始的系统状态更改。 | ||
|
为何重要
该活动有助于区分问题的简单记录与实际工作的开始。分析创建与此步骤之间的时间差,可以揭示在问题确认和资源分配方面潜在的延迟。
获取方式
从质量通知对象的状态更改中推断。这可以通过分析 JEST 和 JCDS 表中的状态更改日志来追踪,例如“NOPO”(通知处理中)状态。
捕获
在 JCDS 表中识别通知被设置为“处理中”状态时的 timestamp。
事件类型
inferred
|
|||
|
需要有效性检查
|
表示需要进行后续验证,以确认所实施的措施已成功解决问题。这通常由通知上的特定状态或创建专门的验证任务来体现。 | ||
|
为何重要
该活动确保质量管理流程包含一个关键的验证环节。它将措施的实施与对其成功的确认区分开来。
获取方式
可以从质量通知的状态更改(通过 JEST/JCDS)或在 QMSM 表中创建特定的“有效性检查”任务推断得出。
捕获
识别 QMSM 中状态更改或验证任务创建的 timestamp。
事件类型
inferred
|
|||
|
预防措施已实施
|
标志着计划好的预防措施已成功执行。通过在系统中记录相应的预防措施 Task 的完成来捕获。 | ||
|
为何重要
预防措施的完成是成熟质量流程中的关键一步。跟踪此活动有助于衡量对防止未来问题及减少重复性问题的重视程度。
获取方式
从 QMSM 表中预防措施任务的完成情况推断,由 ERLDT 字段或“已完成”状态更改指示。
捕获
在 QMSM 表中识别预防措施任务的完成 timestamp (ERLDT)。
事件类型
inferred
|
|||