您的事件管理数据模板

ServiceNow问题管理
您的事件管理数据模板

您的事件管理数据模板

此模板全面介绍了收集事件管理流程分析和优化所需数据的方法,包括需要采集的关键数据属性、需要跟踪的核心活动,以及如何从源系统提取这些信息的实用指导。您可以使用此资源构建可靠的事件日志,开展深入的流程分析和改进。
  • 建议收集的属性
  • 需要跟踪的关键活动
  • ServiceNow问题管理数据提取指南
刚接触事件日志?了解 如何创建流程挖掘事件日志.

事件管理属性

以下是建议纳入事件日志的数据字段,用于全面分析您的事件管理流程。
5 必需 4 建议 10 可选
名称 说明
事件ID
IncidentId
每条Incident记录的唯一标识符,用于跟踪完整生命周期。
说明

Incident ID是ServiceNow为每个已报告Incident分配的唯一引用编号。它是核心Case标识符,用于关联从Incident创建到关闭期间的所有相关活动、更新和沟通。

在流程挖掘分析中,该ID至关重要。它可以将每个Case的事件序列串联起来,为发现流程图、分析变体和计算端到端时长奠定基础。如果每个Case没有唯一的Incident ID,就无法追踪Incident在解决流程中的完整路径。

为什么重要

这是连接Incident生命周期中所有事件的必要Case ID,使端到端流程分析成为可能。

获取位置

ServiceNow Incident表,字段编号。

示例
INC0010001INC0010045INC0010239
事件时间
EventTime
表示活动发生时间的精确时间戳。
说明

事件时间通常也称为时间戳,用于记录活动完成或状态变更的准确日期和时间。在ServiceNow中,通常通过审计轨迹中每次变更对应的sys_updated_on字段捕获。

该属性对于正确排列事件顺序以及所有基于时间的分析都至关重要。它用于计算周期时间、队列等待时间和活动间隔,这些指标是识别瓶颈、衡量SLA绩效和了解流程效率的基础。时间戳的准确性直接关系到所有时长指标的有效性。

为什么重要

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

获取位置

ServiceNowsys_audit表的sys_created_on字段,或Incident表中最后一个状态对应的sys_updated_on字段。

示例
2023-04-15T10:05:21Z2023-04-15T11:22:00Z2023-04-16T09:00:30Z
活动名称
ActivityName
Incident生命周期中某个时间点发生的具体事件或任务的名称。
说明

活动名称描述Incident Management流程中的具体步骤或状态变更,例如Incident Created、Assigned To Agent或Incident Closed。该数据通常来自关键Incident字段的变更,例如State或Assignment Group,也可能来自特定日志条目。

该属性对于构建流程图至关重要。它定义流程图中的节点,使分析人员能够可视化Incident流转、识别常见路径、发现活动之间的瓶颈并分析流程变体。活动名称的粒度和准确性会直接影响流程分析质量。

为什么重要

它定义流程图中的步骤,是所有流程挖掘分析和可视化的基础。

获取位置

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

示例
Incident已创建Assignment Group已变更已提出解决方案Incident已关闭
最后数据更新时间
LastDataUpdate
表示该记录数据最近一次从源系统刷新时间的时间戳。
说明

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

这些信息对于了解分析的时效性至关重要。它可以告知用户数据的最新程度,这对于运营仪表板以及基于近期事件做出决策都很重要,也有助于管理用户对数据相关性和时效性的预期。

为什么重要

它可以告知用户数据的新鲜度,这对于确保分析的相关性和准确性至关重要。

获取位置

该时间戳由数据提取工具或流程在加载数据时生成并填充。

示例
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
源系统
SourceSystem
提取该数据的系统。
说明

该属性用于标识Incident数据的来源,本例中为ServiceNow Problem Management。通常在数据提取和转换过程中添加为静态值。

在可能合并多个系统数据进行分析的环境中,该字段对于数据血缘和数据隔离至关重要。它有助于确保在正确的上下文中分析指标和流程,并支持分析人员比较不同源系统中的流程。

为什么重要

它提供有关数据来源的关键上下文,确保数据血缘清晰,并支持在多系统环境中正确解读数据。

获取位置

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

示例
ServiceNow问题管理ServiceNow
Incident状态
IncidentState
Incident在生命周期中的当前状态。
说明

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

分析每种状态的停留时间,是识别瓶颈的有效方法。例如,On Hold状态持续时间过长,可能表示依赖外部因素或用户。状态变更序列也构成流程图的基础,展示Incident如何逐步走向解决。

为什么重要

它跟踪Incident进展,是分析各阶段耗时和识别流程瓶颈的关键。

获取位置

ServiceNowIncident表,字段incident_state或state。

示例
新建处理中等待用户信息已解决已关闭
优先级
Priority
Incident的优先级,决定响应所需的紧急程度。
说明

Priority是ServiceNow中的关键字段,用于决定Incident的处理顺序和速度。它通常根据Incident的影响和紧急程度得出,并直接影响SLA目标。

该属性是分组和绩效分析的基础。“SLA合规性概览”仪表板使用Priority评估高优先级Incident是否在目标时间内解决。按优先级分析周期时间,有助于确认重大Incident确实比重要性较低的Incident处理得更快。它几乎是所有KPI和仪表板的重要维度。

为什么重要

它支持按业务重要性对Incident进行分组,这对于SLA合规性监控和资源分配至关重要。

获取位置

ServiceNowIncident表,字段priority。

示例
1-严重2-高3-中等4-低
分配组
AssignmentGroup
负责处理Incident的支持团队或组。
说明

Assignment Group代表负责解决Incident的Agent团队。Incident通常会在不同组之间路由,例如从Level 1服务台转交给专业的Level 2网络团队。

该属性对于分析团队间交接和识别系统性瓶颈至关重要。“交接和重新分配率”仪表板高度依赖此数据,用于展示哪些团队经常参与转交。它还支持比较不同支持组的绩效,并帮助了解组织内部的解决专业能力分布。

为什么重要

它跟踪负责处理Incident的团队,支持分析团队绩效、工作负载以及组间交接情况。

获取位置

ServiceNowIncident表,字段assignment_group。

示例
服务台网络支持数据库管理员
指定处理人
AssignedTo
当前负责处理Incident的个人用户或Agent。
说明

该属性用于标识特定时间点负责Incident的支持Agent。此信息对于了解工作负载分配、Agent绩效以及个人之间的交接至关重要。

在分析中,Assigned To有助于可视化资源分配并识别负载过高的Agent。它还用于交接和重新分配仪表板,以跟踪Incident更换个人负责人的次数,这可能表明流程低效或知识存在缺口。按Agent分析解决时间,还可以识别表现优秀的人员或需要额外培训的人员。

为什么重要

它支持分析Agent工作负载、绩效和个人交接情况,这些都是了解资源效率的关键。

获取位置

ServiceNowIncident表,字段assigned_to。

示例
Beth AnglinDavid LooHoward Johnson
SLA截止日期
SlaDueDate
根据SLA,预计事件应完成解决的目标日期和时间。
说明

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

此属性是“SLA合规概览”仪表板和“严重事件SLA违约率”KPI的基础。它作为基准,用于比较实际解决时间。分析接近SLA截止日期的事件,有助于主动升级和确定处理优先级。

为什么重要

它定义了解决目标,使您能够衡量SLA合规情况,并识别可能超出目标期限的事件。

获取位置

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

示例
2023-05-20T17:00:00Z2023-06-01T09:00:00Z
严重性
Severity
Incident造成的业务影响程度。
说明

Severity定义Incident对业务运营的影响程度。它通常与紧急程度结合使用,自动计算Incident优先级。

在分析中,Severity是“SLA合规性概览”仪表板的关键维度。它帮助组织了解对业务影响最大的Incident是否达到服务级别要求。该属性从业务角度呈现绩效,与Priority提供的运营视角形成补充。

为什么重要

它衡量Incident的业务影响,是确定工作优先级和分析重大问题绩效的重要维度。

获取位置

ServiceNowIncident表,字段severity。

示例
1-高2-中3-低
呼叫人
CallerId
最初报告该事件的用户。
说明

呼叫人用于标识受事件影响并报告事件的最终用户或客户。此信息有助于了解服务中断影响了谁。

虽然呼叫人并不总是流程本身的核心信息,但按呼叫人分析事件,可以发现某些个人或部门是否受到问题的不成比例影响。这可能反映出培训需求或局部环境问题。此外,该信息还提供了与客户直接联系的渠道,便于开展满意度调查和沟通。

为什么重要

它用于识别受影响的用户,支持按部门或个人进行分析,并为用户沟通提供背景信息。

获取位置

ServiceNow事件表,字段caller_id。

示例
Abel TuterCarolina PashDon Goodliffe
是否违反SLA
IsSlaBreached
用于标识事件解决是否超过SLA截止日期的标志。
说明

这是一个计算得出的布尔属性,用于标记违反服务级别协议的事件。系统通过比较实际解决时间戳与“SLA截止日期”得出该值。如果解决时间晚于截止日期,则该标志设为true。

此属性是“SLA合规概览”仪表板及相关KPI的基础。它将复杂的时间比较转换为简单的true/false维度,便于筛选所有违约事件,并分析其共同特征,例如类别、分配组或优先级。

为什么重要

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

获取位置

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

示例
truefalse
是否重新打开
IsReopened
用于标识事件在解决后是否被重新打开的标志。
说明

如果事件在达到“已解决”或“已关闭”状态后,状态又变回活动状态(例如“处理中”),则此布尔标志设为true。通常可通过在事件日志中查找“事件重新打开”活动来识别。

重新打开的事件通常表明解决方案不完整或无效。分析这些案例,有助于识别过早关闭或首次未能彻底解决的重复问题。较高的重新打开率会降低用户满意度和团队生产力,因此这是质量控制的重要指标。

为什么重要

此标志用于识别解决流程中的失败,突出显示那些在被视为已解决后仍需追加处理的事件。

获取位置

通过检查每个事件的活动顺序,确认“打开”状态是否出现在“已解决”状态之后。

示例
truefalse
类别
Category
Incident的高层级分类,例如Hardware、Software或Network。
说明

Category用于概括Incident的性质。它通常与子类别结合使用,帮助将Incident路由至正确的支持团队,并用于报告和趋势分析。

对于流程挖掘,该属性是“Incident分类准确性”和“重复Incident数量”仪表板的关键。通过分析流程中途发生Category变更的Incident,组织可以识别初始分诊问题。按Category筛选流程图,还可以发现某些类型的Incident是否遵循不同的解决路径,或面临独特的瓶颈。

为什么重要

它支持分析Incident类型、衡量分类准确性,并对路由和趋势分析至关重要。

获取位置

ServiceNowIncident表,字段category。

示例
硬件软件网络数据库
解决代码
ResolutionCode
表示Incident最终解决方式的代码。
说明

Resolution Code用于说明所采用解决方案的性质,例如由用户解决、通过已知错误解决,或提供了临时解决方案。该字段通常由Agent在关闭Incident时填写。

该属性直接支持“解决类型有效性”仪表板。它可以分析通过永久修复与临时解决方案关闭的Incident数量,这是衡量服务质量和长期稳定性的关键指标。临时解决方案比例较高,可能表明潜在问题未得到充分处理。

为什么重要

它明确解决方式,支持分析永久修复与临时解决方案的差异,并为根因分析提供依据。

获取位置

ServiceNowIncident表,字段close_code或自定义解决代码字段。

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

Configuration Item(CI)是Configuration Management Database(CMDB)中受Incident影响的资产,可能是服务器、应用程序、笔记本电脑或网络设备。

按CI分析Incident对于识别不可靠资产或服务非常有价值。它有助于定位IT基础设施中产生Incident最多的部分,为升级或更换投资提供依据。在流程挖掘中,按CI筛选可以揭示与关键应用相关的Incident是否采用不同或更高效的处理方式。

为什么重要

它标识受影响的资产,有助于定位IT基础设施中的问题组件,并聚焦改进工作。

获取位置

ServiceNowIncident表,字段cmdb_ci。

示例
SAP ERP生产环境Oracle DB Server 05电子邮件服务
重新分配次数
ReassignmentCount
Incident被重新分配给其他组或Agent的次数。
说明

该字段跟踪Incident在不同Assignment Group之间转交的总次数,是流程摩擦的直接衡量指标,也常被用作关键绩效指标。

该属性是“交接和重新分配率”仪表板及“每个Incident的平均交接次数”KPI的主要依据。重新分配次数较多,通常表明初始路由不正确、某个支持层级缺少相应技能,或流程责任不清。减少重新分配次数是流程改进计划的常见目标,因为这通常能够缩短解决时间。

为什么重要

它直接衡量流程交接,是识别低效、路由错误和改进机会的关键指标。

获取位置

ServiceNowIncident表,字段reassignment_count。

示例
0135
问题ID
ProblemId
当Incident关联到更大范围的问题时,对应Problem记录的标识符。
说明

Problem ID将Incident关联到Problem Management模块中的对应记录。当Incident被识别为影响多个用户或服务的更大潜在问题的症状时,就会建立此关联。

该关联对于“重复Incident数量”仪表板和“重复Incident率”KPI至关重要。它支持分析人员将源于同一根因的Incident分组,衡量问题的完整影响,并跟踪问题解决工作的有效性。大量Incident关联到Problem,通常表明支持环境较为被动。

为什么重要

它将Incident关联到根因,对于分析重复问题和衡量Problem Management的影响至关重要。

获取位置

ServiceNowIncident表,字段problem_id。

示例
PRB0040001PRB0040015PRB0040102
必需 建议 可选

事件管理活动

以下是应纳入事件日志的关键流程步骤和里程碑,用于准确发现流程并进行优化。
6 建议 7 可选
活动 说明
Assignment Group已变更
表示Incident从一个支持组转交给另一个支持组的交接。可通过观察assignment_group字段在首次填充后的后续变更来捕获。
为什么重要

频繁重新分配可能意味着初始路由不正确、流程复杂或知识存在缺口。该活动对于衡量“每个Incident的平均交接次数”KPI至关重要。

获取位置

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

采集

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

事件类型 inferred
Incident已关闭
这是生命周期中的最终活动,表示Incident已完全解决并确认,无需进一步处理。该事件通过关闭时间戳明确捕获。
为什么重要

作为明确的结束事件,该活动对于计算Incident完整生命周期时长,以及分析解决后处理所需时间至关重要。

获取位置

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

采集

使用Incident记录中的closed_at时间戳。

事件类型 explicit
Incident已分配至组
当Incident被分配给特定支持组处理时,该活动随之发生。这是路由流程中的关键步骤,可通过观察assignment_group字段的变更来捕获。
为什么重要

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

获取位置

通过sys_audit表跟踪incident表中assignment_group字段被填充或变更的时间来推断。

采集

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

事件类型 inferred
Incident已创建
表示Incident生命周期的开始,即新Incident在ServiceNow中正式记录的时刻。该事件通过Incident记录的创建时间戳明确捕获。
为什么重要

这是流程的主要开始事件。分析从该活动到解决所需的时间,是衡量整体周期时间和SLA合规性的基础。

获取位置

incident表中的sys_created_on时间戳是该活动明确的事件时间戳。

采集

使用Incident记录中的sys_created_on时间戳。

事件类型 explicit
工作已开始
表示Agent已开始主动调查或处理Incident。通常可通过Incident状态从New或Assigned变为In Progress等活动状态来推断。
为什么重要

这一里程碑标志着初始队列等待结束,主动解决工作开始。衡量开始处理前的等待时间,是瓶颈分析的关键。

获取位置

通过sys_audit表识别incident表中state字段变为表示主动处理的值,例如In Progress,来推断。

采集

确定state字段变为In Progress或类似值的时间戳。

事件类型 inferred
已提出解决方案
表示支持Agent已实施修复,并将Incident状态变为Resolved的时刻。这是最终关闭前的关键里程碑。
为什么重要

该活动标志着主动处理结束、确认阶段开始。从此活动到Incident Closed之间的时间,可以揭示用户确认或验证环节的延误。

获取位置

当incident表中的state字段变为Resolved时,通过sys_audit表推断。此时通常也会填充resolved_at时间戳。

采集

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

事件类型 inferred
Incident已关联Problem
当Incident正式关联到Problem记录时,该活动随之发生,表示Incident属于更大范围的潜在问题。可通过Incident记录中的problem_id字段被填充来推断。
为什么重要

关联Problem是从被动修复Incident转向主动根因分析的关键步骤,并支持“重复Incident数量”仪表板。

获取位置

通过检测incident表中的problem_id引用字段是否被填充值来推断。

采集

确定审计日志中problem_id字段被填充时的时间戳。

事件类型 inferred
Incident已分类
表示Incident的初始分类,此时会设置Category、Subcategory和Priority等字段。通常可通过审计轨迹推断该事件,即这些字段首次填充或在创建后不久更新时记录。
为什么重要

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

获取位置

通过sys_audit表推断,识别特定Incident的category、subcategory或priority等字段首次发生变更的时间。

采集

确定审计日志中分类字段首次更新的时间戳。

事件类型 inferred
Incident已分配给Agent
表示支持组中的特定Agent接手Incident并负责处理的时刻。可通过监控assigned_to字段的变更来捕获。
为什么重要

这可以细致呈现Agent工作负载和首次接触解决情况,并帮助确定Incident分配给支持组后等待个人开始处理的时间。

获取位置

通过sys_audit表跟踪incident表中assigned_to字段被填充或变更的时间来推断。

采集

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

事件类型 inferred
Incident已升级
当Incident的优先级或严重性提高时,该事件随之发生,通常意味着需要更快响应或调配不同资源。可通过检测priority字段值的上调来推断。
为什么重要

升级通常表明Incident的严重程度高于最初判断,或正接近SLA违约。分析这些事件有助于了解流程例外。

获取位置

通过sys_audit表识别priority字段变为更高紧急程度的值来推断。

采集

检测priority字段值是否提高,例如从3 - Moderate变为2 - High。

事件类型 inferred
Incident已重新打开
当用户报告问题在标记为已解决后仍然存在时,该事件随之发生。可通过Incident状态从Resolved返回In Progress等活动状态来推断。
为什么重要

重新打开的Incident表明解决失败,并代表返工。跟踪此活动对于衡量解决质量和首次解决率至关重要。

获取位置

通过sys_audit表检测state字段从Resolved返回In Progress或Assigned等活动状态来推断。

采集

确定state从Resolved变为活动状态时的时间戳。

事件类型 inferred
已添加支持评论
支持Agent添加工作备注或用户可见的评论。这是Incident活动流中明确记录的事件。
为什么重要

跟踪支持团队的沟通和调查工作。分析评论的频率和时间,有助于了解调查过程。

获取位置

从sys_journal_field表获取,该表记录incident表中work_notes和comments字段的条目。

采集

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

事件类型 explicit
等待用户确认
Incident处于待处理状态,等待用户确认提出的解决方案是否有效。通常可通过解决后进入Awaiting User Info等特定状态来推断。
为什么重要

如果用户响应缓慢,此状态可能成为显著瓶颈。衡量在此活动中花费的时间,有助于识别沟通缺口和自动关闭机会。

获取位置

通过sys_audit表识别解决后变为特定待处理状态的变更来推断。状态名称可能是自定义值,例如Awaiting Caller。

采集

确定state变为表示等待用户输入的值时的时间戳。

事件类型 inferred
建议 可选

提取指南

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

准备开始了吗?

借助此模板,您已具备开启事件管理流程挖掘所需的一切。立即开始改进事件解决流程。

更快解决事件:立即提升ServiceNow效率

在ServiceNow中将平均修复时间(MTTR)缩短35%。精准定位问题,提升满意度。

开始免费试用

无需信用卡,几分钟内即可开始优化。