您的问题管理数据模板

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

您的问题管理数据模板

此模板为您在ServiceNow中分析ITIL问题管理生命周期提供完整蓝图。模板列出了需要收集的属性、需要跟踪的关键活动,以及数据项目的分步提取指南,帮助您全面了解流程,缩短平均解决时间并消除重复事件。
  • 根因分析推荐属性
  • 关键流程里程碑和活动
  • ServiceNow分步提取指南
刚接触事件日志?了解 如何创建流程挖掘事件日志.

问题管理属性

以下是建议纳入事件日志的数据字段,用于全面分析ITIL问题管理流程。
5 必需 7 建议 9 可选
名称 说明
事件时间戳
EventTime
活动发生的确切日期和时间。
说明

记录系统中记录变更或操作的具体时间戳。该数据点是按时间顺序排列活动,以及计算流程步骤之间周期时间和交付周期等时长指标的基础。

为什么重要

用于排列事件顺序并计算所有基于时间的KPI。

获取位置

ServiceNow审计表或历史表中的“sys_created_on”字段

示例
2023-10-12T08:30:00Z2023-10-12T14:45:12Z
活动
Activity
在问题记录上执行的具体事件或操作。
说明

表示问题记录生命周期中发生的不同步骤或状态变更。例如“问题记录已创建”“已识别根本原因”或“已分配给支持组”。此属性对于构建流程图和可视化事件顺序至关重要。

为什么重要

定义流程图中的节点,用于可视化工作流和流程变体。

获取位置

来源于“sys_audit”、“sys_history_line”表,或“problem”表中的状态变更

示例
问题记录已创建分析已完成状态已变更为已关闭
问题记录
ProblemNumber
问题记录的唯一标识符。
说明

ServiceNow中特定问题记录对应的唯一字母数字键,例如PRB000123。该标识符是连接所有流程活动的主线,从初始记录、根因分析一直到最终关闭。在流程挖掘分析中,此属性充当Case ID,用于重建问题解决的端到端过程。

为什么重要

它是区分不同案例并在流程图中归组相关事件的主键。

获取位置

ServiceNow的problem表,字段number

示例
PRB004512PRB009823PRB001122
最近数据更新时间
LastDataUpdate
数据提取或最近刷新的时间戳。
说明

表示用于分析的数据集时效性。它帮助分析人员判断当前查看的是实时数据还是历史快照,这对于正确解读未关闭案例状态至关重要。

为什么重要

确保用户了解数据的新鲜度,从而准确开展运营报告。

获取位置

ETL执行时的系统时间

示例
2023-11-01T12:00:00Z
源系统
SourceSystem
数据来源系统的名称。
说明

标识提取问题管理数据的具体ServiceNow实例或环境。在多系统环境中,这有助于追踪数据沿袭,并处理分析中的系统特定差异。

为什么重要

说明数据来源,尤其适用于合并多个ITSM工具的数据。

获取位置

提取期间硬编码,例如“ServiceNow Production”

示例
ServiceNow ProdServiceNow EMEA
优先级
Priority
分配给问题记录的优先级。
说明

表示问题的重要性和紧迫性,通常根据影响和紧急程度计算。此属性支持按关键程度细分分析,并用于“合规违约与优先级监控”仪表板。

为什么重要

支持按业务关键程度细分流程绩效。

获取位置

ServiceNow“problem”表中的“priority”字段

示例
1-严重2-高3-中等
关联事件数量
RelatedIncidentCount
与该问题记录关联的事件数量。
说明

通过统计与问题关联的事件数量,量化问题影响。对于已知错误,该字段中的高数量值会进入“已知错误与事件复发”仪表板。

为什么重要

衡量问题造成的用户影响规模。

获取位置

ServiceNow“problem”表中的“related_incidents”字段(字段名称可能不同),或关联记录数量

示例
1501200
已分配用户
AssignedTo
负责处理该问题的具体人员。
说明

标识当前负责问题记录的用户。分析此属性有助于了解工作负载分布、个人绩效以及资源层面的潜在瓶颈。

为什么重要

用于分析资源效率和个人工作负载的关键属性。

获取位置

ServiceNow“problem”表中的“assigned_to”字段

示例
Alice SmithBob Jones系统管理员
支持组
AssignmentGroup
负责解决问题的技术团队。
说明

指定当前负责该问题的具体支持组或团队。此属性对于“支持组重新分配分析”仪表板至关重要,可用于追踪团队间交接并识别组织孤岛。

为什么重要

对于识别部门间瓶颈和分析交接效率至关重要。

获取位置

ServiceNow“problem”表中的“assignment_group”字段

示例
网络运营数据库管理员服务台
根本原因类别
RootCauseCategory
已识别根本原因的分类。
说明

对问题根本原因进行分类,例如软件缺陷、人为错误或硬件故障。此属性为“根本原因分类准确性”仪表板提供数据,并帮助识别系统性故障模式。

为什么重要

支持分析故障模式,推动战略改进。

获取位置

ServiceNow“problem”表中的“rca_category”或“u_root_cause_category”字段

示例
软件缺陷配置错误供应商问题
重新分配次数
ReassignmentCount
问题在不同组之间重新分配的次数。
说明

用于记录分配组变更频率的计数器。该字段直接为“问题记录重新分配次数”KPI提供数据,并帮助识别工单在团队之间反复转派的“乒乓”现象。

为什么重要

流程摩擦和责任归属不清的直接指标。

获取位置

ServiceNow“problem”表中的“reassignment_count”字段

示例
0312
问题状态
ProblemState
问题记录的生命周期状态。
说明

反映问题记录的当前阶段,例如“开放”“根本原因分析”“修复进行中”或“已关闭”。这是筛选和了解“超期问题记录老化分析”中积压构成的主要依据。

为什么重要

用于筛选未关闭和已关闭案例的主要状态指标。

获取位置

ServiceNow“problem”表中的“state”字段

示例
新建评估根因分析已解决
PIR结果
PostImplementationReviewResult
实施后评审的结果或完成状态。
说明

存储PIR的结果或状态,例如“已完成”“无需评审”或“待处理”。此属性是“实施后评审合规性”仪表板的必要数据,可确保重大问题得到评审。

为什么重要

用于确保从重大事件中吸取经验的质量控制指标。

获取位置

ServiceNow“problem”表中的“pir_state”字段或类似自定义字段

示例
已完成已豁免待处理
SLA截止日期
SlaDueDate
根据SLA完成问题解决的目标日期和时间。
说明

表示必须解决问题以满足服务级别协议的时间戳。该时间戳是“合规违约与优先级监控”仪表板及合规率计算的基准。

为什么重要

计算SLA违约状态的基准。

获取位置

与问题关联的ServiceNow“task_sla”表

示例
2023-12-31T17:00:00Z
业务服务
BusinessService
受问题影响的高层级业务服务。
说明

表示面向业务的服务,例如“薪资服务”或“客户门户”,而非技术组件。该属性为利益相关方报告提供以业务为中心的视角。

为什么重要

将技术问题连接到业务价值流。

获取位置

ServiceNow“problem”表中的“business_service”字段

示例
网上银行内部电子邮件
临时解决方案已发布
WorkaroundPublished
表示是否已记录并共享解决方法。
说明

用于表示是否已识别临时修复方案,并将其发布到知识库或已知错误数据库的布尔值或状态标记。该属性支持“解决方法发布绩效”仪表板。

为什么重要

对于衡量最终修复前业务影响得到缓解的速度至关重要。

获取位置

ServiceNow“problem”表中的“work_around”字段(存在文本)或特定状态

示例
truefalse
变更请求编号
ChangeRequestNumber
为修复问题而发起的变更请求标识符。
说明

将问题记录关联到变更管理记录(RFC)。该关联对于“变更请求过渡效率”仪表板至关重要,可用于衡量从问题诊断到基础设施变更执行的交接速度。

为什么重要

追踪从问题管理到变更管理的过渡。

获取位置

ServiceNow“problem”表中的“rfc”字段

示例
CHG003001CHG004552
待处理时长
PendingDuration
问题处于暂停或待处理状态的总时长。
说明

汇总处于“等待供应商”或“搁置”等状态的时长。该指标用于“待处理状态与等待时间分析”,以区分内部处理时间和外部延迟。

为什么重要

区分团队效率问题与外部依赖。

获取位置

计算方式:状态为Pending或On Hold的时间区间时长之和

示例
5天0分钟
是否为已知错误
IsKnownError
表示问题是否被归类为已知错误的标记。
说明

标识问题记录是否已转换为或标记为已知错误。这对于“已知错误与事件复发”分析至关重要,可用于评估知识管理流程的有效性。

为什么重要

区分正在调查的问题与已接受且已有解决方法的缺陷。

获取位置

ServiceNow“problem”表中的“known_error”字段

示例
truefalse
解决方案起草时间
SolutionDraftingTime
从识别根本原因到提出解决方案之间的时间。
说明

追踪已知原因后制定修复方案的设计阶段时长。该指标支持“解决方案起草与修复应用”仪表板。

为什么重要

单独衡量“修复方案设计”阶段的绩效。

获取位置

计算方式:“Proposed Solution Drafted”的时间戳减去“Root Cause Identified”的时间戳

示例
2天4小时
配置项
ConfigurationItem
受问题影响的具体资产或服务。
说明

标识与问题记录关联的配置项(CI)。分析该属性有助于将问题与具体硬件、软件或服务关联起来,并支持“根本原因分类准确性”仪表板。

为什么重要

将流程问题关联到具体的物理或逻辑资产。

获取位置

ServiceNow“problem”表中的“cmdb_ci”字段

示例
SAP ERP服务器01Exchange电子邮件服务Oracle DB Prod
必需 建议 可选

问题管理活动

以下是建议在事件日志中记录的关键流程步骤和生命周期里程碑,用于准确发现问题工作流。
8 建议 6 可选
活动 说明
变更请求已启动
将Change Request(RFC)关联至Problem Record。这表示问题管理向变更管理交接,以实施修复。
为什么重要

对于Change Request Transition Efficiency仪表板至关重要,可识别发现修复方案到启动变更流程之间的延迟。

获取位置

ServiceNow的sys_audit表,用于跟踪problem表中rfc引用字段的填充。

采集

执行Create Normal Change事务时记录

事件类型 explicit
已分配至支持组
将问题记录路由至特定技术团队进行调查。此活动跟踪责任归属流转,对于分析交接至关重要。
为什么重要

用于Support Group Reassignment Analysis仪表板,以识别团队之间的来回转派和瓶颈。

获取位置

ServiceNow的sys_audit或sys_history_line表,用于跟踪assignment_group字段的变更。

采集

比较状态字段变更前后的值

事件类型 inferred
已识别临时解决方案
在问题记录的Workaround字段中输入文本。这记录了分析人员完成临时解决方案文档的时间点。
为什么重要

支持Workaround Publication Performance仪表板,用于确定技术解决方案首次已知的时间。

获取位置

ServiceNow的sys_audit表,其中fieldname为workaround。

采集

比较状态字段变更前后的值

事件类型 inferred
根因已识别
填充Root Cause代码,或状态变更为Fix in Progress的时间点。这表示问题已成功完成诊断。
为什么重要

用于计算Mean Time to Root Cause,并支持Root Cause Investigation Cycle Time仪表板,是重要的流程里程碑。

获取位置

ServiceNow的sys_audit表,用于跟踪root_cause类别字段的变更,或状态变更为Fix in Progress。

采集

比较状态字段变更前后的值

事件类型 inferred
永久修复已应用
问题被标记为Resolved的时间点,通常由关联Change Request关闭触发。这表示技术工作已完成。
为什么重要

确定主动修复周期的结束时间,用于根据SLA计算总解决时间。

获取位置

ServiceNow的sys_audit表,state字段变更为Resolved,通常对应值106。

采集

比较状态字段变更前后的值

事件类型 inferred
调查已开始
问题记录状态从New变更为Assess或Root Cause Analysis。这表示分析人员已开始主动处理问题。
为什么重要

标志着初始队列等待时间结束、主动调查阶段开始,并支持Pending State分析。

获取位置

ServiceNow的sys_audit表,用于跟踪state字段变更,例如根据配置变更为102或103。

采集

比较状态字段变更前后的值

事件类型 inferred
问题记录已关闭
生命周期的最终事件,记录变为非活跃状态,不再需要后续工作。
为什么重要

流程实例的明确终点,是计算总周期时间的必要条件。

获取位置

ServiceNow的problem表,closed_at字段或state字段变更为Closed。

采集

执行Close Problem事务时记录

事件类型 explicit
问题记录已创建
在ServiceNow系统中首次创建问题记录。这标志着问题管理生命周期的开始,并为老化指标设定基准时间戳。
为什么重要

为所有周期时间计算和SLA衡量设定开始时间,也是识别新增问题调查量的主要依据。

获取位置

ServiceNow的problem表,sys_created_on字段。

采集

执行New Record事务时记录

事件类型 explicit
临时解决方案已发布
执行Communicate Workaround操作,将临时解决方案推送至相关事件,或创建Known Error文章。这不同于仅输入临时解决方案文本。
为什么重要

对于衡量知识共享速度至关重要。此处的延迟会直接影响重复发生的事件量。

获取位置

ServiceNow的sys_journal_field或特定UI Action日志;也可以通过创建类型为Known Error的kb_knowledge记录推断。

采集

执行Communicate Workaround事务时记录

事件类型 explicit
实施后评审已完成
PIR任务完成或设置PIR标记。这确认已针对重大问题完成回顾性分析。
为什么重要

直接支持Post-Implementation Review Compliance仪表板。高优先级问题缺少此活动,表示未达到合规要求。

获取位置

ServiceNow的problem_task表中type=PIR的任务关闭,或problem表的pir_state字段发生变更。

采集

通过比较字段X与字段Y得出

事件类型 inferred
拟议解决方案已起草
向Fix Notes或Resolution Code字段录入数据。这表示分析人员已从理解原因转向设计永久修复方案。
为什么重要

支持Solution Drafting and Fix Application仪表板,用于单独衡量设计阶段的持续时间。

获取位置

ServiceNow的sys_audit表,用于跟踪fix_notes字段的更新。

采集

比较状态字段变更前后的值

事件类型 inferred
状态已变更为Fix in Progress
记录变更为表示修复正在构建或部署的状态,通常正在等待变更管理处理。
为什么重要

区分主动调查时间与等待变更时间,从而细化瓶颈分析。

获取位置

ServiceNow的sys_audit表,state字段变更为Fix in Progress,通常对应值104。

采集

比较状态字段变更前后的值

事件类型 inferred
解决方案已验证
确认解决方案有效的验证步骤。根据流程成熟度不同,这可能表现为特定状态或复选框。
为什么重要

在关闭前确保质量控制。跳过此步骤后,可以开展Process Deviation分析。

获取位置

ServiceNow的sys_audit表。可以是状态从Resolved变更为Closed,也可以是配置的特定字段u_resolution_verified发生变更。

采集

比较状态字段变更前后的值

事件类型 inferred
评估已拒绝
由于问题不成立,问题记录在评估阶段被退回至先前状态或取消。
为什么重要

识别事件被错误升级为问题所造成的流程浪费。

获取位置

ServiceNow的sys_audit表,state字段从Assess变更为Closed/Cancelled或New。

采集

比较状态字段变更前后的值

事件类型 inferred
建议 可选

提取指南

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

准备开始了吗?

立即下载完整模板,将问题管理数据转化为可执行的洞察。我们的团队将全程支持您的流程挖掘之旅。

立即优化问题管理,加快解决速度

借助流程挖掘,将调查周期缩短30%

开始免费试用

无需信用卡,几分钟即可完成设置。