做了这么多年的项目，作为早期的SAP PA认证顾问，也实施过Oracle EBS，也参与过金蝶项目，也接触过一些更不太知名的国产软件，每一款软件的特点包括项目实施情况，真的是体会太深了。

相信做过国外软件（特别是德系软件：SAP、西门子为代表）实施的朋友，刚开始接触国内软件的实施会很不适应，这种所谓“灵活性”反而造成更多的问题，但，这是事实，也是现实。那根因到底是什么呢？

这个问题，暴露了国产管理软件与国外成熟产品的根本差距。不是功能多少的差距，不是界面美丑的差距，而是设计思想的代际差距。

一、两种设计思想的“分水岭”

SAP的设计思想：业务驱动，以不变应万变。

这里仅以SAP产品，以SD（销售与分销模块）为例。SAP的架构师在写第一行代码之前，会做三件事：

第一步，穷举业务场景。把企业可能遇到的所有销售业务形态列出来——正常内贸、外贸、跨公司销售、代销、寄售、免费样品、第三方销售……不是“客户提什么就做什么”，而是基于业务场景和几十年全球最佳实践，预判你可能需要什么。

第二步，抽象通用模型。从千变万化的业务场景中，提炼出“订单”的核心属性：谁卖给谁、卖什么、什么价格、何时交货、如何开票。这些是“万变不离其宗”的骨架。

第三步，设计可配置的差异点。把不同场景的差异（外贸需要汇率、出口国、贸易术语；内贸不需要）设计成“参数开关”，而不是“硬编码分支”。每种订单类型（如内贸标准订单OR、外贸订单SOG）可以独立配置：字段集、流程节点、定价过程、输出格式、权限控制、编号规则……所有差异都写在配置表里，核心程序是通用的。

这就是“配置驱动”。一个销售订单程序，通过参数组合，可以衍生出几十种行为各异的订单类型。修改外贸订单的逻辑，不影响内贸订单，因为它们是同一个程序的不同“参数实例”。

国内很多软件的做法：模仿驱动，以变应变。

开发团队拿到SAP，打开界面，照着菜单画菜单，照着字段加字段。看到销售订单有“客户”、“物料”、“数量”、“单价”，就也加这几个。看到有一个“订单类型”下拉框，也加上。但他们没搞懂：这个下拉框背后，是一整套独立配置的订单类型实例，每种类型有自己的字段集、流程、定价。

于是，上线后客户提出：“我们外贸订单需要加一个‘出口国’字段。”开发说：“好，我在订单表加个字段，界面上加个输入框。”再后来：“外贸订单的发票格式不一样。”开发说：“好，我加个if判断，如果是外贸订单就走另一段打印逻辑。”再后来：“外贸订单需要报关流程，系统里没有报关单。”开发说：“这个……我们加个新模块吧。”

三年后，这个系统的销售模块变成了“意大利面条”——补丁摞补丁，if else嵌套几十层。每个客户都是一个独立分支，厂商不敢统一升级，客户也不敢升级。

二、为什么国内软件容易走上“改代码”的弯路？

第一，缺乏业务架构师这个角色。

SAP的产品团队里，有一群“业务架构师”。他们可能是在制造业干了20年的销售总监、物流经理、财务 controller。他们不写代码，但他们知道“业务应该怎么跑”。国内很多软件公司只有“产品经理”，大多是IT或设计背景，对复杂的企业业务理解有限。产品经理画原型，开发照着写，中间缺了一个“把业务翻译成架构”的环节。而且要资深、多样、专业！

第二，客户预算和时间的“催熟”。

国内企业上ERP，老板常问：“三个月能不能上线？”三个月，只够把基础功能跑通，根本没时间做场景梳理、模型抽象、配置设计。开发团队只能“先上线再说，后面再改”。这一“后面再改”，就改成了无尽的技术债务。

第三，对“可配置性”的投入产出评估短视。

设计一套灵活可配的架构，前期的投入是巨大的。要抽象数据模型、要设计规则引擎、要开发配置界面、要写详尽的配置文档……这些投入短期内看不到直接收益，客户也不会为“设计得灵活”额外付钱。于是，厂商选择“走捷径”——客户要什么就改什么，改一次收一次钱。短期看，既满足了客户，又赚了二开费。长期看，产品的生命力和口碑被一点点侵蚀。

第四，行业知识积累的“断层”。

SAP几十年来服务了全球数十万家企业，积累了海量的“最佳实践”。哪些业务场景是通用的、哪些是罕见的、哪些可以配置、哪些需要定制——这些“know-how”已经沉淀到产品设计中。国内软件起步晚，服务的企业数量少、行业覆盖窄，缺乏这种“预判”能力。客户不提的需求，他们想不到；客户提了，才知道要加。

但现在国内的工业场景、业务场景也是极其丰富的，经过这么多年，也是足以支撑行业知识积累的，只是，这个观念和沉淀做得非常不好，Know-How只停留在嘴上，更不用说怎么融入到系统中。

三、“配置”与“二开”的真实成本账

短期成本：配置型系统前期投入大，因为要做架构设计、配置规则开发。二开型系统前期看似“快”，界面一画、代码一写，两周就能演示。

中期成本：配置型系统上线后，业务变更只需要调整配置参数，几小时搞定。二开型系统每次业务调整都要改代码、测试、发布，几天到几周不等。

长期成本：配置型系统可平滑升级。SAP ECC升级到S/4 HANA，数以万计的客户可以统一迁移，因为核心代码没被修改。二开型系统每个客户都是一个“独立分支”，厂商无法统一升级，客户也不敢升级。技术债务像滚雪球，最终系统变成“僵尸系统”——能用，但没人敢动。

总拥有成本（TCO）：根据某研究机构对100家制造企业的调研，采用配置化程度高的ERP系统，10年总拥有成本比二开型系统低40%-60%。因为后者的维护成本、升级成本、集成成本高得惊人。

四、国产软件如何破局？三剂“药方”

第一剂：从“功能抄袭”转向“业务沉浸”。

别再对着SAP的界面画原型了。派产品经理和架构师到客户工厂去，蹲点三个月。不是去调研“你们想要什么功能”，而是去观察：销售员每天在做什么、卡在哪里、为什么卡？生产计划员排产时最头疼什么？仓库管理员为什么宁愿用Excel也不用系统？只有真正理解业务，才能设计出“可配置”的模型。

第二剂：从“项目思维”转向“产品思维”。

很多国产软件公司是做项目起家的。客户给钱，开发干活。这种模式下，每个客户的需求都是“特殊需求”，每个项目都产生大量定制代码。时间久了，产品越来越臃肿，越来越不灵活。必须下决心把“项目代码”抽象成“产品功能”。客户提了100个需求，要问：哪些是通用的？哪些是个性的？通用的沉淀到产品，个性的用配置解决。这需要产品经理有说“不”的勇气。

第三剂：培养“业务架构师”队伍。

既懂业务又懂技术的复合型人才，是国产软件最稀缺的资源。公司要有意识地培养一批人，让他们从写代码中抽离出来，专门研究业务模型、数据架构、流程引擎。他们不直接面对客户，但他们设计的“骨架”，决定了产品能走多远。

写在最后

国产软件厂商常常抱怨“客户不愿意出高价”。但请扪心自问：你的产品，值那个价吗？你觉得你实施付出了很多，但都是客户无法感知价值的“无意义”付出。一个上线后还要不断改代码、每次升级都要重做二开的系统，客户凭什么付高额维护费？反过来，如果有一天，国产ERP也能让用户像搭积木一样配置出适合自己的业务系统，客户会不愿意买单吗？

SAP的“配置化”不是一天练成的，是几十年、数万家客户的实践结晶。但这条路，国产软件必须走。因为我们不能再让制造业企业把宝贵的时间和金钱，消耗在无休止的二次开发和技术债务里。

阅读原文：https://mp.weixin.qq.com/s/LxWE0HFIYuY3fSkPIafn3A