多组织架构

多组织架构

———————————————————————————————— 作者:

———————————————————————————————— 日期:

多组织架构

（一） 业务组（BG)

（二）法律实体(LE）

（三)业务实体（OU）

（四)库存组织(INＶ)

(五）公司成本中心（Cost Ｃentｅr)

（六）HR组织

（七）多组织接入控制

(八)一个集团下的全资子公司才可以设置为ＯＵ。若占百分比的,应设置为新的帐套。

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

但是,对于业务复杂、规模较大的企业（如所谓“集团企业”），管理软件使用与实施的

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

与企业的“行政组织”设置与人员规模密切相关且复杂多变不同，软件系统的“组织设置”必须以业务流程运作为核心，要求尽可能简单并保持相对稳定，在公司（人员）规模扩大的过程中具有延续性与继承性。作为ＥRP鼻祖的SAＰ将系统组织简单地分为“集团(Ｃlｉｅｎt)、公司代码（Company Codｅ）、采购组织（Purchａse Org)、销售组织（Ｓaｌe Ｏrg）、工厂（Plaｎt）”等类别。ORAＣLE的组织设置本质上与之基本相似，但作为后来者作了进一步抽象与简化,系统组织划分为“业务组(Busｉness Grouｐ)、法律实体(Legaｌ Ｅntity）、业务实体(Ｏｐｅｒating Ｕｎｉt)、库存组织（Ｉnventorｙ Org)”等。

如果说SＡP的组织模型字面上多少还带有一点“行政组织”痕迹的话(这可能是某些声称学SAP的国内产品误入歧途的原因），ＯＲACLE系统的组织模型字面上已经几乎看不出与“行政组织”还有什么关系，其中的“Invenｔｏry Oｒｇ”现今中文翻译成“库存组织”,容易令人望文生义和企业的“仓库管理部门（Warehｏuse)”混淆,但Iｎvｅｎtory的本义实际应该是“存货”，称之为“存货组织”或许更好一些。如下图22所示OＲACＬＥ系统有关核心业务的多组织模型:

上图中的“财务、销售、采购”并非系统的“组织实体”,它仅表示业务实体(OU)具有的相关业务处理功能。“子库”是特殊的系统组织实体，没有上下文环境可进入，主要表示库存组织之下的某种业务功能。

(一)业务组（BG）

“业务组”的概念可以与企业的“集团”概念参看,但不同的是一个企业在系统中可以设置多个“业务组(集团)”。通常对于一个企业来说,系统中有一个“业务组” 就够了,这表示企业就是一个“集团公司”。而对于某些业务“多元化”的特大型公司(如跨国公司)，则可能需要在系统中设置多个“业务组”，表示企业由多个 “集团公司”组成。

业务组设置是系统组织设置的第一步，是最高层级的组织形态，但它主要是与人力资源信息的分隔有关,即“人员信息”的设置在一个BG范围内是由各业务模块共享的(如果需

要)。一旦系统设置的用户名(Ｕser）被与“人员”(Ｅmplｏyeｅ)关联，无论使用什么“责任”进入系统,都会定位至一个确定的BＧ中，任何责任在任意时刻只能关联一个BG。EBS安装好后,系统里面已经预置了一个名为“Setuｐ Ｂｕsiｎesｓ Groｕp”的“初始业务组”。如图２3所示系统预置的“Seｔuｐ Ｂusｉnesｓ Ｇrｏup”：

当以系统预置超级用户SＹSADＭIＮ进入后,应首先设置一个具有在HRＭ或ＩNV下创建组织功能的“责任”名,随后给此责任的“ＨＲ:Useｒ Tyｐe”配置文件设定值为“HR User”，则该责任就有了创建新BG的能力。通常需要一次性将企业所需要的BG全部建立,一般另创建一个与企业名称一致如“某某集团”的新ＢG就可以了，也可以（不推荐）直接使用系统预设的“Seｔup Buｓiｎeｓs Gｒoup”而不创建新BG。

系统每新建一个BG，就会自动在配置文件“ＨR:安全性配置文件”的LOV中自动添加一个与新建BＧ同名的可选值（初始时只有“Setup Busiｎeｓｓ Groｕｐ”一个值)。

在某一个ＢG下(初始为Seｔup Busｉnesｓ Group)新建的任何责任,系统都将该责任的配置文件“HＲ：安全性配置文件”值默认为当前BG。要在进入系统时能切换到新的ＢG，必须先修改该责任的“HＲ:安全性配置文件”设定值。

如果将配置文件“HＲ:交叉业务组”的值设为“是”，则在不同ＢG下，新建的组织名称应当(虽然可以）不同,否则查看时可能会引起混淆。在同一个BG下的所有新建组织，名称不允许相同。

（二)法律实体（ＬE）

法律实体(ＬE,Lｅgal Ｅnｔity)对应于真实世界中的按国家法律法规要求注册的“法人公司”。在R11中,LＥ在组织FORM定义时,对于每个ＬE必须为其“法人主体会计科目”关联一个“帐套SOＢ”。每个ＬE对应一个SOＢ，这与真实世界的法规要求是吻合的。如下图2４所示：

要注意的是,在R11中定义的LＥ时，并未作与“会计科目弹性域结构”的“公司段”值关联，用户必须对于其是与公司段值中的哪个值对应心中有数。而在Ｒ12中，LE的组织定义虽在FＯRM中仍然保留，但ＬE的“法人主体会计科目”的FORM设置被废弃(故

FORＭ中定义了也无用），改为在定义“分类帐”时的“会计科目设置管理器”WEB中定义并分配法人实体ＬＥ。一个分类帐设置(主辅分类帐)可以添加多个LE，但每个LE只能具有一个分类帐设置。如下图２5所示：

在Ｒ12中,还必须为法人实体分配会计科目弹性域结构的公司段即平衡段值。每个LE可以分配多个“平衡段”值,公司段值集中每个段值一旦被分配给某LＥ，则其它LE就不能再被分配。在R11或R1２中创建一个LE后，应当及时到会计科目弹性域结构中添加需要对应的公司段值LOV(一个或多个)，并重新进行弹性域的编译,否则系统可能会弹出错误报警信息。Ｒ12中一个LE对应多个公司平衡段值，代表有多个分公司，ＬE是它们的合并。主辅分类帐可拥有相同或不同的公司段值集，表示从不同的维度（如按地区、按产品等)去划分公司以方便考核。如图26所示为ＬE添加平衡段值:

无论是R11还是Ｒ12,法律实体ＬE的设置都对具体的业务处理影响不大,其与系统用户或责任不关联，不直接影响系统上下文的切换,故有人甚至认为ＥBS的LＥ设置作用不大。这对于系统的内部运作来讲情况确实近似如此,但对于需要通过系统产生供外部使用的具有法律意义的文书(如采购订单、财务报表等等）,严格区分法律实体LＥ还是必须的。R12显然更多地考虑了外部使用的这种法律要求(即所谓“法规遵从性”或“合规性”)，并在相关业务应用模块中有所体现。

（三)业务实体(OU）

业务实体(OU,Ｏpｅraｔinｇ Unit)是ＥBＳ系统组织设置的重点也是难点之一。它与法人主体ＬE本身没有必然的关系，与会计科目弹性域结构中的“公司段”也没有直接关系。从企业实际业务管理需要的角度去看,业务实体OU可以看作是在系统中按照业务的相似性,把多个不同公司（包括LE）的业务处理过程及数据划分成相对独立的“管理单元”。

在每个管理单元内部，各公司的业务运作共享相关数据并执行统一的业务策略。

例如，有一个业务多元化的企业既生产医院使用的X光机也生产普通电视机,并且其下属在全国各地有多家生产Ｘ光机或电视机的分公司、子公司。由于这两种产品所使用的物料、供应商以及针对的客户群差异很大，企业为方便管理,可以将“业务运营”划分为两个相对独立的“业务管理群组”，对应到ＥＢＳ系统中就是两个业务实体OＵ。

从企业日常业务运作管理的角度来看,对于单纯的电视机业务，全国范围内就设一个公司负责计划、生产、采购、销售等运营管理最为简便,但企业从非运营管理角度 例如“税收优惠、地方政策”等等因素考虑，有时不得不在全国各地乃至世界各地注册若干所谓“公司”,以便向当地政府纳税并接受其财务会计方面的监管。

ＥBS在一个业务实体OU下,例如“电视机管理群组”,包含了全国各地所有负责生产或销售电视机的分公司、子公司（LＥ)的日常业务运作,在业务运作的组织层面忽略了作为法人实体的公司信息，但在反映业务运营最终结果的财务阶段（GL）,仍能够方便地按照各地的法规要求提供财务数据与结果。而对于负责具体业务的系统用户来说,日常工作几乎不用关心或考虑“公司”的设置问题。

ＥBS中LE的数量可以根据需要任意增加，但对于OU的数量基于管理方便性则要求尽可能精简。EＢS产品早期在实施过程中，存在一个公司(ＬＥ）对应一个OU的做法或一个ＯU只能属于一个LE的说法,这种做法或说法并不恰当。某些国内产品的设计由于未能有效区分“法律实体（公司)”与“业务实体(运营)”两者在系统中既相连接又有本质区别的特殊关系,只好采取一个法人公司对应一个系统业务实体的“笨办法”,企业规模小倒还能对付,一旦规模变大,注册公司增多，所谓的“系统多组织架构”就变得根本不具可用性。

ORACLＥ EＢS业务实体ＯU的这一系统特性极大地方便了企业运作的日常管理,具有高度的灵活性与可扩展性。如下图27是R1１的OU定义界面:

图中的“业务实体信息”中,必须而且只能为之设定一个“帐套”,即一个OＵ只能属于一个帐套(反之，一个帐套可以分配给多个OU)。要注意的是，上述业务实体信息中的法人实体设定,并不代表OU只能属于一个LE，它只是表示在“业务实体”中进行业务操作需要法人实体信息时提供默认值（在Ｒ12中明确了是“默认值”这一点）。R1２中的业务实体定义同R11基本相同，只是将帐套改为“主要分类帐”。

在EBＳ中，一个OU可以同时指定给多个LE,上面“电视机管理群组”的例子已经说明了这一点;一个LE也可以有多个OＵ,这相当于一个注册的法人实体公司下,有多个需要独立运营的“事业部”(如Ｘ光机和电视机）。OU与LE是“多对多”的关系，但有一个限制性的前提条件，即OU与ＬＥ必须属于同一个SOB或Ledgｅr。由于LE与OU的设置在系统中可以独立进行,因此如果双方的SOB或Ledger不同,则不能建立连接关系。

如果说法人实体ＬE与真实世界的企业行政管理组织架构还有点关系的话,业务实体OU则是与行政管理几乎无关,企业内部的行政组织变化对OU的设置没有直接影响。在ＥＢＳ中有关采购管理、销售订单履行、应收应付管理等业务模块的功能均是建立在ＯＵ基础之上的。用户在执行上述相关模块的业务处理时,总是必须进入确定的ＯＵ(上下文环境)才可以进行,EＢS的所谓“多组织”功能（ＭOAＣ)也是针对多OU而言的，与真实世界中的“多公司”（LE）没有直接关系。

实际上，SAＰ的“采购组织、销售组织”设置也是与真实世界的行政组织“采购部、销售部”无关的，ORACＬE抛弃了“采购组织、销售组织”的概念,OＵ实际上就起到了类似的组织分隔作用。ORＡCLＥ的某些相关文档中，如果因描述需要而提及所谓“采购组织、销售组织”等概念,有时实际指的就是业务实体ＯＵ(或OU下的库存INV组织)。

（四)库存组织（IＮV)

ORＡＣＬE EBS的库存组织(INV）是系统组织设置的最基础、也是最重要的工作之一。库存组织的内涵远不是真实世界的“仓库部门”那么简单,它除了是有关“物料接收与发出”等业务功能的基础之外,更重要的是，它还是EBS系统有关计划(MPＳ／MＲP）、在制品管理（WIＰ）、物料清单(BＯM)等模块业务功能的操作与管理平台。如下图2８所示:

EBS中的库存组织IＮV的作用与功能可以与SAＰ中的工厂Ｐlant参看。一个库存组织ＩＮV只能属于一个确定的帐套SOB、一个确定的法人实体LＥ、一个确定的业务实体OＵ,具有唯一性的关系（注意:R11的设置界面未考虑SＯB/LE/ＯＵ的关联限定，容易产

生错误;Ｒ1２作了改进,在选定Ledgｅr之后，可用的LE／OU就被限定)。反之，一个“帐套/法人实体/业务实体”组合则可以有多个库存组织INV。此外，一个ＯＵ下的多个INV可以对应属于该OU的不同ＬE，这相当于将分属于两个法人公司的生产两种产品的四个工厂,按相同产品两两组合抽取出来，分属于两个不同OU进行日常业务管理。

在EBＳ中还有两个组织概念“MRP组织、WIP组织”,它们实际是必须构建于库存组织之上的组织概念，表示该库存组织还可以进行MRP或WＩP的功能。系统之所以如此处理,主要是为了控制某些ＩNV不能做ＭＲＰ或ＷIＰ而已，因为基于物料接收或发出需要所设定的ＩＮＶ数量可能比较多。

对于绝大多数基于库存组织ＩNＶ的业务功能（个别除外),系统用户在做业务操作时,均必须首先进行INV的选择切换，以便进入确定的ＩNV上下文环境。库存组织的作用是如此基础，以至于EBS的相关文档在提及组织(Orｇ)概念时,如果未作特别说明，默认就是指INV组织。

（五)公司成本中心（Cｏst Ｃentｅr)

ＥBＳ的所谓“成本中心组织”并没有业务处理的功能，它的设置主要是考虑与“会计科目弹性域结构”中的“公司段值”与“成本中心段值”的对应关系问题。如下图２９所示:

在系统中创建“公司成本中心组织”后，可以运行一个“并发检查程序”,以校验“会计科目弹性域结构”中的段值是否与所有的“公司成本中心”组织的设置保持一致。

当在“会计科目弹性域结构”中的“成本中心段”值集中添加LOV值并重新编译后,可以运行系统的“自动组织”并发程序功能,由系统自动创建“公司成本中心”组织。

应当注意的是,一个公司成本中心组织及其成本中心段值,不可能属于不同法人实体LＥ及其公司段值，这与真实世界中的管理要求是一致的。库存组织ＩNV与会计科目弹性域中的“成本中心”段(部门）则具有“一对一或多对一”的关系，即一个“成本中心”段值可以有多个库存组织INＶ，但一个库存组织INV只能属于一个确定的成本中心。

(六)ＨR组织

系统的ＨR组织设置是与HRM模块的相关业务处理功能相关，与核心业务/财务处理功能关系不大,主要是需要注意其是否和“成本中心”关联,需要时可以输入“成本中心”代码，其LOV就是“会计科目弹性域”结构中成本中心段的值集。如下图30所示:

(七）多组织接入控制

在图30的ＥBS组织设置界面中，所谓的组织“类型”（Type)划分仅是基于组织自身

的统计分析工作需要而定义的一个“维度”,例如“公司总部、产品线”等等，并不影响系统的业务处理功能。真正起作用的是设置界面中的“组织分类”(Cｌassiｆicａtion)，系统预置的组织分类ＬOＶ除了上述“业务组、法律实体、业务实体、库存组织”等之外,还有诸如“资产组织、运营公司、雇主”等等选项。在ＥBS系统中各应用模块所具有的业务处理功能通常需构建在一个确定的“组织分类”之上,“组织”是相关业务处理功能的平台,企业是否需要作相关组织分类设置、如何设置,取决于企业所需要使用到的应用模块功能。

例如所谓“资产组织”的设置,它是在企业需使用到资产管理模块FA时才涉及到。“资产组织”实际上是所谓“资产账簿”的代名词,它只是表示有关资产信息的一个数据维度,作用主要在于分隔数据范围，用户进入系统作业务处理时，并不需要作上下文业务环境的切换。对于这类并不涉及“上下文”环境切换的所谓“组织”，ORACLＲ系统的设计主要是为了借用“组织”所具有的“层次结构”（Hｉｅraｒchy）概念来达到“多组织接入”权限的控制功能。

需指出的是，这里的组织“层次结构”与真实世界企业的行政管理组织层次结构没有直接关系（尽管可能有所参考）,它只是企业根据某种需要(如权限管理控制、数据统计汇报等)而人为设定的一个“层次结构”，例如将系统中已经设置的任意数量的“业务实体”或“库存组织”等等组织Nａme，人为地设定一个具有上下级关系、自顶向下的金字塔形多层结构。如下图３1所示:

上图中开始定义时,一旦选定(最)顶端组织Name,则就只能为之分配下属组织Name,如要给下属组织分配更下一级的组织，则需点击“向下”按钮,将当前该下属组织上升到“顶

端组织”位置。点击“向上”按钮，则将当前“顶端组织”下降到下属组织位置。企业可以根据实际需要设定若干个具有不同内部结构的“组织层次结构”Naｍe,以供定义系统所谓“安全性配置文件”时调用。如下图３2所示:

上图所定义“安全性配置文件”是系统用以控制包括“组织安全性”等在内的各种安全性控制的基础，它具体规定了系统安全性控制的范围与实现方式，所有定义的“安全性配置文件”Nａme构成系统多组织接入控制参数“ＭO：安全性配置文件”的LOＶ。如下图33所示:

EＢS 通过“MＯ：业务实体”、“MO:安全性配置文件”、“ＭO:默认业务实体”这三个系统配置文件的共同作用,实现所谓“多组织接入”控制功能MＯAC。但上述三个配置文件在R1１与R１２中的作用有比较大的差别。

对于“MO：业务实体”, 在R11中必须设定，而且起决定性控制作用，其ＬOV由系统基于创建的ＯＵ name自动创建,用户登录时系统自动定位于指定ＯU。而在R１2中，一旦设定“ＭO：安全性配置文件”，则此配置文件失效而不起作用。

对于“MO:安全性配置文件”, 在R11中虽有,但实际不起OU接入的控制作用,只针对FA等模块的得某些应用如数据统计等起作用。因此,一般认为R11并不具有完善的多组织接入控制功能。在R12中,该参数如果不设定,则必须设定“MO:业务实体”参数；一旦该参数被设定,则就起决定作用,系统主要依赖其实现MOAC。

对于“MＯ：默认业务实体”， 在R1１中虽有但实际不起作用。在R１2中，随“MO：安全配置文件”起作用后才起作用，其LOV是所有已定义OＵ,但如果设定值不在“MO:安全配置文件”所选择的“组织层次架构”的范围内,则仍不起作用（即在与OU相关诸如PO、ＯM等的FORM界面，OＵ字段的默认值仍然为空）。这似乎是ORAＣLE 系统设计方面的一个难题，即“MO：默认业务实体”的ＬOV值集无法与“MO:安全性配置文件”中“组织层次架构”中的ＯU值范围保持一致。

ORＡCＬE强调其“多组织接入MOAC”功能主要是针对业务实体OU而言，其另外一层含义是,所有构建于库存组织ＩＮV上的应用功能，实际是与上述配置文件无关的。库存组织的可接入性是在“组织访问”控制功能中，专门设定“库存组织”与“责任”的关联性,如下图34所示：

按照OＲACLE的说法，如果系统在初始的时候,不定义库存组织的“组织访问”控制,则所有“责任”可访问所有IＮV，一旦限制或分配其中一个,则其余均必须逐个进行分配以建立“库存组织”与“责任”的链接关系。

总之，ＥＢS系统通过“弹性域段值安全性”、“帐套／分类帐安全性”、“多组织接入安全性（MＯAＣ）”、“库存组织访问控制”等多维度、多方面的组合系统设置,提供了灵活、方便的用户权限管理功能,厘清并掌握它们的复杂关系是系统实施的一项重要基础性工作。

（一)业务组(BG)

（二)法律实体（LE)

（三）业务实体(OＵ）

(四）库存组织（IＮV)

(五)公司成本中心（Coｓｔ Center)

(六)HR组织

(七）多组织接入控制

在企业管理实践的过程中，“组织”(Oｒganｉzatｉoｎ） 一词是个经常需用到的概念，一般与“人员”与“职能”这两个要素密切相关,反映某种行政管理关系，例如“财务部、销售部、采购部、生产部、仓储部”等等。 企业内部行政组织（部门）的划分是企业基于“职能驱动”业务管理模式进行运作的基础。目前，国内适用于小企业使用的大多数低端管理软件并不考虑系统中的 “组织”设置问题，其系统应用模块的划分,例如采购模块、仓管模块、销售模块等等，实际上就已经基本反映了企业运作的“组织职能”划分问题。

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

与企业的“行政组织”设置与人员规模密切相关且复杂多变不同，软件系统的“组织

设置”必须以业务流程运作为核心,要求尽可能简单并保持相对稳定，在公司(人员)规模扩大的过程中具有延续性与继承性。作为ＥRP鼻祖的SAP将系统组织简单地分为“集团(Cｌient）、公司代码（Company Code)、采购组织(Puｒchase Ｏｒｇ）、销售组织(Saｌe Orｇ）、工厂（Plant）”等类别。ORACLE的组织设置本质上与之基本相似,但作为后来者作了进一步抽象与简化,系统组织划分为“业务组(Businｅss Ｇrouｐ)、法律实体（Legal Enｔiｔy）、业务实体(Opｅrａｔiｎg Unit)、库存组织(Ｉｎveｎtｏry Ｏｒg）”等。

如果说SAP的组织模型字面上多少还带有一点“行政组织”痕迹的话(这可能是某些声称学ＳAP的国内产品误入歧途的原因）,ORAＣLE系统的组织模型字面上已经几乎看不出与“行政组织”还有什么关系，其中的“Inventorｙ Org”现今中文翻译成“库存组织”，容易令人望文生义和企业的“仓库管理部门(Ｗａrehｏuse）”混淆,但Iｎventｏry的本义实际应该是“存货”,称之为“存货组织”或许更好一些。如下图２2所示ORACLＥ系统有关核心业务的多组织模型：

上图中的“财务、销售、采购”并非系统的“组织实体”,它仅表示业务实体（OU）具有的相关业务处理功能。“子库”是特殊的系统组织实体,没有上下文环境可进入,主要表示库存组织之下的某种业务功能。

（一)业务组（ＢG)

“业 务组”的概念可以与企业的“集团”概念参看，但不同的是一个企业在系统中可以设置多个“业务组(集团)”。通常对于一个企业来说，系统中有一个“业务组” 就够了，这表示企业就是一个“集团公司”。而对于某些业务“多元化”的特大型公司(如跨国公司)，则可能需要在系统中设置多个“业务组”,表示企业由多个 “集团公司”组成。

业务组设置是系统组织设置的第一步，是最高层级的组织形态，但它主要是与人力资源信息的分隔有关，即“人员信息”的设置在一个BG范围内是由各业务模块共享的(如果需要)。一旦系统设置的用户名(User)被与“人员”（Employee）关联,无论使用什么“责任”进入系统,都会定位至一个确定的BG中，任何责任在任意时刻只能关联一个BG。EＢS安装好后,系统里面已经预置了一个名为“Ｓetup Buｓinｅss Groｕp”的“初始业务组”。如图2３所示系统预置的“Ｓetup Buｓinｅss Gｒoup”:

当以系统预置超级用户SＹSAＤMIN进入后,应首先设置一个具有在HＲM或ＩNV下创建组织功能的“责任”名,随后给此责任的“ＨＲ：Uｓeｒ Tｙpｅ”配置文件设定值为“HＲ Usｅr”,则该责任就有了创建新BＧ的能力。通常需要一次性将企业所需要的BG全部建立,一般另创建一个与企业名称一致如“某某集团”的新ＢG就可以了,也可以(不推荐)直接使用系统预设的“Setup Buｓiness Group”而不创建新BＧ。

系统每新建一个BG,就会自动在配置文件“ＨR：安全性配置文件”的LOV中自动添加一个与新建BＧ同名的可选值（初始时只有“Setuｐ Businｅｓs Ｇｒｏｕp”一个值）。在某一个BG下(初始为Sｅtuｐ Businｅss Ｇｒoｕｐ)新建的任何责任，系统都将该责任的配置文件“ＨＲ：安全性配置文件”值默认为当前BG。要在进入系统时能切换到新的BG,必须先修改该责任的“HR：安全性配置文件”设定值。

如果将配置文件“HR：交叉业务组”的值设为“是”,则在不同BG下,新建的组织名称应当（虽然可以)不同,否则查看时可能会引起混淆。在同一个BG下的所有新建组织,名称不允许相同。

（二)法律实体（LE)

法律实体(LE，Lｅｇal Entitｙ)对应于真实世界中的按国家法律法规要求注册的“法人公司”。在R11中,LE在组织ＦＯRＭ定义时,对于每个LE必须为其“法人主体会计科目”关联一个“帐套ＳＯB”。每个LE对应一个SOB，这与真实世界的法规要求是吻合的。如下图24所示：

要注意的是,在R１1中定义的ＬE时，并未作与“会计科目弹性域结构”的“公司段”值关联,用户必须对于其是与公司段值中的哪个值对应心中有数。而在R１２中，LE的组织定义虽在FOＲＭ中仍然保留，但LE的“法人主体会计科目”的FOＲＭ设置被废弃(故

FORM中定义了也无用),改为在定义“分类帐”时的“会计科目设置管理器”WEB中定义并分配法人实体LＥ。一个分类帐设置(主辅分类帐）可以添加多个LＥ，但每个LE只能具有一个分类帐设置。如下图25所示:

在R1２中，还必须为法人实体分配会计科目弹性域结构的公司段即平衡段值。每个LE可以分配多个“平衡段”值，公司段值集中每个段值一旦被分配给某ＬE,则其它LＥ就不能再被分配。在Ｒ11或R１2中创建一个ＬＥ后,应当及时到会计科目弹性域结构中添加需要对应的公司段值LＯV(一个或多个），并重新进行弹性域的编译，否则系统可能会弹出错误报警信息。R12中一个LＥ对应多个公司平衡段值，代表有多个分公司，LE是它们的合并。主辅分类帐可拥有相同或不同的公司段值集，表示从不同的维度（如按地区、按产品等)去划分公司以方便考核。如图26所示为LE添加平衡段值:

无论是R1１还是R12，法律实体LＥ的设置都对具体的业务处理影响不大,其与系统用户或责任不关联,不直接影响系统上下文的切换,故有人甚至认为EＢS的LE设置作用不大。这对于系统的内部运作来讲情况确实近似如此，但对于需要通过系统产生供外部使用的具有法律意义的文书(如采购订单、财务报表等等）,严格区分法律实体LE还是必须的。R１2显然更多地考虑了外部使用的这种法律要求(即所谓“法规遵从性”或“合规性”）,并在相关业务应用模块中有所体现。

（三）业务实体(OU)

业务实体（OＵ，Opｅraｔing Uｎit）是EBＳ系统组织设置的重点也是难点之一。它与法人主体LE本身没有必然的关系,与会计科目弹性域结构中的“公司段”也没有直接关系。从企业实际业务管理需要的角度去看，业务实体OU可以看作是在系统中按照业务的相似性,把多个不同公司(包括LE）的业务处理过程及数据划分成相对独立的“管理单元”。

在每个管理单元内部，各公司的业务运作共享相关数据并执行统一的业务策略。

例如,有一个业务多元化的企业既生产医院使用的X光机也生产普通电视机,并且其下属在全国各地有多家生产X光机或电视机的分公司、子公司。由于这两种产品所使用的物料、供应商以及针对的客户群差异很大,企业为方便管理，可以将“业务运营”划分为两个相对独立的“业务管理群组”，对应到EBS系统中就是两个业务实体OU。

从 企业日常业务运作管理的角度来看,对于单纯的电视机业务,全国范围内就设一个公司负责计划、生产、采购、销售等运营管理最为简便，但企业从非运营管理角度 例如“税收优惠、地方政策”等等因素考虑，有时不得不在全国各地乃至世界各地注册若干所谓“公司”,以便向当地政府纳税并接受其财务会计方面的监管。

EＢＳ在一个业务实体OU下,例如“电视机管理群组”，包含了全国各地所有负责生产或销售电视机的分公司、子公司(LE）的日常业务运作,在业务运作的组织层面忽略了作为法人实体的公司信息，但在反映业务运营最终结果的财务阶段(GL)，仍能够方便地按照各地的法规要求提供财务数据与结果。而对于负责具体业务的系统用户来说，日常工作几乎不用关心或考虑“公司”的设置问题。

EBS中LE的数量可以根据需要任意增加,但对于OU的数量基于管理方便性则要求尽可能精简。EBS产品早期在实施过程中,存在一个公司(LE）对应一个OＵ的做法或一个ＯＵ只能属于一个LE的 说法，这种做法或说法并不恰当。某些国内产品的设计由于未能有效区分“法律实体(公司）”与“业务实体（运营)”两者在系统中既相连接又有本质区别的特殊 关系,只好采取一个法人公司对应一个系统业务实体的“笨办法”，企业规模小倒还能对付，一旦规模变大，注册公司增多，所谓的“系统多组织架构”就变得根本 不具可用性。

ORAＣＬE EBＳ业务实体OU的这一系统特性极大地方便了企业运作的日常管理,具有高度的灵活性与可扩展性。如下图27是R１1的OＵ定义界面：

图中的“业务实体信息”中,必须而且只能为之设定一个“帐套”，即一个OU只能属于一个帐套（反之,一个帐套可以分配给多个ＯU)。要注意的是,上述业务实体信息中的法人实体设定，并不代表OU只能属于一个LＥ,它只是表示在“业务实体”中进行业务操作需要法人实体信息时提供默认值（在R1２中明确了是“默认值”这一点）。Ｒ12中的业务实体定义同Ｒ１1基本相同，只是将帐套改为“主要分类帐”。

在ＥBS中，一个OU可以同时指定给多个LE,上面“电视机管理群组”的例子已经说明了这一点;一个LＥ也可以有多个ＯU,这相当于一个注册的法人实体公司下，有多个需要独立运营的“事业部”（如X光机和电视机)。OU与LE是“多对多”的关系，但有一个限制性的前提条件，即OU与LE必须属于同一个SOＢ或Ｌedger。由于LＥ与OU的设置在系统中可以独立进行，因此如果双方的ＳOB或Ledgeｒ不同,则不能建立连接关系。

如果说法人实体LE与真实世界的企业行政管理组织架构还有点关系的话，业务实体ＯU则是与行政管理几乎无关，企业内部的行政组织变化对OU的设置没有直接影响。在EBS中有关采购管理、销售订单履行、应收应付管理等业务模块的功能均是建立在ＯU基础之上的。用户在执行上述相关模块的业务处理时,总是必须进入确定的OU(上下文环境)才可以进行,EＢS的所谓“多组织”功能（MOAＣ）也是针对多OＵ而言的,与真实世界中的“多公司”（ＬＥ）没有直接关系。

实际上,SAP的“采购组织、销售组织”设置也是与真实世界的行政组织“采购部、销售部”无关的，ORACLE抛弃了“采购组织、销售组织”的概念，OU实际上就起到了类似的组织分隔作用。ORACLＥ的某些相关文档中，如果因描述需要而提及所谓“采购组织、销售组织”等概念，有时实际指的就是业务实体OU(或OU下的库存INV组织)。

(四）库存组织（IＮV）

ＯRACLE EＢS的库存组织（IＮV）是系统组织设置的最基础、也是最重要的工作之一。库存组织的内涵远不是真实世界的“仓库部门”那么简单，它除了是有关“物料接收与发出”等业务功能的基础之外,更重要的是,它还是EBS系统有关计划(MPS/MRＰ）、在制品管理（WIP)、物料清单(BOM)等模块业务功能的操作与管理平台。如下图28所示:

EBS中的库存组织IＮV的作用与功能可以与SAP中的工厂Ｐlａｎt参看。一个库存组织IＮV只能属于一个确定的帐套SOB、一个确定的法人实体ＬE、一个确定的业务实体OU，具有唯一性的关系(注意：Ｒ11的设置界面未考虑ＳOＢ/LE／OU的关联限定，容易

产生错误;R12作了改进，在选定Ｌｅｄｇer之后,可用的ＬＥ/OＵ就被限定）。反之，一个“帐套/法人实体/业务实体”组合则可以有多个库存组织INV。此外，一个OＵ下的多个INV可以对应属于该OU的不同LE,这相当于将分属于两个法人公司的生产两种产品的四个工厂,按相同产品两两组合抽取出来,分属于两个不同ＯU进行日常业务管理。

在EBS中还有两个组织概念“MRＰ组织、ＷIP组织”，它们实际是必须构建于库存组织之上的组织概念，表示该库存组织还可以进行ＭRＰ或WＩＰ的功能。系统之所以如此处理,主要是为了控制某些INV不能做ＭＲP或WIＰ而已,因为基于物料接收或发出需要所设定的IＮV数量可能比较多。

对于绝大多数基于库存组织IＮV的业务功能（个别除外），系统用户在做业务操作时,均必须首先进行INV的选择切换，以便进入确定的ＩNV上下文环境。库存组织的作用是如此基础,以至于EBＳ的相关文档在提及组织（Org）概念时,如果未作特别说明，默认就是指INV组织。

（五)公司成本中心（Cost Center）

ＥBS的所谓“成本中心组织”并没有业务处理的功能,它的设置主要是考虑与“会计科目弹性域结构”中的“公司段值”与“成本中心段值”的对应关系问题。如下图２９所示：

在系统中创建“公司成本中心组织”后，可以运行一个“并发检查程序”,以校验“会计科目弹性域结构”中的段值是否与所有的“公司成本中心”组织的设置保持一致。

当在“会计科目弹性域结构”中的“成本中心段”值集中添加LOV值并重新编译后,可以运行系统的“自动组织”并发程序功能，由系统自动创建“公司成本中心”组织。

应当注意的是,一个公司成本中心组织及其成本中心段值，不可能属于不同法人实体ＬE及其公司段值，这与真实世界中的管理要求是一致的。库存组织ＩNV与会计科目弹性域中的“成本中心”段(部门)则具有“一对一或多对一”的关系，即一个“成本中心”段值可以有多个库存组织INV,但一个库存组织INV只能属于一个确定的成本中心。

(六)HR组织

系统的HR组织设置是与HＲM模块的相关业务处理功能相关,与核心业务／财务处理功能关系不大，主要是需要注意其是否和“成本中心”关联，需要时可以输入“成本中心”代码,其LOＶ就是“会计科目弹性域”结构中成本中心段的值集。如下图3０所示：

(七)多组织接入控制

在图3０的ＥＢS组织设置界面中,所谓的组织“类型”（Type）划分仅是基于组织自身

的统计分析工作需要而定义的一个“维度”，例如“公司总部、产品线”等等，并不影响系统的业务处理功能。真正起作用的是设置界面中的“组织分类”(Claｓsifｉｃation），系统预置的组织分类LOＶ除了上述“业务组、法律实体、业务实体、库存组织”等之外,还有诸如“资产组织、运营公司、雇主”等等选项。在EBS系统中各应用模块所具有的业务处理功能通常需构建在一个确定的“组织分类”之上，“组织”是相关业务处理功能的平台,企业是否需要作相关组织分类设置、如何设置，取决于企业所需要使用到的应用模块功能。

例如所谓“资产组织”的设置,它是在企业需使用到资产管理模块ＦA时才涉及到。“资产组织”实际上是所谓“资产账簿”的代名词,它只是表示有关资产信息的一个数据维度，作用主要在于分隔数据范围,用户进入系统作业务处理时，并不需要作上下文业务环境的切换。对于这类并不涉及“上下文”环境切换的所谓“组织”,ORACLＲ系统的设计主要是为了借用“组织”所具有的“层次结构”（Hiｅraｒchy）概念来达到“多组织接入”权限的控制功能。

需指出的是,这里的组织“层次结构”与真实世界企业的行政管理组织层次结构没有直接关系(尽管可能有所参考），它只是企业根据某种需要（如权限管理控制、数据统计汇报等)而人为设定的一个“层次结构”,例如将系统中已经设置的任意数量的“业务实体”或“库存组织”等等组织Name,人为地设定一个具有上下级关系、自顶向下的金字塔形多层结构。如下图31所示：

上图中开始定义时,一旦选定（最)顶端组织Nａｍe，则就只能为之分配下属组织Naｍe，如要给下属组织分配更下一级的组织，则需点击“向下”按钮，将当前该下属组织上

升到“顶端组织”位置。点击“向上”按钮，则将当前“顶端组织”下降到下属组织位置。企业可以根据实际需要设定若干个具有不同内部结构的“组织层次结构”Name，以供定义系统所谓“安全性配置文件”时调用。如下图32所示:

上图所定义“安全性配置文件”是系统用以控制包括“组织安全性”等在内的各种安全性控制的基础，它具体规定了系统安全性控制的范围与实现方式，所有定义的“安全性配置文件”Name构成系统多组织接入控制参数“MO：安全性配置文件”的ＬOV。如下图3３所示:

EBＳ 通过“MＯ：业务实体”、“ＭO：安全性配置文件”、“MＯ:默认业务实体”这三个系统配置文件的共同作用，实现所谓“多组织接入”控制功能ＭＯＡC。但上述三个配置文件在Ｒ11与R12中的作用有比较大的差别。

对于“ＭO:业务实体”， 在R11中必须设定，而且起决定性控制作用，其LＯV由系统基于创建的ＯU naｍe自动创建,用户登录时系统自动定位于指定ＯU。而在R１2中，一旦设定“MＯ：安全性配置文件”，则此配置文件失效而不起作用。

对于“MO:安全性配置文件”, 在Ｒ1１中虽有，但实际不起OU接入的控制作用，只针对FＡ等模块的得某些应用如数据统计等起作用。因此，一般认为R11并不具有完善的多组织接入控制功能。在R12中，该参数如果不设定，则必须设定“MO:业务实体”参数;一旦该参数被设定，则就起决定作用，系统主要依赖其实现MＯAC。

对于“MO:默认业务实体”, 在R11中虽有但实际不起作用。在Ｒ12中,随“MO:安全配置文件”起作用后才起作用,其ＬOV是所有已定义ＯU，但如果设定值不在“MO：安全配置文件”所选择的“组织层次架构”的范围内，则仍不起作用(即在与ＯU相关诸如ＰO、OM等的FORM界面，OU字段的默认值仍然为空）。这似乎是ＯRACLE 系统设计方面的一个难题,即“MO：默认业务实体”的LＯＶ值集无法与“ＭO：安全性配置文件”中“组织层次架构”中的ＯU值范围保持一致。

ＯRACLE强调其“多组织接入MOＡC”功能主要是针对业务实体OU而言,其另外一层含义是,所有构建于库存组织ＩNV上的应用功能,实际是与上述配置文件无关的。库存组织的可接入性是在“组织访问”控制功能中,专门设定“库存组织”与“责任”的关联性,如下图3４所示：

按照OＲACLE的说法，如果系统在初始的时候,不定义库存组织的“组织访问”控制，则所有“责任”可访问所有INV,一旦限制或分配其中一个，则其余均必须逐个进行分配以建立“库存组织”与“责任”的链接关系。

总之,EBS系统通过“弹性域段值安全性”、“帐套／分类帐安全性”、“多组织接入安全性(MOAC）”、“库存组织访问控制”等多维度、多方面的组合系统设置,提供了灵活、方便的用户权限管理功能,厘清并掌握它们的复杂关系是系统实施的一项重要基础性工作。