大多数企业架构工作都是从内部开始的。我们梳理系统、画流程图、定义服务边界，本质上都是在回答"我们怎么干活"。架构评审会上讨论最多的问题也是"这个系统的边界在哪"、“这个服务该归哪个团队”。这些都对，但有一个盲区：客户不关心你怎么干活，他只关心你给他交付了什么。
一个典型的场景：业务部门提了一个新需求，架构师的第一反应是"哪个系统来承接"、“数据怎么流转”、“接口怎么设计”。这些都是执行层面的问题。但在回答这些之前，有一个更根本的问题被跳过了——这个需求在客户的价值链条上处于什么位置？它是在帮客户完成一个完整的价值交付，还是只是内部视角下的一个功能点？
TOGAF 里的价值流（Value Stream）就是用来补这个盲区的。它强制你从客户视角出发，倒推企业需要哪些能力来交付价值。方向反过来：不是"我有什么能力就用什么"，而是"客户需要什么价值，我就得有什么能力"。
什么是价值流
价值流是一组端到端的增值活动，最终为客户或利益相关者交付一个完整的、可感知的结果。注意关键词：端到端和可感知。一个孤立的内部操作不算价值流，它必须从客户触发开始，到客户获得价值结束。
TOGAF 定义了价值流的四个标准元素：
| 元素 | 说明 |
|---|---|
| 名称 | 动词+名词结构，如"采购商品"、“招聘员工” |
| 描述 | 这条价值流做什么，边界在哪 |
| 利益相关者 | 谁触发了它，谁从中获益 |
| 价值 | 交付了什么具体结果，用什么衡量 |
每条价值流可以拆解为多个阶段。每个阶段除了名称和描述，还包含进入条件（什么情况下启动这个阶段）、退出条件（什么情况算完成）、以及该阶段贡献的具体价值项。这些条件很重要——它们是判断流程是否真正衔接的标准，而不是画完箭头就完事。
价值流不是业务流程
这两个概念经常被混用，但方向完全不同：
| 维度 | 价值流 | 业务流程 |
|---|---|---|
| 视角 | 自外向内（客户视角） | 自内向外（运营视角） |
| 关注点 | 交付了什么价值 | 怎么完成任务 |
| 粒度 | 粗，面向战略层 | 细，面向执行层 |
| 稳定性 | 相对稳定，随商业模式变化 | 频繁调整，随运营优化变化 |
| 典型用途 | 识别能力缺口、对齐战略 | 流程自动化、效率优化 |
还有一个容易混淆的概念是价值链（Value Chain）。价值链来自波特，是经济学视角，把企业活动分为主要活动和支持活动。价值网络则从参与者角度描述价值交换关系。精益价值流专注制造业中的浪费消除。它们各有适用场景，不要混着用。
怎么做价值流映射
步骤不复杂，但需要克制——别一上来就画二十个阶段。
第一步：识别外部价值流。 从客户和利益相关者出发，列出企业对外交付的核心价值流。一般 5-10 条足够覆盖主要业务。零售企业可能有"采购商品"、“获取客户”、“处理退货”；服务企业可能有"签约客户"、“交付服务”、“续约管理”。
第二步：分解阶段。 每条价值流拆成 4-7 个阶段。每个阶段有清晰的进入和退出条件。以电商"采购商品"为例：
|
|
每个阶段不是内部的操作步骤，而是客户经历的一个状态转换。“等待交付"对客户来说是一个真实的阶段，虽然内部可能涉及物流、仓储、配送等多个流程。
第三步：映射能力到阶段。 把你已经梳理好的业务能力（Business Capability）挂到对应的价值流阶段上。这一步的目的是回答：为了完成这个阶段，企业需要哪些能力？
比如"比较选择"阶段可能需要：商品推荐能力、价格比较能力、用户评价管理能力。“下单支付"阶段需要：订单处理能力、支付网关能力、库存实时查询能力。
一个具体例子
假设你在做一家在线教育平台的业务架构。核心外部价值流之一是"学习课程”：
| 阶段 | 进入条件 | 退出条件 | 阶段价值 |
|---|---|---|---|
| 发现课程 | 用户有学习意图 | 用户找到目标课程 | 匹配需求 |
| 评估课程 | 用户进入课程详情 | 用户做出购买决策 | 降低决策成本 |
| 购买课程 | 用户决定购买 | 订单完成、权限开通 | 获得访问权 |
| 学习课程 | 用户开始学习 | 用户完成课程内容 | 获得知识/技能 |
| 获得认证 | 用户完成考核要求 | 证书发放 | 可验证的成果 |
然后把业务能力映射上去。“学习课程"阶段可能需要：内容分发能力、进度追踪能力、互动答疑能力、离线缓存能力。“获得认证"阶段需要：考核评估能力、证书生成能力、第三方验证能力。
注意这里的映射是多对多的。“用户身份管理能力"可能同时出现在"购买课程"和"获得认证"两个阶段，而"学习课程"阶段可能需要五六个能力的协同支撑。这很正常——能力是组织级的，价值流阶段是场景级的，它们之间不存在一一对应关系。
映射过程中你会自然发现一些问题：某个阶段挂了七八个能力，说明这个阶段复杂度很高，值得单独拆解；某个能力挂了所有阶段，说明它可能是平台级能力，应该下沉到共享服务层。
热力图：找到能力短板
映射完成后，画一张价值流×能力的交叉矩阵，就是热力图。行是价值流阶段，列是业务能力，交叉点标注能力的成熟度：
- 🟢 成熟：能力完备，能支撑该阶段
- 🟡 发展中：有能力但不完善
- 🔴 缺失或薄弱：关键缺口
这张图的价值在于：它能直接告诉你，哪些能力投资能产生最大的客户价值回报。如果"学习课程"阶段的离线缓存能力是红色，而你们有 40% 用户在移动端学习，那这个缺口就直接影响了核心价值的交付。
反过来，热力图也能暴露冗余——某个能力被标记为绿色但没有挂在任何价值流阶段上，说明它可能不直接创造客户价值。不是说要砍掉，而是需要重新审视它的定位：它可能在支撑内部价值流（如"管理合规”、“优化运营”），只是不在外部客户视角内。
实操中热力图最大的价值不是那张图本身，而是画它的过程。你需要和业务方一起逐个讨论每个交叉点的成熟度，这个过程本身就是对齐——技术团队认为"已经做得很好"的能力，业务方可能觉得完全不够用。分歧暴露出来，优先级就清楚了。
一个建议：别试图一次性把所有价值流和能力都放进热力图。挑一条最核心的外部价值流，聚焦在它的关键阶段上，做深做透，再逐步扩展。
几个实操原则
- 从外部价值流开始，别从内部流程倒推。先想客户要什么，再想你需要什么能力。
- 保持简洁。 价值流阶段不是工作流步骤，4-7 个阶段足够。如果你画了 15 个阶段，那你在画流程图，不是价值流。
- 价值流不等于能力。 价值流是"做什么”，能力是"能做什么”。一个是活动序列，一个是组织具备的本领。它们是多对多关系。
- 别追求完美覆盖。 先把核心价值链画出来，识别出最明显的能力缺口，这比一张面面俱到但没人看得懂的图有用得多。
写在最后
价值流映射不是一个独立的架构活动，它是连接战略和执行的桥梁。战略规划告诉你"我们要进入什么市场、服务什么客户”，价值流把这个战略翻译成"我们需要交付什么价值"，能力映射再把它翻译成"我们需要建设什么能力"。
三层对齐之后，技术架构的决策就有了锚点。你知道为什么要投某个系统、为什么某个服务要优先重构、为什么某个能力的数字化比另一个更紧迫。不是因为技术团队觉得它酷，而是因为客户价值链条上的某个阶段在等着它。
这才是业务架构该有的样子：不是为了画图而画图，而是让每一行代码都知道自己在为谁创造价值。