多组织架构.docx

多组织架构.docx

《多组织架构.docx》由会员分享，可在线阅读，更多相关《多组织架构.docx（12页珍藏版）》请在冰豆网上搜索。

多组织架构

多组织架构

（一）业务组（）

（二）法律实体（）

（三）业务实体（）

（四）库存组织（）

（五）公司成本中心（）

（六）组织

（七）多组织接入控制

（八）一个集团下的全资子公司才可以设置为。

若占百分比的，应设置为新的帐套。

在企业管理实践的过程中，“组织”（）一词是个经常需用到的概念，一般及“人员”及“职能”这两个要素密切相关，反映某种行政管理关系，例如“财务部、销售部、采购部、生产部、仓储部”等等。

企业内部行政组织（部门）的划分是企业基于“职能驱动”业务管理模式进行运作的基础。

目前，国内适用于小企业使用的大多数低端管理软件并不考虑系统中的“组织”设置问题，其系统应用模块的划分，例如采购模块、仓管模块、销售模块等等，实际上就已经基本反映了企业运作的“组织职能”划分问题。

但是，对于业务复杂、规模较大的企业（如所谓“集团企业”），管理软件使用及实施的系统“组织设置”问题将是一个首要的重要问题。

一个常见的、也是错误的系统实现方式就是将企业的“行政组织设置”直接映射到系统中，以“行政组织”代替“业务组织”。

这种系统实现方式虽有理解、掌握比较容易的优势，但却完全违背了大企业运作必须基于“流程驱动”业务模式的基本管理原则。

国内有所谓高端管理软件在系统实施过程中，常常出现有几十个财务、采购组织，几百个销售组织，乃至上千个库存组织的“盛况”，导致系统几乎没法使用的困境，其症结正在于此。

及企业的“行政组织”设置及人员规模密切相关且复杂多变不同，软件系统的“组织设置”必须以业务流程运作为核心，要求尽可能简单并保持相对稳定，在公司（人员）规模扩大的过程中具有延续性及继承性。

作为鼻祖的将系统组织简单地分为“集团（）、公司代码（）、采购组织（）、销售组织（）、工厂（）”等类别。

的组织设置本质上及之基本相似，但作为后来者作了进一步抽象及简化，系统组织划分为“业务组（）、法律实体（）、业务实体（）、库存组织（）”等。

如果说的组织模型字面上多少还带有一点“行政组织”痕迹的话（这可能是某些声称学的国内产品误入歧途的原因），系统的组织模型字面上已经几乎看不出及“行政组织”还有什么关系，其中的“”现今中文翻译成“库存组织”，容易令人望文生义和企业的“仓库管理部门（）”混淆，但的本义实际应该是“存货”，称之为“存货组织”或许更好一些。

如下图22所示系统有关核心业务的多组织模型：

上图中的“财务、销售、采购”并非系统的“组织实体”，它仅表示业务实体（）具有的相关业务处理功能。

“子库”是特殊的系统组织实体，没有上下文环境可进入，主要表示库存组织之下的某种业务功能。

（一）业务组（）

 “业务组”的概念可以及企业的“集团”概念参看，但不同的是一个企业在系统中可以设置多个“业务组（集团）”。

通常对于一个企业来说，系统中有一个“业务组”就够了，这表示企业就是一个“集团公司”。

而对于某些业务“多元化”的特大型公司（如跨国公司），则可能需要在系统中设置多个“业务组”，表示企业由多个“集团公司”组成。

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

一旦系统设置的用户名（）被及“人员”（）关联，无论使用什么“责任”进入系统，都会定位至一个确定的中，任何责任在任意时刻只能关联一个。

安装好后，系统里面已经预置了一个名为“”的“初始业务组”。

如图23所示系统预置的“”：

当以系统预置超级用户进入后，应首先设置一个具有在或下创建组织功能的“责任”名，随后给此责任的“：

”配置文件设定值为“”，则该责任就有了创建新的能力。

通常需要一次性将企业所需要的全部建立，一般另创建一个及企业名称一致如“某某集团”的新就可以了，也可以（不推荐）直接使用系统预设的“”而不创建新。

系统每新建一个，就会自动在配置文件“：

安全性配置文件”的中自动添加一个及新建同名的可选值（初始时只有“”一个值）。

在某一个下（初始为）新建的任何责任，系统都将该责任的配置文件“：

安全性配置文件”值默认为当前。

要在进入系统时能切换到新的，必须先修改该责任的“：

安全性配置文件”设定值。

如果将配置文件“：

交叉业务组”的值设为“是”，则在不同下，新建的组织名称应当（虽然可以）不同，否则查看时可能会引起混淆。

在同一个下的所有新建组织，名称不允许相同。

（二）法律实体（）

 法律实体（，）对应于真实世界中的按国家法律法规要求注册的“法人公司”。

在R11中，在组织定义时，对于每个必须为其“法人主体会计科目”关联一个“帐套”。

每个对应一个，这及真实世界的法规要求是吻合的。

如下图24所示：

要注意的是，在R11中定义的时，并未作及“会计科目弹性域结构”的“公司段”值关联，用户必须对于其是及公司段值中的哪个值对应心中有数。

而在R12中，的组织定义虽在中仍然保留，但的“法人主体会计科目”的设置被废弃（故中定义了也无用），改为在定义“分类帐”时的“会计科目设置管理器”中定义并分配法人实体。

一个分类帐设置（主辅分类帐）可以添加多个，但每个只能具有一个分类帐设置。

如下图25所示：

在R12中，还必须为法人实体分配会计科目弹性域结构的公司段即平衡段值。

每个可以分配多个“平衡段”值，公司段值集中每个段值一旦被分配给某，则其它就不能再被分配。

在R11或R12中创建一个后，应当及时到会计科目弹性域结构中添加需要对应的公司段值（一个或多个），并重新进行弹性域的编译，否则系统可能会弹出错误报警信息。

R12中一个对应多个公司平衡段值，代表有多个分公司，是它们的合并。

主辅分类帐可拥有相同或不同的公司段值集，表示从不同的维度（如按地区、按产品等）去划分公司以方便考核。

如图26所示为添加平衡段值：

无论是R11还是R12，法律实体的设置都对具体的业务处理影响不大，其及系统用户或责任不关联，不直接影响系统上下文的切换，故有人甚至认为的设置作用不大。

这对于系统的内部运作来讲情况确实近似如此，但对于需要通过系统产生供外部使用的具有法律意义的文书（如采购订单、财务报表等等），严格区分法律实体还是必须的。

R12显然更多地考虑了外部使用的这种法律要求（即所谓“法规遵从性”或“合规性”），并在相关业务应用模块中有所体现。

（三）业务实体（）

业务实体（，）是系统组织设置的重点也是难点之一。

它及法人主体本身没有必然的关系，及会计科目弹性域结构中的“公司段”也没有直接关系。

从企业实际业务管理需要的角度去看，业务实体可以看作是在系统中按照业务的相似性，把多个不同公司（包括）的业务处理过程及数据划分成相对独立的“管理单元”。

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

例如，有一个业务多元化的企业既生产医院使用的X光机也生产普通电视机，并且其下属在全国各地有多家生产X光机或电视机的分公司、子公司。

由于这两种产品所使用的物料、供应商以及针对的客户群差异很大，企业为方便管理，可以将“业务运营”划分为两个相对独立的“业务管理群组”，对应到系统中就是两个业务实体。

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

在一个业务实体下，例如“电视机管理群组”，包含了全国各地所有负责生产或销售电视机的分公司、子公司（）的日常业务运作，在业务运作的组织层面忽略了作为法人实体的公司信息，但在反映业务运营最终结果的财务阶段（），仍能够方便地按照各地的法规要求提供财务数据及结果。

而对于负责具体业务的系统用户来说，日常工作几乎不用关心或考虑“公司”的设置问题。

中的数量可以根据需要任意增加，但对于的数量基于管理方便性则要求尽可能精简。

产品早期在实施过程中，存在一个公司（）对应一个的做法或一个只能属于一个的说法，这种做法或说法并不恰当。

某些国内产品的设计由于未能有效区分“法律实体（公司）”及“业务实体（运营）”两者在系统中既相连接又有本质区别的特殊关系，只好采取一个法人公司对应一个系统业务实体的“笨办法”，企业规模小倒还能对付，一旦规模变大，注册公司增多，所谓的“系统多组织架构”就变得根本不具可用性。

业务实体的这一系统特性极大地方便了企业运作的日常管理，具有高度的灵活性及可扩展性。

如下图27是R11的定义界面：

图中的“业务实体信息”中，必须而且只能为之设定一个“帐套”，即一个只能属于一个帐套（反之，一个帐套可以分配给多个）。

要注意的是，上述业务实体信息中的法人实体设定，并不代表只能属于一个，它只是表示在“业务实体”中进行业务操作需要法人实体信息时提供默认值（在R12中明确了是“默认值”这一点）。

R12中的业务实体定义同R11基本相同，只是将帐套改为“主要分类帐”。

在中，一个可以同时指定给多个，上面“电视机管理群组”的例子已经说明了这一点；一个也可以有多个，这相当于一个注册的法人实体公司下，有多个需要独立运营的“事业部”（如X光机和电视机）。

及是“多对多”的关系，但有一个限制性的前提条件，即及必须属于同一个或。

由于及的设置在系统中可以独立进行，因此如果双方的或不同，则不能建立连接关系。

如果说法人实体及真实世界的企业行政管理组织架构还有点关系的话，业务实体则是及行政管理几乎无关，企业内部的行政组织变化对的设置没有直接影响。

在中有关采购管理、销售订单履行、应收应付管理等业务模块的功能均是建立在基础之上的。

用户在执行上述相关模块的业务处理时，总是必须进入确定的（上下文环境）才可以进行，的所谓“多组织”功能（）也是针对多而言的，及真实世界中的“多公司”（）没有直接关系。

实际上，的“采购组织、销售组织”设置也是及真实世界的行政组织“采购部、销售部”无关的，抛弃了“采购组织、销售组织”的概念，实际上就起到了类似的组织分隔作用。

的某些相关文档中，如果因描述需要而提及所谓“采购组织、销售组织”等概念，有时实际指的就是业务实体（或下的库存组织）。

（四）库存组织（）

 的库存组织（）是系统组织设置的最基础、也是最重要的工作之一。

库存组织的内涵远不是真实世界的“仓库部门”那么简单，它除了是有关“物料接收及发出”等业务功能的基础之外，更重要的是，它还是系统有关计划（）、在制品管理（）、物料清单（）等模块业务功能的操作及管理平台。

如下图28所示：

中的库存组织的作用及功能可以及中的工厂参看。

一个库存组织只能属于一个确定的帐套、一个确定的法人实体、一个确定的业务实体，具有唯一性的关系（注意：

R11的设置界面未考虑的关联限定，容易产生错误；R12作了改进，在选定之后，可用的就被限定）。

反之，一个“帐套/法人实体/业务实体”组合则可以有多个库存组织。

此外，一个下的多个可以对应属于该的不同，这相当于将分属于两个法人公司的生产两种产品的四个工厂，按相同产品两两组合抽取出来，分属于两个不同进行日常业务管理。

在中还有两个组织概念“组织、组织”，它们实际是必须构建于库存组织之上的组织概念，表示该库存组织还可以进行或的功能。

系统之所以如此处理，主要是为了控制某些不能做或而已，因为基于物料接收或发出需要所设定的数量可能比较多。

对于绝大多数基于库存组织的业务功能（个别除外），系统用户在做业务操作时，均必须首先进行的选择切换，以便进入确定的上下文环境。

库存组织的作用是如此基础，以至于的相关文档在提及组织（）概念时，如果未作特别说明，默认就是指组织。

（五）公司成本中心（）

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

如下图29所示：

在系统中创建“公司成本中心组织”后，可以运行一个“并发检查程序”，以校验“会计科目弹性域结