TOGAF 价值流映射：用客户视角重新审视你的业务架构

Thu, 18 Jun 2026 21:05:00 +0800

大多数企业架构工作都是从内部开始的。我们梳理系统、画流程图、定义服务边界，本质上都是在回答"我们怎么干活"。架构评审会上讨论最多的问题也是"这个系统的边界在哪"、“这个服务该归哪个团队”。这些都对，但有一个盲区：客户不关心你怎么干活，他只关心你给他交付了什么。

一个典型的场景：业务部门提了一个新需求，架构师的第一反应是"哪个系统来承接"、“数据怎么流转”、“接口怎么设计”。这些都是执行层面的问题。但在回答这些之前，有一个更根本的问题被跳过了——这个需求在客户的价值链条上处于什么位置？它是在帮客户完成一个完整的价值交付，还是只是内部视角下的一个功能点？

TOGAF 里的价值流（Value Stream）就是用来补这个盲区的。它强制你从客户视角出发，倒推企业需要哪些能力来交付价值。方向反过来：不是"我有什么能力就用什么"，而是"客户需要什么价值，我就得有什么能力"。

什么是价值流

价值流是一组端到端的增值活动，最终为客户或利益相关者交付一个完整的、可感知的结果。注意关键词：端到端和可感知。一个孤立的内部操作不算价值流，它必须从客户触发开始，到客户获得价值结束。

TOGAF 定义了价值流的四个标准元素：

元素	说明
名称	动词+名词结构，如"采购商品"、“招聘员工”
描述	这条价值流做什么，边界在哪
利益相关者	谁触发了它，谁从中获益
价值	交付了什么具体结果，用什么衡量

每条价值流可以拆解为多个阶段。每个阶段除了名称和描述，还包含进入条件（什么情况下启动这个阶段）、退出条件（什么情况算完成）、以及该阶段贡献的具体价值项。这些条件很重要——它们是判断流程是否真正衔接的标准，而不是画完箭头就完事。

价值流不是业务流程

这两个概念经常被混用，但方向完全不同：

维度	价值流	业务流程
视角	自外向内（客户视角）	自内向外（运营视角）
关注点	交付了什么价值	怎么完成任务
粒度	粗，面向战略层	细，面向执行层
稳定性	相对稳定，随商业模式变化	频繁调整，随运营优化变化
典型用途	识别能力缺口、对齐战略	流程自动化、效率优化

还有一个容易混淆的概念是价值链（Value Chain）。价值链来自波特，是经济学视角，把企业活动分为主要活动和支持活动。价值网络则从参与者角度描述价值交换关系。精益价值流专注制造业中的浪费消除。它们各有适用场景，不要混着用。

怎么做价值流映射

步骤不复杂，但需要克制——别一上来就画二十个阶段。

第一步：识别外部价值流。 从客户和利益相关者出发，列出企业对外交付的核心价值流。一般 5-10 条足够覆盖主要业务。零售企业可能有"采购商品"、“获取客户”、“处理退货”；服务企业可能有"签约客户"、“交付服务”、“续约管理”。

第二步：分解阶段。 每条价值流拆成 4-7 个阶段。每个阶段有清晰的进入和退出条件。以电商"采购商品"为例：

`1`	`发现商品 → 比较选择 → 下单支付 → 等待交付 → 使用评价`

每个阶段不是内部的操作步骤，而是客户经历的一个状态转换。“等待交付"对客户来说是一个真实的阶段，虽然内部可能涉及物流、仓储、配送等多个流程。

第三步：映射能力到阶段。 把你已经梳理好的业务能力（Business Capability）挂到对应的价值流阶段上。这一步的目的是回答：为了完成这个阶段，企业需要哪些能力？

比如"比较选择"阶段可能需要：商品推荐能力、价格比较能力、用户评价管理能力。“下单支付"阶段需要：订单处理能力、支付网关能力、库存实时查询能力。

一个具体例子

假设你在做一家在线教育平台的业务架构。核心外部价值流之一是"学习课程”：

阶段	进入条件	退出条件	阶段价值
发现课程	用户有学习意图	用户找到目标课程	匹配需求
评估课程	用户进入课程详情	用户做出购买决策	降低决策成本
购买课程	用户决定购买	订单完成、权限开通	获得访问权
学习课程	用户开始学习	用户完成课程内容	获得知识/技能
获得认证	用户完成考核要求	证书发放	可验证的成果

然后把业务能力映射上去。“学习课程"阶段可能需要：内容分发能力、进度追踪能力、互动答疑能力、离线缓存能力。“获得认证"阶段需要：考核评估能力、证书生成能力、第三方验证能力。

注意这里的映射是多对多的。“用户身份管理能力"可能同时出现在"购买课程"和"获得认证"两个阶段，而"学习课程"阶段可能需要五六个能力的协同支撑。这很正常——能力是组织级的，价值流阶段是场景级的，它们之间不存在一一对应关系。

映射过程中你会自然发现一些问题：某个阶段挂了七八个能力，说明这个阶段复杂度很高，值得单独拆解；某个能力挂了所有阶段，说明它可能是平台级能力，应该下沉到共享服务层。

热力图：找到能力短板

映射完成后，画一张价值流×能力的交叉矩阵，就是热力图。行是价值流阶段，列是业务能力，交叉点标注能力的成熟度：

🟢 成熟：能力完备，能支撑该阶段
🟡 发展中：有能力但不完善
🔴 缺失或薄弱：关键缺口

这张图的价值在于：它能直接告诉你，哪些能力投资能产生最大的客户价值回报。如果"学习课程"阶段的离线缓存能力是红色，而你们有 40% 用户在移动端学习，那这个缺口就直接影响了核心价值的交付。

反过来，热力图也能暴露冗余——某个能力被标记为绿色但没有挂在任何价值流阶段上，说明它可能不直接创造客户价值。不是说要砍掉，而是需要重新审视它的定位：它可能在支撑内部价值流（如"管理合规”、“优化运营”），只是不在外部客户视角内。

实操中热力图最大的价值不是那张图本身，而是画它的过程。你需要和业务方一起逐个讨论每个交叉点的成熟度，这个过程本身就是对齐——技术团队认为"已经做得很好"的能力，业务方可能觉得完全不够用。分歧暴露出来，优先级就清楚了。

一个建议：别试图一次性把所有价值流和能力都放进热力图。挑一条最核心的外部价值流，聚焦在它的关键阶段上，做深做透，再逐步扩展。

几个实操原则

从外部价值流开始，别从内部流程倒推。先想客户要什么，再想你需要什么能力。
保持简洁。 价值流阶段不是工作流步骤，4-7 个阶段足够。如果你画了 15 个阶段，那你在画流程图，不是价值流。
价值流不等于能力。 价值流是"做什么”，能力是"能做什么”。一个是活动序列，一个是组织具备的本领。它们是多对多关系。
别追求完美覆盖。 先把核心价值链画出来，识别出最明显的能力缺口，这比一张面面俱到但没人看得懂的图有用得多。

写在最后

价值流映射不是一个独立的架构活动，它是连接战略和执行的桥梁。战略规划告诉你"我们要进入什么市场、服务什么客户”，价值流把这个战略翻译成"我们需要交付什么价值"，能力映射再把它翻译成"我们需要建设什么能力"。

三层对齐之后，技术架构的决策就有了锚点。你知道为什么要投某个系统、为什么某个服务要优先重构、为什么某个能力的数字化比另一个更紧迫。不是因为技术团队觉得它酷，而是因为客户价值链条上的某个阶段在等着它。

这才是业务架构该有的样子：不是为了画图而画图，而是让每一行代码都知道自己在为谁创造价值。

价值流 on 文艺技术笔记