您的质量管理数据模板
您的质量管理数据模板
- 建议收集的属性
- 需要追踪的关键活动
- 提取指南
质量管理属性
| 名称 | 描述 | ||
|---|---|---|---|
|
质量事件
QualityEvent
|
单个质量事件的唯一标识符,例如偏差、不合格项或 CAPA。 | ||
|
描述
质量事件是主要的案件标识符,它将与特定质量问题相关的所有活动、调查和解决结果关联起来。它作为核心主线,连接了事故从最初报告到最终关闭的整个生命周期。 在流程挖掘中,此属性对于重建每个质量事件的端到端路径至关重要。通过它,可以分析不同类型事件的流程变异、周期时间和合规性,从而全面了解单个质量事故是如何被管理、调查和解决的。
为何重要
这是必不可少的案件 ID,它将所有相关活动归组为一个流程实例,从而实现端到端分析。
获取方式
这是 Veeva Vault Quality 中质量事件记录的主要标识符,通常被称为“名称”或质量事件对象上的唯一 ID 字段。
示例
QE-2023-00123CAPA-2023-00456DEV-2023-00789
|
|||
|
Event 时间
EventTime
|
记录特定活动开始或发生的时间戳。 | ||
|
描述
此属性捕获活动执行的精确日期和时间。它为案件中的所有事件提供了按时间排序的背景信息。 此 timestamp 是所有基于时间的流程挖掘分析的基础。它用于计算周期时间、活动之间的等待时间以及特定步骤的持续时间,这对于识别延误和性能瓶颈至关重要。
为何重要
此 timestamp 对于按时间顺序排列事件以及计算周期时间和等待时间等所有绩效指标至关重要。
获取方式
这对应于任务的创建日期或完成日期,或者是质量事件对象审计追踪中的事件 timestamp。
示例
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:21:05Z
|
|||
|
最后数据更新
LastDataUpdate
|
从源系统进行最后一次数据刷新或提取的时间戳。 | ||
|
描述
此属性表示正在分析的数据的时效性。它显示了数据最后一次从 Veeva Vault Quality 提取并加载到流程挖掘工具中的日期和时间。 这些信息对于用户了解分析的及时性以及仪表板是否反映了最新的运营状态至关重要。这是一个关键的数据治理属性。
为何重要
向用户传达 data 的及时性和相关性,确保他们了解流程分析的实时程度。
获取方式
此时间戳在数据提取、转换与加载(ETL)过程中生成并添加。
示例
2024-05-20T08:00:00Z2024-05-21T08:00:00Z
|
|||
|
活动名称
ActivityName
|
质量事件生命周期中发生的特定任务或步骤的名称。 | ||
|
描述
此属性描述了在质量事件管理期间发生的独特业务活动或事件。这些是流程中的步骤,例如“调查已启动”或“纠正措施计划已批准”。 分析这些活动的顺序和频率是流程挖掘的核心。它有助于发现实际流程流、识别步骤间的瓶颈并检测与标准操作程序 (SOP) 的偏差。
为何重要
它定义了流程的步骤,支持流程流向的可视化和分析。
获取方式
这通常源自 Veeva Vault Quality 中的工作流任务名称、状态更改或审计追踪条目。
示例
初始分流已完成已执行根本原因分析最终审核与关闭
|
|||
|
源系统
SourceSystem
|
提取质量管理数据的来源系统。 | ||
|
描述
此属性识别数据的来源,本案例中为 Veeva Vault Quality。它有助于数据治理并提供背景信息,尤其是当组合来自多个系统的数据时。 在分析中,它用于过滤并确保数据血缘。了解来源系统有助于正确解读数据并解决任何数据质量问题。
为何重要
提供关于数据来源的关键背景信息,这对于数据治理、追溯和多系统分析至关重要。
获取方式
这是一个静态值,应在数据转换过程中添加,以便标记来自该数据源的所有记录。
示例
Veeva Vault Quality
|
|||
|
严重性级别
SeverityLevel
|
评估的质量事件严重程度或风险等级,例如高、中、低。 | ||
|
描述
此属性根据质量事件对产品质量、患者安全或法规合规性的潜在影响对其进行分类。严重程度通常决定了调查的紧急程度和所需深度。 按严重程度进行分析是划分改进工作优先级的关键。它有助于了解高严重性事件是否需要更长时间解决、是否遵循不同的流程路径或具有更高的返工率,从而确保最关键的问题得到最多的关注。
为何重要
按影响力对 event 进行分类,支持基于风险的分析,并将流程改进重点放在高风险领域。
获取方式
这是质量事件对象上的标准分类字段,通常是源自风险矩阵的选择列表。
示例
高中低
|
|||
|
分配部门
AssignedDepartment
|
负责质量事件或相关活动的部门或职能领域。 | ||
|
描述
此属性指定负责处理质量事件或特定任务的业务单元或部门,如质量保证 (QA)、生产或研发 (R&D)。这通常源自受指派用户的个人资料。 这一维度对于高层级的绩效分析至关重要。它允许比较组织内不同部门的流程效率和合规性,有助于精准定位特定部门内的系统性问题,并支持“调查员工作负载分配”仪表板。
为何重要
允许跨不同业务部门过滤并对比流程绩效,揭示部门瓶颈或最佳实践。
获取方式
此信息通常存储在与“受指派调查员”关联的用户个人资料数据中,或者也可以是质量事件对象本身上的直接字段。
示例
质量保证制造运营研发
|
|||
|
已指派的调查员
AssignedInvestigator
|
被指派执行调查或特定任务的用户或资源。 | ||
|
描述
此属性识别在质量事件生命周期内负责执行特定活动的人员、角色或团队。它可以是质量事件本身的所有者,也可以是特定工作流任务的受指派人。 分析此属性有助于了解工作负载分配、资源绩效,并识别负担过重的团队或个人。它对于“调查员工作负载分配”仪表板以及优化资源分配以提高效率至关重要。
为何重要
追踪工作执行者,从而分析工作负载、资源效率并识别培训需求。
获取方式
位于 Veeva Vault Quality 质量 event 对象或其相关 workflow 任务对象的所有者或被指派用户字段中。
示例
爱丽丝·约翰逊鲍勃·威廉姆斯质量保证 (QA) 调查团队
|
|||
|
活动时长
ActivityDuration
|
单个活动的执行时间。 | ||
|
描述
该指标衡量主动处理任务所花费的时间。它的计算方式是活动的 EndTime 与 StartTime 之差。 分析活动持续时间有助于精准定位流程中哪些特定步骤最耗时。这与等待时间不同,因为它反映了实际的工作量。它是识别单个任务内部低效环节以及进行资源产能规划的关键指标。
为何重要
衡量任务的实际工作时间,有助于识别低效活动以及自动化或简化流程的机会。
获取方式
这是一个计算指标,通过从每个活动的 'EndTime' 中减去 'EventTime' (StartTime) 得出。
示例
2 hours 30 minutes45分钟8小时15分钟
|
|||
|
目标解决日期
TargetResolutionDate
|
质量事件最终关闭的计划日期或要求日期。 | ||
|
描述
此属性定义了解决质量事件的服务水平协议 (SLA) 或目标截止日期。它通常根据事件的创建日期及其严重程度或类型计算得出。 此日期是衡量实际绩效的基准。它对于“按时解决绩效”仪表板和“按时解决率”KPI 至关重要,有助于识别事件是否得到及时解决以及哪些因素导致了延迟。
为何重要
定义 case 解决的 SLA,支持按时绩效的衡量和延误原因分析。
获取方式
这很可能是质量事件对象上的一个日期字段,可能是手动输入或由系统自动计算的。
示例
2024-01-15T23:59:59Z2024-02-28T23:59:59Z2024-03-10T23:59:59Z
|
|||
|
结束时间
EndTime
|
指示活动完成时的时间戳。 | ||
|
描述
此属性捕获特定活动或任务结束的日期和时间。它与 StartTime(事件时间)不同,对于了解流程中各个步骤的持续时间至关重要。 在流程挖掘中,EndTime 与 StartTime 结合使用以计算活动的执行时间。这对于识别哪些特定任务耗时最长、从而导致整体周期延长和潜在延迟至关重要。
为何重要
支持计算活动处理时间,这对于识别任务层级的瓶颈至关重要。
获取方式
此 timestamp 通常可以在质量事件的工作流历史记录或审计追踪数据中找到,通常表现为特定任务或状态的“完成日期”或“修改时间”字段。
示例
2023-10-26T11:30:00Z2023-11-01T18:00:10Z2023-11-15T09:45:00Z
|
|||
|
质量事件状态
QualityEventStatus
|
质量事件当前的生命周期状态。 | ||
|
描述
此属性指示质量事件的当前状态,例如“打开”、“调查中”、“待审批”或“已关闭”。它提供了每个案件在其生命周期中所处位置的快照。 这对于“质量事件进度概览”仪表板至关重要,能够实现对进行中案件的实时监控。它协助经理跟踪进度、识别停滞事件并有效管理整体工作负载。
为何重要
提供案件当前状态的快照,这对于监控进行中的工作和识别停滞事件至关重要。
获取方式
这是 Veeva Vault Quality 中质量事件对象上的一个标准字段,反映了其在生命周期中的位置。
示例
分流中调查中CAPA 已提议已结案
|
|||
|
质量事件类型
QualityEventType
|
质量事件的分类,例如 CAPA、偏差或投诉。 | ||
|
描述
此属性根据质量事件的性质对其进行分类。不同类型的质量事件通常遵循不同的流程路径,并具有不同的合规性要求和解决时间线。 按事件类型分析是理解流程差异的基础。例如,它允许比较处理“偏差”与处理“CAPA”的绩效和效率,并有助于针对特定的流程背景制定改进措施。
为何重要
区分不同类型的质量流程,这些流程通常具有独特的 workflow、SLA 和合规规则。
获取方式
这是 Veeva Vault Quality 中质量事件对象上的标准分类字段,通常是一个选择列表。
示例
偏差纠正与预防措施 (CAPA)不合格项投诉
|
|||
|
产品
Product
|
与质量事件相关的产品或材料。 | ||
|
描述
此属性将质量事件链接到特定的产品、材料或批次。这种关联在受监管行业中对于追溯和影响分析至关重要。 按产品分析质量事件有助于识别某些产品是否更容易出现问题,从而指导产品改进或生产流程调整。它允许过滤仪表板以查看特定产品线的绩效。
为何重要
将质量事件与具体产品关联,以便通过分析识别特定产品的问题和趋势。
获取方式
这通常是质量事件对象上的一个引用字段,链接到 Veeva Vault 中的产品或材料对象。
示例
产品 A-100产品 B-200原材料 C-300
|
|||
|
周期时间
CycleTime
|
从质量事件创建到最终关闭所经历的总时长。 | ||
|
描述
此指标代表解决质量事件的端到端时长。它的计算方式是第一个活动(如“质量事件已创建”)与最后一个活动(如“最终审查与关闭”)之间的时间差。 周期时间是衡量整体流程效率的首要关键绩效指标。它在“质量事件解决时间”仪表板中用于分析趋势、识别导致解决时间过长的因素,并为流程改进设定基准。
为何重要
衡量端到端流程效率,为追踪整体绩效和改进措施的影响提供关键 KPI。
获取方式
这是一个计算指标。它是通过在案件级别用最后一个事件的 timestamp 减去第一个事件的 timestamp 得出的。
示例
30 天 12 小时65天4小时15天2小时
|
|||
|
审批耗时
ApprovalTime
|
完成特定审批活动所花费的时间。 | ||
|
描述
该指标衡量审批步骤的持续时间,如“纠正措施计划已批准”。它的计算方式是从请求审批到获得批准或被拒绝的时间。 此属性专为支持“审批工作流瓶颈”仪表板和“审批工作流周期时间”KPI 而设计。通过隔离等待审批所花费的时间,它有助于识别并解决由于决策缓慢或审批流程低效导致的延迟。
为何重要
精准定位关键决策步骤中的延迟,协助优化审批工作流并缩短整体周期。
获取方式
该指标是通过查找事件日志中审批相关活动开始和结束之间的时间差计算得出的。
示例
3 days 4 hours1天0小时7天8小时
|
|||
|
工作地点
Site
|
质量事件发生或被发现的制造站点、工厂或位置。 | ||
|
描述
此属性指定与质量事件相关的物理位置,例如制造工厂或实验室。它为问题提供了地理或组织背景。 这是一个用于对比分析的强大维度,允许管理层比较不同站点的流程绩效、问题类型和解决时间。它可以帮助识别站点特有的问题,或分享来自高效站点的最佳实践。
为何重要
提供地理或组织维度的分析,有助于比较不同地点的绩效并识别特定站点的问题。
获取方式
这通常是质量事件对象上的一个标准字段,链接到公司站点或位置列表。
示例
站点 A - 新泽西站点 B - 爱尔兰站点 C - 瑞士
|
|||
|
效力检查结果
EffectivenessCheckResult
|
用于确认纠正措施是否有效的验证步骤结果。 | ||
|
描述
此属性记录效能检查的结果,该检查在纠正措施实施后进行。结果通常为“有效”或“无效”。 这是对 CAPA 流程成功的直接衡量,对于“CAPA 有效性与复发率”仪表板和“CAPA 有效性率”KPI 至关重要。它提供了关于实施的解决方案是否真正防止问题再次发生的明确反馈。
为何重要
直接衡量纠正措施的成功率,为改进问题解决流程提供关键反馈。
获取方式
这可能是一个字段,很可能是与主要质量事件相关的 CAPA 行动或效能检查对象上的选择列表。
示例
有效无效待验证
|
|||
|
是否再次发生
IsRecurrence
|
一个标记,用于指示该质量 event 是否为之前已识别问题的再次发生。 | ||
|
描述
此布尔属性信号表明质量事件不是一个新的、唯一的问题,而是之前发生过的问题的重复。这是之前纠正措施失效的关键指标。 该标记对于“CAPA 有效性与复发率”仪表板至关重要。追踪复发情况可提供关于质量管理体系长期成功的直接反馈,并有助于识别尚未得到充分解决的系统性问题。
为何重要
标注纠正措施中的失败项,支持分析问题重复发生的原因以及如何改进长期解决方案。
获取方式
这可以是质量事件对象上的一个复选框字段,或者是基于与之前类似事件链接的派生字段。
示例
truefalse
|
|||
|
是否按时结案
IsOnTimeResolution
|
一个计算标记,用于指示质量 event 是否在目标日期前关闭。 | ||
|
描述
此布尔属性是通过比较质量事件的实际关闭日期与其“目标解决日期”推导出来的。它为按时绩效提供了一个简单的二元结果。 该标记是“按时解决绩效”仪表板和“按时解决率”KPI 的基础。它允许进行简单的汇总和过滤,以了解哪些类型的事件、部门或站点在满足截止日期方面存在困难。
为何重要
为是否按期完成提供清晰的成功或失败衡量指标,简化绩效分析和报表工作。
获取方式
通过对比“最终审核与关闭”活动的 timestamp 与“TargetResolutionDate”属性计算得出。公式:关闭时间 <= 目标解决日期。
示例
truefalse
|
|||
|
是否返工
IsRework
|
一个计算标记,用于识别代表返工的活动或 case。 | ||
|
描述
此属性是一个布尔值标记,表示特定活动或活动序列代表了“返工”,例如重复调查或重新打开已关闭的 CAPA。这不是标准字段,而是根据流程模式计算得出的。 在流程挖掘中,此标记用于量化流程中浪费的精力和成本。它对于“返工分析”仪表板和“质量事件返工率”KPI 至关重要,有助于精准定位导致效率低下和初次质量不合格的原因。
为何重要
通过标记重复工作来量化流程的低效程度,这有助于识别质量问题的根本原因和不必要的资源浪费。
获取方式
此属性并非直接获取。它是在数据转换期间,通过检测给定案件流程中重复的活动名称或循环计算得出的。
示例
truefalse
|
|||
|
根因
RootCause
|
已识别出的质量事件深层原因。 | ||
|
描述
此属性包含根本原因分析 (RCA) 调查的最终结论。它对质量问题的根本原因进行分类,如设备故障、人为错误或程序缺陷。 分析根本原因对于有效解决问题至关重要。它有助于识别需要通过纠正和预防措施解决的经常性系统性问题。此属性直接支持“根本原因分析周期时间”和“CAPA 有效性”仪表板。
为何重要
对质量问题的根本原因进行分类,助力通过战略分析防止未来再次发生。
获取方式
这通常是质量事件对象或相关的根本原因分析对象上的文本字段或选择列表。
示例
设备故障程序错误培训不足材料缺陷
|
|||
质量管理活动
| 活动 | 描述 | ||
|---|---|---|---|
|
最终审核与关闭
|
代表质量事件记录在正式关闭前的最后一次行政审查。此步骤确保所有文档完整且遵循了所有流程步骤。该活动是案件被视为已解决之前的最后一步。 | ||
|
为何重要
此结束活动对于计算总“质量事件周期时间”至关重要。它标志着所有工作的完成,系统会将其 timestamp 与“目标解决日期”进行对比以衡量绩效。
获取方式
推导自质量 event 对象上生命周期状态的变更,例如变为“已关闭”、“已解决”或类似的最终状态。
捕获
源自最终变更为“已关闭”状态的 timestamp。
事件类型
inferred
|
|||
|
已执行根本原因分析
|
代表根本原因分析 (RCA) 阶段的完成,即已识别出质量事件的深层原因。通常在调查员完成 RCA 任务或将事件移至“待 CAPA”状态时记录此信息。 | ||
|
为何重要
此活动对于衡量“平均根本原因分析时间”KPI 至关重要。分析其持续时间有助于识别分析过程中的瓶颈并提高调查质量。
获取方式
通常根据质量事件对象的生命周期状态更改推断得出,例如变更为“RCA 已完成”或“待行动计划”。它也可能对应于特定工作流任务的完成。
捕获
源自状态变更 timestamp 或 RCA 相关任务的完成时间。
事件类型
inferred
|
|||
|
纠正措施已实施
|
代表已完成核准的纠正措施计划中定义的所有任务。此活动确认已采取必要行动解决根本原因。当 CAPA 记录的状态更新为“实施完成”时,系统会捕获此信息。 | ||
|
为何重要
这是一个重要的里程碑,标志着从计划到执行的转变。此步骤与 CAPA 批准之间的时间反映了实施阶段的效率。
获取方式
推导自关联 CAPA 对象上生命周期状态的变更,例如变为“已实施”或“待效力检查”。
捕获
源自关联 CAPA 对象上的状态变更 timestamp。
事件类型
inferred
|
|||
|
纠正措施计划已批准
|
标志着相关利益相关者(如质量评审委员会)正式批准拟定的纠正措施计划。这是实施任何纠正措施之前的关键关卡。当 CAPA 计划记录变更为“已批准”状态时,系统会捕获此事件。 | ||
|
为何重要
此审批步骤通常是主要的瓶颈。衡量该活动的“审批工作流周期时间”有助于识别并处理审查过程中的延迟,从而加快整体解决进度。
获取方式
推导自关联 CAPA 计划对象上生命周期状态变更为“已批准”的 timestamp。此 event 可能会同步体现为父级质量 event 的状态变更。
捕获
源自关联 CAPA 计划对象上的状态变更 timestamp。
事件类型
inferred
|
|||
|
行动效力已验证
|
此活动确认所实施的纠正措施已成功防止问题再次发生。系统会完成正式验证并记录在案。当 CAPA 或质量事件状态更新为“效能已验证”时,系统会捕获此信息。 | ||
|
为何重要
这是对解决方案成功的最终验证,对于计算“CAPA 有效性率”至关重要。在此阶段的失败通常会导致返工,即重新启动调查。
获取方式
推导自质量 event 或 CAPA 对象上生命周期状态的变更,例如变为“已验证”或“已关闭 - 有效”。
捕获
源自指示验证成功的状态变更 timestamp。
事件类型
inferred
|
|||
|
调查已启动
|
标志着针对质量事件根本原因调查的正式开始。通常会指派一名调查员或团队,事件随之进入活跃的调查阶段。当质量事件的生命周期状态变更为“调查中”时,系统会捕获此事件。 | ||
|
为何重要
这是衡量“问题识别到调查时间”KPI 的关键里程碑。此时间点之前的延迟表明在分配资源或启动关键分析方面存在积压。
获取方式
推导自质量 event 对象的生命周期状态更新为“调查中”或类似状态时的 timestamp。指派调查员的操作也可作为触发信号。
捕获
使用状态更改为“调查中”的 timestamp。
事件类型
inferred
|
|||
|
质量事件已创建
|
这是流程的起点,代表了在 Veeva 中正式创建质量事件记录。当识别到新的质量问题、不合格项或投诉并将其录入系统时,通常会触发此活动。 | ||
|
为何重要
此活动标志着案件生命周期的开始,对于计算总质量事件周期时间以及衡量初始流程阶段(如启动调查的时间)的持续时间至关重要。
获取方式
这是一个从 Veeva Vault 中质量事件对象的创建 timestamp 中捕获的显式事件。该对象的审计追踪将显示准确的创建日期、时间和用户。
捕获
使用主质量事件记录的创建 timestamp。
事件类型
explicit
|
|||
|
初始分流已完成
|
代表质量事件初始审查和评估的完成。在此阶段,会收集并核实基本信息,以确定事件的有效性和即时影响。通常在记录状态从“新建”更改为“评估中”或类似状态时捕获此信息。 | ||
|
为何重要
分析分流(triage)环节所花费的时间有助于识别质量 event 初始处理阶段的延误,并为流程起点的资源分配和工作负载提供洞察。
获取方式
推导自质量 event 对象生命周期状态更新以反映分流完成时的 timestamp,例如从“新建”变更为“评估中”或“已分流”。
捕获
源自质量 event 对象上的状态变更 timestamp。
事件类型
inferred
|
|||
|
启动效力检查
|
标志着开始对已实施纠正措施的有效性进行监控。这并非一个时间点事件,而是验证阶段的开始。当质量事件或 CAPA 记录进入“监控中”或“待效能验证”状态时,系统会捕获此事件。 | ||
|
为何重要
此活动启动了最终验证循环。效能检查阶段的持续时间对于了解确认解决方案成功所需的时间非常重要。
获取方式
推导自质量 event 或 CAPA 对象上生命周期状态的变更,例如变为“效力审查中”。
捕获
源自状态变更为监控相关状态的 timestamp。
事件类型
inferred
|
|||
|
已识别预防措施
|
当识别出旨在应对未来潜在复发问题的预防措施时(通常是调查的结果),会发生此活动。通过创建链接到该质量事件的预防措施 (PA) 记录来捕获此信息。 | ||
|
为何重要
虽然并非每个案例都包含此活动,但对其进行跟踪有助于了解质量流程的主动性。这能深入洞察组织是更注重长期预防,还是更侧重于即时纠正。
获取方式
推导自 Veeva Vault 中关联的预防措施记录的创建 timestamp。
捕获
使用链接的预防措施记录的创建 timestamp。
事件类型
inferred
|
|||
|
已通知利益相关者解决结果
|
此活动代表向相关利益相关者发送的通知,告知他们质量事件的解决情况。这可能是由最终关闭步骤触发的自动电子邮件通知,也可能是手动记录的沟通任务。 | ||
|
为何重要
及时沟通是利益相关者满意度和流程透明度的关键。此活动允许衡量“利益相关者通知滞后时间”KPI,从而突出显示沟通中的延迟。
获取方式
如果 Veeva Vault 发送了记录在案的自动通知,这可能是一个显式事件。或者,也可以从手动“通知利益相关者”工作流任务的完成中推断出来。
捕获
源自系统通知日志或沟通任务的完成 timestamp。
事件类型
explicit
|
|||
|
纠正措施计划已提议
|
当针对已识别根本原因的正式纠正计划被起草并提交审查时,会发生此活动。这通常涉及创建一个链接到该质量事件的相关 CAPA(纠正和预防措施)记录。当 CAPA 记录创建或质量事件状态更新时,系统会捕获此事件。 | ||
|
为何重要
跟踪此步骤有助于分析从分析到方案设计所需的时间。它是了解从 RCA 完成到 CAPA 拟定这一“根本原因分析周期时间”的关键输入。
获取方式
这可以从质量事件对象到“待 CAPA 审批”的生命周期状态更改中推断出来,或者根据链接的 CAPA 计划记录的创建 timestamp 确定。
捕获
使用链接的 CAPA 记录的创建 timestamp 或状态更改。
事件类型
inferred
|
|||
|
问题已分类并定级
|
此活动标志着质量事件已正式按类型、严重程度和优先级进行分类。这是决定后续调查路径和时间线的关键步骤。通常通过反映分类完成的状态更改来捕获此信息。 | ||
|
为何重要
此事件对于按事件严重程度或类型细分流程分析至关重要。它有助于了解高优先级问题是否比低优先级问题处理得更快,并确保资源得到有效分配。
获取方式
推导自质量 event 对象上的生命周期状态变更,例如进入“已分类”或“待调查”状态。也可推导自填充关键分类字段时的 timestamp。
捕获
推导自状态变更或“严重程度”和“优先级”等字段的填充。
事件类型
inferred
|
|||