一、ITIL 第5版已经来了，你得先决定“用哪套语言开会”


2026年1月29日，PeopleCert正式发布了ITIL 第5版。作为ITIL官方中国区产品大使，我将会推出系列文章帮大家解读ITIL 第5版到底有哪些重大的更新。

对产品负责人和 IT 负责人来说，这个时间点不是“教材上新”的提醒，而更像一个信号：接下来几年，组织讨论数字化工作的共同语言会加速变化。你可以选择不跟，但你很难不被影响——因为当上下游、供应商、合作伙伴、客户组织都开始用“数字化产品和服务管理”的叙事来讨论交付与治理，你继续只用“IT服务管理”的语言，很容易在对齐上吃亏。


这里的“吃亏”不是术语不够时髦，而是你会在三个关键场景里变得被动：

• 做路线图 (roadmap) 时，你说的是“服务改进”，对方要的是“产品演进”；你说的是“运维稳定”，对方要的是“服务体验”；双方对“成功”的定义不一致，验收准则自然也对不齐。
• 做跨部门协作时，你说“流程要遵守”，对方说“价值流要流动”；你强调“审批要完整”，对方强调“周期时间要缩短”；会议越开越久，行动越变越少。
• 做治理 (governance) 与被问责 (accountability) 时，你能管住IT内部交付，却管不住端到端体验；事故发生后，责任链断裂，谁都说自己“那一段没问题”。
  

所以，本篇要讲清楚一个核心：从IT服务管理到数字化产品和服务管理，不是把“服务”两个字换成“产品”两个字，而是把你看待工作的视角，从“交付一项服务”换成“持续经营一条价值链”。




二、你以为你在管“服务”，但业务真正感知的是“产品 + 服务”的一体体验


先做一个非常现实的拆解。很多组织嘴上说“我们是产品化”，但日常协作仍按老模式运行：

• 业务团队提需求 (business needs)，IT 立项，研发构建，发布上线，运维接管，服务台处理事件。
  

这条链路看起来合理，也确实运转了很多年。但在数字化场景里，它会暴露一个根本问题：用户并不把你的价值切成“产品价值”和“服务价值”，用户只感知一件事——体验是否连贯、是否可靠、是否值得信任。
当用户体验 (UX) 与客户体验 (CX) 成为关键结果，你会发现“服务是否可用”只是底线，远远不够。

• 你提供了一个数字化产品 (digital product)，但登录、支付、客服、交付、退款、升级这些触点 (touchpoint) 任何一段割裂，体验就会被打碎。
• 你提供了一个数字服务 (digital service)，但它背后依赖的平台、数据、算法 (algorithm)、流程、供应商与支持团队只要协同不到位，服务体验就会出问题。
  

这就是为什么 ITIL 第5版要把叙事升级为数字化产品和服务管理。它其实在告诉你：不要把“产品”理解成研发的事，也不要把“服务”理解成运维的事。产品与服务是一体的，你要管理的是贯穿整个生命周期 (lifecycle) 的价值创造与风险控制，而不是某一个部门的局部交付。

三、对比一下：ITIL 4 常见落地方式为什么会“够用但不够好”


我不喜欢把新旧版本写成“谁先进谁落后”。更符合现实的说法是：ITIL 4 解决了很多组织“把服务管理做起来”的问题，但当数字化走到产品化与生态化阶段，它的常见落地方式会出现边界天花板。
1、在ITIL 4 的语境里，很多组织的改进重点仍然围绕交付与支持
你会看到大量投入放在事件管理、变更实施、服务台、SLA、度量与报告上。这些当然重要，而且是基本功。但它们往往把注意力锁在“上线之后”的世界里：运营是否稳定、故障是否减少、SLA 是否达标。
2、为什么不够
当业务增长依赖数字化能力时，价值并不只产生在“上线之后”，而是产生在“发现机会、定义价值、设计体验、选择能力来源、构建与发布策略、运营与支持协同”这一整条链路上。你如果只在后半段用力，前半段欠账会以更昂贵的方式回到你身上：

• 需求定义不清，验收准则模糊，最后只能靠加班补救。
• 体验没在设计阶段被认真对待，上线后你会用事故与投诉来支付学费。
• 自建与采购 (procurement) 决策缺乏统一方法，最后变成技术孤岛 (silo) 与供应商锁定。
• 价值流 (value stream) 被职能边界切碎，交付周期 (lead time) 拉长，组织速度 (velocity) 下降。
  

3、ITIL 第5版补齐了什么
它用“数字化产品和服务管理”的定位，把管理视角推回到端到端；并用更清晰的生命周期模型与治理语言，让你能把“产品演进”和“服务经营”放在同一张图上讨论。




四、ITIL 第5版的核心动作：把“端到端”写进生命周期模型，让你能用活动来对齐协作


如果你要快速抓住 ITIL 第5版的骨架，我建议你先记住它的八个生命周期活动 (activity)。这八个词不是为了考试好看，而是为了让跨职能讨论有共同坐标系：

• 发现 (Discover)
• 设计 (Design)
• 获得 (Acquire)
• 构建 (Build)
• 转换 (Transition)
• 运营 (Operate)
• 交付 (Deliver)
• 支持 (Support)
  

为什么说这不是改名，而是换视角？因为这八个活动把你从“接需求—交付—运维”那条老链路里拎出来，逼你正视三个过去经常被忽略的管理现实：
1、价值的起点不是“需求”，而是“机会与假设”
发现 (Discover) 把起点往前移。产品负责人最怕的不是做得慢，而是做错了。发现阶段的价值，就是把“做什么”先做对：市场机会 (market opportunity) 是什么，业务目标 (business objective) 是什么，成功的验收准则 (acceptance criteria) 是什么，风险评估 (risk assessment) 是否到位。
2、能力来源不再默认自建，获得 (Acquire) 把生态系统拉进来
数字化组织很少从零自建全部能力。云服务提供商、外包、第三方组件、平台能力都可能是最优解。Acquire 这一步让“采购/合作伙伴关系/合同管理/服务关系”从边缘变成生命周期的一部分，逼你在早期就把依赖关系 (dependency) 与责任边界谈清楚。
3、发布不再是一瞬间，转换 (Transition) 是一段风险曲线
很多团队把发布当成一个节点：过了就算完成。ITIL 第5版把转换单独拿出来，意味着你要管理的不只是部署 (deployment)，还包括沟通、培训、回滚、验证 (verification)、服务验证、就绪度 (readiness) 与运营交接。
如果你做过大规模上线，你就会明白：发布当天不出事故不代表成功，真正的成功是上线后一段时间内依旧稳定，体验不掉线，支持团队扛得住。




五、更新内容概述：六个要点把 ITIL 第5版的变化一次讲全


ITIL 第5版更新内容我把它整理成六个管理者与负责人最该记住的要点，并在本篇用“产品化”的解释方式讲一遍。
1、定位升级：数字化产品和服务管理成为核心叙事
这意味着管理对象从“IT 服务交付”扩展为“端到端价值创造”。你要对齐的不只是IT指标，而是业务结果、体验结果、风险边界与持续演进能力。
2、生命周期模型升级：八个活动覆盖从发现到支持
用发现、设计、获得、构建、转换、运营、交付、支持串起全过程，让跨团队协作从“按职能交接”转为“按活动对齐交付物与控制点”。
3、人工智能进入方法论核心：从“应用”走向“治理与管理能力”
不再把人工智能当作单一管理工具，而强调管理能力、成熟度 (maturity)、边界与被问责。它提醒你：引入生成式 AI 与自动化后，风险形态与控制点都会变化，必须把治理、证据链与可审计性纳入设计。
4、指导原则更强调取舍：特别是“优化和自动化”
原则不再只是漂亮话，而要能指导战略决策 (strategic decision)。你需要在效率、风险、合规与体验之间做平衡：哪些可以自动化，哪些必须保留人工确认；哪些适合先做试点 (pilot)，哪些必须建立更强的控制。
5、实践从清单走向组件库：强调适用性与可裁剪
实践不再被理解为“每家都要同样落地的一套流程”，而是能力组件。你要围绕价值流组合实践，让实践服务于交付物、服务于控制点，而不是让团队服务于流程。
6、迁移与学习路径更强调能力栈与路线图
认证 (certification) 的意义不只是考试，而是能力建设路线图。对组织来说，这是规划培训、岗位能力与治理体系升级的一条现实路径：你可以分阶段、按优先级推进，而不是一夜切换。




六、为什么说“不是改名，是换视角”：给产品负责人和 IT 负责人的三张对齐卡


如果你要把这件事落到团队协作里，我建议你用三张“对齐卡”去开会。它们都很简单，但很管用。
第一张对齐卡：把讨论对象从“服务”拉回到“产品 + 服务的端到端体验”
你可以这样开场：我们今天讨论的不是某个系统是否上线，而是端到端服务体验是否可靠。
接着你把问题从“是否交付”转成“是否达成价值”：

• 我们要交付的成果 (outcome) 是什么？
• 关键指标 (key metrics) 与关键绩效指标 (KPI) 是什么？
• 验收准则是什么？谁是授权人？谁最终被问责？
  

第二张对齐卡：把协作方式从“按职能交接”换成“按生命周期活动对齐”
你不再问“研发做完了吗、运维接了吗”，你问：

• 发现阶段我们有没有把假设说清楚？
• 设计阶段有没有把体验与可运维性写进设计规范 (design specification)？
• 获得阶段外部能力的责任边界、合同与支持模式是否清楚？
• 转换阶段的就绪度是否达标？回滚与恢复路径是否清晰？
• 运营、交付、支持三者的目标是否对齐？是否存在瓶颈 (bottleneck)？
  

第三张对齐卡：把治理从“流程遵守”升级为“控制点与证据链”
很多组织把治理理解成“流程要走完”。这在复杂系统里会变成形式化 (formality)。更有效的治理是把控制点放在关键处：

• 哪些环节必须审批与批准 (approval)？哪些可以授权下放？
• 哪些环节必须记录，以保证可审计性？
• 哪些环节需要人工确认，避免自动化带来不可接受风险？
• 哪些环节需要持续监督 (continual monitoring) 与持续评审 (continual review)？
  

七、把话说到更实在：你怎样判断自己是在“换视角”，还是只是在“换说法”


很多组织最容易犯的错，是把新框架当成新名词：开会开始说“价值流”，但实际还是按旧流程推；说“产品化”，但验收仍只看上线；说“体验”，但度量仍只看可用性；说“治理”，但手段仍只是加审批。
我给你一个更直接的判断方法：看你团队的行动有没有发生三件变化。
1、你的需求讨论是否变成了“发现与假设”的讨论
如果你仍然从“需求文档”开始，而不是从机会、目标、验收准则开始，你仍在旧视角里。
2、你的交付对齐是否变成了“生命周期活动对齐”
如果你仍在做“职能交接清单”，而不是围绕活动明确交付物、风险与责任，你仍在旧视角里。
3、你的治理是否变成了“证据链与控制权”的治理
如果你仍以流程遵守为主，而不是以可审计性、责任链与控制点为主，你仍在旧视角里。




八、最后的忠告：你不需要一夜之间变成“数字化产品公司”，但你需要先学会用同一套语言对齐


ITIL 第5版之所以重要，不是因为它要你立刻推翻现有体系，而是因为它提供了一套更贴近现实的管理语言：用数字化产品和服务管理的视角，把产品、服务、治理、人工智能、自动化与价值流放在同一张地图上讨论。对产品负责人和 IT 负责人来说，这套语言最大的价值，是降低对齐成本，提高行动效率，减少“开会很热闹、落地很疲惫”的损耗。


我是AI+ITIL教练长河achotsao，欢迎添加长河老师微信 achotsao 深入交流，即可第一时间获得ITIL 第5版最新动态及官方特邀中国区大使的深度解析，全网同名。

一、ITIL 第5版已经来了，你得先决定“用哪套语言开会”


2026年1月29日，PeopleCert正式发布了ITIL 第5版。作为ITIL官方中国区产品大使，我将会推出系列文章帮大家解读ITIL 第5版到底有哪些重大的更新。

对产品负责人和 IT 负责人来说，这个时间点不是“教材上新”的提醒，而更像一个信号：接下来几年，组织讨论数字化工作的共同语言会加速变化。你可以选择不跟，但你很难不被影响——因为当上下游、供应商、合作伙伴、客户组织都开始用“数字化产品和服务管理”的叙事来讨论交付与治理，你继续只用“IT服务管理”的语言，很容易在对齐上吃亏。


这里的“吃亏”不是术语不够时髦，而是你会在三个关键场景里变得被动：

• 做路线图 (roadmap) 时，你说的是“服务改进”，对方要的是“产品演进”；你说的是“运维稳定”，对方要的是“服务体验”；双方对“成功”的定义不一致，验收准则自然也对不齐。
• 做跨部门协作时，你说“流程要遵守”，对方说“价值流要流动”；你强调“审批要完整”，对方强调“周期时间要缩短”；会议越开越久，行动越变越少。
• 做治理 (governance) 与被问责 (accountability) 时，你能管住IT内部交付，却管不住端到端体验；事故发生后，责任链断裂，谁都说自己“那一段没问题”。
  

所以，本篇要讲清楚一个核心：从IT服务管理到数字化产品和服务管理，不是把“服务”两个字换成“产品”两个字，而是把你看待工作的视角，从“交付一项服务”换成“持续经营一条价值链”。




二、你以为你在管“服务”，但业务真正感知的是“产品 + 服务”的一体体验


先做一个非常现实的拆解。很多组织嘴上说“我们是产品化”，但日常协作仍按老模式运行：

• 业务团队提需求 (business needs)，IT 立项，研发构建，发布上线，运维接管，服务台处理事件。
  

这条链路看起来合理，也确实运转了很多年。但在数字化场景里，它会暴露一个根本问题：用户并不把你的价值切成“产品价值”和“服务价值”，用户只感知一件事——体验是否连贯、是否可靠、是否值得信任。
当用户体验 (UX) 与客户体验 (CX) 成为关键结果，你会发现“服务是否可用”只是底线，远远不够。

• 你提供了一个数字化产品 (digital product)，但登录、支付、客服、交付、退款、升级这些触点 (touchpoint) 任何一段割裂，体验就会被打碎。
• 你提供了一个数字服务 (digital service)，但它背后依赖的平台、数据、算法 (algorithm)、流程、供应商与支持团队只要协同不到位，服务体验就会出问题。
  

这就是为什么 ITIL 第5版要把叙事升级为数字化产品和服务管理。它其实在告诉你：不要把“产品”理解成研发的事，也不要把“服务”理解成运维的事。产品与服务是一体的，你要管理的是贯穿整个生命周期 (lifecycle) 的价值创造与风险控制，而不是某一个部门的局部交付。

三、对比一下：ITIL 4 常见落地方式为什么会“够用但不够好”


我不喜欢把新旧版本写成“谁先进谁落后”。更符合现实的说法是：ITIL 4 解决了很多组织“把服务管理做起来”的问题，但当数字化走到产品化与生态化阶段，它的常见落地方式会出现边界天花板。
1、在ITIL 4 的语境里，很多组织的改进重点仍然围绕交付与支持
你会看到大量投入放在事件管理、变更实施、服务台、SLA、度量与报告上。这些当然重要，而且是基本功。但它们往往把注意力锁在“上线之后”的世界里：运营是否稳定、故障是否减少、SLA 是否达标。
2、为什么不够
当业务增长依赖数字化能力时，价值并不只产生在“上线之后”，而是产生在“发现机会、定义价值、设计体验、选择能力来源、构建与发布策略、运营与支持协同”这一整条链路上。你如果只在后半段用力，前半段欠账会以更昂贵的方式回到你身上：

• 需求定义不清，验收准则模糊，最后只能靠加班补救。
• 体验没在设计阶段被认真对待，上线后你会用事故与投诉来支付学费。
• 自建与采购 (procurement) 决策缺乏统一方法，最后变成技术孤岛 (silo) 与供应商锁定。
• 价值流 (value stream) 被职能边界切碎，交付周期 (lead time) 拉长，组织速度 (velocity) 下降。
  

3、ITIL 第5版补齐了什么
它用“数字化产品和服务管理”的定位，把管理视角推回到端到端；并用更清晰的生命周期模型与治理语言，让你能把“产品演进”和“服务经营”放在同一张图上讨论。




四、ITIL 第5版的核心动作：把“端到端”写进生命周期模型，让你能用活动来对齐协作


如果你要快速抓住 ITIL 第5版的骨架，我建议你先记住它的八个生命周期活动 (activity)。这八个词不是为了考试好看，而是为了让跨职能讨论有共同坐标系：

• 发现 (Discover)
• 设计 (Design)
• 获得 (Acquire)
• 构建 (Build)
• 转换 (Transition)
• 运营 (Operate)
• 交付 (Deliver)
• 支持 (Support)
  

为什么说这不是改名，而是换视角？因为这八个活动把你从“接需求—交付—运维”那条老链路里拎出来，逼你正视三个过去经常被忽略的管理现实：
1、价值的起点不是“需求”，而是“机会与假设”
发现 (Discover) 把起点往前移。产品负责人最怕的不是做得慢，而是做错了。发现阶段的价值，就是把“做什么”先做对：市场机会 (market opportunity) 是什么，业务目标 (business objective) 是什么，成功的验收准则 (acceptance criteria) 是什么，风险评估 (risk assessment) 是否到位。
2、能力来源不再默认自建，获得 (Acquire) 把生态系统拉进来
数字化组织很少从零自建全部能力。云服务提供商、外包、第三方组件、平台能力都可能是最优解。Acquire 这一步让“采购/合作伙伴关系/合同管理/服务关系”从边缘变成生命周期的一部分，逼你在早期就把依赖关系 (dependency) 与责任边界谈清楚。
3、发布不再是一瞬间，转换 (Transition) 是一段风险曲线
很多团队把发布当成一个节点：过了就算完成。ITIL 第5版把转换单独拿出来，意味着你要管理的不只是部署 (deployment)，还包括沟通、培训、回滚、验证 (verification)、服务验证、就绪度 (readiness) 与运营交接。
如果你做过大规模上线，你就会明白：发布当天不出事故不代表成功，真正的成功是上线后一段时间内依旧稳定，体验不掉线，支持团队扛得住。




五、更新内容概述：六个要点把 ITIL 第5版的变化一次讲全


ITIL 第5版更新内容我把它整理成六个管理者与负责人最该记住的要点，并在本篇用“产品化”的解释方式讲一遍。
1、定位升级：数字化产品和服务管理成为核心叙事
这意味着管理对象从“IT 服务交付”扩展为“端到端价值创造”。你要对齐的不只是IT指标，而是业务结果、体验结果、风险边界与持续演进能力。
2、生命周期模型升级：八个活动覆盖从发现到支持
用发现、设计、获得、构建、转换、运营、交付、支持串起全过程，让跨团队协作从“按职能交接”转为“按活动对齐交付物与控制点”。
3、人工智能进入方法论核心：从“应用”走向“治理与管理能力”
不再把人工智能当作单一管理工具，而强调管理能力、成熟度 (maturity)、边界与被问责。它提醒你：引入生成式 AI 与自动化后，风险形态与控制点都会变化，必须把治理、证据链与可审计性纳入设计。
4、指导原则更强调取舍：特别是“优化和自动化”
原则不再只是漂亮话，而要能指导战略决策 (strategic decision)。你需要在效率、风险、合规与体验之间做平衡：哪些可以自动化，哪些必须保留人工确认；哪些适合先做试点 (pilot)，哪些必须建立更强的控制。
5、实践从清单走向组件库：强调适用性与可裁剪
实践不再被理解为“每家都要同样落地的一套流程”，而是能力组件。你要围绕价值流组合实践，让实践服务于交付物、服务于控制点，而不是让团队服务于流程。
6、迁移与学习路径更强调能力栈与路线图
认证 (certification) 的意义不只是考试，而是能力建设路线图。对组织来说，这是规划培训、岗位能力与治理体系升级的一条现实路径：你可以分阶段、按优先级推进，而不是一夜切换。




六、为什么说“不是改名，是换视角”：给产品负责人和 IT 负责人的三张对齐卡


如果你要把这件事落到团队协作里，我建议你用三张“对齐卡”去开会。它们都很简单，但很管用。
第一张对齐卡：把讨论对象从“服务”拉回到“产品 + 服务的端到端体验”
你可以这样开场：我们今天讨论的不是某个系统是否上线，而是端到端服务体验是否可靠。
接着你把问题从“是否交付”转成“是否达成价值”：

• 我们要交付的成果 (outcome) 是什么？
• 关键指标 (key metrics) 与关键绩效指标 (KPI) 是什么？
• 验收准则是什么？谁是授权人？谁最终被问责？
  

第二张对齐卡：把协作方式从“按职能交接”换成“按生命周期活动对齐”
你不再问“研发做完了吗、运维接了吗”，你问：

• 发现阶段我们有没有把假设说清楚？
• 设计阶段有没有把体验与可运维性写进设计规范 (design specification)？
• 获得阶段外部能力的责任边界、合同与支持模式是否清楚？
• 转换阶段的就绪度是否达标？回滚与恢复路径是否清晰？
• 运营、交付、支持三者的目标是否对齐？是否存在瓶颈 (bottleneck)？
  

第三张对齐卡：把治理从“流程遵守”升级为“控制点与证据链”
很多组织把治理理解成“流程要走完”。这在复杂系统里会变成形式化 (formality)。更有效的治理是把控制点放在关键处：

• 哪些环节必须审批与批准 (approval)？哪些可以授权下放？
• 哪些环节必须记录，以保证可审计性？
• 哪些环节需要人工确认，避免自动化带来不可接受风险？
• 哪些环节需要持续监督 (continual monitoring) 与持续评审 (continual review)？
  

七、把话说到更实在：你怎样判断自己是在“换视角”，还是只是在“换说法”


很多组织最容易犯的错，是把新框架当成新名词：开会开始说“价值流”，但实际还是按旧流程推；说“产品化”，但验收仍只看上线；说“体验”，但度量仍只看可用性；说“治理”，但手段仍只是加审批。
我给你一个更直接的判断方法：看你团队的行动有没有发生三件变化。
1、你的需求讨论是否变成了“发现与假设”的讨论
如果你仍然从“需求文档”开始，而不是从机会、目标、验收准则开始，你仍在旧视角里。
2、你的交付对齐是否变成了“生命周期活动对齐”
如果你仍在做“职能交接清单”，而不是围绕活动明确交付物、风险与责任，你仍在旧视角里。
3、你的治理是否变成了“证据链与控制权”的治理
如果你仍以流程遵守为主，而不是以可审计性、责任链与控制点为主，你仍在旧视角里。




八、最后的忠告：你不需要一夜之间变成“数字化产品公司”，但你需要先学会用同一套语言对齐


ITIL 第5版之所以重要，不是因为它要你立刻推翻现有体系，而是因为它提供了一套更贴近现实的管理语言：用数字化产品和服务管理的视角，把产品、服务、治理、人工智能、自动化与价值流放在同一张地图上讨论。对产品负责人和 IT 负责人来说，这套语言最大的价值，是降低对齐成本，提高行动效率，减少“开会很热闹、落地很疲惫”的损耗。


我是AI+ITIL教练长河achotsao，欢迎添加长河老师微信 achotsao 深入交流，即可第一时间获得ITIL 第5版最新动态及官方特邀中国区大使的深度解析，全网同名。