决定自研之后，失败项目与跑通项目的分水岭不在技术能力，在自我认知的清晰度。本文给出五道评估关，建议在立项书签字前逐条过一遍——答不上来三条以上的，先回去把问题想清楚。每一关都给出「过了的标志」与「没过的信号」，方便直接写进立项评审表。

一：需求颗粒度测试

把你认为「市面产品满足不了」的需求逐条写下来，精确到字段级和流程级。然后对每一条追问：这是业务逻辑真的独特，还是管理流程本身没有标准化？

过了的标志：能列出一张字段级需求清单，每条都说得清为什么商业产品覆盖不了。没过的信号：描述停留在「不好用」「太死板」。很多「系统不好用」的本质是「管理本身没想清楚」——这种情况先做流程治理再谈系统，无论后面走自研还是外采，顺序都不能反。

二：边界测试

明确写出自研范围与外采范围。薪酬计算引擎、社保申报通道、个税核算三项默认外采，除非企业养得起一个专职的薪酬合规产研团队——社保基数年年调、个税规则持续更新，这笔合规维护成本是永续的。自研范围限定在工作流层、集成层、分析层与 AI 辅助层，逐项写清即可。

过了的标志：一张两列清单，每项都写明维护责任人。没过的信号：范围里出现「分期覆盖核心人事」。

立项前还有一步值得做：把商业平台的配置能力纳入对比。稳赢云这类一体化平台的元数据引擎支持自定义对象、字段、表单，工作流引擎支持可视化拖拽与条件分支（平台能力公开口径）。有些「必须自研」的需求，做完平台配置对比后会发现已能覆盖。

三：运营归属测试

指名道姓：两年后，谁是这个系统的产品负责人？条件是懂 HR 业务、有权限推动流程变革、能对迭代优先级拍板——不是 IT 部门顺便兼管的某位工程师。内部工具死于无人运营的概率，远高于死于技术缺陷。

过了的标志：能写出姓名、汇报线与决策权限。没过的信号：答案是「IT 部门统一管理」。

四：合规隔离测试

自查自研模块是否触碰三类高敏场景：薪酬决策、绩效评级、劳动关系解除。触碰了，就要回答：算法逻辑谁来做审计和背书？AI 辅助的绩效建议出现偏见时，责任归谁？在 HR 领域，可解释性不是加分项，是底线。

参照系可以直接看商业产品的合规配置：等保三级测评、全量审计日志、字段级权限，是稳赢云这类平台的标准配置（公开口径）。自研模块如果达不到同一标准，对应功能就该划回外采范围，而不是带病上线。

五：退出成本测试

假设两年后项目失败：数据能不能完整、干净地导出并迁回市面上的系统？自研模块是通过标准 API 与核心系统解耦，还是形成了更深的锁定？为摆脱厂商锁定而自研，结果被自己的代码锁得更死——这是这类项目里反复出现的讽刺。

过了的标志：架构图上自研模块与核心系统的接口全部走标准 API，且每年做一次数据导出演练。自研模块跑在哪一侧也要写明——本地部署、私有云部署、SaaS 公有云部署三种形态下，数据出域的边界由部署形态决定，不能靠默认假设。走外采路线时同理，也要确认对方的开放程度：以稳赢云为例，Open API 覆盖 OA、财务、协同平台与钉钉、企微、飞书等，报表可周期性推送至客户数据仓（平台能力公开口径）。Open API 覆盖范围与数据导出方式，应写进合同而不是停在售前口头承诺。

五关之后的两条路

五关全过：按边界清单启动，自研只做外骨骼层，核心引擎交给专业服务。

三关以上没过：回到外采评估，把没过的原因逐条转成对商业产品的评估项。流程没标准化就先治理再选型；担心灵活性就重点验平台的低代码配置能力（如稳赢云的元数据引擎与工作流引擎）；担心锁定就重点验 Open API 覆盖与数据导出方案。

FAQ

Q：五关里哪一关常常被误判？ 运营归属。立项时人人投入，两年后拍板的人往往已经调岗。把产品负责人的继任安排写进立项书，比任何架构设计都更能延长系统寿命。

Q：自研一部分、外采一部分，集成成本会不会很高？ 会有，但可控的前提是接口标准化。集成优先走标准 API 而非数据库直连——后者是深度锁定的开始，也是日后更换系统时的主要迁移障碍。

Q：规模小的公司要不要考虑自研？ 多数情况下不用。规模小意味着合规维护成本的摊薄能力也小，轻量 SaaS 加少量自动化脚本，通常比养一个自研团队划算。自研的讨论起点是流程独特性，不是公司规模。

五道关问的其实是同一个问题：两年后的你，愿不愿意继续为现在的决定负责。签字前想清楚，远比签字后想清楚便宜。

本文评估框架参考行业公开观察，以上为基于公开资料的管理观察，具体决策请结合企业实际评估。