您的问题管理数据模板
您的问题管理数据模板
- 根因分析建议属性
- 关键流程里程碑和活动
- ServiceNow 数据提取逐步指南
问题管理属性
| 名称 | 描述 | ||
|---|---|---|---|
|
事件timestamp
EventTime
|
活动发生的准确日期和时间。 | ||
|
描述
记录系统中登记变更或动作的具体时间戳。该数据点是按时间顺序排列活动,以及计算流程步骤间周转时间(Cycle Time)和提前期(Lead Time)等指标的基础。
为何重要
对于事件排序和计算所有基于时间的 KPI 至关重要。
获取方式
审计/历史表中的 ServiceNow“sys_created_on”字段
示例
2023-10-12T08:30:00Z2023-10-12T14:45:12Z
|
|||
|
活动
Activity
|
对问题记录执行的具体事件或动作。 | ||
|
描述
代表问题记录生命周期中发生的具体步骤或状态变更。例如“问题记录已创建”、“根因已识别”或“已指派给支持组”。此属性对于构建流程图和可视化事件序列至关重要。
为何重要
它定义了流程图中的节点,从而实现工作流和流程变体(variants)的可视化。
获取方式
源自 '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 生产环境ServiceNow 欧洲、中东及非洲区
|
|||
|
优先级
Priority
|
分配给问题记录的优先级水平。 | ||
|
描述
指示问题的重要性和紧急程度,通常由影响度和紧急度计算得出。该属性允许按关键程度对分析进行细分,为“SLA 违约与优先级监控”仪表板提供支持。
为何重要
允许按业务关键性对流程绩效进行细分。
获取方式
ServiceNow“problem”表,“priority”字段
示例
1 - 紧急2 - 高3 - 中等
|
|||
|
关联事件数量
RelatedIncidentCount
|
链接到此问题记录的突发事件数量。 | ||
|
描述
通过计算关联的突发事件(Incident)数量来量化问题的影响。该字段的高计数值(尤其是对于“已知错误”)会直接反馈到“已知错误与事件重复发生”仪表板。
为何重要
衡量该问题对用户造成的影响程度。
获取方式
ServiceNow“problem”表,“related_incidents”字段(名称视配置而定)或关联记录计数
示例
1501200
|
|||
|
支持组
AssignmentGroup
|
负责解决问题的技术团队。 | ||
|
描述
指派当前负责该问题的具体支持小组或团队。该属性对“支持小组重新分派分析”仪表板至关重要,用于追踪团队间的交接并识别组织孤岛。
为何重要
对于识别跨部门瓶颈和分析交接效率至关重要。
获取方式
ServiceNow“problem”表,“assignment_group”字段
示例
网络运营数据库管理员服务台
|
|||
|
根因类别
RootCauseCategory
|
已识别根因的分类。 | ||
|
描述
对问题的底层原因进行分类,如软件漏洞、人为错误或硬件故障。该属性支持“根本原因分类准确性”仪表板,并有助于识别系统性故障模式。
为何重要
支持分析故障模式,以推动战略性改进。
获取方式
ServiceNow“problem”表,“rca_category”或“u_root_cause_category”字段
示例
软件缺陷配置错误供应商问题
|
|||
|
被分配用户
AssignedTo
|
被指派负责处理该问题的具体人员。 | ||
|
描述
识别当前负责问题记录的用户。分析此属性有助于了解工作负载分布、个人绩效以及人员层面的潜在瓶颈。
为何重要
分析资源效率和个人工作负载的关键。
获取方式
ServiceNow“problem”表,“assigned_to”字段
示例
Alice SmithBob Jones系统管理员
|
|||
|
重新分配次数
ReassignmentCount
|
问题在支持组之间重新指派的次数。 | ||
|
描述
用于追踪分派小组更改频率的计数器。这是“问题记录重新分派计数”KPI 的直接来源,有助于识别工单在团队间来回“踢皮球”的现象。
为何重要
流程摩擦和缺乏明确责任归属的直接指标。
获取方式
ServiceNow“problem”表,“reassignment_count”字段
示例
0312
|
|||
|
问题状态
ProblemState
|
问题记录的生命周期状态。 | ||
|
描述
反映问题记录的当前阶段,如“打开”、“根因分析”、“修复中”或“已关闭”。这是在“陈旧问题记录老化分析”中筛选和理解积压工作构成的核心要素。
为何重要
用于筛选未结与已结个案的主要状态指标。
获取方式
ServiceNow“problem”表,“state”字段
示例
新建Assess根因分析已解决
|
|||
|
PIR 结果
PostImplementationReviewResult
|
实施后评审 (PIR) 的结果或完成状态。 | ||
|
描述
存储 PIR 的结果或状态(如“已完成”、“不需要”、“等待中”)。该属性对于“实施后评审合规性”仪表板至关重要,用以确保重大问题均经过评审。
为何重要
用于确保从重大事件中吸取教训的质量控制指标。
获取方式
ServiceNow“problem”表,“pir_state”或类似的自定义字段
示例
已完成已放弃挂起
|
|||
|
RCA 时长
RootCauseAnalysisDuration
|
从创建问题到识别根因所耗费的时间。 | ||
|
描述
用于衡量调查阶段效率的计算时长。这直接支持“平均根本原因分析时间 (MTTRC)”KPI,并有助于识别技术能力差距或流程复杂度问题。
为何重要
调查阶段的关键效率指标。
获取方式
计算方式:“根本原因已识别”活动的时间戳减去“问题记录已创建”的时间
示例
3 days 4 hours12 小时
|
|||
|
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
|
|||
|
方案起草耗时
SolutionDraftingTime
|
从识别根因到提出方案之间的时间。 | ||
|
描述
跟踪在明确原因后开发修复方案的设计阶段时长。这为“方案起草与修复应用”仪表板提供支持。
为何重要
单独分析“修复设计”阶段的绩效。
获取方式
计算方式:“拟定解决方案已起草”的时间戳减去“根本原因已识别”的时间戳
示例
2 天4 小时
|
|||
|
是已知错误
IsKnownError
|
指示问题是否被分类为“已知错误”的标志。 | ||
|
描述
识别问题记录是否已转换或标记为“已知错误”。这对“已知错误与事件重复发生”分析至关重要,用于评估知识管理流程是否有效。
为何重要
区分活动调查与已接受并配有临时解决方案的缺陷。
获取方式
ServiceNow“problem”表,“known_error”字段
示例
truefalse
|
|||
|
等待时长
PendingDuration
|
问题处于挂起或等待状态的总时长。 | ||
|
描述
累计处于“等待供应商”或“挂起”等状态的时间。该指标用于“待处理状态与等待时间分析”,以区分内部处理时间与外部延迟。
为何重要
区分团队效率低下与外部依赖因素。
获取方式
计算方式:状态 = 挂起/待处理的各时间段时长总和
示例
5天0 分钟
|
|||
|
配置项
ConfigurationItem
|
受该问题影响的具体资产或服务。 | ||
|
描述
识别与问题记录关联的配置项 (CI)。分析此项有助于将问题与特定硬件、软件或服务相关联,为“根本原因分类准确性”仪表板提供支持。
为何重要
将流程问题链接到特定的物理或逻辑资产。
获取方式
ServiceNow“problem”表,“cmdb_ci”字段
示例
SAP ERP 服务器 01Exchange 邮件服务Oracle DB 生产环境
|
|||
问题管理活动
| 活动 | 描述 | ||
|---|---|---|---|
|
变更请求已发起
|
将变更请求 (RFC) 关联至问题记录的操作。这标志着工作从问题管理移交给变更管理进行实施。 | ||
|
为何重要
对“变更请求流转效率”仪表板至关重要。可识别出找到修复方案与启动变更流程之间的延迟。
获取方式
ServiceNow“sys_audit”表,跟踪“problem”表中“rfc”引用字段的填充情况。
捕获
在执行“创建常规变更”事务时记录
事件类型
explicit
|
|||
|
已应用永久修复
|
问题被标记为“已解决”的时刻,通常由关联的变更请求关闭触发。这表明技术工作已完成。 | ||
|
为何重要
确定活动修复周期的结束点。用于计算相对于 SLA 的总解决时间。
获取方式
ServiceNow“sys_audit”表,“state”字段流转至“已解决”(典型值为 106)。
捕获
比较状态字段的前后变化
事件类型
inferred
|
|||
|
已确定临时方案
|
在问题记录的“临时方案 (Workaround)”字段中输入文本的行为。它捕捉了分析师记录临时方案的确切时刻。 | ||
|
为何重要
通过确定技术方案的首选时间,为“临时方案发布绩效”仪表板提供支持。
获取方式
ServiceNow“sys_audit”表,其中“fieldname”为“workaround”。
捕获
比较状态字段的前后变化
事件类型
inferred
|
|||
|
已识别根因
|
填充“根因”代码或状态流转至“修复中”的时间点。这代表了对问题的成功诊断。 | ||
|
为何重要
计算平均根本原因分析时间,并支持“根本原因调查周期”仪表板。这是一个主要的流程里程碑。
获取方式
ServiceNow“sys_audit”表,跟踪“root_cause”类别字段的变更或状态流转至“修复中”。
捕获
比较状态字段的前后变化
事件类型
inferred
|
|||
|
指派给支持小组
|
将问题记录路由到特定技术团队进行调查的过程。该活动跟踪所有权流向,对分析交接环节至关重要。 | ||
|
为何重要
对于“支持小组重新分派分析”仪表板至关重要,用于识别团队间的乒乓效应和瓶颈。
获取方式
ServiceNow“sys_audit”或“sys_history_line”表,跟踪“assignment_group”字段的变更。
捕获
比较状态字段的前后变化
事件类型
inferred
|
|||
|
调查已开始
|
问题记录状态从“新建”流转至“评估”或“根因分析”。这标志着分析师已开始积极处理该问题。 | ||
|
为何重要
标记初始队列等待时间的结束和活动调查阶段的开始,支持“待处理状态”分析。
获取方式
ServiceNow“sys_audit”表,跟踪“state”字段的变更(例如,根据配置流转至值 102 或 103)。
捕获
比较状态字段的前后变化
事件类型
inferred
|
|||
|
问题记录已关闭
|
记录变为非活跃状态的最终生命周期事件。此后不再预期会有进一步的工作。 | ||
|
为何重要
流程实例的最终结束点。是计算总周转时间所必需的。
获取方式
ServiceNow“problem”表,“closed_at”字段或状态流转至“已关闭”。
捕获
在执行“关闭问题”事务时记录
事件类型
explicit
|
|||
|
问题记录已创建
|
在 ServiceNow 系统中首次创建问题记录。这标志着问题管理生命周期的开始,并为老化指标设定了基准时间戳。 | ||
|
为何重要
为所有周期计算和 SLA 测量建立起始时间。它是识别待调查问题数量的主要基准。
获取方式
ServiceNow“problem”表,“sys_created_on”字段。
捕获
在执行“新建记录”事务时记录
事件类型
explicit
|
|||
|
临时方案已发布
|
执行“传达临时方案”的操作,这会将临时方案推送到关联事件或创建已知错误文章。这不同于仅仅输入临时方案文本。 | ||
|
为何重要
对于衡量知识共享速度至关重要。此处的延迟会直接影响重复事件的数量。
获取方式
ServiceNow“sys_journal_field”或特定的 UI Action 日志;也可根据是否创建了类型为“已知错误”的“kb_knowledge”记录来推断。
捕获
在执行“传达临时解决方案”事务时记录
事件类型
explicit
|
|||
|
实施后评审 (PIR) 已完成
|
PIR 任务的完成或 PIR 标记的设置。这证实了已针对重大问题进行了回顾性分析。 | ||
|
为何重要
直接支持“实施后评审合规性”仪表板。高优先级问题若缺失此活动,则表示合规性失败。
获取方式
ServiceNow“problem_task”表 (type=PIR) 关闭,或“problem”表“pir_state”字段变更。
捕获
通过比较字段 X 和 Y 派生
事件类型
inferred
|
|||
|
拟议方案已起草
|
在“修复说明”或“解决代码”字段中输入数据。表明分析师已从理解原因转向设计永久性修复方案。 | ||
|
为何重要
通过隔离设计阶段的持续时间,为“方案起草与修复应用”仪表板提供支持。
获取方式
ServiceNow“sys_audit”表,跟踪“fix_notes”字段的更新。
捕获
比较状态字段的前后变化
事件类型
inferred
|
|||
|
状态变更为修复中
|
记录流转至表示正在构建或部署修复方案的状态(通常正在等待变更管理)。 | ||
|
为何重要
区分活动调查时间与“等待变更”时间,使瓶颈分析更加精确。
获取方式
ServiceNow“sys_audit”表,“state”字段流转至“修复中”(典型值为 104)。
捕获
比较状态字段的前后变化
事件类型
inferred
|
|||
|
解决已验证
|
确认解决方案有效的验证步骤。根据流程成熟度的不同,这可能是一个特定状态或一个复选框。 | ||
|
为何重要
在关闭前确保质量控制。跳过此步骤可用于“流程偏差”分析。
获取方式
ServiceNow“sys_audit”表。可以是状态变更(从“已解决”到“已关闭”),或是特定字段“u_resolution_verified”(如果已配置)。
捕获
比较状态字段的前后变化
事件类型
inferred
|
|||
|
评估被驳回
|
由于该问题无效,问题记录在评估阶段被退回至先前状态或取消。 | ||
|
为何重要
识别流程中将事件错误升级为问题的浪费环节。
获取方式
ServiceNow“sys_audit”表,“state”字段从“评估”流转至“已关闭/已取消”或“新建”。
捕获
比较状态字段的前后变化
事件类型
inferred
|
|||