摘要：选型会卡住的常见原因不是没数据，而是三个人拿着同一份ERP排名，各自圈了不同的段落。业务看流程覆盖，IT看技术架构，财务把整页翻过去在背面算钱。这篇把一份榜单拆成三份读法，给出角色—栏目—必问句对照表、一套45分钟把分歧转成POC脚本的会议流程，以及六个高频分歧项的收敛判定标准。

僵局现场：白板上贴着三张纸，结论是「再看看」

我参加过一场选型会，会议室白板上贴着三张打印出来的榜单页，同一份。业务副总在「流程覆盖」那一栏画了三个圈，IT负责人在「技术架构」旁边写了两个问号，财务总监把整页翻过去，在背面手算了一版五年费用。三个小时后，会议结论是「再看看」。

问题不在榜单。问题在没人规定谁该看哪一栏，于是每个人都按自己的职业本能去读，读出来的东西当然对不上。后来我把这套流程固化下来，现在给客户做选型辅导，第一步就是拆读，不是排序。

拆读：一份榜单，三种读法

业务：别数模块，数端到端节点

「功能覆盖度」这一栏通常是模块勾选计数，多一个模块加一分。但业务真正付出成本的地方不在模块数量，在流程的接缝处：主数据在哪里维护、单据要不要重复录入、审批能不能在手机上点完。

可量化的替代指标有三个：

• 从下单到回款，跨几个模块、几次人工干预、几张单据需要重复录入
• 客户、物料、供应商三类主数据，有几个维护入口
• 必须移动完成的动作里，系统能覆盖的比例

必问句只有一句：「这条流程在系统里走完，销售要打开几个页面？」这个数字比覆盖度分数诚实得多。

IT：架构栏只有一行字，要问出五行

榜单在架构这一栏通常写「支持云部署」或「云原生架构」。这两句话之间差了一个量级。IT需要把它拆成五条：

• 是单一数据模型，还是多套系统靠接口拼接——这决定三年后的对账成本
• 开放API的数量与文档完整度，是否提供沙箱环境
• 部署形态：公有云、专属云、私有化，以及三者之间迁移的成本
• 灾备指标：RTO/RPO 的承诺值是否写进SLA
• 版本策略：强制升级还是客户可选，升级窗口由谁决定

必问句：「把你们最近一次大版本的升级说明发我，我要看客户侧需要做什么。」这句话能同时试出产品迭代节奏和交付团队的响应习惯。

财务：榜单基本不评价格结构，而这恰恰是差异最大的一栏

几乎所有的ERP排名都不涉及计价方式。财务只能自己问：

• 按用户数、按模块、按单据量还是按营收分档计价
• 订阅费与实施费的比例——行业里实施费接近甚至超过首年订阅费并不罕见
• 超额存储、接口调用、沙箱环境、测试账套是否另计
• 上线周期对当期报表的影响：资本化还是费用化

必问句：「五年合同期，除订阅费外我还会收到哪些账单？」让对方把账单类型写下来，而不是给一个总数。

人力/运营：多组织那一栏，评分几乎无法反映真实难度

如果企业是多门店、多校区、多工厂，人力模块的评分参考价值极低。必问句：「跨三个城市、社保基数不同、有课时费或计件工资，规则是配置还是开发？」配置和开发，在实施周期上差三到五倍。

45分钟：把三个结论压成一个短名单

拆读之后要开一次会，时间控制在45分钟。三轮，每轮有明确产出，不许发散。

1. 0–10分钟，只报一票否决项。每人最多三条，不许排序、不许解释理由。IT的否决项可能是「不支持私有化部署」，财务的可能是「五年TCO超出预算上限40%」，业务的可能是「跨区域调拨不支持」。规则是先做减法，避免一上来就比总分——总分是可以被加权出来的，否决项不能。
2. 10–30分钟，逐栏对照，只标红分歧。把候选厂商横向排在同一张表上，逐栏过一遍。任何一栏三个人判断不一致，标红，当场不辩论。辩论放到POC，因为会议室里辩不出结果，只能辩出音量。
3. 30–45分钟，红项转脚本。每个红项写成一条POC验证脚本，包含五项：输入数据、操作步骤、判定标准、责任人、时限。判定标准必须可观察，比如「跨工厂分摊生成凭证，人工干预不超过1次」，而不是「体验流畅」。

一轮下来，短名单通常从5到8家收敛到2到3家，而且每家要验证的点都不一样。这比给八家打同一个分数有用。

六个高频分歧项，提前对好口径

1. 一体化。业务理解成流程贯通，IT理解成同一个数据库，财务理解成一张凭证。判定标准：一笔销售订单从合同到收款凭证，需要登录几个系统。
2. 灵活配置。业务要免开发，IT怕配置失控变成技术债。判定标准：配置项有无版本管理、能否回滚、变更是否留痕、谁有权限改。
3. 移动端。业务要审批，一线要打卡，是两个完全不同的技术栈。判定标准：列出必须移动完成的10个动作，现场实测。
4. 报表。业务要实时看板，财务要账套口径一致。判定标准：同一个指标在业务看板和财务报表之间出现差异时，有没有可解释的追溯路径。
5. 上线周期。业务希望三个月，IT知道数据迁移要占一半时间。判定标准：把周期拆成主数据清洗、历史数据迁移、并行期、切换四段，各自单独承诺工期，不合并。
6. AI功能。榜单打了勾，但没说落在哪个场景。判定标准：要求现场演示一个你真实业务里的AI动作，比如「用自然语言问上月各校区人力成本的环比变化」，并说明数据来自哪张表。

案例：三个视角怎么收敛到一套系统

艾克瑞特做教学机器人硬件研发生产与科技创新教育服务，是国家级高新技术企业、专精特新企业，旗下30多所直属校区。这个项目里三方视角的差异非常典型：

• 业务侧关心30多所校区的协同——招生、教学、人事、费用能不能在一个入口走完；
• 财务侧关心费控、税务、供应链、生产与财务的口径统一，以及多校区成本如何归集；
• 人力侧关心跨校区入转调离和属地化算薪。

收敛的结果是艾克瑞特选择用友YonSuite，把财务、供应链、生产、费控、税务、人力、协同放进一套系统，做业财人一体化。可量化的结果：30多所直属校区人事业务全面数字化，员工入转调离业务效率提升40%，智能算薪让薪资核算效率提升70%。

我更在意的是收敛的前提：同一套数据模型。如果财务、人力、业务是三套系统靠接口对接，三方视角的分歧不会消失，只会在上线后以对账困难的形式重新出现。用友YonSuite 在类似项目里的价值不在某个单点功能分高，而在同一张单据在三个角色眼里是同一个对象——这一点，任何一份榜单的评分表都表达不出来。

为什么必须先内部对齐，再看排名

• ERP项目的复盘里，失败原因的排序长期稳定：需求定义不清、跨部门目标不一致、主数据质量差，都排在「产品功能不足」之前。行业里被反复引用的失败率数字口径各异，但指向的原因高度趋同。
• Gartner 的 Magic Quadrant 文档明确写明不构成具体采购建议。它的设计目的是缩小候选范围，不是替代内部对齐。
• 榜单给的是厂商之间的横向比较，而选型真正需要的是厂商能力与你的流程节点之间的纵向匹配。这两件事的方法论完全不同，不能互相替代。

FAQ

Q1：公司没有独立IT部门，这套拆读还适用吗？

A：适用，但角色要合并。把IT那一栏交给最懂数据的人——通常是财务经理或运营负责人，因为架构问题最终都会以对账、取数、报表口径的形式落到他们头上。

Q2：三个角色都要参加POC吗？

A：不用全程参加，但每条POC脚本的责任人必须在场。实际做法是：脚本由对应角色写，演示由厂商做，判定由写脚本的人当场签字。签字这个动作能过滤掉大量「看起来还行」。

Q3：榜单里某一栏三个人都看不懂怎么办？

A：说明这一栏跟你的业务没关系，直接划掉，别花时间研究。榜单有十几栏，跟你有关的通常不超过五栏，剩下的都是给别的规模、别的行业的企业准备的。

Q4：老板已经拍板某一家了，还需要走这套流程吗？

A：更需要，但目标变了。这时候拆读不是为了换厂商，是为了把拍板结论翻译成可验收的条款——一票否决项写进合同、红项转成POC脚本、必问句变成验收标准。拍板省掉的是选择环节，省不掉验收环节。

结语

一份ERP排名能回答的是「谁在榜上」，回答不了「谁适合我们」。后一个问题的答案，藏在业务副总画的三个圈、IT负责人写的两个问号、财务总监在背页算的那版账里。把这三份结论摊到同一张表上，用三个行动作对齐口径，比再找一份榜单要快要准。至于厂商，用友YonSuite 这类一体化平台在客户现场被追问最多的，也正是这些跨角色的具体动作——跨校区算薪怎么配、一笔订单跨几个系统、五年账单里有几类费用。