ORACLEEBS基础设置之组织架构.docx
- 文档编号:24533527
- 上传时间:2023-05-28
- 格式:DOCX
- 页数:19
- 大小:556.90KB
ORACLEEBS基础设置之组织架构.docx
《ORACLEEBS基础设置之组织架构.docx》由会员分享,可在线阅读,更多相关《ORACLEEBS基础设置之组织架构.docx(19页珍藏版)》请在冰豆网上搜索。
ORACLEEBS基础设置之组织架构
ORACLEEBS基础设置之组织架构
四、组织架构
在企业管理实践的过程中,组织”(Organization)—词是个经常需用到的概念,一般与人员”与职
能”这两个要素密切相关,反映某种行政管理关系,例如“财务部、销售部、采购部、生产部、仓储部”等等。
企业内部行政组织(部门)的划分是企业基于“职能驱动”业务管理模式进行运作的基础。
目前,国内适用于小企业使用的大多数低端管理软件并不考虑系统中的“组织”设置问题,其系统应用模块的划分,例如采购模块、仓管模块、销售模块等等,实际上就已经基本反映了企业运作的“组织职能”划分问题。
但是,对于业务复杂、规模较大的企业(如所谓“集团企业”),管理软件使用与实施的系统“组织设置”问题将是一个首要的重要问题。
一个常见的、也是错误的系统实现方式就是将企业的“行政组织设置”直
接映射到系统中,以“行政组织”代替“业务组织”。
这种系统实现方式虽有理解、掌握比较容易的优势,但却完全违背了大企业运作必须基于“流程驱动”业务模式的基本管理原则。
国内有所谓高端管理软件在系统实施过程中,常常出现有几十个财务、采购组织,几百个销售组织,乃至上千个库存组织的“盛况”,导致系
统几乎没法使用的困境,其症结正在于此。
与企业的“行政组织”设置与人员规模密切相关且复杂多变不同,软件系统的“组织设置”必须以业务流程运作为核心,要求尽可能简单并保持相对稳定,在公司(人员)规模扩大的过程中具有延续性与继承性。
作为ERP鼻祖的SAP将系统组织简单地分为“集团(Client)、公司代码(CompanyCode)、采购组织(PurchaseOrg)、销售组织(SaleOrg)、工厂(Plant)”等类别。
ORACLE的组织设置本质上与之基本相似,但作为后来者作了进一步抽象与简化,系统组织划分为“业务组(BusinessGroup)、法律实体(LegalEntity)、业务实体(OperatingUnit)、库存组织(InventoryOrg)”等。
如果说SAP的组织模型字面上多少还带有一点“行政组织”痕迹的话(这可能是某些声称学SAP的国内产品误入歧途的原因),ORACLE系统的组织模型字面上已经几乎看不出与“行政组织”还有什么关系,其中的“InventoryOrg现”今中文翻译成“库存组织”,容易令人望文生义和企业的“仓库管理部门
(Warehouse)”混淆,但Inventory的本义实际应该是“存货”,称之为“存货组织”或许更好一些。
如下图
22所示ORACLE系统有关核心业务的多组织模型:
ORACLE多组织系统摸型
业务组
ii-1.
法律:
实体
法律实休
业务
实体
业务实体
(一)业务组(BG)
业务组”的概念可以与企业的集团”概念参看,但不同的是一个企业在系统中可以设置多个业务组
(集团)”。
通常对于一个企业来说,系统中有一个业务组”就够了,这表示企业就是一个集团公司”。
而
对于某些业务多元化”的特大型公司(如跨国公司),则可能需要在系统中设置多个业务组”,表示企业由
多个集团公司”组成。
业务组设置是系统组织设置的第一步,是最高层级的组织形态,但它主要是与人力资源信息的分隔
有关,即人员信息”的设置在一个BG范围内是由各业务模块共享的(如果需要)。
一旦系统设置的用户名
(User)被与人员"(Employee)关联,无论使用什么责任"进入系统,都会定位至一个确定的BG中,
任何责任在任意时刻只能关联一个BG。
EBS安装好后,系统里面已经预置了一个名为“SetupBusiness
Group"的初始业务组”。
如图23所示系统预置的“SetupBusinessGroup:
”
当以系统预置超级用户SYSADMIN进入后,应首先设置一个具有在HRM或INV下创建组织功能的责任"名,随后给此责任的“HRUserType'配置文件设定值为“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所示:
玄克11凰*1设置妄-1ndHtdnrhl?
匸恥|
丈件卽査音电〕胶麓⑥二MQ枯酗®
Qa•..■;:
■/,w(w电>
亡"*方轄
Jl..山Mgrw.MMgtT见M豹一顽电匸曲開t」(E«rWFUSUHTOiH:
」賞也/“[J转却•社-“
ORACLC*令廿罰貝设冒管理譽
a
C心诉PJih渤*i
1
田整衿去戸弓FH-它声咋世晞
E,链人主住
I
■«(«£)
atAXttUW
营右祥摘乜舅
hrfhhli*Sh
l.rs
U^YSllIT
us
□EETCUDLD
>
旦
u'-juthihc^sL'!
rJH.e
us
□EBS^J'IDL
z
s
USATEST
US
USS册妙
50
p
ra
CA
CTd卵昭江刘疋IQ9旳朝
打
J
•■"I
^HumG-snqikCTREJ
%
CTAWilil'CI1
T?
y
pili£>nLe-iiutig
US
JSVAT-f^j&i*
曾
f
s
Fssuca□pjzakjau
US
□E3泅述
DUO
$
.£辛令*1|后YiUfZArrWMQJS抑
状齐WV
-■:
■■■'■-K:
“T--r:
为M甘紳:
宅加讶更睛E记麻卿i抑
也二审M7G
"丿
•■古祁*讪1棍畫而*4更鶯为巧护也舐口疋^,!
尺适甌
□W苴G匚PEKATK帕
'jiuin.jOmuim
J・¥
創亠■h"f伯
在R12中,还必须为法人实体分配会计科目弹性域结构的公司段即平衡段值。
每个LE可以分配多
个平衡段”值,公司段值集中每个段值一旦被分配给某LE,则其它LE就不能再被分配。
在R11或R12中
创建一个LE后,应当及时到会计科目弹性域结构中添加需要对应的公司段值LOV(一个或多个),并重
新进行弹性域的编译,否则系统可能会弹岀错误报警信息。
R12中一个LE对应多个公司平衡段值,代表
有多个分公司,LE是它们的合并。
主辅分类帐可拥有相同或不同的公司段值集,表示从不同的维度(如按地区、按产品等)去划分公司以方便考核。
如图26所示为LE添加平衡段值:
立眸吐"祕息G®妁催也i1A⑴Wfe吐
0药'>x:
*L/m<■晰査邨•.—•3
轴Jill■>:
打cki>■.Hf^1.in./tMUOHJIuL上f/giZiA疋L#/e.MtZr.hiu十亠口di乂帘JMAtlEkjrfjMkfliS监妙JJLKL*QVtJU酋:
l
佥H啊冃说苦資蹲器
关同住」百.虽氏村的<»
II
咅汁科目、忌骨>侖汁送■期■visiorOperalonsi:
LJii^;i>
•崙]雷用
€SfffcK*&lrl
三莫亀他赠口金丁毎眞聲帥*(!
工OprrM"w匚町吟列爭
」14■豊a__!
A3mj|fcki_iLiiEyhiMH■一L^ys.。
严―屮卜..1_“,州■■呼
输助勺诫半nviHroBikftr泊舉口HA.fMfuy
"提瓜塌粋苴f论値;配站他人主体u績披建人主住錨定知洋护;5:
务处越岀輛序川比医aitM廿丈修便阳正已轴工豊°
j&ftttft
i'0pwtllmJCcrfc^Hfif
己孙配干Kt£值二Lpera血wxL'.ifULT
谁如罕■硼I
下■”SW血FT崛歩itH.■»
DeoptftiaMii
i>*in-SLjKJCC#)
71JisimCFuSrLfdt|力|r3
.IMki.9WW*ir~l_
取荷盟用
1栄千g
tfFWU«i?
rrHn.-joie™恬55所中尸利
无论是R11还是R12,法律实体LE的设置都对具体的业务处理影响不大,其与系统用户或责任不关联,不直接影响系统上下文的切换,故有人甚至认为EBS的LE设置作用不大。 这对于系统的内部运作 来讲情况确实近似如此,但对于需要通过系统产生供外部使用的具有法律意义的文书(如采购订单、财务报表等等),严格区分法律实体LE还是必须的。 R12显然更多地考虑了外部使用的这种法律要求(即所 谓法规遵从性”或合规性”,并在相关业务应用模块中有所体现。 (三)业务实体(0U) 业务实体(OU,OperatingUnit)是EBS系统组织设置的重点也是难点之一。 它与法人主体LE本 身没有必然的关系,与会计科目弹性域结构中的公司段”也没有直接关系。 从企业实际业务管理需要的角 度去看,业务实体0U可以看作是在系统中按照业务的相似性,把多个不同公司(包括LE)的业务处理过 程及数据划分成相对独立的管理单元”在每个管理单元内部,各公司的业务运作共享相关数据并执行统一的业务策略。 例如,有一个业务多元化的企业既生产医院使用的X光机也生产普通电视机,并且其下属在全国各 地有多家生产X光机或电视机的分公司、子公司。 由于这两种产品所使用的物料、供应商以及针对的客户群差异很大,企业为方便管理,可以将业务运营”划分为两个相对独立的业务管理群组”对应到EBS系 统中就是两个业务实体0U。 从企业日常业务运作管理的角度来看,对于单纯的电视机业务,全国范围内就设一个公司负责计划、生产、采购、销售等运营管理最为简便,但企业从非运营管理角度例如税收优惠、地方政策”等等因素考 虑,有时不得不在全国各地乃至世界各地注册若干所谓公司”以便向当地政府纳税并接受其财务会计方 面的监管。 EBS在一个业务实体OU下,例如电视机管理群组”,包含了全国各地所有负责生产或销售电视机的分公司、子公司(LE)的日常业务运作,在业务运作的组织层面忽略了作为法人实体的公司信息,但在反映业务运营最终结果的财务阶段(GL),仍能够方便地按照各地的法规要求提供财务数据与结果。 而对于负责具体业务的系统用户来说,日常工作几乎不用关心或考虑公司”的设置问题。 EBS中LE的数量可以根据需要任意增加,但对于OU的数量基于管理方便性则要求尽可能精简。 EBS产品早期在实施过程中,存在一个公司(LE)对应一个OU的做法或一个OU只能属于一个LE的说 法,这种做法或说法并不恰当。 某些国内产品的设计由于未能有效区分法律实体(公司)”与业务实体(运 营)’两者在系统中既相连接又有本质区别的特殊关系,只好采取一个法人公司对应一个系统业务实体的笨 办法”,企业规模小倒还能对付,一旦规模变大,注册公司增多,所谓的系统多组织架构”就变得根本不具 可用性。 ORACLEEBS业务实体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的设置没有直接影响。 在EBS中有关采购管理、销售订单履行、应收应付管理等业务模块的功能均是建立在OU基础之上的。 用户在执行上述相关模块的业务处理 时,总是必须进入确定的OU(上下文环境)才可以进行,EBS的所谓多组织”功能(MOAC)也是针对 多OU而言的,与真实世界中的多公司”(LE)没有直接关系。 实际上,SAP的采购组织、销售组织”设置也是与真实世界的行政组织采购部、销售部”无关的, ORACLE抛弃了采购组织、销售组织”的概念,OU实际上就起到了类似的组织分隔作用。 ORACLE的某 些相关文档中,如果因描述需要而提及所谓采购组织、销售组织”等概念,有时实际指的就是业务实体OU (或OU下的库存INV组织)。 (四)库存组织(INV) ORACLEEBS的库存组织(INV)是系统组织设置的最基础、也是最重要的工作之一。 库存组织的内涵远不是真实世界的仓库部门”那么简单,它除了是有关物料接收与发岀”等业务功能的基础之外,更重要的是,它还是EBS系统有关计划(MPS/MRP)、在制品管理(WIP)、物料清单(BOM)等模块业务功能的操作与管理平台。 如下图28所示: EBS中的库存组织INV的作用与功能可以与SAP中的工厂Plant参看。 一个库存组织INV只能属于一个确定的帐套SOB、一个确定的法人实体LE、一个确定的业务实体OU,具有唯一性的关系(注意: R11的设置界面未考虑SOB/LE/OU的关联限定,容易产生错误;R12作了改进,在选定Ledger之后, 可用的LE/OU就被限定)。 反之,一个帐套/法人实体/业务实体”组合则可以有多个库存组织INV。 此外,一个0U下的多个INV可以对应属于该0U的不同LE,这相当于将分属于两个法人公司的生产两种产品的四个工厂,按相同产品两两组合抽取出来,分属于两个不同0U进行日常业务管理。 在EBS中还有两个组织概念“MRP组织、WIP组织”,它们实际是必须构建于库存组织之上的组织概念,表示该库存组织还可以进行MRP或WIP的功能。 系统之所以如此处理,主要是为了控制某些INV不 能做MRP或WIP而已,因为基于物料接收或发出需要所设定的INV数量可能比较多。 对于绝大多数基于库存组织INV的业务功能(个别除外),系统用户在做业务操作时,均必须首先 进行INV的选择切换,以便进入确定的INV上下文环境。 库存组织的作用是如此基础,以至于EBS的相 关文档在提及组织(Org)概念时,如果未作特别说明,默认就是指INV组织。 (五)公司成本中心(CostCenter) EBS的所谓成本中心组织”并没有业务处理的功能,它的设置主要是考虑与会计科目弹性域结构 中的公司段值”与成本中心段值”的对应关系问题。 如下图29所示: 在系统中创建公司成本中心组织”后,可以运行一个并发检查程序”,以校验会计科目弹性域结构”中的段值是否与所有的公司成本中心”组织的设置保持一致。 当在会计科目弹性域结构”中的成本中心段”值集中添加LOV值并重新编译后,可以运行系统的自 动组织”并发程序功能,由系统自动创建公司成本中心”组织。 应当注意的是,一个公司成本中心组织及其成本中心段值,不可能属于不同法人实体LE及其公司段 值,这与真实世界中的管理要求是一致的。 库存组织INV与会计科目弹性域中的成本中心”段(部门)则 具有一对一或多对一”的关系,即一个成本中心”段值可以有多个库存组织INV,但一个库存组织INV只能属于一个确定的成本中心。 (六)HR组织 系统的HR组织设置是与HRM模块的相关业务处理功能相关,与核心业务/财务处理功能关系不大,主要是需要注意其是否和成本中心”关联,需要时可以输入成本中心”代码,其LOV就是会计科目弹性域结构中成本中心段的值集。 如下图30所示: (七)多组织接入控制 在图30的EBS组织设置界面中,所谓的组织类型”(Type)划分仅是基于组织自身的统计分析工 作需要而定义的一个维度”,例如公司总部、产品线”等等,并不影响系统的业务处理功能。 真正起作用的是设置界面中的组织分类”(Classification),系统预置的组织分类LOV除了上述业务组、法律实体、业务实体、库存组织”等之外,还有诸如资产组织、运营公司、雇主”等等选项。 在EBS系统中各应用模块所具有的业务处理功能通常需构建在一个确定的组织分类”之上,组织”是相关业务处理功能的平台,企业是 否需要作相关组织分类设置、如何设置,取决于企业所需要使用到的应用模块功能。 例如所谓资产组织”的设置,它是在企业需使用到资产管理模块FA时才涉及到。 资产组织”实际上 是所谓资产账簿”的代名词,它只是表示有关资产信息的一个数据维度,作用主要在于分隔数据范围,用户进入系统作业务处理时,并不需要作上下文业务环境的切换。 对于这类并不涉及上下文'环境切换的所 谓组织”,ORACLR系统的设计主要是为了借用组织”所具有的层次结构”(Hierarchy)概念来达到多组 织接入”权限的控制功能。 需指岀的是,这里的组织层次结构”与真实世界企业的行政管理组织层次结构没有直接关系(尽管可能有所参考),它只是企业根据某种需要(如权限管理控制、数据统计汇报等)而人为设定的一个层次结 构”,例如将系统中已经设置的任意数量的业务实体”或库存组织”等等组织Name,人为地设定一个具有上 下级关系、自顶向下的金字塔形多层结构。 如下图31所示: 上图中开始定义时,一旦选定(最)顶端组织Name,则就只能为之分配下属组织Name,如要给下属组织分配更下一级的组织,则需点击向下”按钮,将当前该下属组织上升到顶端组织”位置。 点击向上”按钮,则将当前顶端组织’下降到下属组织位置。 企业可以根据实际需要设定若干个具有不同内部结构的组 织层次结构”Name以供定义系统所谓安全性配置文件”时调用。 如下图32所示: 上图所定义安全性配置文件”是系统用以控制包括组织安全性”等在内的各种安全性控制的基础,它具体规定了系统安全性控制的范围与实现方式,所有定义的安全性配置文件”Name构成系统多组织接入控 制参数“MO安全性配置文件”的LOV。 如下图33所示: EBS通过“MO业务实体”、“MO安全性配置文件”、“MO默认业务实体”这三个系统配置文件的共同作用,实现所谓多组织接入”控制功能MOAC。 但上述三个配置文件在R11与R12中的作用有比较大的差别。 对于“MO业务实体”,在R11中必须设定,而且起决定性控制作用,其LOV由系统基于创建的 OUname自动创建,用户登录时系统自动定位于指定OU。 而在R12中,一旦设定“MO安全性配置文件”,则此配置文件失效而不起作用。 对于“MO安全性配置文件”,在R11中虽有,但实际不起OU接入的控制作用,只针对FA等模块的得某些应用如数据统计等起作用。 因此,一般认为R11并不具有完善的多组织接入控制功能。 在R12 中,该参数如果不设定,则必须设定“MO业务实体”参数;一旦该参数被设定,则就起决定作用,系统主 要依赖其实现MOAC。 对于“MO默认业务实体”,在R11中虽有但实际不起作用。 在R12中,随“MO安全配置文件”起作用后才起作用,其LOV是所有已定义0U,但如果设定值不在“MO安全配置文件”所选择的组织层次架构”的范围内,则仍不起作用(即在与OU相关诸如PO、OM等的FORM界面,0U字段的默认值仍 然为空)。 这似乎是ORACLE系统设计方面的一个难题,即“MO默认业务实体”的LOV值集无法与“MO 安全性配置文件”中组织层次架构”中的OU值范围保持一致。 ORACLE强调其多组织接入MOAC功能主要是针对业务实体OU而言,其另外一层含义是,所有构建于库存组织INV上的应用功能,实际是与上述配置文件无关的。 库存组织的可接入性是在组织访问” 控制功能中,专门设定库存组织”与责任”的关联性,如下图34所示: 按照ORACLE的说法,如果系统在初始的时候,不定义库存组织的组织访问”控制,则所有责任” 可访问所有INV,一旦限制或分配其中一个,则其余均必须逐个进行分配以建立库存组织”与责任”的链接 关系。 总之,EBS系统通过弹性域段值安全性”帐套/分类帐安全性”多组织接入安全性(MOAC)库存组织访问控制”等多维度、多方面的组合系统设置,提供了灵活、方便的用户权限管理功能,厘清并 掌握它们的复杂关系是系统实施的一项重要基础性工作。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- ORACLEEBS 基础 设置 组织 架构