您的事件管理数据模板

BMC Helix ITSM
您的事件管理数据模板

您的事件管理数据模板

此模板全面介绍如何收集优化事件管理流程所需的关键数据,涵盖需要跟踪的重要属性和活动,并提供数据提取的实用指导。借助此资源,您可以简化数据准备,加快流程分析进程。
  • 建议收集的属性
  • 流程中需要跟踪的关键活动
  • 数据系统提取指南
刚接触事件日志?了解 如何创建流程挖掘事件日志.

事件管理属性

以下是建议纳入事件日志的数据字段,用于深入分析您的事件管理流程。
3 必需 8 建议 10 可选
名称 说明
事件ID
IncidentId
每条事件记录的唯一标识符。
说明

事件ID是每条事件的主键,从创建到关闭始终唯一标识该事件。它关联所有相关活动、日志和变更,帮助您完整、端到端地查看事件生命周期。

在流程挖掘中,此属性至关重要,因为它定义了案例。具有相同事件ID的每个事件都被视为同一流程实例的一部分,从而可以还原并分析单个事件的处理过程。

为什么重要

这是连接事件生命周期中所有事件的核心案例标识符,使端到端流程分析成为可能。

获取位置

这是“HPD:Help Desk”表单中的“Incident Number”字段(字段ID:1000000161)。

示例
INC000001234567INC000002345678INC000003456789
事件时间戳
EventTimestamp
活动发生的准确日期和时间。
说明

此时间戳记录事件生命周期中特定事件发生的时间,为根据原始数据重建流程路径提供所需的时间顺序。

事件时间戳是所有基于时间的分析的基础,包括计算活动之间的周期时间、识别事件长时间等待的瓶颈,以及衡量整体解决时间。它构成流程分析的时间基础。

为什么重要

此时间戳提供事件的时间顺序,对于计算时长、识别瓶颈和了解流程时间线至关重要。

获取位置

“HPD:Help Desk”表单中的“Last Modified Date”(字段ID:6)或特定日期字段。对于历史事件,取自审计日志的时间戳字段。

示例
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:22:05Z
活动名称
ActivityName
事件生命周期中发生的具体事件或任务名称。
说明

此属性描述事件在特定时间点执行的活动,例如“事件已报告”“已分配组”或“事件已解决”。这些活动构成流程图的基本要素。

分析这些活动的顺序和频率,可以揭示实际流程路径、识别常见路径,并突出偏离标准流程的情况。这对于了解解决事件所采取的操作至关重要。

为什么重要

活动定义流程图中的各个步骤,用于可视化和分析事件管理工作流。

获取位置

通常根据“HPD:Help Desk”表单中“Status”(字段ID:7)和“Status_Reason”字段的变更,或根据“HPD:Help Desk Audit Log”表单得出。

示例
事件已报告已分配支持组解决方案已实施事件已关闭
事件状态
IncidentStatus
事件发生时该事件的当前状态或历史状态。
说明

此属性表示事件所处状态,例如“New”、“In Progress”、“Pending”、“Resolved”或“Closed”,用于呈现事件在生命周期中的位置。

分析状态变更是了解事件管理流程的基础。它可用于定义活动、衡量事件在不同状态下的停留时间(例如处于“Pending”状态的时长),并识别可能卡住或处于非活动状态的事件。

为什么重要

跟踪状态变更是了解事件进展的关键,也有助于衡量事件在“Pending”或“In Progress”等特定状态下的停留时间。

获取位置

这是“HPD:Help Desk”表单中的“Status”字段(字段ID:7)。

示例
新建已分配处理中待处理已解决已关闭
事件类别
IncidentCategory
事件的分类方式,通常采用分层结构。
说明

事件分类提供了结构化的分类方式,通常采用多级层次结构(例如:第1层:硬件,第2层:笔记本电脑,第3层:电池)。这些数据对于路由、报告和趋势分析至关重要。

在流程挖掘中,分类用于分别分析不同类型的事件。通过比较初始类别和最终类别,它支持Incident Categorization Accuracy仪表板,并帮助识别Root Cause Trends仪表板中的趋势。

为什么重要

分类有助于准确路由、分析趋势,并比较不同类型事件的处理绩效。

获取位置

这是“HPD:Help Desk”表单中的“Operational Categorization Tier 1/2/3”字段。

示例
硬件 > 笔记本电脑 > 电池软件 > 企业应用 > 登录错误网络 > 连接 > Wi-Fi
优先级
Priority
分配给事件的优先级,用于确定处理紧迫程度。
说明

优先级通常根据影响和紧急程度综合确定,并决定事件解决的顺序和速度。常见取值范围从“Critical”到“Low”。

在流程挖掘中,按优先级分析事件对于性能分析至关重要。它有助于回答“高优先级事件是否达到SLA要求?”以及“低优先级事件是否经历了更长延迟?”等问题。按优先级筛选,可以聚焦最关键的业务问题。

为什么重要

此属性对于细分分析至关重要,可确保高优先级事件得到更快处理,并达到相应的服务级别目标。

获取位置

这是“HPD:Help Desk”表单中的“Priority”字段(字段ID:1000000164)。

示例
严重
分配组
AssignedGroup
负责处理事件的支持组。
说明

此属性用于标识负责事件的团队或部门,例如“Service Desk”、“Network Team”或“Database Administrators”。跟踪分配情况是了解团队间工作流转的关键。

此属性可用于分析团队间交接、识别由特定团队造成的瓶颈,以及衡量Incident Reassignment Rate。它有助于可视化事件在组织中的流转路径,并突出低效路由或知识缺口。

为什么重要

跟踪负责处理事件的组,有助于分析交接、识别重新分配循环,并定位特定团队中的瓶颈。

获取位置

这是“HPD:Help Desk”表单中的“Assigned Group”字段(字段ID:1000000217)。

示例
服务台网络运营应用支持二线基础设施服务
受理人
Assignee
负责处理事件的个人用户。
说明

受理人是特定时间段内负责处理事件的支持人员或技术人员。与分配组相比,它提供了更细粒度的信息。

按受理人分析绩效,有助于识别高绩效人员、可能需要额外培训的人员,以及工作量分配不均的情况。对于复杂事件,还可以借此追踪相关人员采取的具体操作顺序。

为什么重要

提供工作量分配和个人绩效的细粒度视图,帮助识别高绩效人员或需要支持的人员。

获取位置

这是“HPD:Help Desk”表单中的“Assignee”字段(字段ID:1000000218)。

示例
Bob SmithAlice JohnsonCharlie Brown
是否违反SLA
IsSlaBreached
用于标记事件是否在超过SLA目标日期后才解决。
说明

如果事件的解决时间超过规定的SLA,该布尔属性为true。它为每个事件的SLA绩效提供明确的二元结果。

该标记对于创建Incident SLA Performance Overview仪表板和计算“Incident SLA Compliance Rate”KPI至关重要。通过直接筛选和汇总所有未达到服务级别目标的事件,它简化了分析,也便于调查违反SLA的原因。

为什么重要

该标记简化了SLA合规分析,便于筛选所有违反SLA的事件并调查其根因。

获取位置

通过比较“Incident Resolved”事件时间戳与“SlaTargetDate”计算。如果解决时间戳晚于目标日期,该标记为true。

示例
truefalse
是否重新打开
IsReopened
用于标记事件在设置为“Resolved”状态后是否被重新打开。
说明

如果事件状态在标记为“Resolved”后又变回活动状态(例如“In Progress”),该布尔属性为true。这表示初始修复无效或不完整。

该指标可直接衡量返工,并用于计算“Incident Rework Rate”KPI。分析重新打开的事件,有助于识别低质量修复、测试不足或未得到妥善处理的重复问题,并支持Rework and Escalation Paths仪表板。

为什么重要

直接衡量返工情况和解决质量。重新打开率较高,通常表明修复措施无效或流程存在薄弱环节。

获取位置

通过分析事件的活动顺序计算。如果在“Resolution Implemented”活动之后出现“Incident Reopened”或类似活动,则该标记为true。

示例
truefalse
服务
Service
受事件影响的业务或技术服务。
说明

此属性将事件关联到配置管理数据库(CMDB)中定义的特定服务,例如“Email Service”、“VPN Access”或“SAP Financials”。

这种关联对于了解事件的业务影响至关重要。按服务分析事件,有助于识别产生大量事件的问题服务,突出与特定技术相关的重复问题,并支持问题管理中的趋势分析。

为什么重要

将事件关联到业务服务,对于分析影响以及识别最容易出现问题的服务至关重要。

获取位置

这是“HPD:Help Desk”表单中的“ServiceCI”字段,或表示受影响配置项(CI)的类似字段。

示例
企业电子邮件SAP ERP远程访问VPN人力资源门户
SLA目标日期
SlaTargetDate
根据SLA,预计应完成事件解决的日期和时间。
说明

该属性存储适用的服务级别协议(SLA)规定的事件解决期限。期限根据事件的优先级和规定的服务时间计算。

该时间戳是衡量实际解决时间的基准,对于计算“Incident SLA Compliance Rate”KPI和构建可视化SLA绩效的仪表板至关重要。它还支持主动监控即将到期的事件。

为什么重要

这是衡量SLA合规情况的基准,可用于判断事件是否按时解决或违反协议。

获取位置

这些数据通常存储在“SLM:Measurement”表单中,并与事件关联,而不是直接存储在“HPD:Help Desk”字段中。

示例
2023-10-26T14:00:00Z2023-10-27T09:00:00Z2023-11-01T17:00:00Z
关闭代码
CloseCode
关闭事件时选择的代码,用于表示解决结果。
说明

Close Code以结构化方式概括事件的解决情况。示例包括“Resolved by User”“No Fault Found”“Duplicate Incident”和“Permanent Fix Applied”。

该属性对于分析解决效果和结果非常有价值。它可以帮助识别未真正解决问题就关闭的事件,或突出显示用户经常自行解决问题的类别,从而发现改进知识库文章或自助服务工具的机会。

为什么重要

提供有关解决结果的结构化数据,帮助分析修复措施的有效性,并识别事件关闭方式的趋势。

获取位置

通常属于“HPD:Help Desk”表单中的解决或关闭信息。

示例
已远程解决重复问题用户操作错误无需采取措施
最后数据更新时间
LastDataUpdate
表示该事件数据最近一次从源系统刷新时间的时间戳。
说明

此属性记录最近一次数据提取的日期和时间,说明当前分析数据的新鲜度,有助于了解流程洞察的时效性。

了解最后更新时间对于报表和仪表板至关重要,因为它可以告知用户数据的及时程度,并帮助管理对最新事件活动是否已纳入的预期。

为什么重要

表示数据的新鲜度,确保用户了解流程分析及其产生的洞察截至何时。

获取位置

此值通常在数据提取(ETL)过程中生成并写入数据集。

示例
2023-11-01T02:00:00Z2023-11-02T02:00:00Z2023-11-03T02:00:00Z
影响
Impact
衡量事件对业务流程影响程度的指标。
说明

Impact用于评估事件对业务造成不利影响的程度。通常采用分级标准,例如“Extensive/Widespread”“Significant/Large”“Moderate/Limited”或“Minor/Localized”。

Impact与Urgency结合后决定事件的Priority。按影响程度分析,有助于了解哪些事件造成了最大的业务中断,而不受其技术复杂度影响。这对于确定流程改进工作的优先级至关重要。

为什么重要

帮助量化事件对业务造成的严重程度,是确定优先级和聚焦高影响问题分析的关键因素。

获取位置

这是“HPD:Help Desk”表单中的“Impact”字段(字段ID:1000000163)。

示例
1-广泛/大范围2-重大/大规模3-中等/有限范围4-轻微/局部
提交人
Submitter
最初报告事件的人员。
说明

Submitter是遇到问题并报告问题的最终用户或客户,与负责处理事件的受派人不同。

按提交人或其部门分析数据,有助于识别需要更多培训的特定用户群体,或受某类问题影响的群体。这为事件管理流程提供了以客户为中心的视角。

为什么重要

识别报告问题的用户,以便按用户部门、地点或角色进行分析,发现与用户相关的趋势。

获取位置

该信息记录在“HPD:Help Desk”表单的“Submitter”字段或客户信息相关字段中。

示例
John DoeJane SmithPeter Jones
根因
RootCause
导致事件发生的根本原因或最终原因。
说明

Root Cause是导致问题的根本因素。解决该因素后,事件便可避免再次发生。它通常在相关问题调查流程中确定。

并非所有事件都有记录在案的根因,但分析该属性对于主动开展问题管理至关重要。它支持“Root Cause Identification Rate”KPI,并有助于创建跟踪重复问题趋势的仪表板,从而指导实施永久性解决方案。

为什么重要

识别根因对于问题管理以及减少重复事件数量的分析至关重要。

获取位置

该信息可能记录在事件专用的“Root Cause”字段中,也更常见于关联的“PBI:Problem Investigation”表单中。

示例
服务器磁盘空间不足网络配置错误2.1版本中的软件缺陷安全证书已过期
渠道
Channel
用于报告事件的方式。
说明

该属性说明事件通过何种方式提交,例如电话、电子邮件、自助服务门户或现场直接报障。它表示事件进入支持流程的入口。

按渠道分析事件,可以发现哪些渠道最有效,以及哪些渠道产生的事件更容易或更难解决。这也有助于决定自动化或用户培训的投入方向,例如推广能够采集更完整初始数据的自助服务门户。

为什么重要

了解提交渠道有助于分析不同受理方式的效率,并指导自助服务或自动化方面的投入。

获取位置

这是“HPD:Help Desk”表单中的“Reported Source”字段(字段ID:1000000215)。

示例
电子邮件电话自助服务直接录入
源系统
SourceSystem
提取事件数据的系统。
说明

此属性用于标识数据来源,在包含多个ITSM工具或集成系统的环境中尤其有用。它可以确认数据来自预期来源,例如特定的BMC Helix ITSM实例。

在分析中,它有助于区分生产、开发或旧系统之间可能存在差异的流程或数据特征,确保数据血缘清晰可信。

为什么重要

标识数据来源,对于数据验证以及管理多个集成系统中的分析至关重要。

获取位置

通常是在数据提取、转换和加载(ETL)过程中添加的静态值。

示例
BMCHelixITSM_ProdITSM-EU-InstanceServiceManagement-APAC
解决说明
Resolution
对解决事件所采取步骤的自由文本描述。
说明

此字段包含人工编写的最终解决方案详细摘要,说明采取了哪些措施来修复问题并恢复用户服务。

虽然这类文本数据缺乏结构,但可以使用文本挖掘技术进行分析,以识别常见的解决模式,提取与特定问题相关的关键词,或补充根因分析。它提供了结构化数据字段通常缺少的定性背景。

为什么重要

提供解决方案的定性细节,可通过文本挖掘发现结构化数据中不可见的模式。

获取位置

这是“HPD:Help Desk”表单中的“Resolution”字段(字段ID:1000000156)。

示例
已通过Active Directory重置用户密码。已清除浏览器缓存和Cookie,登录问题已解决。已重启3B机房弱电间的网络交换机。
重新分配次数
ReassignmentCount
事件被重新分配给其他组的总次数。
说明

该指标统计事件生命周期内“AssignedGroup”字段发生变化的次数。次数较多通常表明初始路由存在问题、首次接触未能解决,或问题复杂,需要多个团队参与。

该属性直接支持“Incident Reassignment Rate”KPI和“Incident Reassignment Cycle Analysis”仪表板。它有助于量化工单在团队之间来回传递的“乒乓效应”,这种情况会造成明显延迟和流程低效。

为什么重要

量化低效路由和交接,帮助识别在团队间反复重新分配、陷入循环的事件。

获取位置

通过统计事件日志中指定Incident ID对应的“AssignedGroup”值变化次数计算。

示例
0135
必需 建议 可选

事件管理活动

以下是应纳入事件日志的关键流程步骤和里程碑,用于准确发现流程并可视化流程。
5 建议 9 可选
活动 说明
事件已关闭
这是最后一个活动,表示解决方案已确认或确认期已结束后,事件记录正式关闭。当状态设置为“Closed”时记录。
为什么重要

这是事件生命周期的最终结束事件。“Resolved”到“Closed”之间的时间代表用户确认和管理收尾阶段。

获取位置

此事件对应于“HPD:Help Desk”表单中的“Status”字段设置为“Closed”。时间戳记录在“Closed Date”字段和审计日志中。

采集

取自“Closed Date”时间戳或状态变更为“Closed”的时间。

事件类型 inferred
事件已报告
此活动表示系统中首次创建事件记录。它直接取自核心事件管理表单中的事件创建时间戳。
为什么重要

这是事件生命周期的主要开始事件,对于计算整体解决时长和了解事件到达率至关重要。

获取位置

此事件对应于“HPD:Help Desk”表单中的记录创建。时间戳通常取自“Submit Date”或“Reported Date”字段。

采集

取自HPD:Help Desk表单中的“Submit Date”时间戳。

事件类型 explicit
事件已解决
此活动表示从服务台角度看事件已正式解决,但尚未最终关闭。当事件状态设置为“Resolved”时记录。
为什么重要

这是衡量SLA合规性和解决时长最重要的里程碑,表示用户的服务已恢复。

获取位置

此事件对应于“HPD:Help Desk”表单中的“Status”字段设置为“Resolved”。时间戳记录在“Last Resolved Date”字段和审计日志中。

采集

取自审计日志中状态变更为“Resolved”的时间戳。

事件类型 inferred
已分配支持组
此活动表示事件首次被分配给特定支持组进行调查。通常根据事件创建后“Assigned Group”字段首次填充的时间推断。
为什么重要

这是表示主动处理开始的关键里程碑。跟踪首次分配所需时间,对于评估响应时长和初始路由效率至关重要。

获取位置

根据“HPD:Help Desk”表单的审计日志(“HPD:HelpDesk_AuditLogSystem”)推断,记录“Assigned Group”字段首次填充的时间。

采集

取自“Assigned Group”字段首次填充时的时间戳。

事件类型 inferred
调查已开始
表示支持人员已开始主动处理事件。通常根据状态从“Assigned”变更为“In Progress”来推断。
为什么重要

这一里程碑标志着事件从队列等待转入主动诊断。分析调查开始前的等待时间,有助于发现资源瓶颈,并支持“Diagnosis & Investigation Bottlenecks”仪表板。

获取位置

根据“HPD:Help Desk”表单中的状态变更推断。当“Status”字段变为“In Progress”时触发该事件,时间戳取自审计日志。

采集

根据HPD:HelpDesk_AuditLogSystem中状态变更为“In Progress”推断。

事件类型 inferred
SLA违约
这是一个计算得出的事件,当事件解决时间超过规定的服务级别协议目标时发生。通过比较解决时间戳与SLA到期日期得出。
为什么重要

此活动是“Incident SLA Performance Overview”仪表板和“Incident SLA Compliance Rate”KPI的基础,可直接标记未达到服务承诺的事件。

获取位置

通过比较“HPD:Help Desk”表单中的“Last Resolved Date”和“Target Date”(SLA到期日期)计算。如果事件尚未解决,则可以根据当前时间计算。

采集

计算得出的事件:当“Last Resolved Date”>“Target Date”时发生。

事件类型 calculated
事件已分类
表示事件已完成运营分类和产品分类,并已设置优先级。通常根据分类字段首次填充或最后修改的时间推断。
为什么重要

准确、及时的分类对于高效路由和报表分析至关重要。分析此活动有助于发现初始分诊中的延迟或错误,并支持“Incident Categorization Accuracy”仪表板。

获取位置

根据审计日志(“HPD:HelpDesk_AuditLogSystem”)推断,该日志记录了“HPD:Help Desk”表单中“Operational Categorization Tier 1-3”、“Product Categorization Tier 1-3”和“Priority”等字段的变更。

采集

取自创建后分类或优先级字段最后一次更新的时间戳。

事件类型 inferred
事件已取消
此活动表示因事件误创建或已不再相关而终止该事件。当事件状态设置为“Cancelled”时记录。
为什么重要

这是事件的终止状态,与成功解决不同。分析已取消事件,有助于发现事件创建渠道或重复报告方面的问题。

获取位置

当“HPD:Help Desk”表单中的“Status”字段更新为“Cancelled”时推断。时间戳记录在审计日志中。

采集

根据审计日志中状态变更为“Cancelled”推断。

事件类型 inferred
事件已重新打开
表示事件此前已标记为已解决,但因问题仍然存在而被重新激活。通常根据状态从“Resolved”变更回“In Progress”或“Assigned”等活动状态来推断。
为什么重要

此活动直接衡量返工情况和初始解决方案的有效性。重新打开的事件数量较多,通常表明修复质量不佳,并支持“Incident Rework Rate”KPI。

获取位置

根据审计日志(“HPD:HelpDesk_AuditLogSystem”),检测指定事件ID的“Status”从“Resolved”变更为“In Progress”或“Assigned”来推断。

采集

根据状态从“Resolved”变更为活动状态推断。

事件类型 inferred
已收到用户确认
表示用户主动确认所提供的解决方案已解决其问题。它可能是一个明确记录的事件,也可能根据关闭前的备注或相关系统操作推断。
为什么重要

跟踪此活动比单纯等待自动关闭更能准确反映用户验证过程。它有助于衡量“Average User Confirmation Time”KPI并发现沟通缺口。

获取位置

此活动可能难以可靠捕获。可以根据事件变为“Closed”前的工作日志条目或特定状态原因更新进行推断,可能需要分析“HPD:WorkLog”表单。

采集

根据关闭前的特定工作日志条目或状态原因更新推断。

事件类型 inferred
已转移至其他组
当事件从一个支持组重新分配至另一个支持组时,会发生此活动。通常通过检测首次分配后“Assigned Group”字段的变更来推断。
为什么重要

频繁转派通常表明初始路由错误或知识存在缺口。跟踪此活动对于“Incident Reassignment Cycle Analysis”仪表板和“Incident Reassignment Rate”KPI至关重要。

获取位置

根据审计日志(“HPD:HelpDesk_AuditLogSystem”)识别“HPD:Help Desk”表单中“Assigned Group”字段在首次填充后的后续变更,从而推断该活动。

采集

识别初始分配后“Assigned Group”字段的变更。

事件类型 inferred
等待客户输入
表示事件处理因等待用户提供信息或采取行动而暂停。通常根据状态变更为“Pending”来推断。
为什么重要

此活动有助于区分支持人员工作时间和客户等待时间。分析处于该状态的时长,对于了解用户响应延迟如何影响整体解决时长至关重要。

获取位置

当“HPD:Help Desk”表单中的“Status”字段更新为“Pending”时推断。具体原因通常记录在“Status_Reason”字段中。

采集

根据HPD:HelpDesk_AuditLogSystem中状态变更为“Pending”推断。

事件类型 inferred
等待用户确认
解决方案实施后,支持团队等待用户确认修复是否成功时,会发生此活动。通常由“Resolved”状态表示,此时自动关闭计时开始。
为什么重要

此活动对于“User Confirmation & Verification Delays”仪表板至关重要。它有助于量化提供修复方案到获得用户验证之间的延迟,这种延迟可能会人为延长事件生命周期。

获取位置

当“HPD:Help Desk”表单中的“Status”变为“Resolved”时开始。时长从“Last Resolved Date”计算,直到事件变为“Closed”或“Reopened”。

采集

状态变更为“Resolved”时开始,状态变更为“Closed”或“In Progress”时结束。

事件类型 inferred
解决方案已实施
此活动表示支持团队已应用修复方案或变通方案。通常在事件状态变为“Resolved”时推断。
为什么重要

这是表明解决方案已交付的关键里程碑,也是衡量调查完成后应用修复方案所需时间的重要数据点。

获取位置

通常在“HPD:Help Desk”表单中的“Status”变更为“Resolved”时推断。时间戳记录在“Last Resolved Date”字段和审计日志中。

采集

取自“Last Resolved Date”时间戳或状态变更为“Resolved”的时间。

事件类型 inferred
建议 可选

提取指南

如何从BMC Helix ITSM获取数据

准备好开始了吗?

借助此模板启动流程挖掘工作,从事件管理数据中发现有价值的洞察。立即开始优化运营。

立即解决BMC Helix ITSM中的重复事件!

将MTTR降低35%,消除SLA违约,提升用户满意度。

开始免费试用

无需信用卡。免费试用14天。