您的问题管理数据模板
您的问题管理数据模板
这是我们针对问题管理的通用流程挖掘数据模板。使用我们针对特定系统的模板以获得更具体的指导。
选择特定系统- 适用于任何问题管理系统的通用框架。
- 为全面分析推荐的 data 字段和流程步骤。
- 开启您流程挖掘高效之旅的基础洞察。
问题管理属性
| 名称 | 描述 | ||
|---|---|---|---|
| Event 时间 EventTime | 特定活动发生的精确日期和时间。 | ||
| 描述 事件时间(Event Time)即时间戳,为问题生命周期中的每个活动提供了时间背景。它对于正确排序事件以及计算不同流程步骤之间的持续时间至关重要。 在流程挖掘中,此属性用于排列活动顺序、发现流程模型并执行所有基于时间的分析。它是计算诸如“平均根因调查时间”等关键绩效指标的基础,也能识别步骤之间的延迟,例如从识别根因到发起变更请求之间的交接时间。 为何重要 每个活动的时间戳对于事件排序和计算所有基于时间的指标(如周期时间和瓶颈持续时间)至关重要。 获取方式 此时间戳通常位于事件日志(event log)或审核跟踪表中,与活动名称和案例标识符并列。 示例 2023-04-15T10:22:05Z2023-11-20T14:05:30Z2024-01-08T09:00:11Z | |||
| 活动名称 ActivityName | 在问题管理生命周期中发生的特定事件、任务或状态变更的名称。 | ||
| 描述 活动名称(Activity Name)描述了问题管理流程中的单个步骤,例如“创建问题记录”、“识别根因”或“实施永久修复”。这些活动按时间顺序记录,以此构建出问题处理的完整故事。 对于流程挖掘,此属性对于构建流程图至关重要,它能直观地展示工作的实际流向。通过分析这些活动的顺序、频率和路径,有助于发现问题解决流程中的偏差、瓶颈和低效环节。 为何重要 此属性定义了流程中的步骤,支持流程流向的可视化和分析,包括常见路径和偏差。 获取方式 活动名称通常源自与主问题记录相关的状态变更日志、审计轨迹或事件表。 示例 调查已开始优先级已变更已提供临时解决方案问题记录已关闭 | |||
| 问题记录 ID ProblemRecordId | 问题记录的唯一标识符,代表问题管理流程的单个实例。 | ||
| 描述 问题记录 ID 是跟踪问题从创建到最终解决整个生命周期的主键。每个问题可能关联多个事件(incident),并被分配一个唯一的 ID 以与其他问题区分。 在流程挖掘中,此属性至关重要,因为它定义了 case,使工具能将所有相关活动归组为单个流程实例。分析流程流向、识别瓶颈以及计算 case 持续时间都依赖于对每个唯一问题记录的准确识别。 为何重要 这是核心的Case ID,它将所有相关事件分组,从而可以追踪每次问题调查的端到端历程。 获取方式 此标识符通常位于IT服务管理(ITSM)系统的主问题或工单表中。 示例 PRB0040332PROB-1298778103PM-5501 | |||
| 最后数据更新 LastDataUpdate | 指示数据上次从源系统提取或刷新的时间戳。 | ||
| 描述 此属性记录了最近一次数据抽取的日期和时间。它提高了分析数据的时效透明度,确保利益相关者了解分析所涵盖的时间范围。 在仪表板(Dashboard)和报告中,此信息对于提供背景至关重要。它能让用户知道自己看到的是实时信息还是特定时间点的快照,从而影响对“陈旧问题待办”等指标的解读。 为何重要 提供关于数据新鲜度的关键背景,确保分析和仪表板能根据最后一次数据刷新进行正确解读。 获取方式 此时间戳通常由ETL工具或脚本在数据提取过程中生成并存储。 示例 2023-10-01T06:00:00Z2024-02-20T08:00:00Z2024-03-15T05:30:00Z | |||
| 源系统 SourceSystem | 提取数据的应用程序或系统的名称。 | ||
| 描述 此属性标识了问题管理数据的来源,例如ServiceNow、Jira或自建的ITSM工具。在合并多个系统数据进行整体分析的环境中,这尤为重要。 在流程挖掘(Process Mining)背景下,“源系统”可用作过滤器,以比较不同业务单元或平台的流程性能和差异,并通过提供数据来源背景辅助数据验证和排障。 为何重要 识别数据来源,这对于数据验证以及跨不同系统或组织单元的流程比较至关重要。 获取方式 这通常是在数据提取过程中添加的静态值,用于标记来自特定源系统的记录。 示例 ServiceNowJira Service ManagementBMC 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)。如果问题的解决时间戳晚于SLA到期日,通常将其设置为true。 作为直接的结果衡量指标,此标志对于高层级仪表板和报告非常有用。在流程挖掘(Process Mining)中,它可用于创建合规性检查或过滤违规案例。分析违规与未违规问题的流程图,可以揭示导致SLA失败的常见模式、瓶颈或特定活动。 为何重要 为 SLA 合规性提供明确的成功或失败结果,从而可以轻松过滤和分析导致违规的流程路径。 获取方式 这通常是一个衍生或计算字段,通过将解决时间戳与SLA到期日进行比较来确定。 示例 truefalse | |||
| 优先级 Priority | 分配给问题的优先级水平,决定了调查和解决的紧急程度。 | ||
| 描述 优先级是根据业务影响和紧急程度对问题进行分类的关键属性。它帮助团队优先处理最关键的问题。优先级通常是标准化的,例如“极高”、“高”、“中”和“低”。 在流程分析中,优先级是一个强大的过滤和对比维度。分析师可以对比高优先级问题与低优先级问题的流程流向,查看它们的处理方式是否不同或更高效。它也是 SLA 合规性分析的基础,因为 SLA 通常与优先级挂钩。 为何重要 允许进行细分分析,以对比关键问题与常规问题的处理方式,这对于衡量 SLA 遵守情况至关重要。 获取方式 这是大多数ITSM平台主问题记录表中的标准字段。 示例 1 - 紧急2 - 高3 - 中4 - 低 | |||
| 受影响的服务 AffectedService | 受该问题影响的主要业务服务、应用程序或配置项(CI)。 | ||
| 描述 此属性将问题与IT基础设施中的特定组件或服务(如“电子邮件服务”或“客户关系管理平台”)关联起来,为技术问题提供关键业务背景。 在流程挖掘(Process Mining)分析中,“受影响服务”支持以业务为中心的流程视图,有助于回答如“哪些服务产生的问题最多?”或“影响关键财务系统的问题平均解决时间是多少?”等问题。这种背景对于根据业务影响确定改进优先级至关重要。 为何重要 通过将技术问题与其影响的服务相关联来提供业务背景,从而能够根据业务关键性进行优先级排序。 获取方式 这通常从配置管理数据库(CMDB)链接,并存储在问题记录的“配置项”或“服务”字段中。 示例 电子邮件与协作服务SAP ERP财务企业VPN主要客户网站 | |||
| 支持组 SupportGroup | 在给定时间内负责调查和解决问题的技术团队或部门。 | ||
| 描述 支持团队(Support Group)指示了分配给该问题的团队。随着问题的进展,它可能会在不同团队之间重新分配,例如从二线支持团队转交给专门的网络工程团队。 此属性对于分析团队绩效和团队间交接至关重要。流程挖掘可以突显由重新分配引起的延迟,衡量问题在每个团队停留的时间,并识别哪些团队在解决特定类型问题上最有效。它直接支持诸如“支持团队交接分析”等仪表板。 为何重要 对于分析团队绩效、识别由交接引起的瓶颈以及了解不同团队之间的工作量分布至关重要。 获取方式 此信息通常存储在ITSM系统内问题记录的指派历史或主详情表中。 示例 网络运维数据库管理三线应用支持安全团队 | |||
| 根因类别 RootCauseCategory | 导致问题的根本原因的最终分类。 | ||
| 描述 一旦调查完成,根因分类(Root Cause Category)就用于对问题的根本原因进行分类,例如“软件缺陷”、“硬件故障”或“配置错误”。这种分类对于战略改进至关重要。 此属性是“根因调查绩效”仪表板的基石。通过分析不同根因类别的发生频率,组织可以识别重复出现的系统性问题并优先处理长期修复。它有助于将重心从被动解决问题转向主动预防。 为何重要 这对于战略分析至关重要,有助于识别导致整个组织出现问题的系统性缺陷和趋势。 获取方式 此信息通常记录在问题记录的专用字段中,通常在关闭阶段之前或期间填写。 示例 配置错误软件缺陷硬件故障用户培训问题 | |||
| 相关事件计数 RelatedIncidentCount | 链接到该问题的单个事件记录的总数。 | ||
| 描述 此属性通过显示问题引起的面向用户的事件(incident)数量来量化其影响。相关事件数量较多的问题通常对业务的干扰更大。 此指标是优先级排序和影响分析的强大工具。在流程挖掘(Process Mining)中,它可用于将事件数量与调查时间或解决优先级关联。它帮助组织了解问题的规模,并通展示单一修复能防止多少事件发生,为投入问题管理的资源提供依据。 为何重要 量化问题的业务影响,有助于确定调查优先级并衡量解决效果。 获取方式 此值通常是问题记录上的计算字段,用于统计关联事件记录的数量。 示例 5281501 | |||
| 重新分配次数 ReassignmentCount | 问题记录在不同支持团队或个人之间重新分配的次数。 | ||
| 描述 此指标计算问题责任转移的次数。重新分配次数过多通常表示流程效率低下,例如初始路由错误或团队职责不明确。 在流程挖掘(Process Mining)中,这是流程摩擦的关键指标。它可用于识别问题在团队间反复转移的“乒乓球”现象。分析重新分配次数较多的案例可以揭示导致严重延误和精力浪费的知识缺口或流程缺陷。 为何重要 通过跟踪过多的交接来量化流程的低效,这通常指向错误的路由、知识差距或职责不清。 获取方式 这通常是一个计数器字段,随问题记录的每次指派更改而递增,也可以从事件日志(event log)中计算得出。 示例 0135 | |||
| 已提供临时解决方案 WorkaroundProvided | 用于标识是否已针对该问题确定并传达了临时权宜之计(workaround)的标记。 | ||
| 描述 此属性跟踪在开发永久性修复方案的同时,是否已提供临时解决方案以减轻影响。这是问题管理生命周期中的关键里程碑。 它是“规避方案有效性与速度”仪表板的核心属性。流程挖掘(Process Mining)可用于计算提供规避方案的平均时间,随后的分析可将方案提供与新关联事件的减少联系起来。这有助于衡量团队在修复根因前快速恢复服务的能力。 为何重要 指示服务是否已临时恢复,从而可以分析团队减轻业务影响的速度。 获取方式 这可以是一个布尔标志('WorkaroundPublished'),也可以根据规避方案详情字段中是否存在文本来推导。 示例 truefalse | |||
| 相关变更请求 ID RelatedChangeRequestId | 为实施该问题的永久修复而启动的变更请求标识符。 | ||
| 描述 此属性在问题管理流程与变更管理流程之间建立直接联系。当需要代码更改、硬件更换或其他修改来解决问题根因时,需使用此属性。 分析这一联系是理解“变更管理交接延迟”的关键。流程挖掘(Process Mining)可以衡量从识别根因到创建变更请求,以及从变更实施到最终关闭问题所需的时间。这有助于识别两个流程互动中的低效环节。 为何重要 将问题与其在变更管理中的解决方案相关联,从而能够分析交接延迟和端到端的解决生命周期。 获取方式 这通常是问题记录上的一个引用字段,链接到变更管理系统或模块中的相应记录。 示例 CHG0030219CR-8812CHANGE-401 | |||
| 被分配用户 AssignedUser | 当前负责管理该问题记录的个人用户或协调员。 | ||
| 描述 此属性识别在任何时间点负责该问题的具体人员。支持组定义了团队,而“指派用户”则指向处理调查的具体专员、工程师或协调员。 按“指派用户”进行分析有助于了解个人工作量、绩效和培训需求,能够突出显示某些个人是否成为瓶颈,或团队内的工作分配是否均衡。此视图是对支持组分析的补充。 为何重要 支持对个人工作量和绩效的分析,有助于识别表现优异者或可能需要额外支持或培训的人员。 获取方式 此字段通常位于主问题记录表中,标签通常为“代理人”(Assignee)、“指派给”(Assigned To)或“协调员”(Coordinator)。 示例 爱丽丝·约翰逊ajohnsonBob Smithbsmith | |||
| 问题状态 ProblemStatus | 问题记录当前的生命周期状态,例如“开启”、“调查中”或“已关闭”。 | ||
| 描述 问题状态(Problem Status)指示了问题在其工作流中所处的当前阶段。它提供了问题在任何给定时间点的快照,从最初记录到最终解决。 虽然活动名称捕获了状态变更的事件,但问题状态本身对于分析当前积压工作非常有用。它支持创建仪表板以显示每个状态下的未结问题数量,帮助管理工作负载并识别在特定阶段停滞过久的记录。 为何重要 指示问题的当前阶段,这对于积压分析以及识别停滞在特定阶段的问题至关重要。 获取方式 这是主问题记录表上的标准字段,随问题生命周期的推进而更新。 示例 未结根因分析等待变更已解决已结案 | |||
问题管理活动
| 活动 | 描述 | ||
|---|---|---|---|
| 已启动变更请求 | 此事件捕获了正式变更请求的创建或与问题记录的关联。它标志着从问题管理流程向变更管理流程的交接,以实施永久性修复。 | ||
| 为何重要 此活动对于分析问题诊断与启动修复之间的延迟至关重要。它有助于识别问题管理与变更管理交接处的瓶颈。 获取方式 这通常是在记录的关联或链接历史中发现的明确事件,显示了与变更记录的关联。 捕获 识别变更记录链接到问题记录的事件。 事件类型 explicit | |||
| 已实施永久修复 | 此事件表明永久性技术方案(通常通过变更请求管理)已成功部署,标志着补救工作的完成。 | ||
| 为何重要 此活动标志着解决方案实施阶段的结束。从变更启动到此时的时间衡量了变更管理流程在解决问题方面的效率。 获取方式 这通常根据问题记录状态变为“已解决”或“方案已实施”来推断,通常由关联变更请求的关闭触发。 捕获 从问题状态变更为“已解决”或从相关变更记录的完成时间戳中推断。 事件类型 inferred | |||
| 已提供临时解决方案 | 此事件表示临时解决方案或规避方案已记录并可用。此操作有助于在开发永久修复方案时减轻对最终用户的影响。 | ||
| 为何重要 提供权宜之计的时间是衡量团队快速恢复服务能力的关键 KPI。此活动有助于分析临时解决方案的速度和有效性。 获取方式 这可以通过“规避方案”文本字段首次填充的时间戳、记录的“沟通规避方案”操作或设置的特定“规避方案可用”标志来捕捉。 捕获 检测权宜之计字段的首次填充或相关的发布事件。 事件类型 explicit | |||
| 已识别根因 | 此活动标志着问题的根本原因已成功诊断并记录,代表了调查阶段的完成。 | ||
| 为何重要 这是衡量诊断效率的关键里程碑。从开始调查到识别根因的持续时间是问题分析的核心绩效指标。 获取方式 这通常通过状态更改为“已识别根因”来推断,或者在“根因”字段首次填入信息时捕捉。 捕获 捕获状态变更的时间戳,或“根因”文本字段的首次更新时间。 事件类型 inferred | |||
| 调查已开始 | 此事件标志着问题记录从新建或待处理状态转换为主动调查状态。它表明分析师已正式开始诊断该问题。 | ||
| 为何重要 此活动有助于衡量初始响应时间及待办事项处理速度。从创建到开始调查的持续时间是衡量团队响应能力的关键指标。 获取方式 这通常根据记录历史中的状态更改来推断,例如从“新建”变为“进行中”或“调查中”。 捕获 捕获状态首次变更为活跃调查状态的时间戳。 事件类型 inferred | |||
| 问题记录已关闭 | 这是生命周期中的最后一个活动,表示问题记录已在管理上关闭,不再预期有进一步操作。该案例被视为已完成并归档。 | ||
| 为何重要 此活动是大多数流程实例的主要终点。它对于计算问题管理流程的端到端总时长至关重要。 获取方式 这几乎总是从记录历史日志中状态更改为“已关闭”捕捉到的明确事件。 捕获 使用记录状态设置为“已关闭”时的时间戳。 事件类型 explicit | |||
| 问题记录已创建 | 这是问题记录的初始创建。它标志着问题管理流程的正式开始,并为后续分析建立了基准时间戳。 | ||
| 为何重要 此活动是每个流程实例的主要起点。分析从该事件到其他事件的时间,对于了解整体流程时长和前端延迟非常关键。 获取方式 这通常是从主问题记录或工单表的创建时间戳中捕捉的,几乎总是源数据中的显式字段。 捕获 使用主问题表中的“创建于”或类似的时间戳。 事件类型 explicit | |||
| 优先级已变更 | 此活动捕获了问题记录在初始创建后对优先级、影响或紧急程度的任何更新。它反映了对问题业务重要性的重新评估。 | ||
| 为何重要 分析优先级变更由于识别那些频繁升级或降级的问题,这些变更会影响资源分配和 SLA 合规性。 获取方式 这通常记录在审核日志或变更历史表中,用于跟踪对“优先级”字段的修改。 捕获 跟踪记录变更历史中对“优先级”字段的所有更新。 事件类型 explicit | |||
| 实施后评审已完成 | 此事件标志着事后评价(PIR)的完成。这一正式评审过程分析了问题的处理情况,以识别经验教训和流程改进点。 | ||
| 为何重要 跟踪PIR完成情况对于流程合规和持续改进非常重要。它确保捕获并利用重大问题中的宝贵见解。 获取方式 这通常通过PIR子任务的完成、状态更改为“评审完成”或填写PIR完成日期字段来捕捉。 捕获 识别 PIR 相关任务的完成或特定的状态更新。 事件类型 explicit | |||
| 已分配支持团队 | 此活动代表将问题记录指派或重新指派给特定的支持组或团队。它记录了调查所有权和责任的转移。 | ||
| 为何重要 跟踪指派对于分析交接延迟、识别团队间的瓶颈以及了解小组绩效至关重要。重新分配次数多往往意味着流程效率低下。 获取方式 此信息通常位于审核日志或历史表中,用于跟踪问题记录上“指派组”或“支持团队”字段的更改。 捕获 识别记录历史日志中分配组(assignment group)字段的所有变更。 事件类型 explicit | |||
| 检测到SLA超时 | 此事件表示达成解决或响应里程碑所需的时间已超过预定义的SLA目标,是一个由系统生成或计算的事件。 | ||
| 为何重要 跟踪SLA违规是绩效管理和合规报告的基础,它能直接突出显示未能满足服务水平承诺的案例。 获取方式 这可以是系统记录的特定标志或事件,也可以通过将解决时间戳与SLA到期日进行比较来计算。 捕获 通过比较解决或响应的时间戳与 SLA 目标时间戳来计算,或者捕获系统生成的违规事件。 事件类型 calculated | |||
| 等待变更实施 | 此活动表示问题记录处于挂起状态,正在等待相关变更请求完成。问题团队正在等待变更团队部署修复方案。 | ||
| 为何重要 隔离这段等待时间有助于准确衡量在变更管理流程与问题管理流程中各自花费的时间,从而提高责任归属的清晰度。 获取方式 这通常根据问题记录历史中向“待变更”或“修复进行中”状态的转换来推断。 捕获 捕获问题记录状态变更为反映其正在等待变更的时间戳。 事件类型 inferred | |||
| 解决已验证 | 此活动代表确认实施的修复已有效解决根因,且正常服务已恢复。这是关闭前的最终验证步骤。 | ||
| 为何重要 此步骤对解决方案进行质量检查。分析验证所需时间可以突出显示在确认修复成功方面的延迟。 获取方式 这可以是一个明确的状态,如“验证”(Verification),也可以从向“已解决”或“已处理”状态的转换中推断。 捕获 捕获状态变更为指示修复已确认的时间戳。 事件类型 inferred | |||
| 问题记录已取消 | 此活动代表在达成解决方案之前终止问题记录。这可能发生在记录创建错误、重复或不再相关的情况下。 | ||
| 为何重要 分析取消情况有助于了解录入问题记录的质量。高取消率可能表明需要更好的培训或更明确的认定标准。 获取方式 这是从记录历史中状态更改为“已取消”、“已拒绝”或“已撤回”捕捉到的。 捕获 捕获状态变更为最终取消状态的时间戳。 事件类型 explicit | |||
| 问题记录已重新开启 | 当之前已解决或已关闭的问题记录返回活动状态时,会触发此活动。这通常表示所实施的修复无效或问题再次发生。 | ||
| 为何重要 高重新打开率是解决质量不佳的关键指标。跟踪此活动对于衡量首次修复率以及识别无效解决方案至关重要。 获取方式 此事件通过监控记录的状态历史中从已关闭或已解决状态返回到打开或进行中状态的转换来捕捉。 捕获 识别从“已解决”或“已关闭”回到诸如“开启”等活跃状态的状态变更。 事件类型 explicit | |||