您的事件管理数据模板
您的事件管理数据模板
- 建议收集的属性
- 需要跟踪的关键活动
- ServiceNow问题管理数据提取指南
事件管理属性
| 名称 | 说明 | ||
|---|---|---|---|
|
事件ID
IncidentId
|
每条事件记录的唯一标识符,也是跟踪完整生命周期的主键。 | ||
|
说明
事件ID是ServiceNow为每个已报告事件分配的唯一编号。它是核心案例标识符,可关联事件创建至关闭期间的所有相关活动、更新和沟通记录。 在流程挖掘分析中,事件ID至关重要。工具借助它串联每个案例的事件序列,为发现流程图、分析流程变体和计算端到端时长奠定基础。如果每个案例都没有唯一的事件ID,就无法追踪事件在解决过程中的完整历程。
重要性
这是关联事件生命周期中所有事件的必要案例ID,使端到端流程分析成为可能。
获取途径
ServiceNow事件表,字段number。
示例
INC0010001INC0010045INC0010239
|
|||
|
事件时间
EventTime
|
标明活动发生时间的精确时间戳。 | ||
|
说明
事件时间通常也称为时间戳,记录活动完成或状态变更的确切日期和时间。在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
|
|||
|
活动名称
ActivityName
|
事件生命周期中某个时间点发生的具体事件或任务的名称。 | ||
|
说明
活动名称用于描述事件管理流程中的具体步骤或状态变更,例如“事件已创建”“已分派至客服人员”或“事件已关闭”。此数据通常根据“State”或“Assignment Group”等关键事件字段的变更,或特定日志条目生成。 此属性对于构建流程图至关重要。它定义流程图中的节点,使分析人员能够查看事件流转情况、识别常见路径、发现活动之间的瓶颈并分析流程变体。活动名称的粒度和准确性会直接影响流程分析的质量。
重要性
它定义流程图中的步骤,是所有流程挖掘分析和可视化的基础。
获取途径
这是一个派生属性,通常由数据转换逻辑根据sys_audit或incident表中state、assignment_group和assigned_to等字段的变更生成。
示例
事件已创建分派组已变更已提出解决方案事件已关闭
|
|||
|
数据上次更新时间
LastDataUpdate
|
指示此记录的数据上次从源系统刷新时间的时间戳。 | ||
|
说明
此属性记录最近一次从ServiceNow提取或更新数据的日期和时间。它是元数据字段,用于反映所分析数据的新鲜度,并非流程中的事件。 了解分析数据的时效性至关重要。此信息会告知用户数据的更新时间,这对于运营仪表板和基于近期事件做出决策十分重要,也有助于用户判断数据的相关性和时效性。
重要性
它能让用户了解数据的新鲜度,这对确保分析结果的相关性和准确性至关重要。
获取途径
此时间戳由数据提取工具或流程在加载数据时生成并填写。
示例
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
源系统
SourceSystem
|
提取此数据的系统。 | ||
|
说明
此属性用于标识事件数据的来源,本例中为ServiceNow问题管理。通常在数据提取和转换过程中添加一个固定值。 如果分析时需要合并多个系统的数据,此字段对于数据溯源和数据隔离至关重要。它有助于确保在正确的背景下分析指标和流程,也便于分析人员比较不同源系统中的流程。
重要性
它提供有关数据来源的重要背景信息,确保数据可溯源,并支持在多系统环境中正确解读数据。
获取途径
通常在数据提取过程中添加一个固定值。
示例
ServiceNow问题管理ServiceNow
|
|||
|
事件状态
IncidentState
|
事件在生命周期中的当前状态。 | ||
|
说明
事件状态表示事件当前所处的阶段,例如“New”“In Progress”“On Hold”或“Resolved”。状态变更通常是流程挖掘事件日志中活动的主要来源。 分析事件在各状态中停留的时间,是识别瓶颈的有效方法。例如,事件长时间处于“On Hold”状态,可能表明其依赖外部因素或用户。状态变更的顺序也构成流程图的基础,展示事件如何逐步得到解决。
重要性
它跟踪事件进展,是分析各阶段耗时和识别流程瓶颈的关键。
获取途径
ServiceNow事件表,字段incident_state或state。
示例
新建处理中等待用户提供信息已解决已关闭
|
|||
|
优先级
Priority
|
事件的优先级,用于确定所需的响应紧急程度。 | ||
|
说明
优先级是ServiceNow中的关键字段,用于确定事件处理的顺序和速度。它通常根据事件的影响和紧急程度确定,并直接影响SLA目标。 此属性是分类和绩效分析的基础。“SLA合规性概览”仪表板使用优先级评估高优先级事件是否在目标时间内解决。按优先级分析周期时间,有助于确认严重事件是否确实比不太重要的事件处理得更快。它几乎是所有KPI和仪表板的重要分析维度。
重要性
它支持按业务重要性对事件分类,这对于监控SLA合规性和分配资源至关重要。
获取途径
ServiceNow事件表,字段priority。
示例
1 - 严重2 - 高3 - 中4 - 低
|
|||
|
分派组
AssignmentGroup
|
负责处理事件的支持团队或小组。 | ||
|
说明
分派组是指负责解决事件的客服团队。事件通常会在不同支持组之间流转,例如从一级服务台转至专业的二级网络团队。 此属性对于分析团队间交接和识别系统性瓶颈至关重要。“交接与重新分派率”仪表板主要依靠此数据,展示哪些团队经常参与转交。它还支持比较不同支持组的表现,并帮助了解组织内各团队的解决问题能力。
重要性
此属性跟踪负责处理事件的团队,支持分析团队表现、工作量和组间交接情况。
获取途径
ServiceNow事件表,字段assignment_group。
示例
服务台网络支持数据库管理员
|
|||
|
处理人
AssignedTo
|
当前负责处理事件的用户或客服人员。 | ||
|
说明
此属性用于标识在特定时间点负责处理事件的支持人员。了解此信息对于分析工作量分配、人员表现和个人之间的交接至关重要。 在分析中,“处理人”有助于查看资源分配情况并识别工作负荷过重的人员。它也用于“交接与重新分派”仪表板,跟踪事件更换负责人的次数,这可能反映出效率低下或知识不足。按客服人员分析解决时间,还能帮助发现表现出色的人员或需要额外培训的人员。
重要性
它支持分析客服人员的工作量、表现和个人交接情况,这些都是了解资源使用效率的关键。
获取途径
ServiceNow事件表,字段assigned_to。
示例
Beth AnglinDavid LooHoward Johnson
|
|||
|
SLA到期时间
SlaDueDate
|
根据SLA要求,事件预计解决的目标日期和时间。 | ||
|
说明
SLA到期时间是计算得出的时间戳,表示事件的解决期限。该日期根据事件的优先级等特征及其关联的服务级别协议(SLA)确定。 此属性是“服务级别合规概览”仪表板和“严重事件SLA违约率”KPI的重要依据。它可作为基准,用于比较实际解决时间。分析临近SLA到期时间的事件,有助于及时升级处理并确定优先级。
重要性
该属性定义解决期限,便于衡量SLA合规情况,并识别可能无法按期完成的事件。
获取途径
此值通常位于与事件表关联的task_sla表中,相关时间戳字段为planned_end_time。
示例
2023-05-20T17:00:00Z2023-06-01T09:00:00Z
|
|||
|
严重程度
Severity
|
事件造成的业务影响程度。 | ||
|
说明
严重程度用于衡量事件对业务运营的影响。通常会与紧急程度一起用于自动计算事件优先级。 在分析中,严重程度是“服务级别合规概览”仪表板的重要维度。它帮助组织了解影响最大的事件是否达到服务级别要求,并从业务角度补充优先级所反映的运营情况。
重要性
该属性衡量事件对业务的影响,是确定工作优先级和分析关键问题处理表现的重要维度。
获取途径
ServiceNow事件表中的severity字段。
示例
1-高2-中3-低
|
|||
|
报告人
CallerId
|
最初报告事件的用户。 | ||
|
说明
报告人是受事件影响并提交报告的最终用户或客户。此信息有助于了解服务中断影响了谁。 按报告人分析事件未必是流程分析的核心,但可以发现某些个人或部门是否受到问题的影响更大,从而提示培训需求或局部环境问题。此信息也可用于联系客户、开展满意度调查和沟通。
重要性
该属性标识受影响的用户,便于按部门或个人分析,并为用户沟通提供背景信息。
获取途径
ServiceNow事件表中的caller_id字段。
示例
Abel TuterCarolina PashDon Goodliffe
|
|||
|
是否违反SLA
IsSlaBreached
|
用于标记事件解决时间是否超过SLA到期时间。 | ||
|
说明
这是一个计算得出的布尔属性,用于标记是否有事件违反服务级别协议。系统通过比较实际解决时间戳与“SLA到期时间”得出此值。如果解决时间晚于到期时间,该标记将设为true。 此属性是“服务级别合规概览”仪表板及相关KPI的基础。它将复杂的时间比较转换为简单的真/假维度,便于筛选所有违约事件,并分析其类别、分配组或优先级等共同特征。
重要性
该属性简化了SLA合规分析,便于筛选并深入分析所有未达到目标的事件。
获取途径
通过比较“Resolved At”时间戳和“SlaDueDate”时间戳计算得出。(Resolved At>SlaDueDate)
示例
truefalse
|
|||
|
是否重新打开
IsReopened
|
用于标记事件解决后是否重新打开。 | ||
|
说明
如果事件状态在达到“已解决”或“已关闭”后又变为活跃状态(例如“处理中”),此布尔标记将设为true。通常可通过在事件日志中查找“事件重新打开”活动来识别。 事件重新打开通常说明解决方案不完整或无效。分析这类事件有助于发现过早关闭或首次处理时未能彻底解决的重复问题。重新打开率过高会影响用户满意度和团队效率,因此是质量控制的重要指标。
重要性
此标记用于发现解决流程中的问题,突出显示那些在被视为已解决后仍需继续处理的事件。
获取途径
检查每个事件的活动顺序,确认“已解决”状态之后是否出现“已打开”状态。
示例
truefalse
|
|||
|
类别
Category
|
事件的大类,例如硬件、软件或网络。 | ||
|
说明
类别用于概括事件的性质。类别通常与子类别结合使用,有助于将事件路由至正确的支持团队,也可用于报表和趋势分析。 在流程挖掘中,此属性对于“事件分类准确率”和“重复事件数量”仪表板至关重要。通过分析流程中途变更类别的事件,组织可以发现初步分诊环节的问题。按类别筛选流程图,还能揭示不同类型的事件是否遵循不同的解决路径,或是否存在特有瓶颈。
重要性
它支持分析事件类型、衡量分类准确率,并为路由和趋势分析提供重要依据。
获取途径
ServiceNow事件表,字段category。
示例
硬件软件网络数据库
|
|||
|
解决代码
ResolutionCode
|
用于说明事件最终如何解决的代码。 | ||
|
说明
解决代码用于说明采用的解决方案,例如由用户自行解决、通过已知错误解决,或提供了临时解决方法。通常由处理人员在关闭事件时填写。 此属性直接支持“解决类型有效性”仪表板。通过该属性,您可以分析事件是通过永久修复还是临时解决方法关闭,从而了解服务质量和长期稳定性。临时解决方法占比较高,可能意味着根本问题尚未得到妥善处理。
重要性
该属性说明解决方式,便于比较永久修复和临时解决方法,并支持根因分析。
获取途径
ServiceNow事件表中的close_code字段,或自定义解决代码字段。
示例
已解决(临时解决方法)已解决(永久修复)未解决(用户取消)已知错误
|
|||
|
配置项
ConfigurationItem
|
受事件影响的特定IT组件、服务或资产。 | ||
|
说明
配置项(CI)是配置管理数据库(CMDB)中受事件影响的资产,可以是服务器、应用程序、笔记本电脑或网络设备。 按CI分析事件有助于发现可靠性较差的资产或服务,找出IT基础设施中产生事件最多的部分,为升级或更换投资提供依据。在流程挖掘中,按CI筛选还能揭示关键应用相关事件的处理方式或效率是否与其他事件不同。
重要性
该属性标识受影响的资产,帮助您找出IT基础设施中的问题组件,并有针对性地开展改进。
获取途径
ServiceNow事件表中的cmdb_ci字段。
示例
SAP ERP生产环境Oracle数据库服务器05电子邮件服务
|
|||
|
重新分配次数
ReassignmentCount
|
事件转交给其他小组或处理人员的次数。 | ||
|
说明
此字段记录事件在不同分配组之间转交的总次数,是衡量流程阻力的直接指标,也常用作关键绩效指标。 此属性是“转交与重新分配率”仪表板和“每个事件的平均转交次数”KPI的主要依据。重新分配次数较多,通常说明初始分派不准确、支持层级缺少相应技能,或流程职责不清。减少转交次数是流程改进的常见目标,通常也有助于缩短解决时间。
重要性
该属性直接衡量流程转交,是发现效率低下、分派错误和改进机会的重要指标。
获取途径
ServiceNow事件表中的reassignment_count字段。
示例
0135
|
|||
|
问题ID
ProblemId
|
如果事件关联到更大的问题,此处为相关问题记录的标识符。 | ||
|
说明
问题ID将事件关联到问题管理模块中的对应记录。当事件被认定为影响多个用户或服务的更大根本问题的症状时,就会建立此关联。 此关联对于“重复事件量”仪表板和“重复事件率”KPI至关重要。分析人员可以据此归类由同一根因引发的事件,衡量问题的整体影响,并跟踪问题解决工作的成效。大量事件关联到问题,通常说明支持工作较为被动。
重要性
该属性将事件与根因关联,是分析重复问题和衡量问题管理影响的关键依据。
获取途径
ServiceNow事件表中的problem_id字段。
示例
PRB0040001PRB0040015PRB0040102
|
|||
事件管理活动
| 活动 | 说明 | ||
|---|---|---|---|
|
事件已关闭
|
这是生命周期中的最后一项活动,表示事件已彻底解决并确认,无需进一步处理。此事件通过关闭时间戳明确记录。 | ||
|
重要性
作为明确的结束事件,此活动对于计算事件的完整生命周期时长,以及分析解决后的处理时间至关重要。
获取途径
'incident'表中的'closed_at'时间戳是此事件明确的时间戳。通常在'state'字段变为'Closed'时设置。
采集
使用事件记录中的'closed_at'时间戳。
事件类型
explicit
|
|||
|
事件已分派至支持组
|
事件分派给特定支持组处理时,会发生此活动。这是路由过程中的关键步骤,可通过观察assignment group字段的变更来记录。 | ||
|
重要性
跟踪分派情况对于分析交接、各支持组的排队时间,以及识别路由低效或瓶颈至关重要。
获取途径
通过'sys_audit'表跟踪'incident'表中的'assignment_group'字段何时填写或变更,以此推断该活动。
采集
使用审计日志中'assignment_group'字段变更的时间戳。
事件类型
inferred
|
|||
|
事件已创建
|
在ServiceNow中正式记录新事件时,事件生命周期由此开始。此事件直接使用事件记录的创建时间戳。 | ||
|
重要性
这是流程的主要开始事件。分析从此活动到解决事件所需的时间,是衡量整体周期时间和SLA合规性的基础。
获取途径
'incident'表中的'sys_created_on'时间戳是此活动明确的事件时间戳。
采集
使用事件记录中的'sys_created_on'时间戳。
事件类型
explicit
|
|||
|
分派组已变更
|
表示事件从一个支持组转交给另一个支持组。首次填写'assignment_group'字段后,可通过观察该字段后续的变更来记录此活动。 | ||
|
重要性
频繁重新分派可能意味着初始路由不当、流程复杂或知识不足。此活动对于衡量“每个事件的平均交接次数”这一KPI至关重要。
获取途径
通过'sys_audit'表跟踪初次分派后'assignment_group'字段的任何变更,以此推断该活动。
采集
在审计日志中识别'assignment_group'字段每次变更的时间戳。
事件类型
inferred
|
|||
|
已提出解决方案
|
支持人员实施修复并将事件状态改为'Resolved'时,即表示此活动发生。这是最终关闭事件之前的关键里程碑。 | ||
|
重要性
此活动表示主动处理工作结束,确认阶段开始。从此时到“事件已关闭”之间的时间,可以揭示用户确认或验证环节的延误。
获取途径
当'incident'表中的'state'字段变为'Resolved'时,可通过'sys_audit'表推断此活动。此时通常也会填写'resolved_at'时间戳。
采集
使用'state'字段变为'Resolved'时的时间戳,或使用'resolved_at'时间戳。
事件类型
inferred
|
|||
|
开始处理
|
表示客服人员已开始主动调查或处理事件。通常可根据事件状态从'New'或'Assigned'变为'In Progress'等处理中状态来推断。 | ||
|
重要性
这一里程碑标志着初始排队时间结束,主动解决工作开始。衡量开始处理前的等待时间,是瓶颈分析的关键。
获取途径
通过'sys_audit'表推断,识别'incident'表中的'state'字段何时变为表示正在处理的值,例如'In Progress'。
采集
识别'state'字段变为'In Progress'或类似值时的时间戳。
事件类型
inferred
|
|||
|
事件已关联问题记录
|
事件与问题记录正式关联时会发生此活动,表明该事件属于更大范围的潜在问题。可通过检查事件记录中的'problem_id'字段是否已填写来推断。 | ||
|
重要性
将事件关联到问题记录,是从被动解决事件转向主动分析根本原因的关键一步。这也为“重复事件数量”仪表板提供支持。
获取途径
检测'incident'表中的'problem_id'引用字段是否已填写,以此推断该活动。
采集
在审计日志中查找'problem_id'字段填写时的时间戳。
事件类型
inferred
|
|||
|
事件已分派至客服人员
|
表示支持组中的某位客服人员开始负责处理事件。可通过监控'assigned_to'字段的变更来记录此活动。 | ||
|
重要性
这能细致呈现客服人员的工作量和首次联系解决情况,并帮助确定事件分派至支持组后,等待个人开始处理所用的时间。
获取途径
通过'sys_audit'表跟踪'incident'表中的'assigned_to'字段何时填写或变更,以此推断该活动。
采集
使用审计日志中'assigned_to'字段变更的时间戳。
事件类型
inferred
|
|||
|
事件已分类
|
表示事件的初步分类,此时会设置类别、子类别和优先级等字段。通常可根据审计记录推断此事件:这些字段首次填写或在创建后不久更新时,即视为发生。 | ||
|
重要性
准确分类对正确路由和确定优先级至关重要。跟踪此活动有助于分析重新分类率及其对解决时间的影响。
获取途径
通过'sys_audit'表推断,识别指定事件的'category'、'subcategory'或'priority'等字段首次变更的时间。
采集
在审计日志中查找分类字段首次更新的时间戳。
事件类型
inferred
|
|||
|
事件已升级
|
事件的优先级或严重程度提高时会发生此活动,通常意味着需要更快响应或调配不同资源。可通过检测'priority'字段的值上调来推断。 | ||
|
重要性
升级通常表明事件比最初判断的更严重,或即将违反SLA。分析这些事件有助于了解流程例外情况。
获取途径
通过'sys_audit'表推断,识别'priority'字段是否变更为紧急程度更高的值。
采集
检测'priority'字段值是否提高,例如从'3 - Moderate'变为'2 - High'。
事件类型
inferred
|
|||
|
事件已重新打开
|
事件标记为已解决后,用户报告问题仍然存在时会发生此活动。可根据事件状态从'Resolved'变回'In Progress'等处理中状态来推断。 | ||
|
重要性
重新打开的事件表明解决方案未能奏效,也意味着需要返工。跟踪此活动对于衡量解决质量和一次性修复率至关重要。
获取途径
通过'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效率
在ServiceNow中将MTTR缩短35%。找准问题,提升满意度。
无需信用卡,几分钟即可开始优化。