问题管理中的 5 个为什么框架

使用 ServiceDesk Plus 实施问题管理框架

假设有一家名为 Zylker 的虚构医院,其 IT 基础设施相对典型。该医院的 IT 团队经常在工作高峰期遇到网络中断,这不仅干扰了日常运营,也影响了整体工作效率。虽然通过事件管理可以临时恢复网络服务,但如果缺乏问题管理来调查反复故障的根本原因,团队将面临持续且重复的干扰。问题管理的作用在于识别每次类似事件背后的根本原因——可能是老旧的固件、过时的驱动程序或网络拥堵问题。

本文将深入探讨问题管理在 IT 服务管理中的重要性,介绍包括“五问法”、鱼骨图和凯普纳-特雷戈在内的分析框架,并重点讲解如何使用 ServiceDesk Plus 实施“五问法”来简化问题解决流程。

什么是问题管理?

ITIL® 将问题管理定义为识别和管理重复性事件根本原因的过程,同时涵盖 IT 服务中潜在问题整个生命周期的管理。事件管理通常关注单一事件的处理,而问题管理则是一种更全面的策略,旨在防止事件重复发生,从而提升系统的长期稳定性。

为什么需要在 IT 基础设施中实施问题管理框架?

如果不使用问题管理框架进行根本原因分析,组织可能会面临以下问题:

  • 持续的系统宕机会影响业务流程,甚至导致收入损失,尤其是关键系统受到影响时;
  • 问题反复发生会给 IT 团队带来持续负担,使得事件在未彻底解决的情况下再次出现;
  • 服务频繁中断会造成生产力下降,影响服务交付质量;

持续的问题及其带来的工作压力将削弱员工士气,进而影响整体数字化体验。

关键问题管理框架

组织可以采用多种问题管理框架来诊断和解决 IT 问题。

每种框架都有其独特的分析路径和解决策略,能帮助 IT 团队准确识别并消除根本原因,防止类似事件再次发生,从而增强系统的可靠性。

借助这些框架,IT 团队能够构建高效的根本原因分析(RCA)流程,从而更好地理解和解决深层次问题。根据具体问题类型和组织需求,可以灵活选择适用的框架,以更系统地推进问题管理工作。

框架关键信息
五问法- 通过反复追问“为什么?”直到找出核心问题,以识别根本原因。
- 不止停留在表面症状,深入挖掘问题实质。
- 在跨职能协作中效果最佳,可获得多角度见解。
凯普纳-特雷戈(Kepner-Tregoe)- 一种结构化、系统化的方法,强调通过“是/不是”分析厘清问题。
- 包括评估现状、分析问题、制定决策及识别潜在问题。
- 适用于因素复杂、相互关联的 IT 环境。
鱼骨图- 可视化工具,用于对问题原因进行分类(如人员、流程、技术、环境)。
- 通过分解复杂问题,推动全面系统的分析。
- 常用于头脑风暴会议及主动或被动的问题管理中。
帕累托(Pareto)- 基于 80/20 法则,聚焦引发最多问题的关键少数因素。
- 有助于优先解决高影响问题,从而提高整体效率。
- 适合资源有限的团队,有效优化问题解决流程。

使用 ServiceDesk Plus 实施五问法框架

像 ServiceDesk Plus 这样的平台,使 IT 团队能够运用结构化框架(如五问法和鱼骨图法)来推进问题管理,从而识别并解决根本原因。这有助于打破“被动修复—再次中断”的循环,确保服务的持续性与用户信任。

我们以 Zylker 医院所面临的问题为例,说明如何应用五问法框架。五问法是一种灵活且实用的分析方法:通过连续追问“为什么?”以层层深入查找问题根源。它不仅操作简单,也可与其他分析工具(如鱼骨图)结合使用,因而非常适用于处理日常问题。以下为一个具体示例:

  • 第一次为什么:为什么网络中断了?
    因为在高峰时段,主网络交换机之一发生故障。
  • 第二次为什么:为什么交换机发生故障?
    因为该交换机已经过时,无法处理高流量的数据传输。
  • 第三次为什么:为什么仍在使用过时的交换机?
    因为预算分配中未纳入定期更换硬件的计划,同时缺乏主动的设备维护策略。

此处在未进行第五次“为什么”之前,根本原因已被明确识别。

以下是如何在 ServiceDesk Plus 中配置和使用“五个为什么”框架的详细步骤说明。

1. 创建五问法框架的自定义模板


首先,我们可以在 ServiceDesk Plus 中创建一个问题管理模板,用于引导 IT 人员完成五问法流程。该模板确保每个“为什么”的问题分析过程保持一致,并以结构化的方式记录回答及根本原因分析。用户可以为每个“为什么”及其识别的根本原因设置自定义字段。模板中包含立即原因、潜在原因和次要原因的字段,以及系统性问题和根本原因字段,方便全面记录问题信息。

要设置五问法模板,请转到「设置 > 模板及表单 > 问题模板 > 新建问题模板」。

如图 1 所示,我们为 Zylker 医院的 ServiceDesk Plus 实例创建了一个五问分析模板,并关联了生命周期,同时设置了五级“为什么?”字段。每个字段用于收集上下文数据,帮助技术人员更深入理解问题本质。所有字段均可设为必填。相关字段也可以合并成一个分组,方便管理。模板支持拖放操作,简化了设置流程。

图1:问题管理模板

通过表单规则,可以根据用户在模板中填写的内容动态显示或隐藏字段,进一步优化问题管理流程。系统可以逐步展示字段,响应用户输入,避免技术人员面对冗杂信息,从而保持模板的灵活性与可操作性。

例如,下面的表单规则设置了只显示第一个“为什么?”字段,并在用户填写后,才依次显示后续字段。这类设置帮助 Zylker 技术团队在采集数据时做到高效而个性化,针对具体问题显示所需字段,避免信息冗余并提升用户体验。Zylker 的技术人员设置的规则确保:只有填写第一个“为什么?”后,第二个才会显示;并在表单加载时隐藏所有后续字段。

要设置表单规则,请前往「设置 > 模板与表单 > 问题模板 > 新建问题模板 > 表单规则」。

图2展示了表单规则的界面和可用选项。

2. 设计包含必填字段和通知的生命周期


问题管理模板设置完成后,我们可在 ServiceDesk Plus 中创建一个生命周期,用于管理问题从初始分析到最终解决的全过程。此生命周期针对五问法框架设计,确保在推进到下一阶段之前,前一个“为什么”必须先被处理完毕。在各阶段完成后,系统还会发送通知提醒相关人员,提升透明度和责任落实。

生命周期规则还可用于自动更新字段,尤其当根本原因在第五个“为什么”之前就被明确识别时。通过设置每一级“为什么”为必填字段,我们确保每一阶段的过渡都有依据,保证问题分析的完整性。同时,自动通知机制能让所有利益相关者实时掌握问题进展,促进高效协作。

此外,规则还能自动触发与每个生命周期阶段相关的任务安排。这些配置可在问题工单中直观呈现,如图3所示。

要配置生命周期,请转到「设置 > 自动化 > 生命周期 > 新建生命周期」。

例如,当处理一个关于 Zylker 网络连接问题的工单时,生命周期中首先需要检查路由器、设备功能、驱动程序状态,并进一步判断问题出在连接设备还是网络端(如路由器)。这一结构化流程使整个问题排查过程更具条理,也提高了响应效率。

图3:生命周期配置

在问题处理工作流中,ServiceDesk Plus 支持通过切换必填字段来设置检查与平衡机制,确保每一步“为什么”分析都严谨可控。每个“为什么”的回答,以及当前阶段是否为最终“为什么”,都可以在系统中实现自动化配置。

图4:必填字段

如果技术人员在尚未进行完五次“为什么”分析之前就已找出根本原因,ServiceDesk Plus 可以通过表单规则自动更新后续字段,以便准确反映当前分析状态。

Zylker 的技术团队还设置了规则,当根本原因已识别时,后续阶段字段可自动填充为“根本原因已识别”,简化操作流程,如图5所示。

您可以在路径 设置 > 自动化 > 生命周期 > 新建生命周期 > 过渡 > 规则集 > 新建规则 中创建和编辑这些生命周期规则。

图5:生命周期规则

图中展示了围绕“五个为什么”逻辑所创建的任务,帮助技术人员循序渐进地推进问题根因分析。一旦模板填写完成且问题工单创建,系统即可分配相关任务,技术人员需按顺序完成这些任务来闭环工单。

您可以在 ServiceDesk Plus 的“问题”选项卡中选择某个问题工单,并切换至“任务”选项卡,在此点击“添加新任务”,如图6所示。

图6:创建的任务

3. 在 ServiceDesk Plus 中记录问题工单

完成“五个为什么”模板及生命周期配置后,您就可以为实际场景(如网络中断)创建问题工单。每一个“为什么”的回答都将作为问题工单内容的一部分进行记录,全面保留整个诊断链条的详细信息,并为后续的纠正措施提供清晰指引。

Zylker 医院的实践表明,在问题工单中以条目形式记录每个“五个为什么”的分析过程,有助于团队成员充分理解问题的根本原因分析路径,并形成标准化处理流程。

如果类似问题再次发生在其他区域或站点,团队成员可以查阅知识库和解决方案模块,参考既有的分析与处置措施,进而快速响应,提升问题解决效率。

4. 将事件与问题工单关联

为保证根本原因分析的全面性与精准性,可以将相关事件与问题工单建立关联。这一操作不仅提供了问题的上下文信息,有助于快速识别影响范围和优先级,还便于未来针对类似事件做出更加高效的响应。

如图所示,多个与网络中断相关的事件已被归集到同一问题工单下。这种集中视图帮助技术团队从宏观角度理解问题影响,突出了彻底解决根因的重要性。同时,系统支持将临时解决方案与最终解决方案进行分类保存并复用。

您可以在问题工单详情页面的右侧列查看关联信息,或在工单页面切换至“关联”选项卡。一个问题工单可同时与事件、变更请求,甚至引发该问题的发布版本建立联系。

Zylker 医院在网络中断工单中所建立的事件和变更关联关系,如图7所示。

图7:事件关联

5. 使用关闭规则确保问题被彻底解决

关闭规则可确保在关闭问题工单之前,所有必要步骤都已完成。例如,Zylker 设置的规则要求,所有相关任务必须被完成后,问题工单才可关闭。这种机制防止问题被草率结案,从而提高了问题管理的质量。

您可以通过路径:设置 > 自动化 > 关闭规则 > 切换关闭规则,来创建或编辑相应的关闭逻辑。

图8:关闭规则

6. 通过五问法框架生成问题分析报表

最后一步是借助报表功能追踪和评估使用五问法解决的问题案例。这类报表可揭示最常见的根本原因类型、五问法框架在特定问题类型上的应用效果,并帮助 IT 经理识别出需要更广泛预防措施或替代分析框架的趋势。

Zylker 所创建的报表展示了通过五问法解决的问题工单列表。报表中列出了问题状态、关闭原因、问题描述等核心字段,有助于 IT 团队总结经验、持续改进并进行趋势分析。

用户可以在报表选项卡中查看、筛选、分类保存各类报表,并灵活切换图表视图和表格视图,以适应不同场景的展示和沟通需求。

图9:问题管理报表

通过 ServiceDesk Plus 最小化停机时间

ServiceDesk Plus 基于 ITIL 框架,提供一整套由 AI 驱动的事件与问题管理功能,致力于将 IT 服务中断的影响降至最低。平台支持 IT 团队构建标准化的事件响应手册,帮助团队在面对突发事件时迅速响应并恢复服务运行。

此外,其问题管理模块能够支持技术人员批量处理相似类型的工单,甚至可直接从知识库中调用以往工单的成熟解决方案。这样不仅节省了排查和处理时间,还有效减少了系统停机时间,简化了整体问题解决流程。

欢迎立即开启 ServiceDesk Plus 免费试用,或预约个性化演示,了解它如何助力您在 IT 管理及更广泛的业务场景中构建智能、高效的服务体验。