外观
自研还是采购：一份内部工具 TCO 核算清单避坑实录
问题背景：免费开源并不等于零成本
很多团队在做内部工具选型时，第一反应是：能开源就别采购，能自研就别外包。理由听起来很充分：数据在自己手里、需求可以随时改、没有 License 费用，还能沉淀团队技术能力。
但真正上线半年后，问题往往不是“能不能用”，而是“谁来维护”。登录认证要接公司 SSO，权限模型要适配组织架构，审计日志要满足合规要求，浏览器升级后页面白屏，依赖库爆出漏洞要紧急修复。最初节省的采购费，可能很快被两三个工程师的长期投入吞掉。
因此，自研、开源自部署、商业采购之间，不应按“喜好”或“技术信仰”决策，而应按 TCO（Total Cost of Ownership，总拥有成本） 核算。TCO 不只看首年采购价，而是评估工具从引入、运行、维护到退出的全周期成本。
方案对比：自研、开源与采购的成本结构
企业内部工具通常有三类路径：
- 完全自研：从需求分析、架构设计、前后端开发到运维监控全部自建；
- 开源自部署：基于成熟开源项目二次开发，自行负责部署、升级、安全与定制；
- 商业采购 / SaaS：支付订阅或 License 费用，由供应商提供产品能力、维护与 SLA。
三者最容易被误判的地方，是只比较“首年现金支出”。自研看起来没有采购价，但占用了最昂贵的工程师时间；SaaS 看起来每年都要付费，却可能显著降低运维与合规成本；开源看似免费，但版本分叉、插件兼容、安全响应都可能变成隐性税。
TCO 核算清单：不要只填采购价格
一套可执行的核算清单，建议按 5 个维度计算三年成本。之所以建议三年，是因为一年太短，容易低估维护；五年又过长，业务和技术路线可能已变化。
1. 显性成本：最容易看见的现金支出
包括 License、订阅费、实施费、培训费、服务器、数据库、对象存储、日志监控、专线与安全设备等。
采购方案要特别注意价格口径：用户数是按注册人数、活跃人数，还是管理员数计费？测试环境是否单独收费？私有化部署是否需要额外节点费？
自研方案也要计入基础设施费用。一个内部系统即使只有 200 人使用，也可能需要测试环境、预发环境、生产环境、备份、监控、告警与灾备，这些都不是“顺手搭一下”。
2. 人力成本：自研决策中最大的隐藏项
核算人力时，不要用工资，而应使用“全成本人天”。一个工程师的成本除了薪资，还包括社保、办公场地、设备、管理摊销、招聘成本和机会成本。
可用下面的简化公式估算：
text
方案三年人力成本 = 投入人天 × 全成本人天单价
示例：
- 初级开发 2 人 × 3 个月：120 人天
- 高级开发 1 人 × 2 个月架构与评审：40 人天
- 测试、运维、安全评审：30 人天
- 上线后每年维护：60 人天 × 3 年 = 180 人天
总投入：370 人天
若全成本人天单价为 2500 元：
三年人力成本 = 370 × 2500 = 925000 元这还没有计算项目延期导致的业务等待成本。很多自研项目的真实问题，是团队只估算了“开发第一个版本”的时间，没有把后续三年维护排进人力计划。
3. 运维与安全成本：上线只是付款开始
内部工具通常要接入统一登录、权限、审计、日志、监控、备份、漏洞扫描和变更流程。每次依赖升级、证书更换、数据库扩容、浏览器兼容修复，都需要真实人力。
开源自部署还要评估社区健康度：维护者是否稳定、Issue 响应是否及时、版本发布频率如何、是否有清晰的升级文档、开源协议是否允许企业内部使用和二次修改。一个协议不清晰的项目，即使功能再强，也可能带来法务风险。
4. 机会成本：工程师没有去做更重要的事
这是管理层最应关注、技术团队最容易忽略的一项。如果两名工程师花三个月做一个通用工单系统，他们就无法同时推进核心业务的自动化测试、性能优化或数据治理。
判断机会成本，可以问三个问题：
- 这个工具是否构成公司的核心竞争力？
- 市场上是否已有成熟产品能满足 80% 需求？
- 自研带来的差异化收益，是否显著高于工程师投入其他项目的收益？
如果答案分别是“不构成”“有”“不显著”，采购通常更合理。
5. 退出成本：避免从一个系统换到另一个系统
任何选型都要假设未来可能替换。退出成本包括数据导出、历史数据迁移、接口改造、权限重建、用户培训和双轨运行。
SaaS 方案要确认是否支持标准 API、批量导出、数据删除证明和合同到期后的宽限期。自研或开源自部署也要避免把流程写死在代码里，否则未来迁移时会发现，真正的资产不是代码，而是一堆难以搬迁的业务状态。
实操步骤：用评分表把争论变成决策
建议在选型会上使用一张简单评分表，而不是围绕“哪个技术更先进”争论。
| 评估项 | 自研 | 开源 | 采购 / SaaS | 说明 |
|---|---|---|---|---|
| 三年显性费用 | 低 | 中低 | 高 | 包含基础设施、License、实施费 |
| 三年人力投入 | 高 | 中 | 低 | 开发、维护、升级、安全都要计入 |
| 上线速度 | 慢 | 中 | 快 | 业务紧迫时速度本身就是收益 |
| 个性化匹配 | 高 | 中 | 中低 | 差异需求是否真的关键 |
| 安全合规 | 自控高 | 取决于团队 | 看资质与合同 | 数据分级决定可选范围 |
| 退出难度 | 中高 | 中 | 中 | 重点看数据与接口可迁移性 |
| 战略相关性 | 高才值得 | 视情况 | 通常低 | 非核心能力不轻易自研 |
评分时不要追求绝对精确，而要迫使团队把假设写出来。例如“自研只需一个月”必须拆成需求澄清、接口联调、SSO、权限、审计、测试、上线和运维文档；“SaaS 数据不安全”也要具体到数据等级、合规条款、加密方式和供应商资质，而不是情绪化判断。
一个实用的决策原则是：核心差异化能力自研，通用标准化能力采购，介于两者之间且开源生态成熟时，可选择自部署并严格控制二次开发。
例如，发布系统如果深度绑定公司的微服务治理、灰度策略和合规审批，可能值得自研；但员工报销、通用知识库、问卷调查、项目协同等标准场景，通常采购更划算。
避坑总结：三类常见误判与修正方法
坑 1：把开源 License 免费当成 TCO 为零
常见现象：团队认为“项目可以直接拉下来跑”，于是没有预算、没有负责人，也没有升级计划。半年后版本严重落后，安全漏洞无法修复，定制代码与上游主线冲突。
修正方法：立项时明确系统 Owner、维护窗口和版本策略；二次开发尽量通过插件、外部适配层或配置完成，避免直接修改核心代码；每季度评估一次升级成本和社区活跃度。
坑 2：只估算开发成本，不估算维护成本
常见现象：项目汇报中写“两人两个月上线”，但上线后需求变更、权限调整、故障排查、依赖升级无人认领，最终演变成“谁写的谁一直背”。
修正方法：预算中至少加入三年维护人天，并把监控、告警、备份、灾备、安全扫描和文档写入验收标准。没有明确维护人的内部系统，不应进入生产环境。
坑 3：因为少量特殊需求否定成熟商业产品
常见现象：业务方提出一个冷门字段、一个特殊审批节点或一张个性化报表，就认为 SaaS “不满足需求”，转而启动自研。
修正方法：区分“必须有”“适合有”和“以后有”。对非核心差异点，优先通过配置、流程调整或外围小工具解决；只有当特殊需求直接影响核心业务效率或合规时，才把它作为自研理由。
坑 4：忽略供应商锁定与数据退出条款
常见现象：采购时只看功能演示和折扣，合同中没有数据导出格式、API 限流、到期后数据保留期限和安全删除义务。替换时才发现历史数据无法批量迁出。
修正方法：选型阶段进行数据迁移演练，至少验证用户、权限、附件、审批记录和操作日志能否导出；合同中写明数据归属、交付格式、协助迁移义务和到期宽限期。
结语：好的自研决策，是知道什么不该自研
技术团队容易把“自己造”理解为能力强，把“买现成”理解为没追求。但成熟的技术判断恰恰相反：在资源有限的现实组织里，把工程投入投向真正形成业务差异化的地方，才是更高阶的能力。
开源、自研和采购没有道德高下，只有成本结构和风险收益不同。把三年 TCO 算清楚，把系统 Owner 定下来，把退出路径提前设计好，选型争论才会从立场之争变成可复盘的工程决策。
免责声明
本工具与文章内容仅用于学习测试场景，优化建议仅供参考，请勿直接用于生产环境，由此产生的风险自行承担。