您的质量管理数据模板
您的质量管理数据模板
- 建议采集的属性
- 需要跟踪的关键活动
- 数据提取指南
质量管理属性
| 名称 | 说明 | ||
|---|---|---|---|
|
事件开始时间
EventStartTime
|
表示活动或事件开始时间的时间戳。 | ||
|
说明
此属性提供特定流程步骤开始的准确日期和时间,是按时间顺序排列事件并构建每个质量事件案例流程顺序的主要时间依据。 在分析中,事件开始时间对于计算周期时间、持续时间和活动间等待时间至关重要。它能突出连续步骤之间的长时间延误,帮助识别瓶颈,也可用于跟踪根本原因分析周期时间等基于时间的指标。
重要性
此时间戳是流程分析的基础,可用于所有基于时间的计算,并确保活动顺序正确。
获取途径
此时间戳通常位于与质量措施和收集计划相关的事务日志或历史表中,字段名可能为CREATION_DATE或类似名称。
示例
2023-04-15T09:00:12Z2023-04-16T11:30:00Z2023-05-01T14:22:45Z
|
|||
|
活动名称
ActivityName
|
质量管理流程中发生的具体任务或步骤的名称。 | ||
|
说明
此属性描述质量事件管理过程中发生的单个事件或采取的行动。按时间戳排序后,这些活动构成每个案例的流程。 分析活动名称是流程挖掘的核心。它有助于发现实际流程模型、与目标模型进行一致性检查,并识别特定活动之间的瓶颈或返工循环。例如,可据此衡量从“启动调查”到“完成根本原因分析”所用的时间。
重要性
此属性是绘制流程、识别偏差和了解实际工作方式的基础。
获取途径
此信息通常来自Oracle质量管理模块中的事件日志、状态变更记录或操作历史表。
示例
发现质量问题启动调查批准纠正措施计划最终审查并结案
|
|||
|
质量事件
QualityEventId
|
用于唯一标识单个质量事件的标识符,例如不符合项、投诉或偏差。 | ||
|
说明
质量事件ID是主要案例标识符,用于归集从初次报告到最终结案的所有相关活动。每起质量事件都会分配一个唯一ID,从而形成完整的调查与解决历史记录。 在流程挖掘分析中,此属性是还原每个质量事件端到端处理过程的基础。它可用于计算整体周期时间、识别流程变体,并分析不同类型事件的处理方式。将每条活动日志关联到特定质量事件ID后,分析人员便能查看完整流程,并发现系统性瓶颈或合规问题。
重要性
此ID用于界定单个案例的范围,是准确跟踪质量事件和计算端到端绩效指标的基础。
获取途径
在Oracle质量管理中,此字段通常是主要质量事件表或收集计划表的主键,例如QA_RESULTS。
示例
NC-2023-00123CAPA-45892QE-500-A
|
|||
|
严重程度
SeverityLevel
|
对质量事件影响程度的分类,例如严重、重大或轻微。 | ||
|
说明
严重程度通常在初步评估期间确定,用于评估质量问题对客户、合规或业务运营的潜在影响。此分类有助于安排资源,并确定所需响应的紧迫程度。 在流程挖掘中,此属性对于分组分析至关重要。分析人员可以比较高严重程度和低严重程度事件的流程、周期时间及结果。此属性支持“质量事件初步评估一致性”仪表板和“按严重程度划分的问题解决率”指标,帮助判断严重问题是否得到更快速、更有效的处理。
重要性
此属性支持确定优先级和划分分析范围,确保影响重大的质量事件得到有效、高效的管理。
获取途径
请参阅Oracle质量管理文档。这通常是质量收集计划中的可配置元素。
示例
1 - 严重2 - 主要3 - 次要4 - 信息
|
|||
|
事件结束时间
EventEndTime
|
表示活动或事件完成时间的时间戳。 | ||
|
说明
事件结束时间标记特定活动的完成时间。与事件开始时间结合后,可计算该活动的处理时间。在某些系统中,活动可能即时完成,此时开始时间和结束时间相同。 此属性对于详细分析持续时间至关重要。它有助于区分主动处理时间(开始到结束的时长)和等待时间(一项活动结束到下一项活动开始的时长),从而识别资源实际投入工作的环节,以及交接造成延误的环节。
重要性
此属性可精确计算活动处理时间,帮助区分低效任务和长时间等待。
获取途径
此数据可能与开始时间一样,位于事务表或历史表中,字段名有时为LAST_UPDATE_DATE或特定的完成时间戳。也可以根据后续事件的开始时间推断。
示例
2023-04-15T09:15:30Z2023-04-16T12:00:00Z2023-05-02T10:00:00Z
|
|||
|
受派用户
AssignedUser
|
负责执行某项活动或管理质量事件的用户。 | ||
|
说明
此属性指定负责特定任务或整体管理质量事件的人员,提供比负责部门更细致的信息。 按用户分析有助于了解个人工作量、发现培训需求并识别表现突出的员工。分析还可揭示工作是否经常被重新分派,或任务是否总是停滞在特定人员手中。这些信息可用于绩效管理和精细化资源优化。
重要性
此属性支持对个人工作量和绩效进行细致分析,有助于发现资源限制或培训机会。
获取途径
请查阅Oracle质量管理文档。用户分派信息通常存储在与质量事件关联的措施表或工作流表中。
示例
j.smitha.jonesr.williams
|
|||
|
当前状态
CurrentStatus
|
质量事件案例的当前状态。 | ||
|
说明
此属性表示质量事件在整个生命周期中的当前状态,例如“Open”“Under Investigation”“Pending Approval”或“Closed”。它反映数据提取时案例所处的流程阶段。 此属性对于运营监控至关重要,可直接支持“未结质量事件与状态概览”仪表板。管理人员可以快速查看当前待处理的质量问题,并合理安排资源。流程挖掘中,按最终状态筛选有助于分析不同流程路径的结果。
重要性
此属性实时呈现质量事件的处理情况,帮助有效管理运营并确定待处理案例的优先级。
获取途径
此信息通常位于质量事件的主表头表中,反映事件最近一次记录的状态。
示例
未结进行中待审批已关闭
|
|||
|
根本原因类别
RootCauseCategory
|
对质量问题已确定根本原因的分类。 | ||
|
说明
完成根本原因分析后,通常会将分析结果归入预定义类别,例如“设备故障”“人为错误”或“设计缺陷”。此属性用于记录最终分类。 按根本原因类别分析流程,有助于将关注点从修复个别症状转向解决系统性问题。例如,如果大量事件的根本原因是“培训问题”,就可以据此判断是否需要完善员工培训计划。这也是预防性措施的重要目标。
重要性
此属性有助于分析故障的根本原因,是推动质量管理从被动响应转向主动预防的关键。
获取途径
请参阅Oracle质量管理文档。这很可能是收集计划中的用户自定义元素,并在“完成根本原因分析”活动后填入。
示例
设备故障物料缺陷人为错误未遵循过程
|
|||
|
目标解决日期
TargetResolutionDate
|
质量事件最终关闭的计划日期或预期日期。 | ||
|
说明
此属性表示质量事件预计彻底解决的截止日期。它相当于服务级别协议(SLA)或内部目标,通常根据事件的严重程度或类型确定。 此日期是绩效监控的重要依据,也是计算“CAPA实施按时率”KPI的直接数据。分析人员可将各项活动的实际完成日期与目标日期进行比较,衡量处理是否及时、识别可能逾期的事件,并跟踪按时完成情况的变化趋势,从而推动缩短解决周期。
重要性
此属性为衡量按时完成情况提供基准,也是计算及时性KPI和管理SLA的必要依据。
获取途径
请参阅Oracle质量管理文档。这可能是标准日期字段,也可能是质量收集计划中的用户自定义元素。
示例
2023-05-302023-06-152024-01-10
|
|||
|
负责部门
ResponsibleDepartment
|
负责质量事件或当前活动的部门或职能团队。 | ||
|
说明
此属性标识负责处理质量事件的团队或部门,例如质量保证、工程、生产或其他团队。随着事件推进,负责方可能发生变化。 在流程挖掘中,按负责部门分析有助于了解工作量分布、发现部门瓶颈并比较不同团队的绩效。此属性支持“质量事件资源分配”仪表板,展示各部门参与的活动类型,帮助优化资源管理。
重要性
此属性支持按部门分析工作量、绩效和瓶颈,对于资源规划和组织改进至关重要。
获取途径
请查阅Oracle质量管理文档。相关数据可能存储在与质量措施或分派相关、并关联到质量事件的表中。
示例
质量工程制造运营供应商质量设计工程
|
|||
|
业务单元
BusinessUnit
|
发生质量事件或负责管理该事件的业务单元或组织部门。 | ||
|
说明
此属性将质量事件归属到业务架构中的特定部分,便于分析和比较不同组织单元的质量绩效。 大型企业通常需要按业务单元细分流程分析,以便为各业务单元创建专属仪表板,并识别哪些部门的质量流程更高效,或面临哪些独特挑战。这有助于企业层面的监督,也便于在组织内分享最佳实践。
重要性
此属性支持比较和分析组织不同部门的绩效,助力企业范围内的质量管理。
获取途径
这通常属于与交易相关的组织背景数据,通常取自用户或部门的主数据。
示例
医疗器械消费电子产品汽车零部件
|
|||
|
产品标识符
ProductIdentifier
|
与质量事件相关产品的标识符。 | ||
|
说明
此属性将质量事件关联到特定产品、物料或服务,可以是产品代码、SKU或零件编号。 这种关联对产品质量分析至关重要。您可以使用流程挖掘比较不同产品线的质量管理流程,或识别经常出现质量问题的产品,从而优先改进最需要关注的工程或制造环节。
重要性
此属性将质量事件与特定产品关联起来,便于分析产品质量趋势和流程差异。
获取途径
此信息存储在质量收集计划的字段中,通常关联到Oracle库存物料主数据。
示例
SKU-100-A-REDPN-987654CHEM-X2
|
|||
|
关闭代码
ClosureCode
|
用于表示质量事件关闭原因或结果的代码。 | ||
|
说明
质量事件关闭时,通常会分配关闭代码来标记最终结果,例如“措施有效”“无需采取措施”或“重复问题”。 此属性对结果分析很有帮助。分析人员可以按不同关闭代码筛选数据,研究哪些流程路径能带来成功结果,哪些不能。还可以回答“被标记为重复问题并关闭的事件经过了哪些流程?”等问题,并发现分流处理中的低效环节。
重要性
此属性提供案例结果的关键信息,便于分析哪些流程路径能够成功解决问题。
获取途径
请参阅Oracle质量管理文档。此字段很可能在最终关闭活动中填入。
示例
有效无需采取措施重复问题接受风险
|
|||
|
最近数据更新时间
LastDataUpdate
|
源系统最近一次数据刷新或更新的时间戳。 | ||
|
说明
此属性表示流程挖掘数据集中该事件数据的最近更新时间,反映数据的新鲜度,并帮助用户了解分析结果的时效性。 在仪表板和报告中,此时间戳为用户提供重要背景信息,说明查看的是实时数据还是某个时间点的快照。这对于做出有依据的运营决策至关重要,也能让数据的时效性一目了然。
重要性
此时间戳清晰呈现数据的新鲜度,帮助用户了解流程分析反映的是当前情况还是较早的数据。
获取途径
此值在数据ETL过程中生成并存储,通常表示数据管道最近一次成功运行的时间戳。
示例
2023-10-27T04:00:00Z2023-10-26T04:00:00Z
|
|||
|
总周期时间
TotalCycleTime
|
从发现质量问题到最终关闭所经过的总时间。 | ||
|
说明
此属性衡量单个质量事件案例从开始到结束的完整时长,计算方式为第一个活动(“发现质量问题”)与最后一个活动(“最终审核并关闭”)的时间戳之差。 这是衡量质量管理流程整体效率的核心KPI,也是“质量事件端到端周期时间”仪表板的主要指标。持续跟踪此指标,并按严重程度或问题类别等属性细分数据,可全面了解流程健康度及改进措施的影响。
重要性
这是关键KPI,用于衡量整个质量管理流程从开始到结束的整体速度和效率。
获取途径
此指标在流程挖掘的数据处理阶段按案例计算。计算时需要每个QualityEventId对应的首个事件开始时间和最后一个事件结束时间。
示例
P30DT12HP15DP92D
|
|||
|
是否按时完成
IsOnTime
|
用于标记纠正措施是否在目标解决日期前实施的标志。 | ||
|
说明
此布尔属性通过比较“实施纠正措施”活动的完成时间戳与案例的“目标解决日期”得出。若措施在目标日期当天或之前完成,则为true;否则为false。 此属性直接用于计算“CAPA实施按时率”KPI。它为每个案例提供清晰的二元分类,简化了分析和仪表板创建。您可以轻松筛选和汇总数据,监控服务级别达成情况并识别延误的根本原因。
重要性
此属性简化了目标达成情况的跟踪,便于衡量和报告这一关键KPI。
获取途径
此标志在数据转换过程中计算得出,需要TargetResolutionDate以及相关完成活动的时间戳。
示例
truefalse
|
|||
|
是否返工
IsRework
|
用于标记某项活动是否为同一案例中先前步骤的重复执行或返工。 | ||
|
说明
如果某项活动(例如“提出纠正措施计划”)在单个质量事件案例中出现多次,此布尔属性就会设为true。这表示流程中出现了循环或纠正,即已完成的步骤需要重新执行。 识别返工是流程挖掘的一项重要能力。此标志便于量化这类低效情况,并直接用于计算“活动返工频率”KPI。分析哪些步骤最容易返工,以及返工在什么情况下发生,有助于发现培训、数据质量或审批标准方面的问题,明确提升流程效率的机会。
重要性
此属性标记流程低效和循环,帮助量化浪费并找出返工的根本原因。
获取途径
此属性通过数据准备阶段对事件日志应用窗口函数或顺序分析计算得出,用于识别同一案例中多次出现的相同活动名称。
示例
truefalse
|
|||
|
源系统
SourceSystem
|
标识数据提取自哪个记录系统。 | ||
|
说明
此属性指定事件数据的来源应用程序或系统。在企业环境中,质量事件数据可能来自多个来源,例如Oracle质量管理核心模块、独立的CAPA系统或客户投诉门户。 在分析中,此字段有助于了解数据沿袭,也可用于按来源系统划分流程。它对于数据治理和排查数据集成问题至关重要,可确保流程视图准确反映整合后的数据全貌。
重要性
此属性提供重要的数据来源背景,有助于数据验证、治理以及分析不同系统间的流程差异。
获取途径
此值通常在数据提取、转换和加载(ETL)过程中作为静态值添加,用于标记数据集的来源。
示例
Oracle Quality Management R12Oracle EBS QualityQM-PROD
|
|||
|
纠正措施计划ID
CorrectiveActionPlanId
|
为解决质量事件而创建的纠正措施计划(CAPA)的唯一标识符。 | ||
|
说明
此属性将质量事件与为解决该事件而制定的具体纠正和预防措施计划直接关联起来。该计划通常是系统中的独立对象,拥有自己的生命周期。 分析时,可使用此ID将质量事件流程数据与CAPA管理流程数据关联起来,从而全面了解整个流程。您可以据此跟踪每个需要CAPA的事件是否都已分配计划,并分析措施的有效性。
重要性
此属性将问题(质量事件)与解决方案(CAPA)关联起来,便于全面分析质量管理体系的端到端流程。
获取途径
这通常是质量事件记录中的引用字段,指向CAPA专用表或模块中的记录。
示例
CAPA-2023-088CAPA-2023-091
|
|||
|
问题类别
IssueCategory
|
质量问题的类别或类型,例如“产品缺陷”或“流程偏差”。 | ||
|
说明
此属性用于对质量事件进行分类,便于归类分析相似问题。类别通常由组织根据自身运营情况定义。 按问题类别分析流程,有助于发现特定问题类型的规律。例如,分析可能显示“供应商物料”问题的周期时间远长于“内部流程”问题。按类别细分数据有助于有针对性地改进流程。
重要性
对问题进行分类,有助于针对特定问题领域开展分析,发现趋势和根本原因。
获取途径
请参阅Oracle质量管理文档。这很可能是质量收集计划中的用户自定义元素。
示例
产品缺陷流程偏差供应商物料客户投诉
|
|||
质量管理活动
| 活动 | 说明 | ||
|---|---|---|---|
|
最终审查并结案
|
此为最后一步,确认所有相关措施均已完成,并正式关闭上级质量问题。主记录的状态最终变为“Closed”或“Resolved”时,会记录此活动。 | ||
|
重要性
这是流程的主要结束事件,对于计算“平均事件周期时间”指标和衡量整体流程吞吐量至关重要。
获取途径
根据上级质量问题记录的最终状态变为“Closed”推断。该状态变化的时间戳即为事件时间。
采集
根据主要质量问题记录的状态变为“Closed”推断。
事件类型
inferred
|
|||
|
发现质量问题
|
此活动表示新建了一条质量事件记录,例如不符合项、偏差或客户投诉。用户在Oracle中新建质量问题或质量措施记录时,系统会明确记录此活动。 | ||
|
重要性
作为开始事件,此活动对于计算质量管理流程的总周期时间,以及了解新增质量事件的数量至关重要。
获取途径
此事件取自质量问题或质量措施记录的创建时间戳,相关数据可能位于QAM_QUALITY_ISSUES或QAM_QUALITY_ACTIONS等表中。
采集
新建质量问题或质量措施记录时记录的事件。
事件类型
explicit
|
|||
|
启动调查
|
此活动标志着调查阶段正式开始,目的是确定质量问题的根本原因。系统通常会通过状态变化记录此活动,例如状态变为“Under Investigation”。 | ||
|
重要性
此活动是计算“根本原因分析周期时间”指标的起点,也有助于了解问题在正式调查开始前等待了多久。
获取途径
根据质量问题记录或关联的质量措施记录状态变为“Investigation”推断。该状态变化的时间戳即为事件时间。
采集
根据状态变为“Under Investigation”或类似状态推断。
事件类型
inferred
|
|||
|
批准纠正措施计划
|
此活动表示指定审批人正式批准了拟定的纠正措施计划。这是一个关键控制点,通常通过明确的审批操作或状态变为“Approved”来记录。 | ||
|
重要性
此审批是重要里程碑,也经常成为瓶颈。分析审批耗时有助于简化流程,并确保流程符合规定。
获取途径
根据质量措施或CAPA记录的状态变为“Approved”推断。采用审批工作流的Oracle系统通常会在审计表中明确记录此变化。
采集
根据状态变为“Approved”推断。
事件类型
inferred
|
|||
|
确认措施有效
|
此活动确认已实施的纠正措施成功解决根本原因并防止问题复发。用户完成验证步骤并更新记录状态时,会记录此活动。 | ||
|
重要性
这是一个以结果为导向的关键里程碑,也是“有效性验证率”指标的依据。此活动闭合纠正措施流程,确保问题得到真正解决。
获取途径
根据CAPA记录的状态变为“Verification Complete”或“Effective”推断,也可能需要填写特定的验证结果字段。
采集
根据状态变为“Verification Complete”或“Effective”推断。
事件类型
inferred
|
|||
|
问题分类并确定优先级
|
分析人员完成初步评估并设置严重程度、优先级和问题类型等关键属性时,会发生此活动。通常可通过问题状态从“New”变为“Assessed”或“In Triage”来记录。 | ||
|
重要性
此里程碑对于“平均初步评估处理时间”指标至关重要。此处的延误可能拖慢整个问题解决流程,尤其是严重问题。
获取途径
根据质量问题记录的状态变化推断,例如从“New”变为“Under Assessment”;也可根据“Severity”或“Priority”等字段首次填写的时间推断。
采集
根据状态变化,或Severity、Priority字段首次填写的时间推断。
事件类型
inferred
|
|||
|
分派问题进行初步评估
|
此活动表示将新建的质量问题分派给特定用户或团队,以进行初步审查和评估。通常可通过跟踪质量问题记录中的受派人或所有者字段变化来推断此事件。 | ||
|
重要性
跟踪这次初始交接,有助于发现评估开始前的延误。分析问题在此状态下停留的时间,可以揭示初步评估队列中的潜在积压。
获取途径
根据质量问题记录中所有者或受派人字段的变化推断。数据可能来自审计跟踪表,也可能通过跟踪分派工作流中的状态变化获得。
采集
根据质量问题中“Assigned To”或“Owner”字段的变化推断。
事件类型
inferred
|
|||
|
完成根本原因分析
|
此活动表示根本原因分析(RCA)已完成,调查结果已记录。通常在调查团队将确定的根本原因更新到质量问题记录并更改其状态时记录。 | ||
|
重要性
此活动是“根本原因分析周期时间”指标的终点。分析到达此步骤所需的时间,有助于定位问题解决阶段的瓶颈。
获取途径
根据状态变为“RCA Complete”,或根本原因类别字段填写并保存记录时推断。使用该更新的时间戳。
采集
根据状态变为“RCA Complete”或根本原因字段填写情况推断。
事件类型
inferred
|
|||
|
提出纠正措施计划
|
定义纠正措施并将其关联到质量问题,列明解决问题所需步骤时,会发生此活动。可能是新建关联的纠正措施记录,也可能是状态变更为计划待审。 | ||
|
重要性
此活动跟踪从问题分析到方案设计的转变。通过返工指标衡量此步骤涉及的返工情况,可发现需求不明确或计划不充分等问题。
获取途径
此事件可能来自CAPA对象中新建纠正措施记录,也可能根据状态变为“Plan Proposed”或“Pending Approval”推断。
采集
根据状态变为“Pending Approval”或新建关联的纠正措施记录推断。
事件类型
inferred
|
|||
|
落实纠正措施
|
此活动标志着已完成获批纠正措施计划中列出的任务。用户将纠正措施记录的状态更新为“Implemented”或“Completed”时,通常会记录此活动。 | ||
|
重要性
此活动对于“CAPA按时实施率”指标至关重要,因为它表明计划中的整改已执行,可据此与目标日期进行比较。
获取途径
根据关联的质量措施或CAPA记录状态变为“Implemented”或“Completed”推断此事件。
采集
根据状态变为“Implemented”或“Completed”推断。
事件类型
inferred
|
|||
|
落实预防措施
|
此活动标志着已完成预防措施计划中用于降低系统性风险的任务。用户将预防措施记录的状态更新为“Implemented”或“Completed”时,会记录此活动。 | ||
|
重要性
此活动衡量组织落实主动质量改进的能力。此处的延误可能表明组织难以推动系统性变革。
获取途径
根据关联的预防措施记录状态变为“Implemented”或“Completed”推断,方式与跟踪纠正措施类似。
采集
根据预防措施记录的状态变为“Implemented”推断。
事件类型
inferred
|
|||
|
识别预防措施
|
此活动表示创建预防措施(PA),以解决系统性问题,防止类似质量事件再次发生。通常会记录新建的预防措施记录,并将其关联到原始问题。 | ||
|
重要性
此活动体现了成熟的质量流程:不仅解决单个问题,也着眼于预防未来问题。跟踪此活动有助于衡量主动质量改进情况。
获取途径
新建类型为“Preventive Action”的质量措施记录时,会记录此活动;该记录通常关联到原始质量问题或纠正措施。
采集
新建类型为“Preventive Action”的质量措施记录时记录。
事件类型
explicit
|
|||
|
通知相关方问题已解决
|
此活动表示向相关方传达质量事件的解决结果,例如报告人或受影响的客户。此活动难以直接记录,可能需要根据结案后的状态变化或已记录的评论推断。 | ||
|
重要性
此活动对于“相关方通知延迟”指标至关重要。即使问题已解决,及时沟通仍有助于提升客户满意度和内部透明度。
获取途径
此活动通常难以自动记录。可能需要根据“Notification Sent”等状态推断,或从活动或评论字段中提取记录,因此需要专门的处理逻辑。
采集
根据特定状态变化推断,也可能需要对活动日志进行文本挖掘。
事件类型
inferred
|
|||
|
需要进行有效性检查
|
此活动表示系统或用户标记已实施的措施需要后续验证,以确认其有效性。通常在措施实施后自动或手动更改状态时记录。 | ||
|
重要性
此步骤启动关键的验证阶段。了解实施措施与此活动之间的间隔,有助于发现必要的后续跟进是否延迟。
获取途径
根据工作流中质量措施的状态变为“Pending Effectiveness Check”或类似状态推断此事件。
采集
根据状态变为“Pending Effectiveness Check”推断。
事件类型
inferred
|
|||
数据提取指南
改进Oracle质量管理,立即提升合规水平
消除低效环节,将周期时间缩短30%。
无需信用卡。免费试用14天。