一、ISO/IEC 20000-1:2018 8.6.3 标准原文
条款要求：组织应对问题进行管理，以防止事件发生、减少事件影响并防止重复发生。问题应被记录、分析、优先级排序，并在适当时建立已知错误和变更措施以实现永久解决。
二、标准条款解读说明
2.1 问题管理核心表
| 环节 | 说明 | 关键产出 |
|---|---|---|
| 问题识别 | 从重大事件、重复事件、趋势异常中识别问题 | 问题记录 |
| 根因分析 | 找出导致事件重复或高影响的真正原因 | 根因结论、影响分析 |
| 已知错误控制 | 在永久解决前提供临时绕行或控制方法 | 已知错误记录、临时措施 |
| 永久解决 | 通过变更等方式消除根因 | 解决方案、验证结果 |
2.2 核心理解
问题管理是组织摆脱重复救火的关键。事件管理解决的是“现在怎么恢复”，而问题管理解决的是“为什么总会再来”。如果没有问题管理，团队可能会非常忙，也能把很多事件快速处理掉，但同类事故、同类慢单、同类客户抱怨还是会一遍遍出现。
8.6.3强调两个重要概念：一是根因分析，二是已知错误管理。根因分析帮助组织从表象走向源头；已知错误管理则承认在永久解决方案到位前，组织仍需要一种透明、可控的临时应对方式。也就是说，问题管理并不要求一夜之间彻底修好所有问题，但要求组织知道问题在哪、影响什么、暂时怎么控、最终如何消除。
三、实施要点
3.1 建立问题识别入口
- 从重大事件、重复故障、趋势异常、客户投诉和审计发现中识别问题候选项。
- 明确什么情况下必须建问题单，例如同类事件重复出现、重大事件或高影响缺陷。
3.2 强化根因分析质量
- 采用5 Why、鱼骨图、时序分析等方法，避免停留在“人为失误”这类表层结论。
- 根因分析要覆盖技术、流程、人员、监控、文档和供应商等因素。
3.3 管理已知错误和临时措施
- 在永久解决前，提供可执行的规避步骤、监控手段和用户告知方式。
- 已知错误应被共享给服务台和一线处理团队。
3.4 将永久解决落到变更和验证
- 根因措施通常需要通过变更实施，应与变更管理联动推进。
- 永久解决后验证问题是否真正消除，防止“形式关闭”。
四、常用工具与实施方法
| 工具/方法 | 用途 | 输出 |
|---|---|---|
| 问题台账 | 统一管理问题状态 | 问题清单 |
| RCA方法 | 识别根因 | 根因分析报告 |
| 已知错误库 | 共享临时控制方案 | 已知错误记录 |
| 趋势分析 | 发现重复性问题 | 高频问题列表 |
| 变更联动机制 | 推动永久性解决 | 问题-变更跟踪关系 |
五、典型案例
案例一：重复性故障长期靠重启解决
某平台缓存异常每周发生一次，团队每次重启后都能快速恢复，于是一直未建问题单。后来组织通过8.6.3要求把重复事件转问题，最终发现是连接泄漏和监控阈值不合理共同导致，修复后故障彻底消失。
案例二：已知错误帮助一线快速止损
某业务系统在特定报表场景下存在已知缺陷，开发修复需两周。问题管理团队先建立已知错误记录和临时规避步骤，让服务台能够快速指导用户绕行，显著降低了投诉和重复排查成本。
案例三：跨团队问题清单推动长期治理
某企业核心链路涉及应用、中间件、数据库和网络团队，过去每次故障都能各自给出局部解释，却始终找不到长期根因。依据8.6.3建立跨团队问题台账后，组织要求重复事件必须以问题单形式统一跟踪，并为每项问题指定牵头人、已知错误、临时控制和永久解决路径。数月后，多项长期“顽疾”终于被逐步消除，重复故障显著下降。
很多团队其实并不缺分析能力，真正缺的是把问题正式拉出来、持续盯到关闭的治理机制。没有问题单、没有优先级、没有责任人、没有已知错误、没有与变更联动，再好的讨论也容易停留在会议纪要里。8.6.3 正是把“分析”升级为“治理”。
问题管理还必须平衡短期控制与长期解决。并非所有问题都能立刻修复，但组织至少应给一线一个可执行的已知错误方案，让事件处理不必每次都从头摸索。已知错误管理做得好，能在永久解决前显著降低用户损失和团队排查成本。
从管理节奏上看，问题管理最怕两种极端：一种是只在重大事故后才启动，导致大量高频小问题长期损耗无人治理；另一种是问题单开了很多，却缺少优先级和落地动作，最终台账越来越厚、价值越来越弱。成熟组织会根据影响和复发性聚焦最值得治理的问题，并持续追踪到永久解决验证完成。
审核8.6.3时，最值得关注的是问题与事件、变更、知识之间是否真正联动。一个成熟的问题单，通常应能追溯来源事件、关联临时绕行方案、推动必要变更并在解决后更新知识库。若这些关系断裂，问题管理往往仍停留在单点分析层面。
问题管理成熟后，组织会慢慢出现一个非常明显的变化，就是一线团队不再总被同类问题拖住。因为临时处置路径已经明确，根因治理也在持续推进，重复性事件会逐步减少，支持资源便能从旧问题中释放出来。
因此，问题管理并不是事件管理的附属收尾，而是服务组织能否从“持续救火”走向“持续减火”的关键分水岭。
很多组织在问题管理成熟前，常常误以为自己是“故障太多”。实际上更准确的描述往往是“同类故障太多、同类代价重复付出太多”。问题管理的价值，正是把这种重复损耗逐步压下去。
只要问题识别、已知错误和永久解决三条线能持续运转，组织就会越来越少被旧问题牵制，越来越多把精力投入真正新的风险和改进机会。
这也是为什么问题管理常常被视为服务成熟度的分水岭。会处理故障的团队很多，但能持续减少故障来源的团队并不多，而后者才真正体现了体系的进化能力。
因此，8.6.3 做得越深，组织越不容易在老问题上反复消耗，服务运行也越有机会从被动应对走向主动优化。
只要问题治理持续向前推进，服务团队就能逐步把旧问题留在过去，而不是把它们反复带进未来。
也就是说，问题管理真正减少的不是工单数量本身，而是那些本不该一再发生的重复损失。
当这种治理习惯稳定下来，服务组织就会越来越像在经营风险，而不是在被风险追着跑。
这正是问题管理能够真正拉开服务成熟度差距的地方。
问题治理越扎实，服务运行就越能摆脱旧故障的循环牵制。
长期看，这会显著提升体系韧性。
也能持续降低重复代价。
六、成文信息管理要求
- 保留问题记录、根因分析、已知错误记录、规避措施和永久解决验证记录。
- 保留问题来源依据，如事件趋势、重大事故复盘、投诉或审计输入。
- 问题与变更、知识库、服务报告之间应保持可追溯关系。
七、常见误区及踩坑提醒
| 误区 | 表现 | 正确做法 |
|---|---|---|
| 只有重大事故才建问题单 | 高频小问题长期无人治理 | 关注重复性和长期损耗问题 |
| 根因分析停留表面 | 结论总是“加强管理”“加强培训” | 追到技术、流程和机制层面 |
| 已知错误不共享 | 一线团队重复踩坑 | 建立共享和更新机制 |
| 问题关闭不验证 | 名义上解决，实际上问题仍在 | 通过数据和观察确认永久解决有效 |