问题管理数据模板
问题管理数据模板
这是适用于问题管理的通用流程挖掘数据模板。使用针对具体系统的模板,可获取更有针对性的指导。
选择具体系统- 适用于任意问题管理系统的通用框架。
- 为全面分析推荐的数据字段和流程步骤。
- 助您高效开启流程挖掘之旅的基础洞察。
问题管理属性
| 名称 | 说明 | ||
|---|---|---|---|
| 事件时间 EventTime | 特定活动发生的准确日期和时间。 | ||
| 说明 事件时间(即时间戳)为问题生命周期中的每项活动提供时间顺序信息。它对于正确排列事件以及计算不同流程步骤之间的持续时间至关重要。 在流程挖掘中,此属性用于排列活动、发现流程模型并开展各类时间分析。它也是计算“根本原因调查平均时间”等关键绩效指标的依据,还可用于识别步骤间的延迟,例如从识别根本原因到发起变更请求之间的延迟。 重要性 每项活动的时间戳对于排列事件顺序和计算周期时间、瓶颈持续时间等时间指标至关重要。 获取途径 此时间戳通常与活动名称和案例标识符一起存储在事件日志或审计跟踪表中。 示例 2023-04-15T10:22:05Z2023-11-20T14:05:30Z2024-01-08T09:00:11Z | |||
| 活动名称 ActivityName | 问题管理生命周期中发生的特定事件、任务或状态变更的名称。 | ||
| 说明 活动名称描述问题管理流程中的一个步骤,例如“问题记录已创建”“已识别根本原因”或“永久修复已实施”。这些活动按时间顺序记录,呈现问题的处理过程。 在流程挖掘中,此属性对于构建流程图至关重要,可直观呈现实际工作路径。分析活动的顺序、频率和路径,有助于发现问题解决流程中的偏差、瓶颈和低效环节。 重要性 此属性定义流程中的各个步骤,便于呈现和分析流程路径,包括常见路径与偏差。 获取途径 活动名称通常取自状态变更日志、审计跟踪记录,或与主问题记录关联的事件表。 示例 开始调查优先级变更提供临时解决方案关闭问题记录 | |||
| 问题记录ID ProblemRecordId | 问题记录的唯一标识符,用于代表问题管理流程中的单个实例。 | ||
| 说明 问题记录ID是跟踪问题从创建到最终解决整个生命周期的主键。每个问题都有唯一ID,以便与其他问题区分开来;一个问题可能关联多个事件。 在流程挖掘中,此属性至关重要,因为它用于定义案例,让工具将所有相关活动归为同一个流程实例。分析流程路径、识别瓶颈和计算案例持续时间,都依赖于正确识别每条问题记录。 重要性 这是关键的案例ID,用于归集所有相关事件,从而追踪每项问题调查的端到端过程。 获取途径 此标识符通常位于IT服务管理(ITSM)系统的主问题表或工单表中。 示例 PRB0040332PROB-1298778103PM-5501 | |||
| 数据最近更新时间 LastDataUpdate | 表示最近一次从源系统提取或刷新的数据时间戳。 | ||
| 说明 此属性记录最近一次提取数据的日期和时间,帮助了解所分析数据的新鲜度,确保相关人员清楚分析涵盖的时间范围。 在仪表板和报告中,这一信息是重要的背景依据。它能帮助用户判断查看的是实时信息,还是某个时间点的快照,从而正确解读“积压问题存量”等指标。 重要性 提供数据新鲜度的重要背景信息,确保根据最近一次数据刷新时间正确解读分析结果和仪表板。 获取途径 此时间戳通常由数据提取、转换和加载(ETL)工具或脚本在数据导入时生成并存储。 示例 2023-10-01T06:00:00Z2024-02-20T08:00:00Z2024-03-15T05:30:00Z | |||
| 源系统 SourceSystem | 提取数据的应用程序或系统名称。 | ||
| 说明 此属性标识问题管理数据的来源,例如ServiceNow、Jira或自建ITSM工具。在整合多个系统的数据进行全面分析时,这一属性尤为重要。 在流程挖掘中,可将源系统用作筛选条件,比较不同业务单元或平台的流程绩效和差异。它还可提供数据来源信息,帮助验证数据和排查问题。 重要性 标识数据来源,对于验证数据以及比较不同系统或组织单元的流程至关重要。 获取途径 此值通常在数据提取过程中作为静态值添加,用于标记来自特定源系统的记录。 示例 ServiceNowJira服务管理BMC Helix ITSMFreshservice | |||
| SLA到期日 SlaDueDate | 根据服务级别协议,预期完成问题解决的目标日期和时间。 | ||
| 说明 SLA到期日为问题解决设定正式目标。该目标通常根据问题优先级和服务级别协议(SLA)条款确定。 此属性是“SLA合规概览”仪表板的重要依据。通过比较实际解决时间与SLA到期日,组织可以计算SLA达标率。流程挖掘还可以进一步细分分析,找出对SLA违约影响最大的流程步骤或团队。 重要性 定义解决问题的目标,是衡量和报告SLA达标情况的依据。 获取途径 此日期通常根据问题的创建时间和优先级计算,并存储在问题记录中。 示例 2023-05-20T17:00:00Z2024-01-10T09:30:00Z2024-03-01T12:00:00Z | |||
| SLA已违约 SlaBreached | 用于标记问题解决时间是否超过指定SLA到期日。 | ||
| 说明 此布尔属性可直接显示是否达到服务级别协议要求。如果问题解决时间戳晚于SLA到期日,通常会将其设为true。 作为直接的结果指标,此标记非常适合用于高层级仪表板和报告。在流程挖掘中,可用它创建一致性检查,或筛选出所有违约案例。比较违约与未违约问题的流程图,可以发现导致SLA未达标的模式、瓶颈或常见活动。 重要性 清晰标示SLA是否达标,便于筛选和分析导致违约的流程路径。 获取途径 这通常是派生或计算字段,通过比较解决时间戳与SLA到期日确定。 示例 truefalse | |||
| 优先级 Priority | 问题的指定优先级,用于确定调查和解决的紧迫程度。 | ||
| 说明 优先级是根据业务影响和紧迫程度对问题进行分类的关键属性,可帮助团队优先处理最严重的问题。优先级通常采用统一标准,例如严重、高、中和低。 在流程分析中,优先级是重要的筛选和比较维度。分析人员可以比较高优先级与低优先级问题的流程路径,了解处理方式或效率是否存在差异。SLA通常与优先级挂钩,因此优先级也是SLA一致性分析的基础。 重要性 可按优先级细分分析,比较严重问题与常规问题的处理方式,也是衡量SLA达标情况的必要依据。 获取途径 这是大多数ITSM平台主问题记录表中的标准字段。 示例 1 - 严重2 - 高3 - 中4 - 低 | |||
| 关联事件数 RelatedIncidentCount | 与该问题关联的独立事件记录总数。 | ||
| 说明 此属性通过显示问题引发的面向用户事件数量来量化其影响。关联事件较多的问题通常会对业务造成更大干扰。 此指标有助于确定处理优先级和分析影响。在流程挖掘中,可用于分析事件数量与调查时间或解决优先级之间的关系。它能帮助组织了解问题的影响范围,并通过显示一次修复可避免的事件数量,说明问题管理投入的价值。 重要性 量化问题对业务的影响,帮助确定调查优先级并衡量解决方案的成效。 获取途径 此值通常是问题记录中的计算字段,用于统计关联事件记录的数量。 示例 5281501 | |||
| 受影响服务 AffectedService | 受问题影响的主要业务服务、应用程序或配置项(CI)。 | ||
| 说明 此属性将问题关联到IT基础设施中的特定组件或服务,例如“电子邮件服务”或“客户关系管理平台”,为技术问题补充重要的业务背景。 在流程挖掘分析中,受影响服务可用于从业务角度查看流程,帮助回答“哪些服务产生的问题最多?”或“影响关键财务系统的问题平均需要多久解决?”等问题。根据业务影响确定改进工作的优先级时,这些背景信息至关重要。 重要性 将技术问题与受影响的服务关联,提供业务背景,便于根据业务重要性确定处理优先级。 获取途径 此信息通常关联自配置管理数据库(CMDB),并存储在问题记录的“配置项”或“服务”字段中。 示例 电子邮件与协作服务SAP ERP财务企业VPN公司主网站 | |||
| 支持组 SupportGroup | 在特定时间负责调查和解决问题的技术团队或部门。 | ||
| 说明 支持组表示负责处理问题的团队。问题处理过程中可能会在不同小组间重新分配,例如从二线支持团队转交给网络工程专业团队。 此属性对于分析团队绩效和团队间交接至关重要。流程挖掘可以突出显示重新分配造成的延迟,衡量问题在各小组的处理时长,并识别最擅长解决特定问题的团队。它可直接用于“支持组交接分析”等仪表板。 重要性 对于分析团队绩效、识别交接造成的瓶颈,以及了解不同团队的工作量分布至关重要。 获取途径 此信息通常存储在ITSM系统的问题记录分配历史或主详情表中。 示例 网络运营数据库管理应用支持三级安全团队 | |||
| 根本原因类别 RootCauseCategory | 导致问题的根本原因的最终分类。 | ||
| 说明 调查完成后,使用根本原因类别对问题的根本原因进行分类,例如“软件缺陷”“硬件故障”或“配置错误”。这类分类对于制定改进策略至关重要。 此属性是“根本原因调查绩效”仪表板的核心。通过分析不同根本原因类别的出现频率,组织可以识别反复出现的系统性问题,并优先处理长期修复措施。这有助于将工作重点从被动解决问题转向主动预防。 重要性 对于战略分析至关重要,有助于识别组织内导致问题的系统性因素和趋势。 获取途径 此信息通常记录在问题记录的专用字段中,往往在关闭阶段之前或期间填写。 示例 配置错误软件缺陷硬件故障用户培训问题 | |||
| 重新分配次数 ReassignmentCount | 问题记录在不同支持组或个人之间重新分配的次数。 | ||
| 说明 此指标统计问题责任转交的次数。重新分配次数较多通常意味着流程效率低下,例如初始转派有误,或团队职责不明确。 在流程挖掘中,这是衡量流程阻力的关键指标,可用于识别问题在团队间来回转派的情况。分析重新分配次数较多的案例,有助于发现知识缺口或流程缺陷,这些问题可能造成明显延迟和资源浪费。 重要性 通过跟踪过多的交接来量化流程低效,这通常意味着转派有误、存在知识缺口或职责不清。 获取途径 这通常是问题记录中的计数器字段,每次变更分配时递增;也可以根据事件日志计算得出。 示例 0135 | |||
| 关联变更请求ID RelatedChangeRequestId | 为实施问题的永久修复而发起的变更请求标识符。 | ||
| 说明 此属性将问题管理流程与变更管理流程直接关联。当需要更改代码、更换硬件或进行其他修改以解决问题的根本原因时,会使用此属性。 分析这一关联有助于了解“变更管理交接延迟”。流程挖掘可以衡量从识别根本原因到创建变更请求所需的时间,以及从实施变更到最终关闭问题所需的时间,从而发现两个流程协作中的低效环节。 重要性 将问题与变更管理中的解决方案关联,便于分析交接延迟和端到端解决过程。 获取途径 这通常是问题记录中的引用字段,链接到变更管理系统或模块中的对应记录。 示例 CHG0030219CR-8812CHANGE-401 | |||
| 指定用户 AssignedUser | 当前负责管理问题记录的用户或协调人员。 | ||
| 说明 此属性标识在任一时间点负责处理问题的具体人员。支持组代表团队,指定用户则指负责调查的个人代理、工程师或协调人员。 按指定用户分析有助于了解个人工作量、绩效和培训需求,也能发现是否有人成为瓶颈,或团队内部的工作分配是否不均。这一视角可补充支持组分析。 重要性 便于分析个人工作量和绩效,帮助识别表现突出者,以及可能需要额外支持或培训的人员。 获取途径 此字段通常位于主问题记录表中,名称可能为“受派人”“分配给”或“协调人”。 示例 Alice JohnsonajohnsonBob Smithbsmith | |||
| 提供临时解决方案 WorkaroundProvided | 用于标记是否已为问题确定并传达临时解决方案。 | ||
| 说明 此属性跟踪是否已提供临时解决方案,以便在开发永久修复方案期间减轻问题影响。这是问题管理生命周期中的重要里程碑。 此属性是“临时解决方案的成效与速度”仪表板的重要依据。流程挖掘可用于计算提供临时解决方案的平均时间,并进一步分析提供临时解决方案后新增关联事件是否减少。这有助于衡量团队在根本原因修复前快速恢复服务的能力。 重要性 表示服务是否已暂时恢复,可用于分析团队减轻业务影响的速度。 获取途径 这可以是布尔标记(“WorkaroundPublished”),也可以根据临时解决方案详情字段中是否有文本推导得出。 示例 truefalse | |||
| 问题状态 ProblemStatus | 问题记录当前所处的生命周期状态,例如待处理、调查中或已关闭。 | ||
| 说明 问题状态表示问题在工作流中的当前阶段,呈现问题从最初记录到最终解决的进展情况。 活动名称记录状态变更这一事件,而问题状态本身适用于分析当前积压情况。您可以创建仪表板,查看各状态下的未解决问题数量,以便管理工作量,并识别在某个阶段停滞过久的记录。 重要性 表示问题当前所处阶段,对于分析积压情况和识别停滞在特定阶段的问题至关重要。 获取途径 这是主问题记录表中的标准字段,会随问题生命周期的推进而更新。 示例 待处理根因分析等待变更已解决已关闭 | |||
问题管理活动
| 活动 | 说明 | ||
|---|---|---|---|
| 关闭问题记录 | 这是生命周期中的最后一项活动,表示问题记录已完成行政关闭,后续无需采取行动。该案例视为已完成并归档。 | ||
| 重要性 这是大多数流程实例的主要终点,对于计算问题管理流程的端到端总时长至关重要。 获取途径 通常可从记录历史日志中状态变更为“已关闭”的明确事件获取。 采集 使用记录状态设为“已关闭”时的时间戳。 事件类型 explicit | |||
| 创建问题记录 | 这是问题记录的初始创建事件,标志着问题管理流程正式开始,并为后续分析提供基准时间戳。 | ||
| 重要性 这是每个流程实例的主要起点。分析此事件与其他事件之间的耗时,对于了解流程总时长和前期延误至关重要。 获取途径 通常可从主要问题记录表或工单表的创建时间戳中获取。源数据中几乎总会有明确的对应字段。 采集 使用主问题表中的“创建时间”或类似时间戳。 事件类型 explicit | |||
| 发起变更请求 | 此事件记录正式变更请求的创建,或其与问题记录的关联,标志着工作从问题管理流程移交至变更管理流程,以实施永久修复。 | ||
| 重要性 此活动对于分析问题诊断与修复发起之间的延误至关重要,有助于找出问题管理与变更管理交界处的瓶颈。 获取途径 通常可在记录的关联或链接历史中找到明确事件,显示问题记录与变更记录之间的关联。 采集 识别变更记录与问题记录建立关联的事件。 事件类型 explicit | |||
| 实施永久修复 | 此事件表示永久技术解决方案已成功部署,通常通过变更请求进行管理,标志着修复工作完成。 | ||
| 重要性 此活动结束解决方案实施阶段。从发起变更到此时的耗时,可衡量变更管理流程解决问题的效率。 获取途径 通常可根据问题记录状态变为“已解决”或“解决方案已实施”推断,关联变更请求关闭时也可能触发此状态。 采集 根据问题状态变为“已解决”推断,或使用关联变更记录的完成时间戳。 事件类型 inferred | |||
| 开始调查 | 此事件标志着问题记录从新建或待处理状态转为正在调查状态,表示分析人员已正式开始诊断问题。 | ||
| 重要性 此活动有助于衡量初始响应时间和积压处理速度。从创建记录到开始调查的耗时,是衡量团队响应速度的重要指标。 获取途径 通常可根据记录历史中的状态变更推断,例如从“新建”变为“处理中”或“调查中”。 采集 记录状态首次变为正在调查时的时间戳。 事件类型 inferred | |||
| 提供临时解决方案 | 此事件表示临时解决方案或权宜方案已记录并可供使用。在永久修复开发期间,这有助于减轻对终端用户的影响。 | ||
| 重要性 提供临时解决方案所需的时间,是衡量团队快速恢复服务能力的重要KPI。此活动有助于分析临时解决方案的提供速度和效果。 获取途径 可通过以下方式记录:首次填写“临时解决方案”文本字段、记录“传达临时解决方案”操作,或设置“临时解决方案可用”标记。 采集 检测临时解决方案字段首次填写的时间,或相关发布事件的时间。 事件类型 explicit | |||
| 识别根本原因 | 此活动标志着问题的根本原因已成功诊断并记录,代表调查阶段完成。 | ||
| 重要性 这是衡量诊断效率的重要节点。从开始调查到识别根本原因的耗时,是问题分析的关键绩效指标。 获取途径 通常可根据状态变更为“已识别根本原因”推断,也可记录“根本原因”字段首次填写信息的时间。 采集 记录状态变更的时间戳,或“根本原因”文本字段首次更新的时间戳。 事件类型 inferred | |||
| 优先级变更 | 此活动记录问题记录创建后优先级、影响程度或紧急程度的任何更新,反映问题业务重要性的重新评估。 | ||
| 重要性 分析优先级变更有助于发现频繁升级或降级的问题,这些变更可能影响资源分配和SLA达成情况。 获取途径 通常可在审计日志或变更历史表中找到相关记录,其中会跟踪“优先级”字段的修改。 采集 跟踪记录变更历史中“优先级”字段的所有更新。 事件类型 explicit | |||
| 分派支持组 | 此活动表示将问题记录分派或重新分派给特定支持组或团队,记录调查工作的责任转移。 | ||
| 重要性 跟踪分派情况对于分析交接延误、识别团队间的瓶颈和了解各组表现至关重要。重新分派次数过多通常意味着流程效率不高。 获取途径 通常可在审计日志或历史记录表中找到相关信息,这些记录会跟踪问题记录中“分派组”或“支持团队”字段的变更。 采集 识别记录历史日志中分派组字段的所有变更。 事件类型 explicit | |||
| 取消问题记录 | 此活动表示问题记录在得出解决方案前终止。可能是记录误建、重复,或已不再相关。 | ||
| 重要性 分析取消情况有助于了解问题记录的质量。取消率较高可能意味着需要加强培训或完善资格审核标准。 获取途径 此事件根据记录历史中状态变更为“已取消”“已拒绝”或“已撤回”来捕获。 采集 识别状态变更为最终取消状态的时间戳。 事件类型 explicit | |||
| 完成实施后复盘 | 此事件标志着实施后复盘(PIR)完成。该正式复盘流程会分析问题的处理过程,总结经验教训并提出流程改进措施。 | ||
| 重要性 跟踪PIR完成情况对于流程合规和持续改进十分重要,可确保重大问题带来的宝贵洞察得到记录并付诸行动。 获取途径 通常可通过PIR子任务完成、状态变更为“复盘完成”,或填写PIR完成日期字段来记录。 采集 识别PIR相关任务的完成事件或特定状态更新。 事件类型 explicit | |||
| 检测到SLA违约 | 此事件表示,达到解决或响应里程碑所用的时间已超过预先设定的服务级别协议(SLA)目标。该事件由系统生成或计算得出。 | ||
| 重要性 跟踪SLA违约情况是绩效管理和合规报告的基础,可直接指出未达到服务级别承诺的案例。 获取途径 这可以是系统记录的特定标记或事件,也可以通过比较解决时间戳与SLA到期时间计算得出。 采集 比较解决或响应时间戳与SLA目标时间戳进行计算,或捕获系统生成的违约事件。 事件类型 calculated | |||
| 等待实施变更 | 此活动表示问题记录处于暂停状态,等待关联的变更请求完成。问题团队正在等待变更团队部署修复方案。 | ||
| 重要性 单独识别这段等待时间,有助于准确衡量变更管理流程与问题管理流程各自耗时,明确责任归属。 获取途径 通常可根据问题记录历史中的状态变更推断,例如变为“待变更”或“修复处理中”。 采集 记录问题记录状态变为等待变更时的时间戳。 事件类型 inferred | |||
| 重新打开问题记录 | 此活动发生在先前已解决或已关闭的问题记录重新回到活跃状态时,通常表示已实施的修复无效,或问题再次发生。 | ||
| 重要性 重新打开率偏高是解决质量不佳的重要信号。跟踪此活动对于衡量一次解决率和识别无效方案至关重要。 获取途径 通过监控记录状态历史,识别状态从已关闭或已解决重新变为打开或处理中时,即可记录此事件。 采集 识别状态从“已解决”或“已关闭”重新变为“打开”等活跃状态的变更。 事件类型 explicit | |||
| 验证解决结果 | 此活动表示已确认实施的修复有效解决了根本问题,服务也已恢复正常。这是关闭记录前的最后验证步骤。 | ||
| 重要性 此步骤用于检查解决质量。分析验证所需时间,有助于发现确认修复效果时的延误。 获取途径 可通过明确的“验证中”状态记录,也可根据状态变为“已解决”或“已修复”推断。 采集 记录状态变为表示修复已确认的时间戳。 事件类型 inferred | |||
数据提取指南
不同系统的数据提取方式各不相同。详细说明请
现在就改进问题管理
借助数据洞察发现低效环节,更快解决问题。
无需信用卡,几分钟即可完成设置。