门）的划分是企业基于“职能驱动”业务管理模式进行运作的基础。目前，国内
适用于小企业使用的大多数低端管理软件并不考虑系统中的“组织”设置问题，
其系统应用模块的划分，例如采购模块、仓管模块、销售模块等等，实际上就已
经基本反映了企业运作的“组织职能”划分问题。
但是，对于业务复杂、规模较大的企业（如所谓“集团企业”），管理软件使用与实
施的系统“组织设置”问题将是一个首要的重要问题。一个常见的、也是错误的系统实现方
式就是将企业的“行政组织设置”直接映射到系统中，以“行政组织”代替“业务组织”。
这种系统实现方式虽有理解、掌握比较容易的优势，但却完全违背了大企业运作必须基于“流
程驱动”业务模式的基本管理原则。国内有所谓高端管理软件在系统实施过程中，常常出现
有几十个财务、采购组织，几百个销售组织，乃至上千个库存组织的“盛况”，导致系统几
乎没法使用的困境，其症结正在于此。
与企业的“行政组织”设置与人员规模密切相关且复杂多变不同，软件系统的“组织
设置”必须以业务流程运作为核心，要求尽可能简单并保持相对稳定，在公司（人员）规模
扩大的过程中具有延续性与继承性。作为 ERP 鼻祖的 SAP 将系统组织简单地分为“集
团（Client）、公司代码（Company Code）、采购组织（Purchase Org）、销售
组织（Sale Org）、工厂（Plant）”等类别。ORACLE 的组织设置本质上与之基
本相似，但作为后来者作了进一步抽象与简化，系统组织划分为“业务组
（Business Group）、法律实体（Legal Entity）、业务实体（Operating Unit）、
库存组织（Inventory Org）”等。
如果说 SAP 的组织模型字面上多少还带有一点“行政组织”痕迹的话（这可
能是某些声称学 SAP 的国内产品误入歧途的原因），ORACLE 系统的组织模型字
面上已经几乎看不出与“行政组织”还有什么关系，其中的“Inventory Org”
现今中文翻译成“库存组织”，容易令人望文生义和企业的“仓库管理部门
（Warehouse）”混淆，但 Inventory 的本义实际应该是“存货”，称之为“存
货组织”或许更好一些。如下图 22 所示 ORACLE 系统有关核心业务的多组织模型：
