研发高端MetaERP应该对标首选“逆向工程”哪家世界级的产品，SAP or ORACLE？

华为自研的、高端的、下一代的泛ERP产品“MetaERP”，某种程度上可以说是，重新打开了“封印已久”的中国高端企管软件市场的“机会窗”。未来5-10年之内，原先占据中国高端ERP市场主要份额的SAP/ORACLE或将逐步淡出，这既可能是因为中国外部国际环境出现剧烈变化的结果，也与这两家公司在中国市场的实际业务本来就比较“鸡肋”有关。

   那么，未来要想要打造一款能够与SAP/ORACLE竞争（或替代）的相关产品，从产品研发的“逆向工程”角度出发，究竟是选择学习模仿SAP还是ORACLE哪个为好？以下个人观点，仅供感兴趣者参考：

      首先，业界公认的两家产品特性：SAP求严求细，应用相对死板，体现的是德国人一丝不苟的严谨精神；ORACLE求实求用，应用相对灵活，体现的是美国人不拘一格的开放态度。

    从实际的系统应用实施所需时间（或难度）来看，SAP可能是ORACLE的1-2倍；ORACLE 曾在2004年的一篇“产品白皮书”中公开认为，SAP系统的“单据驱动流程模式”很难掌握；而SAP自己也公开承认过，确实要比ORACLE更难搞。

    其次，ORACLE ERP产品的真正“面世”要比SAP晚约十年，ORACLE 是在1992年SAP推出其划时代的R/3产品之后，花了580万美金买了一套SAP在其公司内实施应用，在精研SAP产品的基础之上，以SAP为师，继承了SAP产品的设计精髓，然后对其原有的老产品进行了推倒重构，前后历时近4年（1993至1997年），才推出其可堪使用的ERP产品，且要到6年之后（2003年左右）11i版本的面世，才算真正拥有比较成熟的产品。（参考笔者在《ORACLE ERP 的前世今生》一文中描述）

     因此，从技术层面的相关因素来看，SAP的产品设计由于所处年代相对较早（上世纪80年代），有许多应用架构方面的设计，因为要考虑性能方面的限制（当时的硬件技术水平），只能采取相对比较保守的方式；

     而ORACLE的产品设计因为几乎晚了十年，摩尔定律的作用使得硬件技术水平已有很大提高，加之产品设计者对未来技术进步的预判比较乐观，故而可以在产品设计时，可以考虑采取相对更为激进的方式。

     例如，作为高端ERP产品重要标志的“系统参数体系设计”，SAP与ORACLE两者均有近万个可以根据业务需要配置的不同参数，以便对系统业务流程进行灵活更改，从而满足不同行业、不同企业、不同业务场景的实际需要。

     SAP的参数设计因为需要顾虑系统性能，故采取的是“将参数设置值先编译进用户的应用程序”的方式，应用程序直接运行、无需中断停顿。但“参数设置”这项工作本身“技术性”较强，对相关人员的要求比较高，管理比较死板、使用不够灵活。

   由于类似的系统基础性设计，设计方案一旦在最初阶段定下来，就如系统DNA，以后的产品发展过程中，即使明知有很大缺点，也只能是萧规曹随、无可奈何。因为修改类似系统的基础性设计，意味着要伤筋动骨、推倒重来，代价与风险均太大了。

     而ORACLE的参数设计则是将所有参数设置值放在数据库层面，长驻机器内存，应用程序运行过程中会根据需要中断停顿，先基于规则去取数、读数，再做判断然后继续运行。对“参数设置”这项工作本身的管理比较灵活、使用比较方便。

     由于类似的系统基础性设计，从原理上来讲就比较耗系统资源，故而实际使用需要得到硬件资源方面的配合。上世纪九十年中期，ORACLE ERP刚正式推出不久，客户投诉与不满曾经很厉害，华为当时的使用也遇到很多性能等方面的严重问题（一度到了考虑要换马），一直到六年之后11i版本的面世，情况才有根本性的改善。

    从技术原理上来说，相同硬件技术条件下，ORACLE设计方式的性能肯定是不及SAP的，但胜在实际使用要远比SAP方便灵活，因为无需先进行程序编译，用户可以随时根据需要进行结构化的参数设置值修改，但前提条件是机器硬件性能必须超过某个阈值。

    通常情况下，个人对系统性能的主观感受为，系统响应时间不超过2-3秒均可以接受，而这一点，考虑到当前的即便普通电脑内存也已达4G-16G或更多，比之二十多年前的上世纪末普通电脑最多才几十M内存，过去存在的某些系统性能问题，到现在实际早已完全不存在了。

    因此，业界也公认，ORACLE 产品的技术应用先进性、架构思想的前瞻性与灵活性方面要优于SAP，尽管业务流程与功能方面有些粗枝大叶，没有SAP做得那么的细腻完善。

    SAP与ORACLE 系统两者在设计与使用方面的综合比较，笔者认为，也可以用城市公共交通网络的建设方案选择，来做一个形象的类比，参考如下：

SAP的系统设计就好比一个以“公交线路网络”为主的大城市，有密密麻麻分布的“公交站点”，有数量众多、四通八达的公交线路（例如上海的公交车超过1500路）。

    对于任何一个出行的人来说，无论出行的起点与终点若何，你都可以找到离你的“出发地”最近的公交站上车，然后通过合理的（多次）线路换乘，以最短的路程、最快的时间到达离你的“目的地”最近的公交站下车。

     这种出行方式，对于已经在这个城市生活了较长时间、熟悉公交线路的人来说，显然不会有什么问题（类似于已经把SAP用得比较熟练了）；但对于初来乍到该城市人来说（类似于刚开始使用SAP的新手），就显得不那么友好了，可能需要较长的时间熟悉、适应，才能游刃有余。

ORACLE的系统设计就好比一个以“地铁线路网络”为主的大城市，地铁站点相比公交站点要少得多，线路数量与覆盖密度方面，地铁相比公交更是非常有限（例如上海仅有20条地铁线路）。

      对于任何一个出行的人来说，从进地铁站开始到出地铁站为止，中间或许也需要换乘不同的地铁线路，但因为地铁换乘一般都很简单，通常不会出现人们在公交站换乘时，面对N路车需选择判断的“换乘焦虑”。这一点对于初来乍到这个城市的人来说（类似刚开始使用ORACLE的新手），尤其显得友好。

     但是，选择地铁出行方式，你必须自己想办法解决如何从你的“出发地”到最近的“起始地铁站”、从“终点地铁站”到你的“目的地”。因为这“一头一尾”的两段路程可能并不近，你或许需要根据自己的实际情况，选择通过“步行、打车、骑车”等不同方式来完成这两段路程。

     ORACLE系统的企业实际使用也存在较多的类似问题，这也是实际系统应用实施时，需要较多的“二次开发”或增加“外挂系统”才能真正发挥出ORACLE 系统最大效益的原因。

     此外，还有一点需要着重指出的是，2022年SAP ERP的年营收约325亿美元，ORACLE ERP的年营收约200亿美元。而ORACLE ERP是有史以来，唯一个通过学习研究SAP、青出于蓝，仅用了十年时间（1993-2003），就实现产品从“低端”到“高端”，从当时的一大堆ERP厂商中脱颖而出、逆袭成功的佼佼者。（国内也曾有企业声称学的是SAP，但画虎不成反类犬，迄今为止，还没有真正能取得成功的。）

      过去二十年来（2003-2023），ORACLE与SAP双峰壁立，世界第二的江湖地位一直非常稳固，且把后续的追赶者远远抛在身后。当前所谓的世界第三ERP厂商（SAGE/INFOR/MICROSOFT是谁有争议）的年营收仅30-50亿美元左右，与前两名比还不在一个数量级。（注意，Salesforce并非传统ERP厂商，不好类比）

      综上所述，笔者私以为，高端泛ERP产品研发的“逆向工程”，以复制ORACLE为主、参考SAP为辅，外加新时代条件下的“创新超越”，应该是中国厂商有关产品研发策略的最佳选择。

     当然，未来要走出一条更适合中国国情的MetaERP（泛ERP）发展道路，除了要践行笔者此前文章（华为MetaERP的战略三要素、云系统测试，以及有关产品研发的“逆向工程”与“创新超越”的探索问题）中所提出的“Meta战略三要素”之外，我们还可能需要探索并走出一条更符合我国的经济发展历史阶段，不同于SAP/ORACLE“躺着就能挣大钱”的盈利模式（尽管令人艳羡），且有利于从整体上促进我国企业数字化转型升级的MetaERP市场商业化之路。