ORACLEEBS基础设置之组织架构

1、ORACLE EBS基础设置之组织架构四、组织架构在企业管理实践的过程中，组织”(Organization) 词是个经常需用到的概念，一般与人员”与职能”这两个要素密切相关，反映某种行政管理关系，例如 “财务部、销售部、采购部、生产部、仓储部 ”等等。 企业内部行政组织(部门)的划分是企业基于 “职能驱动 ”业务管理模式进行运作的基础。 目前， 国内适用 于小企业使用的大多数低端管理软件并不考虑系统中的 “组织”设置问题，其系统应用模块的划分，例如采 购模块、仓管模块、销售模块等等，实际上就已经基本反映了企业运作的“组织职能 ”划分问题。但是，对于业务复杂、规模较大的企业(如所谓 “集团企业

2、”)，管理软件使用与实施的系统 “组织设 置”问题将是一个首要的重要问题。一个常见的、也是错误的系统实现方式就是将企业的“行政组织设置 ”直接映射到系统中，以 “行政组织 ”代替 “业务组织 ”。这种系统实现方式虽有理解、掌握比较容易的优势，但却 完全违背了大企业运作必须基于 “流程驱动 ”业务模式的基本管理原则。国内有所谓高端管理软件在系统实 施过程中，常常出现有几十个财务、采购组织，几百个销售组织，乃至上千个库存组织的“盛况 ”，导致系统几乎没法使用的困境，其症结正在于此。与企业的 “行政组织 ”设置与人员规模密切相关且复杂多变不同，软件系统的 “组织设置 ”必须以业务流 程运作为核心，要

3、求尽可能简单并保持相对稳定，在公司(人员)规模扩大的过程中具有延续性与继承性。 作为ERP鼻祖的SAP将系统组织简单地分为 “集团(Client)、 公司代码(Company Code)、 采购组织 (Purchase Org)、 销售组织(Sale Org)、 工厂(Plant) ”等类别。ORACLE的组织设置本质上与之基 本相似， 但作为后来者作了进一步抽象与简化，系统组织划分为 “业务组(Business Group)、 法律实体(LegalEntity)、业务实体(Operating Unit)、库存组织(Inventory Org) ”等。如果说SAP的组织模型字面上多少还带有一点

4、 “行政组织 ”痕迹的话 (这可能是某些声称学SAP的国 内产品误入歧途的原因)，ORACLE系统的组织模型字面上已经几乎看不出与 “行政组织 ”还有什么关系， 其中的 “Inventory Org现”今中文翻译成 “库存组织 ”，容易令人望文生义和企业的 “仓库管理部门(Warehouse) ”混淆，但Inventory的本义实际应该是 “存货 ”，称之为 “存货组织 ”或许更好一些。如下图22所示ORACLE系统有关核心业务的多组织模型：ORACLE多组织系统摸型业务组法律:实体法律实休业务 实体业务实体（一）业务组（BG）业务组”的概念可以与企业的 集团”概念参看，但不同的是一个企业在系

5、统中可以设置多个业务组（集团）”。通常对于一个企业来说，系统中有一个业务组”就够了，这表示企业就是一个 集团公司”。而对于某些业务 多元化”的特大型公司（如跨国公司），则可能需要在系统中设置多个业务组”，表示企业由多个集团公司”组成。业务组设置是系统组织设置的第一步，是最高层级的组织形态，但它主要是与人力资源信息的分隔有关，即人员信息”的设置在一个BG范围内是由各业务模块共享的（如果需要）。一旦系统设置的用户名（User）被与人员（Employee）关联，无论使用什么责任进入系统，都会定位至一个确定的BG中,任何责任在任意时刻只能关联一个BG。EBS安装好后，系统里面已经预置了一个名为“Set

6、up BusinessGroup的初始业务组”。如图23所示系统预置的 “Setup Business Group :”ii-1.库存组织库存组纭库存组纭上图中的功能。子库”是特殊的系统组织实体，没有上下文环境可进入，主要表示库存组织之下的某种业务功能。财务、销售、采购”并非系统的组织实体”，它仅表示业务实体（0U）具有的相关业务处理当以系统预置超级用户SYSADMIN进入后，应首先设置一个具有在HRM或INV下创建组织功能的 责任名，随后给此责任的 “HRUser Type配置文件设定值为 “HR User，则该责任就有了创建新BG的 能力。通常需要一次性将企业所需要的BG全部建立，一般另创

7、建一个与企业名称一致如某某集团”的新BG就可以了，也可以（不推荐）直接使用系统预设的“Setup Business Group而不创建新BG。系统每新建一个BG,就会自动在配置文件“HR安全性配置文件”的LOV中自动添加一个与新建BG同名的可选值（初始时只有 “Setup Business Group一个值）。在某一个BG下（初始为Setup Business Group）新建的任何责任，系统都将该责任的配置文件“HR安全性配置文件”值默认为当前BG。要在进入系统时能切换到新的BG,必须先修改该责任的“HR安全性配置文件”设定值。如果将配置文件“HR交叉业务组”的值设为是”，则在不同BG下，新

8、建的组织名称应当（虽然可以） 不同，否则查看时可能会引起混淆。在同一个BG下的所有新建组织，名称不允许相同。（二）法律实体（LE）法律实体（LE，Legal Entity）对应于真实世界中的按国家法律法规要求注册的法人公司”在R11中，LE在组织FORM定义时，对于每个LE必须为其法人主体会计科目”关联一个帐套SOB。每个LE对应一个SOB，这与真实世界的法规要求是吻合的。如下图24所示：要注意的是，在R11中定义的LE时，并未作与会计科目弹性域结构”的公司段”值关联，用户必须 对于其是与公司段值中的哪个值对应心中有数。而在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转却社-“ORACLC*令廿罰貝设冒管理譽a_ _田整衿去戸弓FH-它声咋世晞E,链人主住I ()atAXttUW营右祥摘乜舅h rfhhli* Shl.rsU

10、YSll ITusEETCUDLD旦u-juthi hcs L!rJH.eusEBSJIDLzsUSA TESTUSUSS册妙50pr aCACTd卵昭江刘疋IQ9旳朝打JIHumG-snqik CTREJ%CTAWililCI 1T?ypilin Le-iiutigUSJSVAT-fj&i*曾f fsFssucaFssucap jzakjauUSE3泅述DUO$. 辛令*1|后YiUfZArrWMQJS抑状齐WV-： -K ：“ T-r：,为M甘紳:宅加讶更睛E记麻卿i抑也二审M7G 丿古祁*讪1棍畫而*4 更鶯为巧护也舐口疋 ,!尺适甌W苴G匚PEKATK帕jiu in.jOMUI

11、MJ創亠 hf伯在R12中，还必须为法人实体分配会计科目弹性域结构的公司段即平衡段值。每个LE可以分配多个平衡段”值，公司段值集中每个段值一旦被分配给某LE，则其它LE就不能再被分配。在R11或R12中创建一个LE后，应当及时到会计科目弹性域结构中添加需要对应的公司段值LOV（一个或多个），并重新进行弹性域的编译，否则系统可能会弹岀错误报警信息。R12中一个LE对应多个公司平衡段值，代表有多个分公司，LE是它们的合并。主辅分类帐可拥有相同或不同的公司段值集，表示从不同的维度（如按 地区、按产品等）去划分公司以方便考核。如图26所示为LE添加平衡段值：Dl巳计凰鸭ijLX.1I豐 mJjhtei

12、nEL HxiilifrcE- 立眸吐祕息G 妁催也i1AWfe吐0药x：*L/m:打cki . H f 1. in./tMUOHJIuL上f/giZiA疋L# /e.MtZr.hiu十亠口di乂帘JMAtlEkjrfjMkfliS监妙JJLKL * Q VtJU酋：l佥H啊冃说苦資蹲器关同住百.虽氏村的 侖汁送期visior OperalonsI：LJII；I崙雷用SfffcK*&lrl三莫亀他赠口金丁毎眞聲帥 *（!工OprrMwOprrMw匚町吟列爭14豊a_!A3mj|fcki_iLiiE yhiMH一Lys.。严屮卜.1_“,州呼输助勺诫半nvi HroBikf tr泊舉 口

13、HA.fMfuy提瓜塌粋苴 f 论値；配站他人主体u績披建人主住錨定知洋护;5：务处越 岀輛序川比医aitM廿丈修便阳正已轴 工豊j&ft ttfti 0pwtllmJ CcrfcHfif己孙配干Kt值二Lpera血wx L.ifULT谁如罕硼I下”SW血FT崛歩itH.DEoptftiaMiii*in-SLJKJCC#）71Ji si m CFuSrLfdt| 力| r3.I _ Mki. 9WW*ir_l_取荷 盟用1栄千 gtf FWU i?rr H n.-joie恬55所中尸利jhtrm无论是R11还是R12，法律实体LE的设置都对具体的业务处理影响不大，其与系统用户或责任不

14、关联，不直接影响系统上下文的切换，故有人甚至认为EBS的LE设置作用不大。这对于系统的内部运作来讲情况确实近似如此，但对于需要通过系统产生供外部使用的具有法律意义的文书（如采购订单、财务 报表等等），严格区分法律实体LE还是必须的。R12显然更多地考虑了外部使用的这种法律要求（即所谓法规遵从性”或合规性”，并在相关业务应用模块中有所体现。（三）业务实体（0U）业务实体（OU，Operating Unit）是EBS系统组织设置的重点也是难点之一。它与法人主体LE本身没有必然的关系，与会计科目弹性域结构中的公司段”也没有直接关系。从企业实际业务管理需要的角度去看，业务实体0U可以看作是在系统中按照

15、业务的相似性，把多个不同公司（包括LE）的业务处理过程及数据划分成相对独立的 管理单元”在每个管理单元内部，各公司的业务运作共享相关数据并执行统 一的业务策略。例如，有一个业务多元化的企业既生产医院使用的X光机也生产普通电视机，并且其下属在全国各地有多家生产X光机或电视机的分公司、子公司。由于这两种产品所使用的物料、供应商以及针对的客户 群差异很大，企业为方便管理，可以将业务运营”划分为两个相对独立的 业务管理群组”对应到EBS系统中就是两个业务实体0U。从企业日常业务运作管理的角度来看，对于单纯的电视机业务，全国范围内就设一个公司负责计划、生产、采购、销售等运营管理最为简便，但企业从非运营管

16、理角度例如税收优惠、地方政策”等等因素考虑，有时不得不在全国各地乃至世界各地注册若干所谓公司”以便向当地政府纳税并接受其财务会计方面的监管。EBS在一个业务实体OU下，例如 电视机管理群组”，包含了全国各地所有负责生产或销售电视机的 分公司、子公司（LE）的日常业务运作，在业务运作的组织层面忽略了作为法人实体的公司信息，但在反 映业务运营最终结果的财务阶段（GL），仍能够方便地按照各地的法规要求提供财务数据与结果。而对于 负责具体业务的系统用户来说，日常工作几乎不用关心或考虑公司”的设置问题。EBS中LE的数量可以根据需要任意增加，但对于OU的数量基于管理方便性则要求尽可能精简。EBS产品早期

17、在实施过程中，存在一个公司（LE）对应一个OU的做法或一个OU只能属于一个LE的说法，这种做法或说法并不恰当。 某些国内产品的设计由于未能有效区分法律实体（公司）”与业务实体（运营）两者在系统中既相连接又有本质区别的特殊关系，只好采取一个法人公司对应一个系统业务实体的笨办法”，企业规模小倒还能对付，一旦规模变大，注册公司增多，所谓的系统多组织架构”就变得根本不具可用性。ORACLE EBS业务实体OU的这一系统特性极大地方便了企业运作的日常管理，具有高度的灵活性与可扩展性。如下图27是R11的OU定义界面：图中的 业务实体信息”中，必须而且只能为之设定一个 帐套”，即一个OU只能属于一个帐套（

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

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

20、销售部”无关的，ORACLE抛弃了采购组织、销售组织”的概念，OU实际上就起到了类似的组织分隔作用。ORACLE的某些相关文档中，如果因描述需要而提及所谓采购组织、销售组织”等概念，有时实际指的就是业务实体OU（或OU下的库存INV组织）。（四）库存组织（INV）ORACLE EBS的库存组织（INV）是系统组织设置的最基础、也是最重要的工作之一。库存组织 的内涵远不是真实世界的 仓库部门”那么简单， 它除了是有关 物料接收与发岀”等业务功能的基础之外， 更 重要的是， 它还是EBS系统有关计划 （MPS/MRP） 、 在制品管理 （WIP） 、物料清单（BOM）等模块业 务功能的操作与管理平

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

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

23、并没有业务处理的功能，它的设置主要是考虑与会计科目弹性域结构中的 公司段值”与成本中心段值”的对应关系问题。如下图29所示：在系统中创建 公司成本中心组织”后，可以运行一个 并发检查程序”，以校验 会计科目弹性域结构” 中的段值是否与所有的公司成本中心”组织的设置保持一致。当在 会计科目弹性域结构”中的 成本中心段”值集中添加LOV值并重新编译后，可以运行系统的自动组织”并发程序功能，由系统自动创建公司成本中心”组织。应当注意的是，一个公司成本中心组织及其成本中心段值，不可能属于不同法人实体LE及其公司段值，这与真实世界中的管理要求是一致的。库存组织INV与会计科目弹性域中的 成本中心”段（部

24、门）则具有一对一或多对一 ”的关系，即一个成本中心”段值可以有多个库存组织INV，但一个库存组织INV只能 属于一个确定的成本中心。（六）HR组织系统的HR组织设置是与HRM模块的相关业务处理功能相关， 与核心业务/财务处理功能关系不大, 主要是需要注意其是否和 成本中心”关联，需要时可以输入 成本中心”代码，其LOV就是 会计科目弹性域 结构中成本中心段的值集。如下图30所示：（七）多组织接入控制在图30的EBS组织设置界面中，所谓的组织类型”（Type）划分仅是基于组织自身的统计分析工作需要而定义的一个 维度”，例如公司总部、产品线”等等，并不影响系统的业务处理功能。真正起作用的 是设置界

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

26、业务环境的切换。对于这类并不涉及上下文环境切换的所谓组织”,ORACLR系统的设计主要是为了借用组织”所具有的 层次结构”（Hierarchy）概念来达到 多组织接入”权限的控制功能。需指岀的是，这里的组织 层次结构”与真实世界企业的行政管理组织层次结构没有直接关系（尽管可 能有所参考），它只是企业根据某种需要（如权限管理控制、数据统计汇报等）而人为设定的一个层次结构”，例如将系统中已经设置的任意数量的业务实体”或库存组织”等等组织Name,人为地设定一个具有上下级关系、自顶向下的金字塔形多层结构。如下图31所示：上图中开始定义时，一旦选定（最）顶端组织Name，则就只能为之分配下属组织Name，如要给下 属组织分配更下一级的组织，则需点击 向下”按钮，将当前该下属组织上升到 顶端组织”位置。点击 向上” 按钮，则将当前 顶端组织下降到下属组织位置。企业可以根据实际需要设定若干个具有不同内部结构的组织层次结构”Name以供定义系统所谓 安全性配置文件”时调用。如下图32所示：上图所定义 安全性配置文件”是系统用以控制包括 组织安全性”等在内的各种安全性控制的基础，它 具体规定了系统安全性控制的范围与实现方式，所有定义的安全性配置文件”Name构成系统多组织接入控制参数“MO安全性配置文件”的LOV。如下图33所示：EBS通过“MO业务实体”、“MO安全性配置文件