Arch Day 2: 业务能力建模(高级) — 从能力地图到投资决策

日期: 2026-03-31 阶段: 第一阶段 - 架构基础 标签: #业务能力 #BIAN #能力热力图 #投资决策 #成熟度评估

---

核心概念

一句话定义

业务能力建模(Business Capability Modeling)不是画一张"功能清单"，而是建立一张与实现方式无关的业务能力全景图，它是连接业务战略和IT投资决策的桥梁 — 告诉你"组织能做什么"(What)，而不是"怎么做"(How)或"谁在做"(Who)。

为什么资深架构师仍需关注

1. 微服务边界划分的最佳输入: Domain-Driven Design的Bounded Context需要业务语义支撑，能力模型是最好的输入源
2. M&A尽职调查的架构工具: 并购时用能力地图做IT资产对比，比逐个系统对比高效10倍
3. 投资优先级排序: CIO/CTO每年面对数十个项目申请，能力热力图是最有效的决策工具
4. 避免重复建设: 大型金融机构常见"每个部门都在建自己的客户管理系统"，能力地图让重复一目了然

常见误区与反模式

---

知识点详解

知识点1: L0-L3层级设计原则

层级定义

L0 (领域级/Domain): 企业最顶层的业务领域划分
   通常4-8个，如: 客户管理、产品管理、风险管理...

L1 (能力组/Capability Group): 每个领域下的主要能力
   每个L0下3-8个，如: 客户管理→客户获取、客户服务、客户洞察...

L2 (能力/Capability): 具体的、可评估的业务能力
   每个L1下3-6个，如: 客户获取→线索管理、KYC、开户...

L3 (子能力/Sub-Capability): 当需要更精细分析时使用
   每个L2下2-4个，如: KYC→身份验证、地址验证、风险评估...

设计原则

原则1: 能力命名用"名词+名词"或"动名词"，不用"动词+名词"

✅ 正确: 客户身份验证(Customer Identity Verification)
❌ 错误: 验证客户身份(Verify Customer Identity)

原因: "验证客户身份"描述的是一个活动(Activity)，
而非能力(Capability)。能力是稳定的，活动可以有多种实现方式。

原则2: 能力应该与实现方式无关

✅ 正确: 支付处理(Payment Processing)
❌ 错误: SWIFT支付处理 / 支付网关调用

原因: "SWIFT"是一种具体的实现方式，未来可能被CIPS或
区块链支付替代。能力层面只关心"能不能处理支付"。

原则3: 同一层级的能力应该互斥且完整(MECE)

L1层级检验:
✅ 客户获取 | 客户服务 | 客户洞察 → 互斥且覆盖客户管理
❌ 客户获取 | 客户维护 | 客户投诉 → "维护"和"投诉"有重叠

原则4: L2是投资决策的核心层级

• L0/L1太粗，看不出差异
• L3太细，信息过载
• L2是最佳的"决策粒度" — 可以评估成熟度、分配投资、识别差距

典型金融企业L0-L2示例

零售银行能力地图(L0-L2):

L0: 客户管理
├── L1: 客户获取
│   ├── L2: 营销活动管理
│   ├── L2: 线索管理与评分
│   ├── L2: KYC与开户
│   └── L2: 渠道引流管理
├── L1: 客户服务
│   ├── L2: 多渠道客服
│   ├── L2: 投诉处理
│   ├── L2: 工单管理
│   └── L2: 客户反馈收集
├── L1: 客户洞察
│   ├── L2: 客户画像
│   ├── L2: 行为分析
│   ├── L2: 流失预警
│   └── L2: 交叉销售推荐

L0: 产品管理
├── L1: 存款产品
│   ├── L2: 活期存款管理
│   ├── L2: 定期存款管理
│   └── L2: 结构性存款管理
├── L1: 贷款产品
│   ├── L2: 消费贷管理
│   ├── L2: 抵押贷管理
│   ├── L2: 信用卡管理
│   └── L2: 贷款审批
├── L1: 投资产品
│   ├── L2: 基金代销
│   ├── L2: 理财产品管理
│   └── L2: 贵金属交易

L0: 支付与结算
├── L1: 支付处理
│   ├── L2: 境内转账
│   ├── L2: 跨境汇款
│   ├── L2: 批量代发
│   └── L2: 实时清算
├── L1: 收单
│   ├── L2: POS收单
│   ├── L2: 线上收单
│   └── L2: 二维码收款

L0: 风险管理
├── L1: 信用风险
│   ├── L2: 信用评分
│   ├── L2: 额度管理
│   └── L2: 不良资产管理
├── L1: 合规风控
│   ├── L2: 反洗钱(AML)
│   ├── L2: 反欺诈
│   └── L2: 制裁筛查
├── L1: 市场风险
│   ├── L2: 限额管理
│   └── L2: 压力测试

L0: 运营管理
├── L1: 核算
│   ├── L2: 总账管理
│   ├── L2: 对账
│   └── L2: 日终批处理
├── L1: 监管报送
│   ├── L2: 报表生成
│   └── L2: 数据报送

知识点2: 能力热力图 — 从地图到决策

能力地图本身只是"地图"，叠加热力图才能变成"导航"。热力图将每个能力(通常L2)按一个或多个维度着色。

常用热力图维度

热力图 → 投资决策的映射方法

投资决策四象限:

        高战略重要性
              |
    紧急投资   |   持续投入
   (高差距+    |  (低差距+
    高重要性)  |   高重要性)
              |
  ────────────────────────
              |
    观察/退出  |   维护
   (高差距+    |  (低差距+
    低重要性)  |   低重要性)
              |
        低战略重要性

示例:
- 紧急投资: KYC能力(监管要求高，现有系统老旧)
- 持续投入: 反欺诈能力(已有AI模型，持续优化)
- 维护: 总账管理(成熟稳定，无需大投入)
- 观察/退出: POS收单(如果战略转向纯线上)

能力热力图的实际制作方法

Step 1: 评估问卷设计

每个L2能力，由业务方和IT方分别评分(1-5分):

Step 2: 差距计算

差距分 = 战略重要性 - 当前成熟度
差距分 > 2: 红色(紧急)
差距分 1-2: 黄色(关注)
差距分 ≤ 0: 绿色(良好)

Step 3: 投资优先级排序

投资优先级 = 差距分 × 战略重要性权重 × 业务影响系数

业务影响系数:
- 影响客户体验: ×1.5
- 影响合规: ×2.0
- 影响运营效率: ×1.0
- 影响收入: ×1.3

知识点3: BIAN银行业参考模型深度

BIAN(Banking Industry Architecture Network)是银行业最重要的能力参考模型。它不只是一个能力清单，而是一个完整的服务导向架构参考。

BIAN核心概念

BIAN的三层结构:

Business Area (业务领域) → 约12个
   ↓
Service Domain (服务域) → 约300个
   ↓
Service Operation (服务操作) → 每个SD有标准操作

BIAN Service Domain示例(节选)

BIAN Service Landscape

BIAN Service Landscape是一张预定义的服务域关系图，展示了300个Service Domain之间的交互关系。它的价值在于：

1. 快速构建集成架构: 不需要从头分析系统间的集成关系，直接参考BIAN的标准交互
2. API标准化: BIAN为每个Service Domain定义了标准API(RESTful)，可以直接作为微服务API设计的起点
3. 供应商选型: 评估银行核心系统供应商时，用BIAN覆盖度作为评估标准

如何使用BIAN(实践方法)

Step 1: 下载BIAN Service Landscape (bian.org)
Step 2: 与自己的能力地图做映射
        自建能力 ←→ BIAN Service Domain
Step 3: 识别差距
        - BIAN有但自己没有的: 是否需要？
        - 自己有但BIAN没有的: 是否是行业特有？
Step 4: 参考BIAN API设计微服务接口
Step 5: 用BIAN做供应商评估矩阵

知识点4: 能力成熟度评估模型(CMM映射)

将CMM(Capability Maturity Model)的5级成熟度应用于业务能力评估：

关键洞察: 不是所有能力都需要到L5。成熟度目标应该与战略重要性匹配：

投资决策矩阵:

战略重要性 高 + 当前成熟度 L1 → 紧急投资到L3
战略重要性 高 + 当前成熟度 L3 → 持续投资到L4/L5
战略重要性 低 + 当前成熟度 L1 → 外包或SaaS
战略重要性 低 + 当前成熟度 L3 → 维护现状

---

对比分析

业务能力建模方法对比

能力建模工具对比

---

架构设计实操

实操: 对标BIAN为"数字银行"画L0-L3能力地图+热力图

设计目标

为一家新成立的数字银行(纯线上、无物理网点)设计完整的业务能力地图，并叠加热力图识别投资优先级。

设计方案

Step 1: L0能力域确定(基于BIAN裁剪)

数字银行L0能力域(8个):

1. 客户管理 (Customer Management)
2. 存贷产品 (Deposit & Lending)
3. 支付与转账 (Payment & Transfer)
4. 投资与财富 (Investment & Wealth)
5. 风险与合规 (Risk & Compliance)
6. 运营与核算 (Operations & Accounting)
7. 数据与分析 (Data & Analytics)
8. 技术平台 (Technology Platform)

Step 2: L1-L2展开(示例展开两个L0)

L0: 客户管理
├── L1: 数字获客
│   ├── L2: 数字营销管理 [战略:5 成熟:2 差距:3 🔴]
│   ├── L2: 在线开户(eKYC) [战略:5 成熟:1 差距:4 🔴]
│   ├── L2: 身份验证(生物识别) [战略:4 成熟:1 差距:3 🔴]
│   └── L2: 邀请与推荐 [战略:3 成熟:1 差距:2 🟡]
├── L1: 客户服务
│   ├── L2: AI智能客服 [战略:4 成熟:1 差距:3 🔴]
│   ├── L2: 人工在线客服 [战略:3 成熟:2 差距:1 🟡]
│   ├── L2: 自助服务中心 [战略:4 成熟:1 差距:3 🔴]
│   └── L2: 客诉与工单 [战略:3 成熟:2 差距:1 🟡]
├── L1: 客户洞察
│   ├── L2: 客户360画像 [战略:5 成熟:1 差距:4 🔴]
│   ├── L2: 行为分析与预测 [战略:4 成熟:1 差距:3 🔴]
│   ├── L2: 客户分群 [战略:4 成熟:1 差距:3 🔴]
│   └── L2: 流失预警 [战略:3 成熟:1 差距:2 🟡]

L0: 支付与转账
├── L1: 账户支付
│   ├── L2: 行内转账 [战略:5 成熟:1 差距:4 🔴]
│   ├── L2: 跨行转账 [战略:5 成熟:1 差距:4 🔴]
│   ├── L2: 定时/批量转账 [战略:3 成熟:1 差距:2 🟡]
│   └── L2: 跨境汇款 [战略:4 成熟:1 差距:3 🔴]
├── L1: 收付款
│   ├── L2: 二维码收付款 [战略:5 成熟:1 差距:4 🔴]
│   ├── L2: NFC支付 [战略:3 成熟:1 差距:2 🟡]
│   └── L2: 代扣代付 [战略:4 成熟:1 差距:3 🔴]
├── L1: 清结算
│   ├── L2: 实时清算 [战略:5 成熟:1 差距:4 🔴]
│   ├── L2: 日终批量结算 [战略:4 成熟:1 差距:3 🔴]
│   └── L2: 差错处理 [战略:4 成熟:1 差距:3 🔴]

Step 3: 热力图分析与投资优先级

投资优先级排序(差距分×战略重要性×业务影响系数):

P0(立即投资 — 开业必备):
1. 在线开户(eKYC) → 差距4×战略5×合规2.0 = 40
2. 行内转账 → 差距4×战略5×客户1.5 = 30
3. 跨行转账 → 差距4×战略5×客户1.5 = 30
4. 实时清算 → 差距4×战略5×合规2.0 = 40

P1(3个月内投资):
5. 客户360画像 → 差距4×战略5×收入1.3 = 26
6. 二维码收付款 → 差距4×战略5×客户1.5 = 30
7. AI智能客服 → 差距3×战略4×效率1.0 = 12
8. 数字营销管理 → 差距3×战略5×收入1.3 = 19.5

P2(6个月内投资):
9. 行为分析与预测
10. 跨境汇款
11. 代扣代付

ADR

ADR-002: 采用BIAN参考模型作为能力建模基线

状态: 已批准
日期: 2026-03-31

背景:
数字银行需要建立业务能力模型，用于指导系统建设和投资决策。
团队有两个选择：从头设计 vs 参考BIAN。

决策:
采用BIAN Service Domain作为L1-L2的参考基线，但做以下裁剪：
1. 去除物理渠道相关的Service Domain(无网点)
2. 增加"数据与分析"和"技术平台"两个L0(BIAN覆盖不足)
3. 增加数字原生能力(如eKYC、生物识别、AI客服)

理由:
1. BIAN覆盖了银行业80%的通用能力，避免重复发明
2. BIAN的API标准可以直接用于微服务设计
3. 未来与核心银行系统供应商对接时有统一语言

后果:
- 团队需要BIAN培训(2天)
- 需要维护BIAN映射表(自建能力 ↔ BIAN Service Domain)
- 某些数字银行特有能力(社交功能、游戏化)没有BIAN参考

权衡取舍

---

AI增强实践

本日AI提效方法

1. BIAN映射加速: 用AI将自建能力列表自动映射到BIAN Service Domain
2. 能力缺失检测: 让AI对比能力地图和业务需求，识别遗漏的能力
3. 热力图评估辅助: 用AI分析行业报告，提供各能力的行业成熟度基准

AI辅助的具体Prompt示例

Prompt 1: 能力地图生成

我正在为一家数字银行(纯线上、无物理网点)建立业务能力模型。

请基于BIAN v12.0的Service Domain分类，生成L0-L2的能力地图。
要求：
1. L0不超过8个
2. 每个L1不超过6个子能力
3. 去除与物理网点相关的能力
4. 增加数字银行特有的能力(如eKYC、生物识别、AI客服、社交功能)
5. 用树状结构输出
6. 每个L2标注对应的BIAN Service Domain编号(如果有)

额外要求:
- 与Nubank、Revolut、WeBank等成功数字银行对标
- 标注哪些能力是"开业必备"(Day 1 Capability)

Prompt 2: 能力成熟度行业基准

我需要为以下银行业务能力设置成熟度目标。请基于行业最佳实践，
给出国内外标杆银行在各能力上的典型成熟度等级(L1-L5):

能力清单:
1. 在线开户(eKYC)
2. 反洗钱(AML)
3. 实时支付处理
4. 客户360画像
5. AI智能客服
6. 跨境汇款

请对每个能力给出:
- 国内银行平均水平
- 国际领先水平(如DBS、Revolut)
- 建议的18个月目标
- 达到目标所需的关键投入

Prompt 3: 差距分析报告生成

基于以下能力评估数据，生成投资优先级报告:

[粘贴能力评估Excel数据]

报告要求:
1. 按P0/P1/P2/P3分类
2. 每个优先级给出投资理由
3. 给出粗略的投资估算(人月)
4. 识别能力间的依赖关系(如"客户画像"依赖"数据平台")
5. 生成一段给CIO的Executive Summary

AI生成 vs 人工判断的边界

---

与Web3/DeFi的关联

深度思考: DeFi协议也可以做能力建模。以Aave为例:

Aave的"业务能力地图":
├── 借贷管理
│   ├── 存款管理(Supply)
│   ├── 借款管理(Borrow)
│   ├── 利率管理(Interest Rate)
│   └── 清算管理(Liquidation)
├── 风险管理
│   ├── 资产风险评估(Asset Risk)
│   ├── 用户健康度监控(Health Factor)
│   └── 风险参数治理(Risk Parameters)
├── 治理
│   ├── 提案管理(Proposal)
│   ├── 投票管理(Voting)
│   └── 执行管理(Execution)
└── 集成
    ├── 预言机集成(Oracle)
    ├── 闪电贷(Flash Loan)
    └── 跨链部署(Multi-chain)

---

今日思考

思考1: 能力建模最大的挑战是什么？

不是"怎么画"，而是**"怎么让人用"**。我见过太多能力地图画完后束之高阁。解决方法是：

• 能力地图必须与投资决策直接挂钩(热力图)
• 能力地图必须与项目申请模板关联(每个项目必须标注影响哪些能力)
• 能力地图必须有owner(每个L1必须有一个业务owner负责)

思考2: 能力模型和微服务边界的关系是什么？

这是一个常见但容易犯错的问题。能力 ≠ 微服务，但能力是划分微服务边界的重要输入：

• L2能力通常对应一个Bounded Context
• 一个Bounded Context可能包含1-3个微服务
• 关键判断标准：能力之间的数据耦合度和变更频率

例如"信用评分"和"额度管理"是两个L2能力，但它们共享客户信用数据，变更频率相似，可能属于同一个Bounded Context(信用域)。

思考3: 金融行业的能力建模有什么特殊性？

金融行业的特殊性主要体现在三方面：

1. 监管能力是硬性要求: AML、KYC、监管报送等能力不是"可选"的，必须从Day 1就到L3以上
2. 资金安全能力不可妥协: 清结算、对账、日终处理等能力的成熟度直接关系资金安全
3. 牌照约束能力边界: 不同牌照(支付牌照、银行牌照、证券牌照)决定了能做哪些能力

---

面试题准备

Q1: 如何用能力建模驱动IT投资决策？

30秒版本: 建立L0-L2的业务能力地图，叠加"战略重要性"和"当前成熟度"两个维度的热力图，用差距分数(战略重要性-当前成熟度)乘以业务影响系数来排序投资优先级。这种方法让IT投资从"谁喊得响谁先做"变成"数据驱动的优先级排序"。

2分钟版本:

我的方法分四步：

第一步，建立业务能力地图。我通常参考行业标准(银行用BIAN，零售用APQC)作为基线，然后根据企业实际裁剪到L0-L2，大约30-60个L2能力。

第二步，做能力评估。每个L2能力由业务方评"战略重要性"(1-5分)，由业务+IT联合评"当前成熟度"(1-5分)。这个过程本身就是一次非常有价值的业务-IT对话。

第三步，生成热力图和投资优先级矩阵。差距分 = 战略重要性 - 当前成熟度。再乘以业务影响系数(合规类×2.0，客户体验×1.5，收入×1.3，效率×1.0)。按得分排序就是投资优先级。

第四步，与项目组合管理(PPM)打通。每个项目申请必须标注它影响哪些L2能力，以及预期将成熟度提升多少。这样年度项目组合评审就有了统一的评估标准。

实际效果：我在之前的项目中，用这个方法帮助一家金融机构将年度IT预算的分配从"政治博弈"变为"数据驱动"。最终砍掉了3个低优先级项目(节省了约800万)，将资源集中到2个高优先级能力建设上。

追问准备:

• 追问: 如果业务方对战略重要性的评估不一致怎么办？ → 用Delphi方法做两轮评估，取中位数。差异大的能力做专题讨论
• 追问: 这个方法的局限性是什么？ → 1)依赖评估质量 2)不能完全消除政治因素 3)短期紧急需求可能被低估
• 追问: 能力建模需要多长时间？ → 首次建模2-4周(含Workshop)，后续维护每季度1-2天

Q2: 能力建模在微服务架构设计中怎么用？

30秒版本: L2业务能力通常对应DDD中的Bounded Context，是微服务边界划分的最佳输入。但不是1:1映射——需要结合数据耦合度、变更频率和团队边界(Conway's Law)来最终确定微服务粒度。

2分钟版本:

能力模型在微服务设计中有三个用途：

第一，识别Bounded Context。每个L2能力是一个候选的Bounded Context。然后通过分析能力间的数据共享关系(共享哪些核心实体？)和变更频率(多久改一次？改的时候是否一起改？)来决定是否合并或拆分。

第二，定义服务契约。能力模型的名词术语就是Ubiquitous Language的基础。比如"客户身份验证"这个能力，它的输入输出就是对应微服务API的基础。

第三，团队组织设计。根据Conway's Law，组织结构决定系统架构。能力模型可以反过来指导团队划分——每个团队负责1-3个关联的L2能力。

具体方法：我会画一个能力关联矩阵(Capability Affinity Matrix)，行和列都是L2能力，格子里填数据共享强度(0/1/2/3)。然后用聚类分析找出"数据紧密耦合"的能力簇——每个簇就是一个Bounded Context，也就是一个(或一组)微服务。

追问准备:

• 追问: 如果一个能力太大(如"支付处理")怎么拆？ → 展开到L3，每个L3可能是一个微服务
• 追问: 如何处理跨能力的共享数据？ → 用事件驱动(Event-Driven)解耦，避免共享数据库

---

学习资源

---

明日预告

Day 3: 价值流×能力×投资三角 — 将能力地图与价值流(Value Stream)结合，建立从客户价值到IT投资的完整链路。学习Value Stream Mapping在金融行业的高级应用，实操画"跨境支付"端到端价值流并映射到能力和投资优先级。