国产ERP：几大主流ERP组织体系分析

企业准备上ERP，前期通常要整理一份组织资料：集团下面有哪些公司，每家公司又有哪些事业部、工厂和部门。

照着现有架构图把这些名称录进系统，并不难。可接下来还有一些事情，光看这张图就不容易说清了。

比如，我们用一个简化的集团采购场景来说明。集团有甲、乙两家制造公司，采购人员集中在总部办公，统一询价、谈价格，再分别为两家公司办理采购。两家公司各自签合同，约定材料分别归自己所有，各自承担货款，材料也分别送到两家工厂。

总部还有一个装备事业部，负责考核这两家公司里同一类产品的经营情况。

这时候，几种管理关系就同时出现了：采购中心负责办事，相关公司负责记账，装备事业部还要考核相关产品的成本和利润。

采购员在总部上班，总不能因为订单由他录入，就把两家公司的材料和应付款都算到总部。可如果只按公司分开，事业部又该从哪里看自己的经营结果？

ERP里的组织体系，要把这些关系一项项安排好。

所以，看几家主流ERP怎样设计组织，我们关心的不能只有组织树能建多少层。各自的业务怎样分开，集中办理时怎样协作，组织变了以后旧记录怎样保留，都值得往下了解。

SAP、Oracle EBS、金蝶星瀚和用友BIP，在这些事情上各有自己的组织概念。前两家作为设计参照，可以帮助我们理解国产ERP选型或自研时，哪些问题应该先想清楚。

一、ERP里的几类组织，分别管什么？

先从前面的采购说起。甲公司要记自己的账，采购中心要办理业务，采购员还要有部门和岗位。这几种关系都存在，但用途不同。

1. 法人、核算主体和账簿，要分开理解

甲、乙两家公司分别签合同、承担相应责任，ERP就要保留各自的业务与核算归属。月底出甲公司本身的财务报表，就按甲公司的核算范围取数。

这里有几个容易混在一起的概念。法人涉及法律责任，核算主体决定哪一部分业务放在一起核算，账簿则用来按照相应会计规则记账、形成报告。

一家公司的核算如果要满足不同报告要求，可能会安排多套账簿。因此，系统里有几个法人、有几个核算主体、设几套账簿，需要分别确认，不能简单认为一家公司就只能对应一套账。

2. 成本中心、利润中心，按考核需要来划

甲公司的账可以单独做，但总部还想知道，装备事业部负责的产品到底赚了多少钱。这就要把甲、乙两家公司里相关的收入和成本，按事业部的考核范围归集起来。

利润中心通常用于这样的经营成果分析。成本中心则更侧重费用归集和责任分析，比如维修部门这个月花了多少钱，哪些费用后面还要按规则分摊。

具体划到哪里，取决于企业希望管到什么程度。一个部门可以对应一个成本中心，也可能还要细分。把部门名单原样复制过来，未必符合财务和业务的考核需要。

3. 业务组织，说明采购、收货和生产由谁负责

总部采购中心办理采购，工厂收货、保管材料，再安排生产。这些工作由谁负责，ERP里也要有相应的记录。

采购组织、库存组织、生产组织，就是从这些业务分工出发设置的。即使采购集中到总部，各工厂收了多少货、材料属于哪家公司，仍然要记录清楚。

当然，组织也不用越拆越细。如果一家单工厂企业由同一主体完成采购、生产和销售，只是内部岗位不同，就未必需要把每个部门都建成独立业务组织。

4. 行政组织和岗位，先看人在哪里任职

采购员属于总部哪个部门，向谁汇报，谁可以代岗，通常要通过行政组织和岗位关系来安排。

至于他能不能处理乙公司的采购，还要另看业务授权。一个人可以受托服务几家公司，人员任职和经办业务分别记录。

5. 组织视图，让不同管理者按自己的范围看业务

甲公司的负责人看甲公司的情况，装备事业部看相关产品线，集团采购负责人看两家公司的采购执行情况。同一批业务，会有不同的查看和汇总要求。

组织视图可以用来表达这些关系。但前提是，原始业务里已经记录了相应归属。如果订单上没有公司或责任范围的信息，后面再画一棵组织树，也补不回这些内容。

合并报表还要另看合并范围、内部交易抵消等规则。把几家公司挂到集团下面，只是建立了组织关系，后面的合并处理仍要配置。

还有租户、实例，以及SAP里的Client，它们涉及系统部署和数据管理边界。实际建设时要确认这些边界怎样设置，但不要把它们当成法人、事业部的另一种叫法。

二、四家主流ERP，怎样设计这些组织？

下面的SAP采用相关ERP/S/4HANA组织概念，Oracle看EBS R12.2；金蝶重点看星瀚所依托的苍穹企业建模，用友看BIP。即使是同一家厂商，不同产品线、版本的具体设置也需要分别核对。

1. SAP：先把核算、考核和业务执行的关系定好

看SAP，可以先认识公司代码和控制范围。

公司代码用于独立会计核算及相应财务报表。控制范围用于管理会计，成本中心、利润中心等也在这套管理会计安排中发挥作用。到了采购、生产和库存业务，又会用到采购组织、工厂等组织单元。

为什么要分开？还是看甲、乙两家公司。它们各自需要财务报表，集团又可能希望按共同规则分析、分配成本。在SAP里，一个控制范围可以对应多个公司代码，但这些公司代码需要满足共同运营科目表、一致会计年度变式等配置条件。SAP官方课程说明了这种关系。

集中采购也有相应安排。工厂归属于一个公司代码，采购组织则可以不绑定某一个公司代码，在满足工厂分配等条件后，为多个公司开展采购。具体关系见SAP采购组织文档。

所以，采购职能集中，并不要求把各工厂的公司归属也合并。后续单据如何核算，哪些内部往来要处理，再按实际业务配置。

这种设计把各类归属和分配条件列得比较清楚。企业采用时，也得把自己的规则说清楚。比如，两家公司准备共用一个控制范围，财务人员就需要先确认相关核算设置能否保持一致，不能只为了少建一个组织就放在一起。

2. Oracle EBS：OU、账簿和访问范围，要放在一起看

EBS的多组织体系里，有业务组、法律实体、主账簿、业务实体OU和库存组织等概念。

OU用于应收、应付、采购、订单等子分类账业务。库存组织用于记录库存交易、余额，以及相应的制造或分销活动，不能只把它理解成现实中的一间仓库。

到了R12.2的组织配置，OU要分配到主账簿和默认法律上下文；库存组织也要明确相应的OU、法律实体和账簿。这里的默认法律上下文，是配置中指定的默认法律实体信息。相关设置可查Oracle实施指南。

集团共享人员需要处理几个单位的业务时，可以通过多组织访问控制MOAC，把允许访问的OU配置给相应职责或用户。这样，同一职责下可以处理多个OU的业务，范围仍受授权限制。Oracle多组织概述对此有说明。

共享人员操作起来可以集中，各单位的业务归属仍然保留。只是实施时，要把OU、账簿和安全配置一起检查；只改其中一项，未必符合实际分工。

3. 金蝶星瀚：一个业务单元，可以按分工配置不同职能

看星瀚的组织设计，可以先把苍穹平台里的行政组织和业务单元分清。

行政组织侧重部门和人员关系。业务单元则按采购、销售、生产、库存、核算等业务需要来设置，并配置相应职能。

比如，一个业务单元负责采购，就需要配置采购职能；同时负责库存管理，再配置库存职能。

实际填单时，采购订单上的采购组织、入库单上的库存组织，以及相应结算组织，也要按各自用途来选。哪个单位负责采购，哪里收货，结算归谁，应当和企业的实际分工一致。

官方业务单元用户手册也明确提醒，不建议把所有行政组织都快速添加成业务单元。采用快速新增形成的关联，还可能影响两边属性的维护。

4. 用友BIP：从多个角度管理，也保留组织不同时期的记录

用友BIP公开介绍了多维组织与时间轴。可以这样理解：同一家企业，按不同管理要求建立组织关系；组织发生变化时，保留不同时期的版本。相关说明见用友年度报告和企业数智化底座白皮书第30页。

前面的装备事业部，就能用来理解为什么要记录时间。

假设7月开始，乙公司的一部分产品改由另一个事业部负责。到了年底，我们既可能要按当时的分工考核原事业部，也可能要按现在的管理范围，重新整理相关产品全年的表现。

这两种统计都可能用到，口径却不同。如果调整组织时直接用新关系覆盖原关系，年初已经确认的管理报表也可能跟着改变。负责人再打开报表，自然会问：当时不是这个数，为什么现在不一样？

要查清调整前后的关系，就需要保留组织在不同时期的记录。至于历史报表是否按新范围重列、采用哪种规则，还得另外确定。

这也不是用友独有的时间管理概念。SAP的利润中心主数据同样有有效期及按时段维护的属性。比较时，应当继续看具体保留哪些对象，以及业务和报表怎样使用这些记录。

三、这些组织设计，区别究竟在哪里？

前面几家的名称不少。如果直接把公司代码、OU、业务单元摆成一排，容易觉得它们只是叫法不同。

但公司代码侧重会计核算，OU承担特定子分类账业务，金蝶业务单元又可以通过配置职能承担不同业务。比较它们时，先要确认所说的究竟是哪一类用途。

从前面介绍的机制来看，各自值得借鉴的地方，以及企业要做的准备，可以放在一起看：

| 产品 | 这部分设计的长处 | 企业要先想清楚的事 |
| --- | --- | --- |
| SAP | 用不同组织单元区分核算、内部考核和业务执行，并规定分配关系 | 跨公司共用哪些规则，哪些关系需要分别保留 |
| Oracle EBS | OU、账簿和多组织访问控制配合，支持按授权集中处理业务 | 业务归属、记账安排和共享人员访问范围怎样对应 |
| 金蝶星瀚 | 业务单元可以组合职能，行政部门不必全部变成业务单元 | 哪些单位确实需要独立业务政策、数据范围和协作关系 |
| 用友BIP | 多维组织与时间轴结合，描述不同管理关系及其变化 | 各维度用于什么管理，变更前后的业务与报表采用哪套关系 |

这些能力并非某家独有，表中列的是这次重点分析的设计，也不是产品整体实力排名。

比如，SAP这类明确的分配关系，给企业提供了可遵循的规则。但前期就得讨论得很细：两家公司要怎样统一核算设置，集中采购可以覆盖哪些工厂，都要落实。

金蝶通过职能组合来描述业务分工，企业可以据此配置自己的业务单元。这里也有一项工作省不掉：一个采购部，到底只是人员所属部门，还是需要独立管理采购业务？如果这个判断没有做好，业务单元仍然可能越建越多。

用EBS的共享访问机制，企业要决定谁可以服务哪些OU。采用BIP的多维关系和历史版本，也要决定哪套关系用于经营考核、由谁维护变更。

所以我们比较组织模型，既要看它提供什么，也要看企业需要配合完成什么。只说一套标准关系不灵活，或者只说可以自定义就是好，都有些简单了。

四、企业自己设计时，先把几件事讲清楚

到了选型或自研阶段，可以请业务、财务和信息化人员一起，把前面那笔采购完整梳理一遍。

1. 先列业务责任，不急着画层级

合同主体、采购执行方、收货单位、存货归属、结算单位，先分别列出来。再补上人员任职和经营考核范围。

有些公司可能一套组织就能承担几项职能，有些集团需要分开。先知道每个单位在做什么，再决定系统里建哪些组织。为了凑齐五层模型，给每一层都造一个节点，后面反而容易多出没有实际用途的组织。

2. 上下级之外，协作关系也要写出来

总部采购中心可以为甲公司服务，也可以为乙公司服务。两家公司都在集团下面，并不能直接说明哪类采购由总部办理、哪些仍由工厂自行处理。

涉及委托采购、跨公司调拨或内部销售时，还要分别确认单据和结算方式。自研团队尤其要把这些关系落实到数据、校验和流程里。仅有组织名称和上级组织字段，后面的业务仍缺少依据。

3. 共用资料和业务权限，分别检查

集团统一物料编码，采购价格和供应商交易条件却可能按公司管理。谁维护共用内容，谁维护自己公司的内容，要事先安排。

允许采购员使用供应商资料下单，不代表也允许他修改集团共用的收款信息。同样，事业部负责人可以查看汇总结果，也不一定有权修改各公司的订单。

验收时，可以分别用普通采购员、共享人员和事业部负责人的账号试一遍。除了允许的操作，还应试试不允许的查看、修改和导出；有接口或关联数据的，也一并检查。

4. 组织变更，要带着未完业务一起考虑

原组织的采购订单还没收完，谁继续跟？未结应付款留在哪个核算主体？人员调走以后，原来的访问权限何时撤回？

这些事不交代，组织树虽然改好了，业务人员还是不知道下一步该怎么办。

历史记录也要安排好。哪些保留发生时的归属，哪些管理分析允许按新范围重列，最好在变更前约定。到年底再临时统一口径，前面的报表可能又要重新核对。

写在最后

看完这些模型，我更愿意先问企业一个具体问题：同一笔采购，从总部经办，到工厂收货，再到财务核算和事业部考核，各自的归属能不能说清楚？

如果还说不清，先让相关部门把这些分工谈明白。说清楚以后，再请厂商用系统演示，或者由自研团队落实到设计里。

组织体系设计得怎么样，最终还是要回到这些业务上看。采购可以集中办理，账要各自记清；管理层可以换个范围看经营，历史记录也要查得明白。