EBS系统组织架构讲解

1、.ORACLE EBS组织架构介绍业务组（BQ法律实体（LE）业务实体（OU（四）库存组织（INV）（五）公司成本中心（Cost Center ）（六）HR组织多组织接入控制在企业管理实践的过程中，"组织” （Orga nizatio n ） 词是个经常需用到的概念, 一般与“人员”与“职能”这两个要素密切相关，反映某种行政管理关系，例如“财务 部、销售部、采购部、生产部、仓储部”等等。企业内部行政组织（部门）的划分是企 业基于“职能驱动”业务管理模式进行运作的基础。目前，国内适用于小企业使用的大 多数低端管理软件并不考虑系统中的“组织”设置问题，其系统应用模块的划分，例如 采购模块

2、、仓管模块、销售模块等等，实际上就已经基本反映了企业运作的 “组织职能” 划分问题。但是，对于业务复杂、规模较大的企业（如所谓“集团企业”），管理软件使用与 实施的系统“组织设置”问题将是一个首要的重要问题。一个常见的、也是错误的系统 实现方式就是将企业的“行政组织设置”直接映射到系统中，以“行政组织”代替“业 务组织”。这种系统实现方式虽有理解、掌握比较容易的优势，但却完全违背了大企业 运作必须基于“流程驱动”业务模式的基本管理原则。国内有所谓高端管理软件在系统 实施过程中，常常出现有几十个财务、采购组织，几百个销售组织，乃至上千个库存组 织的“盛况”，导致系统几乎没法使用的困境，其症结正在

3、于此。与企业的“行政组织”设置与人员规模密切相关且复杂多变不同，软件系统的“组 织设置”必须以业务流程运作为核心， 要求尽可能简单并保持相对稳定， 在公司（人员）规模扩大的过程中具有延续性与继承性。作为ERP鼻祖的SAP将系统组织简单地分为“集 团（Client ）、公司代码（CompanyCode）、采购组织（Purchase Org）、销售组织（SaleOrg）、工厂（Plant ） ”等类别。ORACLE勺组织设置本质上与之基本相似，但作为后来 者作了进一步抽象与简化，系统组织划分为"业务组（Bus in ess Grou p）、法律实体（LegalEn tity )、业务实体

4、(Op erati ng Un it)、库存组织(Inven tory Org )"等。如果说SAP的组织模型字面上多少还带有一点“行政组织”痕迹的话（这可能是某 些声称学SAP的国内产品误入歧途的原因），ORACLED统的组织模型字面上已经几乎看不出与“行政组织”还有什么关系，其中的“Inven tory Org "现今中文翻译成“库存组织”，容易令人望文生义和企业的"仓库管理部门（Warehouse） ”混淆，但Inventory 的本义实际应该是“存货”，称之为“存货组织”或许更好一些。如下图22所示ORACLE 系统有关核心业务的多组织模型:ORACLE多

5、组织系统模型上图中的“财务、销售、采购”并非系统的“组织实体”，它仅表示业务实体（OU具有的相关业务处理功能。“子库”是特殊的系统组织实体，没有上下文环境可进入, 主要表示库存组织之下的某种业务功能。（一）业务组（BG“业务组”的概念可以与企业的“集团”概念参看，但不同的是一个企业在系统中可以设置多个“业务组（集团）”。通常对于一个企业来说，系统中有一个“业务组” 就够了，这表示企业就是一个“集团公司”。而对于某些业务“多元化”的特大型公司（如跨国公司），则可能需要在系统中设置多个“业务组”，表示企业由多个“集团公 司”组成。业务组设置是系统组织设置的第一步，是最高层级的组织形态，但它主要是与

6、人力资源信息的分隔有关，即“人员信息”的设置在一个BG范围内是由各业务模块共享的（如果需要）。一旦系统设置的用户名（User）被与"人员”（EmpIoyee）关联，无论使用什么“责任”进入系统，都会定位至一个确定的BG中，任何责任在任意时刻只能关联一个BG EBS安装好后，系统里面已经预置了一个名为“Set up Bus in ess Group ”的“初始业务组”。如图23所示系统预置的“ Setup Business Group ”当以系统预置超级用户 SYSADMir进入后，应首先设置一个具有在HRM或INV下创建组织功能的“责任”名，随后给此责任的“ HR User Type

7、”配置文件设定值为“ HRUser ”， 则该责任就有了创建新 BG的能力。通常需要一次性将企业所需要的BG全部建立，一般另创建一个与企业名称一致如“某某集团”的新BG就可以了，也可以使用系统预设的“ Set up Bus in ess Group ”而不创建新BG系统每新建一个BG就会自动在配置文件“ HR安全性配置文件”的LOV中自动添加一个与新建BG同名的可选值（初始时只有“Setup Busin ess Group”一个值）。在某一个 BG 下（初始为 Set up Busi ness Group）新建的任何责任，系统都将该责任的配置文件“ HR安全性配置文件”值默认为当前BG要在进入

8、系统时能切换到新的BG（不推荐）直接必须先修改该责任的“ HR安全性配置文件”设定值。BG下，新建的组BG下的所有新如果将配置文件“ HR交叉业务组”的值设为“是”，则在不同织名称应当（虽然可以）不同，否则查看时可能会引起混淆。在同一个 建组织，名称不允许相同。（二）法律实体（LE）法律实体（LE, Legal Entity ）对应于真实世界中的按国家法律法规要求注册的“法人公司”。在 R11中，LE在组织FORM定义时，对于每个LE必须为其“法人主体会计科目”关联一个“帐套 SOB。每个LE对应一个SOB这与真实世界的法规要求是吻合的。如下图24所示:R12 中，LE要注意的是，在R11中定

9、义的LE时，并未作与“会计科目弹性域结构”的“公司 段”值关联，用户必须对于其是与公司段值中的哪个值对应心中有数。而在 的组织定义虽在FORM中仍然保留，但LE的“法人主体会计科目”的 FORM设置被废弃WEB（故 FORM中定义了也无用），改为在定义“分类帐”时的“会计科目设置管理器”中定义并分配法人实体 LE。一个分类帐设置（主辅分类帐）可以添加多个LE，但每个LE只能具有一个分类帐设置。如下图25所示:在R12中，还必须为法人实体分配会计科目弹性域结构的公司段即平衡段值。每个LE,则其它LELE可以分配多个“平衡段”值，公司段值集中每个段值一旦被分配给某就不能再被分配。在 R11或R12

10、中创建一个LE后，应当及时到会计科目弹性域结构中添加需要对应的公司段值 LOV（个或多个），并重新进行弹性域的编译，否则系统可能会弹出错误报警信息。R12中一个LE对应多个公司平衡段值， 代表有多个分公司，LE 是它们的合并。主辅分类帐可拥有相同或不同的公司段值集，表示从不同的维度（如按地区、按产品等）去划分公司以方便考核。如图26所示为LE添加平衡段值:无论是R11还是R12,法律实体LE的设置都对具体的业务处理影响不大，其与系统用户或责任不关联，不直接影响系统上下文的切换，故有人甚至认为EBS的LE设置作用LE还不大。这对于系统的内部运作来讲情况确实近似如此，但对于需要通过系统产生供外部

11、使用的具有法律意义的文书（如采购订单、财务报表等等），严格区分法律实体 是必须的。R12显然更多地考虑了外部使用的这种法律要求（即所谓“法规遵从性”或“合规性”），并在相关业务应用模块中有所体现。（三）业务实体（OU业务实体（OU Op erat ing Unit ）是EBS系统组织设置的重点也是难点之一。它与 法人主体LE本身没有必然的关系，与会计科目弹性域结构中的“公司段”也没有直接关系。从企业实际业务管理需要的角度去看，业务实体OU可以看作是在系统中按照业务的相似性，把多个不同公司（包括LE）的业务处理过程及数据划分成相对独立的“管 理单元”。在每个管理单元内部，各公司的业务运作共享相关

12、数据并执行统一的业务策 略。例如，有一个业务多元化的企业既生产医院使用的X光机也生产普通电视机，并且其下属在全国各地有多家生产 X光机或电视机的分公司、子公司。由于这两种产品所使用的物料、供应商以及针对的客户群差异很大，企业为方便管理，可以将“业务运营”划分为两个相对独立的“业务管理群组”，对应到EBS系统中就是两个业务实体 OU从企业日常业务运作管理的角度来看，对于单纯的电视机业务，全国范围内就设一 个公司负责计划、生产、采购、销售等运营管理最为简便，但企业从非运营管理角度例如“税收优惠、地方政策”等等因素考虑，有时不得不在全国各地乃至世界各地注册若 干所谓“公司”，以便向当地政府纳税并接受

13、其财务会计方面的监管。EBS在一个业务实体 0L下，例如“电视机管理群组”，包含了全国各地所有负责生GL）,仍能够方产或销售电视机的分公司、子公司（LE）的日常业务运作，在业务运作的组织层面忽略 了作为法人实体的公司信息，但在反映业务运营最终结果的财务阶段（ 便地按照各地的法规要求提供财务数据与结果。而对于负责具体业务的系统用户来说, 日常工作几乎不用关心或考虑“公司”的设置问题。EBS中LE的数量可以根据需要任意增加，但对于0U的数量基于管理方便性则要求尽可能精简。EBS产品早期在实施过程中，存在一个公司（LE）对应一个0U的做法或一 个0U只能属于一个LE的说法，这种做法或说法并不恰当。某

14、些国内产品的设计由于未 能有效区分“法律实体（公司）”与“业务实体（运营）”两者在系统中既相连接又有 本质区别的特殊关系，只好采取一个法人公司对应一个系统业务实体的“笨办法”，企 业规模小倒还能对付，一旦规模变大，注册公司增多，所谓的“系统多组织架构”就变 得根本不具可用性。ORACLE EBSk务实体OU的这一系统特性极大地方便了企业运作的日常管理，具有高度的灵活性与可扩展性。如下图27是R11的0U定义界面:4n "j| El mWtORACLE&'t ITt Illin' _. -T- XMi： ViJ- 堆a瓯k主悻Mum wcnTi图中的“业务实体信

15、息”中，必须而且只能为之设定一个“帐套”，即一个0U只能属于一个帐套（反之，一个帐套可以分配给多个0U。要注意的是，上述业务实体信息中的法人实体设定，并不代表 0U只能属于一个LE,它只是表示在“业务实体”中进行业务操作需要法人实体信息时提供默认值（在R12中明确了是“默认值”这一点）。R12中的业务实体定义同 R11基本相同，只是将帐套改为“主要分类帐”。在EBS中，一个0U可以同时指定给多个 LE,上面“电视机管理群组”的例子已经说明了这一点；一个LE也可以有多个0U这相当于一个注册的法人实体公司下，有多 个需要独立运营的“事业部”（如 X光机和电视机）。0U与LE是“多对多”的关系,但有

16、一个限制性的前提条件，即0U与LE必须属于同一个S0B或 Ledger。由于LE与0U的设置在系统中可以独立进行，因此如果双方的S0B或 Ledger不同，则不能建立连接关系。如果说法人实体LE与真实世界的企业行政管理组织架构还有点关系的话，业务实0U的设置没有直接影响。体0U则是与行政管理几乎无关，企业内部的行政组织变化对在EBS中有关采购管理、销售订单履行、应收应付管理等业务模块的功能均是建立在0U基础之上的。用户在执行上述相关模块的业务处理时，总是必须进入确定的 0U（上下文 环境）才可以进行，EBS的所谓“多组织”功能（MOAC也是针对多0U而言的，与真实 世界中的“多公司” （LE）

17、没有直接关系。实际上，SAP的“采购组织、销售组织”设置也是与真实世界的行政组织“采购部、销售部”无关的，ORACLED弃了 “采购组织、销售组织”的概念，0U实际上就起到了类似的组织分隔作用。ORACLE勺某些相关文档中，如果因描述需要而提及所谓 “采购组织、销售组织”等概念，有时实际指的就是业务实体0U（或0U下的库存INV组织）。（四）库存组织（INV）ORACLE EBS的库存组织（INV）是系统组织设置的最基础、也是最重要的工作之。库存组织的内涵远不是真实世界的“仓库部门”那么简单，它除了是有关“物料接 收与发出”等业务功能的基础之外，更重要的是，它还是EBS系统有关计划（MPS/M

18、RP、在制品管理（WIP、物料清单（BOM等模块业务功能的操作与管理平台。如下图28所示:EBS中的库存组织INV的作用与功能可以与 SAP中的工厂Plant参看。一个库存组织INV只能属于一个确定的帐套 SOB一个确定的法人实体LE、一个确定的业务实体 0U具有唯一性的关系（注意：R11的设置界面未考虑SOB/LE/OU的关联限定，容易产生错误；R12作了改进，在选定Ledger之后，可用的LE/OU就被限定）。反之，一个“帐套/法人实体/业务实体”组合则可以有多个库存组织INV。此外，一个OU下的多个INV可以对应属于该 0U的不同LE，这相当于将分属于两个法人公司的生产两种产品的四个工厂

19、，按相同产品两两组合抽取出来，分属于两个不同OU进行日常业务管理。在EBS中还有两个组织概念“ MRP!织、WIP组织”，它们实际是必须构建于库存组织之上的组织概念， 表示该库存组织还可以进行 MRP或WIP的功能。系统之所以如此处理，主要是为了控制某些INV不能做MRP或WIP而已，因为基于物料接收或发出需要 所设定的INV数量可能比较多。对于绝大多数基于库存组织INV的业务功能（个别除外），系统用户在做业务操作 时，均必须首先进行INV的选择切换，以便进入确定的 INV上下文环境。库存组织的作用是如此基础，以至于EBS的相关文档在提及组织（Org）概念时，如果未作特别说明, 默认就是指IN

20、V组织。（五）公司成本中心（Cost Center ）29EBS的所谓“成本中心组织”并没有业务处理的功能，它的设置主要是考虑与“会计科目弹性域结构”中的“公司段值”与“成本中心段值”的对应关系问题。如下图 所示:E5-07-003«*| h i nmGF冈OTJACLe-畑T:彌 CI!Mfr阳 CvpattAnM二旬 i * 普，心 " !0片 在系统中创建“公司成本中心组织”后，可以运行一个“并发检查程序”，以校验“会计科目弹性域结构”中的段值是否与所有的“公司成本中心”组织的设置保持一致。当在“会计科目弹性域结构”中的“成本中心段”值集中添加L0V值并重新编译后,

21、可以运行系统的“自动组织”并发程序功能，由系统自动创建“公司成本中心”组织。应当注意的是，一个公司成本中心组织及其成本中心段值，不可能属于不同法人实INV与会计科目体LE及其公司段值，这与真实世界中的管理要求是一致的。库存组织 弹性域中的“成本中心”段（部门）贝具有“一对一或多对一”的关系，即一个“成本中心”段值可以有多个库存组织INV,但一个库存组织INV只能属于一个确定的成本中心。（六）HR组织系统的HR组织设置是与HRM莫块的相关业务处理功能相关，与核心业务/财务处理功能关系不大，主要是需要注意其是否和“成本中心”关联，需要时可以输入“成本30所中心”代码，其L0V就是“会计科目弹性域”

22、结构中成本中心段的值集。如下图 示:ORACLEeon w iMu： iMir uiHEM当"B工ak孙Jfr中舟降Pi.& OrorLc 肓工-Tision.詢即羯轩冲穴嘛曙新為 T貝G伽g科中却总罚F丰宇心運叮?JJIX电卢内郎余吐£H feEjaCn 1 f Ml- wr翻CCDEr Dyu:r.rHlK+iaarcnILDhE L 1 1 11*1. AaI-1 VCV1.ILL t b.iam 毎pvurc"IL：JfektIfljvlUv-ibIFPiiilLlkJi kfefevll-J«klaISUS 0"皿E中U帕Cj

23、JJ.iak£30Ljil-二皿Lllo; J. Or舀H一 z/Llig.5UjJPiAf±uCt 2j-J.v4UI'UiLAb-lbBlip TUdnt*沽帕ua口I亡Fpni.bixn*l SJafbtfr（七）多组织接入控制在图30的EBS组织设置界面中，所谓的组织“类型”（Type）划分仅是基于组织自身的统计分析工作需要而定义的一个“维度”，例如“公司总部、产品线”等等，并 不影响系统的业务处理功能。真正起作用的是设置界面中的“组织分类”EBS系（Classificatio n），系统预置的组织分类 LOV除 了上述"业务组、法律实体、业务实

24、体、库存组织”等之外，还有诸如“资产组织、运营公司、雇主”等等选项。在“组织分类”之上，“组统中各应用模块所具有的业务处理功能通常需构建在一个确定的 织”是相关业务处理功能的平台，企业是否需要作相关组织分类设置、如何设置，取决 于企业所需要使用到的应用模块功能。例如所谓“资产组织”的设置，它是在企业需使用到资产管理模块FA时才涉及到。“资产组织”实际上是所谓“资产账簿”的代名词，它只是表示有关资产信息的一个数ORACLI系据维度，作用主要在于分隔数据范围，用户进入系统作业务处理时，并不需要作上下文 业务环境的切换。对于这类并不涉及“上下文”环境切换的所谓“组织”， 的设计主要是为了借用“组织”

25、所具有的“层次结构” （ Hierarchy ）概念来达到“多 组织接入”权限的控制功能。需指出的是，这里的组织“层次结构”与真实世界企业的行政管理组织层次结构没 有直接关系（尽管可能有所参考），它只是企业根据某种需要（如权限管理控制、数据 统计汇报等）而人为设定的一个“层次结构”，例如将系统中已经设置的任意数量的“业 务实体”或“库存组织”等等组织 Name人为地设定一个具有上下级关系、自顶向下的：金字塔形多层结构。如下图 31所示:B Oz >cIe 141 pli-ir-E.-liocLE空片© JMS©即花茯，ii TiQ tg口 :;?时引or?ACLe用智

26、蛙馬事'jgF'曲E去，子J .，少罰甘？JTMZ r X rTT 呼養寺忖交um： ：¥Ji 号!Tfi芳有IF干5宾e将匸J'3(<*DClEvbal Pi->rzanv.4rat国MS檜IS0 -dDDQQ起明-7EiaUfi若碎 ig些 itfName上图中开始定义时，一旦选定（最）顶端组织Name则就只能为之分配下属组织 如要给下属组织分配更下一级的组织，贝懦点击“向下”按钮，将当前该下属组织上升 到“顶端组织”位置。点击“向上”按钮，则将当前“顶端组织”下降到下属组织位置。 企业可以根据实际需要设定若干个具有不同内部结构的“组织层次结构

27、”Name以供定义系统所谓“安全性配置文件”时调用。如下图32所示：GocIe Appli-cBTl-ifnLs寸3叩s If m一 二"1 旨口忙 ffifi©匚厉XORACLE'屯也占wd :异 1 1嗣1上'-y1 ?aFL Var*L H_UFl塵SEff丈fli旳十STfl十 BHSr KJ«!hk z 却a tCl羊bd Viyi m-HmBLXILELFeO口 述；Uk iLQ-MluCi ili1也4WLMU?noHXDTW HbE rBTrvtcsB rrtHTs*人+ 丙印产2+ 宣翡+丄件iJlVjLriUb CkiriUiL

28、hlldU.九hvfe石4>JW山ra<iPh ItixW"N-inuL'ucluc iii£ »hd Ditlirpchoe 愛全iailAS3CHvihrtp r:bPiL rqrLf-jJAC PtfVllEIOL EflTTLC-i t上图所定义“安全性配置文件”是系统用以控制包括“组织安全性”等在内的各种 安全性控制的基础，它具体规定了系统安全性控制的范围与实现方式，所有定义的“安MO安全性配置文件”的 LOV如全性配置文件” Name构成系统多组织接入控制参数“下图33所示:ORAa_e-3 flEBS通过“ MO业务实体”、“ M

29、O安全性配置文件”、“ M0默认业务实体”这三个系统配置文件的共同作用,实现所谓“多组织接入”控制功能MOAC但上述三个配置文件在R11与R12中的作用有比较大的差别。对于“ MO业务实体”，在R11中必须设定，而且起决定性控制作用，其LOV由系统基于创建的OU n ame自动创建，用户登录时系统自动定位于指定OU而在R12中,一旦设定“ MO安全性配置文件”，则此配置文件失效而不起作用。对于“ MO安全性配置文件”，在R11中虽有，但实际不起0U接入的控制作用,只针对FA等模块的得某些应用如数据统计等起作用。因此，一般认为R11并不具有完善的多组织接入控制功能。 在R12中，该参数如果不设定

30、，则必须设定“MO业务实体”参数；一旦该参数被设定，则就起决定作用，系统主要依赖其实现MOAC对于“ MO默认业务实体”，在R11中虽有但实际不起作用。在 R12中，随“ MO安全配置文件”起作用后才起作用，其LOV是所有已定义OU但如果设定值不在“ MOOU相关安全配置文件”所选择的“组织层次架构”的范围内，则仍不起作用（即在与ORACLE系统设计诸如PO 0M等的FOR碍面，0U字段的默认值仍然为空）。这似乎是方面的一个难题，即“ MO默认业务实体”的 LOV值集无法与“ MO安全性配置文件”中“组织层次架构”中的 OU值范围保持一致。ORACLES调其“多组织接入MOAC功能主要是针对业

31、务实体 OU而言，其另外一层含义是，所有构建于库存组织INV上的应用功能，实际是与上述配置文件无关的。库存组织的可接入性是在“组织访问”控制功能中，专门设定“库存组织”与“责任”的关联性，如下图34所示:I ?+ Ccarlr Aqipl xcaticnsORACkG"2 % 妙 I 了 V -'囲 43 ' Ja, 卒工 #11九轨 a镇 fUtM工 np»干序寺科佈巾i*1躺坤加InvvAtvE y; ixff: fl 紀;相何Ih ht r jlriitliin VntirtE«riijLiLiiirliili 1-ihK Mpd"

32、tLlnatTinlikzH让 *1iWhffl 初t Sivpr njtr.LK4CaLinatyloii 实hTiz9上fietFT按照ORACLE勺说法,制，贝所有“责任”可访问所有如果系统在初始的时候，不定义库存组织的“组织访问”控INV, 旦限制或分配其中一个，则其余均必须逐个进行分配以建立“库存组织”与“责任”的链接关系。总之，EBS系统通过“弹性域段值安全性”、“帐套 /分类帐安全性”、“多组织接入安全性（MOAC ”、“库存组织访问控制”等多维度、多方面的组合系统设置，提供了灵活、方便的用户权限管理功能，厘清并掌握它们的复杂关系是系统实施的一项重要 基础性工作。A杠Ulj!左霄卅aHeiu前仇 IblrLJKt BtplulelSBQfirK -:it 3'；” 遊八啊玉：”yr雜I *. ' ' 靳卄下“商让*咛“jjaaryMHffijiu 注“卩护/彳询/咨“rimn胡和丘訓*询rd_tf PJJ.】賈m：*" F苫/ 机冋两翟_训.¥.】叫 *i| © «却 喜半 "合tfrftuBiS&as主稈E农心yjffifen. Qli ! fL'SA> flS舜