ORACLE组织架构

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

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

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

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

5、下的某种业务功能。（一）业务组（BGDBGD业务组”的概念可以与企业的“集团”概念参看，但不同的是一个企业在系统中可以设置多个“业务组（集团）通常对于一个企业来说，系统中有一个“业务组”就够了，这表示企业就是一个“集团公司”。而对于某些业务“多元化”的特大型公司（如跨国公司），则可能需要在系统中设置多个“业务组”，表示企业由多个“集团公司”组成。业务组设置是系统组织设置的第一步，是最高层级的组织形态，但它主要是与人力资源信息的分隔有关，即人员信息”的设置在一个 BG 范围内是由各业务模块共享的（如果需要）。一旦系统设置的用户名（User）被与“人员”（Employee）关联，无论使用什么“责任

6、”进入系统，都会定位至一个确定的 BG 中，任何责任在任意时刻只能关联一个 BG。EBS 安装好后，系统里面已经预置了一个名为“SetupBusinessGroup”的“初始业务组”。如图 23 所示系统预置的SetupBusinessGroup”:OU）具有的相关业务处理功能。“子库，上图中的财务、销售、采购”并非系统的组织实体：它仅表示业务实体（&Srui-Jc 马明产品中门当以系统预置超级用户 SYSADMIN 进入后，应首先设置一个具有在 HRM 或 INV 下创建组织功能的“责任”名，随后给此责任的“HR：UserType 配置文件设定值为HRUser，则该责任就有了创建新

7、BG 的能力。通常需要一次性将企业所需要的 BG 全部建立，一般另创建一个与企业名称一致如“某某集团”的新 BG 就可以了，也可以（不推荐）直接使用系统预设的SetupBusinessGroup 而不创建新 BG。系统每新建一个 BG,就会自动在配置文件“HR:安全性配置文件”的 LOV 中自动添加一个与新建 BG 同名的可选值（初始时只有SetupBusinessGroup2 个值）。在某一个 BG 下（初始为 SetupBusinessGroup）新建的任何责任，系统都将该责任的配置文件“HR：安全性配置文件”值默认为当前 BGo 要在进入系统时能切换到新的 BG,必须先修改该责任的“HR

8、:安全性配置文件”设定值。如果将配置文件“HR 交叉业务组”的值设为“是”，则在不同 BG 下，新建的组织名称应当（虽然可以）不同，否则查看时可能会引起混淆。在同一个 BG 下的所有新建组织，名称不允许相同。（二）法律实体（LELE法律实体（LE,LegalEntity）对应于真实世界中的按国家法律法规要求注册的“法人公司”。在 R11 中，LE 在组织FORM 定义时，对于每个 LE 必须为其“法人主体会计科目”关联一个“帐套 SOB，o每个 LE 对应一个 SOB,这与真实世界的法规要求是吻合的。如下图 24 所示：要注意的是，在 R11 中定义的 LE 时，并未作与“会计科目弹性域结构”

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

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

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

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

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

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

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

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

17、EBS 的所谓“多组织”功能（MOAC）也是针对多 OU 而言的，与真实世界中的“多公司”（LE）没有直接关系。实际上，SAP 的“采购组织、销售组织”设置也是与真实世界的行政组织“采购部、销售部”无关的，ORACLE1 弃了“采购组织、销售组织”的概念，OU 实际上就起到了类似的组织分隔作用。ORACLE 勺某些相关文档中，如果因描述需要而提及所谓“采购组织、销售组织”等概念，有时实际指的就是业务实体 OU（或 OU 下的库存 INV 组织）。（四）库存组织（INVINV）ORACLEEBS 的库存组织（INV）是系统组织设置的最基础、也是最重要的工作之一。库存组织的内涵远不是真实世界的“仓

18、库部门”那么简单，它除了是有关“物料接收与发出”等业务功能的基础之外，更重要的是，它还是 EBS 系统有关计划（MPS/MRP）、在制品管理（WIP）、物料清单（BOM）等模块业务功能的操作与管理平台。如下图 28所示：EBS 中的库存组织 INV 的作用与功能可以与 SAP 中的工厂 Plant 参看。一个库存组织 INV 只能属于一个确定的帐套 SOB 一个确定的法人实体 LE、一个确定的业务实体 OU,具有唯一性的关系（注意：R11 的设置界面未考虑 SOB/LE/OU 的关联限定，容易产生错误；R12 作了改进，在选定 Ledger 之后，可用的 LE/OU 就被限定）。反之，一个“帐

19、套/法人实体/业务实体”组合则可以有多个库存组织 INV。此外，一个 OU 下的多个 INV 可以对应属于该 OU 的不同 LE这相当于将分属于两个法人公司的生产两种产品的四个工厂，按相同产品两两组合抽取出来，分属于两个不同 OU进行日常业务管理。在 EBS 中还有两个组织概念“MRP 组织、WIP 组织”，它们实际是必须构建于库存组织之上的组织概念，表示该库存组织还可以进行 MRP 或 WIP 的功能。系统之所以如此处理，主要是为了控制某些 INV 不能做 MRP 或 WIP 而已，因为基于物料接收或发出需要所设定的 INV 数量可能比较多。对于绝大多数基于库存组织 INV 的业务功能（个别

20、除外），系统用户在做业务操作时，均必须首先进行 INV 的选择切换，以便进入确定的 INV 上下文环境。库存组织的作用是如此基础，以至于 EBS 的相关文档在提及组织（Org）概念时，如果未作特别说明，默认就是指 INV 组织。（五）公司成本中心（CostCenterCostCenterEBS 的所谓“成本中心组织”并没有业务处理的功能，它的设置主要是考虑与“会计科目弹性域结构”中的“公司段值”与“成本中心段值”的对应关系问题。如下图 29 所示：在系统中创建公司成本中心组织”后，可以运行一个并发检查程序”，以校验含计科目弹性域结构”中的段值是否与所有的公司成本中心”组织的设置保持一致。当在含

21、计科目弹性域结构”中的成本中心段”值集中添加 LOV 值并重新编译后，可以运行系统的“自动组织”并发程序功能，由系统自动创建“公司成本中心”组织。应当注意的是，一个公司成本中心组织及其成本中心段值，不可能属于不同法人实体 LE 及其公司段值，这与真实世界中的管理要求是一致的。库存组织 INV 与会计科目弹性域中的“成本中心”段（部门）则具有“一对一或多对一”的关系，即一个“成本中心”段值可以有多个库存组织 INV,但一个库存组织 INV 只能属于一个确定的成本中O（六）HRHR 组织系统的 HR 组织设置是与 HRM 模块的相关业务处理功能相关， 与核心业务/财务处理功能关系不大， 主要是需要

22、注意其是否和“成本中心”关联，需要时可以输入“成本中心”代码，其 LOV 就是“会计科目弹性域”结构中成本中心段的值集。如下图 30 所示：（七）多组织接入控制在图 30 的 EBS 组织设置界面中，所谓的组织“类型（Type）划分仅是基于组织自身的统计分析工作需要而定义的一个“维度”，例如“公司总部、产品线”等等，并不影响系统的业务处理功能。真正起作用的是设置界面中的“组织分类（Classification）,系统预置的组织分类 LOV 除了上述“业务组、法律实体、业务实体、库存组织”等之外，还有诸如“资产组织、运营公司、雇主”等等选项。在 EBS 系统中各应用模块所具有的业务处理功能通常需

23、构建在一个确定的“组织分类”之上，“组织”是相关业务处理功能的平台，企业是否需要作相关组织分类设置、如何设置，取决于企业所需要使用到的应用模块功能。例如所谓资产组织”的设置，它是在企业需使用到资产管理模块 FA 时才涉及到。“资产组织”实际上是所谓“资产账簿”的代名词，它只是表示有关资产信息的一个数据维度，作用主要在于分隔数据范围，用户进入系统作业务处理时，并不需要作上下文业务环境的切换。对于这类并不涉及“上下文”环境切换的所谓“组织，ORACL 繇统的设计主要是为了借用“组织”所具有的“层次结构（Hierarchy）概念来达到“多组织接入”权限的控制功能。需指出的是，这里的组织层次结构”与真

24、实世界企业的行政管理组织层次结构没有直接关系（尽管可能有所参考），它只是企业根据某种需要（如权限管理控制、数据统计汇报等）而人为设定的一个层次结构”，例如将系统中已经设置的任意数量的业务实体”或库存组织”等等组织 Name,人为地设定一个具有上下级关系、自顶向下的金字塔形多层结构。如下图 31 所示：上图中开始定义时，一旦选定（最）顶端组织 Name,则就只能为之分配下属组织 Name,如要给下属组织分配更下一级的组织，则需点击“向下”按钮，将当前该下属组织上升到“顶端组织”位置。点击“向上”按钮，则将当前“顶端组织”下降到下属组织位置。企业可以根据实际需要设定若干个具有不同内部结构的“组织层

25、次结构Name,以供定义系统所谓“安全性配置文件”时调用。如下图 32 所示：上图所定义安全性配置文件”是系统用以控制包括组织安全性”等在内的各种安全性控制的基础， 它具体规定了系统安全性控制的范围与实现方式，所有定义的安全性配置文件”Name 勾成系统多组织接入控制参数“MO:安全性配置文件”的 LOV。如下图 33 所示：EBS 通过“MO:业务实体”、“MO:安全性配置文件”、“MO:默认业务实体”这三个系统配置文件的共同作用，实现所谓“多组织接入”控制功能 MOAC 但上述三个配置文件在 R11 与 R12 中的作用有比较大的差别。对于“MO 业务实体”，在 R11 中必须设定，而且起

26、决定性控制作用，其 LOV 由系统基于创建的 OUname 自动创建，用户登录时系统自动定位于指定 OU。而在 R12 中，一旦设定“MO:安全性配置文件”，则此配置文件失效而不起作用。对于“MO 安全性配置文件”，在 R11 中虽有，但实际不起 OU 接入的控制作用，只针对 FA 等模块的得某些应用如数据统计等起作用。因此，一般认为 R11 并不具有完善的多组织接入控制功能。在 R12 中，该参数如果不设定，则必须设定“MO:业务实体”参数；一旦该参数被设定，则就起决定作用，系统主要依赖其实现 MOAC。对于“MO 默认业务实体”，在 R11 中虽有但实际不起作用。在 R12 中，随“MO:安全配置文件”起作用后才起作用，其 LOV 是所有已定义 OU,但如果设定值不在“MO:安全配置文件”所选择的“组织层次架构”的范围内，则仍不起作用（即在与 OU 相关诸如P。OM 等的 FORM 界面，OU 字段的默认值仍然为空）。这似乎是 ORACLE 系统设