质量管理数据模板
质量管理数据模板
这是适用于质量管理的通用流程挖掘数据模板。使用针对具体系统的模板,可获取更有针对性的指导。
选择具体系统- 为事件日志规范数据字段。
- 跟踪关键活动,全面了解流程。
- 提供从不同系统提取数据的指导。
质量管理属性
| 名称 | 说明 | ||
|---|---|---|---|
| 事件开始时间 EventStartTime | 特定活动或事件发生或启动的准确日期和时间。 | ||
| 说明 事件开始时间是标记质量事件生命周期中每项活动开始时刻的时间戳,为理解流程走向和绩效提供必要的时间信息。它对于按时间顺序排列事件和计算耗时至关重要。 在流程挖掘中,此时间戳用于按正确顺序排列每个案例中的活动,并计算周期时间、等待时间和处理时间等关键绩效指标。分析这些时间戳有助于发现步骤间的延误、衡量资源效率,并监控服务水平协议的执行情况。它是所有基于时间的流程分析的基础。 重要性 此时间戳对于排列事件顺序、计算周期时间和等待时间,以及发现流程瓶颈至关重要。 获取途径 通常与活动名称一同记录在事件日志或事务记录中,字段名称可能是“创建日期”“事件日期”或“时间戳”。 示例 2023-04-15T09:00:00Z2023-07-21T14:35:10Z2024-01-05T11:20:00Z | |||
| 活动名称 ActivityName | 质量管理流程中发生的特定任务、事件或步骤的名称。 | ||
| 说明 活动名称用于描述质量事件生命周期中的具体操作或里程碑,例如“初步评估已完成”“调查已启动”或“纠正措施已实施”。这些活动构成了质量管理流程的基本环节。 在流程分析中,此属性是构建流程图的关键,可直观呈现活动顺序和案例流转情况。分析人员可以据此发现瓶颈、识别常见和少见的流程变体,并检查流程是否符合标准操作规程。了解活动顺序是改进流程的第一步。 重要性 此属性定义流程中的各个步骤,构成流程图的节点,并支持分析流程走向和变体。 获取途径 通常从事件日志、状态变更记录或与主要质量事件对象相关的任务表中提取。 示例 启动调查完成根本原因分析有效性已验证 | |||
| 质量事件ID QualityEventId | 单个质量事件的唯一标识符,作为案例标识符,将从启动到关闭的所有相关活动关联起来。 | ||
| 说明 质量事件ID是用于标识特定质量问题的唯一键,例如不符合项、客户投诉、偏差或审核发现。此标识符至关重要,可将事件整个生命周期内相关的各个步骤、文档和数据点关联起来。 在流程挖掘中,此属性是还原每个质量事件端到端流程的基础。将所有相关活动归入同一个质量事件ID后,分析人员可以查看流程图、计算案例耗时,并分析不同事件路径的差异。这样便能清晰、准确地分析质量问题从开始到结束的处理过程。 重要性 这是流程挖掘的主键,可将所有相关事件关联到同一个流程实例或案例中。 获取途径 通常位于质量通知、事件或不符合项记录的标题信息或主表中。 示例 QN-2023-00123NC-450008761COMP-5501-A | |||
| 数据最近更新时间 LastDataUpdate | 表示流程数据最近一次从源系统刷新或提取时间的时间戳。 | ||
| 说明 数据最近更新时间属性记录了数据最近一次从源系统同步的时间戳,可用于判断数据的新鲜度,了解分析中的信息是否为最新数据。这对于持续监控和近实时决策尤为重要。 此属性有助于用户了解流程挖掘仪表板和分析结果的时效性。解读KPI和流程模型时,相关方可以据此确认数据是否为最新,避免依据过时信息做出决策。这是维护数据可信度的重要元数据。 重要性 用于显示数据的新鲜度,让用户了解流程分析和KPI的更新情况。 获取途径 这通常是数据提取(ETL)过程中生成的元数据,一般不会出现在源系统的事务表中。 示例 2024-05-20T04:00:00Z2024-05-21T04:00:00Z2024-05-22T04:00:00Z | |||
| 源系统 SourceSystem | 提取数据的系统,例如特定的ERP、QMS或MES实例。 | ||
| 说明 源系统属性用于标识记录质量管理数据的源应用程序或数据库。在复杂的IT环境中,质量事件数据可能来自多个系统,例如,物料数据来自ERP,流程数据来自专用质量管理系统。 识别源系统对于数据治理、验证和故障排查十分重要,有助于了解数据背景,也可用于细分分析。例如,分析人员可以比较不同系统或地点管理的质量流程,从而发现最佳实践或不一致之处。 重要性 提供数据来源背景,这对于多系统环境中的数据验证、故障排查和细分分析至关重要。 获取途径 源表中可能没有这项信息,但通常会在数据提取、转换和加载(ETL)过程中添加。 示例 SAP S/4HANA QMVeeva Vault QualityMasterControl QMS | |||
| 严重程度 Severity | 对质量事件潜在影响的分类,例如严重、重大或轻微。 | ||
| 说明 严重程度属性根据质量事件对业务的影响、风险或紧急程度进行分类,有助于优先分配资源并关注最关键的问题。严重程度级别通常由组织的质量政策规定。 在流程挖掘中,此属性适用于筛选和细分分析。分析人员可以比较“严重”事件与“轻微”事件的流程走向,确认高严重程度事件是否按预期优先处理。分析还可以发现“轻微”问题是否占用了过多资源,或“严重”问题是否在流程中受阻,从而优化基于风险的管理流程。 重要性 支持基于风险的流程分析,帮助确定调查优先级,并验证高影响事件是否得到及时处理。 获取途径 这是质量事件标题数据中的标准字段,名称通常为“严重程度级别”或“优先级”。 示例 严重重大轻微 | |||
| 事件结束时间 EventEndTime | 特定活动或事件完成的准确日期和时间。 | ||
| 说明 事件结束时间是标记活动完成时刻的时间戳。结合事件开始时间,可以准确计算质量管理流程中各项任务的处理时间。对于瞬时事件,开始时间和结束时间可能相同。 此属性对于活动层面的绩效分析至关重要。通过计算每项任务的耗时(结束时间减去开始时间),分析人员可以找出耗时最长、最值得优化的步骤。它还可用于更准确地计算整体案例周期时间,并为资源工作量和效率分析提供所需数据。 重要性 用于计算活动处理时间,这对于详细分析绩效和识别资源密集型任务至关重要。 获取途径 通常与开始时间一同记录在事件日志或事务记录中。在某些系统中,可能需要根据后续事件的开始时间推算。 示例 2023-04-15T17:30:00Z2023-07-22T10:05:45Z2024-01-05T11:25:00Z | |||
| 根因类别 RootCauseCategory | 对已识别的质量事件根因进行的高级分类。 | ||
| 说明 根因类别用于归类质量问题的根本原因,例如“人为错误”“设备故障”“流程缺陷”或“供应商问题”。通常在调查和根因分析完成后填写此属性。 分析不同根因类别的发生频率,有助于制定改进策略。如果“流程缺陷”是常见根因,说明需要重新设计流程;如果“设备故障”频繁发生,则可能需要优化维护计划。流程挖掘还可以将这些类别与流程行为关联起来,例如,查看由“人为错误”引发的事件是否需要更长时间才能解决。 重要性 这对战略分析至关重要,因为它不仅关注流程如何流转,还能揭示问题背后的原因,为有针对性的预防措施提供依据。 获取途径 可在质量事件记录的调查或根因分析部分找到。内容可能是代码或自由文本。 示例 设备故障人为错误材料缺陷 | |||
| 责任部门 ResponsibleDepartment | 对质量事件或特定活动负责的部门、团队或职能领域。 | ||
| 说明 责任部门属性用于标明对质量事件或流程中特定步骤负责的组织单位,例如“生产”“质量保证”“研发”或“物流”。 此属性对于组织分析至关重要。管理者可以据此了解工作如何在不同部门间流转、衡量各职能部门的绩效,并发现跨部门协作中的摩擦或延误。例如,分析可能发现生产部门与质量保证部门之间的交接是延误的主要原因。按部门细分KPI,有助于确定有针对性的流程改进方向。 重要性 支持按组织单位分析流程绩效,突出跨部门延误,并帮助明确责任归属。 获取途径 通常位于质量事件记录的标题数据中,也可能根据活动负责人推导得出。 示例 质量控制B生产线供应商质量 | |||
| 质量事件类型 QualityEventType | 质量事件的分类,例如不符合项、客户投诉、审核发现或偏差。 | ||
| 说明 质量事件类型用于对所处理的质量问题进行分类。不同类型的事件通常遵循不同流程,紧急程度各异,并受不同标准操作规程约束。 按此属性筛选和比较流程,分析人员可以发现显著差异。例如,处理“客户投诉”的流程可能比处理“内部问题”的流程更严格、时限要求更高。了解这些差异,对于评估各类流程变体是否高效运行并符合相应要求至关重要。 重要性 支持按不同质量问题类型细分分析和比较处理方式,从而发现重要的流程差异。 获取途径 位于质量事件的标题数据中,字段名称通常为“通知类型”“事件类型”或“类别”。 示例 客户投诉不符合项报告(NCR)偏差 | |||
| 资源 Resource | 执行特定活动或质量事件,或被分配执行该活动或事件的用户、员工或自动化代理。 | ||
| 说明 资源属性用于标识负责执行任务的个人或系统,例如调查人员、质量审批人员或自动化系统用户。跟踪每项活动的执行者,是了解工作量分配、团队绩效和协作模式的基础。 按资源分析流程,有助于发现个人或团队之间的绩效差异、确定培训需求并优化工作量分配。分析还可以发现可能成为瓶颈的超负荷资源,或不同人员之间的交接模式,而交接往往是流程延误的原因之一。这类分析有助于提升组织效率。 重要性 此属性对于资源分析至关重要,包括工作量分配、绩效比较和组织瓶颈识别。 获取途径 通常位于事务表或日志表中,字段名称可能是“用户名”“修改人”“所有者”或“分配给”。 示例 j.doem.smithSystem.Batch | |||
| 受影响产品 AffectedProduct | 质量事件涉及的产品、物料或组件。 | ||
| 说明 受影响产品属性用于标识受质量问题影响的具体物料、产品或产品线。将流程数据与产品关联,对于根因分析和影响评估至关重要。 按产品分析质量事件,有助于企业发现趋势,例如某款产品的不符合项数量异常偏高。这可能促使团队进一步调查产品设计或生产流程。此属性还有助于根据受影响产品的战略重要性或销量确定质量事件的优先级,确保优先处理关键问题。 重要性 将流程数据与产品数据关联,支持按产品线分析质量问题,发现趋势并优先处理影响较大的问题。 获取途径 位于质量事件的主记录中,字段名称通常为“物料编号”“产品ID”或“零件编号”。 示例 PROD-100-XLMAT-RAW-05BFG-2055-ASSY | |||
| 地点 Location | 质量事件发生或正在处理的物理或逻辑地点,例如工厂、场地或仓库。 | ||
| 说明 地点属性用于指定与质量事件相关的地理位置或组织场所,例如制造工厂、特定生产线、配送中心或业务单元。 按地点分析流程绩效,有助于进行对标并发现最佳实践。分析可以揭示哪些场所解决质量问题的效率更高,或哪些地点反复出现问题。基于地理位置或场所的分析有助于管理层有效分配资源,并在组织内推广绩效较好的流程。 重要性 便于比较不同场所或工厂的绩效,进行对标,并发现特定地点的问题或最佳实践。 获取途径 此信息通常位于质量事件主记录中,字段名称可能为“工厂”“场所”或“业务单元”。 示例 A场地-2号楼主仓库工厂0010 | |||
| 有效性检查结果 EffectivenessCheckOutcome | 用于确认已实施的纠正和预防措施是否有效的验证结果。 | ||
| 说明 有效性检查结果记录了纠正措施实施后的验证结果。结果通常为“有效”或“无效”,用于说明该措施是否成功解决了问题的根因。 此属性对于衡量质量管理流程的实际成效至关重要。“无效”结果比例较高,说明根因分析或措施规划阶段可能存在系统性问题,导致返工和问题反复发生。在流程挖掘中,可利用此属性分析返工循环。例如,结果为“无效”的案例往往会返回调查或根因分析阶段,显著延长周期时间并增加成本。 重要性 直接衡量纠正措施的成效,是分析返工循环和根因分析流程有效性的关键依据。 获取途径 可在与纠正和预防措施(CAPA)验证或关闭步骤相关的记录中找到。 示例 有效无效待验证 | |||
| 目标解决日期 TargetResolutionDate | 质量事件应完成解决并关闭的计划日期或要求日期。 | ||
| 说明 目标解决日期是为关闭质量事件设定的截止日期。该日期通常依据法规要求、客户服务级别协议,或根据事件严重程度制定的内部政策确定。 此属性对于绩效监控和合规分析至关重要。将实际关闭日期与目标日期进行比较,组织可以计算“按时解决率”这一KPI。流程挖掘可以识别哪些类型的事件或流程步骤最容易导致延误和未能按期完成,从而帮助团队将改进工作聚焦于按时完成目标。 重要性 用于衡量流程是否达到时效目标,帮助计算按时解决率并识别延误原因。 获取途径 通常位于质量事件记录的标题或计划数据中。 示例 2024-06-302024-07-152024-08-01 | |||
| 质量事件状态 QualityEventStatus | 质量事件生命周期中的当前整体状态,例如已开启、调查中或已关闭。 | ||
| 说明 质量事件状态表示质量事件案例的当前状态。此属性会随着案例在生命周期中的推进而动态变化,可概览事件在任一时点的进展情况。 在流程挖掘中,此属性有助于分析当前工作量和积压情况。管理者可以筛选状态为“已开启”或“处理中”的事件,监控活跃案例数量。此属性也有助于进行一致性检查,将实际状态变更与预期流程进行比较。例如,纠正措施尚未实施时,事件不应“已关闭”。 重要性 显示案例当前状态,对于监控积压和活跃工作量,以及检查流程一致性至关重要。 获取途径 这是质量事件标题记录中的关键字段,会随着事件进展而更新。 示例 已开启待批准已关闭 | |||
质量管理活动
| 活动 | 说明 | ||
|---|---|---|---|
| 创建质量事件 | 这是流程中的第一个活动,标志着正式创建质量事件记录。用户发现质量问题,例如不符合项、缺陷或投诉,并将其录入系统,启动处理流程。 | ||
| 重要性 此活动是流程的主要起点,可用于衡量从发现问题到解决问题的总周期时间,也有助于跟踪新增质量事件的数量。 获取途径 通常,创建新记录时会在审计轨迹或事务日志中留下明确事件。请查看主要质量事件表中的创建时间戳。 采集 使用质量事件记录的创建时间戳,例如质量通知、不符合项或投诉记录。 事件类型 explicit | |||
| 启动调查 | 标志着调查阶段正式开始,以确定质量事件的范围和根本原因。调查人员或团队会被正式指派处理该案例。 | ||
| 重要性 此活动标志着核心问题解决阶段的开始。跟踪从事件创建到调查启动的时间,有助于发现质量团队可能存在的积压。 获取途径 通常在记录状态更新为“调查中”或正式指派调查人员时记录此事件。 采集 使用状态变为“调查中”时的时间戳,或首次指派负责人或调查人员角色时的时间戳。 事件类型 inferred | |||
| 完成根本原因分析 | 表示调查已完成,并已识别和记录质量事件的一个或多个根本原因。这是制定纠正措施前的重要里程碑。 | ||
| 重要性 此里程碑标志着诊断阶段结束。分析根本原因分析所需时间,有助于发现问题解决活动中的复杂环节和瓶颈。 获取途径 当“根本原因”或相关分析字段填写并保存后,可据此推断此活动。在某些系统中,它对应特定RCA任务的完成。 采集 记录专门的根本原因分析任务标记为完成时的时间戳,或首次填写根本原因说明字段时的时间戳。 事件类型 inferred | |||
| 有效性已验证 | 确认已实施的纠正和预防措施成功解决根因并防止问题再次发生。这是正式的验证步骤,通常在一段监控期后进行。 | ||
| 重要性 这是衡量质量干预是否成功的最终标准。它验证调查和措施投入的资源是否取得了积极成效,并避免未来返工。 获取途径 通常在专门的有效性检查任务完成,或记录状态更新为“有效性已验证”时记录,且往往附有电子签名。 采集 记录有效性检查任务完成或最终验证审批步骤的时间戳。 事件类型 explicit | |||
| 纠正措施已实施 | 表示已完成获批纠正措施计划中列出的任务,确认已采取必要措施解决当前问题。 | ||
| 重要性 此活动标志着实际纠正工作结束。从计划获批到措施实施的时间,反映了团队执行相关任务的效率。 获取途径 通常由实施人员在系统中将分配的措施项或任务标记为完成时记录。 采集 使用相关纠正措施任务的完成时间戳,或措施计划记录状态更改为“已实施”的时间戳。 事件类型 explicit | |||
| 纠正措施计划已批准 | 表示指定负责人正式批准了拟议的纠正措施计划。这是启动实施的关键审批环节。 | ||
| 重要性 审批周期往往是造成延误的原因。分析此活动的耗时和频率,有助于发现审核与审批工作流中的瓶颈。 获取途径 通常会在工作流中明确记录带时间戳的审批操作,例如电子签名或特定状态变更。 采集 记录电子签名的时间戳,或状态更改为“已批准”或“已发布实施”的时间戳。 事件类型 explicit | |||
| 质量事件已关闭 | 这是最后一项活动,标志着质量事件已成功解决并完成行政关闭。此时流程结束,记录转为历史记录。 | ||
| 重要性 这是流程的主要终点。关闭所需时间是一项关键KPI,分析已关闭事件可以全面了解端到端流程。 获取途径 这是一个关键的明确事件:记录的最终状态更改为“已关闭”或“已完成”时会记录相应时间戳。 采集 使用最终状态更改为“已关闭”“已完成”或其他等效终止状态的时间戳。 事件类型 explicit | |||
| 最终审核已完成 | 对完整的质量事件记录进行最终检查,确保文档齐全且已遵循所有程序步骤。这通常是关闭事件前的最后一个审批步骤。 | ||
| 重要性 此活动是关闭案例前的最后一道质量关口。此处的延误会拉长周期时间,也可能表明存在文档问题。 获取途径 通常由质量保证人员明确执行审批或电子签名,之后才能将状态更改为“已关闭”。 采集 使用最终质量审核获批的时间戳,或状态更改为“待关闭”或“最终审核已完成”的时间戳。 事件类型 explicit | |||
| 完成初步评估 | 表示已完成对新建质量事件的初步审查或分流。在此步骤中,系统会按类型对事件分类、分配严重程度并确定优先级,以决定后续工作流。 | ||
| 重要性 分析此初始阶段的耗时,有助于发现确认和处理新质量事件时的延误,也可提供按严重程度或类型筛选案例的属性。 获取途径 通常可根据状态从“新建”变为“评估中”或“处理中”推断此活动。也可以在首次填写特定分类和优先级字段时记录。 采集 记录状态变为评估完成时的时间戳,或首次保存分类和优先级字段时的时间戳。 事件类型 inferred | |||
| 提出纠正措施计划 | 此活动发生在记录并提交针对已识别根本原因的正式计划以供审核时。计划列明将采取的具体纠正措施。 | ||
| 重要性 此步骤标志着流程进入解决阶段。跟踪方案提出所需的时间,可以了解团队从分析转向行动的速度。 获取途径 通常可通过创建相关的纠正措施计划记录,或将状态更改为表示方案已准备好审核的状态来记录。 采集 使用关联的纠正措施或CAPA记录的创建时间戳,或状态更改为“待批准”的时间戳。 事件类型 explicit | |||
| 有效性验证未通过 | 表示已实施的措施未能有效解决问题。此结果通常会触发新一轮调查或纠正措施流程。 | ||
| 重要性 此活动表明流程出现重大问题并产生大量返工。分析这些事件对于了解解决方案失效的原因、改进根因分析流程至关重要。 获取途径 验证未通过时会记录此活动,并导致状态更改,重新启动调查或CAPA计划。 采集 记录表示验证未通过的状态变更时间戳,例如“有效性检查未通过”或“需要重新调查”。 事件类型 explicit | |||
| 相关方已收到通知 | 表示正式向相关人员传达质量事件的处理结果,例如报告人或受影响的部门。 | ||
| 重要性 虽然并非总是核心流程步骤,但跟踪与相关方的沟通情况,有助于了解流程是否完整以及整体服务水平。 获取途径 此活动较难记录,可能需要明确记录为一项操作;也可以根据工作流中“最终通知”任务的完成情况推断。 采集 记录自动邮件通知的时间戳,或手动沟通任务标记为完成的时间戳。 事件类型 inferred | |||
| 纠正措施计划已驳回 | 表示拟议的纠正措施计划经审核后未获批准。计划需要修订并重新提交,导致流程出现返工循环。 | ||
| 重要性 此活动反映了流程中的低效和返工。驳回率较高,可能意味着要求不明确或根因分析不充分。 获取途径 通常通过状态更改为“已驳回”或“需要修订”来记录,且往往附有原因代码或评论。 采集 记录状态更改为“已驳回”或“已退回修订”的时间戳。 事件类型 explicit | |||
| 质量事件已取消 | 这是另一种终止方式:质量事件未完全解决便结束。如果事件被判定为无效、与其他记录重复或因误操作而创建,就会出现这种情况。 | ||
| 重要性 此活动表示流程以另一种非有效方式结束。取消事件数量较多,可能说明用户培训或初始数据录入环节存在问题。 获取途径 通常通过终止状态更改为“已取消”或“已作废”来记录,且往往附有相应的原因代码。 采集 记录记录状态更新为“已取消”“已作废”或“无效”的时间戳。 事件类型 explicit | |||
| 预防措施已实施 | 表示已完成旨在消除潜在不符合项根因、避免问题再次发生的任务。这是一项主动措施,通常在纠正措施之后实施。 | ||
| 重要性 此活动体现了注重预防而非仅仅纠正的成熟质量流程。跟踪预防措施的实施情况,有助于衡量长期流程改进成效。 获取途径 通常在分配的预防措施任务被标记为完成时记录,相关记录往往关联到原始质量事件。 采集 使用相关预防措施任务的完成时间戳,或预防措施记录的状态更新时间。 事件类型 explicit | |||
数据提取指南
立即开始优化质量管理
借助数据洞察识别瓶颈、提升合规水平。
无需信用卡,5分钟即可完成设置。