文档介绍：该【多组织架构 】是由【sc2462】上传分享，文档一共【48】页，该文档可以免费在线阅读，需要了解更多关于【多组织架构 】的内容，可以使用淘豆网的站内搜索功能，选择自己适合的文档，以下文字是截取该文章内的部分文字，如需要获得完整电子版，请下载此文档到您的设备，方便您编辑和打印。欢迎阅读本文档,希望本文档能够对您有所帮助!
欢迎阅读本文档,希望本文档能够对您有所帮助!
感谢阅读本文档,希望本文档能够对您有所帮助!
感谢阅读本文档,希望本文档能够对您有所帮助!
欢迎阅读本文档,希望本文档能够对您有所帮助!
感谢阅读本文档,希望本文档能够对您有所帮助!
多组织架构
业务组(BG)
(二)法律实体(LE)
(三)业务实体(OU)
(四)库存组织(INV)
(五)公司成本中心(CostCenter)
(六)HR组织
(七)多组织接入控制
(八)一个集团下的全资子公司才可以设置为OU。若占百分比的,应设置为新的帐套。
在企业管理实践的过程中,“组织”(Organization)一词是个经常需用到的概念,一般与“人员”与“职能”这两个要素密切相关,反映某种行政管理关系,例如“财务部、销售部、采购部、生产部、仓储部”等等。企业内部行政组织(部门)的划分是企业基于“职能驱动”业务管理模式进行运作的基础。目前,国内适用于小企业使用的大多数低端管理软件并不考虑系统中的“组织”设置问题,其系统应用模块的划分,例如采购模块、仓管模块、销售模块等等,实际上就已经基本反映了企业运作的“组织职能”划分问题。
但是,对于业务复杂、规模较大的企业(如所谓“集团企业”),管理软件使用与实施的系统“组织设置”问题将是一个首要的重要问题。一个常见的、也是错误的系统实现方式就是将企业的“行政组织设置”直接映射到系统中,以“行政组织”代替“业务组织”。这种系统实现方式虽有理解、掌握比较容易的优势,但却完全违背了大企业运作必须基于“流程驱动”业务模式的基本管理原则。国内有所谓高端管理软件在系统实施过程中,常常出现有几十个财务、采购组织,几百个销售组织,乃至上千个库存组织的“盛况”,导致系统几乎没法使用的困境,其症结正在于此。
欢迎阅读本文档,希望本文档能够对您有所帮助!
欢迎阅读本文档,希望本文档能够对您有所帮助!
感谢阅读本文档,希望本文档能够对您有所帮助!
感谢阅读本文档,希望本文档能够对您有所帮助!
欢迎阅读本文档,希望本文档能够对您有所帮助!
感谢阅读本文档,希望本文档能够对您有所帮助!
与企业的“行政组织”设置与人员规模密切相关且复杂多变不同,软件系统的“组织设置”必须以业务流程运作为核心,要求尽可能简单并保持相对稳定,在公司(人员)规模扩大的过程中具有延续性与继承性。作为ERP鼻祖的SAP将系统组织简单地分为“集团(Client)、公司代码(CompanyCode)、采购组织(PurchaseOrg)、销售组织(SaleOrg)、工厂(Plant)”等类别。ORACLE的组织设置本质上与之基本相似,但作为后来者作了进一步抽象与简化,系统组织划分为“业务组(BusinessGroup)、法律实体(LegalEntity)、业务实体(OperatingUnit)、库存组织(InventoryOrg)”等。
如果说SAP的组织模型字面上多少还带有一点“行政组织”痕迹的话(这可能是某些声称学SAP的国内产品误入歧途的原因),ORACLE系统的组织模型字面上已经几乎看不出与“行政组织”还有什么关系,其中的“InventoryOrg”现今中文翻译成“库存组织”,容易令人望文生义和企业的“仓库管理部门(Warehouse)”混淆,但Inventory的本义实际应该是“存货”,称之为“存货组织”或许更好一些。如下图22所示ORACLE系统有关核心业务的多组织模型:
欢迎阅读本文档,希望本文档能够对您有所帮助!
欢迎阅读本文档,希望本文档能够对您有所帮助!
感谢阅读本文档,希望本文档能够对您有所帮助!
感谢阅读本文档,希望本文档能够对您有所帮助!
欢迎阅读本文档,希望本文档能够对您有所帮助!
感谢阅读本文档,希望本文档能够对您有所帮助!
上图中的“财务、销售、采购”并非系统的“组织实体”,它仅表示业务实体(OU)具有的相关业务处理功能。“子库”是特殊的系统组织实体,没有上下文环境可进入,主要表示库存组织之下的某种业务功能。
 
(一)业务组(BG)
 “业务组”的概念可以与企业的“集团”概念参看,但不同的是一个企业在系统中可以设置多个“业务组(集团)”。通常对于一个企业来说,系统中有一个“业务组”就够了,这表示企业就是一个“集团公司”。而对于某些业务“多元化”的特大型公司(如跨国公司),则可能需要在系统中设置多个“业务组”,表示企业由多个“集团公司”组成。
业务组设置是系统组织设置的第一步,是最高层级的组织形态,但它主要是与人力资源信息的分隔有关,即“人员信息”的设置在一个BG范围内是由各业务模块共享的(如果需要)。一旦系统设置的用户名(User)被与“人员”(Employee)关联,无论使用什么“责任”进入系统,都会定位至一个确定的BG中,任何责任在任意时刻只能关联一个BG。EBS安装好后,系统里面已经预置了一个名为“SetupBusinessGroup”的“初始业务组”。如图23所示系统预置的“SetupBusinessGroup”:
欢迎阅读本文档,希望本文档能够对您有所帮助!
欢迎阅读本文档,希望本文档能够对您有所帮助!
感谢阅读本文档,希望本文档能够对您有所帮助!
感谢阅读本文档,希望本文档能够对您有所帮助!
欢迎阅读本文档,希望本文档能够对您有所帮助!
感谢阅读本文档,希望本文档能够对您有所帮助!
当以系统预置超级用户SYSADMIN进入后,应首先设置一个具有在HRM或INV下创建组织功能的“责任”名,随后给此责任的“HR:UserType”配置文件设定值为“HRUser”,则该责任就有了创建新BG的能力。通常需要一次性将企业所需要的BG全部建立,一般另创建一个与企业名称一致如“某某集团”的新BG就可以了,也可以(不推荐)直接使用系统预设的“SetupBusinessGroup”而不创建新BG。
系统每新建一个BG,就会自动在配置文件“HR:安全性配置文件”的LOV中自动添加一个与新建BG同名的可选值(初始时只有“SetupBusinessGroup”一个值)。在某一个BG下(初始为SetupBusinessGroup)新建的任何责任,系统都将该责任的配置文件“HR:安全性配置文件”值默认为当前BG。要在进入系统时能切换到新的BG,必须先修改该责任的“HR:安全性配置文件”设定值。
如果将配置文件“HR:交叉业务组”的值设为“是”,则在不同BG下,新建的组织名称应当(虽然可以)不同,否则查看时可能会引起混淆。在同一个BG下的所有新建组织,名称不允许相同。
 
(二)法律实体(LE)
欢迎阅读本文档,希望本文档能够对您有所帮助!
欢迎阅读本文档,希望本文档能够对您有所帮助!
感谢阅读本文档,希望本文档能够对您有所帮助!
感谢阅读本文档,希望本文档能够对您有所帮助!
欢迎阅读本文档,希望本文档能够对您有所帮助!
感谢阅读本文档,希望本文档能够对您有所帮助!
 法律实体(LE,LegalEntity)对应于真实世界中的按国家法律法规要求注册的“法人公司”。在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,OperatingUnit)是EBS系统组织设置的重点也是难点之一。它与法人主体LE本身没有必然的关系,与会计科目弹性域结构中的“公司段”也没有直接关系。从企业实际业务管理需要的角度去看,业务实体OU可以看作是在系统中按照业务的相似性,把多个不同公司(包括LE)的业务处理过程及数据划分成相对独立的“管理单元”。在每个管理单元内部,各公司的业务运作共享相关数据并执行统一的业务策略。
欢迎阅读本文档,希望本文档能够对您有所帮助!
欢迎阅读本文档,希望本文档能够对您有所帮助!
感谢阅读本文档,希望本文档能够对您有所帮助!
感谢阅读本文档,希望本文档能够对您有所帮助!
欢迎阅读本文档,希望本文档能够对您有所帮助!
感谢阅读本文档,希望本文档能够对您有所帮助!
例如,有一个业务多元化的企业既生产医院使用的X光机也生产普通电视机,并且其下属在全国各地有多家生产X光机或电视机的分公司、子公司。由于这两种产品所使用的物料、供应商以及针对的客户群差异很大,企业为方便管理,可以将“业务运营”划分为两个相对独立的“业务管理群组”,对应到EBS系统中就是两个业务实体OU。
从企业日常业务运作管理的角度来看,对于单纯的电视机业务,全国范围内就设一个公司负责计划、生产、采购、销售等运营管理最为简便,但企业从非运营管理角度例如“税收优惠、地方政策”等等因素考虑,有时不得不在全国各地乃至世界各地注册若干所谓“公司”,以便向当地政府纳税并接受其财务会计方面的监管。
EBS在一个业务实体OU下,例如“电视机管理群组”,包含了全国各地所有负责生产或销售电视机的分公司、子公司(LE)的日常业务运作,在业务运作的组织层面忽略了作为法人实体的公司信息,但在反映业务运营最终结果的财务阶段(GL),仍能够方便地按照各地的法规要求提供财务数据与结果。而对于负责具体业务的系统用户来说,日常工作几乎不用关心或考虑“公司”的设置问题。
EBS中LE的数量可以根据需要任意增加,但对于OU的数量基于管理方便性则要求尽可能精简。EBS产品早期在实施过程中,存在一个公司(LE)对应一个OU的做法或一个OU只能属于一个LE的说法,这种做法或说法并不恰当。某些国内产品的设计由于未能有效区分“法律实体(公司)”与“业务实体(运营)”两者在系统中既相连接又有本质区别的特殊关系,只好采取一个法人公司对应一个系统业务实体的“笨办法”,企业规模小倒还能对付,一旦规模变大,注册公司增多,所谓的“系统多组织架构”就变得根本不具可用性。
ORACLEEBS业务实体OU的这一系统特性极大地方便了企业运作的日常管理,具有高度的灵活性与可扩展性。如下图27是R11的OU定义界面:
欢迎阅读本文档,希望本文档能够对您有所帮助!
欢迎阅读本文档,希望本文档能够对您有所帮助!
感谢阅读本文档,希望本文档能够对您有所帮助!
感谢阅读本文档,希望本文档能够对您有所帮助!
欢迎阅读本文档,希望本文档能够对您有所帮助!
感谢阅读本文档,希望本文档能够对您有所帮助!
 
图中的“业务实体信息”中,必须而且只能为之设定一个“帐套”,即一个OU只能属于一个帐套(反之,一个帐套可以分配给多个OU)。要注意的是,上述业务实体信息中的法人实体设定,并不代表OU只能属于一个LE,它只是表示在