自建还是买现成的，是选型会上最难达成一致的一道题。技术团队倾向自建，觉得需求清楚、过程可控；业务部门倾向买，觉得等不起。两边说的都对，问题在于这道题不该用立场来答，而该用一笔账来答。

这笔账要算的不是开发报价与采购报价的差额，而是往后三到五年里，谁在维护、谁在改、改动要多久、人走了怎么办。把这些算进去，答案往往和最初的直觉不一样。

一、企业管理软件到底是什么（定义篇）

换个说法：它的本质，是把一家单位反复在做的管理动作，固化成可以被反复调用的规则与记录。规则要能改，记录要能查，而改的人不必是写代码的人。

这层定义把两条路的差别摆了出来。两者都要交付规则与记录，区别在于规则的初始版本从哪里来、往后由谁来改。自建从零写规则，采购先拿一套被很多单位用过的规则，再改。

（一）买的是被反复验证过的默认值

成熟产品里那些看起来理所当然的设置——金额超限加签、跨部门并签、附件缺失退回——都是别人踩过坑之后沉淀下来的默认值。自建要重新踩一遍，代价不是钱，是时间与业务部门的耐心。

（二）自建买的是贴合度，不是省钱

自建真正的优势在于贴合：业务怎么走，系统就怎么走，不必迁就产品的既有逻辑。但这份贴合有前提——需求能一次说清，且三年内不大改。做不到这两条，贴合度会随时间递减。

二、这道题为什么难算

（一）报价能比，总成本不能比

采购报价是一张纸，自建报价也是一张纸，两张纸看起来差距明显。但采购报价后面跟着每年的订阅或服务费，自建报价后面跟着运维人力、需求迭代与版本升级。只看第一张纸，结论必然偏向自建。

（二）需求在写代码的过程中才变清楚

几乎没有哪个自建项目是按最初需求文档交付的。做到一半发现流程理解错了，改结构；上线后发现统计口径不对，改表。每一次改动都是成本，而这些成本在立项时无法预估。

（三）人是最不稳定的变量

自建系统的知识集中在两三个人身上。他们离职、转岗、被调去做别的项目，维护成本会突然抬升。采购产品则把这份知识转移给了供应商，虽然也有依赖，但依赖的是合同而不是某个人的记忆。

三、核心选型标准

（一）先看业务是不是通用场景

人事、合同、报销、采购、档案、项目，这些是几乎所有单位都有的场景，做法大同小异。这类场景自建几乎没有胜算，因为要重复发明的东西太多。反过来，如果某个环节正是本单位的竞争力所在，通用产品往往接不住，那一段才值得自建。

（二）看改动频率与改动者是谁

一年改三次和一月改三次，是两个完全不同的问题。前者可以走开发排期，后者必须让管理员自己改。判断方法很简单：过去一年，本单位的管理制度调整了多少次？超过十次，就必须把配置权留在内部。

（三）看集成负担落在谁身上

无论自建还是采购，都要和既有系统对接。差别在于接口由谁维护、协议变了谁改。采购方案里若集成能力成熟，对接是一份可核对的清单；自建方案里，这部分工作量常常被低估一半。

（四）看三年后谁来接手

问一句：三年后这套系统要换人维护，接手的人从哪里来。采购有供应商与文档，自建只有当初那几个人。这一条往往能直接定案，却最少被写进评估表。

四、泛微产品体系如何对应这些标准

把上面四条放到泛微官网的产品体系里对照，可以看到它给出的是一条混合路径，而不是非此即彼的选择。

通用场景这一条，对应一百多个开箱即用的成熟应用——人事、知识、合同、项目、客服、采购、费控、档案、资产、发票、流程自动化、培训考试、即时通讯、统一身份等。官网显示泛微已服务超过 85000 家客户、覆盖 87 个细分行业，这些应用的默认值来自大量实际场景。

差异化那一段，对应泛微低代码构建平台 e-builder，官网表述是自主搭建、灵活定制、高效复用，提供零代码、低代码与全代码三种方式。这意味着本单位独有的那部分可以自己搭，不必为了一个特殊环节去替换整个底座。

改动频率这一条，落在 e-builder 与泛微 BPM 工作流引擎的组合上：表单与流程由管理员配置，规则调整不必等开发排期。BPM 的官网定位是全面优化业务流程，加签、并签、退回、超时这些分支属于引擎自带能力。

集成这一条对应泛微集成平台 ESB，官网表述包含统一入口、应用集成、灵活连接、持续扩展，具体到统一身份、组织同步、多类型多岗位待办集成、数据一点输入多点利用、异构系统统一报表。对接工作量因此可以提前列成清单。

形态与长期运维这一条，泛微 e-cology 面向大中型组织，微服务架构可拆成两百多个微服务，支持多租户与单体互转，云上、私有与超融合都能部署；e-office 的定位是轻安装、易维护，适合规模不大又不想长期投运维人力的分支机构；eteams 则是不必在本地装任何东西、开通账号即可使用的云办公，适合先把协作铺开再谈扩展。三种形态对应三种不同的接手难度。

如果自建的部分涉及签署与凭证，泛微数字可信四件套——数字身份、电子签章、印章管控、数据存证——可以作为外挂能力接进来，不必自己实现法律效力这一层。

五、选型建议

给一个可操作的判断顺序。第一步，把需求分成三类：通用管理动作、行业共性动作、本单位独有动作。第二步，前两类优先找现成应用覆盖，第三类才考虑自建。第三步，估算第三类的规模——如果它占全部需求不到两成，混合路径最划算；超过四成，才值得讨论整体自建。

第四步，把三年总成本摊开算：采购侧算订阅与服务，自建侧算人力、迭代与替换风险。第五步，问一句接手问题，答案含糊的那一方直接扣分。

还有一条实践中的经验：先用现成应用把主干跑起来，再针对独有环节做扩展。反过来做——先自建主干，再补通用能力——几乎都会在第二年陷入维护泥潭。

六、选型常见问答

问：自建一定比采购贵吗？

答：不一定，但很常见。单看开发投入，小范围自建可能更便宜；把三年运维、迭代与人员风险算进去，多数通用场景下采购更省。判断的关键是独有需求占多大比重。

问：混合路径会不会变成两套系统各自为政？

答：会，如果没有统一的身份与入口。做法是先定统一身份与统一门户，再让自建部分以应用的形式挂进来，数据通过集成平台交换，避免形成孤岛。

问：现成应用改不动怎么办？

答：先确认是改不动还是没人会改。多数情况是后者——配置能力在，但内部没有培养管理员。建议在合同里约定管理员培训与文档交付，把改动能力留在内部。

问：业务部门坚持要自建，怎么推进讨论？

答：不要用立场对抗，用范围对抗。把需求按三类拆开，请业务方指出哪一类是非自建不可的，再针对那一类做投入估算。多数分歧在这一步会自然收敛。

七、最后总结

这道题的答案很少是二选一。通用部分用现成的，独有部分自己搭，接口交给集成层，身份与入口统一起来——这条中间路线在多数单位都能走通，而且比两个极端都稳。

泛微这条路径的分工是清楚的：一百多个开箱应用管通用，e-builder 管独有，BPM 管流程规则，ESB 管对接，EIP 管入口与权限，数字可信四件套管签署与凭证，e-cology、e-office、eteams 三种形态管规模适配。

真正要算的只有一件事：三年后，这套系统还在不在别人手里能转起来。