下载文档原格式
E B S组织架构RACLE EBS-组织架构介绍2010-08-07 19:22:42| 分类：名词解释|字号订阅（一）业务组（BG）（二）法律实体（LE）（三）业务实体（OU）（四）库存组织（INV）（五）公司成本中心（Cost Center）（六）HR组织（七）多组织接入控制在企业管理实践的过程中，“组织”（Organization）一词是个经常需用到的概念，一般与“人员”与“职能”这两个要素密切相关，反映某种行政管理关系，例如“财务部、销售部、采购部、生产部、仓储部”等等。
企业内部行政组织（部门）的划分是企业基于“职能驱动”业务管理模式进行运作的基础。
目前，国内适用于小企业使用的大多数低端管理软件并不考虑系统中的“组织”设置问题，其系统应用模块的划分，例如采购模块、仓管模块、销售模块等等，实际上就已经基本反映了企业运作的“组织职能”划分问题。
但是，对于业务复杂、规模较大的企业（如所谓“集团企业”），管理软件使用与实施的系统“组织设置”问题将是一个首要的重要问题。
一个常见的、也是错误的系统实现方式就是将企业的“行政组织设置”直接映射到系统中，以“行政组织”代替“业务组织”。
这种系统实现方式虽有理解、掌握比较容易的优势，但却完全违背了大企业运作必须基于“流程驱动”业务模式的基本管理原则。
国内有所谓高端管理软件在系统实施过程中，常常出现有几十个财务、采购组织，几百个销售组织，乃至上千个库存组织的“盛况”，导致系统几乎没法使用的困境，其症结正在于此。
与企业的“行政组织”设置与人员规模密切相关且复杂多变不同，软件系统的“组织设置”必须以业务流程运作为核心，要求尽可能简单并保持相对稳定，在公司（人员）规模扩大的过程中具有延续性与继承性。
作为ERP鼻祖的SAP将系统组织简单地分为“集团（Client）、公司代码（Company Code）、采购组织（Purchase Org）、销售组织（Sale Org）、工厂（Plant）”等类别。
EBS系统组织架构讲解EBS系统（Enterprise Business System，企业商业系统）的组织架构一般由多个部门和职能团队组成，以实现企业的信息化和数字化管理。
在这篇文章中，我将详细讲解EBS系统的组织架构，并介绍各个部门和团队的职责和作用。
1.研发部门：负责EBS系统的开发和维护工作。
该部门通常包括软件工程师、数据库管理员、系统分析师等技术人员，负责系统的设计、编码、测试和修复等工作。
研发团队需要根据用户需求和企业的业务流程，设计和实现各个功能模块，并确保系统的稳定性和安全性。
2.实施部门：负责EBS系统的实施和部署工作。
该部门通常包括顾问、项目经理、系统工程师等人员，负责与客户进行沟通和了解需求，制定系统实施计划，并负责系统的安装、配置和测试等工作。
实施团队需要与用户密切合作，确保系统能够满足用户的需求，并提供培训和支持。
3.运维部门：负责EBS系统的运行和维护工作。
该部门通常包括系统管理员、网络管理员、技术支持等人员，负责系统的日常运维、监控和故障处理等工作。
运维团队需要确保系统的可用性和性能，及时处理用户的问题和反馈，并定期进行系统升级和优化。
4.数据管理部门：负责EBS系统中的数据管理工作。
该部门通常包括数据分析师、数据管理员等人员，负责数据的采集、清洗、存储和分析等工作。
数据管理团队需要确保系统中的数据准确可靠，并通过数据分析提供决策支持和业务优化。
5.用户支持部门：负责EBS系统的用户支持和问题解答工作。
该部门通常包括客户服务人员、售后支持人员等，负责回答用户的问题、解决用户遇到的困难，并提供技术支持和培训。
用户支持团队需要时刻与用户保持沟通，及时解决用户的问题，并收集用户的反馈和需求。
此外，为了更好地管理和协调EBS系统的开发和运维工作，往往还会设立一个项目管理办公室（Project Management Office，简称PMO）。
PMO负责项目的规划、执行和监控，协调各个部门和团队之间的合作和沟通，提供项目管理的方法和工具，并负责项目的进度和质量的控制。
Oracle ebs 组织架构介绍SAP将系统组织简单地分为“集团（Client）、公司代码（Company Code）、采购组织（Purchase Org）、销售组织（Sale Org）、工厂（Plant）”等类别。
ORACLE的组织设置本质上与之基本相似，但作为后来者作了进一步抽象与简化，系统组织划分为“业务组（Business Group）、法律实体（Legal Entity）、业务实体（Operating Unit）、库存组织（Inventory Org）”等。
1、业务组【BG】参考“集团”概念，通常一个企业设置一个，对于业务多元化的特大型公司，可以设置多个。
当以系统预置超级用户SYSADMIN进入后，应首先设置一个具有在HRM或INV下创建组织功能的“责任”名，随后给此责任的“HR：User Type”配置文件设定值为“HR User”，则该责任就有了创建新BG的能力。
系统每新建一个BG，就会自动在配置文件“HR：安全性配置文件”的LOV中自动添加一个与新建BG同名的可选值（初始时只有“Setup Business Group”一个值）。
在某一个BG 下（初始为Setup Business Group）新建的任何责任，系统都将该责任的配置文件“HR：安全性配置文件”值默认为当前BG。
要在进入系统时能切换到新的BG，必须先修改该责任的“HR：安全性配置文件”设定值。
2、法律实体【LE】：对应于真实世界中的按国家法律法规要求注册的“法人公司”。
LE在组织FORM定义时，对于每个LE必须为其“法人主体会计科目”关联一个“帐套SOB”。
每个LE对应一个SOB，这与真实世界的法规要求是吻合的。
在定义“分类帐”时的“会计科目设置管理器”WEB中定义并分配法人实体LE。
一个分类帐设置（主辅分类帐）可以添加多个LE，但每个LE只能具有一个分类帐设置。
创建一个LE后，应当及时到会计科目弹性域结构中添加需要对应的公司段值LOV（一个或多个），并重新进行弹性域的编译，否则系统可能会弹出错误报警信息。
OＲACLE ＥBS 基础设置之组织架构四、组织架构在企业管理实践的过程中,“组织”(Oｒｇａnization)一词是个经常需用到的概念，一般与“人员”与“职能”这两个要素密切相关,反映某种行政管理关系,例如“财务部、销售部、采购部、生产部、仓储部”等等。
企业内部行政组织(部门)的划分是企业基于“职能驱动”业务管理模式进行运作的基础。
目前,国内适用于小企业使用的大多数低端管理软件并不考虑系统中的“组织”设置问题，其系统应用模块的划分，例如采购模块、仓管模块、销售模块等等,实际上就已经基本反映了企业运作的“组织职能”划分问题。
但是，对于业务复杂、规模较大的企业(如所谓“集团企业”）,管理软件使用与实施的系统“组织设置”问题将是一个首要的重要问题。
一个常见的、也是错误的系统实现方式就是将企业的“行政组织设置”直接映射到系统中，以“行政组织”代替“业务组织”。
这种系统实现方式虽有理解、掌握比较容易的优势，但却完全违背了大企业运作必须基于“流程驱动”业务模式的基本管理原则。
国内有所谓高端管理软件在系统实施过程中,常常出现有几十个财务、采购组织，几百个销售组织，乃至上千个库存组织的“盛况”，导致系统几乎没法使用的困境，其症结正在于此。
与企业的“行政组织”设置与人员规模密切相关且复杂多变不同,软件系统的“组织设置”必须以业务流程运作为核心,要求尽可能简单并保持相对稳定，在公司（人员）规模扩大的过程中具有延续性与继承性。
作为ERP鼻祖的SAP将系统组织简单地分为“集团（Clｉent)、公司代码(Ｃoｍpany Ｃode）、采购组织(Purcｈａse Org）、销售组织（ＳalｅOrg)、工厂（Pｌaｎｔ)”等类别。
OＲＡＣＬE的组织设置本质上与之基本相似,但作为后来者作了进一步抽象与简化,系统组织划分为“业务组（Busｉness Groｕp）、法律实体（Legａl Entity)、业务实体(Opeｒａｔiｎg Unｉt）、库存组织（InveｎtｏrｙＯrｇ）”等。
ORACLE EBS-组织架构介绍 (引用)2010年08月05日星期四 11:43（一）业务组（BG）（二）法律实体（LE）（三）业务实体（OU）（四）库存组织（INV）（五）公司成本中心（Cost Center）（六）HR组织（七）多组织接入控制在企业管理实践的过程中，“组织”（Organization）一词是个经常需用到的概念，一般与“人员”与“职能”这两个要素密切相关，反映某种行政管理关系，例如“财务部、销售部、采购部、生产部、仓储部”等等。
企业内部行政组织（部门）的划分是企业基于“职能驱动”业务管理模式进行运作的基础。
目前，国内适用于小企业使用的大多数低端管理软件并不考虑系统中的“组织”设置问题，其系统应用模块的划分，例如采购模块、仓管模块、销售模块等等，实际上就已经基本反映了企业运作的“组织职能”划分问题。
但是，对于业务复杂、规模较大的企业（如所谓“集团企业”），管理软件使用与实施的系统“组织设置”问题将是一个首要的重要问题。
一个常见的、也是错误的系统实现方式就是将企业的“行政组织设置”直接映射到系统中，以“行政组织”代替“业务组织”。
这种系统实现方式虽有理解、掌握比较容易的优势，但却完全违背了大企业运作必须基于“流程驱动”业务模式的基本管理原则。
国内有所谓高端管理软件在系统实施过程中，常常出现有几十个财务、采购组织，几百个销售组织，乃至上千个库存组织的“盛况”，导致系统几乎没法使用的困境，其症结正在于此。
与企业的“行政组织”设置与人员规模密切相关且复杂多变不同，软件系统的“组织设置”必须以业务流程运作为核心，要求尽可能简单并保持相对稳定，在公司（人员）规模扩大的过程中具有延续性与继承性。
作为ERP鼻祖的SAP将系统组织简单地分为“集团（Client）、公司代码（Company Code）、采购组织（Purchase Org）、销售组织（Sale Org）、工厂（Plant）”等类别。
Oracle EBS多组织结构ORACLE EBS-个很大的卖点是它的多组织结构. ORACLE EBS的文档资料里面解释呈现这样一个树型图：营运单元未完待续.接上.实际上，ORACLE电子商务套件中的组织属性可以分为如下几类：1. 业务组: 它代表组织结构的最高层次, 它分离了人力资源的信息. 例如, 当你查询人员时，它会列出所有分配给相应业务组的成员，而你自己所属于的组织只不过是业务组的一份子. 这样说可能造成一种误解：一个公司只能有一个业务组，实际上可能有多个，但是业务组之间不能共享信息.2. 帐簿：它其实不能称为一种组织，更象组织中的一个层次或性. 一个业务组中可以有一个或者多个帐簿.3. 法律实体：法律实体类型赋予组织税码以及其它与法律相关的属性. 一套帐簿可以分配给多个法律实体.4. 平衡实体：平衡实体就是帐户结构中的一个段，即平衡段. 在你准备财务报表的时候它体现你的帐户实体.5. 业务实体：如果一个组织应用到现金管理，订单管理，运输，应收，应付和采购模块，则它就是一个业务实体. 它可能是一个销售中心，一个分公司，或者一个部门. 对于这些应用，EBS按照法律实体分离了业务信息，每个用户只能访问到他自己所属于的业务实体的信息. 一个法律实体下面可以有一个或者多个业务实体.6. 库存组织：当一个组织要用到库存事物（例如接收，转移等），或者它要负责制造和分销产品时，这个组织就是一个库存组织. 它可能是一个制造厂，仓库，分销中心或者销售部门. 当用到下列模块时， EBS 按照库存组织来分割业务信息： Oracle Inventory， Bills of Material，Engineering， Work in Process， Master Scheduling/MRP， Capacity， and Purchasing receiving functions. 当你登陆到这些模块时， ORACLE EBS 会提示你选择一个库存组织. 同样，一个业务实体下面可以有一个或者多个库存组织.7. 人力资源组织：它体现了一个公司的基本工作结构. 只有当一个组织是人力资源组织时你才能分配人员给这个组织. 一个业务组中可以有一个或者多个人力资源组织.8. 资产组织：资产组织属性使组织可以执行与资产相关的功能. 只有当一个组织属于资产组织时，才能使用Oracle Assets.还需要说明一点的是：EBS的一个组织并非只能归属于一个类型•例如，例如，一个组织是一个业务实体，若在这个组织中要用到Oracle Inventory，那么它同时还是一个库存组织. 所以，组织类型代表了组织的一种属性，而不是把组织简单的分类.当你在实施的时候，可能用不同的模型来描述组织结构.当你在实施HR的时候，你可能会按照下图来描述:当你在实施制造，物流和财务的时候，你更加可能按下图所示去进行组织的设置可能设置一个或多个业务组，一个业务组下面可能包含一个或多个帐套，一个帐套下面可能有一个或多个业务实体（也就是多个子公司共用一个帐套）,一个业务实体下面可能有一个或多个业务机构，一个业务机构下面又可能有一个或多个库存组织，一个库存组织下面又可能有一个或多个子库存，在下面依次是库位和货架（相当于行和列）.这两种模型并非是孤立的，而应该综合考虑•例如，你设置一个业务组织，但同时你还要分配人员给这个组织，那么你同时还要把它设置为一个HR组织.接下来我们来讨论如何实施多组织结构，我们将遵循如下步骤：1．规划和描述组织结构。
EBS系统架构介绍及客户化开发纵览培训1 EBS 系统架构1.1 EBS R12 介绍EBS 应用架构图如下：1.2 总目录结构1.3 应用目录结构说明：Bin ：保存主机类并发程序；Forms：保存表单文件；Resource：保存资源类文件；Reports：保存报表文件。
US：英语版文件。
ZHS：中文版文件。
2 EBS 客户化开发纵览2.1 常用开发方法2.2 软件安装方法2.2.1 Developer Suit的安装点击Disk1 目录中的Setup.exe安装时注意事项：安装时选择简体中文。
安装类型选择“结束”安装后的设置：（1）设置资源文件路径资源文件在服务器的路径：$AU_TOP/resource 设置资源文件路径步骤：运行中输入：regedit，打开资源编辑器输入查询键值FORMS_PATH输入资源文件路径：2)TNS 文件中增加连接项连接项举例：CQTEST =(DESCRIPTION =(ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 10.9.168.60)(PORT = 1521)))(CONNECT_DA TA =(SERVICE_NAME = EBSTST )))(说明以上红字部分要修改)2.2.2 PL/SQL Developer 的安装运行安装：plsqldev711.exe安装后消除注册方法：把 crack 目录中文件把原文件覆盖。
2.2.3 XML Publisher Desktop 的安装安装前的条件 ： 安装有 JAVA 的 SDK 安装步骤 ：运行 setup安装后变化 ：Word中增加了一个菜单。
ORACLEEBS基础设置之组织架构ORACLE EBS（Enterprise Business Suite）是甲骨文公司开发的一款集成式企业资源规划（ERP）软件系统，可以帮助企业进行各类业务的管理和协调。
在使用ORACLE EBS之前，首先需要进行一系列的基础设置，其中之一就是组织架构的设置。
组织架构是指企业内部不同部门之间的关系和职责分工。
在ORACLEEBS中，通过设置组织架构可以实现企业内部各部门之间的协作和信息流动。
下面将详细介绍ORACLEEBS中组织架构的设置。
首先，要设置组织架构，需要在ORACLEEBS中创建组织。
组织可以包括多个级别，一般组织架构最高层级为公司，下面可以包括多个业务单元，每个业务单元下面又可以包括多个部门。
通过这样的层级结构可以实现不同组织之间的隔离和相互关联。
在创建组织时，需要输入组织的详细信息，包括组织名称、组织代码、组织类型等。
组织类型可以根据企业的实际情况进行设置，常见的组织类型包括公司、业务单元、地区、部门等。
通过设置不同的组织类型，可以实现对不同组织的不同管理需求。
在设置组织架构时，还可以设置组织之间的关系。
ORACLEEBS可以支持不同组织之间的父子关系、兄弟关系等。
通过设置组织之间的关系，可以实现信息的共享和协同，提高组织的工作效率。
在进行组织架构设置之后，还需要进行职责和职位的设置。
职责是指组织架构中不同部门或职位的职责和权限。
职位是指组织中不同职员所担任的职位。
通过设置职责和职位，可以实现对组织内部人员的权限管理和工作分配。
在设置职责和职位时，需要指定职责和职位的名称、描述、权限等信息。
通过设置不同的权限，可以限制不同职责和职位的操作范围，提高组织的安全性和保密性。
最后，还需要设置组织的层次结构和员工的隶属关系。
通过设置组织的层次结构，可以实现组织之间的上下级关系。
通过设置员工的隶属关系，可以将员工与特定的组织或职位进行关联，方便进行人员的管理和工作分配。
ORACLE EBS-组织架构介绍（一）业务组（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 Group”一个值）。
在某一个BG下（初始为Setup Business Group）新建的任何责任，系统都将该责任的配置文件“HR：安全性配置文件”值默认为当前BG。
要在进入系统时能切换到新的BG，必须先修改该责任的“HR：安全性配置文件”设定值。
如果将配置文件“HR：交叉业务组”的值设为“是”，则在不同BG下，新建的组织名称应当（虽然可以）不同，否则查看时可能会引起混淆。
在同一个BG下的所有新建组织，名称不允许相同。
（二）法律实体（LE）法律实体（LE，Legal Entity）对应于真实世界中的按国家法律法规要求注册的“法人公司”。
在R11中，LE在组织FORM定义时，对于每个LE必须为其“法人主体会计科目”关联一个“帐套SOB”。
每个LE对应一个SOB，这与真实世界的法规要求是吻合的。
如下图24所示：要注意的是，在R11中定义的LE时，并未作与“会计科目弹性域结构”的“公司段”值关联，用户必须对于其是与公司段值中的哪个值对应心中有数。
而在R12中，LE 的组织定义虽在FORM中仍然保留，但LE的“法人主体会计科目”的FORM设置被废弃（故FORM中定义了也无用），改为在定义“分类帐”时的“会计科目设置管理器”WEB 中定义并分配法人实体LE。
一个分类帐设置（主辅分类帐）可以添加多个LE，但每个LE只能具有一个分类帐设置。
如下图25所示：在R12中，还必须为法人实体分配会计科目弹性域结构的公司段即平衡段值。
每个LE可以分配多个“平衡段”值，公司段值集中每个段值一旦被分配给某LE，则其它LE 就不能再被分配。
在R11或R12中创建一个LE后，应当及时到会计科目弹性域结构中添加需要对应的公司段值LOV（一个或多个），并重新进行弹性域的编译，否则系统可能会弹出错误报警信息。
R12中一个LE对应多个公司平衡段值，代表有多个分公司，LE 是它们的合并。
主辅分类帐可拥有相同或不同的公司段值集，表示从不同的维度（如按地区、按产品等）去划分公司以方便考核。
如图26所示为LE添加平衡段值：无论是R11还是R12，法律实体LE的设置都对具体的业务处理影响不大，其与系统用户或责任不关联，不直接影响系统上下文的切换，故有人甚至认为EBS的LE设置作用不大。
这对于系统的内部运作来讲情况确实近似如此，但对于需要通过系统产生供外部使用的具有法律意义的文书（如采购订单、财务报表等等），严格区分法律实体LE还是必须的。
R12显然更多地考虑了外部使用的这种法律要求（即所谓“法规遵从性”或“合规性”），并在相关业务应用模块中有所体现。
（三）业务实体（OU）业务实体（OU，Operating Unit）是EBS系统组织设置的重点也是难点之一。
它与法人主体LE本身没有必然的关系，与会计科目弹性域结构中的“公司段”也没有直接关系。
从企业实际业务管理需要的角度去看，业务实体OU可以看作是在系统中按照业务的相似性，把多个不同公司（包括LE）的业务处理过程及数据划分成相对独立的“管理单元”。
在每个管理单元内部，各公司的业务运作共享相关数据并执行统一的业务策略。
例如，有一个业务多元化的企业既生产医院使用的X光机也生产普通电视机，并且其下属在全国各地有多家生产X光机或电视机的分公司、子公司。
由于这两种产品所使用的物料、供应商以及针对的客户群差异很大，企业为方便管理，可以将“业务运营”划分为两个相对独立的“业务管理群组”，对应到EBS系统中就是两个业务实体OU。
从企业日常业务运作管理的角度来看，对于单纯的电视机业务，全国范围内就设一个公司负责计划、生产、采购、销售等运营管理最为简便，但企业从非运营管理角度例如“税收优惠、地方政策”等等因素考虑，有时不得不在全国各地乃至世界各地注册若干所谓“公司”，以便向当地政府纳税并接受其财务会计方面的监管。
EBS在一个业务实体OU下，例如“电视机管理群组”，包含了全国各地所有负责生产或销售电视机的分公司、子公司（LE）的日常业务运作，在业务运作的组织层面忽略了作为法人实体的公司信息，但在反映业务运营最终结果的财务阶段（GL），仍能够方便地按照各地的法规要求提供财务数据与结果。
而对于负责具体业务的系统用户来说，日常工作几乎不用关心或考虑“公司”的设置问题。
EBS中LE的数量可以根据需要任意增加，但对于OU的数量基于管理方便性则要求尽可能精简。
EBS产品早期在实施过程中，存在一个公司（LE）对应一个OU的做法或一个OU只能属于一个LE的说法，这种做法或说法并不恰当。
某些国内产品的设计由于未能有效区分“法律实体（公司）”与“业务实体（运营）”两者在系统中既相连接又有本质区别的特殊关系，只好采取一个法人公司对应一个系统业务实体的“笨办法”，企业规模小倒还能对付，一旦规模变大，注册公司增多，所谓的“系统多组织架构”就变得根本不具可用性。
ORACLE EBS业务实体OU的这一系统特性极大地方便了企业运作的日常管理，具有高度的灵活性与可扩展性。
如下图27是R11的OU定义界面：图中的“业务实体信息”中，必须而且只能为之设定一个“帐套”，即一个OU只能属于一个帐套（反之，一个帐套可以分配给多个OU）。
要注意的是，上述业务实体信息中的法人实体设定，并不代表OU只能属于一个LE，它只是表示在“业务实体”中进行业务操作需要法人实体信息时提供默认值（在R12中明确了是“默认值”这一点）。
R12中的业务实体定义同R11基本相同，只是将帐套改为“主要分类帐”。
在EBS中，一个OU可以同时指定给多个LE，上面“电视机管理群组”的例子已经说明了这一点；一个LE也可以有多个OU，这相当于一个注册的法人实体公司下，有多个需要独立运营的“事业部”（如X光机和电视机）。
OU与LE是“多对多”的关系，但有一个限制性的前提条件，即OU与LE必须属于同一个SOB或Ledger。
由于LE与OU 的设置在系统中可以独立进行，因此如果双方的SOB或Ledger不同，则不能建立连接关系。
如果说法人实体LE与真实世界的企业行政管理组织架构还有点关系的话，业务实体OU则是与行政管理几乎无关，企业内部的行政组织变化对OU的设置没有直接影响。
