下载文档原格式
ORACLE EBS R12 MOAC使用配置MOAC使用配置1.2.1.概述在MOAC中使用的是安全性配置文件来实现对OU访问的控制的，我们首先定义好安全性配置文件，然后将该文件使用预制文件的形式定义在职责或者用户上，让这个用户可以访问该安全性配置文件所分配的安全OU，但由于业务上的需要，不是所有拥有该安全性配置文件的用户都想访问该安全性配置文件分配的全部OU,在R12中用户可以在职责中使用“用户首选项”来设置自己的操作OU，本节实现MOAC的设置。
1.2.2.安全性控制文件介绍在这里引用一段实施文档对安全性配置文件的介绍:安全性配置文件控制对业务组中的组织、职位、员工和申请人记录的访问，系统管理员可以使用安全性配置文件来限制用户的责任。
具体限制内容如下：1 按人员类型应用限制；（您可以选择将您设置的安全性限制应用于员工、申请人、联系人或者他们的任何组合。
）2 按组织限制访问；（您可以查看所有组织（无安全性）；按组织层次结构和（或）组织列表保护组织；按单个业务实体保护组织；按业务实体和库存组织的组合保护组织。
）3 按职位限制访问；（您可以在“职位安全性”标签区域中，查看所有职位（无安全性）；或者撤消选定“查看所有职位”复选框，然后选择职位层次结构和顶层职位。
如果您要允许访问该职位，请选定“包括顶层职位”复选框。
）4 按工资单限制访问；（您可以选定“查看所有工资单”复选框，允许访问所有工资单；或者通过撤消选定“查看所有工资单”复选框，然后撤消选定“包括”复选框，排除不可访问工资单，这样可以允许访问许多工资单；您可以通过撤消选定“查看所5按主管限制访问；（您可以在“基于用户的安全性”标签区域中，选定“按主管限制”复选框，然后在“最大结构层”框中输入您要允许主管查看的访问层数，或者将此字段留空，以便允许访问所有层。
）6 允许访问授权用户记录（仅限于 SSHR）；您可以选定“允许授权用户”复选框，可以在其他用户使用自助应用产品授权自助用户进行访问的情形下，允许使用该配置文件的自助用户访问其他自助用户的记录。
ORACLE EBS基础设置要点简介一、安全性管理二、会计科目弹性域结构三、帐套（分类帐）四、组织架构（一)业务组（ＢG)（二）法律实体（LE)(三)业务实体（ＯU）(四)库存组织(INV）（五）公司成本中心（Cｏst Ｃenter）（六）ＨR组织(七)多组织接入控制五、基础数据(一）关于“日历”(二)关于“币种”（三)关于“汇率”（四）关于“单位”（五）关于“地点”六、并发管理七、工作流八、系统初始化设置(一）关于安全性。
(二)关于配置文件（三）值集与弹性域（四)分类账（帐套）与组织架构（五)单据编号（六）层次性设置结构九、结语首先需要说明的是,本系列文档假定读者已经具备基本的系统相关使用知识与技能(例如,能够基本领会“ＯＲAＣLＥEＢS系统应用基础概述”中的内容),故所讨论的内容仅限于笔者认为从系统使用与实际业务两方面来看比较重要或者容易存疑的问题，并不能面面俱到，旨在帮助读者掌握核心、抓住要点（详尽内容必须参考ORAＣLE相关官方文档)。
文中为讨论需要所附图文均取自OＲACLE EBS 的测试环境（VisioｎDｅmo),版本以R12．1．1为主,辅之以版本Ｒ11.5．１0，界面语言主要为中文（必要时辅之以英文）。
两个ＥBS版本在界面与功能应用方面实际可能有一些差异，必要时会作相关说明，但一般不会影响对基本问题的讨论。
技术是业务的抽象与工具,业务是技术的来源与目的。
本系列文档通篇将秉持“从业务的角度去审视技术,从技术的角度去回归业务”的方法论(这里的所谓“技术”，意指“系统实现”)，去探讨系统实现与业务实践的融合问题,以求逐步能达到技术与业务的融会贯通。
限于笔者的认知水平，有讹误或不正确之处,欢迎批评指正。
一、安全性管理从系统使用角度来看,系统管理的一项重要的日常工作是关于“用户”及其“权限”的管理，在ORACLE 中即所谓“安全性”(Securｉtｙ）管理。
“安全性”是一个涵义较之“权限”更为丰富、更为广阔的概念术语，它虽然比较抽象，但顾名思义,它很好地涵盖了于实际业务与系统使用中,有关企业数据与信息管理的某些需要重点保护、控制的内容。
（O管理）O权威资料EBS 基础设置全手册ORACLEEBS基础设置手册首先需要说明的是，本系列文档假定读者已经具备基本的系统相关使用知识与技能(例如，能够基本领会“ORACLEEBS系统应用基础概述”中的内容)，故所讨论的内容仅限于笔者认为从系统使用与实际业务两方面来看比较重要或者容易存疑的问题，并不能面面俱到，旨在帮助读者掌握核心、抓住要点（详尽内容必须参考ORACLE相关官方文档）。
文中为讨论需要所附图文均取自ORACLEEBS的测试环境（VisionDemo），版本以R12.1.1为主，辅之以版本R11.5.10，界面语言主要为中文（必要时辅之以英文）。
两个EBS版本在界面与功能应用方面实际可能有一些差异，必要时会作相关说明，但一般不会影响对基本问题的讨论。
技术是业务的抽象与工具，业务是技术的来源与目的。
本系列文档通篇将秉持“从业务的角度去审视技术，从技术的角度去回归业务”的方法论（这里的所谓“技术”，意指“系统实现”），去探讨系统实现与业务实践的融合问题，以求逐步能达到技术与业务的融会贯通。
限于笔者的认知水平，有讹误或不正确之处，欢迎批评指正。
一、安全性管理从系统使用角度来看，系统管理的一项重要的日常工作是关于“用户”及其“权限”的管理，在ORACLE中即所谓“安全性”（Security）管理。
“安全性”是一个涵义较之“权限”更为丰富、更为广阔的概念术语，它虽然比较抽象，但顾名思义，它很好地涵盖了于实际业务与系统使用中，有关企业数据与信息管理的某些需要重点保护、控制的内容。
有关用户权限的管理，在ORACLE系统中主要有三个基本要素构成：菜单（Menu）、责任（Responsibility）、以及用户（User）。
三者的有机结合构成了系统权限或安全性管理的基础，辅之以参数或“安全性配置文件”等的使用，则进一步对用户的“实体（组织、帐套或分类帐）接入”权限进行细分。
此外，系统在各个应用模块中，还将可能基于不同业务特点采取各具特色的系统实现方式，对用户的准入管理或功能权限作更进一步的划分（具体方式与系统设计者的个人偏好也有一定关系，不能一概而论）。
《企业电子商务组织架构图》企业电子商务组织架构图生产型企业电子商务组织架构图客网订美户络单工关分处设怀销理计部部部部协作部门电子商务部贸易型企业电子商务组织架构图网订客美络单户工分处关设销理怀计部部部部协作部门电子商务部网商型企业组织架构图网客订美络户单工分关处设销怀理计部部部部管理类部门业务类部门2页空白没用的～请掠过阅读吧哈,这2页空白没用的～请掠过阅读吧哈,请掠过阅读吧～哈哈哈空白没用的～请掠过阅读吧哈这1页空白没用的～请掠过阅读吧哈空白没用的～请掠过阅读吧～这1页空白没用的～请掠过阅读吧～空白没用的～请掠过阅读吧哈这1页空白没用的～请掠过阅读吧哈空白没用的～请掠过阅读吧～这1页空白没用的～请掠过阅读吧～电子商务部门职责及岗位设置部门名称部门职能岗位设置由公司管理层组成工作小组，总经办直接领导，工作内容包括:战略管理协调小组电子商务总监(1) 规划、运营实施、项目监督、员工培训、管理部署、企业文化建设等产品编辑(1) 产品编辑部负责产品图片拍摄、处理，产品描述编辑，产品上架等摄影师(兼职)零售主管(1) 网络零售部承担网上零售工作;负责在线答复客户、销售商品、订单处理等;销售客服(若干) 网络分销部负责网络分销商的招募、管理、发货、支持等; 分销主管(1)物流主管(1) 物流仓储部负责管理仓库，进货、打包发货、进销存管理等;配货员(若干)打包员(若干)复核员(1) 订单处理部负责打印发货清单、快递单、安排发货、监督运输等;打单员(1) 售后服务部负责接待售后客户，处理纠纷、退换货、评价处理、客户答疑等; 售后客服(若干)负责老客户关系维护及二次开发;客户数据库建立、数据分析、决策客户关怀部客户关怀(1) 支持等。
营销推广部负责品牌宣传推广;网络软营销、广告;网店运营、网店促销等; 营销专员(1) 美工设计部负责产品图片编辑、网店装修与美化，市场营销工作的美工支持。
美工(若干)岗位职能与任职要求岗位设置岗位职能任职要求良好的敬业精神和职业道德操守;了解电子商务认同1、制定电子商务部战略及规章制度; 电子商务企业战略，熟悉企业情况;具备独立网店经营的能力，2、负责电子商务部运营、协调部门工作; 总监有网店管理经验;熟练掌握电子商务知识和网店业务3、企业资源与社会资源整合。
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）”等类别。
电子商务组织机构电子商务（E-commerce）是指利用互联网和电子技术进行商业活动的一种形式。
在电子商务产业链中，组织机构起着至关重要的作用。
组织机构的设计和运作对于电子商务企业的发展和运营至关重要。
本文将分析电子商务组织机构的基本架构和常见职能部门。
1. 组织机构的基本架构电子商务组织机构的基本架构往往包括三个层次：高层管理层、业务部门和辅助部门。
每个层次有不同的职能和责任。
1.1 高层管理层高层管理层是电子商务企业的决策者和战略规划者。
他们负责制定企业的发展战略、制定决策、控制和管理企业的整体运作。
高层管理层通常由董事会、首席执行官（CEO）、首席财务官（CFO）等职位组成。
他们在电子商务企业中扮演着重要的角色，决策的正确与否将直接影响企业的发展。
1.2 业务部门业务部门是电子商务企业中直接与客户交互、实施销售、运营等工作的部门。
通常包括市场营销部门、销售部门、采购部门、客户服务部门等。
这些部门负责市场调研、产品开发、销售推广、订单处理、售后服务等工作。
业务部门通常是电子商务企业最重要的部门，他们直接决定了企业的销售额和商业效益。
1.3 辅助部门辅助部门是电子商务企业中提供支持和保障的部门。
通常包括人力资源部门、财务部门、技术部门等。
这些部门负责管理企业的人力资源、财务活动和技术支持。
辅助部门的有效运作能够为业务部门提供必要的支持，保障企业的正常运营。
2. 常见职能部门及其职责2.1 市场营销部门市场营销部门负责制定企业的市场推广策略和销售计划。
他们通过市场调研、分析竞争对手和制定营销策略等手段，提供企业的产品在市场中的销售方向和方法。
市场营销部门通常包括市场调研团队、市场策划团队和市场推广团队等。
2.2 销售部门销售部门负责与客户直接接触，实施产品的销售工作。
他们负责寻找潜在客户、与客户洽谈销售合同、完成订单等工作。
销售部门通常包括销售团队、销售代表和销售支持团队等。
2.3 采购部门采购部门负责企业所需物品和服务的采购工作。
埃森哲中国组织架构精品课件(一)埃森哲作为世界顶尖的管理咨询公司之一，在中国市场发展迅速，业务范围涵盖企业转型、数字化转型、供应链管理等多个领域。
为了更好地服务客户，埃森哲在中国的组织架构上进行了优化，形成了一套科学合理的架构框架，课件中对此进行了详细的介绍。
一、组织架构概述埃森哲中国的组织架构分为靠山、前哨、服务、内控及其他五大板块，每个板块分别管辖行业组、行政及其他机构。
其中靠山板块负责集团战略的制定和执行，前哨板块负责开拓新业务领域，服务板块负责服务客户，内控板块负责企业内部管控，其他板块是一些特殊机构。
整个组织架构呈现出环状层级关系，每个板块之间相互联系、互为补充，形成一个完整的管理体系。
二、板块介绍1.靠山板块靠山板块是埃森哲在中国市场的依靠，主要负责制定公司战略、管理及财务事务等。
靠山板块下设战略规划组、财务组、法务组等行政机构。
这些机构的职责分别是制定公司长期规划、管理公司投资回报、保障公司合规经营。
2.前哨板块前哨板块是埃森哲在中国市场的开拓者，主要负责发掘、探索新市场及业务领域。
前哨板块下设数字化事业部、运营管理事业部等行业组，这些组织将通过精准的市场研究和深度的客户调研，为公司提供更多业务拓展和增长空间。
3.服务板块服务板块是埃森哲在中国市场的服务提供者，主要负责为客户提供咨询服务、解决方案及项目执行等，该板块下设能源、制造、金融等多个行业组，覆盖广泛，服务项目多种多样。
4.内控板块内控板块是埃森哲在中国市场的内部管控机构，主要负责监督公司的风险管理、合规及内部审计等。
内控板块下设风险管理组、合规组、内部审计组等行政机构，通过规范化的管理流程和完善的内部审计机制，为公司的可持续发展提供保障。
5.其他板块其他板块包括人力资源、信息技术、食品安全、经营与流程等特殊机构，这些机构也是公司运营所必须的板块，人力资源、信息技术等是公司运营所必需的支持服务，食品安全、经营与流程等则是公司特殊领域的经营关键点。
系列之四：ORACLE EBS 基础设置要点简介（A）ORACLE EBS 基础设置要点简介一、安全性管理二、会计科目弹性域结构三、帐套（分类帐）四、组织架构（一）业务组（BG）（二）法律实体（LE）（三）业务实体（OU）（四）库存组织（INV）（五）公司成本中心（Cost Center）（六）HR组织（七）多组织接入控制五、基础数据（一）关于“日历”（二）关于“币种”（三）关于“汇率”（四）关于“单位”（五）关于“地点”六、并发管理七、工作流八、系统初始化设置（一）关于安全性。
（二）关于配置文件（三）值集与弹性域（四）分类账（帐套）与组织架构（五）单据编号（六）层次性设置结构九、结语（注：网站批量发图有问题，上传后显示不清楚。
点击图片打开后，质量尚可）首先需要说明的是，本系列文档假定读者已经具备基本的系统相关使用知识与技能(例如，能够基本领会“ORACLE EBS系统应用基础概述”中的内容)，故所讨论的内容仅限于笔者认为从系统使用与实际业务两方面来看比较重要或者容易存疑的问题，并不能面面俱到，旨在帮助读者掌握核心、抓住要点（详尽内容必须参考ORACLE相关官方文档）。
文中为讨论需要所附图文均取自ORACLE EBS 的测试环境（Vision Demo），版本以R12.1.1为主，辅之以版本R11.5.10，界面语言主要为中文（必要时辅之以英文）。
两个EBS版本在界面与功能应用方面实际可能有一些差异，必要时会作相关说明，但一般不会影响对基本问题的讨论。
技术是业务的抽象与工具，业务是技术的来源与目的。
本系列文档通篇将秉持“从业务的角度去审视技术，从技术的角度去回归业务”的方法论（这里的所谓“技术”，意指“系统实现”），去探讨系统实现与业务实践的融合问题，以求逐步能达到技术与业务的融会贯通。
限于笔者的认知水平，有讹误或不正确之处，欢迎批评指正。
一、安全性管理从系统使用角度来看，系统管理的一项重要的日常工作是关于“用户”及其“权限”的管理，在ORACLE中即所谓“安全性”（Security）管理。
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）”等。
埃森哲的组织架构埃森哲是一家全球性的管理咨询公司，其组织架构体现了其强大的专业能力和高效的团队协作。
以下是埃森哲的组织架构。
一、总部管理层埃森哲的总部管理层负责制定公司的战略方向和决策，并监督公司各个业务部门的运营情况。
总部管理层通常由公司的高级执行团队组成，包括首席执行官（CEO）、首席运营官（COO）和首席财务官（CFO）等高级职位。
二、业务部门埃森哲的业务部门是公司的核心组成部分，负责提供各种管理咨询服务。
业务部门通常按照行业或专业领域进行划分，例如金融服务、能源和公共事业、健康和公共服务等。
每个业务部门都由一位业务部门负责人领导，他们负责管理团队、开展业务并与客户进行沟通。
三、咨询团队埃森哲的咨询团队是公司最重要的资源之一。
咨询团队由具有专业知识和经验的顾问组成，他们与客户合作，提供量身定制的解决方案。
咨询团队通常由一位项目经理领导，他们负责协调团队成员、管理项目进度并与客户进行沟通。
四、研究与开发部门埃森哲的研究与开发部门负责进行行业研究、技术创新和知识管理。
研究与开发团队的成员通过对市场趋势和客户需求的分析，提供创新的解决方案，并将其应用于实践中。
研究与开发部门的工作对于公司的长期发展非常重要。
五、支持部门埃森哲的支持部门包括人力资源、财务、营销和信息技术等。
这些部门负责提供公司运营所需的支持和服务，确保公司的日常运作顺利进行。
支持部门的工作对于保持公司的高效运营至关重要。
六、全球办公室埃森哲在全球范围内设有多个办公室，以便更好地为客户提供服务。
这些办公室遍布世界各地，在不同的国家和地区建立了强大的业务网络。
全球办公室之间通过信息技术和协作工具进行紧密的合作，以实现全球范围内的团队协作。
埃森哲的组织架构体现了高效的团队协作和专业能力的集中体现。
各个部门和团队通过密切合作，为客户提供最佳的解决方案，实现共同的商业目标。
这种组织架构使埃森哲成为全球管理咨询行业的领导者。
新能源公司组织架构及部门职责一、公司组织结构图二、机构设置◆最高权利机构(高级管理层)：【股东会】股东大会是公司的最高权利机关，它由全体股东组成，对公司重大事项进行决策，有权选任和解除监事、董事，并对公司的经营管理有广泛的决定权。
【董事会】董事会主要负责公司的经营决策、公司制度的审批以及高层管理人员的聘用等方面重大决策。
本公司不设监事会，只设监事，监事对股东会负责。
对公司财务以及公司董事、董事长、财务总监履行职责的合法性进行监督，维护公司及股东的合法权益。
◆公司部门设置（职能部门）：暂拟定，综合部、财务部、项目管理部、技术研发部。
三、各部门细化结构及部门职责◆综合部工作职能及职责：主要职能：综合部在公司内部处于承上启下的地位，是联结领导和基层的桥梁，协调各有关部门关系的纽带，保持公司工作正常运转的中枢，在日常工作中具有十分重要的一位和作用。
为公司的发展，提供强有力的后勤保障。
主要职责：1、协助公司领导控制和协调各部门经营管理，制定并发布公司重要制度，发表决策、宏观控制的各种指令，督促、检查各项制度、决策、指令的执行落实情况。
2、对公司各部门的业务流程和业务开展情况进行调查，了解实际运营情况，协助相关决策管理部门进行深入探讨分析，形成并落实优化或整改建议、措施。
3、促成公司各部门制度化、信息化、人性化管理，实现管理有序，业务高效，协作紧密，团队和谐。
4、协助公司领导处理外部公共关系，配合其它部门做好与外联系的具体工作。
5、开展精神文明建设，扶植并引导公司企业文化的形成与发展，营造浓厚的人文关怀氛围，实现公司经营活动与社会责任承担的共赢。
6、对优秀人才进行发现跟踪、锻炼培养。
7、负责发现并跟踪潜在的发展新方向、新业务、新项目，进行前期的考察研究。
8、负责会议、文秘、档案、办公自动化、政务、信访、保密、对外接待、资产管理等其他行政、后勤事物管理工作。
9、草拟统计工作计划、总结、报告等行政文件，收集、整理、上报统计政务信息、大事记及集团网站维护等；10、在公司领导和上级工会组织的领导下，努力做好员工的政治思想工作。
电子商务公司的组织架构（一）引言概述:电子商务公司的组织架构是指该公司的内部组织形式和职能划分。
一个合理和高效的组织架构对于电子商务公司的运营和发展至关重要。
本文将探讨电子商务公司的组织架构，重点分析其五个关键方面。
正文：一、管理层架构1. 设立公司董事会，明确公司的决策和治理结构。
2. 设立总裁，负责整体公司的战略规划和目标设定。
3. 设立不同部门的副总裁，负责具体业务领域的管理和运营。
4. 设立行政管理部门，负责人力资源、财务以及法务等事务管理。
二、业务部门架构1. 设立市场营销部门，负责产品推广、品牌宣传和市场调研。
2. 设立销售部门，负责客户关系管理、订单处理和售后服务。
3. 设立供应链管理部门，负责与供应商的合作、库存管理和物流运输。
4. 设立技术研发部门，负责产品技术研究、开发和维护。
三、支持团队架构1. 设立人力资源部门，负责员工招聘、培训和绩效评估。
2. 设立财务部门，负责公司的财务管理和财务报告。
3. 设立法务部门，负责公司的合规事务和法律纠纷处理。
4. 设立客服部门，负责与客户的沟通和问题解答。
四、项目管理架构1. 设立项目管理办公室（PMO），负责跨部门项目的协调和监控。
2. 设立项目经理团队，负责具体项目的计划、执行和控制。
3. 设立项目团队，包括各个相关部门的代表，共同协作完成项目目标。
五、团队协作架构1. 建设高效的团队协作平台，提供在线协作和沟通工具。
2. 建立跨部门的沟通机制，保证信息的畅通和协作的顺利进行。
3. 鼓励员工参与团队活动和培训，提升整体团队素质。
总结:电子商务公司的组织架构是一项复杂而重要的任务。
通过建立适应公司特点的管理层架构、业务部门架构、支持团队架构、项目管理架构以及团队协作架构，电子商务公司能够实现高效的运作和持续的发展。
每个部门的职责明确，信息流通高效，团队之间协作密切，将为公司提供良好的组织基础，促进业务增长和核心竞争力的提升。
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）”等类别。
ORACLE的组织设置本质上与之基本相似，但作为后来者作了进一步抽象与简化，系统组织划分为“业务组（Business Group）、法律实体（Legal Entity）、业务实体（Operating Unit）、库存组织（Inventory Org）”等。
如果说SAP的组织模型字面上多少还带有一点“行政组织”痕迹的话（这可能是某些声称学SAP的国内产品误入歧途的原因），ORACLE系统的组织模型字面上已经几乎看不出与“行政组织”还有什么关系，其中的“ Org”现今中文翻译成“库存组织”，容易令人望文生义和企业的“仓库管理部门（Warehouse）”混淆，但Inventory的本义实际应该是“存货”，称之为“存货组织”或许更好一些。
如下图22所示ORACLE系统有关核心业务的多组织模型：上图中的“财务、销售、采购”并非系统的“组织实体”，它仅表示业务实体（OU）具有的相关业务处理功能。
“子库”是特殊的系统组织实体，没有上下文环境可进入，主要表示库存组织之下的某种业务功能。
“业务组”的概念可以与企业的“集团”概念参看，但不同的是一个企业在系统中可以设置多个“业务组（集团）”。
通常对于一个企业来说，系统中有一个“业务组”就够了，这表示企业就是一个“集团公司”。
而对于某些业务“多元化”的特大型公司（如跨国公司），则可能需要在系统中设置多个“业务组”，表示企业由多个“集团公司”组成。
业务组的设置是系统组织设置的第一步，是最高层级的组织形态，但它主要是与人力资源信息的分隔有关，即“人员信息”的设置在一个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，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，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的设置没有直接影响。
