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業界風光一時、有著不俗業績的企業，諸如J.D.Edwards、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。

 J.D.Edwards（愛德華茲），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年：引領風騷，徵購無極限

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月就開始推出其新一代基於網路的企業套件mySAP.com，但多年之後，SAP不得不無奈地承認：許多人弄不明白mySAP.com是什麼東西。

伴隨著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，其它都是相對數：

	應用模組	相對困難程度	備註
1	總賬GL	100
2	應付帳款AP	80
3	應收帳款AR	90
4	固定資產FA	80
5	採購管理PO	120
6	庫存管理INV	100
7	訂單管理OM	170	值針對原OE，OM當更高
8	物料清單BOM	80
9	工程ENG	50
10	主生產計劃MPS	90	MPS/MRP實際是一個模組
11	物料需求計劃MRP	150
12	生產能力計劃CAP	30
13	在製品WIP	100
14	成本管理CST	120

注：1、難易程度相對於不同行業、不同企業以及不同業務背景的人來說有一定差別。

    2、系統實施上線的難易程度與學習掌握的難易程度不盡相同，有些可能恰好相反。