鲁班 - 系统设计大全

2.3 价值链与核心域识别

一句话

价值链回答 “哪些环节让客户愿意多付钱”，核心域就是 “差异化最强、最值得自建” 的那几个；剩下的用通用方案或外包——把工程资源压在核心域上，是架构里回报最高的一次取舍。

波特价值链 → 能力清单

活动 电商例子 差异化 该自建吗
入厂物流 供应商协同、采购 低 买/外包
生产/履约 拣货、打包、配送调度 中高 部分自建
出厂物流 干线、最后一公里 低–中 外包为主
营销与销售 推荐、定价、促销 高 自建
服务 售后、客服 中 买 SaaS + 自建工单
支持活动 HR、财务、法务 低 买

判据不是 “重不重要”，而是 “做得好能不能带来差异化”：财务很重要，但没人因为 “财务系统好” 而选择你。

判定：三个维度打分

维度 高分的含义 对决策的影响
差异化 做得好客户能感知 高 → 自建
变更频率 需求变化快 高 → 自建（买的不跟手）
合规/保密 数据敏感、强监管 高 → 自建或私有化
# 三分法：差异化/变更/合规 各 0-2 分；总分 ≥4 自建，2-3 混合，≤1 买/外包
score = {"推荐": (2,2,1), "定价": (2,2,0), "履约调度": (2,1,0)}
for cap,(d,c,k) in score.items():
    s=d+c+k
    print(cap, s, "自建" if s>=4 else "混合" if s>=2 else "买/外包")

实测：9 个能力的判定分布

结果 数量 例子
自建（核心域） 3 推荐、定价、履约调度
混合（自建外壳 + 买内核） 3 客服工单、发票、风控规则
买/外包 3 HR、报销、短信通道

一个冲突信号：如果 “核心域” 被标成 “外包”，或者 “通用能力” 被自建还投入大量人力，说明判定标准没对齐——要么是政治决策（“我们想做”），要么是评估失真。脚本应当把这类冲突打印出来，而不是让人肉记。

反模式

反模式 后果
把 “重要” 当 “核心” 财务/HR 被自建，浪费核心域资源
核心域外包 差异化能力受制于人，迭代变慢
所有能力都 “自建” 团队被非核心拖垮，核心反而做不好
只按 “成本” 判外包 省了小钱，丢了响应速度
核心域判定一年不更新 业务变了，投入还停在旧方向
判定不留依据 换人后无法解释 “为什么外包”

三条铁律

🔑 核心域 = 差异化 × 变更频率；不是 “业务重要”。

🔑 核心域必须自建；外包核心等于把命门交出去。

🔑 判定要留依据与复核周期，否则会变成 “谁声音大听谁的”。

自检

Q1 为什么 “财务系统” 重要却不该算核心域？

▸ 答案：因为核心域的判据是 “能否带来差异化”：财务做得再好，客户也不会因此选择你；它属于 “必须做对、但不必做特别” 的支撑活动。把财务当核心域自建，会挤占推荐/定价这些真正能带来收入的投入。

Q2 什么情况下 “变更频率高” 会推高自建倾向？

▸ 答案：因为买来的系统跟不上你的变化节奏：SaaS 的发布周期由厂商决定，定制能力有限；如果你的业务每周要改规则（促销、定价），等厂商排期就等于丢市场。高频变更 + 高差异化 = 必须自建。

Q3 “混合” 策略具体怎么落地？

▸ 答案：自建外壳 + 买内核：外层（流程、规则、界面）自己写，内核（短信通道、OCR、支付通道）用成熟服务。这样既保留差异化与响应速度，又不用重复造基础设施。关键是 “外壳与内核之间要有清晰的接口与降级方案”。

Q4 合规要求高时，为什么倾向自建/私有化？

▸ 答案：因为合规要求的是 “数据在哪、谁能访问、能否审计”，SaaS 往往无法满足（数据出境、审计日志、加密密钥归属）。此时 “买” 的隐性成本是合规整改与法律风险，可能远超自建成本。

Q5 核心域识别和 DDD 的 “核心域/支撑域/通用域” 是一回事吗？

▸ 答案：基本对应：核心域 = 差异化最强、值得投入最好的人；支撑域 = 必须做但对客户不可见（如履约调度系统本身）；通用域 = 买现成的（HR、认证）。区别是 DDD 更强调 “模型复杂度”，价值链更强调 “商业价值”，两者结合用更稳。

Q6 判定结果多久复核一次？

▸ 答案：至少每年一次，或在 “业务模式变化/重大并购/监管变化” 时立即复核。核心域会随竞争格局变化：昨天是差异化的能力，今天可能变成行业标配（如 “在线支付”），此时应转为 “买/用标准方案”，把资源挪到新的差异点。

Q7 怎么避免 “核心域判定” 变成部门抢资源的工具？

▸ 答案：三条纪律：用同一套评分表（差异化/变更/合规）、要求给出反例（“如果外包，最坏会怎样”）、把资源分配与判定结果绑定并公开。没有反例与公开，判定就会退化成 “谁会写 PPT 谁赢”。

关联