1、ORACLE EBS基礎(chǔ)設置之組織架構(gòu)四、組織架構(gòu)在企業(yè)管理實踐的過程中，組織”(Organization) 詞是個經(jīng)常需用到的概念，一般與人員”與職能”這兩個要素密切相關(guān)，反映某種行政管理關(guān)系，例如 “財務部、銷售部、采購部、生產(chǎn)部、倉儲部 ”等等。 企業(yè)內(nèi)部行政組織(部門)的劃分是企業(yè)基于 “職能驅(qū)動 ”業(yè)務管理模式進行運作的基礎(chǔ)。 目前， 國內(nèi)適用 于小企業(yè)使用的大多數(shù)低端管理軟件并不考慮系統(tǒng)中的 “組織”設置問題，其系統(tǒng)應用模塊的劃分，例如采 購模塊、倉管模塊、銷售模塊等等，實際上就已經(jīng)基本反映了企業(yè)運作的“組織職能 ”劃分問題。但是，對于業(yè)務復雜、規(guī)模較大的企業(yè)(如所謂 “集團企業(yè)

2、”)，管理軟件使用與實施的系統(tǒng) “組織設 置”問題將是一個首要的重要問題。一個常見的、也是錯誤的系統(tǒng)實現(xiàn)方式就是將企業(yè)的“行政組織設置 ”直接映射到系統(tǒng)中，以 “行政組織 ”代替 “業(yè)務組織 ”。這種系統(tǒng)實現(xiàn)方式雖有理解、掌握比較容易的優(yōu)勢，但卻 完全違背了大企業(yè)運作必須基于 “流程驅(qū)動 ”業(yè)務模式的基本管理原則。國內(nèi)有所謂高端管理軟件在系統(tǒng)實 施過程中，常常出現(xiàn)有幾十個財務、采購組織，幾百個銷售組織，乃至上千個庫存組織的“盛況 ”，導致系統(tǒng)幾乎沒法使用的困境，其癥結(jié)正在于此。與企業(yè)的 “行政組織 ”設置與人員規(guī)模密切相關(guān)且復雜多變不同，軟件系統(tǒng)的 “組織設置 ”必須以業(yè)務流 程運作為核心，要

3、求盡可能簡單并保持相對穩(wěn)定，在公司(人員)規(guī)模擴大的過程中具有延續(xù)性與繼承性。 作為ERP鼻祖的SAP將系統(tǒng)組織簡單地分為 “集團(Client)、 公司代碼(Company Code)、 采購組織 (Purchase Org)、 銷售組織(Sale Org)、 工廠(Plant) ”等類別。ORACLE的組織設置本質(zhì)上與之基 本相似， 但作為后來者作了進一步抽象與簡化，系統(tǒng)組織劃分為 “業(yè)務組(Business Group)、 法律實體(LegalEntity)、業(yè)務實體(Operating Unit)、庫存組織(Inventory Org) ”等。如果說SAP的組織模型字面上多少還帶有一點

4、 “行政組織 ”痕跡的話 (這可能是某些聲稱學SAP的國 內(nèi)產(chǎn)品誤入歧途的原因)，ORACLE系統(tǒng)的組織模型字面上已經(jīng)幾乎看不出與 “行政組織 ”還有什么關(guān)系， 其中的 “Inventory Org現(xiàn)”今中文翻譯成 “庫存組織 ”，容易令人望文生義和企業(yè)的 “倉庫管理部門(Warehouse) ”混淆，但Inventory的本義實際應該是 “存貨 ”，稱之為 “存貨組織 ”或許更好一些。如下圖22所示ORACLE系統(tǒng)有關(guān)核心業(yè)務的多組織模型：ORACLE多組織系統(tǒng)摸型業(yè)務組法律:實體法律實休業(yè)務 實體業(yè)務實體（一）業(yè)務組（BG）業(yè)務組”的概念可以與企業(yè)的 集團”概念參看，但不同的是一個企業(yè)在系

5、統(tǒng)中可以設置多個業(yè)務組（集團）”。通常對于一個企業(yè)來說，系統(tǒng)中有一個業(yè)務組”就夠了，這表示企業(yè)就是一個 集團公司”。而對于某些業(yè)務 多元化”的特大型公司（如跨國公司），則可能需要在系統(tǒng)中設置多個業(yè)務組”，表示企業(yè)由多個集團公司”組成。業(yè)務組設置是系統(tǒng)組織設置的第一步，是最高層級的組織形態(tài)，但它主要是與人力資源信息的分隔有關(guān)，即人員信息”的設置在一個BG范圍內(nèi)是由各業(yè)務模塊共享的（如果需要）。一旦系統(tǒng)設置的用戶名（User）被與人員（Employee）關(guān)聯(lián)，無論使用什么責任進入系統(tǒng)，都會定位至一個確定的BG中,任何責任在任意時刻只能關(guān)聯(lián)一個BG。EBS安裝好后，系統(tǒng)里面已經(jīng)預置了一個名為“Set

6、up BusinessGroup的初始業(yè)務組”。如圖23所示系統(tǒng)預置的 “Setup Business Group :”ii-1.庫存組織庫存組紜庫存組紜上圖中的功能。子庫”是特殊的系統(tǒng)組織實體，沒有上下文環(huán)境可進入，主要表示庫存組織之下的某種業(yè)務功能。財務、銷售、采購”并非系統(tǒng)的組織實體”，它僅表示業(yè)務實體（0U）具有的相關(guān)業(yè)務處理當以系統(tǒng)預置超級用戶SYSADMIN進入后， 應首先設置一個具有在HRM或INV下創(chuàng)建組織功能的 責任名， 隨后給此責任的 “HRUser Type配置文件設定值為 “HR User，則該責任就有了創(chuàng)建新BG的 能力。通常需要一次性將企業(yè)所需要的BG全部建立，一般

7、另創(chuàng)建一個與企業(yè)名稱一致如某某集團”的新BG就可以了，也可以（不推薦）直接使用系統(tǒng)預設的“Setup Business Group而不創(chuàng)建新BG。系統(tǒng)每新建一個BG,就會自動在配置文件“HR安全性配置文件”的LOV中自動添加一個與新建BG同名的可選值（初始時只有 “Setup Business Group一個值）。在某一個BG下（初始為Setup Business Group）新建的任何責任，系統(tǒng)都將該責任的配置文件“HR安全性配置文件”值默認為當前BG。要在進入系統(tǒng)時能切換到新的BG,必須先修改該責任的“HR安全性配置文件”設定值。如果將配置文件“HR交叉業(yè)務組”的值設為是”，則在不同BG下

8、，新建的組織名稱應當（雖然可以） 不同，否則查看時可能會引起混淆。在同一個BG下的所有新建組織，名稱不允許相同。（二）法律實體（LE）法律實體（LE，Legal Entity）對應于真實世界中的按國家法律法規(guī)要求注冊的法人公司”在R11中，LE在組織FORM定義時，對于每個LE必須為其法人主體會計科目”關(guān)聯(lián)一個帳套SOB。每個LE對應一個SOB，這與真實世界的法規(guī)要求是吻合的。如下圖24所示：要注意的是，在R11中定義的LE時，并未作與會計科目彈性域結(jié)構(gòu)”的公司段”值關(guān)聯(lián)，用戶必須 對于其是與公司段值中的哪個值對應心中有數(shù)。而在R12中，LE的組織定義雖在FORM中仍然保留，但LE的法人主體會

9、計科目”的FORM設置被廢棄（故FORM中定義了也無用），改為在定義 分類帳”時的會 計科目設置管理器”WEB中定義并分配法人實體LE。一個分類帳設置（主輔分類帳）可以添加多個LE，但每個LE只能具有一個分類帳設置。如下圖25所示：玄克11凰*1設置妄 -1 nd HtdnrHL?匸恥|丈件卽査音電膠麓二MQ枯酗Qa .；:/ , w( (w電亡*方轄JL.山Mgrw.MMgtT見M豹一頑電匸曲開t（ErWF USUHTOiH：賞也/“ J轉(zhuǎn)卻社-“ORACLC*令廿罰貝設冒管理譽a_ _田整衿去戸弓FH-它聲咋世晞. 辛令*1|后YiUfZArrWMQJS抑狀齊WV-： -K ：“ T-r：

10、,為M甘紳:宅加訝更睛E記麻卿i抑也二審M7G 丿古祁*訕1棍畫而*4 更鶯為巧護也舐口疋 ,!尺適甌W苴G匚PEKATK帕jiu in.jOMUIMJ創(chuàng)亠 hf伯在R12中，還必須為法人實體分配會計科目彈性域結(jié)構(gòu)的公司段即平衡段值。每個LE可以分配多個平衡段”值，公司段值集中每個段值一旦被分配給某LE，則其它LE就不能再被分配。在R11或R12中創(chuàng)建一個LE后，應當及時到會計科目彈性域結(jié)構(gòu)中添加需要對應的公司段值LOV（一個或多個），并重新進行彈性域的編譯，否則系統(tǒng)可能會彈岀錯誤報警信息。R12中一個LE對應多個公司平衡段值，代表有多個分公司，LE是它們的合并。主輔分類帳可擁有相同或不同的公

11、司段值集，表示從不同的維度（如按 地區(qū)、按產(chǎn)品等）去劃分公司以方便考核。如圖26所示為LE添加平衡段值： ()atAXttUW營右祥摘乜舅h rfhhli* Shl.rsUYSll ITusEETCUDLD旦u-juthi hcs L!rJH.eusEBSJIDLzsUSA TESTUSUSS冊妙50pr aCACTd卵昭江劉疋IQ9旳朝打JIHumG-snqik CTREJ%CTAWililCI 1T?ypilin Le-iiutigUSJSVAT-fj&i*曾fsFssucap jzakjauUSE3泅述DUO$E,鏈人主住I無論是R11還是R12，法律實體LE的設置都對具體的業(yè)務

12、處理影響不大，其與系統(tǒng)用戶或責任不 關(guān)聯(lián)，不直接影響系統(tǒng)上下文的切換，故有人甚至認為EBS的LE設置作用不大。這對于系統(tǒng)的內(nèi)部運作來講情況確實近似如此，但對于需要通過系統(tǒng)產(chǎn)生供外部使用的具有法律意義的文書（如采購訂單、財務 報表等等），嚴格區(qū)分法律實體LE還是必須的。R12顯然更多地考慮了外部使用的這種法律要求（即所謂法規(guī)遵從性”或合規(guī)性”，并在相關(guān)業(yè)務應用模塊中有所體現(xiàn)。（三）業(yè)務實體（0U）業(yè)務實體（OU，Operating Unit）是EBS系統(tǒng)組織設置的重點也是難點之一。它與法人主體LE本身沒有必然的關(guān)系，與會計科目彈性域結(jié)構(gòu)中的公司段”也沒有直接關(guān)系。從企業(yè)實際業(yè)務管理需要的角度去看

13、，業(yè)務實體0U可以看作是在系統(tǒng)中按照業(yè)務的相似性，把多個不同公司（包括LE）的業(yè)務處理過程及數(shù)據(jù)劃分成相對獨立的 管理單元”在每個管理單元內(nèi)部，各公司的業(yè)務運作共享相關(guān)數(shù)據(jù)并執(zhí)行統(tǒng) 一的業(yè)務策略。例如，有一個業(yè)務多元化的企業(yè)既生產(chǎn)醫(yī)院使用的X光機也生產(chǎn)普通電視機，并且其下屬在全國各地有多家生產(chǎn)X光機或電視機的分公司、子公司。由于這兩種產(chǎn)品所使用的物料、供應商以及針對的客戶 群差異很大，企業(yè)為方便管理，可以將業(yè)務運營”劃分為兩個相對獨立的 業(yè)務管理群組”對應到EBS系統(tǒng)中就是兩個業(yè)務實體0U。從企業(yè)日常業(yè)務運作管理的角度來看，對于單純的電視機業(yè)務，全國范圍內(nèi)就設一個公司負責計劃、生產(chǎn)、采購、銷售

14、等運營管理最為簡便，但企業(yè)從非運營管理角度例如稅收優(yōu)惠、地方政策”等等因素考慮，有時不得不在全國各地乃至世界各地注冊若干所謂公司”以便向當?shù)卣{稅并接受其財務會計方面的監(jiān)管。EBS在一個業(yè)務實體OU下，例如 電視機管理群組”，包含了全國各地所有負責生產(chǎn)或銷售電視機的 分公司、子公司（LE）的日常業(yè)務運作，在業(yè)務運作的組織層面忽略了作為法人實體的公司信息，但在反 映業(yè)務運營最終結(jié)果的財務階段（GL），仍能夠方便地按照各地的法規(guī)要求提供財務數(shù)據(jù)與結(jié)果。而對于 負責具體業(yè)務的系統(tǒng)用戶來說，日常工作幾乎不用關(guān)心或考慮公司”的設置問題。EBS中LE的數(shù)量可以根據(jù)需要任意增加，但對于OU的數(shù)量基于管理方

15、便性則要求盡可能精簡。EBS產(chǎn)品早期在實施過程中，存在一個公司（LE）對應一個OU的做法或一個OU只能屬于一個LE的說法，這種做法或說法并不恰當。 某些國內(nèi)產(chǎn)品的設計由于未能有效區(qū)分法律實體（公司）”與業(yè)務實體（運營）兩者在系統(tǒng)中既相連接又有本質(zhì)區(qū)別的特殊關(guān)系，只好采取一個法人公司對應一個系統(tǒng)業(yè)務實體的笨辦法”，企業(yè)規(guī)模小倒還能對付，一旦規(guī)模變大，注冊公司增多，所謂的系統(tǒng)多組織架構(gòu)”就變得根本不具可用性。ORACLE EBS業(yè)務實體OU的這一系統(tǒng)特性極大地方便了企業(yè)運作的日常管理，具有高度的靈活性與可擴展性。如下圖27是R11的OU定義界面：圖中的 業(yè)務實體信息”中，必須而且只能為之設定一個

16、帳套”，即一個OU只能屬于一個帳套（反之， 一個帳套可以分配給多個OU）。要注意的是，上述業(yè)務實體信息中的法人實體設定，并不代表OU只能屬于一個LE，它只是表示在業(yè)務實體”中進行業(yè)務操作需要法人實體信息時提供默認值 （在R12中明確了 是默認值”這一點）。R12中的業(yè)務實體定義同R11基本相同，只是將帳套改為 主要分類帳”。在EBS中，一個OU可以同時指定給多個LE，上面電視機管理群組”的例子已經(jīng)說明了這一點；一 個LE也可以有多個OU，這相當于一個注冊的法人實體公司下，有多個需要獨立運營的事業(yè)部” （如X光機和電視機）。OU與LE是多對多”的關(guān)系，但有一個限制性的前提條件，即OU與LE必須屬

17、于同一個SOB或Ledger。由于LE與OU的設置在系統(tǒng)中可以獨立進行，因此如果雙方的SOB或Ledger不同，則不能建立連接關(guān)系。如果說法人實體LE與真實世界的企業(yè)行政管理組織架構(gòu)還有點關(guān)系的話，業(yè)務實體OU則是與行政管理幾乎無關(guān)，企業(yè)內(nèi)部的行政組織變化對OU的設置沒有直接影響。在EBS中有關(guān)采購管理、銷售訂單 履行、應收應付管理等業(yè)務模塊的功能均是建立在OU基礎(chǔ)之上的。用戶在執(zhí)行上述相關(guān)模塊的業(yè)務處理時，總是必須進入確定的OU（上下文環(huán)境）才可以進行，EBS的所謂多組織”功能（MOAC）也是針對多OU而言的，與真實世界中的 多公司”（LE）沒有直接關(guān)系。實際上，SAP的采購組織、銷售組織”

18、設置也是與真實世界的行政組織采購部、銷售部”無關(guān)的，ORACLE拋棄了采購組織、銷售組織”的概念，OU實際上就起到了類似的組織分隔作用。ORACLE的某些相關(guān)文檔中，如果因描述需要而提及所謂采購組織、銷售組織”等概念，有時實際指的就是業(yè)務實體OU（或OU下的庫存INV組織）。（四）庫存組織（INV）ORACLE EBS的庫存組織（INV）是系統(tǒng)組織設置的最基礎(chǔ)、也是最重要的工作之一。庫存組織 的內(nèi)涵遠不是真實世界的 倉庫部門”那么簡單， 它除了是有關(guān) 物料接收與發(fā)岀”等業(yè)務功能的基礎(chǔ)之外， 更 重要的是， 它還是EBS系統(tǒng)有關(guān)計劃 （MPS/MRP） 、 在制品管理 （WIP） 、物料清單（B

19、OM）等模塊業(yè) 務功能的操作與管理平臺。如下圖28所示：EBS中的庫存組織INV的作用與功能可以與SAP中的工廠Plant參看。一個庫存組織INV只能屬于 一個確定的帳套SOB、一個確定的法人實體LE、一個確定的業(yè)務實體OU，具有唯一性的關(guān)系（注意：R11的設置界面未考慮SOB/LE/OU的關(guān)聯(lián)限定，容易產(chǎn)生錯誤；R12作了改進，在選定Ledger之后，可用的LE/OU就被限定）。反之，一個 帳套/法人實體/業(yè)務實體”組合則可以有多個庫存組織INV。此外， 一個0U下的多個INV可以對應屬于該0U的不同LE，這相當于將分屬于兩個法人公司的生產(chǎn)兩種產(chǎn)品的 四個工廠，按相同產(chǎn)品兩兩組合抽取出來，分

20、屬于兩個不同0U進行日常業(yè)務管理。在EBS中還有兩個組織概念 “MRP組織、WIP組織”，它們實際是必須構(gòu)建于庫存組織之上的組織概 念，表示該庫存組織還可以進行MRP或WIP的功能。系統(tǒng)之所以如此處理，主要是為了控制某些INV不能做MRP或WIP而已，因為基于物料接收或發(fā)出需要所設定的INV數(shù)量可能比較多。對于絕大多數(shù)基于庫存組織INV的業(yè)務功能（個別除外），系統(tǒng)用戶在做業(yè)務操作時，均必須首先進行INV的選擇切換，以便進入確定的INV上下文環(huán)境。庫存組織的作用是如此基礎(chǔ)，以至于EBS的相關(guān)文檔在提及組織（Org）概念時，如果未作特別說明，默認就是指INV組織。（五）公司成本中心（Cost Ce

21、nter）EBS的所謂成本中心組織”并沒有業(yè)務處理的功能，它的設置主要是考慮與會計科目彈性域結(jié)構(gòu)中的 公司段值”與成本中心段值”的對應關(guān)系問題。如下圖29所示：在系統(tǒng)中創(chuàng)建 公司成本中心組織”后，可以運行一個 并發(fā)檢查程序”，以校驗 會計科目彈性域結(jié)構(gòu)” 中的段值是否與所有的公司成本中心”組織的設置保持一致。當在 會計科目彈性域結(jié)構(gòu)”中的 成本中心段”值集中添加LOV值并重新編譯后，可以運行系統(tǒng)的自動組織”并發(fā)程序功能，由系統(tǒng)自動創(chuàng)建公司成本中心”組織。應當注意的是，一個公司成本中心組織及其成本中心段值，不可能屬于不同法人實體LE及其公司段值，這與真實世界中的管理要求是一致的。庫存組織INV與

22、會計科目彈性域中的 成本中心”段（部門）則具有一對一或多對一 ”的關(guān)系，即一個成本中心”段值可以有多個庫存組織INV，但一個庫存組織INV只能 屬于一個確定的成本中心。（六）HR組織系統(tǒng)的HR組織設置是與HRM模塊的相關(guān)業(yè)務處理功能相關(guān)， 與核心業(yè)務/財務處理功能關(guān)系不大, 主要是需要注意其是否和 成本中心”關(guān)聯(lián)，需要時可以輸入 成本中心”代碼，其LOV就是 會計科目彈性域 結(jié)構(gòu)中成本中心段的值集。如下圖30所示：（七）多組織接入控制在圖30的EBS組織設置界面中，所謂的組織類型”（Type）劃分僅是基于組織自身的統(tǒng)計分析工作需要而定義的一個 維度”，例如公司總部、產(chǎn)品線”等等，并不影響系統(tǒng)的

23、業(yè)務處理功能。真正起作用的 是設置界面中的 組織分類”（Classification），系統(tǒng)預置的組織分類LOV除了上述業(yè)務組、法律實體、業(yè) 務實體、庫存組織”等之外，還有諸如 資產(chǎn)組織、運營公司、雇主”等等選項。在EBS系統(tǒng)中各應用模塊所 具有的業(yè)務處理功能通常需構(gòu)建在一個確定的組織分類”之上，組織”是相關(guān)業(yè)務處理功能的平臺，企業(yè)是否需要作相關(guān)組織分類設置、如何設置，取決于企業(yè)所需要使用到的應用模塊功能。例如所謂 資產(chǎn)組織”的設置，它是在企業(yè)需使用到資產(chǎn)管理模塊FA時才涉及到。 資產(chǎn)組織”實際上是所謂資產(chǎn)賬簿”的代名詞，它只是表示有關(guān)資產(chǎn)信息的一個數(shù)據(jù)維度，作用主要在于分隔數(shù)據(jù)范圍，用 戶進

24、入系統(tǒng)作業(yè)務處理時，并不需要作上下文業(yè)務環(huán)境的切換。對于這類并不涉及上下文環(huán)境切換的所謂組織”,ORACLR系統(tǒng)的設計主要是為了借用組織”所具有的 層次結(jié)構(gòu)”（Hierarchy）概念來達到 多組織接入”權(quán)限的控制功能。需指岀的是，這里的組織 層次結(jié)構(gòu)”與真實世界企業(yè)的行政管理組織層次結(jié)構(gòu)沒有直接關(guān)系（盡管可 能有所參考），它只是企業(yè)根據(jù)某種需要（如權(quán)限管理控制、數(shù)據(jù)統(tǒng)計匯報等）而人為設定的一個層次結(jié)構(gòu)”，例如將系統(tǒng)中已經(jīng)設置的任意數(shù)量的業(yè)務實體”或庫存組織”等等組織Name,人為地設定一個具有上下級關(guān)系、自頂向下的金字塔形多層結(jié)構(gòu)。如下圖31所示：上圖中開始定義時，一旦選定（最）頂端組織Na

25、me，則就只能為之分配下屬組織Name，如要給下 屬組織分配更下一級的組織，則需點擊 向下”按鈕，將當前該下屬組織上升到 頂端組織”位置。點擊 向上” 按鈕，則將當前 頂端組織下降到下屬組織位置。企業(yè)可以根據(jù)實際需要設定若干個具有不同內(nèi)部結(jié)構(gòu)的組織層次結(jié)構(gòu)”Name以供定義系統(tǒng)所謂 安全性配置文件”時調(diào)用。如下圖32所示：上圖所定義 安全性配置文件”是系統(tǒng)用以控制包括 組織安全性”等在內(nèi)的各種安全性控制的基礎(chǔ)，它 具體規(guī)定了系統(tǒng)安全性控制的范圍與實現(xiàn)方式，所有定義的安全性配置文件”Name構(gòu)成系統(tǒng)多組織接入控制參數(shù)“MO安全性配置文件”的LOV。如下圖33所示：EBS通過“MO業(yè)務實體”、“MO安全性配置文件”、“MO默認業(yè)務實體”這三個系統(tǒng)配置文件的 共同作用，實現(xiàn)所謂 多組織接入”控制功能MOAC。但上述三個配置文件在R11