一、從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、系統實施上線的難易程度與學習掌握的難易程度不盡相同，有些可能恰好相反。