您的问题管理数据模板
您的问题管理数据模板
- 根因分析推荐属性
- 关键流程里程碑和活动
- ServiceNow分步提取指南
问题管理属性
| 名称 | 说明 | ||
|---|---|---|---|
|
事件时间戳
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
|
|||
问题管理活动
| 活动 | 说明 | ||
|---|---|---|---|
|
变更请求已启动
|
将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
|
|||
提取指南
立即优化问题管理,加快解决速度
借助流程挖掘,将调查周期缩短30%
无需信用卡,几分钟即可完成设置。