数据模板:事件管理

ServiceNow 问题管理
数据模板:事件管理

事件管理数据模板

本模板提供采集事件管理流程分析与优化所需数据的完整指引。内容涵盖需收集的核心数据属性、需要跟踪的关键活动,以及如何从源系统抽取这些信息的实操建议。借助此资源,构建可靠的事件日志,支持深入的流程分析与改进。
  • 建议收集的属性
  • 需要追踪的关键活动
  • ServiceNow问题管理数据抽取指南
不熟悉事件日志?了解 如何创建流程挖掘事件日志.

事件管理属性

以下为建议纳入事件日志的数据字段,用于全面分析事件管理流程。
5 必填 4 推荐 11 可选
名称 描述
Event 时间
EventTime
标识该活动发生时间的精确时间戳。
描述

事件时间(timestamp)记录某个活动完成或状态变化发生的准确日期与时间。在ServiceNow中,审计轨迹里每次变更通常会写入sys_updated_on字段。

该属性是正确排序事件及所有基于时间分析的基础。它用于计算周期时长、排队时长以及活动间的持续时间,帮助识别瓶颈、衡量SLA绩效并评估流程效率。时间戳的准确性直接关系到所有基于时长度量的有效性。

为何重要

该时间戳用于按时间顺序排列所有活动,并支持计算各类以时长为基础的指标,如周期时间和瓶颈分析。

获取方式

使用 ServiceNow sys_audit 表中的 sys_created_on 字段,或 incident 表中的 sys_updated_on 字段,作为最终状态的时间戳。

示例
2023-04-15T10:05:21Z2023-04-15T11:22:00Z2023-04-16T09:00:30Z
事件ID
IncidentId
每条事件记录的唯一标识,是跟踪完整生命周期的主键。
描述

Incident ID(事件编号)是 ServiceNow 中为每条报障事件分配的唯一参考号。它作为核心案例标识,从事件创建到关闭,串联所有相关活动、更新与沟通。

在流程挖掘分析中,该 ID 至关重要。它让工具得以拼接每个案例的事件序列,构成发现流程图、分析变体与计算端到端时长的基础。没有唯一的 Incident ID,便无法追踪事件在解决流程中的完整轨迹。

为何重要

这是连接某个事件生命周期内所有活动的关键Case ID,使端到端流程分析成为可能。

获取方式

ServiceNow incident 表,字段 number。

示例
INC0010001INC0010045INC0010239
活动名称
ActivityName
在事件生命周期某一时间点发生的特定事件或任务的名称。
描述

“Activity Name”描述事件管理流程中的具体步骤或状态变更,例如 'Incident Created'、'Assigned To Agent' 或 'Incident Closed'。这些数据通常来源于关键字段(如 'State' 或 'Assignment Group')的变更,或特定日志记录。

此属性对构建流程图至关重要。它定义流程图中的节点,帮助分析人员可视化事件流转、识别常见路径、发现活动之间的瓶颈,并分析流程变体。活动名称的粒度与准确性将直接影响流程分析的质量。

为何重要

用于界定流程图中的步骤,是所有流程挖掘分析与可视化的基础。

获取方式

这是一个派生属性,通常由数据转换逻辑基于sys_audit或incident表中state、assignment_group、assigned_to等字段的变更生成。

示例
事件已创建指派组已变更已提出解决方案事件已关闭
最后数据更新
LastDataUpdate
指示此 record 数据上次从源系统刷新的 timestamp。
描述

该属性记录最近一次从ServiceNow抽取或更新数据的日期与时间。它是反映被分析数据新鲜度的元数据字段,而非流程中的事件。

此信息对理解分析的时效性至关重要。它告知用户数据的最新程度,对运营类仪表板以及基于近期事件做决策尤为重要,同时也有助于管理对数据相关性与新近性的预期。

为何重要

告知数据的新鲜度,这对分析的相关性与准确性至关重要。

获取方式

该时间戳由数据加载时的数据抽取工具或流程生成并写入。

示例
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
源系统
SourceSystem
该数据的来源系统。
描述

该属性用于指明事件数据的来源,此处为ServiceNow Problem Management。它通常是在数据抽取与转换过程中添加的静态值。

当来自多个系统的数据被整合分析时,此字段对数据血缘与数据隔离至关重要。它确保指标与流程在正确的上下文中被分析,并便于在不同来源系统之间进行流程对比。

为何重要

提供数据来源的关键信息,确保数据血缘可追溯,并便于在多系统环境中正确解读。

获取方式

通常是在数据抽取过程中添加的静态值。

示例
ServiceNow 问题管理ServiceNow
事件状态
IncidentState
事件在其生命周期中的当前状态。
描述

“Incident State”表示事件所处阶段,例如 'New'、'In Progress'、'On Hold' 或 'Resolved'。在流程挖掘的事件日志中,状态变更通常是生成活动的主要来源。

分析每个状态的停留时长是识别瓶颈的有力方式。例如,'On Hold' 停留过久可能表示受外部因素或用户影响。状态变更的先后顺序也构成流程图的基础,展示事件如何逐步走向解决。

为何重要

跟踪事件进度,是分析各阶段耗时与识别流程瓶颈的关键。

获取方式

ServiceNow incident 表,字段 incident_state 或 state。

示例
新建进行中等待用户提供信息已解决已结案
优先级
Priority
事件的优先级,用于确定响应的紧急程度。
描述

优先级是ServiceNow中的关键字段,用于决定事件处理的先后顺序与速度。它通常由事件的影响与紧急程度推导而来,并直接影响SLA目标。

该属性是分段分析与绩效评估的基础。“SLA合规概览”仪表板会基于优先级评估高优先级事件是否在目标时间内得到解决。按优先级分析处理时长有助于确认关键事件确实比一般事件处理得更快。几乎所有KPI与仪表板都离不开这一维度。

为何重要

可按业务重要性对事件进行分级,这对监控SLA达标与资源分配至关重要。

获取方式

ServiceNow incident 表,字段 priority。

示例
1 - 紧急2 - 高3 - 中等4 - 低
分配给
AssignedTo
当前被指派处理该事件的处理人。
描述

该属性用于标识在某一时间点上对该事件负责的具体支持坐席。这对于了解工作负载分布、坐席绩效以及个体间的交接情况至关重要。

在分析中,'Assigned To'有助于可视化资源分配并识别负载过重的坐席。它也被用于交接与转派类仪表板,用以跟踪事件更换个人负责人的次数,这往往是低效或知识缺口的信号。按坐席分析解决时长还能识别表现优秀者以及需要额外培训的成员。

为何重要

可分析坐席工作量、绩效与个人交接情况,是理解资源效率的关键。

获取方式

ServiceNow incident 表,字段 assigned_to。

示例
Beth AnglinDavid LooHoward Johnson
指派组
AssignmentGroup
负责处理该事件的支持团队或小组。
描述

“Assignment Group”表示负责处理该事件的支持团队。事件常在不同团队间流转,例如从一级服务台转至二级网络专业团队。

该属性对于分析跨团队移交与识别系统性瓶颈至关重要。“移交与重分派率”仪表板高度依赖此数据,用于展示哪些团队频繁参与转派。它还能支持不同支持组之间的绩效对比,帮助定位组织内的解决能力所在。

为何重要

用于记录负责团队,便于分析团队绩效、工作负载以及跨组交接情况。

获取方式

ServiceNow incident 表,字段 assignment_group。

示例
服务台网络支持数据库管理员
SLA 到期日期
SlaDueDate
根据SLA约定,该事件预期应完成解决的目标日期和时间。
描述

SLA到期时间是一个计算得出的时间戳,表示事件的最晚解决期限。该时间由与事件特征(如优先级)相关的服务级别协议(SLA)决定。

此属性是'SLA Compliance Overview'仪表板和'Critical Incident SLA Breach Rate' KPI的关键依据。它作为对照基准,用于与实际解决时间进行比较。分析临近SLA到期的事件,有助于主动升级和合理排定优先级。

为何重要

定义解决目标,便于衡量SLA达标情况并识别存在违约风险的事件。

获取方式

该值通常位于task_sla表(与incident表相关)中,关联的时间戳字段为planned_end_time。

示例
2023-05-20T17:00:00Z2023-06-01T09:00:00Z
严重性
Severity
该事件对业务造成的影响程度。
描述

“严重性”表示事件对业务运营的影响程度。通常会与“紧急性”一起,用于自动计算事件优先级。

在分析中,严重性是“SLA 合规概览”仪表板的关键维度,帮助组织判断影响最大的事件是否满足服务水平要求。它从业务视角呈现绩效,与“优先级”所体现的运维视角相互补充。

为何重要

衡量事件的业务影响,为优先级取舍与关键问题绩效分析提供重要维度。

获取方式

ServiceNow incident 表,字段 severity。

示例
1 - 高2 - 中等3 - 低
周期时间
CycleTime
从事件创建到关闭的总用时。
描述

周期时长(Cycle Time)是一个计算型指标,表示单个案例的事件管理流程端到端耗时。通常计算为“Closed”时间戳减去“Created”时间戳。

这是流程挖掘中最基础的KPI之一,直接支撑“事件解决周期时长”仪表板。分析平均周期时长及其分布,有助于衡量整体效率、设定绩效基线,并识别流程变更的影响。按优先级或类别等属性切片,可发现哪些类型的事件耗时最长。

为何重要

该核心KPI用于衡量流程的端到端效率,用来识别长周期工单并跟踪整体绩效。

获取方式

对每个Incident ID,用最后一个事件的时间戳减去第一个事件的时间戳。

示例
2592008640001209600
是否发生SLA违约
IsSlaBreached
指示事件解决是否超过其SLA到期时间的标记。
描述

这是一个计算得到的布尔属性,用于标记事件是否已违反服务级别协议。它通过对比实际解决的时间戳与'SLA Due Date'得出;若解决时间晚于到期时间,则置为true。

此属性是'SLA Compliance Overview'仪表板及相关KPI的基础。它将复杂的时间比较简化为易筛选的真/假维度,便于过滤所有违约事件并分析其共性,如类别、分配组或优先级等。

为何重要

简化SLA合规分析,便于快速筛选并深入分析所有未达标的事件。

获取方式

通过比较“Resolved At”时间戳与“SlaDueDate”时间戳计算。(Resolved At > SlaDueDate)

示例
truefalse
是否重新打开
IsReopened
指示事件在解决后是否重新打开的标记。
描述

如果某事件在达到'Resolved'或'Closed'状态后又被改回活动状态(如'In Progress'),则该布尔标记置为true。通常可在事件日志中查找'Incident Reopened'活动来识别此情况。

被重开的事件通常表明解决不完整或无效。对这些工单的分析有助于发现过早关闭或未一次性修复的反复性问题。较高的重开率会影响用户满意度并拖累团队产能,是质量管控的重要指标。

为何重要

该标记用于识别解决流程中的失败,突出显示那些被认为已解决但仍需追加处理的事件。

获取方式

通过检查每个事件的活动序列,判断在“resolved”状态之后是否出现“open”状态。

示例
truefalse
来电人
CallerId
最初报告该事件的用户。
描述

“Caller”用于标识受该事件影响并发起报障的终端用户或客户,提供受服务中断影响对象的背景信息。

虽然它并非总是流程本身的核心,但按报告人分析事件可揭示是否有特定个人或部门受到不成比例的影响,从而指向培训需求或局部环境问题。同时,它也为满意度调查与沟通提供了直连渠道。

为何重要

识别受影响的用户,可按部门或个人开展分析,并为用户沟通提供背景。

获取方式

ServiceNow incident 表,字段 caller_id。

示例
Abel TuterCarolina PashDon Goodliffe
类别
Category
事件的高层分类,例如硬件、软件或网络。
描述

“Category”为事件性质提供宏观分类,通常与子类配合,用于将事件路由到合适的支持团队,并支撑报表与趋势分析。

在流程挖掘中,此属性是“事件分类准确率”和“重复发生事件量”仪表板的关键。通过分析流程中途被改分类的事件,组织可识别初始分诊问题。按类别筛选流程图,还能看出某些类型的事件是否存在不同的解决路径或独特瓶颈。

为何重要

可分析事件类型,帮助衡量分类准确度,并对路由与趋势分析至关重要。

获取方式

ServiceNow incident 表,字段 category。

示例
硬件软件网络数据库
解决代码
ResolutionCode
用于表示事件最终解决方式的代码。
描述

“解决代码”用于说明所采取解决方案的类型,例如由用户自行解决、因已知错误而解决,或提供了临时变通方案。该字段通常由坐席在关闭事件时填写。

此属性直接支持'Resolution Type Effectiveness'仪表板,可分析采用永久修复与临时变通方案关闭的事件占比,这是衡量服务质量与长期稳定性的关键指标。变通方案占比过高,可能说明底层问题尚未得到有效根治。

为何重要

明确解决方式,便于区分永久修复与临时变通方案,并支持根因分析。

获取方式

ServiceNow incident 表,字段 close_code 或自定义的解决代码字段。

示例
已解决(临时方案)已永久解决未解决(用户取消)已知错误
配置项
ConfigurationItem
受该事件影响的具体IT组件、服务或资产。
描述

配置项(CI)是来自配置管理数据库(CMDB)的、受该事件影响的资产,可能是服务器、应用、笔记本电脑或网络设备。

按 CI 分析事件有助于识别不稳定的资产或服务,定位 IT 基础设施中事件高发的部分,从而指导升级或替换投资。在流程挖掘中,按 CI 筛选还能揭示与关键应用相关的事件是否被区别对待,或处理得更高效。

为何重要

识别受影响的资产,帮助定位IT基础设施中的问题组件,聚焦改进重点。

获取方式

ServiceNow incident 表,字段 cmdb_ci。

示例
SAP ERP 生产环境Oracle DB Server 05邮件服务
重新分配次数
ReassignmentCount
该事件被重新分派给不同组或人员的次数。
描述

该字段统计事件在不同分配组之间被转派的总次数。它直接反映流程摩擦,常被用作关键绩效指标。

此属性是'Handoff and Reassignment Rate' 仪表板和'Average Handoffs per Incident' KPI的主要驱动因素。转派次数过高往往意味着初始路由不正确、某级支持缺乏所需技能,或流程责任不清。降低此次数是常见的流程改进目标,通常也会带来更短的解决时间。

为何重要

该指标直接衡量流程交接情况,是低效、路由不当以及改进机会的关键信号。

获取方式

ServiceNow incident 表,字段 reassignment_count。

示例
0135
问题ID
ProblemId
如果该事件关联到更大范围的问题,此字段为关联的 Problem(问题)记录的标识符。
描述

“问题ID”用于将事件与问题管理模块中的对应记录关联。当确认某个事件是影响多个用户或服务的更大潜在问题的一个症状时,会建立此关联。

这种关联对'Recurring Incident Volume'仪表板和'Recurring Incident Rate' KPI至关重要。它便于分析师将同一根因导致的事件归组,衡量问题的整体影响,并跟踪问题解决的成效。大量事件被关联到问题,通常意味着支持模式偏向被动响应。

为何重要

将事件关联到根因,是分析重复问题与衡量问题管理成效的关键。

获取方式

ServiceNow incident 表,字段 problem_id。

示例
PRB0040001PRB0040015PRB0040102
必填 推荐 可选

事件管理活动

为实现准确的流程发现与优化,事件日志应记录的关键步骤和里程碑如下。
6 推荐 7 可选
活动 描述
事件已关闭
这是生命周期中的最终活动,表示该事件已完全解决并确认,无需进一步处理。该活动通过关闭时间戳记录。
为何重要

作为明确的结束事件,此活动用于计算事件全生命周期时长,并分析解决后的收尾处理耗时。

获取方式

在 'incident' 表中,'closed_at' 时间戳作为明确的事件时间。通常在 'state' 字段变为 'Closed' 时设置。

捕获

使用事件记录中的'closed_at'时间戳。

事件类型 explicit
事件已创建
当新事件在 ServiceNow 中被正式登记时,标志着事件生命周期的开始。此事件可通过事件记录的创建时间戳明确捕获。
为何重要

这是流程的主要起始事件。从此活动到解决的耗时是衡量整体周期时间与SLA合规性的基础。

获取方式

在 'incident' 表中,'sys_created_on' 时间戳用作此活动的明确事件时间。

捕获

使用事件记录中的'sys_created_on'时间戳。

事件类型 explicit
事件已指派给处理组
当事件被指派给某个支持小组处理时,会发生此活动。它是路由流程中的关键一步,可通过监控Assignment Group字段的变更来识别。
为何重要

跟踪分配情况对于分析交接、各小组的排队时间,以及识别路由低效或瓶颈至关重要。

获取方式

通过 'sys_audit' 表跟踪 'incident' 表上的 'assignment_group' 字段被填入或被修改的时间来推断。

捕获

使用审计日志中针对'assignment_group'字段变更的时间戳。

事件类型 inferred
工作已启动
表示坐席已开始对该事件进行调查或处理。通常在事件状态从 'New' 或 'Assigned' 变更为 'In Progress' 等活动状态时推断。
为何重要

该里程碑标志着初始排队时间结束、实际处理开始。衡量“开始处理”之前的等待时长是进行瓶颈分析的关键。

获取方式

通过 'sys_audit' 表识别到 'incident' 表的 'state' 字段变更为表示正在处理的状态(如 'In Progress')时推断。

捕获

识别审计日志中'state'字段变更为'In Progress'或类似值时的时间戳。

事件类型 inferred
已提出解决方案
标记支持坐席完成修复并将事件置为 'Resolved' 状态的时间点,这是最终关闭前的重要里程碑。
为何重要

该活动标志着实际处理结束并进入确认阶段。此时间点与'Incident Closed'之间的时间差,可揭示用户确认或验证环节的延迟。

获取方式

当检测到 'incident' 表的 'state' 字段变更为 'Resolved' 时(此时通常会填充 'resolved_at' 时间戳),即可通过 'sys_audit' 表推断。

捕获

使用'state'字段变为'Resolved'时的时间戳,或使用'resolved_at'时间戳。

事件类型 inferred
指派组已变更
表示一次交接:事件从一个支持组转移到另一个支持组。可在“assignment_group”字段首次赋值后,通过观察其后续变更来识别。
为何重要

频繁重分配可能意味着初始路由不正确、流程过于复杂或知识缺口。该活动是衡量“每起事件平均交接次数”KPI的关键。

获取方式

通过 'sys_audit' 表跟踪初始分配后对 'assignment_group' 字段的任何变更来推断。

捕获

在审计日志中识别每一次带时间戳的'assignment_group'字段变更。

事件类型 inferred
事件已关联到问题
当事件被正式关联到某条问题记录时,会发生此活动,表示它属于更大的底层问题的一部分。通常在事件记录的'problem_id'字段被填写时,即可推断发生此活动。
为何重要

将事件关联到问题记录,是从被动修复转向主动根因分析的关键一步。这一操作也支撑“重复事件量”仪表板。

获取方式

当检测到 'incident' 表上的引用字段 'problem_id' 被填入值时推断。

捕获

在审计日志中识别'problem_id'字段被填写时的时间戳。

事件类型 inferred
事件已分类
表示事件的初始分类阶段,会设置类别、子类别和优先级等字段。通常通过审计轨迹推断:当这些字段在创建后首次被填充或在短时间内更新时,即视为发生该事件。
为何重要

准确分类对正确路由和设定优先级至关重要。跟踪该活动有助于分析重分类率及其对解决时间的影响。

获取方式

通过 'sys_audit' 表识别到某事件的 'category'、'subcategory' 或 'priority' 等字段的首次变更时推断。

捕获

在审计日志中识别分类字段首次更新的时间戳。

事件类型 inferred
事件已升级
当事件的优先级或严重性被上调时触发,通常需要更快响应或调用不同资源。可通过检测“priority”字段的值由低变高来推断。
为何重要

升级通常意味着事件比最初判断更严重,或正接近SLA违约。分析这些事件有助于理解流程中的例外情况。

获取方式

通过 'sys_audit' 表识别到 'priority' 字段变更为更高紧急程度时推断。

捕获

检测“priority”字段值上升的情况(例如从“3 - Moderate”升至“2 - High”)。

事件类型 inferred
事件已指派给处理人
表示支持组内某位处理人接手该事件的时点。可通过监控“assigned_to”字段的变化来捕捉。
为何重要

可细致呈现处理人的工作负载和首次接触解决情况,并衡量事件在分配到小组后,等待个人接手并开始处理的时长。

获取方式

通过 'sys_audit' 表跟踪 'incident' 表上的 'assigned_to' 字段被填入或被修改的时间来推断。

捕获

使用审计日志中针对'assigned_to'字段变更的时间戳。

事件类型 inferred
事件已重新开启
当用户在事件被标记为已解决后仍反馈问题存在时触发。通常通过事件状态从“已解决”变回“处理中”等活动状态来推断。
为何重要

被重新打开的事件意味着上次解决失败,也代表着返工。跟踪此类活动对于衡量解决质量与一次性修复率至关重要。

获取方式

通过 'sys_audit' 表检测到 'state' 字段由 'Resolved' 回到 'In Progress' 或 'Assigned' 等活动状态时推断。

捕获

识别'state'字段从'Resolved'变为活动状态值时的时间戳。

事件类型 inferred
已添加支持备注
支持人员新增工作备注或对用户可见的评论。这会在该事件的活动流中作为显式事件被记录。
为何重要

用于记录支持团队的沟通与排查活动。分析这些备注的频率与时间点,可洞察排查过程。

获取方式

来自“sys_journal_field”表,该表记录“incident”表上“work_notes”和“comments”字段的日志条目。

捕获

使用元素为'work_notes'或'comments'的日志条目的创建时间戳。

事件类型 explicit
等待用户确认
事件处于挂起状态,等待用户确认所提解决方案是否有效。通常可从特定状态推断(如在已解决后进入 'Awaiting User Info')。
为何重要

若用户响应缓慢,此状态可能成为显著瓶颈。衡量在该活动上停留的时间,可发现沟通断点以及自动化关闭的机会。

获取方式

通过 'sys_audit' 表识别到在已解决后状态变更为特定的挂起状态时推断。状态名称可能为自定义,例如 'Awaiting Caller'。

捕获

识别'state'字段变更为表示等待用户输入的值时的时间戳。

事件类型 inferred
推荐 可选

提取指南

如何从ServiceNow问题管理获取数据