文章梳理 ITIL 知识管理从 v2 到 ITIL 4 的两次改版：2007 年确立为流程并附带 SKMS 架构，2019 年改称实践、不再规定做法，但未解决内容老化问题。文末给出以问题为单元、明确审核责任等维护要点。
名词释义｜ITIL：ITIL 全称 Information Technology Infrastructure Library（信息技术基础架构库），是一套关于 IT 服务管理（ITSM，IT Service Management）的最佳实践框架，源于 20 世纪 80 年代末英国政府部门对 IT 服务经验的总结，用于指导 IT 服务的规划、交付与持续改进。它不规定具体做法，只提供方向，现由 Axelos 维护，最新版本为 ITIL 4。
一位服务台分析师收到一张关于 VPN 推送失败的工单。她在知识库中检索，返回三篇文章：一篇写于 2023 年，涉及一家公司早已停用的客户；一篇与它结论相反；还有一篇自三月起一直停留在草稿状态。她读了中间那篇，半信半疑，最后还是打电话给网络团队。
避免这种情况，正是 ITIL 知识管理的目的，而相关指南已经两次改变形态。2007 年的版本把知识确立为正式流程，并为其配置了一套架构；2019 年的重写取消了这套架构，改称其为一项实践。两次调整各自都有合理的依据，但都不够充分。因为真正拖垮知识库的问题与结构无关：在实施项目结束很久之后，必须有人持续维护这些文章。
以下内容包括发展脉络、当前版本遗留的缺口，以及在机器先于人类阅读知识库的今天，必须由什么来填补这一缺口。
ITIL 中的知识管理是什么，为什么答案一直在变
ITIL 中的知识管理，是指捕获、存储并共享服务型组织所掌握的知识，使同一问题不会被重复解决。这一目的自 2007 年以来始终未变。发生变化的有两点，而且变了两次：知识管理被归入哪个部分，以及指南要求你为此做多少事。
ITIL v3 丛书于 2007 年发布，将知识管理确立为服务转换阶段中的正式流程，因此它拥有明确的负责人、定义清晰的输入与输出。2019 年 2 月发布的 ITIL 4，把该流程并入一般管理实践，并彻底取消了其中的子流程。
两个版本至今仍在使用。许多服务台虽然标着 ITIL 4，实际运行的却是 v3 形态的流程，因为认证的更新速度快于工具，更快于习惯。因此这个问题有两个诚实的答案：哪一种适用于你，取决于最近一次流程审计引用的是哪个版本，而非你持有的证书。
2007 年之前，ITIL 知识管理没有自己的归属
ITIL v2 大约在本世纪初问世，建立在两本核心书籍之上：服务支持与服务交付。两者都没有包含知识管理流程。知识当然依然存在，只是作为其他工作的副产品而存在，而非由某个明确的负责人专门维护。
那个时期最清晰的遗留物是已知错误数据库。问题管理会发现一个暂时无法修复的根本原因，将故障及其临时解决方案记录为已知错误，并期望服务台在升级之前先检索该记录。已知错误数据库能很好地完成自己的任务，但它在设计上范围很窄：它只收录故障，对其他内容一无所知，既不涉及如何配置邮箱，也不涉及退款期限，更无法告诉你现场工程师本季度用的是四款 VPN 客户端中的哪一款。
这个行业中大多数年过四十的人都能认出接下来发生的事。由于有流程负责、有审计核查，团队会把故障记录得井井有条；其他一切则散落在邮件往来、共享盘，以及那些资历最深的同事脑子里。这些人本身就是真正的知识库，而他们每年八月都会休假两周。
ITIL v3 把知识变成流程，并配了一套没人能买到的系统
2007 年的丛书直接针对这一缺口，2011 年的修订版收紧了措辞，但未改变整体形态。该流程有了名称和位置：知识管理，位于服务转换阶段，并附带两个概念。
第一是 DIKW 层级。数据变成信息，信息变成知识，知识变成智慧。作为运营模型，它略显单薄；但作为教学模型，它在一群从未区分过日志行与答案的人面前依然有价值。
第二是服务知识管理系统（SKMS）。在纸面上，它承载了一个服务型组织所知道的一切，位于配置管理系统与配置管理数据库之上，为任何需要的人呈现统一的视图。
这一构想很好，方向也对。问题在于，知识管理系统从来不是买家能够购买的东西，指南也从未假装它是：它描述的是一种逻辑架构，而非一款产品。然而供应商仍按这张图去销售，于是整整一代服务台最终拿到一款贴着 SKMS 标签的工具，而标签之下，不过是一个带有权限模型、搜索框大多只返回附件的 wiki。
ITIL 4 把流程变成实践，却不再告诉你该怎么做
2019 年 2 月，实践取代了流程，知识管理被归入一般管理实践，与持续改进和供应商管理并列。其目的完好保留，但机制没有保留，如今这项实践并未规定任何子流程。
如果你把它理解为一次退步，那就理解错了。有足够多的组织把 v3 流程当作合规任务来执行，以致各项交付物总能比价值存活得更久：一位名义上的知识经理、一场季度评审会、一张出现在指导幻灯片里的 SKMS 图，以及仍然转过身去询问身后同事的一线坐席。ITIL 4 之所以不再规定机制，是因为事实证明规定机制并未奏效。
它转而提供的是方向：从现状出发、持续改进、共创价值。这三条直觉都不错，但直觉不等于设计。你的组织仍须决定由谁撰写文章、由谁批准，须设定一篇文章可以搁置多久才必须处理，还须说明当产品团队在周四下午发布变更时该怎么办。
搜索“ITIL v4 知识管理”的人，通常是想透过术语问一个实际问题：周一早上我究竟该做什么？框架已经有意停止回答这个问题。任何答案如今只能来自需要它的组织内部，否则就不会出现。
ITIL 知识管理从不点名的失败：文章会腐烂
每一个版本的 ITIL 知识管理都在回答知识该放在哪里，却没有一个回答那个悄然杀死知识库的问题：内容衰减。
Gartner 在 2024 年 7 月至 8 月间调查了 187 位客户服务与支持负责人。其中 61% 手头积压着待修改的知识文章；值得注意的是，超过三分之一完全没有修订过时文章的正式流程。同一项调查显示，85% 的负责人计划在次年对面向客户的对话式生成式 AI 展开探索或试点。
这两个数字描述的是同一批组织。换句话说，内容层背负着维护欠账，而计划是直接把语言模型指向它。
内容过时并非新发现。麦肯锡全球研究院早在 2012 年就把其成本估算为接近每周工作时间的 20%，这是普通交互型员工用于寻找内部信息的时间占比。这个数字虽旧，却依然成立，因为其机制从未改变：当书面答案显得不可信时，人们就不再阅读，转而开口询问。
无人负责的审核节奏，是最先被放弃的东西
2019 年以来发布的大多数 ITIL 知识管理最佳实践，都会在清单里列出审核节奏。但其中明确指出由谁为此负责的却少得多，而这是一个知识治理问题，而非文档问题。结果，无人负责的节奏只是一条周期性日历邀请，而日历邀请永远比不过事件队列。
已知错误数据库是值得研究的反例。它能比之后每一次框架重写都活得更久，恰恰因为它同时具备两半：有流程负责它，也有触发器在无人排期的情况下生成条目——一个未解决的根本原因就会产生一条记录。审核节奏的运作方式并非如此，这就是忙碌团队最先悄悄放弃它的原因。
修正的迹象已经开始出现。Gartner 在 2025 年 12 月的一篇文章中再次谈及该主题，其调查覆盖 321 位负责人。在当年 9 月至 10 月间，58% 的人表示计划把坐席提升为知识管理专员。这些专员负责审查并整理内容。这是一个人事决策，而非框架决策，而这正是关键所在。
服务台知识管理系统在哪里是错的模型
这套指南也常被用于它从未考虑的工作，这一点值得直说，因为 ITIL 知识管理并不适用于每一个采用它的支持团队。
从根本上说，ITIL 是 IT 服务管理指南，它预设的读者是修复内部故障的内部技术员，几乎每一个设计决策都源自这一假设。而面向客户的支持遵循不同的经济逻辑：受众不了解产品，服务量高出一个数量级，语言要经得起一位紧张的新用户阅读，同一个答案还必须在聊天窗口、IVR 语音提示、帮助中心文章和坐席屏幕上都正确呈现。团队最终要把同一内容写四遍。
把客户内容塞进一个继承了上述假设的服务台知识管理系统，往往得到的是准确、可审计却在一线无法使用的文章。更适合这类工作的是知识中心化服务。服务创新联盟（Consortium for Service Innovation）基于一个简单前提建立了这套方法：解决问题的人在解决问题的同时撰写并改进文章。而那种由独立写作职能在数周后另行成文的做法，恰恰是该方法要取消的。现行指南为这种做法留有余地，但并未把它交到你手上。
对联络中心而言，其成败体现在管理层本就关注的指标上。良好的联络中心知识管理会体现在处理时长上，而非一份审计报告里。
Baklib 曾与一家《财富》500 强零售商合作，该零售商在 27 个国家运营超过 10,000 家门店。这次零售部署将处理时长缩短 13%，坐席错误率降低 30%，客户满意度提升 11%。
如今，机器会先于人类阅读 ITIL 知识管理
下一次转变已经在进行中。它改变的是好文章长什么样，而不是你把知识存在哪里。
检索系统阅读知识库的方式与分析师不同：它抽取的是片段，而非整页。一个由斯坦福大学主导的团队在 2023 年测试了语言模型如何使用长输入，发现当相关段落位于上下文开头或结尾附近时准确率最高；一旦模型必须在长文档中部定位该段落，准确率就会大幅下降。
因此，一篇标题为“计费：你需要知道的一切”的四千字文章，如今几乎是知识的最小可用单元里最糟的一种。它当然一直让时间紧迫的人很头疼，但对检索层来说更糟，因为检索层会从文章中部抽出一个自信满满的片段，并把你的品牌名一起附上去。
一篇文章只回答一个问题，并把答案放在开头
这里的要求并不花哨，主要属于编辑工作：一篇文章只回答一个问题，答案放在开头，结构要经得起切片，版本日期要有实际意义，治理要足够严格，确保一项已废止的政策在其替代版本上线六个月后不会再出现在索引里。这些正是框架一直在暗示的 ITIL 知识管理最佳实践，只是如今的失败代价更严厉。过去的过时文章只是浪费坐席的时间；如今它会以你的口吻直接回答客户，中间没有任何人把关。
总体而言，工具的价值正体现在这里。要寻找这样的知识管理软件：它能强制执行审核日期、追踪哪些文章被检索过，并显示客户实际提出了什么问题。AI 是否有帮助，主要取决于底层内容是否值得一读。
ITIL 知识管理并未告诉你谁负责审核队列。它已经两次用两套不同的措辞告诉你，这个队列很重要。而正是这一个决定，将决定下一个版本是否还有值得管理的东西。
常见问题
你们如何衡量知识管理的成功？
用业务已经在跟踪的成果来衡量，而不是用文章数量来衡量。有用的指标集合是首次联系解决率、平均处理时长、重复联系率、自助服务成功率，以及按时通过复审日期的文章占比。文章数量上升的同时质量却在下降，因此它是唯一值得忽略的数字。
什么是知识文章？
知识文章是针对单个问题的单一文档化答案，其形式设计让某人能够在需要的那一刻找到并使用它。在服务台场景中，它通常涵盖一个故障、一个流程或一项政策，并且带有明确的负责人和复审日期。与此同时，长度不是衡量标准。解决问题才是。
什么是知识中心服务？
知识中心服务，即KCS，是来自服务创新联盟的一种方法论。坐席在解决每个案例的过程中捕获并改进知识，而不是事后再单独撰写，因此知识库作为支持工作的副产品而增长。相比ITIL，它更适合高业务量的面向客户团队。
ITIL中的SKMS是什么？
SKMS，即服务知识管理系统，是ITIL v3中的一个概念，指一个逻辑存储库，容纳服务组织所知道的一切，分层位于配置管理数据库之上。ITIL 4随后弃用了这一术语。你仍然需要它所描述的东西，也就是一个单一可信的查找场所，尽管没有供应商能卖给你一张图。
提交反馈
