ORACLE ERP 的前世今生

残羽C0 10-21 3006

前言：

今天小伙伴们对“oracle erp使用手册”大概比较讲究，兄弟们都需要了解一些“oracle erp使用手册”的相关知识。那么小编同时在网上网罗了一些对于“oracle erp使用手册””的相关资讯，希望小伙伴们能喜欢，你们一起来学习一下吧！

一个伟大的公司必有一个伟大的产品。如果说数据库是ORACLE在上世纪最后二十年赖以起家并奠定江湖地位的旗舰产品，那么，企业应用产品（或曰ERP）则毫无疑问是ORACLE在本世纪初的这近十年，征战疆场、所向披靡的核心武器。有关ORACLE数据库的传奇故事，相信对于大多数程序员或IT技术人员来说，已经是耳熟能详、了然于心，但对于ORACLE的ERP产品的来源与发展历史，许多人则似乎不甚了了，甚至于连ORACLE自己对于自家ERP产品的历史渊源也是语焉不详，有些遮遮掩掩。2007年国内有一位SAP顾问在网上与ORACLE的拥趸者争吵时就曾说过：“十年前哪里有人听说过Oracle有什么ERP产品，就是三年前如果你去问做ERP的，大家只知道SAP R/3，Oracle是数据库”。

客观来看，这位仁兄所言也并非完全是意气用事，因为十多年前，当时人们还习惯称之为MRP II 的ORACLE ERP确实有些默默无闻（至少在国内是这样），以至于2000年8月15日，联想集团正式对外自豪地宣布：由联想、SAP和德勤合作的联想集团ERP项目实施成功。有媒体欢呼：联想集团ERP项目的成功，不但创造了中国IT行业在ERP项目中的“第一”，也创造了一个新的Legend (传奇〉。可实际情况却是，早在1996年华为就已经开始了ORACLE R10.6的全业务应用（13个核心业务模块，仅HR模块策略性地选择了SAP）。到2000年正当媒体及业界上下正热议柳传志的名言“上ERP是找死，不上ERP是等死”的时候，华为却正静悄悄地部署着由ORACLE R10.7升级到R11。

毋庸置疑，倒退十多年，今日与SAP并称并被业界誉为“一个是奔驰、一个是宝马”的ORACLE ERP，在当时与SAP相比，确实还只能算是一个“丑小鸭”，以至于当年SAP在华为项目上（因为更贵）输给ORACLE之后，只是有些“不屑”地表示“遗憾”。当年的华为，与联想相比还只是个不太起眼的角色，SAP的“遗憾”也不能完全说是故作轻松，多少也带有点“等着瞧好看”的意思。只是十年之后的2006年，当在IT业界已是声名显赫、如日中天的华为以“重金”礼送SAP出境，将HR模块也切换到ORACLE的时候，SAP的销售人员除了大骂“前辈”的愚蠢，就怎么也“轻松”不起来了。

过去十多年来，那些曾在ERP业界风光一时、有着不俗业绩的企业，诸如s、Baan、Peoplesoft、Siebel、i2等等，都已经一个个倒下或象流星一般消失。后加入的重量级玩家如微软，十年耕耘ERP，也是收获甚微。为何只有ORACLE ERP 最终脱颖而出，能够与SAP比肩如双峰壁立？是历史的必然，还是偶然？或许从回顾、探讨ORACLE ERP的发展历史能给我们一些有益的启发。

一、1993年之前：漠不关心的旁观者

讲到ERP的历史就不能不讲到SAP，因为在上个世纪末的最后十年，业界几乎公认SAP是ERP软件的鼻祖，SAP的R/3几乎就是ERP的代名词。而讲到SAP的历史（也正如讲到Microsoft、Oracle 的历史），就不能不提到一个人所共知的名字“IBM”。IBM与当今世界最大的三家“独立软件供应商ISV”（第一Microsoft、第二Oracle、第三SAP）的关系可说是“源远流长”。不仅如此，今天的所谓“独立软件供应商ISV”之所以能有立足之地并发展壮大，也与40年前IBM的一纸声明大有关系。

四十多年前的上世纪六十年代，是IBM大型计算机所主导的时代，当时所谓的应用软件巿场，例如企业用的财务管理软件，才刚在起歩阶段。虽然IBM销售出大型计算机时会“附赠”这种软件，但通常研发应用软件还主要是客户自己的工作。IBM起初并没有向计算机买主另外收取软件费用，附赠软件纯粹是为了促销整个计算机系统。IBM此举使得那些希望靠为企业的大型计算机编写软件生存的小公司处境艰难，于是几家小公司联合起来准备向美国司法部提起“反托拉斯”诉讼。面对来自美国司法部的压力以及内部软件开发成本的不断增加，IBM于1969年6月23日终于做出了一个决定性的声明：将停止发送免费随机软件，硬件和软件开始分别定价。这一天或许可称为“世界软件业的诞辰日”，从此，一个个未来的软件巨人将得以出生、壮大，并开始主导我们这个世界。

正是在这一背景之下，1972年5位从IBM西德分公司辞职的德国人开始了创业之旅，他们成立了一家名为SAP的公司（全称为“Systems，Applications and

Products in Data Processing”），公司的远景目标是：开发用于实时业务处理的标准应用软件。1973年，SAP推出第一个标准软件产品：财务会计软件RF，它是公司继续幵发其它软件组件的基础，该软件后来成为著名的R/1系统。“R”

代表实时处理（Real time），主要针对当时大型机非交互式程序运行方式而言。前两年，有国内ERP厂商玩起“实时企业”的概念，不知道其“灵感”的来源是否正出于此！

1981年，已有80多位员工、100多家客户的SAP推出其第二代标准产品： R/2系统。此后经SAP对R/2系统的多年发展与完善，截至1986年，即使以今天的眼光从企业的核心业务应用角度来衡量，R/2也已经是一个相当完整的“企业级”应用系统，它包括了RF （财务管理系统）、RK（管理会计系统）、RK-P（生产计划系统）、RM（工厂维护管理系统）、RM-Mat（物料管理系统）、RM-PPS（生产管理系统）、RM-QSS（品质管理系统〉、RP（人力资源管理系统）、RV（销售、配货、出货管理系统）。R/2系统在鼎盛时期的客户约为2200家。1988年，SAP的股票开始在德国上市。直至1992年SAP推出划时代的第三代产品“R/3系统”之前，SAP的年收入已达8.3亿马克（按当时的汇率约为3.5亿美金）。

上世纪70-80年代，是企业应用产品（即今天泛称的ERP）英雄辈出的时代，其中有不少公司在上世纪末的90年代，均在中国国内留下过身影，其中有些产品目前在国内还有一定市场、发展得不错，有些迄今虽以寂寞无闻，但可能还在某些企业里工作。它们是：

Sage（赛捷），一家成立于1979年的美国公司，目前自称是仅次于SAP、ORACLE的世界第三大ERP供应商，2008年的营收达21亿美金。（另一家成立于2002年的名为Infor ，属于私人基金性质的投资公司，在过去几年网罗收购了一班ERP的“昨日黄花”后，年营收也高达23亿美金，也自称自己是世界第三大ERP供应商）。

Peoplesoft（仁科），1987年成立的一家美国公司，曾被誉为世界第二大ERP供应商，年营收最高曾达28亿美金。2004年底以103亿美金的身价“下嫁”ORACLE。

s（爱德华兹），1977年成立的一家美国公司，上世纪80年代中期，曾被公认为是应用软件的领头羊，年营收曾高达10亿美金，2003年以15亿美金身价被Peoplesoft 收购，次年底随Peoplesoft一起被oracle 纳入囊中。

Baan（博安），1978年成立的一家荷兰公司，年营收曾达6亿美金，在本世纪初的互联网泡沫破裂后，任人买卖、几经转手，于2008年随SSA被私人基金投资公司Infor收购，成为其一个产品品牌。

SSA全球科技，1981年成立的一家美国公司，年营收曾达3亿美金，2003年曾收购BaaN，2008年被私人基金投资公司Infor收购，成为其一个产品品牌。

Fourshift（四班或思博），1985年成立的一家美国公司，年营收最高也未曾超过1亿美金。该ERP产品国人对之有些特殊感情，因为其全球2000多家制造业客户中，有近20%的400多家客户是中国企业。可惜其在2001年遇人不淑，以4000万美金收购其的新东家，一家英国公司AremisSoft的老板竟然是个骗子，涉嫌财务造假欺诈。Fourshift（四班）随后改名Softbrands（思博）独立运营，历经艰难，最终于2009年5月以每股不足1美金的低价，贱卖给了私人基金投资公司Infor收购，成为其一个产品品牌。

值得一提的是，1988年一家名为“用友”的中国本土企业应用软件公司成立，与大多数国外应用软件公司相似，都是从财务软件开始做起。2001年用友在上海交易所上市，募集资金8亿元人民币。用友上市当日，受到了国内股民的热烈追捧，每股价突破100元。截至2008年，用友年营收约2.5亿美金。

那么，在整个上世纪七、八十年代，正当SAP在应用软件市场如鱼得水，其它诸多公司亦风生水起的时候，ORACLE在干什么呢？这家于1977年创建的软件公司，于1986年在NASDAQ上市，1987年营收已达1亿美金，当然，主要是数据库产品的收入，因为oracle于1987年才正式建立起一个仅7个人的应用软件开发部门。可笑的是，这个应用软件部门最初的任务，一半是为自己的财务部门开发应用软件，一半是在销售数据库产品时，应客户的要求顺便将自家使用的财务软件拿出来卖。

数据库是ORACLE的业务基础，是它存在的最初理由，而ORACLE应用软件业务则几乎是在偶然间发展起来的。ORACLE最初应用软件（财务会计软件）的业务开展，与当时的两位公司高管有关，一个是ORACLE欧洲地区负责人杰夫·斯夸尔，一个是公司的首席财务官（CFO）杰夫·沃克。上世纪80年代中期，ORACLE公司的管理运作还处在一个极其松散的状态，出于工作需要以及

个人兴趣，远在英国的杰夫·斯夸尔决定搞一个财务会计软件。他不仅在自己的公司内部使用这种软件，而且还将它销售给国际客户。与此同时，在美国总部的ORACLE老板拉里·埃里森也找来了曾自己建立过财务软件公司的杰夫·沃克，来负责ORACLE的应用软件开发，但很快埃里森又任命杰夫· 沃克兼任公司的首席财务官，理由仅仅是“搞财务软件开发必然也懂财务管理”。埃里森这一奇怪、轻率的任命，为几年之后（1990年）的公司销售财务管理失控、公司濒临崩溃埋下了隐患。埃里森后来不得不承认“任命杰夫·沃克为CFO是一个错误，不幸的是，我当时不明白”。

按照今天ORACLE官方资料的说法：ORACLE于1987年收购了一个名为“TCI”的项目（project）管理软件公司，当年首先发布了基于UNIX的总账GL模块与采购PO模块，并在以后从无到有开发了其它所有应用软件。1988年，ORACLE开发出固定资产FA模块与应付帐款AP模块。

但实际情况并非如ORACLE官方说的那样“轻描淡写”。在斯夸尔与沃克这两个“杰夫”的分别努力下，ORACLE有了两套不同的开发工具和两套不同的会计软件：一套在美国，一套在海外。两个开发团队之间的关系非常糟糕，在至少两年时间里，双方各干各的、相互争斗，以决出谁的财务会计系统能够胜出。埃里森最后介入，让他们都重写产品，以达到公司要求。最终埃里森于1989年选中了杰夫·沃克的产品，而另一个“杰夫”的产品则被束之高阁，后来卖给了第三方。

1989年，ORACLE首次发布制造应用，库存管理（INV）是其第一个模块。注意：INV模块以后将在ORACLE ERP产品的应用架构中，扮演着极其重要的角色。ORALCE早期的产品规划设计人员或许是于“无意识”当中，为应用产品以后的发展、壮大奠定了一个重要的基石。如同在“幼苗”阶段，物种“基因”将决定未来能否长成“参天大树”一样，ERP 产品在早期规划设计阶段有关业务流程的设计理念与模式选择，对于产品未来发展前景将产生重大、深远的影响。须知“小草”是怎么浇水也长不大的。

1990年，ORACLE发布应用产品R7、R8，主要还是C/S架构的财务会计软件，与SAP对“R”的“实时”定义不同，这里的“R”仅是“Release（版本）”的意思，ORACLE应用产品后来一直沿用了这一叫法。

在1990-1991年期间，由于公司对销售财务管理的混乱，作为上市公司的财务报表反复被修改，收入数字一再被调减，亏损数字一再被扩大。ORACLE陷入了一场空前的灾难，股价暴跌，股民提起诉讼，埃里森被要求下台。作为“替罪羊”，曾经搞过财务会计软件的杰夫·斯夸尔，一直负责应用软件开发兼CFO的杰夫·沃克，先后都被埃里森逐出公司。

不过，1992年中进入公司并承担起挽救公司角色的前ORACLE公司总裁雷·莱恩，对于已经离开公司的杰夫·沃克在应用软件开发方面的表现，则有相当高的评价：“沃克才华横溢，他将一些非常具有创意的东西注入了应用软件当中”。雷·莱恩的话很容易让人联想到ORACLE 产品中独特的“弹性域”技术，弹性域与其说是一种技术，不如说是一种“方法论”，它最早使用在财务领域的会计科目中，随后逐步发展，成为今日应用产品最重要的基础元素之一。

1992年，ORACLE发布应用产品R9，这是一个包含财务会计、生产制造、人力资源的应用软件包。这一年ORACLE已经基本摆脱危机困境，年营收达到12亿美金，当然，数据库仍是主要收入来源。其时，在应用软件方面，ORACLE大约已经拥有了1500个客户，但主要是一些中小型的美国公司，它们使用ORACLE的应用软件包来管理自身财务、人力资源以及生产制造方面的一些业务。

尽管埃里森较早就意识到了ORACLE应当进入应用软件业务，但事实上当时及其后很多年，他对应用软件业务一直兴趣不大，他认为相对于数据库、开发工具，应用软件太过平庸，只是管理账目、工资单之类的无聊东西。埃里森后来曾坦言：“我从未关注过应用软件领域的事情，可以说我是个对此漠不关心的旁观者”。有这样一位主要对技术感兴趣，对于属于管理范畴的应用软件甚至有些不屑一顾的CEO，或许已经预示着ORACLE应用软件产品今后的发展道路不会一帆风顺，将命运多蹇、充满坎坷。

二、1993年至2000年：奋起直追，艰难突围

1988年，SAP的创业者们做出了一个后来被称为“天才”的决定：开发基于C/S架构的R/3系统。4年之后的1992年7月，R/3问世并很快风靡欧洲、席卷美国。在随后的短短几年内，R/3取得了空前的成功，那些世界500强的企业

巨头，包括在IT业界声名显赫的大公司诸如IBM、惠普、微软、苹果、英特尔等等，纷纷上线SAP R/3。

如今的SAP在其市场宣传中，总是喜欢刻意强调“SAP 是世界500强中80%公司的选择，是财富500强背后的管理大师”。其实，这也没有什么特别的，因为在上世纪最后十年，信息化革命浪潮滚滚而来，各大公司纷纷进行企业信息化建设的时候，SAP几乎就是唯一的、可能的选择。用SAP的CEO普拉特纳的话说就是：“我们把同行吓得3年动弹不得，放眼望去，市场上还看不见对手”。

SAP

当时可谓占尽天时、地利、人和，并奠定了到如今都一直难以撼动的市场老大地位。高端ERP软件的“粘着性”很强，与企业之间用“夫妻关系”来形容毫不为过。如今的世界500强圈子里，除了极少数近10多年才冒出来的“暴发户”，ORACLE要想去那些“老贵族”家里插一脚、当“小三”，谈何容易，何况SAP也根本就不是“糟糠”。

对于ORACLE的应用产品而言，1992年R/3的问世无异于一场灾难。前ORACLE总裁雷·莱恩曾说“R/3改变了整个竞争格局，我们好像没穿裤子被逮到一样。与SAP相比，我们显得微不足道，我们与SAP之间根本无竞争可言，因为我们几乎从未有与他们一较短长的局面”。

知耻而后勇。于是ORACLE管理层做出了一个重大的决定：从1993到1997年，争取用4年的时差奋力追赶SAP，集中精力投入到打造特色应用软件产品中，以此与SAP展开竞争。为了能够尽快缩短与SAP的差距，ORACLE购买并使用了SAP的产品，一向倨傲不逊，喜欢口出狂言的ORACLE老板拉里·埃里森，甚至也谦虚地承认SAP是自己的老师。

1993年，ORACLE 决定将过去所有的应用产品重写以适应于C/S架构。当年，发布应用产品 R10，包括财务、制造与人力资源三大部分。财务部分包括：总账GL、应付AP、应收AR、采购PO、订单OE、库存INV、固定资产FA、项目会计（project account）；制造部分包括：工程ENG、清单BOM、物料计划MRP、主计划MPS、能力计划CAP、在制品WIP；人力资源部分：人事管理Employee、工资册Payroll。尽管R10实际尚无力与SAP竞争，但从企业核心业务应用角度来看，产品的规划设计至少看起来已经相当完整，这为产品的市场推广及以后的完善与提高打下了坚实基础。

1993年，ORACLE曾经的市场销售“状元”，一度曾负责ORALCE内部所使用的“电话销售管理系统”开发并在公司危难时刻离开的汤姆·西贝尔，创建“Siebel 系统公司”，主推CRM产品（西贝尔看来一直是对自己在ORACLE曾搞过的产品念念不忘）。公司迅速壮大，后来成为ORACLE的一个强劲对手，年营收曾高达16亿美金，并最终在2005年被ORACLE收购。

另外，值得一提的是，1993年另外一家中国本土企业应用软件公司“金蝶”成立，也是从财务软件开始做起。截至2008年，其年营收约1.25亿美金。

上世纪90年代中期，与在应用软件市场相形见绌不同的是，ORACLE在数据库市场正高歌猛进，埃里森发誓要将其竞争对手Sybase、Informix赶尽杀绝。SAP R/3的火爆间接地也促进了ORACLE数据库的销售，两家公司的合作关系一度还是相当的融洽。对于ORACLE的应用软件产品，SAP表现得不以为然、不屑一顾。虽然也受到来自IBM数据库DB2的有力竞争，但ORACLE数据库很快就获得了王者地位，在高端数据库市场几乎占有50%的份额，这为ORACLE带来了滚滚财源。

1995年，ORACLE应用产品R10SC（smart client application）发布。1996年，ORACLE开始实施其应用产品的JAVA战略，30多个模块全部实现JAVA使能。1997年，ORACLE应用产品R10.7NCA 套件（network change architecture）发布，此时已经大约包含35个应用模块，涉及财务、人力资源、制造、供应链等所有企业核心业务范畴。

与大多数应用软件开发公司一样，ORACLE也是一边开发、完善其产品，一边在市场上推广、销售。此时的SAP已逐渐感受到来自ORACLE的竞争威胁，1996年SAP在中国华为项目上输给ORACLE就是案例之一，其后，又在美的、中兴等项目上相继失利于ORACLE。SAP此时开始公开与ORACLE翻脸交恶，并宣布在其ERP销售中将主要向客户推荐IBM的DB2数据库产品。

边开发边销售的产品战略，虽有尽早抢占市场先机、增加销售收入，并依靠客户应用发现产品漏洞、促进产品完善的好处，但其弊端也是显而易见的。产品的功能与质量有欠缺、客户使用体验差、投诉抱怨多、市场口碑不佳等等，这些问题如果掌握、处理不好，甚至可能会毁掉产品自身的前途。在这方面，ORACLE也不能例外。更为糟糕的是，由应

用产品所引发的问题，逐步演变成了ORACLE公司内部高层之间的一场复杂的政治斗争。

1994年，埃里森指派年轻的罗恩·沃尔负责应用软件开发，但公司其他高层如负责市场销售的雷·莱恩，负责咨询服务的罗伯特·肖，以及董事会的一些人反对埃里森的这一决定，理由是他们认为罗恩·沃尔不懂应用软件。而不太善于团队合作、有些书生意气的罗恩·沃尔，则仗着有埃里森的撑腰，几年来又一直与运营团队针锋相对。

从市场销售、咨询实施的角度考虑，运营团队希望在自家产品不够完善的情况下，要么开发部门优先提供能够集成第三方公司优秀产品的接口软件（即所谓“最佳配置方案”），要么开发部门能对自家产品开发、完善的进度期限能给出尽可能早的明确承诺，以帮助消除客户怨气，为市场灭火。而从产品开发管理角度考虑，由于ERP产品体系十分庞大而复杂，罗恩·沃尔坚决不愿意就应用产品的开发进度与完成期限作出明确承诺，也不愿意多花费宝贵的开发资源为第三方产品作嫁衣裳。于是，开发团队与运营团队之间的矛盾、争吵就不可避免、越演越烈。

有意思的是，随着公司经营状况的大大改善，本来就对应用产品开发不甚感兴趣，此时正热衷于开飞机、玩帆船的埃里森，对开发团队采取了明显“袒护”的态度。在他看来，开发人员的职责就是提供产品，销售人员的职责就是卖出产品。“不要回来告诉我，你卖不出去。如果客户不买，那么他们就是傻瓜”。面对运营团队的责难与不满，埃里森甚而至于在一次管理层会议上掏出自己的银行存折翻了翻，然后对在座的人说“我按照自己的方式来处理这件事，我有足够的Money，我做得肯定没错”。

历史的发展轨迹常常是诡异的，胜利者或许是不该受责备的。以今天的眼光回头来看，埃里森的一意孤行，对于ORACLE ERP产品的未来发展，又很难说是“负面”的。有一位ORACLE的长期客户、后来成为咨询公司负责人的马克·法纳姆就坚持认为：罗恩·沃尔不对应用软件开发限定日期的做法是正确的。应用软件非常复杂，在一个地方做改动就可能影响另一功能。销售人员想要产品有更多功能、能够及时出来，那样他们就可以有更多收入。但对于应用软件用户来说，晚半年拿到产品，拿到能正常运转、更稳定的产品，也许更有利，即使这意味着有些功能暂时不到位、产品交付错过日期。

但客户由于产品功能、质量方面所遭受的痛苦与挫败感也是实实在在的。以国内最早的ORACLE ERP 用户“华为”为例，最初使用的头两年，情况是是相当可怖的。莫名其妙的错误、无缘无故的宕机、没完没了的补丁，以及用户忽然间进不去、出不来等等一系列问题，导致公司上下怨声载道，IT部门承受着沉重的压力，以至于最终导致负责IT工程选型与实施的一位创业元老、公司副总裁，在被老板骂得狗血喷头后怏怏地黯然离去。

1997年底，围绕应用软件业务在ORACLE公司高层之间所引发的政治斗争已经到了“白日化”的地步，鉴于应用软件在市场上的糟糕表现，董事会有人跳出来公开建议：ORACLE要么收购一家竞争对手以壮大应用软件业务，要么干脆将这方面业务全部卖掉。这当然引起了来自开发团队的无比愤怒。以公司总裁雷·莱恩为首的运营团队则公开指责罗恩·沃尔无能，在大庭广众之下说应用软件根本是个败笔，并向埃里森“逼宫”：要么让罗恩·沃尔出局，另换他人，要么我们就辞职。

斗争的最后结果以埃里森将公司总裁雷·莱恩及其他反对者通通逐出公司为收场。埃里森从此开始关心并亲自掌管起应用软件的开发工作，并敏锐地提出了“应用产品转向B/S架构、全面实现互联网应用”的创新设想。应当说，以罗恩·沃尔为首的开发团队并没有辜负老板的“知遇之恩”，产品开发与完善进度明显加快，产品的市场表现开始逐步变得亮丽。多年以后，对于罗恩·沃尔曾经受到的攻击与屈辱，埃里森还在替他打抱不平：“雷称罗恩为笑料，这不仅与事实不符，而且说的是外行话，有失公允。罗恩建造的应用软件管理着全球近1.5万家公司，仅次于SAP”。

1998年，ORACLE应用产品R11 套件面世。到98年4月，已经有大约1300个客户。到98年10月，ORACLE 发布CRM3.0，并实现ERP与CRM产品的高度集成。也是在这年，ORACLE ERP 的在线商务应用（business On line）与移动商务应用（Mobile APPS）得以成功实现。这两款应用亦即多年后国内有人热炒的ASP、移动ERP。

1999年4月，ORACLE 开始对于其“业界第一款完全基于互联网应用的 11i

电子商务套件”进行预发布，面对电子商务潮流，ORACLE开始下手把自己塑造成新时代的领袖。同年11月，ORACLE经营的B2B电子交易市场ORACLE

EXCHANGE 正式开张，继赢得三大汽车商（福特、通用、克莱斯勒）的网上交易市场Covisint 的大单之后，ORACLE又赢得不少虚拟市场的生意。

需要顺便一提的是，也是在1999年末，IBM公司决定将企业应用软件部门分拆出去，全面退出。按照郭士纳在其自传中的说法：IBM在先前的12年中，用于应用软件开发和并购的投资是200亿美金，但利润回报却是大约负增长70%。IBM一度曾考虑并购SAP。看来，应用软件这碗饭不是那么好吃的，也不是财大气粗就能搞定的，连IBM这个蓝色巨人最后都选择了知难而退。而在今天，恐怕已经很少有人知道IBM曾经搞过什么应用软件（据说主要是有关生产制造方面的）。

尽管在上世纪90年代后期，ORACLE付出极大努力在尽力追赶SAP，但从ERP市场的总体份额来看，仍不足SAP的三分之一。埃里森为其对ERP市场曾经的漠视付出了代价。2001年，埃里森在一次公开讲演中曾说道“我几乎十年时间没有关注应用软件。我非常幸福地看到数据库的起步与飞翔。后来我认识到，我从未见过我们的应用软件。作为首席执行官而没有见过自己的某种产品，这令我很惊讶。对于没有尽早以应用软件为核心，我感到遗憾吗？绝对遗憾。要是早在这方面多下功夫就好了，我犯了许多错误”。

不过，平心而论，ORACLE能在短短的6年时间里，打败诸多竞争对手，一跃而居于应用软件世界第二的位置，尽管与SAP仍有不小差距，但这已经是个不小的成绩。难怪那位作为ORACLE应用软件创始人的杰夫·沃克，在被迫离开公司多年之后重提旧事，仍抑制不住地感到骄傲与自得：“仅在6年时间里，ORACLE就从一个不入流的角色发展成应用软件行业的领头羊，尽管SAP有R/3，但在应用软件市场上，他们并没有达到高不可及的程度，他们并没有真正做到象ORACLE那样成功”。或许可以说，ORACLE 应用软件产品后来的成功，杰夫·沃克在最初的产品规划设计阶段，就已经为之植入了最重要的成功“基因”，昔日他植下的“幼苗”已长成大树，他有理由为之骄傲。

三、2000年-2009年：引领FS，征购无极限

2000年5月，历经3年潜心研发，ORACLE 11i 电子商务套件（EBS）正式发布。该产品有两大宣传卖点：一是完全的B/S架构，二是互联网应用。关于所

谓B/S架构，今天已几乎成为行业技术标准，没什么好说的。而所谓“互联网应用”，即ORACLE刻意强调的那个“i”（internet的意思），则很大部分是为了迎合当时的互联网泡沫泛滥的时代潮流。

11i

中的那个“i”的影响之深、之广，以至于今天的ORACLE R12 出来后，有人还习惯性地将它称之为“12i”。但实际上从企业实际业务的核心应用角度来讲，这个“i”（互联网应用）在当时象征意义大于实际意义。在今天企业互联网应用已逐步深入，远非昔日可比的时候，R12的出台却抛弃了这个“i”，这或许可以说明，ORACLE会玩概念，是玩概念的高手，但ORACLE从未将“玩概念”当成自家产品的“立身之本”。

2001年，财富100家中已经有65家在运行11i EBS，ORACLE抢得了市场先机。相对而言，面对互联网所带来的巨大改变，SAP则显得有些反应迟钝，业界评论家们甚至认为SAP落后了。尽管SAP在1999年10月就开始推出其新一代基于网络的企业套件，但多年之后，SAP不得不无奈地承认：许多人弄不明白是什么东西。

伴随着11i的成功，客户群的扩大，来自客户的抱怨与不满也在增多。应用软件的早期版本不够成熟，总是存在这样那样的问题，这本来是一个业界所普遍存在的正常现象，但所谓“期望越高，失望越大”，客户开始抱怨“产品并没有埃里森吹嘘的那么好”。加之埃里森不介意得罪同行、得罪媒体、得罪合作伙伴，甚至得罪客户的独特的行事风格，也给自己招来了许多麻烦。

过去若干年来，争议诋毁、嫉妒中伤、幸灾乐祸几乎与ORACLE的发展如影随形。咨询机构AMR调查公司在自己的报告中就曾宣称“用最好听的词汇描述，ORACLE应用软件的历史也是充满波折。这家公司有一个传统：将软件卖给早期的买家，依靠它们洒下的鲜血、汗水、泪水去填补产品的漏洞，使之变得可靠”。然而，尽管如此，有趣的是，大多数客户还是相信ORACLE能最终解决存在的问题，虽然抱怨不满、大声抗议，但却一次又一次地愿意给予ORACLE机会。这或许从另一个侧面反映了ORACLE ERP产品所具有的强大生命力。

2002年5月，软件巨人微软公司在继一年多前以11亿美金收购一家美国本土中型财务软件公司后，又以13亿美金收购欧洲小型企业应用软件供应商Navision，希图在据说整体规模有千亿美金之巨的企业应用软件市场分一杯羹。

有媒体甚至报道说“微软收购欧洲ERP公司目标直指SAP”。Navision目前在国内有一定市场，据说曾让用友、金蝶十分不安。该产品小巧玲珑但五脏俱全，居然不用install就可以直接使用（感趣者可以找来试试）。但要用这样一个类似“玩具”一般的产品挑战SAP/ORACLE，则恐怕是媒体的捕风捉影、夸大其词。

2003年，ORACLE推出EBS的特别版（special edition），仅包含FI、INV、PO、OM，产品形态与策略和SAP的A1类似。也就在这一年，ORACLE在与Peoplesoft争抢JDE的过程中，演出了一场“螳螂捕蝉，黄雀在后”的好戏，最终在2004年以103亿美金的代价将Peoplesoft和JDE一起纳入囊中。至此，ORACLE与SAP在ERP市场的整体份额差距进一步缩小，因为Peoplesoft与JDE当时位列世界第三、第四。尽管当时有很多人怀疑ORACLE会消化不良、自食其果，但时间已经表明，ORACLE笑到了最后。

2004年，ORACLE 推出On Demand Business服务，该项业务实际上也就是三年之后忽然在国内变得异常火爆的所谓SaaS。近年来，SaaS即“软件即服务”的概念在国内被炒到了近乎“神话”的地步，一时间国内ERP厂商们争先恐后，仿佛它就是“救星”，真不知道这是福还是祸。

2005年，ORACLE以58.5亿美金的代价并购Sieble。Sieble最著名的产品是CRM，该产品追根究源，可以追溯到ORACLE早年在其内部使用的一个“电话销售管理系统”。叶落归根，Sieble的历史仿佛转了一个圈，又回到了起点。

2006年，ORACLE 发布“应用无极限”的产品战略，发誓要将收购来的一堆产品（JDE/Peoplesoft/Sieble等）与自家产品“熔合”到一起。姑妄言之，姑妄信之。对于过去使用这些产品或依靠这些产品谋生的公司与个人来说，似乎还是应当未雨绸缪，早做准备。

2007年，ORACLE正式发布EBS R12。此时的EBS已经包含有高度集成的300多个模块，几乎覆盖了制造业、商业、金融、服务、政府、公用事业等等各行各业的全部应用。过去曾看到ORACLE的一个说法：R12将是EBS的最后一个版本。不知道ORACLR葫芦里卖的是什么药？同年，ORACLE以33亿美金的代价收购知名的绩效管理软件Hyperion，以近5亿美金代价收购知名的产品生命周期管理软件Agile。

2008年，ORACLE 提供Sieble CRM On Demand 服务。同年，ORACLE以85亿美金的代价收购中间件厂商BEA。

2009年，ORACLE 宣布提供Sourcing on demand 的合作伙伴计划，以自己的独特方式再次介入正热火朝天的SAAS市场（但笔者看来，此举似乎有点搅局的意味）。随后，ORACLE宣布以74亿美金收购SUN，业界再次被震撼。曾有个一问一答的笑话。问：上帝与埃里森有何不同？答：上帝不认为他是埃里森。如果ORACLE收购SUN成功，从操作系统、数据库到中间件、应用软件，从底层到上层，从硬件到软件，ORACLE全包，埃里森一统江湖，看来真要成上帝了！

因为埃里森被看作是收购狂人，于是有不少人似乎认为ORACLE的应用产品之所以强大，是靠收购得来的。国内有些ERP厂商也想效仿、走捷径。但实际上这其实是一种误解。从产品规划设计、企业实际应用角度来看，收购只可能锦上添花，不可能是雪中送炭！然个中就里，涉及对产品应用架构的复杂分析，实非三言两语所能说清。

四、从SAP到ORACLE

截至2008年，ORACLE年营收为224亿美金，而SAP年营收为161亿美金。年人均创收ORACLE为26万美金，SAP则为31万美金。相比之下，国内的用友年营收2.5亿美金，人均创收仅3.6万美金，金蝶年营收1.25亿美金，人均创收仅3.1万美金，差距十分明显。

由于ORACLE的产品销售，应用产品与数据库是绑在一起的，从ORACLE的年报中根本看不出各自是多少。而ORACLE似乎也有意回避做明确的划分，因此，考虑到现如今应用产品（ERP）在ORACLE产品家族中的核心地位，大约以50%的比例来计量（110亿美金），应当还算靠谱。这样看来，就应用产品的市场份额而言，ORACLE大约是SAP的三分之二。SAP是无可争议的老大，ORACLE是无可争议的老二。两者合计占应用产品全球市场总体的份额，按某些调查机构的数据约为60%（35%+25%）。至于市场上林林种种的其它产品，则就是“余子纷纷不足数”了。

由于SAP/ORACLE的产品主要靠合作伙伴、咨询机构来实施服务，一般认为，围绕它们所衍生的市场价值链有三到五倍，因此，可以说这是一个由SAP/ORACLE所创造的千亿美金规模的大市场。而国内应用软件市场的总价值，按某些调查机构的数据，当前约为100亿人民币左右。发达国家企业信息化市场的饱和度近70%，而国内市场的饱和度不足20%，随着中国经济的快速发展，电子商务与企业信息化水平的提高，未来几年出现一个千亿人民币规模的大市场指日可待。这对于国内应用软件厂商们来说，无疑既是一个巨大的机会，也是一个艰巨的挑战。

那么，从ORACLE应用产品过往十几年迂回曲折又波澜壮阔的发展历程中，国内厂商能获得一些怎样的有益启发呢？概而言之，ORACLE 产品研发的经验有以下两个重要方面：

其一是产品开发策略的“目标明确”。以SAP为标杆、为榜样，承认差距，奋起直追，结合技术发展的最新成果，争取“青出于蓝而胜于蓝”。SAP一向喜欢标榜自己的产品“包含有丰富的管理思想，凝聚了各大成功企业宝贵的管理经验，有着30多年的深厚积累”。那么，以SAP为师，跟着SAP走，大方向总不会错的。

最近有人在谈到R12中的新东西“子分类帐”（Subledger）时，曾调侃说“能看到SAP的影子”。其实，如果对ORACLE与SAP的产品做一些比较深入的对比研究分析就会发现，尽管两个产品外表长相、操作习惯差别甚大，但其核心的业务流程、应用架构相似度还是很高的，许多地方不过是名词概念的的改头换面而已。反观国内不少厂商的产品，虽然也声称在学，但核心、本质的东西往往弄得南辕北辙。

其二是开发管理策略的“过程坚定”。这里的“坚定”，不是说要象埃里森那样固执到去骂别人是“傻瓜”。然而，一个设计精良、高度集成的ERP产品，是计算机技术与企业业务实践的完美结合，它是如此庞大而复杂，以致于它绝对不是一般的“无知”用户，在工厂走马观花的程序员，或者读过几本管理书籍的咨询实施人员就能轻易理解与掌握的。产品研发、实施、发展过程中，七嘴八舌、众说纷纭，甚至各执一词、矛盾冲突都是在所难免，面对内外交困的局面，如果没有“坚定”的意志坚持，最终必然是弄出一个“四不像”的大杂烩。

埃里森是天生的领袖、天才的企业家，但他绝不是一个优秀的企业管理者，这从他曾轻率地任命一个产品开发主管兼任上市公司的CFO就可见一斑。当然，埃里森也无意把自己打造成一个所谓的“企业管理专家”。与SAP自诩自己是“管理大师”不同，ORACLE则简单地把自己说成是一个“信息公司”（Information Company）。或许正是埃里森（还有罗恩·沃尔）在这方面有自知之明，在ORACLE的产品开发团队内部，有一个很小范围的由核心专家所组成的执行委员会。面对来自内部（销售、实施）、外部（客户、伙伴）的种种压力，埃里森以一种近乎“孩子气”的简单与固执，只相信并依赖他那个“核心小组”。为此，他不惜和那些高层反对者闹翻，并把他们一个个逐出公司。

网上的ERP论坛中常有“新人”问：SAP与ORACLE孰优孰劣，我该学哪一个？多年以来，关于SAP/ORACLE高下对比的“口水仗”就重来没有停止过。2004年，ORACLE自己曾发表一个白皮书：ORACLE与SAP对比——是什么使ORACLE脱颖而出？（有人干脆将之译成“为什么ORACLE比SAP强”），有兴趣者可以找来看看。其中有一句：“SAP的表格驱动的方法已经过时，并且很难掌握”，倒是很值得认真仔细研究。SAP是ERP的鼻祖，包括ORACLE在内，大家都在学它。但回顾过去十几年国内厂商的学习成绩，令人唏嘘，恐怕问题的根源正如ORACLE所说。

有一种说法：SAP求严求全，ORACLE求实求用，前者体现德国人的做事风格，后者体现美国人的做事风格。论者立场比较公允，切中肯綮。但是，国内另一种说法：SAP体现的是德国管理模式，ORACLE体现的是美国管理模式，国产ERP体现的是中国管理模式。则似乎就有误导之嫌了。

管理是什么？是科学与艺术的结合。“科学”属于自然属性范畴，“艺术”属于人文属性范畴。ERP所针对的对象、所要解决的问题，主要是企业管理中属于自然属性范畴的“科学”那部分。而科学无国界。一个能够同时为成千上万家企业所使用、高度集成的ERP产品必须同时考虑众多的“约束条件”，数学原理告诉我们：约束条件越多，可能的最优解越少。套用托尔斯泰的一句名言：成功的产品比比相似，不成功的产品各有其不幸。

纵观从SAP到ORACLE的历史风云，还应当指出的是：SAP早年曾将ORACLE的产品蔑视为中低端产品，而ORACLE董事会有人在花了50万美金

的调研后，也曾提出过“放弃高端，从中低端围堵SAP”的建议，但被埃里森断然否决。德国人的傲慢、美国人的坚持成就了今日ORACLE应用产品的市场地位。再翻翻其它公司或产品的历史，迄今似乎还没有谁能够实现由低端向高端“仰攻”而取得成功的先例。强大如微软也不能例外。这一点颇值得业内人士进一步做深入研究。

五、结束语

十年前，春风得意的拉里·埃里森面对满座高朋踌躇满志地宣示：“5年之后，世界应用软件市场的对手，将只剩下SAP和我们，或者，我们和SAP”。果然，随着那些风光一时的明星企业一个个倒下或被吞并，埃里森实现了自己的预言。由于高端管理软件产品“不惧盗版，甚至欢迎盗版”的特殊性，管理软件“一家独大”或“两强争霸”的局面，长远来看绝非市场之福、客户之福。想想前两年SAP/ORACLE突然相继单方面将年服务费率提高5个百分点时用户的无奈吧！

无论是从经济学的市场充分竞争原理还是从中国人固有的认识哲学角度来看，理论上，管理软件业界未来还有可能再出现一个世界级的巨头（但愿不是微软）。管理软件“三足鼎立”是市场的期望，也是我们的愿望，而其中“一足”能是国内本土企业则更是我们的梦想。

最近一段时间，国内业界有人耐不住寂寞，煽风点火，蓄意把SAP架在火上烤，一时间弄得乌烟瘴气。联想到前些时SAP有人说了句大实话“国内企业落后SAP二十年”所引发的轩然大波，实在是可悲可叹。回头再看看ORACLE，尽管口无遮拦的埃里森，一会是要开着战斗机去微软总部扔炸弹，一会又是要去踢IBM的屁股，但ORACLE至少在几年之前还是在表面上对SAP表现得很是尊敬。能让埃里森亲口承认自己是学生，就是明证。只不过是在最近几年，随着11i的成功，ORACLE觉得自己的产品已经足够强大，才公开喊出“OFF SAP”的口号。其实，面对国际巨头，承认自己的落后并不是什么丢人的事情，真不明白国内业界何以风气如此！

与印度人相比，我们是世界工厂，有着数量庞大的工业企业供软件产品做实践；与美国人相比，我们有质优价廉、数量丰沛且吃苦耐劳的软件开发人员可供驱使；与德国人相比，我们甚至可以嘲笑他们的ABAP技术过时、平台落后。我们的应用软件产业与那些国外公司相比，起步并不算晚，但二十年的时光悠悠过去，当中国的家电产业从

无到有，已能够与欧美日韩并驾齐驱，当中国的通信产业出身草根，正逼得那些百年老店、跨国巨头走投无路的时候，何以中国的应用软件产业还只能是在贫瘠的低端市场广种薄收、收获与付出不成比例？难道真的如有些人认为的那样，是因为国内企业的管理水平普遍偏低？这种说法和“我们造不出好车，是因为国内路况不好”一样，实在难以令人信服。看来，国内管理软件业界已经到了必须集体反思的时候。

二十年前，身影憔悴的任正非面对着一帮灰头土脸的部下喃喃梦呓：“二十年后，世界电信市场三分天下，华为必将有其一”。今天梦想成为现实，2008年华为以180多亿美金的营收，成为继爱立信、诺西（诺基亚、西门子合并后的公司）之后的世界电信三甲之一。

码字到这里，突然想起篇首“一个伟大的公司必有一个伟大的产品”这句话，第一次看到原是出自“何经华”，这位曾花了近10年时间在国内管理软件界转了一圈的台湾人刚刚涉足国内业界不久时的一篇讲演稿。当去年底何先生从国内业界二次转身、黯然离去的时候，有多少人是否还记得他这句现在已经说不清是包含“希望”还是“失望”的话：

一个伟大的公司必有一个伟大的产品！

ORACLE EBS 系统架构与应用实践

一、从ERP到EBS

从上世纪70年代晚期的物料需求计划MRP（Material Requirements Planning）到80年代的MRP II，再到90年代的企业资源计划ERP（Enterprise Resource

Planning），企业管理软件（或曰应用软件）已经走过了三十多年的历史。今天ERP事实上几乎已经成了“管理软件”的代名词，然而，在专业人士及有些专家学者眼中两者还是有本质区别的。

在国内，据说鼎盛时期注册的6000家软件公司中，有3000家宣称自己是做ERP的，截止目前，有人估计国内可能还剩下成规模或不成规模的大约1000家左右，而其它国家加起来的总数也不过几百家。有网友曾调侃说：SAP/ORACLE被气得只哭，你们都叫ERP了，那我该叫啥呢？有国内ERP第一人之称的陈启申老师前两年曾撰文呼吁：应当正本清源回到Gartner最初的关于ERP的定义上来，进销存就是进销存，财务软件就是财务软件，一个连基本的生产制造都没有的东西怎么能称为ERP呢？然而，更狠的还有：ERP已经被中国人终结，现在是ERP

II时代！

闲话少扯，言归正传。今天关于管理软件的名词概念委实名目繁多，ERP、HRM、CRM、SCM、SRM、EHR、PDM、PLM、EPM、BIS以及SOA、SAAS等等，“三字经”泛滥江湖，以致于使一些刚入行的“新人”摸不着头脑。在这方面，应当说SAP关于企业管理软件的“划分法”相对比较合理与实用。

从企业的管理实践与信息化发展进程所处阶段来看，涉及企业的核心业务过程，诸如财务、采购、库存、销售、计划、生产制造等范畴，对应SAP R/3的主要内容（FI/MM/PP/SD

/CO），属于BACK-OFFICE的应用范畴，SAP将它划入ERP；属于人力资源管理范畴，包括人事、培训、工资管理等等，SAP将之名曰HRM；属于FRONT-OFFICE的应用范畴，主要是“客户相关”，涉及客户关系管理的内容，包括市场营销、销售管理、售后服务、渠道管理、电话或网上销售等等，SAP将它划入CRM；涉及买卖双方的业务协同、网上应用，主要是“供应商相关”的内容，SAP将它划入SCM（关于此点，各方的习惯与差别较大）；关于供应商资格认证、管理考核等等，涉及供应商关系管理的内容，SAP将它划入SRM；

关于产品研发过程管理，涉及产品生命周期的内容，SAP将它划入PLM（或PDM）；相对于上述主要涉及“业务过程管理”（联机事务处理OLTP）的范畴，主要针对业务过程的结果进行数据分析（联机数据分析OLAP）的应用软件，则名曰BIS（商务智能分析）或EPM（企业绩效分析）。

ORACLE的应用产品（Applications Product，相对于其数据库Database 而言的称谓）早期则简单地划分为四大部分：财务、制造、分销、人力资源。其中的所谓“分销产品”（Distribution），有人或许会将之与企业的产品“直销、分销”模式混淆，但实际与企业的产品分销模式管理没啥关系，它只是“采购PO、库存INV、销售订单管理OM”的总称。不过，若针对不涉及生产制造的商业企业而言，ORACLE 分销产品因为包括库存计划功能，已是一个很完整的应用软件，故而称之为“分销产品”还是比较贴切。但是，容易造成误解混淆总是个麻烦的事情，基于方便或习惯的原因，“采购PO、库存INV、销售订单管理OM”加在一起又常被业者笼统地称之为“供应链SCM产品”（此点与许多企业或用户的习惯叫法也比较接近）。当然这又容易和SCM的本来涵义产生混淆。显然，在这方面ORACLE与SAP相比没有那么精细准确，马马虎虎也就算了。

十年前ORACLE 11i 出台时，干脆一网打尽将所有应用产品统称为“电子商务套件”（E-Business Suits，EBS），不仅解决了产品的命名问题，同时也搭上了“电子商务”这个时代潮流的便车，可谓一举两得。但不好的是，由于缺少从企业信息化进程与发展阶段对产品家族“分层分级”的划分界定，认识较浅与经验不足的企业面对几十、上百的相关应用模块可能会感到茫然无措或因销售的引导而误入歧途。

二、ORACLE EBS的系统组成

早期的ORACLE 11i EBS将系统主要划分为五大部分，包括：

财务应用产品：总账GL、应收AR、应付AP、固定资产FA、现金管理CA、项目会计Project Account、财产管理Property、金融管理Treasure等等；

制造应用产品：物料清单BOM、库存INV、采购PO、计划MPS/MRP、订单管理OM、发运管理Ship、质量管理QA、在制品WIP、成本管理Cost、车间管理Shop Floor、工程管理ENG、能力计划CAP、高级价格Pricing、制造计划

Manufacturing Scheduling、高级供应链计划ASCP、供应商计划Supplier

Scheduling、配置管理Configurator、流式制造Flow、流程制造Process、项目制造Project等等；

人力资源产品：人事管理HRMS（包括全球与各国应用）、培训管理Training、时间管理Time、组织管理Hierarchy等等；

客户关系管理产品：市场营销Marketing、销售管理Sales、服务管理Service、呼叫中心Call Center等等；

公共服务产品：津贴管理Grant、劳动力管理Labor、公共预算Public Budgeting等等。

随着产品系统的日臻完善与发展，应用范围的不断扩大，后期的11i（11.5.10）则将系统主要划分为十五个大部分，包括：

财务部分：GL、AR、AP、FA、Cash、Property、Treasure、iPayment、iAsset、Grant、Labor、Public Budgeting等等；

制造部分：BOM、ENG、INV、MPS/MRP、WIP、Cost、QA、Warehouse、Project、Manufacturing Scheduling 、Flow Manufacturing、Process

Manufacturing等等；

采购部分：PO、i-Procurement、Sourcing、iSupplier、Supplier Scheduling等等；

订单履行部分：OM、Shipping、Pricing、Configurator、Transportation、Release、Automotive等等；

供应链计划部分：ASCP、Demand Planning、Global Order Promising等等；

客户关系管理部分：Marketing、Sales、Quoting、iStore、Proposal等等；

合同和服务部分：Contract、Service Fulfillment、iSupport、Depot Repair、Teleservice、Knowledge Management等等；

人力资源部分：HRMS、Training、Time等等；

设备维护部分：EAM、Maintenance Repair等等；

产品生命周期管理：Advanced Product Catalog等等；

租赁管理部分：Lease Management等等；

项目管理部分：Project Costing、Project Billing、Project Management、Project Source等等；

高等教育管理：Student、Self-service等等；

客户数据管理：Customers Online、Data Librarian等等；

商业智能：BIS、Balanced Scorecard等等。

与早期相比，“采购、订单履行、供应链计划”由于功能的完善丰富，应用范围的扩大增强，故得以脱离原“制造系统”，自成体系。“合同和服务”脱离原客户关系管理，自成一脉，情况也类似。

到了目前的ORACLE R12，系统范畴的划分与R11.5.10相比虽略有调整，但差别不大，主要表现在新增了“物流（Logistics）部分”，实际也就是将原来的“库存INV、仓库Warehouse、运输Transportation”归在了一起，单独出来、自立门户；原先的大类划分中新增了不少模块，其中的部分所谓“新增”，也不过是因为某些重要功能经“增强完善、发展壮大”后从原先的模块中独立出来自立门户，例如Leads Management、Partner Management等等；有些则是模块在大类间做了些移动，例如iStore从“客户关系管理”移动到“订单履行管理”（Order

Fulfillment）中等等。

以上之所以不怨其烦地介绍EBS内容的发展变化，做相关模块组成的罗列，主要是想说明以下两个问题：

一是经过的多年的发展与完善，ORACLE产品范围的广度、产品内容的深度，已经“由小到大、由浅入深”形成了庞大的产品组件家族。而更重要的是，ORACLE产品发展与成熟的过程，同时也与企业管理信息化必须“分层分级”，必然是由初级阶段向高级阶段逐步过渡、完善的历史进程高度吻合，这或许正是ORACLE产品之所以强大，有高度的可伸缩性与适应性，全球应用市场非常广阔的关键所在；

二是尽管ORACLE产品家族迄今已经包含300多个模块，乍一看令人生畏。但其最核心、最基础的东西仍是早年就开始做的包括财务、制造、分销（或曰供应链）等在内的十来个基本模块。与SAP今日的“MYSAP套件”仍然是以差不多二十年前开发的R/3（MM/FI/PP/SD/CO）为核心相类似，ORACLE最初的那十来个核心模块仍然是今日ORACLE EBS产品大厦的坚实基础。现在如此，将

来还会是如此，尽管有点遗憾的是，它们没有共同拥有一个类似R/3那样响亮的名字，这在产品的市场宣传以及企业对 EBS的认知接受方面多少有些不利影响。

三、ORACLE EBS 的系统架构

这里的所谓“系统架构”非是指“技术层面”而言，而是指从企业实际应用的角度来看的“应用架构”。借用马斯洛的“需求层次论”，企业与“人”一样，其信息化的应用需求也有一个从低到高，从“核心（Core）”到“增强（Enhance）”再到“高级（Advance）”的客观过程，不可能一蹴而就。下图是一个已经使用了十多年的有关ORACLE产品核心基础模块应用的示例图，它与SAP R/3的内容(FI/MM/PP/SD/CO)相比，高度近似，其核心内容实际在R/3的基础上有进一步的精简：

企业的现实目标是赚钱、盈利，利润是企业存在的最初理由。对于一个典型的制造型企业而言，简单来说，它至少包括两个最基本的业务过程：其一是所谓“价值增值”过程，即买进原材料、进行加工生产出产品，再以更高的价值卖出去，

这个过程通常属于“业务运营管理”范畴；其二是所谓“价值实现”过程，即从客户回收货款，向供应商支付购买材料的费用，再根据国家的会计法规，扣除相关费用如设备折旧等等，剩下的就是利润（或曰股东价值），这个过程通常属于“财务会计管理”范畴。

如果一个企业的“业务运营”与“财务会计”管理的核心过程能够实现信息化、IT化，那么按照国内的说法就是实现了“财务/业务一体化”。上图示例中的13个模块恰好实现了对“业务运营”与“财务会计”管理这两大核心业务过程的全覆盖，符合“财务/业务一体化”的标准，是一个最小的、也是基本完整的“企业级”应用。以国内最早的ORACLE ERP用户“华为”为例，其1996年上线R10.6时，就仅选择了这13个最核心、最基础的模块，因此其当时的企业信息化也仅是“财务业务一体化”的水准。细心的读者可能已经发现，“质量管理QA”对于一个制造型企业的重要性是怎么强调也不过分，为何这核心的13个模块中当初却没有将之包括？另外，人力资源管理也很重要，为何核心应用也不包括？

一个成熟完善的企业应用管理系统，若从系统所处理的对象或范围来划分，可以归纳为三大部分：财务Finance、业务Business、事务Transaction。它们分别对应于“资金流、实物流、信息流”这三个领域。实现“财务+业务+事务”的高度集成，是一个企业信息系统的终极理想，然而要做到这一点，基于系统的实现成本、设计复杂性、实施方便性等相互背离的因素综合考虑则绝非易事。

就企业广义的“财务Finance”的内涵而言，它通常包括属于日常的、基础性的“会计Accouting”工作，以及属于非日常性的、狭义的“财务管理”工作。

就企业广义的“业务Business”的内涵而言，它可以划分为“直接业务”与“间接业务”两大部分。直接业务，亦可称之为“核心业务”，它体现的是价值增值的运营过程，例如“采购、库存、制造、订单履行”等，它们的显著特点：一是实际工作与系统应用均缺一不可，二是同时与“财务”的链接关系十分紧密，必须高度集成；间接业务，亦可称之为“专业业务”或“外围业务”，它通常是为“核心业务”提供支持与服务，例如“HRM、CRM、QAM、APS、EAM”等，从系统应用的角度来说，没有它们对应用的完整性或整体效果影响不是太大，它们的共同特点是与“财务”的链接关系不是太紧密。

就企业广义的“事务Transaction”的内涵而言，它可以划分为“特定事务”（Specific Transaction）与“行政事务”（General Transaction）两大部分。“特定事务”通常需要一些专门知识，涉及的部门或人员范围较小，例如“编码管理、预算管理、合同管理、海关事务”等等，此类“事务”通常是为核心的“业务”与“财务”活动提供支持与服务，但在系统中与“业务、财务”的集成性、紧密性要求相对比较低。而“行政事务”基本上属于OA的范畴，特点是涉及的部门或人员范围广大，一般是围绕“人的活动”来展开，其中虽有部分可能会与“财务/业务”发生一定关系，例如：“行政申购管理、费用报销管理”等等，但对核心的“业务/财务”系统应用影响比较有限。

企业的信息化发展进程实际上也就是从核心的“财务/业务一体化”，逐步向非核心的“业务、事务”扩展与深入，并不断提高系统应用层次的过程。与之相适应，软件产品的应用架构规划，产品设计的优先级选择，各模块之间的链接关系，均必须考虑从“财务会计”向“核心业务”、“非核心业务”乃至“事务”逐步扩展、丰富、完善的路径选择问题，否则会对产品的未来前途产生致命的影响。有网友在谈到SAP/ORACLE产品的特点时，曾表示：SAP/ORACLE的产品模块设计简洁、实用，反观某国产软件，在核心系统还做得很不怎样的时候，居然就在里面添加了“档案管理、合同管理”模块，不仅企业应用没什么效果，而且还给系统实施过程带来一堆麻烦。

下图表达了当前ORACLE产品系统的应用架构层次性与实践应用的可伸缩性：

（注: EGO 高级产品目录，IGC 合同履行管理，IEP 预测管理，ZPB 企业计划与预算管理）

毫无疑问，“财务”居于核心地位，与之仅仅依靠、高度集成的是“核心业务”，随着企业信息化实践的深入，逐步向“非核心业务”及“事务”应用领域外延扩张。前两年，国内某ERP专业网站曾组织过一个有关“如何提高国内ERP生产制造水平”的讨论，有人在抱怨国内ERP产品水平低时，将原因怪罪到国产厂商“财务软件”的出身，这种说法实际并不成立。看看SAP/ORACLE（还有自称世界第三的SAGE），全是做财务软件出身，反而是靠HRM成名的Peoplesoft、靠生产制造成名的JDE、靠CRM成名的Sieble，最后全部都倒下了。从产品整体设计与应用角度来讲，财务软件的出身不仅不是短处，反而是优势所在。国内产品从财务软件向ERP软件进化所遇到的困难，不是“出身”问题，而是“路径选择”问题。

四、ORACLE EBS的系统集成性

这里的所谓系统“集成性”，既非指“技术层面”的集成，也非指模块“应用层面”的集成，而是指企业管理发展过程中内在“核心要素”的集成。有人以为，一个ERP产品

所包含的模块数量足够多、企业上线的模块数量足够多，就意味着“集成性”高，这实际上是一种误解。

一个企业从小到大的发展壮大过程，在不同阶段企业管理所要关注的重点因素是不同的。我们常说企业大则有规模经济效益，但实际上企业规模愈大，相应的管理成本也在急剧上升，如果因规模扩大而获得的生产率的提高，不能超过或抵消因规模扩大而导致的管理成本的升高，则就是所谓的“做大但没有做强”。有些人抱怨国外产品（SAP/ORACLE）系统刻板、流程僵化，这实际上是不懂企业管理精髓的外行话。想想看，尽管我们经常取笑国外大公司做事拖拉、流程死板、官僚主义，是资本主义的“国企”，但实际上这些大公司的“生产率”（以人均营收或人均公司GDP计）常十倍于国内同行业。所以说，管理的标准化、流程化是企业发展的必然选择。

一个高度集成的应用产品系统要适应企业管理的发展需要，必须同时考虑以下三大核心要素：数据集成、流程集成、管理集成。但需注意的是，这三大核心要素对于前述企业三大管理领域“财务、业务、事务”的影响与侧重点是有所不同的。

所谓“数据集成”比较好理解，即通常所说的“消除信息孤岛”是也。它可以分为两个方面：“静态数据共享”与“动态数据传递”。“静态数据”主要指类似“物料、供应商、客户”等基础数据，由各模块调用共享；“动态数据”则主要指诸如“采购订单、制造工单、销售订单、发票”等随时间不断累积的业务数据，它们之间需要遵循一定规则进行数据传递。

相较于传统的手工业务模式，现代的计算机技术与数据库技术在解决企业管理“数据集成”方面易如反掌。在系统“静态数据共享”方面国内外产品差距不大，但在系统“动态数据传递”方面，由于有些国内主流产品采取的是“模仿手工单据”的实现方式，导致数据冗余，传递、同步非常困难，使用效果非常糟糕。

ORACLE产品在“数据集成”方面有一个突出的“亮点”是各模块几乎都有集成第三方系统的接口（API），其内部各模块之间的数据集成也基本上采取类似集成第三方系统的“松耦合”方式。有人将之认作是ORACLE比SAP灵活、易用的优点。这可能是与ORACLE产品早期还不完善时，不得不考虑所谓“最佳配置实施方案”有关（详情见“ORACLE ERP的前世今生”有关内容）。这也许可以说是ORACLE的“因祸得福”。

所谓“流程集成”也可以分为两个方面：“流程传递的自动化”与“流程识别的自动化”。ORACLE在其产品宣传中经常讲到一点“用户只需很少的干预与击键操作，其它都由系统自动替你完成”，说的正是这个意思。

所谓“流程传递的自动化”，例如ORACLE“内部申购”，如果是向其它公司的库存组织申请物料，则该采购申请PR被自动导入OM，OM发货后循发运网络被接收，系统自动在两公司间生成应收、应付。再如OM中的直接发运（Drop

shipment）物料，系统自动生成PR，客户收货后，一旦PO作接收，则OM系统自动作发货确认并生成AR等。

所谓“流程识别自动化”，ORACLE系统通过大量的“参数”设置（SAP的参数设置有七、八千，ORACLE也不遑多让），使得不同的物料、业务类别，在各模块间循不同的业务流程自动得到相应处理。这无疑使得单个用户在面对大业务量且流程复杂的情况下能够轻松应对，应付自如，获得高的生产率。

参数多，设置复杂，令人生畏，实施困难，向来是SAP R/3产品早年开始就一直遭不少人诟病的地方。ORACLE的实际情况不比SAP好多少，但ORACLE产品作为后来者，在系统流程“参数”设计的层次性、使用的方便性方面，还是做了很多努力，相对而言可能要比SAP容易掌握一些。ORACLE在系统业务流程方面相较于SAP也做了一些简化，但这种“简化”往往是以牺牲某些不怎么常用或使用意义不大的“功能”为代价的。这或许正如有人评价的：SAP求严求全，ORACLE求实求用。现代企业管理的发展方向是追求企业管理的整体效益，要求业务流程简化、再简化，因此ORACLE的做法还是符合潮流的。

曾经碰到一位国内产品的设计人员，对于SAP/ORACLE通过复杂的参数设置以控制业务流程的做法，该仁兄颇为不屑、不以为然：“参数设置已经过时，未来的方向是工作流”。这种说法委实不敢苟同，实际上，ORACLE产品内同时也大量使用“工作流”技术（Workflow），但它与“参数”设置并不冲突，两者是相辅相成的关系。

在企业管理实践的核心“业务+财务”领域，系统的“数据集成与流程集成”的重要性是怎么强调也不过分。在“财务”领域，系统的数据集成是重点，因为该领域流程本来就不是很复杂（这也是应用软件厂商多财务出身，企业信息化也往往先从实现财务电算化开始的原因）。而在核心“业务”领域，系统的流程集成

是重点，因为该领域业务环节多、流程长，涉及部门与人员众多，只有实现高度的流程集成才能达到高的生产率。ORACLE的产品之所以强大（当然还有SAP），正是首先在于其核心“业务与财务”系统内部及相互之间的高度的数据集成性与流程集成性。

纵观国内ERP使用比较成功的企业，诸如联想、华为、中兴等，无不是以SAP或ORACLE的核心系统搭建自己的企业信息化平台，原因就在于外围系统（非核心系统、事务管理系统）可以策略性地使用第三方系统或干脆自己开发，但“核心系统”基于数据与流程高度集成性的要求则别无选择（尽管必须忍受高昂的License价格）。反过来从产品研发角度看，核心系统也是不可能通过收购或集成第三方产品取得成功的，ORACLE过往所收购的补充性质的应用产品几乎全是外围或周边应用产品（同类产品收购看重的仅仅是市场份额）。

需要强调指出的一点是，这里所讲的系统“流程”不是指一般意义上的企业管理“过程”。所有的ERP产品都有所谓“流程”，所有的顾问、咨询人员都在给企业大讲特讲所谓的“流程”。但此流程非彼流程，有些产品中的所谓“流程”可能只是无甚管理意义的“过程”而已。前两年有一位国内厂商的咨询顾问在某地公开演讲时，曾发高论：企业管理流程是由“销售计划、采购计划、生产计划”这三大计划驱动的。此论一出，立刻有业内人士斥之为“混淆概念、误导企业”。

京城有一位出身草根、创业传奇的民营企业家，靠摆摊卖包子起家做成一餐饮集团，其在使用了国产ERP后曾评价道“除了把数据归到了一起，没看到有其它好处”。真是奇人奇语，一语道破国内产品的问题所在。细究其原因，就在于国内主流产品普遍都采取“模仿手工业务过程”的系统实现方式，丢掉的是“计算机技术与数据库技术”的长处，彰显的是“手工业务操作”的短处，实现数据集成还能对付，要实现业务流程的“高度集成”，则几无客观上的可能。目前国内主流产品的系统实现与手工操作相比，工作效率的提高有限，有时甚至比手工操作更不方便，因而也无法适应于业务量大、流程复杂的大企业的使用需要。

不过，对于许多中小企业来说，由于规模有限、业务量相对较小，规范但欠灵活的流程管理并非其核心竞争力所在，能做到“数据集成”就可以了（有次在网上与前SAP中小企业市场负责人黄骁俭讨论时，他也感叹，中小企业的管理确实不靠什么流程）。此时，“模仿手工业务操作”的系统实现方式所天然具有的“学习上手容易，实

施比较简单”的特点就凸显了。当前中低端市场的国外产品如SAP的SBO、微软的Navision，系统业务流程简单也是它们的共同特点，不过，相较国内产品，它们还是抛弃了很多“手工操作”与“系统实现”相冲突的东西，因而，系统流程的业务效率比纯粹的手工操作还是有明显改善。

最后，来谈谈所谓应用系统的“管理集成”问题。这里的所谓“管理集成”主要是针对非核心业务或其它“事务”性工作领域，系统所能提供的“管理与控制”而言。这些领域工作的共同特点是，不象核心的“业务/财务”领域那样与“实物流”（价值增值）、“资金流”（价值实现）紧密相关。有很多人在学习ORACLE（或SAP）时，都曾会有一个疑问：新增物料、新增供应商、新增销售订单等等，系统的标准操作功能几乎都不考虑这些数据是怎么来的过程问题（例如“单据审批、流程审批”等），实际情况肯定不是这样的吗！为什么核心系统的有些单据界面感觉纯粹只是提供一个“最终结果”的录入功能？

原因在于ORACLE/SAP核心业务/财务系统“以价值为中心”（物与资金都属价值）的应用架构设计，本来就不擅长于处理“以关乎人或组织的行为信息为中心”的事务过程。世上有没有“两者”处理同时都很擅长的应用系统呢？迄今为止还没有出现，鱼与熊掌不可兼得。也就是说针对核心系统，为了保证数据与流程的高度集成性，必须适当牺牲系统的“管理集成性”。为了弥补核心系统的这一不足，ORACLE/SAP提供了大量的外围系统（非核心业务或事务领域）供用户选择使用。

例如“新增物料”过程管理，EBS有“Advance Product Catalog”产品可以提供支持；“新增供应商”过程管理，EBS R12 已经增加提供了基于WEB的某些新功能，相信未来会逐步丰富完善并独立出类似SAP SRM的产品；至于OM中的销售订单，属于CRM的很多模块都是其前端产品，都在为其提供支持与服务。非核心的外围产品由于它们与核心系统在“数据与流程集成性”方面的要求相对较低，故在系统设计时可以更多地考虑系统的管理集成性。这些外围系统通常还有一个共同特征，就是尽可能采用比较适合处理“需要多人参与的信息传递与管理过程”的WEB界面方式。EBS R12中将供应商及客户定义的GUI界面改为WEB界面，单纯从数据录入（集成）角度来看或许并不更方便易用，但却为系统向强调“管理集成”的事务领域扩展打开了方便之门。

前面曾经谈到对于制造型企业非常重要的“质量管理QA”功能，ORACLE核心业务模块中可以不用把它包括在内，而实际上用过“QA”模块的人都知道：它主要只是起到一个收集或录入质量数据的最终结果，并基于录入的结果数据在核心业务流程的某些节点起到某种控制的功能。至于企业所关心的这些质量数据的最终得来要经过怎样的一个复杂事务过程，系统基本不涉及（SAP的QA模块情况类似）。之所以会出现这种状况，是因为“质量管理过程”从系统实现角度来看，基本与“价值增值与价值实现”这两大核心业务过程关系不大，标准产品的规划设计时必须有所“取舍”，否则可能效果适得其反。所以，企业通常需要根据自己的实际情况寻求另外的“基于质量过程管理”的解决方案来配合使用。而人力资源HRM模块与企业核心业务过程的关系也离得比较远，集成性要求并不高，故通常在系统实施优先级方面也可以放得更后一些。

基于“信息与行为”的事务过程管理，各行各业、不同企业的习惯做法或制度规定差异很大，客观上进行系统标准化难度甚大。早些年有人鼓吹自己的ERP产品对ISO9000如何支持（这等“俗事”ORACLE以前也曾干过），前些年有人鼓吹对欧盟的ROHS如何支持，近年又有人鼓吹对“萨班斯法案”如何支持。很难想象这种所谓的“支持”从系统实现的角度来看有多少现实意义。基本上只是“投企业所好”，当不得真。如果有ERP厂商自己先信以为真，则结果必然是缘木求鱼。

由于非核心的业务系统、事务管理系统，与核心的业务/财务系统在“数据与流程”两方面，集成性、紧密性的要求并不是太高。尽管ORACLE/SAP均有很多的类似外围产品，也尽力鼓吹、游说企业只使用其同一家的所有产品，以达到应用系统高度的“管理集成性”，但很多企业还是乐于使用第三方产品或自己开发（License 价格太贵也是重要考虑因素），原因就是完全使用一家的所有外围产品于实际的使用效果或管理效益，很多时候综合优势并不明显。

近年来，电子商务大行其道，国内新锐的IT企业如腾讯、百度、阿里巴巴等纷纷投身介入，如果这些企业能够认识到，ORACL/SAP目前所采取的以单个企业为中心，连接供应商与客户，向上下游延伸、通吃的所谓“大企业”应用全程电子商务战略，因存在先天缺陷而历经多年却发展缓慢，ORACLE/SAP自我革命动力不足，市场客观上正期盼出现突破性的新电子商务应用模式，在精研ORACLE/SAP的核心系统及外围系统的基础上，能够做出与ORACLE/SAP核心

业务系统在“数据集成性、流程集成性、管理集成性”方面并不比它们的自身产品差，更符合国内市场且体现中国特色的外围电子商务产品，则介入范围广大、利润丰厚的高端企业应用市场并非没有可能。而核心的ERP产品目前看来还只能是期待国内的传统厂商能在高端领域有所突破。

五、ORACLE EBS 的应用与实践

经过过去二十年尤其是近十年的快速发展与完善，ORACLE 电子商务套件（EBS）作为一个大型的、高端的管理软件程序包，已经在全世界范围内有着广泛的应用，拥有数万家不同类型的用户，涉及高科技、制造、商业、化工、航空、金融、公用事业等各行各业。ORACLE目前在中国国内的客户也已有近千家。

一个公司选择什么样的ERP产品搭建自己的企业信息化平台，并不是如有些人所说的“主要考虑当前的企业管理水平与成熟程度，适合就好”，而是应当立足当前、放眼未来，考虑企业的长远发展规划与愿景目标。企业信息化是一项重要的基础性工作，与企业管理水平的提高是相辅相成、相互促进的关系，也有一个不断完善、积累的过程。企业早年岁月所做出的“路径选择”，若干年后回头来看，往往才能真正体会到其重要性所在。深圳有两家比邻而居，都是千亿规模以上级的大公司，十多年前的不同选择导致十多年后，一个企业的信息化系统出现“不推倒重来就难以为继”的进退两难局面，而另一个企业的信息化系统则已经溶进公司的管理血液，成为企业核心竞争力的一部分。

今天人们一谈到ORACLE或SAP产品的应用，往往都会提及两点：价格昂贵、难懂难用。最近有人撰文找SAP的麻烦，提到SAP的产品在有些企业卖得很贵、有些企业卖得很便宜时，认为是存在“价格欺诈”。这种说法其实是很外行的话。软件产品不同于“硬件”产品，其“边际成本”实际上等于零（好的软件产品基本就等于“印钞机”）。软件产品License许可的价格，不是基于“成本+利润”的一般产品定价原则，它主要是基于能够为客户带来或创造多少价值。

当然，企业的客观承受能力也是考虑的一个重要因素。这里所谓“企业承受能力”的判定标准，业界通常以“年度IT预算投入”占年度销售收入的比例来衡量，国外的一般标准大约为2%，国内由于种种原因一般在1%以下。一个企业从小发展到大，其年度IT投入占销售额的比重，比较合理的情况是，随着人员、销售规模

的不断扩大，先从0逐渐增加到一个峰值，然后又逐渐回落并维持在一个相对合理的水平，形成一个类似正态分布的曲线。之所以如此，是因为当企业规模较小时，IT投入的产出效益并不明显，企业缺少在IT上作投入的动力与紧迫性。随着企业规模的扩大，传统的手工业务模式或“电算化”管理模式越来越难以满足企业在运作效率、管理控制方面的要求，企业必须及时地、不断地加大IT投入，借助IT手段与工具，才能突破企业规模与管理发展的“瓶颈”；当一个企业发展到相当大的规模，且管理的IT化也达到一个相当高的水平时，以“人均产出”为核心表现的企业效率与竞争优势的提升速度将明显快于人均IT投入的增加速度，故此时IT投入占销售额的比重反而会出现下降的趋势。

一个企业发展到一定规模，如果未将IT投入保持合理水平，没有或未能依靠IT手段突破管理发展的瓶颈，则这个企业的未来发展很可能就出现如下两种情况：一种是企业内部管理循环不良、迅速恶化，任何外部环境的变化冲击（如金融危机）都有可能使得公司突然崩溃；二是企业规模（人员、销售）虽然还在不断做大，但反映企业内在管理质量的核心指标如“人均产出”等徘徊不前或不升反降，企业做大的同时不是在做强，而是变得越来越虚弱，一旦外延性的规模增长也出现停滞，则企业的内在危机就可能总爆发。

ORACLE公司对于其产品家族的市场应用，采取的是一种非常“开放”的策略，所有的产品软件包及其浩瀚的应用文档在其官网上可以随便下载学习、试用（当然，其有象征性的法定权利保留声明），系统一经安装就具备所有模块的所有应用功能，技术上不做任何限制，所谓License许可也不过仅是只具法律意义的一纸文书。ORACLE这一自信、大度、从容的做法，不仅有利于其产品的推广普及，也为企业的应用选择提供了足够自由、灵活的空间，可谓一举两得。所以说，License价格问题通常不是真正有心选择ORACLE产品的企业所“绕不开”的难题。

至于“难懂难用”的问题，要分两个方面来看。一方面，学习、掌握有难度是所有高端产品共同的属性。早些年有网文曾作一个比喻：SAP/ORACLE是波音飞机，国内产品是自行车。这个比喻对国内产品多少有些刻薄，但倒是能说明一些问题，试想：学骑自行车找个空地练练也就能上路了，学开汽车、考车牌就没那么简单了，学开飞机就更不容易了。

另一方面，国内有一种说法“高端ERP产品对企业员工素质要求高，国内企业员工素质普遍较低，所以很难适应”。这其实是一种不了解情况、想当然的说法。实际上就ORACLE EBS系统而言，企业的涉及人员主要分两大类：一类是EBS系统实施、维护人员，高端产品对此类人员的要求很高，但这毕竟只是涉及很少的人员，并且企业通常可以通过聘请外部咨询顾问来弥补自身人才的不足。另一类是EBS系统应用操作人员即所谓“User”，这类人员数量广泛，涉及几乎所有部门，人员众多。但应用人员User通常又可以分成两类：一是决策型用户，另一类是事务型用户。

所谓“决策型用户”，通常是指在EBS系统中从事诸如计划调度（Planner）、绩效分析与管理（BI/EPM）等等之类工作的用户，这类人员不仅要求对相关EBS系统逻辑、功能流程有透彻的了解，熟练掌握EBS系统所提供的各种模拟分析工具的使用，同时对于企业实际业务必须有丰富的经验积累，并且还要有强大的管理推动与跨部门协调能力。这类人员在企业里虽然可能没有高的行政职务，但由于其工作结果与工作质量影响的全局性、重要性，通常在企业里占有举足轻重的地位。国内某高科技企业的计划人员就享有“用金子堆出来的人”的说法（半指其高工资高待遇，半指其工作质量可能导致公司巨额损益）。但这类系统用户毕竟还是涉及企业很少的一些人。

所谓“事务型用户”，主要是指那些只需严格按照EBS系统操作规程在规定的时间里完成规定的系统操作即可的那些用户，他们在企业里占绝大多数，例如采购员（Fulfillment Buyer）、仓管员、发货员、发票会计等等。对于这些事务型用户来说，基本上无需详细掌握EBS系统是如何定义的、业务流程在系统中是如何运转的，大概了解一点就可以了，会上网也就基本能玩得转。ORACLE高度集成的EBS系统就是把企业变成一部高度自动化的机器，大多数人则成了机器的一部分。

所以，对于使用ORACLE EBS这样的高端ERP产品来说，对企业员工的素质要求出现的是“两极分化”现象，综合看来，所谓“国内企业员工普遍的素质问题”根本就不是高端产品的使用障碍。问题通常出在企业对于高端的系统维护与应用实施人才的使用与培养的态度上，出在对有真才实学的高端咨询顾问“知识价值”的真正尊重上。国外发达国家企业管理水平普遍较高是事实，但国外管理

咨询服务市场更为发达也是事实，而管理水平已经很高的大企业在“咨询顾问服务”上常年保持很高的预算投入水平更是普遍现象。反观有些国内企业，往往在买好车、做办公豪华装修等方面可以一掷千金，但在提高管理水平的投入方面却十分吝啬。须知全靠“小米加步枪”就可以打天下的时代已经过去了。

国内业界在谈到高端ERP的企业应用时，还有一种说法认为：高端产品包含有丰富的管理思想，企业应用通常需要进行业务流程重组BPR，伤筋动骨，弄得不好会把企业搞死（即“上ERP是找死”）。这种说法也未免有些危言耸听。

首先，就ORACLE EBS系统而言，其包含的所谓“管理元素”，根本就不是什么象有些人故弄玄虚的“这思想、那模式”的神秘东西，它只是一些最朴素、最简单的基本管理原理与管理原则，例如“决策与执行的职责分离、专业化的分工协作、需求与供应的平衡”等等（有关EBS中的所谓“管理思想”的详细讨论，容以后结合具体的应用模块再来逐个做点评）。这些简单的道理很少有企业不懂或不能接受，系统只是提供了一种较之于“手工”更容易、更简单实现这些基本管理准则的工具而已。

这就好比城市街道中央虽然划了禁止跨越的“双黄线”（类似公司的规章制度），但大部分人开车总是会时不时地图方便压线超车或掉头，即使心知可能会被“电子眼”拍到而遭罚款，但还是难以杜绝。但仅在街道中央立起一道低低的隔离栏（类似企业上了系统），问题马上解决，交通混乱状况立刻得到根本改善。企业上系统首先一定是为了解决已经存在的或者潜在隐患的问题，绝不会只是为了简单地“模仿或复制”当前的手工业务过程，因此，能够解决问题的、有效果的管理改进或改良，一般不会在企业内产生很大阻力。

有人或许会觉得，把ERP中神秘的“管理思想”比喻成街道中央的那一道低低的“隔离栏杆”，这也太简单、太看轻系统了的吧！其实，问题的关键就在于那道隔离栏杆用在什么时候、什么地方，怎么来用（类似于ERP系统的实施水平）。请再看下例：

有一居民小区大门口有一长约几百米的窄窄街道，双向仅两车道，街道两旁有些商店饭馆，于是经常有些人就图方便把车停在路边。如果停的车数量较少倒也影响不大，但车停多了变成靠边一长溜，两车道变成一车道，对小区的车辆进出麻烦就大了。经常出现小区一进一出的两辆车被堵在中间而进退两难的情况，于是抱怨、投诉，立禁止停车的告示牌，甚至把交警请来抄牌、开罚单等等，种种招数使尽，但都还是难以从根本上解决问题。直到有

一天，窄窄的路中央突然冒出高不到一尺、低低的一溜隔离U型弯管（学名：U型护栏、分道栏），如下图所示：

原本就很窄的两车道变成了事实上更窄的双向、单车单行线。虽然对于小区车辆进出来说，没了以前掉头灵活、来去自由的方便，但路边乱停车而导致进出堵塞的现象却忽然从此就彻底没有了，这是为什么呢？相信许多人开车或坐车在比较窄的街道上都见过那种在中间起隔离分道作用的一长溜U型弯管，但有谁想过它居然实际上还蕴含着一种十分高明、堪称完美的“管理思想”呢？（这里卖个关子，且不点破，留给读者思考）。为方便表述，姑且将其名曰管理上的“栏杆效应”，在以后EBS系统各应用模块有关“管理思想”的探讨中，本系列文档可能还会反复引用到它。

其次，ORACLE EBS系统的应用架构设计如前所述，从企业应用角度来看，从内到外、从初级阶段到高级阶段有很强的可伸缩性，可以适应企业不同发展阶段管理进步的需要；即使是具体到EBS每一个模块内部，其实现功能也有“基础应用、增强应用与高级应用”之分。企业信息化与管理水平的提高是一个循序渐进、不断完善的长期过程，那些抱怨实施效果不理想或失败的企业，很多是因为急于求成，把信息化看成是“一锤子买卖”，想“一口吃成个胖子，结果反而被噎住”造成的。例如，有些企业认为EBS有那么多模块，自己应用的还不到总数的5%就很不甘心，还有些人鼓吹“MRP已经落后，要上就上APS”等等。

不过，需要指出的是，由于制造型企业核心的“价值增值与价值实现”业务过程对于系统在“数据集成性与流程集成性”方面有很高要求，那种“先财务，后进销存，再生产制

造”的做法也是很不可取的。作为一个完整的基本“企业级”应用，将EBS系统的那十多个核心模块割裂开来使用，将严重影响系统整体功能与效益的发挥。这个道理有点类似管理上的“木桶原理”，木桶能装多少水是由最短的那块板决定的。同样的道理，那种财务用国产的，生成制造用进口的，进销存等模块又用另外一家的“拉郎配”式的系统集成实施方案，于核心业务系统的整体实施效果，大多数情况下也是极不科学、极不可取的做法。

最后，引用美国BOSS咨询顾问公司关于ORACLE EBS 核心业务模块实施的难易程度的经验数据，供大家参考，其中假定总账GL的困难程度为100，其它都是相对数：