Custom Software · 深度解读
自建还是采购：构建与购买的决策网格
何时自建定制软件、何时采购平台：一套基于流程契合度、总拥有成本、锁定、数据所有权与价值实现时间的决策网格。
架构 · 自建还是采购
输入 · 待启用的能力
产出 · 自建 / 采购 / 组合
核心 vs 通用（价值地图）
把系统拆解为各项能力，将每一项放上核心/通用品轴：把让你在市场上与众不同、并值得自有代码的部分，与已沦为通用品、直接向最便宜供应商购买的部分区分开来。
与业务流程的契合度
衡量你的流程有多专有：行业标准成熟的通用流程推向平台，而属于你优势一部分的流程推向定制，因为在这里平台强加的变通方案比专门构建的代码更贵。
5 年总拥有成本
计算五年成本，含维护、集成与培训——不只是许可证或初始报价——因为软件成本的大部分发生在上线之后，而这正是推翻裁决之处。
锁定风险与退出权利
在进入之前先权衡退出成本：合同、数据可迁移性与硬接线的集成，决定了你在续约时是握有筹码，还是面对一个深知此点的供应商而毫无筹码。
数据所有权
核查让你与众不同的数据仍归你所有，可导出为开放标准且独立于供应商：单个不可导出的项目就可能推翻决策，因为一项变成人质的资产，其分量重于任何标价上的节省。
价值兑现时间
在价值的紧迫性与优势的持久性之间取得平衡：一个已有的成熟方案让你现在就动起来，而一项结构性的差异化要素则证明更长、更持续的实施是值得的。
表明你的自建-采购分界线画错了位置的信号
问题从来不是「定制还是平台」。而是：哪种能力值得拥有自有代码，哪种是可以购买的通用品。出现这些症状，说明分界线画在了错误的位置。
- 你在定制一套标准平台 ，直到它面目全非：供应商每次发版都会破坏你的配置，「开箱即用」已变成一个长期的开发项目。
- 你从零构建了一项通用品 ——认证、支付、通知——把工程能力花在市场早已解决的问题上，而不是你的竞争优势上。
- 让你与众不同的数据被困在某个供应商内部 ，以私有格式存放，无法导出为开放标准：它不再是资产，而是人质。
- 从未有人算过五年的账 ：决策是基于许可证标价或开发报价做出的，忽略了主导整个生命周期的维护、集成与培训。
- 更换供应商不可想象 ：多年期合同、不可迁移的数据与硬接线的集成，把退出成本抬高到一个在续约时让你毫无议价权的水平。
面向首席技术官、首席运营官与运营负责人，他们必须决定在何处投入工程能力、在何处依靠市场，并以能在董事会面前站得住脚的标准来决定。
购买通用品，自建让你与众不同之物
最牢靠的运营法则不是财务的，而是战略的：把每项能力放上价值地图，依其位置而非依写代码者的偏好来决策。这是一套由 Wardley Mapping 正式化的方法论。
核心 vs 通用品，而非个人口味
一项让你在市场上与众不同、且快速演进的能力，值得拥有自有代码。一项已沦为通用品的能力——你与竞争对手别无二致——是成本中心：向最便宜的供应商购买即可，无需多想。自建通用品就是在已解决的问题上焚烧工程能力。
流程契合度才是真正的分水岭
如果你的流程是通用的、行业已有成熟标准，平台凭速度取胜。如果流程是专有的、是你优势的一部分，平台会强加变通方案，加总起来比专门构建的代码更贵。平台把你弯向它的模型；定制则把软件弯向你的模型。
配置并非免费
在购买与自建之间还有第三条路——配置与集成——但它并不中立。把一套复杂平台塞进特定流程，连同数据迁移与培训，早在第一笔交易之前就承载着真实成本。陷阱是过度定制：从推荐配置起步，在使用数据上迭代，别在第一天就重写一切。
Compose：兼取两者之长，但要有纪律
成熟的做法是混合式：标准功能采用市场能力，通过有文档的 API 连接，而内部工程能力集中在真正让你与众不同的部分。这就是可组合（composable）逻辑（微服务、API-first、cloud-native、headless）：可替换的组件，更换时不会让与之相连的一切崩塌。
决策必须是结构性的，而非情绪化的
对能力进行测绘让选择变得可读：你能看到每个组件在「起源—通用品」轴上的位置、它依赖什么、演进将其推向何方。自建-采购的分界线不再是部门偏好，而成为一项可辩护的架构决策。
我们如何逐项能力地划线
我们不为整个系统决定「定制还是平台」。我们把系统拆解为能力，让每一项通过同样的关口。产出是一张地图，而非一种观点。
我们把系统拆解为各项能力，将每一项放上核心/通用品轴：什么让你与众不同，什么已成为标准。这就区分出值得自有代码的部分与你直接购买的部分。
对每项能力，我们检验你的流程有多专有。60-70% 标准、例外可控：配置。属于优势一部分的流程：自建。通用流程：购买。
我们计算五年成本，含维护、集成与培训——不只是许可证或初始报价。同时衡量退出成本：数据可迁移性、导出权利、对集成的依赖。
每项能力得到一个裁决——build、buy 或 compose——以及它在架构中的位置。通用品置于有文档的 API 之后；差异化部分成为自有代码，数据在你的掌控之下。
从能力地图到可辩护的决策网格只需数周，而非耗费一个季度做研究。
Build、Buy 还是 Compose：决策关口
每项能力都要通过五个杠杆。这不是分数累加：单个杠杆就可能推翻决策（不可导出的专有数据，其分量重于任何标价上的节省）。
| 决策杠杆 | 推向 BUY / 平台 | 推向 BUILD / 定制 |
|---|---|---|
| 在地图上的位置 | 通用品能力，与竞争对手别无二致 | 让你与众不同且快速演进的核心能力 |
| 流程契合度 | 通用流程，行业标准成熟 | 专有流程；平台强加昂贵的变通方案 |
| 五年总拥有成本 | 维护与风险由供应商承担 | 用量与使用时长摊销自建成本 |
| 锁定与退出 | 导出为开放标准，可因便利而退出，通过 API 集成 | 关键数据必须保持自有，独立于供应商 |
| 价值实现时间 | 现在就需要价值；已有成熟方案可用 | 优势足以证明更长、更持续的实施是值得的 |
网格守护的四项资产
一项稳健的自建-采购决策不只优化成本。它守护那些一旦失去便无法再买回之物。
数据所有权
让你与众不同的数据仍归你所有，可导出为标准格式且独立于供应商。不是私有竖井中的人质，而是一项可议价的资产，在续约时赋予你筹码。
花得明智的工程能力
每一个开发小时都用在你的竞争优势上，而非市场早已解决的通用品上。该定制处定制，不该处则用市场。
退出权利
数据可迁移性、有文档的 API 集成、没有私有接线，让切换成本保持低位。能够离开，正是让你留在公平条款上的原因。
可组合架构
通过 API 连接的可替换能力：一个组件更换而其余不崩塌。系统随时间保持鲜活，而非一块需要重做的单体。
自建让你与众不同之物，购买你与竞争对手共有之物。
决策前人们常问我们的问题
定制是否总比平台更贵？
在生命周期上并非如此。软件成本的大部分发生在上线之后——维护、集成、培训。在通用品上平台取胜，因为它把这部分成本转嫁给供应商。在用量大、使用时长长的核心能力上，定制会被摊销，而平台的价格随时间攀升。答案在五年总拥有成本里，而非入门价里。
我可以先买、以后再建吗？
可以，而且往往是正确的一步——只要你别落入陷阱。为了快速起步而购买是合理的，前提是数据仍可导出为开放标准、集成走有文档的 API。若供应商以私有格式扣住你的数据，「以后」就会变成一次你永远不会做的昂贵迁移。可迁移性在签约时谈，而非在分手时谈。
我们如何避免自建市场做得更好的东西？
在写代码之前对每项能力进行测绘。如果一项功能已成为标准——你与竞争对手别无二致——自建它就是焚烧工程能力。自有代码留给让你与众不同且不断演进的部分；其余一切要么购买、要么通过 API 组合。这份纪律把投资与开销区分开来。
案例笔记
从问题到结果——已匿名。
被改得面目全非的平台
问题 一家零售商把一套标准电商平台定制到面目全非：供应商每次发版都会破坏配置，「开箱即用」已变成一个长期的开发项目，而定价引擎——他们真正的差异化要素——被困在他们无法掌控的约束之中。
方法 我们在核心/通用品轴上对能力进行测绘：目录、结账与支付作为通用品保留在平台上、置于有文档的 API 之后；定价与促销引擎，作为竞争优势的一部分，抽取为以可组合方式接入的自有服务。
结果 供应商发版不再破坏系统，工程能力回到定价而非变通方案上，让他们与众不同的逻辑成了他们自己的代码——可替换而不致让其余部分崩塌。
被扣作人质的数据
问题 一家金融服务公司把让它与众不同的客户数据存放在某个供应商内部，以私有格式且无法导出为开放标准：更换不可想象，续约时供应商握有全部议价权，因为退出实际上被封死了。
方法 我们应用了锁定与数据所有权这两道关口：在合同中断点重新谈判导出为标准格式的权利，把关键集成迁移到有文档的 API 上，并把差异化数据收回内部掌控，让通用功能留在原处。
结果 退出成本下降到足以在续约时恢复议价权，数据重新成为可议价的资产而非人质，能够离开正是让他们留在公平条款上的原因。
从零自建的通用品
问题 一家物流运营商从零自建了已成通用品的能力——认证、通知、用户管理——在市场早已解决的问题上焚烧工程能力，而路线规划这一他们真正的优势，却投入不足。
方法 我们让每项能力通过价值地图与五年总拥有成本：把通用品上的定制退役，改用置于 API 之后的市场服务，并把开发者集中到路线优化上，那里用量与使用时长摊销了专门构建的代码。
结果 每一个开发小时都回到了差异化要素上，通用品的维护转移给供应商，架构变得可组合——可替换的组件，更换时无需重做整个模块。
继续深入