oracle-ebs-组织架构介绍.docx

业务组（BG） 法律实体（LE） 业务实体（OU） 库存组织（INV） 公司成本中心（Cost Center） HR 组织 多组织接入控制 在企业管理实践的过程中，“组织”（Organization）一词是个经常需用到的概念，一般与“人员”与“职能”这两个要素密切相关， 反映某种行政管理关系，例如“财务部、销售部、采购部、生产部、仓储部”等等。企业内部行政组织（部门）的划分是企业基于“职 能驱动”业务管理模式进行运作的基础。目前，国内适用于小企业使用的大多数低端管理软件并不考虑系统中的“组织”设置问题， 其系统应用模块的划分，例如采购模块、仓管模块、销售模块等等，实际上就已经基本反映了企业运作的“组织职能”划分问题。 但是，对于业务复杂、规模较大的企业（如所谓“集团企业”），管理软件使用与实施的系统“组织设置”问题将是一个首要的重要问题。一个常 见的、也是错误的系统实现方式就是将企业的“行政组织设置”直接映射到系统中，以“行政组织”代替“业务组织”。这种系统实现方式虽有理解、 精选范本 掌握比较容易的优势，但却完全违背了大企业运作必须基于“流程驱动”业务模式的基本管理原则。国内有所谓高端管理软件在系统实施过程中，常常 出现有几十个财务、采购组织，几百个销售组织，乃至上千个库存组织的“盛况”，导致系统几乎没法使用的困境，其症结正在于此。 与企业的“行政组织”设置与人员规模密切相关且复杂多变不同，软件系统的“组织设置”必须以业务流程运作为核心，要求尽可能简单并保持相 对稳定，在公司（人员）规模扩大的过程中具有延续性与继承性。作为  ERP 鼻祖的 SAP 将系统组织简单地分为“集团（Client）、公司代码（Company Code）、采购组织（Purchase Org）、销售组织（Sale Org）、工厂（Plant）”等类别。ORACLE 的组织设置本质上与之基本相似， 但作为后来者作了进一步抽象与简化，系统组织划分为“业务组（Business Group）、法律实体（Legal Entity）、业务实体（Operating Unit）、库存组织（Inventory Org）”等。 如果说  SAP 的组织模型字面上多少还带有一点“行政组织”痕迹的话（这可能是某些声称学 SAP 的国内产品误入歧途的原因），ORACLE 系统的组织模型字面上已经几乎看不出与“行政组织”还有什么关系，其中的“Inventory Org”现今中文翻译成“库存组织”，容易 令人望文生义和企业的“仓库管理部门（Warehouse）”混淆，但 Inventory 的本义实际应该是“存货”，称之为“存货组织”或许更 好一些。如下图 22 所示 ORACLE 系统有关核心业务的多组织模型： 上图中的“财务、销售、采购”并非系统的“组织实体”，它仅表示业务实体（OU）具有的相关业务处理功能。“子库”是特殊的系统组织 实体，没有上下文环境可进入，主要表示库存组织之下的某种业务功能。 精选范本 （一）业务组（  BG） “业务组”的概念可以与企业的“集团”概念参看，但不同的是一个企业在系统中可以设置多个“业务组（集团）”。通常对 于一个企业来说，系统中有一个“业务组”就够了，这表示企业就是一个“集团公司”。而对于某些业务“多元化”的特大型公司（如 跨国公司），则可能需要在系统中设置多个“业务组”，表示企业由多个“集团公司”组成。 业务组设置是系统组织设置的第一步，是最高层级的组织形态，但它主要是与人力资源信息的分隔有关，即“人员信息”的设置在一个BG 范围内 是由各业务模块共享的（如果需要）。一旦系统设置的用户名（User）被与“人员”（Employee）关联，无论使用什么“责任”进入 系统，都会定位至一个确定的 BG 中，任何责任在任意时刻只能关联一个 BG。EBS 安装好后，系统里面已经预置了一个名为“Setup Business Group”的“初始业务组”。如图 23 所示系统预置的“Setup Business Group”： 当以系统预置超级用户  SYSADMIN 进入后，应首先设置一个具有在 HRM 或 INV 下创建组织功能的“责任”名，随后给此责任的“HR： User Type”配置文件设定值为“HR User”，则该责任就有了创建新 BG 的能力。通常需要一次性将企业所需要的 BG 全部建立，一般 另创建一个与企业名称一致如“某某集团”的新 BG 就可以了，也可以（不推荐）直接使用系统预设的“Setup Business Group”而不 创建新 BG。 精选范本 系统每新建一个  BG，就会自动在配置文件“HR：安全性配置文件”的 LOV 中自动添加一个与新建 BG 同名的可选值（初始时只有“Setup Business Gro