您的问题管理数据模板
您的问题管理数据模板
- 根因分析的推荐属性
- 关键流程里程碑和活动
- 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)。该标识符贯穿整个流程,将从初始登记、根因分析到最终关闭的所有活动关联起来。在流程挖掘分析中,此属性用作案例ID,以便还原问题解决的端到端过程。
重要性
这是区分不同案例并在流程图中归组相关事件的主键。
获取途径
ServiceNow的“problem”表,“number”字段
示例
PRB004512PRB009823PRB001122
|
|||
|
上次数据更新时间
LastDataUpdate
|
数据提取或上次刷新的时间戳。 | ||
|
说明
说明分析所用数据集的时效性。分析人员可据此判断查看的是实时数据还是历史快照,这对正确解读未结案例状态至关重要。
重要性
让用户了解数据的新鲜度,以便准确开展运营报告分析。
获取途径
ETL执行时的系统时间
示例
2023-11-01T12:00:00Z
|
|||
|
源系统
SourceSystem
|
数据来源系统的名称。 | ||
|
说明
标识提取问题管理数据的ServiceNow实例或环境。在多系统环境中,此属性尤其有用,可用于追踪数据来源并处理分析中的系统差异。
重要性
说明数据来源,尤其适用于合并多个ITSM工具的数据。
获取途径
提取时写入固定值(例如“ServiceNow Production”)
示例
ServiceNow生产环境ServiceNow欧洲、中东和非洲地区
|
|||
|
优先级
Priority
|
分配给问题记录的优先级。 | ||
|
说明
表示问题的重要性和紧急程度,通常根据影响和紧急程度计算。此属性可按严重程度细分分析,支持“SLA违约与优先级监控”仪表板。
重要性
可按业务重要程度细分流程绩效。
获取途径
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”字段
示例
新建评估根因分析已解决
|
|||
|
SLA到期日期
SlaDueDate
|
根据SLA要求解决问题的目标日期和时间。 | ||
|
说明
表示必须解决问题以满足服务级别协议的时间戳。此时间是“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
|
|||
|
实施后评审结果
PostImplementationReviewResult
|
实施后评审的结果或完成状态。 | ||
|
说明
存储实施后评审(PIR)的结果或状态(例如“已完成”“无需评审”或“待处理”)。此属性是“实施后评审合规性”仪表板的必要数据,可确保重大问题得到评审。
重要性
用于确保从重大事件中吸取经验的质量控制指标。
获取途径
ServiceNow的“problem”表,“pir_state”字段或类似的自定义字段
示例
已完成已豁免待处理
|
|||
|
待处理时长
PendingDuration
|
问题处于暂停或待处理状态的总时长。 | ||
|
说明
汇总处于“等待供应商”或“暂停”等状态的时长。“待处理状态与等待时间分析”使用此指标,将内部处理时间与外部延误区分开来。
重要性
区分团队效率问题与外部依赖因素。
获取途径
计算方式:状态为“待处理”或“暂停”期间的时长总和
示例
5天0分钟
|
|||
|
是否为已知错误
IsKnownError
|
用于标记问题是否被归类为已知错误。 | ||
|
说明
标识问题记录是否已转为或标记为已知错误。此属性对于“已知错误与事件复发”分析至关重要,可用于评估知识管理流程的成效。
重要性
区分正在调查的问题与已接受且有临时解决方案的缺陷。
获取途径
ServiceNow的“problem”表,“known_error”字段
示例
truefalse
|
|||
|
解决方案拟定时间
SolutionDraftingTime
|
从确定根因到提出解决方案所用的时间。 | ||
|
说明
追踪确定原因后制定修复方案的设计阶段时长。此指标支持“解决方案拟定与修复实施”仪表板。
重要性
单独衡量修复方案设计阶段的绩效。
获取途径
计算方式:“拟定解决方案”时间戳减去“确定根因”时间戳
示例
2天4小时
|
|||
|
配置项
ConfigurationItem
|
受问题影响的具体资产或服务。 | ||
|
说明
标识与问题记录关联的配置项(CI)。分析此属性有助于将问题与特定硬件、软件或服务关联起来,并支持“根因分类准确性”仪表板。
重要性
将流程问题关联到具体的物理或逻辑资产。
获取途径
ServiceNow的“problem”表,“cmdb_ci”字段
示例
SAP ERP服务器01Exchange电子邮件服务Oracle生产数据库
|
|||
问题管理活动
| 活动 | 说明 | ||
|---|---|---|---|
|
关闭问题记录
|
生命周期的最后一个事件,表示记录已停用,不再需要后续处理。 | ||
|
重要性
流程实例的明确结束点,是计算总周期时间所必需的。
获取途径
ServiceNow的“problem”表中的“closed_at”字段,或“state”字段变更为“Closed”。
采集
执行Close Problem事务时记录
事件类型
explicit
|
|||
|
分配至支持组
|
将问题记录分派给特定技术团队进行调查。此活动用于跟踪责任流转,对分析交接情况至关重要。 | ||
|
重要性
支持组重新分配分析仪表板依靠此数据识别团队间的来回转派和瓶颈。
获取途径
ServiceNow的“sys_audit”或“sys_history_line”表,用于跟踪“assignment_group”字段的变更。
采集
比较状态字段变更前后的值
事件类型
inferred
|
|||
|
创建问题记录
|
在ServiceNow系统中首次创建问题记录。这标志着问题管理生命周期的开始,并为记录时长指标设定基准时间戳。 | ||
|
重要性
为所有周期时间计算和SLA衡量确定开始时间,也是识别问题调查数量的主要依据。
获取途径
ServiceNow的“problem”表、“sys_created_on”字段。
采集
执行New Record事务时记录
事件类型
explicit
|
|||
|
发起变更请求
|
将变更请求(RFC)关联至问题记录,表示工作从问题管理交接至变更管理,以便实施修复。 | ||
|
重要性
变更请求交接效率仪表板依靠此数据,识别找到修复方案到启动变更流程之间的延误。
获取途径
ServiceNow的“sys_audit”表,用于跟踪“problem”表中“rfc”引用字段的填写情况。
采集
执行Create Normal Change事务时记录
事件类型
explicit
|
|||
|
实施永久修复
|
问题标记为Resolved的时间,通常由相关变更请求关闭触发。这表示技术工作已完成。 | ||
|
重要性
确定主动修复周期的结束时间,用于计算相对于SLA的总解决时间。
获取途径
ServiceNow的“sys_audit”表,“state”字段变更为“Resolved”(通常值为106)。
采集
比较状态字段变更前后的值
事件类型
inferred
|
|||
|
开始调查
|
问题记录状态从“New”变更为“Assess”或“Root Cause Analysis”。这表示分析人员已开始处理问题。 | ||
|
重要性
标记初始队列等待时间的结束和主动调查阶段的开始,可用于分析待处理状态。
获取途径
ServiceNow的“sys_audit”表,用于跟踪“state”字段变更(例如,根据配置,值变为102或103)。
采集
比较状态字段变更前后的值
事件类型
inferred
|
|||
|
确定根因
|
填写“Root Cause”代码,或将状态变更为“Fix in Progress”时,表示问题已成功诊断。 | ||
|
重要性
用于计算平均根因确定时间,并支持根因调查周期时间仪表板,是流程中的重要里程碑。
获取途径
ServiceNow的“sys_audit”表,用于跟踪“root_cause”类别字段的变更,或状态变更为“Fix in Progress”。
采集
比较状态字段变更前后的值
事件类型
inferred
|
|||
|
识别临时解决方案
|
在问题记录的“Workaround”字段中输入文本,记录分析人员填写临时解决方案的时间。 | ||
|
重要性
为临时解决方案发布绩效仪表板提供数据,确定首次获知技术解决方案的时间。
获取途径
ServiceNow的“sys_audit”表,其中“fieldname”为“workaround”。
采集
比较状态字段变更前后的值
事件类型
inferred
|
|||
|
发布临时解决方案
|
执行“Communicate Workaround”操作,将临时解决方案发送至相关事件,或创建已知错误文章。这与仅仅输入临时解决方案不同。 | ||
|
重要性
此活动对于衡量知识共享速度至关重要。延误会直接增加事件复发数量。
获取途径
ServiceNow的“sys_journal_field”表或特定UI Action日志;也可根据是否创建了“Known Error”类型的“kb_knowledge”记录进行推断。
采集
执行Communicate Workaround事务时记录
事件类型
explicit
|
|||
|
完成实施后评审
|
完成PIR任务或设置PIR标记,确认已对重大问题进行回顾分析。 | ||
|
重要性
直接支持实施后评审合规仪表板。高优先级问题缺少此活动,表示未达到合规要求。
获取途径
ServiceNow的“problem_task”表中type=PIR的任务关闭,或“problem”表的“pir_state”字段变更。
采集
通过比较字段X和Y推导
事件类型
inferred
|
|||
|
状态变更为Fix in Progress
|
记录状态变更为正在构建或部署修复方案(通常需要等待变更管理)。 | ||
|
重要性
区分主动调查时间与“等待变更”时间,进一步细化瓶颈分析。
获取途径
ServiceNow的“sys_audit”表,“state”字段变更为“Fix in Progress”(通常值为104)。
采集
比较状态字段变更前后的值
事件类型
inferred
|
|||
|
评估未通过
|
评估阶段发现问题记录不符合有效问题的条件,因此将其退回到先前状态或取消。 | ||
|
重要性
识别将事件错误升级为问题所造成的流程浪费。
获取途径
ServiceNow的“sys_audit”表,“state”字段从“Assess”变更为“Closed/Cancelled”或“New”。
采集
比较状态字段变更前后的值
事件类型
inferred
|
|||
|
起草拟议解决方案
|
在“Fix Notes”或“Resolution Code”字段中输入数据,表示分析人员已从了解问题原因转向设计永久修复方案。 | ||
|
重要性
支持解决方案起草与修复实施仪表板,用于单独衡量方案设计阶段的耗时。
获取途径
ServiceNow的“sys_audit”表,用于跟踪“fix_notes”字段的更新。
采集
比较状态字段变更前后的值
事件类型
inferred
|
|||
|
验证解决结果
|
确认解决方案有效的验证步骤。根据流程成熟度,可能通过特定状态或复选框记录。 | ||
|
重要性
在关闭前进行质量检查。跳过此步骤可用于分析流程偏差。
获取途径
ServiceNow的“sys_audit”表。可以是状态变更(Resolved→Closed),也可以是已配置的特定字段“u_resolution_verified”。
采集
比较状态字段变更前后的值
事件类型
inferred
|
|||
数据提取指南
立即优化问题管理,加快问题解决
借助流程挖掘,将调查周期缩短30%
无需信用卡,几分钟即可完成设置。