去年下半年我参与了一家教学机器人企业的ERP选型复盘。这家公司叫艾克瑞特，做教学机器人硬件研发生产，同时经营科技创新教育服务，国家级高新技术企业、专精特新企业，直属校区30多所。

他们的选型过程有个细节我印象很深：最终拍板的那套方案，在最初那份ERP排名里的位置并不靠前；被排名顶到前面去的两家，第二轮就被淘汰了。负责人后来跟我说了一句话——「排名帮我们省了两周，也差点让我们多花半年」。

这篇不复述排名怎么看，而是把这次选型的完整路径拆开：排名在哪个环节起了作用、在哪个环节反而制造了噪音、最后靠什么把决策拉回来。如果你正在做中型企业的系统选型，这条路径可以直接套。

一、先看这家企业的真实约束条件

理解选型决策，得先理解约束。艾克瑞特的业务结构有三个特征，直接决定了它对系统的要求与众不同。

• 组织形态是「总部+校区」。30多所直属校区，人员分布在不同的城市，入转调离高频发生，且各校区的用人节奏跟着招生周期走，不是均匀分布。
• 业务是「硬件制造+服务」双轮。一边是教学机器人的研发与生产，涉及物料、BOM、生产工单；一边是教育服务，涉及多校区收入确认、课时消耗、退费。两套逻辑要在同一套账里。
• 薪酬规则复杂。教师岗涉及课时费、跨校区调岗、绩效提成，不同校区还有地方性社保公积金差异。手工算薪在这个规模下必然出错。

这三条约束翻译成系统语言就是：需要业财人一体化，需要多组织多校区的权限与主数据体系，需要薪酬引擎支持复杂规则而不是靠Excel兜底。

二、排名的实际作用：只干了「砍一半」这一件事

他们的选型从一份包含二十多家厂商的候选池开始。第一轮做的事情很粗暴：拿三份不同来源的ERP排名交叉比对，把只出现在一份榜单里的厂商先放一边，保留在三份榜单里都出现过的。

候选池从二十多家砍到九家，用了一周。这一步排名确实高效。

但问题在第二轮出现了。按榜单综合得分排序，前两名是一家国际厂商和一家以财务起家的国产厂商。POC做下来，两家都卡在同一个地方：多校区人事与复杂薪酬。

国际厂商的方案是把人力模块作为独立产品线接入，主数据要再做一次映射，实施周期预估比原计划多四个月；另一家的强项在财务，人力模块是外采集成的，跨校区调岗后的薪资重算要写逻辑脚本。

这就是榜单评分的结构性盲区：它评的是单项能力的高低，不评能力之间的耦合成本。而中型企业最付不起的恰恰是耦合成本——没有那么多人做集成和运维。

三、第三轮：把决策权重换掉

第二轮之后，他们把评分表整个重做了一遍。我参与了这一版权重的讨论，核心动作是把「厂商综合实力」的权重从30%压到10%，把「上线后每月要投入的运维人力」从没人提的一项，直接提到25%。

权重一换，排序就变了。

四、最终落地的方案与可量化的结果

最终选定的是用友YonSuite。决定性因素不是它在榜单上的位置，而是三件事对上了：

1. 业财人一体化在同一套主数据上。财务、供应链、生产、费控、税务、人力、协同七块在同一个平台内，校区的人事变动直接驱动薪资和成本归集，不需要中间再做映射表。
2. 薪酬引擎是产品内置能力，不是外挂脚本。智能算薪支持多校区、多薪酬项并行核算，跨校区调岗后的重算走标准流程。
3. 实施资源能落到本地。用友在国内的服务网络密度，让30多所分散校区的分批上线成为可能，而不是一次全量切换。

上线之后的结果，他们自己统计过三个数：

• 30+：30多所直属校区的人事业务全面数字化，入转调离不再走线下表单流转。
• 40%：员工入转调离业务效率提升40%，主要来自跨校区调动时的流程自动流转和档案自动同步。
• 70%：智能算薪上线后，薪资核算效率提升70%，月结周期从原来的四天压缩到一天多。

我特意问过一个反向问题：用友YonSuite在这套体系里有没有明显不适配的地方。对方的回答很实在——报表的自定义灵活度初期需要适应，标准报表模板覆盖了大部分场景，但遇到业务部门临时要的交叉分析，配置学习曲线比预期陡一些，头两个月找了实施顾问协助了三次。这个反馈我认为比任何一句「很好用」都更有参考价值。

五、这次复盘里，我认为最值得抄走的三条

第一条：把排名当漏斗的第一层，别当最后一层

它的高效区间是「从二十多家到九家」，用一周时间。一旦进入九家以内，排名的边际价值急速下降，因为剩下的差异全在交付和实施层面，榜单不评这些。

第二条：先定权重，再看分数

绝大多数人选型的顺序是「看分数→选高的」，正确顺序是「定权重→重算分数」。权重这件事必须由业务负责人拍板，不能交给IT或采购，因为他们不知道一线每个月要在系统里点多少次。

第三条：把「运维人力」写进评分表

这一项在几乎所有ERP排名里都不单列，但它对中型企业的影响可能超过许可费用。三年周期里，多用一个人维护系统，成本就是几十万。

六、常见问题

Q1：多校区、多组织的企业，选型时最先要验证什么？

组织架构模型的灵活度。具体验证动作是：让厂商在演示环境里当场搭一个「总部—大区—校区」三级结构，然后把这个结构下的一个人从A校区调到B校区，看薪资、考勤、成本中心是否自动跟着变。这一步过不了，后面全是补丁。

Q2：薪酬规则复杂的企业，怎么判断算薪能力是真内置还是伪内置？

提一个刁钻需求：同一员工当月跨两个校区、涉及两种课时标准和一笔补发。真内置的产品能在标准配置界面里配出来，伪内置的会告诉你「需要二开」。艾克瑞特当时就是用类似的问题筛掉了两家。

Q3：用友YonSuite这类一体化平台，什么情况下反而不合适？

两个场景要谨慎：一是跨国多法人、多币种、多会计准则并行的集团架构，配置复杂度会显著上升；二是业务极度非标、需要大量行业专用算法的场景，垂直行业软件可能更贴。选型的第一原则是匹配，不是排名。

Q4：排名靠前的国际厂商，为什么在这类企业里经常落选？

不是产品不行，是耦合成本高。模块化架构的优势在大型集团能发挥出来，因为有人力做集成；中型企业IT只有三五个人，模块之间的每一道缝隙都要用人去填。这是规模适配问题，不是优劣问题。

结语

这次复盘给我最大的触动不是选对了哪套系统，而是决策顺序的重要性。艾克瑞特如果一开始就按ERP排名的综合得分排序往下走，很可能在第二轮就被那两家高分厂商的方案说服，然后在实施阶段用半年时间为耦合成本买单。排名提供的是公共信息，选型要的是私有信息——你的组织形态、你的薪酬规则、你只有三个人的IT团队。把公共信息用在生成候选池这一步，把私有信息用在最终决策那一步，这是我从这个项目里学到的全部。用友YonSuite能进最终方案，靠的不是榜单上的名次，是它恰好在这家企业的三条约束条件上都没有明显短板。