Skip to content

Chapter 03 - Value Co-Creation

本章目标

看完本章后,你应当可以回答:

  • 为什么 value 不是 provider 单方面交付?
  • provider、consumer、客户、user、stakeholder 的差异是什么?
  • outcome、cost、risk、experience、sustainability 如何一起影响 value?
  • PM 如何判断一个功能是真的创造 value,还是只是完成 delivery?
  • 考试遇到 value co-creation 题目时应该怎么选?

一句话

Value 不是「我交付功能」就自动产生,而是 provider、consumer 和其他 stakeholders 通过合作,让 outcome 在可接受的 cost、risk 和 experience 下被实现。

核心概念

Value Co-Creation

Value co-creation 的重点是:provider 不能单方面宣告 value 已经完成。Provider 可以提供 product、service、support、knowledge、automation 和 governance,但 value 只有在 consumer 真的达成 outcome 时才成立。

线上服务示例:

text
Provider: product / engineering / operations team
Consumer: 使用服务流程的客户、用户、客服、运营
Service: 操作、查询、数据修正请求、异常处理
Outcome: 用户完成主要操作,客户确认处理结果,客服能处理问题
Value: 成交率提升、信任提高、人工处理成本下降

如果团队只上线 API,但客户不会串、客服查不到状态、用户遇到错误不知道怎么办,value 就没有完整被共同创造出来。

Provider

Provider 是提供 product 或 service 的一方。它可能是外部供应商,也可能是公司内部团队。

示例:

  • AWS 对使用 RDS 的团队来说是 provider
  • platform team 对客户后台用户来说是 provider
  • Backend team 对 frontend / mobile team 来说可能是 internal provider

Provider 的责任不是只交付技术组件,而是让 consumer 能通过 service 达成 outcome。

Consumer

Consumer 是使用、要求、付费或受 service 影响的一方。它可以再拆成 客户、user、sponsor 等角色。

示例:

  • Customer:决定购买或采用 service 的人
  • User:实际使用 service 的人
  • Sponsor:提供预算或支持的人

在内部产品里,角色常常混在一起。PM 要小心不要只听 sponsor,而忽略每天真正使用系统的 user。

Stakeholder

Stakeholder 是会影响 service,或被 service 影响的人或组织。它不一定直接使用 product。

线上服务场景里的 stakeholders 可能包含:

  • 用户
  • 客户
  • 客服
  • 运营
  • 财务
  • 法务
  • 信息安全
  • external gateway vendor
  • on-call engineer
  • product owner

Value co-creation 需要看整个 stakeholder ecosystem,不是只看单一用户。

Service Relationship

Service relationship 是 provider 和 consumer 之间为了共同创造 value 形成的关系。它不只是合约,也包含沟通、支持、使用方式、反馈、责任分工和改善机制。

AWS 的示例:

text
AWS provides RDS capability
Customer configures schema, access, backup policy, monitoring use
Both sides influence database service value

如果 客户 把 production database 开成 public access,不能说「AWS 没有创造 value」。这是 service relationship 里 responsibility 没有被正确管理。

Experience and Sustainability

Value 不只看 outcome,也看 experience 和 sustainability。

同样是「完成主要操作」:

  • 如果用户要重试 5 次才成功,experience 很差
  • 如果客服要查 4 个系统才确认状态,operation cost 很高
  • 如果每次 release 都靠英雄式救火,team sustainability 很差
  • 如果 AI chatbot 回答很快但经常误导用户,trust 和 risk 都有问题

所以 value co-creation 不是短期交付,而是长期可持续地共同创造结果。

PM 视角

PM 的工作不是把需求丢给工程师,也不是把功能上线就收工。PM 在 value co-creation 里要做的是把不同 stakeholder 的 outcome、cost、risk 和 experience 对齐。

一个核心功能至少要问:

  1. 用户的 outcome 是什么?
  2. 客户的 outcome 是什么?
  3. 客服需要什么信息才能支持?
  4. 财务需要什么数据才能对账?
  5. 工程团队能不能稳定维护?
  6. 发生 incident 时谁要知道、谁要处理、谁要对外沟通?

这些不是「PM 多管闲事」。这些是确保功能变成 service value 的必要工作。

Developer / DevOps 视角

Developer 和 DevOps 在 value co-creation 中不是单纯的 build team。

示例:React checkout release

text
Frontend team builds checkout UI
Backend team exposes core API
DevOps maintains deployment and rollback
QA validates critical flow
CS team handles user issue
PM aligns scope and launch risk
Users complete the main operation
Merchants receive money

Value 是整条链一起创造的。任何一段断掉,最后的 service value 都会下降。

工程上常见的盲点是只看「我的 component 有没有完成」:

  • frontend merged 了,但 backend error message 无法被 user 理解
  • backend API 可用,但 support team 没有查询工具
  • pipeline deploy 成功,但没有 business metric 看成功率
  • alert 有发,但没有 runbook

从 ITIL 的角度,这些都是 value co-creation 的断点。

AWS 对照

AWS 的 shared responsibility 很适合理解 value co-creation。

以 RDS 为例:

  • AWS 提供 managed database capability
  • Customer 选择 instance、schema、backup、network、access control
  • Application team 设计 query、connection pool、retry
  • DevOps 设定 monitoring 和 alarm
  • Security team 管理权限与数据保护
  • Business team 定义可接受的 outage impact

RDS 的 value 不是 AWS 单方面交付,也不是 客户 单方面完成。它是 provider 和 consumer 在明确责任分工下共同创造。

实践对照

假设 团队要引入 AI chatbot 处理服务问题。

表面上的 delivery:

  • chatbot 上线
  • 可以回答服务状态
  • 可以查询 FAQ

Value co-creation 要看更深:

  • 用户是否真的更快解决问题?
  • chatbot 不能处理时是否能顺利转客服?
  • 客服是否看得到 chatbot 对话纪录?
  • chatbot 回答错误时谁负责修正 knowledge base?
  • 法务或信息安全是否确认可暴露的数据范围?
  • PM 是否追踪 deflection rate、resolution rate、CSAT、错误率?

如果 chatbot 只是 demo 很美观,但让用户更困惑,甚至提供错误服务信息,它不但没有创造 value,还增加 risk。

常见误区

误解 1:Provider 可以单方面交付 value

Provider 可以交付 product 或 service capability,但 value 需要 consumer 使用、反馈、配合,并在真实情境中达成 outcome。

误解 2:只要 客户 满意,其他 stakeholder 不重要

短期 客户 满意不代表整体 value 成立。如果客服成本暴增、工程团队不可持续、信息安全风险升高,value 可能只是被转嫁成本。

误解 3:Value co-creation 就是多开会

Co-creation 不是会议数量,而是责任、反馈、信息、支持、改善是否让 outcome 更容易被达成。

误解 4:AI 自动化越多,value 越高

AI 能提升速度,但如果错误率、信任、风险、治理没有管理好,自动化可能降低 value。

Interview Angle

可能被问:

  • What does value co-creation mean in ITIL?
  • How do you identify stakeholders for a digital service?
  • How do you make sure a new feature actually creates value?
  • How would you evaluate an AI chatbot from a service management perspective?

回答方向:

  • 不要说「value is delivered by provider」就结束
  • 要提 provider、consumer、stakeholders
  • 要提 outcome、cost、risk、experience
  • 最好用 production feature、cloud service 或 support workflow 当示例

Exam Tips

考 value co-creation 时,题目常会设计成「某团队已经交付功能,但用户还是没有得到想要的结果」。

看到以下线索要敏感:

  • 多个角色需要协作
  • 用户 outcome 没达成
  • 成本或风险被转嫁给 consumer
  • stakeholder 没有被纳入
  • feedback 没有进入改善循环
  • AI / automation 上线但 experience 变差

答题原则:

  • 优先选能促进 collaboration、visibility、feedback、shared understanding 的选项
  • 避免选「provider 自己决定就好」的选项
  • 避免只看工具或流程,忽略 outcome

Summary

Value co-creation 是 ITIL 的核心思维:value 不是 provider 单方面交付,而是在 provider、consumer 和 stakeholders 的 service relationship 中共同形成。对 Technical PM 来说,这章的关键是把「功能上线」改成「stakeholders 是否真的一起达成 outcome,并且 cost、risk、experience、sustainability 都可接受」。

References

Quiz

请见 Chapter 03 Quiz

原创练习内容。非 PeopleCert 官方资料。