您的质量管理数据模板
您的质量管理数据模板
这是适用于质量管理的通用流程挖掘数据模板。如需更具体的指导,请使用系统专用模板。
选择具体系统- 适用于事件日志的标准化数据字段。
- 用于完整了解流程情况的关键活动。
- 从不同系统提取数据的指导。
质量管理属性
| 名称 | 说明 | ||
|---|---|---|---|
| 事件开始时间 EventStartTime | 特定活动或事件发生或启动的准确日期和时间。 | ||
| 说明 Event Start Time是标记质量事件生命周期中每项活动开始时间的时间戳,为理解流程顺序和绩效提供必要的时间背景。该时间戳对于按时间顺序排列事件和计算持续时间至关重要。 在流程挖掘中,该时间戳用于将活动按每个案例的正确顺序排列,并计算周期时间、等待时间和处理时间等关键绩效指标。分析这些时间戳有助于识别步骤之间的延迟、衡量资源效率,并监控服务级别协议的执行情况。它是所有基于时间的流程分析的基础。 为什么重要 该时间戳对于排列事件顺序、计算周期时间和等待时间,以及发现流程瓶颈至关重要。 获取位置 通常与活动名称一起出现在事件日志或交易记录中,可能标记为“Creation Date”“Event Date”或“Timestamp”。 示例 2023-04-15T09:00:00Z2023-07-21T14:35:10Z2024-01-05T11:20:00Z | |||
| 活动名称 ActivityName | 质量管理流程中发生的特定任务、事件或步骤的名称。 | ||
| 说明 Activity Name描述质量事件生命周期中的具体操作或里程碑。例如“Initial Assessment Completed”“Investigation Initiated”或“Corrective Action Implemented”。这些活动构成质量管理流程的基本单元。 在流程分析中,此属性对于构建流程图至关重要。流程图以可视化方式呈现活动顺序和案例流转,帮助分析人员识别瓶颈、发现常见和罕见的流程变体,并根据标准操作规程检查合规性。理解活动顺序是流程改进的第一步。 为什么重要 此属性定义流程中的步骤,构成流程图的节点,并支持对流程顺序和变体进行分析。 获取位置 通常来源于事件日志、状态变更记录,或与主要质量事件对象相关的任务表。 示例 调查已启动根因分析已完成有效性已验证 | |||
| 质量事件ID QualityEventId | 单个质量事件的唯一标识符,作为案例标识,关联从启动到关闭的所有相关活动。 | ||
| 说明 Quality Event ID是用于标识特定质量问题的唯一键,例如不符合项、客户投诉、偏差或审计发现。该标识符至关重要,因为它将事件整个生命周期中相关的各个步骤、文档和数据点连接起来。 在流程挖掘中,此属性是重建每个质量事件端到端流程顺序的基础。将所有相关活动归入同一个Quality Event ID后,分析人员可以可视化流程图、计算案例持续时间,并分析不同事件路径之间的差异。这样可以清晰、准确地分析质量问题从开始到结束的处理过程。 为什么重要 这是流程挖掘的主键,可将所有相关事件连接到单个流程实例或案例。 获取位置 通常位于质量通知、事件或不符合项记录的表头或主表中。 示例 QN-2023-00123NC-450008761COMP-5501-A | |||
| 数据最后更新时间 LastDataUpdate | 表示流程数据最近一次刷新或从源系统提取时间的时间戳。 | ||
| 说明 Last Data Update属性记录数据最近一次从源系统同步的时间,是数据新鲜度指标,用于说明分析中的信息有多新。这对于持续监控和近实时决策尤其重要。 该属性帮助用户了解流程挖掘仪表板和分析结果的时效性。解读KPI和流程模型时,它能确保利益相关方了解数据的更新时间,避免依据过时信息做出决策。它是维护数据可信度的重要元数据。 为什么重要 表示数据的新鲜度,帮助用户了解流程分析和KPI的更新程度。 获取位置 通常是数据提取(ETL)过程中生成的元数据,一般不会出现在源系统的交易表中。 示例 2024-05-20T04:00:00Z2024-05-21T04:00:00Z2024-05-22T04:00:00Z | |||
| 源系统 SourceSystem | 提取数据的系统,例如特定的ERP、QMS或MES实例。 | ||
| 说明 Source System属性用于标识记录质量管理数据的源应用程序或数据库。在复杂的IT环境中,质量事件数据可能来自多个系统,例如ERP提供物料数据,专用质量管理系统提供流程数据。 识别源系统对于数据治理、验证和故障排查十分重要。它有助于了解数据背景,也可用于分段分析。例如,分析人员可以比较不同系统或地点管理的质量流程,以识别最佳实践或不一致之处。 为什么重要 提供数据来源背景,对于多系统环境中的数据验证、故障排查和分段分析至关重要。 获取位置 源表中可能没有此信息,但通常会在数据提取、转换和加载(ETL)过程中添加。 示例 SAP S/4HANA QMVeeva Vault QualityMasterControl QMS | |||
| 严重程度 Severity | 对质量事件潜在影响的分类,例如critical、major或minor。 | ||
| 说明 Severity属性根据质量事件的业务影响、风险或紧迫程度对其进行分类。这种分类有助于优先向最严重的问题分配资源和关注。严重程度通常由组织的质量政策定义。 在流程挖掘中,这是用于筛选和分段分析的重要属性。分析人员可以比较“Critical”事件与“Minor”事件的流程顺序,确保高严重程度问题按预期优先处理。该属性还可以揭示“Minor”问题是否占用过多资源,或“Critical”问题是否在流程中受阻,从而帮助优化基于风险管理的流程。 为什么重要 支持基于风险的流程分析,帮助确定调查优先级,并验证高影响事件是否得到及时、适当的处理。 获取位置 这是质量事件表头数据中的标准字段,通常标记为“Severity Level”或“Priority”。 示例 严重重大轻微 | |||
| 事件结束时间 EventEndTime | 特定活动或事件完成的准确日期和时间。 | ||
| 说明 Event End Time是标记活动完成时间的时间戳。结合Event Start Time,可以准确计算质量管理流程中单项任务的处理时间。对于瞬时事件,开始和结束时间可能相同。 该属性对于活动级绩效分析至关重要。通过计算每项任务的持续时间(结束时间减开始时间),分析人员可以识别最耗时、最适合优化的步骤。它还支持更准确地计算案例总体周期时间,并为资源工作量和效率分析提供所需数据。 为什么重要 支持计算活动处理时间,对于详细绩效分析和识别资源密集型任务至关重要。 获取位置 通常与开始时间一起出现在同一事件日志或交易记录中。在某些系统中,可能需要根据后续事件的开始时间推断。 示例 2023-04-15T17:30:00Z2023-07-22T10:05:45Z2024-01-05T11:25:00Z | |||
| 根因类别 RootCauseCategory | 对已识别质量事件根因的高层级分类。 | ||
| 说明 Root Cause Category用于分类质量问题的根本原因,例如“Human Error”“Equipment Failure”“Process Deficiency”或“Supplier Issue”。该属性通常在调查和根因分析完成后填写。 分析不同根因类别的发生频率,可以为战略改进提供重要洞察。如果“Process Deficiency”是常见根因,说明需要重新设计流程;如果“Equipment Failure”频繁发生,则可能需要改进维护计划。流程挖掘还可以将这些类别与流程行为关联,例如显示由“Human Error”引起的事件是否需要更长时间才能解决。 为什么重要 这对战略分析至关重要,因为它超越流程顺序,深入探究失败背后的原因,为有针对性的预防措施提供依据。 获取位置 位于质量事件记录的调查或根因分析部分,可能是代码或自由文本。 示例 设备故障人为错误材料缺陷 | |||
| 负责部门 ResponsibleDepartment | 负责质量事件或特定活动的部门、团队或职能领域。 | ||
| 说明 Responsible Department属性表示对质量事件或流程中特定步骤负责的组织单元,可能是“Manufacturing”“Quality Assurance”“Research and Development”或“Logistics”。 该属性对于组织分析至关重要。它帮助管理人员了解工作如何在不同部门之间流转,衡量各职能领域的绩效,并识别跨职能协作中的摩擦或延误。例如,分析可能显示制造部门与质量保证部门之间的交接是延误的主要来源。按部门细分KPI,有助于精准定位流程改进重点。 为什么重要 支持按组织单元分析流程绩效,突出跨职能延误并帮助明确责任。 获取位置 通常位于质量事件记录的表头数据中,或根据活动负责人的用户信息推导。 示例 质量控制B生产线供应商质量 | |||
| 质量事件类型 QualityEventType | 质量事件的分类,例如Non-Conformance、Customer Complaint、Audit Finding或Deviation。 | ||
| 说明 Quality Event Type用于分类所处理质量问题的性质。不同类型的事件通常遵循不同流程,具有不同紧急程度,并受不同标准操作规程约束。 按此属性筛选和比较流程,分析人员可以发现显著差异。例如,“Customer Complaint”的处理流程可能比“Internal Problem”更加严格且对时效要求更高。理解这些差异,对于评估每种流程变体是否高效运行并符合特定要求至关重要。 为什么重要 支持按不同质量问题类型细分分析,比较其处理方式,发现重要的流程差异。 获取位置 位于质量事件的表头数据中,通常是“Notification Type”“Event Type”或“Category”字段。 示例 客户投诉不符合项报告(NCR)偏差 | |||
| 资源 Resource | 执行或被分配执行特定活动或质量事件的用户、员工或自动化代理。 | ||
| 说明 Resource属性用于标识负责执行任务的个人或系统,可能是调查人员、质量审批人员或自动化系统用户。跟踪每项活动的执行者,是了解工作量分配、团队绩效和协作模式的基础。 按资源分析流程,有助于发现个人或团队之间的绩效差异、识别培训需求并优化工作量平衡。分析还可以发现工作负荷过高、可能成为瓶颈的资源,或识别不同人员之间的交接模式,而交接往往是流程延误的来源。这类分析是提升组织效率的关键。 为什么重要 此属性对于基于资源的分析至关重要,包括工作量分配、绩效比较和组织瓶颈识别。 获取位置 通常位于交易表或日志表中,常标记为“User Name”“Changed By”“Owner”或“Assigned To”。 示例 j.doem.smithSystem.Batch | |||
| 位置 Location | 质量事件发生或管理所在的物理或逻辑位置,例如工厂、场地或仓库。 | ||
| 说明 Location属性用于指定与质量事件相关的地理位置或组织地点,可能是制造工厂、具体生产线、配送中心或业务单元。 按地点分析流程绩效,是开展基准比较和识别最佳实践的有效方式。它可以显示某些地点解决质量问题的效率是否更高,或特定地点是否持续产生问题。这类基于地理位置或场地的分析,有助于管理层有效分配资源,并在组织内推广高绩效流程。 为什么重要 支持比较不同场地或工厂的绩效,帮助开展基准分析,并识别地点特有的问题或最佳实践。 获取位置 通常属于质量事件主记录的一部分,常标记为“Plant”“Site”或“Business Unit”。 示例 A地点,2号楼主仓库工厂0010 | |||
| 受影响产品 AffectedProduct | 作为质量事件对象的产品、物料或组件。 | ||
| 说明 Affected Product属性用于标识受质量问题影响的具体物料、产品或产品线。流程与产品之间的关联对于根因分析和影响评估至关重要。 按产品分析质量事件,可以发现趋势,例如某一产品的不符合项数量异常偏高,从而推动对产品设计或制造流程开展深入调查。该属性还可根据受影响产品的战略重要性或销售量,帮助确定质量事件优先级,确保先处理关键问题。 为什么重要 将流程数据与产品数据关联,支持按产品线分析质量问题,识别趋势并优先处理影响较大的问题。 获取位置 位于质量事件的主记录中,通常标记为“Material Number”“Product ID”或“Part Number”。 示例 PROD-100-XLMAT-RAW-05BFG-2055-ASSY | |||
| 有效性检查结果 EffectivenessCheckOutcome | 用于确认已实施的纠正和预防措施是否有效的验证检查结果。 | ||
| 说明 Effectiveness Check Outcome记录纠正措施实施后验证步骤的结果。结果通常为“Effective”或“Not Effective”,用于表示该措施是否成功解决问题的根本原因。 该属性对于衡量质量管理流程的实际成效至关重要。“Not Effective”结果占比较高,说明根本原因分析或措施规划阶段可能存在系统性问题,进而导致返工和问题反复发生。在流程挖掘中,这一属性可用于分析返工循环。例如,结果为“Not Effective”的案例通常会回到调查或根本原因分析阶段,显著增加周期时间和成本。 为什么重要 直接衡量纠正措施的成效,对于分析返工循环和根本原因分析流程的有效性至关重要。 获取位置 可在与纠正和预防措施(CAPA)验证或关闭步骤相关的记录中找到。 示例 有效无效等待验证 | |||
| 目标解决日期 TargetResolutionDate | 质量事件应完全解决并关闭的计划日期或要求日期。 | ||
| 说明 Target Resolution Date是质量事件关闭期限,通常根据事件严重程度,由法规要求、客户服务级别协议或内部政策确定。 该属性对于绩效监控和合规分析至关重要。将实际关闭日期与目标日期比较,可以计算“按时解决率”KPI。流程挖掘能够识别最容易导致延误和超出目标的事件类型或流程步骤,帮助将改进工作集中于达成时效目标。 为什么重要 支持根据时效目标衡量绩效,帮助计算按时解决率并识别延误原因。 获取位置 通常位于质量事件记录的表头或计划数据中。 示例 2024-06-302024-07-152024-08-01 | |||
| 质量事件状态 QualityEventStatus | 质量事件在生命周期中的当前总体状态,例如Open、Under Investigation或Closed。 | ||
| 说明 Quality Event Status表示质量事件案例的当前状态。这是一个动态属性,会随着案例在生命周期中推进而变化,为事件在任意时点所处的位置提供高层概览。 在流程挖掘中,此属性有助于分析当前工作量和积压。通过筛选状态为“Open”或“In Progress”的事件,管理人员可以监控活跃案例数量。它还支持一致性检查,将实际状态变化与预期流程顺序进行比较。例如,在实施“Corrective Action”之前,事件不应变为“Closed”。 为什么重要 提供案例当前状态的概览,对于监控积压、活动工作量和检查流程合规性至关重要。 获取位置 这是质量事件表头记录中的关键字段,会随着事件推进而更新。 示例 开放等待批准已关闭 | |||
质量管理活动
| 活动 | 说明 | ||
|---|---|---|---|
| 有效性已验证 | 确认已实施的纠正和预防措施成功解决根因并防止问题再次发生。这是正式的验证步骤,通常在设定的监控期结束后进行。 | ||
| 为什么重要 这是衡量质量干预是否成功的最终指标。它验证调查和措施投入的资源是否产生了积极结果,并避免未来返工。 获取位置 通常在专门的有效性检查任务完成,或记录状态更新为“Effectiveness Verified”时记录,并可能附带电子签名。 采集 记录有效性检查任务完成,或最终验证审批步骤完成的时间戳。 事件类型 explicit | |||
| 根因分析已完成 | 表示调查已完成,质量事件的一个或多个根本原因已经识别并记录。这是制定任何纠正措施前的关键里程碑。 | ||
| 为什么重要 该里程碑标志着诊断阶段结束。分析根因分析的持续时间,有助于识别问题解决活动中的复杂环节和瓶颈。 获取位置 当“根本原因”或相关分析字段填写并保存时,可以推断该活动已完成。在某些系统中,它对应特定RCA任务的完成。 采集 记录专用根因分析任务标记为完成的时间戳,或根本原因描述字段首次填写的时间。 事件类型 inferred | |||
| 纠正措施已实施 | 表示已完成批准的纠正措施计划中列出的任务,确认已采取必要措施解决当前问题。 | ||
| 为什么重要 此活动标志着实际纠正工作的结束。计划获批到措施实施之间的时间,反映了团队执行相关任务的效率。 获取位置 通常在实施人员于系统中将分配的行动项或任务标记为完成时记录。 采集 使用相关纠正措施任务的完成时间戳,或将措施计划记录的状态更新为“Implemented”的时间戳。 事件类型 explicit | |||
| 纠正措施计划已批准 | 表示指定负责人正式批准拟定的纠正措施计划。这项批准是启动实施的关键关口。 | ||
| 为什么重要 审批周期通常是延误的主要来源。分析此活动的持续时间和频率,有助于识别审核和审批工作流中的瓶颈。 获取位置 通常是工作流中明确记录并带有时间戳的审批操作,往往通过电子签名或特定状态变更记录。 采集 记录电子签名记录的时间戳,或状态更改为“Approved”或“Released for Implementation”的时间戳。 事件类型 explicit | |||
| 调查已启动 | 标志着调查阶段正式开始,用于确定质量事件的范围和根本原因。调查人员或团队会被正式分配到该案例。 | ||
| 为什么重要 该活动标志着核心问题解决阶段的开始。跟踪从事件创建到调查启动的时间,可以揭示质量团队可能存在的积压。 获取位置 通常在记录状态更新为“调查中”或调查人员正式分配到记录时捕获该事件。 采集 使用状态变更为“调查中”的时间戳,或负责人、调查人员角色首次分配的时间。 事件类型 inferred | |||
| 质量事件已关闭 | 最后一个活动,标志着质量事件记录已成功解决并完成管理关闭。此时流程视为完成,记录转为历史记录。 | ||
| 为什么重要 这是流程的主要终点。关闭所需时间是关键KPI,分析已关闭事件可以完整了解端到端流程。 获取位置 这是一个关键的明确事件,在记录的最终状态更改为“Closed”或“Completed”时捕获,并带有时间戳。 采集 使用最终状态更改为“Closed”、“Completed”或等效终止状态的时间戳。 事件类型 explicit | |||
| 质量事件已创建 | 这是第一个活动,标志着质量事件记录正式创建。用户识别质量问题,例如不符合项、缺陷或投诉,并将其录入系统,从而启动流程。 | ||
| 为什么重要 该活动是流程的主要起点,可用于衡量从识别到解决的总周期时间,也是跟踪新增质量事件数量的基础。 获取位置 这通常是审计轨迹或交易日志中记录的明确事件,表示新记录已创建。请在主要质量事件表中查找创建时间戳。 采集 使用质量事件记录的创建时间戳,例如质量通知、不符合项或投诉记录的创建时间。 事件类型 explicit | |||
| 最终审核已完成 | 对完整的质量事件记录进行最终检查,确保文档齐全且所有流程步骤均已执行。这通常是关闭前的最后一个审批步骤。 | ||
| 为什么重要 此活动代表关闭案例前的最终质量关口。这里的延误会人为延长周期时间,也可能表明存在文档问题。 获取位置 通常是质量保证人员执行的明确审批步骤或电子签名,完成后状态才能更改为“Closed”。 采集 使用最终质量审核批准的时间戳,或状态更改为“Pending Closure”或“Final Review Complete”的时间戳。 事件类型 explicit | |||
| 初始评估已完成 | 表示对新创建质量事件的初步审查或分流已完成。在此步骤中,事件会按类型分类、分配严重程度,并确定优先级,以决定后续工作流。 | ||
| 为什么重要 分析初始阶段耗时,有助于识别新质量事件在确认和处理过程中的延迟,也能提供按严重程度或类型筛选案例所需的属性。 获取位置 通常可根据状态从“新建”变为“评估中”或“处理中”来推断。也可以在特定分类和优先级字段首次填写时记录。 采集 记录状态变更为表示评估完成的时间戳,或分类和优先级字段首次保存的时间。 事件类型 inferred | |||
| 有效性验证失败 | 表示已实施的措施未能有效解决问题。此结果通常会触发新的调查或新一轮纠正措施。 | ||
| 为什么重要 此活动表示流程出现重大失败,并形成较大的返工循环。分析这些事件对于了解解决方案失效原因、改进RCA流程至关重要。 获取位置 通常在验证步骤失败并导致状态变更、重新打开调查或CAPA计划时记录。 采集 记录表示验证失败的状态变更时间戳,例如“Effectiveness Failed”或“Re-Investigation Required”。 事件类型 explicit | |||
| 相关方已通知 | 表示向相关方正式传达质量事件的解决结果,例如报告人或受影响的部门。 | ||
| 为什么重要 虽然利益相关方沟通不一定是核心流程步骤,但跟踪沟通情况可以了解流程的完整性和整体服务水平。 获取位置 此活动较难记录,可能表现为明确的日志操作,也可能根据工作流中“Final Notification”任务的完成情况推断。 采集 记录自动邮件通知的时间戳,或手动沟通任务被标记为完成的时间戳。 事件类型 inferred | |||
| 纠正措施计划已拒绝 | 表示拟定的纠正措施计划经过审核但未获批准。计划需要修改后重新提交,从而在流程中形成返工循环。 | ||
| 为什么重要 此活动反映了流程中的低效和返工。较高的拒绝率可能表明要求不明确,或根因分析不充分。 获取位置 通常通过将状态更改为“Rejected”或“Revision Required”来记录,并可能附带原因代码或评论。 采集 记录状态更改为“Rejected”或“Sent Back for Revision”的时间戳。 事件类型 explicit | |||
| 纠正措施计划已提出 | 当针对已识别根本原因的正式处理计划完成记录并提交审核时,该活动发生。计划中会列出需要采取的具体纠正措施。 | ||
| 为什么重要 此步骤启动流程的解决阶段。跟踪提出计划所需的时间,可以了解团队从分析转向行动的速度。 获取位置 通常通过创建相关的Corrective Action Plan记录,或将状态更改为表示计划已准备好接受审核的状态来记录。 采集 使用关联Corrective Action或CAPA记录的创建时间戳,或状态更改为“Pending Approval”的时间戳。 事件类型 explicit | |||
| 质量事件已取消 | 这是质量事件未完全解决即终止的另一种终点。事件可能被判定为无效、与其他条目重复,或因误操作创建。 | ||
| 为什么重要 此活动代表流程的另一种非生产性终点。取消事件数量较多,可能表明用户培训或初始数据录入流程存在问题。 获取位置 通常通过将状态更改为“Canceled”或“Void”来记录,并附带相应的原因代码。 采集 记录记录状态更新为“Canceled”、“Void”或“Invalid”的时间戳。 事件类型 explicit | |||
| 预防措施已实施 | 表示已完成旨在消除潜在不符合项原因、防止问题再次发生的任务。这是一项通常在纠正措施之后采取的主动措施。 | ||
| 为什么重要 此活动体现了成熟的质量流程,重点在于预防,而不仅是纠正。跟踪预防措施的实施情况,有助于衡量长期流程改进工作。 获取位置 通常在分配的预防措施任务被标记为完成时记录,相关记录往往与原始质量事件关联。 采集 使用相关预防措施任务的完成时间戳,或预防措施记录的状态更新时间。 事件类型 explicit | |||
数据提取指南
立即开始优化质量管理
借助数据驱动的洞察识别瓶颈,提升合规水平。
无需信用卡,5分钟完成设置。