多組織架構(gòu)概述

1、多組織架構(gòu)業(yè)務(wù)組（BG）（二）法律實體（LE）（三）業(yè)務(wù)實體（OU）（四）庫存組織（INV）（五）公司成本中心（Cost Center）（六）HR組織（七）多組織接入操縱(八)一個集團下的全資子公司才能夠設(shè)置為OU。若占百分比的，應(yīng)設(shè)置為新的帳套。在企業(yè)治理實踐的過程中，“組織”（Organization） 一詞是個經(jīng)常需用到的概念，一般與“人員”與“職能”這兩個要素緊密相關(guān)，反映某種行政治理關(guān)系，例如“財務(wù)部、銷售部、采購部、生產(chǎn)部、倉儲部”等等。 企業(yè)內(nèi)部行政組織（部門）的劃分是企業(yè)基于“職能驅(qū)動”業(yè)務(wù)治理模式進行運作的基礎(chǔ)。目前，國內(nèi)適用于小企業(yè)使用的大多數(shù)低端治理軟件并不考慮系統(tǒng)中的

2、“組織”設(shè)置問題，其系統(tǒng)應(yīng)用模塊的劃分，例如采購模塊、倉管模塊、銷售模塊等等，實際上就差不多差不多反映了企業(yè)運作的“組織職能”劃分問題。然而，關(guān)于業(yè)務(wù)復(fù)雜、規(guī)模較大的企業(yè)（如所謂“集團企業(yè)”），治理軟件使用與實施的系統(tǒng)“組織設(shè)置”問題將是一個首要的重要問題。一個常見的、也是錯誤的系統(tǒng)實現(xiàn)方式確實是將企業(yè)的“行政組織設(shè)置”直接映射到系統(tǒng)中，以“行政組織”代替“業(yè)務(wù)組織”。這種系統(tǒng)實現(xiàn)方式雖有理解、掌握比較容易的優(yōu)勢，但卻完全違背了大企業(yè)運作必須基于“流程驅(qū)動”業(yè)務(wù)模式的差不多治理原則。國內(nèi)有所謂高端治理軟件在系統(tǒng)實施過程中，常常出現(xiàn)有幾十個財務(wù)、采購組織，幾百個銷售組織，乃至上千個庫存組織的“盛

3、況”，導(dǎo)致系統(tǒng)幾乎沒法使用的困境，其癥結(jié)正在于此。與企業(yè)的“行政組織”設(shè)置與人員規(guī)模緊密相關(guān)且復(fù)雜多變不同，軟件系統(tǒng)的“組織設(shè)置”必須以業(yè)務(wù)流程運作為核心，要求盡可能簡單并保持相對穩(wěn)定，在公司（人員）規(guī)模擴大的過程中具有連續(xù)性與繼承性。作為ERP鼻祖的SAP將系統(tǒng)組織簡單地分為“集團（Client）、公司代碼（Company Code）、采購組織（Purchase Org）、銷售組織（Sale Org）、工廠（Plant）”等類不。ORACLE的組織設(shè)置本質(zhì)上與之差不多相似，但作為后來者作了進一步抽象與簡化，系統(tǒng)組織劃分為“業(yè)務(wù)組（Business Group）、法律實體（Legal Enti

4、ty）、業(yè)務(wù)實體（Operating Unit）、庫存組織（Inventory Org）”等。假如講SAP的組織模型字面上多少還帶有一點“行政組織”痕跡的話（這可能是某些聲稱學(xué)SAP的國內(nèi)產(chǎn)品誤入歧途的緣故），ORACLE系統(tǒng)的組織模型字面上差不多幾乎看不出與“行政組織”還有什么關(guān)系，其中的“Inventory Org”現(xiàn)今中文翻譯成“庫存組織”，容易令人望文生義和企業(yè)的“倉庫治理部門（Warehouse）”混淆，但Inventory的本義實際應(yīng)該是“存貨”，稱之為“存貨組織”或許更好一些。如下圖22所示ORACLE系統(tǒng)有關(guān)核心業(yè)務(wù)的多組織模型：上圖中的“財務(wù)、銷售、采購”并非系統(tǒng)的“組織實體

5、”，它僅表示業(yè)務(wù)實體（OU）具有的相關(guān)業(yè)務(wù)處理功能?！白訋臁笔菍ｉT的系統(tǒng)組織實體，沒有上下文環(huán)境可進入，要緊表示庫存組織之下的某種業(yè)務(wù)功能。（一）業(yè)務(wù)組（BG） “業(yè)務(wù)組”的概念能夠與企業(yè)的“集團”概念參看，但不同的是一個企業(yè)在系統(tǒng)中能夠設(shè)置多個“業(yè)務(wù)組（集團）”。通常關(guān)于一個企業(yè)來講，系統(tǒng)中有一個“業(yè)務(wù)組” 就夠了，這表示企業(yè)確實是一個“集團公司”。而關(guān)于某些業(yè)務(wù)“多元化”的特大型公司（如跨國公司），則可能需要在系統(tǒng)中設(shè)置多個“業(yè)務(wù)組”，表示企業(yè)由多個 “集團公司”組成。業(yè)務(wù)組設(shè)置是系統(tǒng)組織設(shè)置的第一步，是最高層級的組織形態(tài)，但它要緊是與人力資源信息的分隔有關(guān)，即“人員信息”的設(shè)置在一個BG

6、范圍內(nèi)是由各業(yè)務(wù)模塊共享的（假如需要）。一旦系統(tǒng)設(shè)置的用戶名（User）被與“人員”（Employee）關(guān)聯(lián)，不管使用什么“責(zé)任”進入系統(tǒng)，都會定位至一個確定的BG中，任何責(zé)任在任意時刻只能關(guān)聯(lián)一個BG。EBS安裝好后，系統(tǒng)里面差不多預(yù)置了一個名為“Setup Business Group”的“初始業(yè)務(wù)組”。如圖23所示系統(tǒng)預(yù)置的“Setup Business Group”：當(dāng)以系統(tǒng)預(yù)置超級用戶SYSADMIN進入后，應(yīng)首先設(shè)置一個具有在HRM或INV下創(chuàng)建組織功能的“責(zé)任”名，隨后給此責(zé)任的“HR：User Type”配置文件設(shè)定值為“HR User”，則該責(zé)任就有了創(chuàng)建新BG的能力。通常需

7、要一次性將企業(yè)所需要的BG全部建立，一般另創(chuàng)建一個與企業(yè)名稱一致如“某某集團”的新BG就能夠了，也能夠（不推舉）直接使用系統(tǒng)預(yù)設(shè)的“Setup Business Group”而不創(chuàng)建新BG。系統(tǒng)每新建一個BG，就會自動在配置文件“HR：安全性配置文件”的LOV中自動添加一個與新建BG同名的可選值（初始時只有“Setup Business Group”一個值）。在某一個BG下（初始為Setup Business Group）新建的任何責(zé)任，系統(tǒng)都將該責(zé)任的配置文件“HR：安全性配置文件”值默認(rèn)為當(dāng)前BG。要在進入系統(tǒng)時能切換到新的BG，必須先修改該責(zé)任的“HR：安全性配置文件”設(shè)定值。假如將配置

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

9、R12中，LE的組織定義雖在FORM中仍然保留，但LE的“法人主體會計科目”的FORM設(shè)置被廢棄（故FORM中定義了也無用），改為在定義“分類帳”時的“會計科目設(shè)置治理器”WEB中定義并分配法人實體LE。一個分類帳設(shè)置（主輔分類帳）能夠添加多個LE，但每個LE只能具有一個分類帳設(shè)置。如下圖25所示：在R12中，還必須為法人實體分配會計科目彈性域結(jié)構(gòu)的公司段即平衡段值。每個LE能夠分配多個“平衡段”值，公司段值集中每個段值一旦被分配給某LE，則其它LE就不能再被分配。在R11或R12中創(chuàng)建一個LE后，應(yīng)當(dāng)及時到會計科目彈性域結(jié)構(gòu)中添加需要對應(yīng)的公司段值LOV（一個或多個），并重新進行彈性域的編譯

10、，否則系統(tǒng)可能會彈出錯誤報警信息。R12中一個LE對應(yīng)多個公司平衡段值，代表有多個分公司，LE是它們的合并。主輔分類帳可擁有相同或不同的公司段值集，表示從不同的維度（如按地區(qū)、按產(chǎn)品等）去劃分公司以方便考核。如圖26所示為LE添加平衡段值：不管是R11依舊R12，法律實體LE的設(shè)置都對具體的業(yè)務(wù)處理阻礙不大，其與系統(tǒng)用戶或責(zé)任不關(guān)聯(lián)，不直接阻礙系統(tǒng)上下文的切換，故有人甚至認(rèn)為EBS的LE設(shè)置作用不大。這關(guān)于系統(tǒng)的內(nèi)部運作來講情況確實近似如此，但關(guān)于需要通過系統(tǒng)產(chǎn)生供外部使用的具有法律意義的文書（如采購訂單、財務(wù)報表等等），嚴(yán)格區(qū)分法律實體LE依舊必須的。R12顯然更多地考慮了外部使用的這種法律

11、要求（即所謂“法規(guī)遵從性”或“合規(guī)性”），并在相關(guān)業(yè)務(wù)應(yīng)用模塊中有所體現(xiàn)。（三）業(yè)務(wù)實體（OU）業(yè)務(wù)實體（OU，Operating Unit）是EBS系統(tǒng)組織設(shè)置的重點也是難點之一。它與法人主體LE本身沒有必定的關(guān)系，與會計科目彈性域結(jié)構(gòu)中的“公司段”也沒有直接關(guān)系。從企業(yè)實際業(yè)務(wù)治理需要的角度去看，業(yè)務(wù)實體OU能夠看作是在系統(tǒng)中按照業(yè)務(wù)的相似性，把多個不同公司（包括LE）的業(yè)務(wù)處理過程及數(shù)據(jù)劃分成相對獨立的“治理單元”。在每個治理單元內(nèi)部，各公司的業(yè)務(wù)運作共享相關(guān)數(shù)據(jù)并執(zhí)行統(tǒng)一的業(yè)務(wù)策略。例如，有一個業(yè)務(wù)多元化的企業(yè)既生產(chǎn)醫(yī)院使用的X光機也生產(chǎn)一般電視機，同時其下屬在全國各地有多家生產(chǎn)X光機

12、或電視機的分公司、子公司。由于這兩種產(chǎn)品所使用的物料、供應(yīng)商以及針對的客戶群差異專門大，企業(yè)為方便治理，能夠?qū)ⅰ皹I(yè)務(wù)運營”劃分為兩個相對獨立的“業(yè)務(wù)治理群組”，對應(yīng)到EBS系統(tǒng)中確實是兩個業(yè)務(wù)實體OU。從企業(yè)日常業(yè)務(wù)運作治理的角度來看，關(guān)于單純的電視機業(yè)務(wù)，全國范圍內(nèi)就設(shè)一個公司負責(zé)打算、生產(chǎn)、采購、銷售等運營治理最為簡便，但企業(yè)從非運營治理角度 例如“稅收優(yōu)惠、地點政策”等等因素考慮，有時不得不在全國各地乃至世界各地注冊若干所謂“公司”，以便向當(dāng)?shù)卣{稅并同意其財務(wù)會計方面的監(jiān)管。EBS在一個業(yè)務(wù)實體OU下，例如“電視機治理群組”，包含了全國各地所有負責(zé)生產(chǎn)或銷售電視機的分公司、子公司（L

13、E）的日常業(yè)務(wù)運作，在業(yè)務(wù)運作的組織層面忽略了作為法人實體的公司信息，但在反映業(yè)務(wù)運營最終結(jié)果的財務(wù)時期（GL），仍能夠方便地按照各地的法規(guī)要求提供財務(wù)數(shù)據(jù)與結(jié)果。而關(guān)于負責(zé)具體業(yè)務(wù)的系統(tǒng)用戶來講，日常工作幾乎不用關(guān)懷或考慮“公司”的設(shè)置問題。EBS中LE的數(shù)量能夠依照需要任意增加，但關(guān)于OU的數(shù)量基于治理方便性則要求盡可能精簡。EBS產(chǎn)品早期在實施過程中，存在一個公司（LE）對應(yīng)一個OU的做法或一個OU只能屬于一個LE的講法，這種做法或講法并不恰當(dāng)。某些國內(nèi)產(chǎn)品的設(shè)計由于未能有效區(qū)分“法律實體（公司）”與“業(yè)務(wù)實體（運營）”兩者在系統(tǒng)中既相連接又有本質(zhì)區(qū)不的專門關(guān)系，只好采取一個法人公司對應(yīng)

14、一個系統(tǒng)業(yè)務(wù)實體的“笨方法”，企業(yè)規(guī)模小倒還能應(yīng)付，一旦規(guī)模變大，注冊公司增多，所謂的“系統(tǒng)多組織架構(gòu)”就變得全然不具可用性。ORACLE EBS業(yè)務(wù)實體OU的這一系統(tǒng)特性極大地點便了企業(yè)運作的日常治理，具有高度的靈活性與可擴展性。如下圖27是R11的OU定義界面：圖中的“業(yè)務(wù)實體信息”中，必須而且只能為之設(shè)定一個“帳套”，即一個OU只能屬于一個帳套（反之，一個帳套能夠分配給多個OU）。要注意的是，上述業(yè)務(wù)實體信息中的法人實體設(shè)定，并不代表OU只能屬于一個LE，它只是表示在“業(yè)務(wù)實體”中進行業(yè)務(wù)操作需要法人實體信息時提供默認(rèn)值（在R12中明確了是“默認(rèn)值”這一點）。R12中的業(yè)務(wù)實體定義同R1

15、1差不多相同，只是將帳套改為“要緊分類帳”。在EBS中，一個OU能夠同時指定給多個LE，上面“電視機治理群組”的例子差不多講明了這一點；一個LE也能夠有多個OU，這相當(dāng)于一個注冊的法人實體公司下，有多個需要獨立運營的“事業(yè)部”（如X光機和電視機）。OU與LE是“多對多”的關(guān)系，但有一個限制性的前提條件，即OU與LE必須屬于同一個SOB或Ledger。由于LE與OU的設(shè)置在系統(tǒng)中能夠獨立進行，因此假如雙方的SOB或Ledger不同，則不能建立連接關(guān)系。假如講法人實體LE與真實世界的企業(yè)行政治理組織架構(gòu)還有點關(guān)系的話，業(yè)務(wù)實體OU則是與行政治理幾乎無關(guān)，企業(yè)內(nèi)部的行政組織變化對OU的設(shè)置沒有直接阻

16、礙。在EBS中有關(guān)采購治理、銷售訂單履行、應(yīng)收應(yīng)付治理等業(yè)務(wù)模塊的功能均是建立在OU基礎(chǔ)之上的。用戶在執(zhí)行上述相關(guān)模塊的業(yè)務(wù)處理時，總是必須進入確定的OU（上下文環(huán)境）才能夠進行，EBS的所謂“多組織”功能（MOAC）也是針對多OU而言的，與真實世界中的“多公司”（LE）沒有直接關(guān)系。實際上，SAP的“采購組織、銷售組織”設(shè)置也是與真實世界的行政組織“采購部、銷售部”無關(guān)的，ORACLE拋棄了“采購組織、銷售組織”的概念，OU實際上就起到了類似的組織分隔作用。ORACLE的某些相關(guān)文檔中，假如因描述需要而提及所謂“采購組織、銷售組織”等概念，有時實際指的確實是業(yè)務(wù)實體OU（或OU下的庫存INV

17、組織）。（四）庫存組織（INV） ORACLE EBS的庫存組織（INV）是系統(tǒng)組織設(shè)置的最基礎(chǔ)、也是最重要的工作之一。庫存組織的內(nèi)涵遠不是真實世界的“倉庫部門”那么簡單，它除了是有關(guān)“物料接收與發(fā)出”等業(yè)務(wù)功能的基礎(chǔ)之外，更重要的是，它依舊EBS系統(tǒng)有關(guān)打算（MPS/MRP）、在制品治理（WIP）、物料清單（BOM）等模塊業(yè)務(wù)功能的操作與治理平臺。如下圖28所示：EBS中的庫存組織INV的作用與功能能夠與SAP中的工廠Plant參看。一個庫存組織INV只能屬于一個確定的帳套SOB、一個確定的法人實體LE、一個確定的業(yè)務(wù)實體OU，具有唯一性的關(guān)系（注意：R11的設(shè)置界面未考慮SOB/LE/OU

18、的關(guān)聯(lián)限定，容易產(chǎn)生錯誤；R12作了改進，在選定Ledger之后，可用的LE/OU就被限定）。反之，一個“帳套/法人實體/業(yè)務(wù)實體”組合則能夠有多個庫存組織INV。此外，一個OU下的多個INV能夠?qū)?yīng)屬于該OU的不同LE，這相當(dāng)于將分屬于兩個法人公司的生產(chǎn)兩種產(chǎn)品的四個工廠，按相同產(chǎn)品兩兩組合抽取出來，分屬于兩個不同OU進行日常業(yè)務(wù)治理。在EBS中還有兩個組織概念“MRP組織、WIP組織”，它們實際是必須構(gòu)建于庫存組織之上的組織概念，表示該庫存組織還能夠進行MRP或WIP的功能。系統(tǒng)之因此如此處理，要緊是為了操縱某些INV不能做MRP或WIP而已，因為基于物料接收或發(fā)出需要所設(shè)定的INV數(shù)量可

19、能比較多。關(guān)于絕大多數(shù)基于庫存組織INV的業(yè)務(wù)功能（個不除外），系統(tǒng)用戶在做業(yè)務(wù)操作時，均必須首先進行INV的選擇切換，以便進入確定的INV上下文環(huán)境。庫存組織的作用是如此基礎(chǔ)，以至于EBS的相關(guān)文檔在提及組織（Org）概念時，假如未作特不講明，默認(rèn)確實是指INV組織。（五）公司成本中心（Cost Center）EBS的所謂“成本中心組織”并沒有業(yè)務(wù)處理的功能，它的設(shè)置要緊是考慮與“會計科目彈性域結(jié)構(gòu)”中的“公司段值”與“成本中心段值”的對應(yīng)關(guān)系問題。如下圖29所示：在系統(tǒng)中創(chuàng)建“公司成本中心組織”后，能夠運行一個“并發(fā)檢查程序”，以校驗“會計科目彈性域結(jié)構(gòu)”中的段值是否與所有的“公司成本中心

20、”組織的設(shè)置保持一致。當(dāng)在“會計科目彈性域結(jié)構(gòu)”中的“成本中心段”值集中添加LOV值并重新編譯后，能夠運行系統(tǒng)的“自動組織”并發(fā)程序功能，由系統(tǒng)自動創(chuàng)建“公司成本中心”組織。應(yīng)當(dāng)注意的是，一個公司成本中心組織及其成本中心段值，不可能屬于不同法人實體LE及其公司段值，這與真實世界中的治理要求是一致的。庫存組織INV與會計科目彈性域中的“成本中心”段（部門）則具有“一對一或多對一”的關(guān)系，即一個“成本中心”段值能夠有多個庫存組織INV，但一個庫存組織INV只能屬于一個確定的成本中心。（六）HR組織 系統(tǒng)的HR組織設(shè)置是與HRM模塊的相關(guān)業(yè)務(wù)處理功能相關(guān)，與核心業(yè)務(wù)/財務(wù)處理功能關(guān)系不大，要緊是需要

21、注意其是否和“成本中心”關(guān)聯(lián)，需要時能夠輸入“成本中心”代碼，其LOV確實是“會計科目彈性域”結(jié)構(gòu)中成本中心段的值集。如下圖30所示：（七）多組織接入操縱在圖30的EBS組織設(shè)置界面中，所謂的組織“類型”（Type）劃分僅是基于組織自身的統(tǒng)計分析工作需要而定義的一個“維度”，例如“公司總部、產(chǎn)品線”等等，并不阻礙系統(tǒng)的業(yè)務(wù)處理功能。真正起作用的是設(shè)置界面中的“組織分類”（Classification），系統(tǒng)預(yù)置的組織分類LOV除了上述“業(yè)務(wù)組、法律實體、業(yè)務(wù)實體、庫存組織”等之外，還有諸如“資產(chǎn)組織、運營公司、雇主”等等選項。在EBS系統(tǒng)中各應(yīng)用模塊所具有的業(yè)務(wù)處理功能通常需構(gòu)建在一個確定的“

22、組織分類”之上，“組織”是相關(guān)業(yè)務(wù)處理功能的平臺，企業(yè)是否需要作相關(guān)組織分類設(shè)置、如何設(shè)置，取決于企業(yè)所需要使用到的應(yīng)用模塊功能。例如所謂“資產(chǎn)組織”的設(shè)置，它是在企業(yè)需使用到資產(chǎn)治理模塊FA時才涉及到?！百Y產(chǎn)組織”實際上是所謂“資產(chǎn)賬簿”的代名詞，它只是表示有關(guān)資產(chǎn)信息的一個數(shù)據(jù)維度，作用要緊在于分隔數(shù)據(jù)范圍，用戶進入系統(tǒng)作業(yè)務(wù)處理時，并不需要作上下文業(yè)務(wù)環(huán)境的切換。關(guān)于這類并不涉及“上下文”環(huán)境切換的所謂“組織”，ORACLR系統(tǒng)的設(shè)計要緊是為了借用“組織”所具有的“層次結(jié)構(gòu)”（Hierarchy）概念來達到“多組織接入”權(quán)限的操縱功能。需指出的是，那個地點的組織“層次結(jié)構(gòu)”與真實世界企業(yè)

23、的行政治理組織層次結(jié)構(gòu)沒有直接關(guān)系（盡管可能有所參考），它只是企業(yè)依照某種需要（如權(quán)限治理操縱、數(shù)據(jù)統(tǒng)計匯報等）而人為設(shè)定的一個“層次結(jié)構(gòu)”，例如將系統(tǒng)中差不多設(shè)置的任意數(shù)量的“業(yè)務(wù)實體”或“庫存組織”等等組織Name，人為地設(shè)定一個具有上下級關(guān)系、自頂向下的金字塔形多層結(jié)構(gòu)。如下圖31所示：上圖中開始定義時，一旦選定（最）頂端組織Name，則就只能為之分配下屬組織Name，如要給下屬組織分配更下一級的組織，則需點擊“向下”按鈕，將當(dāng)前該下屬組織上升到“頂端組織”位置。點擊“向上”按鈕，則將當(dāng)前“頂端組織”下降到下屬組織位置。企業(yè)能夠依照實際需要設(shè)定若干個具有不同內(nèi)部結(jié)構(gòu)的“組織層次結(jié)構(gòu)”Na

24、me，以供定義系統(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è)務(wù)實體”、“MO：安全性配置文件”、“MO：默認(rèn)業(yè)務(wù)實體”這三個系統(tǒng)配置文件的共同作用，實現(xiàn)所謂“多組織接入”操縱功能MOAC。但上述三個配置文件在R11與R12中的作用有比較大的差不。關(guān)于“MO：業(yè)務(wù)實體”， 在R11中必須設(shè)定，而且起決定性操縱作用，其LOV由系統(tǒng)

25、基于創(chuàng)建的OU name自動創(chuàng)建，用戶登錄時系統(tǒng)自動定位于指定OU。而在R12中，一旦設(shè)定“MO：安全性配置文件”，則此配置文件失效而不起作用。關(guān)于“MO：安全性配置文件”， 在R11中雖有，但實際不起OU接入的操縱作用，只針對FA等模塊的得某些應(yīng)用如數(shù)據(jù)統(tǒng)計等起作用。因此，一般認(rèn)為R11并不具有完善的多組織接入操縱功能。在R12中，該參數(shù)假如不設(shè)定，則必須設(shè)定“MO：業(yè)務(wù)實體”參數(shù)；一旦該參數(shù)被設(shè)定，則就起決定作用，系統(tǒng)要緊依靠事實上現(xiàn)MOAC。關(guān)于“MO：默認(rèn)業(yè)務(wù)實體”， 在R11中雖有但實際不起作用。在R12中，隨“MO：安全配置文件”起作用后才起作用，其LOV是所有已定義OU，但假如設(shè)

26、定值不在“MO：安全配置文件”所選擇的“組織層次架構(gòu)”的范圍內(nèi)，則仍不起作用（即在與OU相關(guān)諸如PO、OM等的FORM界面，OU字段的默認(rèn)值仍然為空）。這大概是ORACLE 系統(tǒng)設(shè)計方面的一個難題，即“MO：默認(rèn)業(yè)務(wù)實體”的LOV值集無法與“MO：安全性配置文件”中“組織層次架構(gòu)”中的OU值范圍保持一致。ORACLE強調(diào)其“多組織接入MOAC”功能要緊是針對業(yè)務(wù)實體OU而言，其另外一層含義是，所有構(gòu)建于庫存組織INV上的應(yīng)用功能，實際是與上述配置文件無關(guān)的。庫存組織的可接入性是在“組織訪問”操縱功能中，專門設(shè)定“庫存組織”與“責(zé)任”的關(guān)聯(lián)性，如下圖34所示：按照ORACLE的講法，假如系統(tǒng)在初

27、始的時候，不定義庫存組織的“組織訪問”操縱，則所有“責(zé)任”可訪問所有INV，一旦限制或分配其中一個，則其余均必須逐個進行分配以建立“庫存組織”與“責(zé)任”的鏈接關(guān)系?？傊?，EBS系統(tǒng)通過“彈性域段值安全性”、“帳套/分類帳安全性”、“多組織接入安全性（MOAC）”、“庫存組織訪問操縱”等多維度、多方面的組合系統(tǒng)設(shè)置，提供了靈活、方便的用戶權(quán)限治理功能，厘清并掌握它們的復(fù)雜關(guān)系是系統(tǒng)實施的一項重要基礎(chǔ)性工作。（一）業(yè)務(wù)組（BG）（二）法律實體（LE）（三）業(yè)務(wù)實體（OU）（四）庫存組織（INV）（五）公司成本中心（Cost Center）（六）HR組織（七）多組織接入操縱在企業(yè)治理實踐的過程中，“

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

29、是錯誤的系 統(tǒng)實現(xiàn)方式確實是將企業(yè)的“行政組織設(shè)置”直接映射到系統(tǒng)中，以“行政組織”代替“業(yè)務(wù)組織”。這種系統(tǒng)實現(xiàn)方式雖有理解、掌握比較容易的優(yōu)勢，但卻完全違 背了大企業(yè)運作必須基于“流程驅(qū)動”業(yè)務(wù)模式的差不多治理原則。國內(nèi)有所謂高端治理軟件在系統(tǒng)實施過程中，常常出現(xiàn)有幾十個財務(wù)、采購組織，幾百個銷售組 織，乃至上千個庫存組織的“盛況”，導(dǎo)致系統(tǒng)幾乎沒法使用的困境，其癥結(jié)正在于此。與企業(yè)的“行政組織”設(shè)置與人員規(guī)模緊密相關(guān)且復(fù)雜多變不同，軟件系統(tǒng)的“組織設(shè)置”必須以業(yè)務(wù)流程運作為核心，要求盡可能簡單并保持相對穩(wěn)定，在公司（人員）規(guī)模擴大的過程中具有連續(xù)性與繼承性。作為ERP鼻祖的SAP將系統(tǒng)組

30、織簡單地分為“集團（Client）、公司代碼（Company Code）、采購組織（Purchase Org）、銷售組織（Sale Org）、工廠（Plant）”等類不。ORACLE的組織設(shè)置本質(zhì)上與之差不多相似，但作為后來者作了進一步抽象與簡化，系統(tǒng)組織劃分為“業(yè)務(wù)組（Business Group）、法律實體（Legal Entity）、業(yè)務(wù)實體（Operating Unit）、庫存組織（Inventory Org）”等。假如講SAP的組織模型字面上多少還帶有一點“行政組織”痕跡的話（這可能是某些聲稱學(xué)SAP的國內(nèi)產(chǎn)品誤入歧途的緣故），ORACLE系統(tǒng)的組織模型字面上差不多幾乎看不出與“行政

31、組織”還有什么關(guān)系，其中的“Inventory Org”現(xiàn)今中文翻譯成“庫存組織”，容易令人望文生義和企業(yè)的“倉庫治理部門（Warehouse）”混淆，但Inventory的本義實際應(yīng)該是“存貨”，稱之為“存貨組織”或許更好一些。如下圖22所示ORACLE系統(tǒng)有關(guān)核心業(yè)務(wù)的多組織模型：上圖中的“財務(wù)、銷售、采購”并非系統(tǒng)的“組織實體”，它僅表示業(yè)務(wù)實體（OU）具有的相關(guān)業(yè)務(wù)處理功能?！白訋臁笔菍ｉT的系統(tǒng)組織實體，沒有上下文環(huán)境可進入，要緊表示庫存組織之下的某種業(yè)務(wù)功能。（一）業(yè)務(wù)組（BG） “業(yè) 務(wù)組”的概念能夠與企業(yè)的“集團”概念參看，但不同的是一個企業(yè)在系統(tǒng)中能夠設(shè)置多個“業(yè)務(wù)組（集團）”

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

33、usiness Group”的“初始業(yè)務(wù)組”。如圖23所示系統(tǒng)預(yù)置的“Setup Business Group”：當(dāng)以系統(tǒng)預(yù)置超級用戶SYSADMIN進入后，應(yīng)首先設(shè)置一個具有在HRM或INV下創(chuàng)建組織功能的“責(zé)任”名，隨后給此責(zé)任的“HR：User Type”配置文件設(shè)定值為“HR User”，則該責(zé)任就有了創(chuàng)建新BG的能力。通常需要一次性將企業(yè)所需要的BG全部建立，一般另創(chuàng)建一個與企業(yè)名稱一致如“某某集團”的新BG就能夠了，也能夠（不推舉）直接使用系統(tǒng)預(yù)設(shè)的“Setup Business Group”而不創(chuàng)建新BG。系統(tǒng)每新建一個BG，就會自動在配置文件“HR：安全性配置文件”的LOV中自

34、動添加一個與新建BG同名的可選值（初始時只有“Setup Business Group”一個值）。在某一個BG下（初始為Setup Business Group）新建的任何責(zé)任，系統(tǒng)都將該責(zé)任的配置文件“HR：安全性配置文件”值默認(rèn)為當(dāng)前BG。要在進入系統(tǒng)時能切換到新的BG，必須先修改該責(zé)任的“HR：安全性配置文件”設(shè)定值。假如將配置文件“HR：交叉業(yè)務(wù)組”的值設(shè)為“是”，則在不同BG下，新建的組織名稱應(yīng)當(dāng)（盡管能夠）不同，否則查看時可能會引起混淆。在同一個BG下的所有新建組織，名稱不同意相同。（二）法律實體（LE） 法律實體（LE，Legal Entity）對應(yīng)于真實世界中的按國家法律法規(guī)要

35、求注冊的“法人公司”。在R11中，LE在組織FORM定義時，關(guān)于每個LE必須為其“法人主體會計科目”關(guān)聯(lián)一個“帳套SOB”。每個LE對應(yīng)一個SOB，這與真實世界的法規(guī)要求是吻合的。如下圖24所示：要注意的是，在R11中定義的LE時，并未作與“會計科目彈性域結(jié)構(gòu)”的“公司段”值關(guān)聯(lián)，用戶必須關(guān)于其是與公司段值中的哪個值對應(yīng)心中有數(shù)。而在R12中，LE的組織定義雖在FORM中仍然保留，但LE的“法人主體會計科目”的FORM設(shè)置被廢棄（故FORM中定義了也無用），改為在定義“分類帳”時的“會計科目設(shè)置治理器”WEB中定義并分配法人實體LE。一個分類帳設(shè)置（主輔分類帳）能夠添加多個LE，但每個LE只能

36、具有一個分類帳設(shè)置。如下圖25所示：在R12中，還必須為法人實體分配會計科目彈性域結(jié)構(gòu)的公司段即平衡段值。每個LE能夠分配多個“平衡段”值，公司段值集中每個段值一旦被分配給某LE，則其它LE就不能再被分配。在R11或R12中創(chuàng)建一個LE后，應(yīng)當(dāng)及時到會計科目彈性域結(jié)構(gòu)中添加需要對應(yīng)的公司段值LOV（一個或多個），并重新進行彈性域的編譯，否則系統(tǒng)可能會彈出錯誤報警信息。R12中一個LE對應(yīng)多個公司平衡段值，代表有多個分公司，LE是它們的合并。主輔分類帳可擁有相同或不同的公司段值集，表示從不同的維度（如按地區(qū)、按產(chǎn)品等）去劃分公司以方便考核。如圖26所示為LE添加平衡段值：不管是R11依舊R12，

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

38、系。從企業(yè)實際業(yè)務(wù)治理需要的角度去看，業(yè)務(wù)實體OU能夠看作是在系統(tǒng)中按照業(yè)務(wù)的相似性，把多個不同公司（包括LE）的業(yè)務(wù)處理過程及數(shù)據(jù)劃分成相對獨立的“治理單元”。在每個治理單元內(nèi)部，各公司的業(yè)務(wù)運作共享相關(guān)數(shù)據(jù)并執(zhí)行統(tǒng)一的業(yè)務(wù)策略。例如，有一個業(yè)務(wù)多元化的企業(yè)既生產(chǎn)醫(yī)院使用的X光機也生產(chǎn)一般電視機，同時其下屬在全國各地有多家生產(chǎn)X光機或電視機的分公司、子公司。由于這兩種產(chǎn)品所使用的物料、供應(yīng)商以及針對的客戶群差異專門大，企業(yè)為方便治理，能夠?qū)ⅰ皹I(yè)務(wù)運營”劃分為兩個相對獨立的“業(yè)務(wù)治理群組”，對應(yīng)到EBS系統(tǒng)中確實是兩個業(yè)務(wù)實體OU。從 企業(yè)日常業(yè)務(wù)運作治理的角度來看，關(guān)于單純的電視機業(yè)務(wù)，全國

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

40、能夠依照需要任意增加，但關(guān)于OU的數(shù)量基于治理方便性則要求盡可能精簡。EBS產(chǎn)品早期在實施過程中，存在一個公司（LE）對應(yīng)一個OU的做法或一個OU只能屬于一個LE的 講法，這種做法或講法并不恰當(dāng)。某些國內(nèi)產(chǎn)品的設(shè)計由于未能有效區(qū)分“法律實體（公司）”與“業(yè)務(wù)實體（運營）”兩者在系統(tǒng)中既相連接又有本質(zhì)區(qū)不的專門 關(guān)系，只好采取一個法人公司對應(yīng)一個系統(tǒng)業(yè)務(wù)實體的“笨方法”，企業(yè)規(guī)模小倒還能應(yīng)付，一旦規(guī)模變大，注冊公司增多，所謂的“系統(tǒng)多組織架構(gòu)”就變得全然 不具可用性。ORACLE EBS業(yè)務(wù)實體OU的這一系統(tǒng)特性極大地點便了企業(yè)運作的日常治理，具有高度的靈活性與可擴展性。如下圖27是R11的OU

41、定義界面：圖中的“業(yè)務(wù)實體信息”中，必須而且只能為之設(shè)定一個“帳套”，即一個OU只能屬于一個帳套（反之，一個帳套能夠分配給多個OU）。要注意的是，上述業(yè)務(wù)實體信息中的法人實體設(shè)定，并不代表OU只能屬于一個LE，它只是表示在“業(yè)務(wù)實體”中進行業(yè)務(wù)操作需要法人實體信息時提供默認(rèn)值（在R12中明確了是“默認(rèn)值”這一點）。R12中的業(yè)務(wù)實體定義同R11差不多相同，只是將帳套改為“要緊分類帳”。在EBS中，一個OU能夠同時指定給多個LE，上面“電視機治理群組”的例子差不多講明了這一點；一個LE也能夠有多個OU，這相當(dāng)于一個注冊的法人實體公司下，有多個需要獨立運營的“事業(yè)部”（如X光機和電視機）。OU與L

42、E是“多對多”的關(guān)系，但有一個限制性的前提條件，即OU與LE必須屬于同一個SOB或Ledger。由于LE與OU的設(shè)置在系統(tǒng)中能夠獨立進行，因此假如雙方的SOB或Ledger不同，則不能建立連接關(guān)系。假如講法人實體LE與真實世界的企業(yè)行政治理組織架構(gòu)還有點關(guān)系的話，業(yè)務(wù)實體OU則是與行政治理幾乎無關(guān)，企業(yè)內(nèi)部的行政組織變化對OU的設(shè)置沒有直接阻礙。在EBS中有關(guān)采購治理、銷售訂單履行、應(yīng)收應(yīng)付治理等業(yè)務(wù)模塊的功能均是建立在OU基礎(chǔ)之上的。用戶在執(zhí)行上述相關(guān)模塊的業(yè)務(wù)處理時，總是必須進入確定的OU（上下文環(huán)境）才能夠進行，EBS的所謂“多組織”功能（MOAC）也是針對多OU而言的，與真實世界中的“

43、多公司”（LE）沒有直接關(guān)系。實際上，SAP的“采購組織、銷售組織”設(shè)置也是與真實世界的行政組織“采購部、銷售部”無關(guān)的，ORACLE拋棄了“采購組織、銷售組織”的概念，OU實際上就起到了類似的組織分隔作用。ORACLE的某些相關(guān)文檔中，假如因描述需要而提及所謂“采購組織、銷售組織”等概念，有時實際指的確實是業(yè)務(wù)實體OU（或OU下的庫存INV組織）。（四）庫存組織（INV） ORACLE EBS的庫存組織（INV）是系統(tǒng)組織設(shè)置的最基礎(chǔ)、也是最重要的工作之一。庫存組織的內(nèi)涵遠不是真實世界的“倉庫部門”那么簡單，它除了是有關(guān)“物料接收與發(fā)出”等業(yè)務(wù)功能的基礎(chǔ)之外，更重要的是，它依舊EBS系統(tǒng)有關(guān)

44、打算（MPS/MRP）、在制品治理（WIP）、物料清單（BOM）等模塊業(yè)務(wù)功能的操作與治理平臺。如下圖28所示：EBS中的庫存組織INV的作用與功能能夠與SAP中的工廠Plant參看。一個庫存組織INV只能屬于一個確定的帳套SOB、一個確定的法人實體LE、一個確定的業(yè)務(wù)實體OU，具有唯一性的關(guān)系（注意：R11的設(shè)置界面未考慮SOB/LE/OU的關(guān)聯(lián)限定，容易產(chǎn)生錯誤；R12作了改進，在選定Ledger之后，可用的LE/OU就被限定）。反之，一個“帳套/法人實體/業(yè)務(wù)實體”組合則能夠有多個庫存組織INV。此外，一個OU下的多個INV能夠?qū)?yīng)屬于該OU的不同LE，這相當(dāng)于將分屬于兩個法人公司的生產(chǎn)

45、兩種產(chǎn)品的四個工廠，按相同產(chǎn)品兩兩組合抽取出來，分屬于兩個不同OU進行日常業(yè)務(wù)治理。在EBS中還有兩個組織概念“MRP組織、WIP組織”，它們實際是必須構(gòu)建于庫存組織之上的組織概念，表示該庫存組織還能夠進行MRP或WIP的功能。系統(tǒng)之因此如此處理，要緊是為了操縱某些INV不能做MRP或WIP而已，因為基于物料接收或發(fā)出需要所設(shè)定的INV數(shù)量可能比較多。關(guān)于絕大多數(shù)基于庫存組織INV的業(yè)務(wù)功能（個不除外），系統(tǒng)用戶在做業(yè)務(wù)操作時，均必須首先進行INV的選擇切換，以便進入確定的INV上下文環(huán)境。庫存組織的作用是如此基礎(chǔ)，以至于EBS的相關(guān)文檔在提及組織（Org）概念時，假如未作特不講明，默認(rèn)確實是

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

47、公司段值，這與真實世界中的治理要求是一致的。庫存組織INV與會計科目彈性域中的“成本中心”段（部門）則具有“一對一或多對一”的關(guān)系，即一個“成本中心”段值能夠有多個庫存組織INV，但一個庫存組織INV只能屬于一個確定的成本中心。（六）HR組織 系統(tǒng)的HR組織設(shè)置是與HRM模塊的相關(guān)業(yè)務(wù)處理功能相關(guān)，與核心業(yè)務(wù)/財務(wù)處理功能關(guān)系不大，要緊是需要注意其是否和“成本中心”關(guān)聯(lián)，需要時能夠輸入“成本中心”代碼，其LOV確實是“會計科目彈性域”結(jié)構(gòu)中成本中心段的值集。如下圖30所示：（七）多組織接入操縱在圖30的EBS組織設(shè)置界面中，所謂的組織“類型”（Type）劃分僅是基于組織自身的統(tǒng)計分析工作需要而定義的一個“維度”，例如“公司總部、產(chǎn)品線”等等，并不阻礙系統(tǒng)的業(yè)務(wù)處理功能。真正起作用的是設(shè)置界面中的“組織分類”（Classification），系統(tǒng)預(yù)置的組織分類LOV除了上述“業(yè)務(wù)組、法律實體、業(yè)務(wù)實體、庫存組織”等之外，還有諸如“資產(chǎn)組織、運營公司、雇主”等等選項。在EBS系統(tǒng)中各應(yīng)用模塊所具有的業(yè)務(wù)處理功能通常需構(gòu)建在一個確定的“組織分類”之上，“組織”是相關(guān)業(yè)務(wù)處理功能的平臺，企業(yè)是否需要作相關(guān)組織分類設(shè)置、如何設(shè)置，取決于企業(yè)所需要使用到的應(yīng)用模塊功能。例如所謂“資產(chǎn)組織”的設(shè)置，它是在企業(yè)需使用到資產(chǎn)治理模塊FA時才涉及到。“資產(chǎn)組織