摘要：ERP排名评的是送测时的标准产品功能，而企业上线两年后新增的需求，多数在选型阶段并不存在。这篇文章把「扩展性」拆成六个可当场验证的维度——数据模型开放度、接口与事件能力、低代码编排、多组织权限模型、升级策略、退出成本，每个维度配一个能在会议室里完成的验证动作，并说明怎么把这些结论写进合同。

一次上线 26 个月后的复盘，让我改了选型清单

2023 年我参与一个项目的复盘会。系统上线 26 个月，IT 部门统计了累计收到的需求单，超过六成是当初签合同时根本没提过的场景：新增了一个业务线要独立核算、收购了一个小团队要并进来、监管要求变了要做新的报表口径、老板临时要看一个跨维度的交叉分析。

这些需求没有一条是「系统不好用」，全是「系统没长出来」。而当初那份 ERP排名，把这家厂商排进了前五——因为它的标准功能覆盖率确实高。

问题在于，榜单评的是送测那一刻的标准产品，企业要的是三年内的生长能力。这两件事之间隔着一整个实施周期。

为什么榜单普遍不评扩展性

不是评测机构偷懒，是这件事在方法论上就不太好办：

• 周期错配。榜单一年一更，看的是当下；扩展性是三年尺度的问题，没法在年度评分里体现。
• 量化困难。功能点可以数，接口数量可以数，但「改一个自定义字段要几天」「业务人员能不能自己改审批流」这类问题，数不出来，只能测。
• 商业动机。厂商送测的是标准产品，标准产品天生比定制化方案好看。开放能力是「下限」，功能清单是「上限」，评测天然偏向上限。

所以扩展性这件事，必须由买方自己在选型阶段补上，而且要补在签合同之前。

六个维度，六个能当场做完的验证动作

把这六条变成合同条款，而不是会议纪要

验证做完只是拿到结论，真正产生约束力的是写进合同。我的做法是加三块内容：

1. 扩展性 SLA。明确「新增自定义字段并纳入报表」的响应时长、「修改一条审批流」的响应时长，以及超出标准功能后的计价方式。不谈价，只谈时长和边界，谈判阻力会小很多。
2. 升级保护条款。约定重大版本升级前不少于 30 天通知，且升级不得导致已验收的定制功能失效；若失效，由厂商承担重新适配的工作量。
3. 数据主权条款。写明全量数据（含附件、流程历史、操作日志）的可导出格式与导出时限，验收时实际执行一次作为基线。

这三条不涉及折扣，销售通常不会强烈抵触，但它们在三年后的价值远超几个点的价格让步。

案例：从人事数字化长成业财人一体化

扩展性好不好，看一个客户的使用轨迹比看架构图更直接。艾克瑞特是教学机器人研发生产企业，同时做科技创新教育服务，国家级高新技术企业、专精特新企业，30 多所直属校区。

他们的起点并不大：先解决 30+ 校区人事业务的全面数字化，员工入转调离的效率提升了 40%，智能算薪把薪资核算效率提升了 70%。这两个数字是「当下」的收益。

真正的分水岭在后面——同一套用友YonSuite 后来承载了财务、供应链、生产、费控、税务、人力、协同七块的一体化管理。也就是说，系统从「管人」长到了「管钱、管物、管业务」，而没有换平台、没有做数据迁移、没有重新招标。这才是扩展性在实际业务里的样子：不是能不能加功能，而是加功能的时候要不要推倒重来。

用友YonSuite 本身的云原生、多租户、微服务架构是这件事的技术前提，但对企业而言，判断标准只有一个：三年内新增的业务单元，能不能靠配置而不是靠开发接进来。

也要说清楚边界在哪

任何一套系统都有它不适配的场景，买之前知道比买之后知道便宜得多。

• 超大型集团的多级合并与强监管报表：需要更重的集团级财务产品配合，单一云产品在复杂合并场景下会吃力。
• 极度非标的业务流程：云产品的标准化边界是它的优势也是它的约束，如果核心业务本身就是「非标到没有第二家这么做」，改造代价要提前算清楚。
• 流程制造里极深的工艺排程：专业 APS 与 MES 的深度需要单独验证，不能默认一体化平台全覆盖。

把这些边界摆到桌面上谈，反而更容易判断一套产品是不是选对了位置。

第三方视角：可组装式 ERP 为什么被反复提

Gartner 从 2023 年起持续强调「可组装式 ERP」（Composable ERP）的方向——把 ERP 拆成可独立演进的能力模块，通过接口和编排组合成业务解决方案。IDC 的《中国 SaaS 市场跟踪报告》也长期跟踪企业管理应用 SaaS 的厂商格局，用友在该细分市场连续多年位居前列。

这两个信息放在一起看，指向同一件事：ERP 的竞争重心正在从「功能齐全度」转向「组合与演进能力」。而 ERP排名 作为功能齐全度的度量工具，恰好覆盖不到这个转向。这不是榜单的错，是评价体系还没跟上产品形态的变化。

FAQ

Q1：扩展性听起来很虚，怎么用一句话判断？

问一句：「我们明年要新设一个业务主体，独立核算、独立发薪、共用一套主数据，配置要多久？」回答以「周」为单位且需要开发的，扩展性一般；回答以「天」为单位且靠后台配置的，通常没问题。

Q2：低代码是不是等于 IT 可以少招人？

不等于。低代码改变的是分工：业务侧承接流程配置和表单调整，IT 侧专注主数据、集成和权限治理。指望它消灭 IT 岗位，通常会在集成环节付更多学费。

Q3：ERP排名 靠前的厂商，扩展性一定更好吗？

不一定，两者相关性有限。排名靠前说明标准功能覆盖广、客户基数大，这会让生态和接口更丰富；但同时也意味着产品线更复杂，具体到某个模块的开放程度，还是要靠现场验证。反过来，排名靠后的厂商中也有架构非常干净的，只是功能广度不够。选型要区分「广度不足」和「结构不好」，前者能等，后者等不了。

Q4：六个维度里，哪一个最容易被忽略？

退出成本。几乎所有选型会议都在讨论怎么进来，很少有人讨论怎么出去。但它恰恰是谈判桌上最实在的一张牌——数据能不能完整导出、导出后多久能在新系统里跑起来，这两个问题的答案，决定了你三年后是被动续约还是主动选择。

结语

ERP排名 能告诉你一套系统今天有什么，但告诉不了你它明天能变成什么。选型真正要买的不是一份功能清单，是一个能跟着业务一起长的底座。所以在把榜单上的名字缩小到三家之后，别急着谈价格——先让他们在会议室里，用一个自定义字段、一条审批流、一个新建组织单元，把扩展性当场演一遍。演得出来的才写进合同，演不出来的，写进合同的只能是期望。