一、ITIL 第5版已发布，它在提醒组织别再用“交付完就算”来理解价值
2026年1月29日，PeopleCert正式发布了ITIL 第5版。作为ITIL官方中国区产品大使，我将会推出系列文章帮大家解读ITIL 第5版到底有哪些重大的更新。
ITIL v5（即ITIL 第5版）已经正式发布。很多人听到“数字产品与服务管理”，第一反应是：这是不是又一次概念升级，把原来的服务管理换个更潮的名字。看起来像，但本质完全不同。
因为真正改变组织命运的，从来不是名字，而是责任边界与度量方式。你叫它服务也好、产品也好，只要开发、运营、支持之间仍然用不同的目标与不同的指标在做事，端到端价值交付就一定会断裂：研发追求迭代速度，运维追求稳定与可用性，服务台追求响应与关闭，产品追求需求上线与增长。每个局部都能做得很努力，但组合在一起，用户体验依旧会起伏，交付周期依旧会被等待与返工拖长，风险依旧会在转换阶段集中爆发。
ITIL 第5版这次升级的“狠”，就在于它不再允许组织把价值交付理解为“上线那一刻”。它把关注点从“把服务交付出来”迁移到“把数字产品与服务持续运营好”，把开发、运营、支持真正绑成一条命运线：你做的每一次迭代、每一次变更、每一次自动化，都必须能在端到端价值与体验上交出结果，并且在治理边界内可问责、可审计。
这就是为什么说，这不是改名，而是换视角。视角一换，组织运行方式就必须跟着换。
二、ITIL 第5版升级内容全景
要把“服务到数字产品”的迁移讲透，必须先把ITIL 第5版的更新内容要点完整交代。因为所谓“产品化”，并不是单点变化，而是一条贯穿框架的主轴。
1）定位升级：从服务管理走向数字产品与服务管理
ITIL 第5版把管理对象扩展为数字产品与服务的整体，强调端到端价值交付。它不再默认“服务管理只是IT内部的运营问题”，而把数字化组织如何持续创造价值放到中心：研发、交付、运营、支持、治理必须在同一张图上协作。
2）生命周期模型升级：八个阶段覆盖从想法到退役
ITIL 第5版提出产品与服务生命周期的八个阶段：发现（Discover，发现）、设计（Design，设计）、获取（Acquire，获取）、构建（Build，构建）、转换（Transition，转换）、运营（Operate，运营）、交付（Deliver，交付）、支持（Support，支持）。这八个阶段让“端到端”不再是口号，而是一套可复用的结构：你可以清晰描述价值从哪里来、怎么被验证、怎么被交付、怎么被运营、怎么被支持与改进。
3）体验进入核心：从达标导向走向旅程结果
ITIL 第5版更强调体验，把体验纳入管理与度量视野。组织不再只问“是否达标”，还要问“旅程是否顺畅、触点摩擦是否减少、客户满意度是否持续改善”。这会直接改变产品团队与运维团队的共同目标：不再各自守一段指标，而要共同守住端到端体验。
4）AI进入框架中心：从工具话题走向治理与能力边界
ITIL 第5版把AI从工具层提升到治理层：数据质量、授权与问责、可审计性、风险边界成为AI进入生产体系的前置条件。对数字产品而言，这意味着自动化与智能化不再是“能做就做”，而是“在可控边界内做，并能证明可控”。
5）实践使用方式变化：从清单背诵走向情境化组合
ITIL 第5版更强调环境与可裁剪，实践不再是背清单，而是围绕价值流进行组合：事件管理、变更实施、发布管理、知识管理、度量与报告、风险管理等要共同支撑端到端价值，而不是各自为政。
把这五点连起来，你会发现“数字产品化”不是多了一章内容，而是整个框架在重写组织的协作方式：统一对象、拉通链路、以体验验收、以治理兜底、以实践组合落地。
三、为什么“服务视角”会越来越吃力：你以为在交付，其实在切割责任
很多组织并不是不重视运营，只是长期以来的默认叙事让责任天然切割：项目交付完了，扔给运维；系统上线了，交给服务台；出现事故了，再临时拉研发。短期能跑，长期一定越来越吃力。
服务视角最常见的三种后果，几乎每个组织都见过。
1）责任断裂：上线像交接棒，没人对端到端结果负责
研发说需求做完了，运维说环境接住了，服务台说工单都关了，但用户体验依旧不稳。因为“完成”的定义被分段了：
• 研发的完成是代码合并、功能上线
• 运维的完成是可用性达标、告警可控
• 服务台的完成是响应及时、工单关闭
• 业务的完成是体验顺、效率高、结果到手
每段都能达标，但端到端没有一个共同的“验收标准”。于是问题会在缝隙里长出来：上线后才发现可观测性不足、权限流程绕路、知识缺口、变更风险没讲清，最终用返工与内耗补洞。
2）运营欠账：迭代越快，后面越痛
当产品迭代变快，运营欠账会呈现出“复利”效应：一次小缺陷影响一个用户，十次小缺陷影响一群用户；一次不清晰的变更公告造成一次误操作，长期不清晰就会形成“习惯性救火”。欠账的本质不是技术，而是运行机制没跟上：
• 没有把运营与支持的反馈稳定回流到设计与构建
• 没有把转换阶段的风险曲线管理成制度
• 没有把知识与证据链固化成资产
• 没有把体验摩擦纳入持续改进节奏
你以为是在“多做功能”，其实是在“多欠债”。债到一定程度，迭代速度一定被拉慢，稳定性也一定被拖垮。
3）围墙成本：开发、运营、支持之间的协作开销吞掉收益
当边界切得越硬，协作开销就越大。开销主要体现在：
• 交接与等待：工单转手、排队、反复确认
• 信息补全：日志、版本、影响范围、复现路径来回追
• 责任扯皮：谁该处理、谁该承担问责
• 复盘失效：没有证据链，只能讲故事，改进落不到系统
围墙成本最可怕的一点是：它会被组织误认为“业务太急”“系统太复杂”。但如果你把价值流拉出来一看，很多绕路其实是人为制造的。
所以，ITIL 第5版强调“数字产品与服务管理”，本质是在提醒组织：不要再用切割责任的方式解释价值交付了。数字产品不是一次性交付物，它是一个长期运行的系统，你只能用端到端的方式去管理它。
四、数字产品视角到底改变了什么：从“交付”变成“持续运营”，从“局部指标”变成“共同结果”
把服务升级为数字产品视角，并不是否定服务管理，而是把服务管理放回更大的运行框架里。变化至少体现在四个层面。
1）共同目标：端到端结果成为共同验收标准
数字产品视角要求研发、运维、支持对同一组结果负责，而不是各自守自己的指标。结果不是一句话，需要可验证：
• 用户是否能在最少触点完成目标
• 旅程等待占比是否下降
• 一次解决率是否提升
• 重大事件是否减少、恢复是否更可控
• 变更风险是否被提前识别并受控
当结果被共同持有，协作会自然变得更有方向，因为大家在同一张地图上。
2）共同语言：生命周期八个阶段让端到端边界可见
生命周期八个阶段的价值，在于它让“端到端”可落地。很多组织说端到端，但边界依旧模糊。八个阶段提供了稳定要点：
• 发现阶段把机会与假设讲清
• 设计阶段把方案与验收标准讲清
• 获取阶段把外部能力与采购纳入计划
• 构建阶段把敏捷与DevOps变成默认语境
• 转换阶段把发布与变更变成可管理的风险曲线
• 运营、交付、支持把日常运行拆开讲清职责与接口，并形成反馈回路
当边界可见，围墙成本才有机会被系统性消除。
3）共同底座：数据质量、知识资产、证据链成为“产品能力的一部分”
数字产品要长期运行，最怕的不是一次事故，而是组织无法持续学习。持续学习靠三类资产：
• 数据：准确性、完整性、一致性，支撑度量与决策
• 知识：把重复问题变成可复用路径，减少返工
• 证据链：保证可审计性与可追溯，支撑问责与改进
这些资产过去常被当作“运维文档”“服务台知识库”，现在必须被当作产品能力：它们直接决定体验与效率。
4）共同边界：AI与自动化进入执行链路，治理必须前置
数字产品化必然会推进自动化与AI：自动分派、自动升级、自动补救、智能洞察。越是这样，治理越要前置：
• 哪些动作可以自动执行，授权人是谁
• 出错时谁承担问责，如何追溯证据
• 数据质量门槛是什么
• 异常触发如何降级为人工接管
• 如何在持续改进中调整边界
这不是让组织变保守，而是让效率建立在可控的地基上。
五、怎么把“产品化”做出来：三步把开发、运营、支持绑到同一条价值流上
“从服务到数字产品”听起来宏大，落地却可以从很小的动作开始。更稳的做法，是用三步把一条高价值旅程跑顺，再逐步扩面。
第一步：选一条端到端旅程，画出真实价值流，找到绕路点
不要从全域开始，从一条高频、高价值、痛点清晰的旅程开始。例如：账号与权限、关键业务系统登录、核心报表生成、支付与结算、客户下单与履约等。把真实发生的步骤画出来，重点找四类浪费：
• 等待：排队、审批、跨团队等待
• 交接：转派、升级失败、重复确认
• 信息缺口：日志、版本、影响范围来回补
• 返工：验收不清、发布说明不清、知识缺口导致重复处理
价值流一旦清晰，围墙成本就不再是“感觉”，而是可度量的改进对象。
第二步：用生命周期八个阶段定位问题来源，把改进从下游推回上游
很多体验问题不是支持做得不好，而是上游欠账。把绕路点对应到八个阶段，你就能找到真正的改进抓手：
• 如果频繁返工，往往是设计阶段验收标准不清
• 如果发布后波动大，往往是转换阶段风险曲线没管好
• 如果排障时间长，往往是构建阶段可观测性不足
• 如果重复问题多，往往是支持阶段知识回流机制缺失
• 如果自动化误判多，往往是数据质量与证据链不足
这一步很关键：它让改进不再只改流程，而是改系统。
第三步：建立最小共同度量集与复盘节奏，让“共同结果”变成日常经营
产品化最怕口号化。要避免口号化，就要有共同度量与固定复盘。建议从最小集合开始：
• 端到端周期时间与等待占比
• 一次解决率与返工率
• 交接次数与升级效率
• 关键触点满意度与不确定性指标（例如进度透明度、信息往返次数）
• 变更相关事故比例与恢复验证通过率
然后把复盘固化为BAU：每两周或每月复盘一次，以价值流为单位看改进，而不是以部门为单位看工作量。复盘输出要落到行动项：谁负责、何时完成、怎么验证。
当这三步跑通一条旅程，所谓“数字产品化”才会从概念变成组织能力：开发、运营、支持不再靠开会对齐，而靠同一条价值流与同一组结果协同。
六、最容易走偏的三种“伪产品化”：看起来很忙，实际没拆墙
最后提醒三种常见走偏，很多组织吃过亏。
1）只改组织架构，不改共同度量
把人放到一个群里并不等于协作变好。如果研发仍然只对上线负责、运维仍然只对可用性负责、支持仍然只对关闭负责，围墙只是从“看得见”变成“看不见”。没有共同度量，产品化一定会变成新形式的扯皮。
2）只追迭代速度，不管转换风险曲线
数字产品化不是鼓励冒进。转换阶段的风险曲线如果不受控，迭代越快，事故越多，用户体验越差，最后只能用更多审批与人工兜底来止血，速度反而被拖垮。
3）只上AI工具，不补数据质量与证据链
自动化越深，风险放大越快。数据不完整、不一致、不可追溯时，AI会把偏差规模化传播。没有授权与问责、可审计性与降级机制，智能化会变成新的混乱源。
真正的产品化，是运行机制的升级，不是表面动作的堆叠。
我的个人体会：ITIL v5提出“数字产品与服务管理”，不是换个名字让人耳目一新，而是用ITIL 第5版的端到端视角把开发、运营、支持绑成同一条命运线：用生命周期的八个阶段把边界拉通，用价值流把绕路显性化，用体验结果做共同验收，用数据质量与证据链支撑治理与问责，再用持续改进把改进固化为日常经营；当组织能用同一组结果与度量协同运转时，“从服务到数字产品”才算真正发生。
我是AI+ITIL教练长河achotsao，欢迎交流。关注我，即可第一时间获得ITIL 第5版最新动态及官方特邀中国区大使的深度解析，全网同名。
