ORACLE EBS 系统架构与应用实践（一）

一、从ERP到EBS

从上世纪70年代晚期的物料需求计划MRP（Material Requirements Planning）到80年代的MRP II，再到90年代的企业资源计划ERP（Enterprise Resource Planning），企业管理软件（或曰应用软件）已经走过了三十多年的历史。今天ERP事实上几乎已经成了“管理软件”的代名词，然而，在专业人士及有些专家学者眼中两者还是有本质区别的。

在国内，据说鼎盛时期注册的6000家软件公司中，有3000家宣称自己是做ERP的，截止目前，有人估计国内可能还剩下成规模或不成规模的大约1000家左右，而其它国家加起来的总数也不过几百家。有网友曾调侃说：SAP/ORACLE被气得只哭，你们都叫ERP了，那我该叫啥呢？有国内ERP第一人之称的陈启申老师前两年曾撰文呼吁：应当正本清源回到Gartner最初的关于ERP的定义上来，进销存就是进销存，财务软件就是财务软件，一个连基本的生产制造都没有的东西怎么能称为ERP呢？然而，更狠的还有：ERP已经被中国人终结，现在是ERP II时代！

闲话少扯，言归正传。今天关于管理软件的名词概念委实名目繁多，ERP、HRM、CRM、SCM、SRM、EHR、PDM、PLM、EPM、BIS以及SOA、SAAS等等，“三字经”泛滥江湖，以致于使一些刚入行的“新人”摸不着头脑。在这方面，应当说SAP关于企业管理软件的“划分法”相对比较合理与实用。

从企业的管理实践与信息化发展进程所处阶段来看，涉及企业的核心业务过程，诸如财务、采购、库存、销售、计划、生产制造等范畴，对应SAP R/3的主要内容（FI/MM/PP/SD /CO），属于BACK-OFFICE的应用范畴，SAP将它划入ERP；属于人力资源管理范畴，包括人事、培训、工资管理等等，SAP将之名曰HRM；属于FRONT-OFFICE的应用范畴，主要是“客户相关”，涉及客户关系管理的内容，包括市场营销、销售管理、售后服务、渠道管理、电话或网上销售等等，SAP将它划入CRM；涉及买卖双方的业务协同、网上应用，主要是“供应商相关”的内容，SAP将它划入SCM（关于此点，各方的习惯与差别较大）；关于供应商资格认证、管理考核等等，涉及供应商关系管理的内容，SAP将它划入SRM；关于产品研发过程管理，涉及产品生命周期的内容，SAP将它划入PLM（或PDM）；相对于上述主要涉及“业务过程管理”（联机事务处理OLTP）的范畴，主要针对业务过程的结果进行数据分析（联机数据分析OLAP）的应用软件，则名曰BIS（商务智能分析）或EPM（企业绩效分析）。

ORACLE的应用产品（Applications Product，相对于其数据库Database 而言的称谓）早期则简单地划分为四大部分：财务、制造、分销、人力资源。其中的所谓“分销产品”（Distribution），有人或许会将之与企业的产品“直销、分销”模式混淆，但实际与企业的产品分销模式管理没啥关系，它只是“采购PO、库存INV、销售订单管理OM”的总称。不过，若针对不涉及生产制造的商业企业而言，ORACLE 分销产品因为包括库存计划功能，已是一个很完整的应用软件，故而称之为“分销产品”还是比较贴切。但是，容易造成误解混淆总是个麻烦的事情，基于方便或习惯的原因，“采购PO、库存INV、销售订单管理OM”加在一起又常被业者笼统地称之为“供应链SCM产品”（此点与许多企业或用户的习惯叫法也比较接近）。当然这又容易和SCM的本来涵义产生混淆。显然，在这方面ORACLE与SAP相比没有那么精细准确，马马虎虎也就算了。

十年前ORACLE 11i 出台时，干脆一网打尽将所有应用产品统称为“电子商务套件”（E-Business Suits，EBS），不仅解决了产品的命名问题，同时也搭上了“电子商务”这个时代潮流的便车，可谓一举两得。但不好的是，由于缺少从企业信息化进程与发展阶段对产品家族“分层分级”的划分界定，认识较浅与经验不足的企业面对几十、上百的相关应用模块可能会感到茫然无措或因销售的引导而误入歧途。

 

二、ORACLE EBS的系统组成

早期的ORACLE 11i EBS将系统主要划分为五大部分，包括：

财务应用产品：总账GL、应收AR、应付AP、固定资产FA、现金管理CA、项目会计Project Account、财产管理Property、金融管理Treasure等等；

制造应用产品：物料清单BOM、库存INV、采购PO、计划MPS/MRP、订单管理OM、发运管理Ship、质量管理QA、在制品WIP、成本管理Cost、车间管理Shop Floor、工程管理ENG、能力计划CAP、高级价格Pricing、制造计划Manufacturing Scheduling、高级供应链计划ASCP、供应商计划Supplier Scheduling、配置管理Configurator、流式制造Flow、流程制造Process、项目制造Project等等；

人力资源产品：人事管理HRMS（包括全球与各国应用）、培训管理Training、时间管理Time、组织管理Hierarchy等等；

客户关系管理产品：市场营销Marketing、销售管理Sales、服务管理Service、呼叫中心Call Center等等；

公共服务产品：津贴管理Grant、劳动力管理Labor、公共预算Public Budgeting等等。

随着产品系统的日臻完善与发展，应用范围的不断扩大，后期的11i（11.5.10）则将系统主要划分为十五个大部分，包括：

财务部分：GL、AR、AP、FA、Cash、Property、Treasure、iPayment、iAsset、Grant、Labor、Public Budgeting等等；

制造部分：BOM、ENG、INV、MPS/MRP、WIP、Cost、QA、Warehouse、Project、Manufacturing Scheduling 、Flow Manufacturing、Process Manufacturing等等；

采购部分：PO、i-Procurement、Sourcing、iSupplier、Supplier Scheduling等等；

订单履行部分：OM、Shipping、Pricing、Configurator、Transportation、Release、Automotive等等；

供应链计划部分：ASCP、Demand Planning、Global Order Promising等等；

客户关系管理部分：Marketing、Sales、Quoting、iStore、Proposal等等；

合同和服务部分：Contract、Service Fulfillment、iSupport、Depot Repair、Teleservice、Knowledge Management等等；

人力资源部分：HRMS、Training、Time等等；

设备维护部分：EAM、Maintenance Repair等等；

产品生命周期管理：Advanced Product Catalog等等；

租赁管理部分：Lease Management等等；

项目管理部分：Project Costing、Project Billing、Project Management、Project Source等等；

高等教育管理：Student、Self-service等等；

客户数据管理：Customers Online、Data Librarian等等；

商业智能：BIS、Balanced Scorecard等等。

与早期相比，“采购、订单履行、供应链计划”由于功能的完善丰富，应用范围的扩大增强，故得以脱离原“制造系统”，自成体系。“合同和服务”脱离原客户关系管理，自成一脉，情况也类似。

到了目前的ORACLE R12，系统范畴的划分与R11.5.10相比虽略有调整，但差别不大，主要表现在新增了“物流（Logistics）部分”，实际也就是将原来的“库存INV、仓库Warehouse、运输Transportation”归在了一起，单独出来、自立门户；原先的大类划分中新增了不少模块，其中的部分所谓“新增”，也不过是因为某些重要功能经“增强完善、发展壮大”后从原先的模块中独立出来自立门户，例如Leads Management、Partner Management等等；有些则是模块在大类间做了些移动，例如iStore从“客户关系管理”移动到“订单履行管理”（Order Fulfillment）中等等。

以上之所以不怨其烦地介绍EBS内容的发展变化，做相关模块组成的罗列，主要是想说明以下两个问题：

一是经过的多年的发展与完善，ORACLE产品范围的广度、产品内容的深度，已经“由小到大、由浅入深”形成了庞大的产品组件家族。而更重要的是，ORACLE产品发展与成熟的过程，同时也与企业管理信息化必须“分层分级”，必然是由初级阶段向高级阶段逐步过渡、完善的历史进程高度吻合，这或许正是ORACLE产品之所以强大，有高度的可伸缩性与适应性，全球应用市场非常广阔的关键所在；

二是尽管ORACLE产品家族迄今已经包含300多个模块，乍一看令人生畏。但其最核心、最基础的东西仍是早年就开始做的包括财务、制造、分销（或曰供应链）等在内的十来个基本模块。与SAP今日的“MYSAP套件”仍然是以差不多二十年前开发的R/3（MM/FI/PP/SD/CO）为核心相类似，ORACLE最初的那十来个核心模块仍然是今日ORACLE EBS产品大厦的坚实基础。现在如此，将来还会是如此，尽管有点遗憾的是，它们没有共同拥有一个类似R/3那样响亮的名字，这在产品的市场宣传以及企业对 EBS的认知接受方面多少有些不利影响。

 

三、ORACLE EBS 的系统架构

     这里的所谓“系统架构”非是指“技术层面”而言，而是指从企业实际应用的角度来看的“应用架构”。借用马斯洛的“需求层次论”，企业与“人”一样，其信息化的应用需求也有一个从低到高，从“核心（Core）”到“增强（Enhance）”再到“高级（Advance）”的客观过程，不可能一蹴而就。下图是一个已经使用了十多年的有关ORACLE产品核心基础模块应用的示例图，它与SAP R/3的内容(FI/MM/PP/SD/CO)相比，高度近似，其核心内容实际在R/3的基础上有进一步的精简：

     企业的现实目标是赚钱、盈利，利润是企业存在的最初理由。对于一个典型的制造型企业而言，简单来说，它至少包括两个最基本的业务过程：其一是所谓“价值增值”过程，即买进原材料、进行加工生产出产品，再以更高的价值卖出去，这个过程通常属于“业务运营管理”范畴；其二是所谓“价值实现”过程，即从客户回收货款，向供应商支付购买材料的费用，再根据国家的会计法规，扣除相关费用如设备折旧等等，剩下的就是利润（或曰股东价值），这个过程通常属于“财务会计管理”范畴。

如果一个企业的“业务运营”与“财务会计”管理的核心过程能够实现信息化、IT化，那么按照国内的说法就是实现了“财务/业务一体化”。上图示例中的13个模块恰好实现了对“业务运营”与“财务会计”管理这两大核心业务过程的全覆盖，符合“财务/业务一体化”的标准，是一个最小的、也是基本完整的“企业级”应用。以国内最早的ORACLE ERP用户“华为”为例，其1996年上线R10.6时，就仅选择了这13个最核心、最基础的模块，因此其当时的企业信息化也仅是“财务业务一体化”的水准。细心的读者可能已经发现，“质量管理QA”对于一个制造型企业的重要性是怎么强调也不过分，为何这核心的13个模块中当初却没有将之包括？另外，人力资源管理也很重要，为何核心应用也不包括？

    一个成熟完善的企业应用管理系统，若从系统所处理的对象或范围来划分，可以归纳为三大部分：财务Finance、业务Business、事务Transaction。它们分别对应于“资金流、实物流、信息流”这三个领域。实现“财务+业务+事务”的高度集成，是一个企业信息系统的终极理想，然而要做到这一点，基于系统的实现成本、设计复杂性、实施方便性等相互背离的因素综合考虑则绝非易事。

就企业广义的“财务Finance”的内涵而言，它通常包括属于日常的、基础性的“会计Accouting”工作，以及属于非日常性的、狭义的“财务管理”工作。

就企业广义的“业务Business”的内涵而言，它可以划分为“直接业务”与“间接业务”两大部分。直接业务，亦可称之为“核心业务”，它体现的是价值增值的运营过程，例如“采购、库存、制造、订单履行”等，它们的显著特点：一是实际工作与系统应用均缺一不可，二是同时与“财务”的链接关系十分紧密，必须高度集成；间接业务，亦可称之为“专业业务”或“外围业务”，它通常是为“核心业务”提供支持与服务，例如“HRM、CRM、QAM、APS、EAM”等，从系统应用的角度来说，没有它们对应用的完整性或整体效果影响不是太大，它们的共同特点是与“财务”的链接关系不是太紧密。

就企业广义的“事务Transaction”的内涵而言，它可以划分为“特定事务”（Specific Transaction）与“行政事务”（General Transaction）两大部分。“特定事务”通常需要一些专门知识，涉及的部门或人员范围较小，例如“编码管理、预算管理、合同管理、海关事务”等等，此类“事务”通常是为核心的“业务”与“财务”活动提供支持与服务，但在系统中与“业务、财务”的集成性、紧密性要求相对比较低。而“行政事务”基本上属于OA的范畴，特点是涉及的部门或人员范围广大，一般是围绕“人的活动”来展开，其中虽有部分可能会与“财务/业务”发生一定关系，例如：“行政申购管理、费用报销管理”等等，但对核心的“业务/财务”系统应用影响比较有限。

企业的信息化发展进程实际上也就是从核心的“财务/业务一体化”，逐步向非核心的“业务、事务”扩展与深入，并不断提高系统应用层次的过程。与之相适应，软件产品的应用架构规划，产品设计的优先级选择，各模块之间的链接关系，均必须考虑从“财务会计”向“核心业务”、“非核心业务”乃至“事务”逐步扩展、丰富、完善的路径选择问题，否则会对产品的未来前途产生致命的影响。有网友在谈到SAP/ORACLE产品的特点时，曾表示：SAP/ORACLE的产品模块设计简洁、实用，反观某国产软件，在核心系统还做得很不怎样的时候，居然就在里面添加了“档案管理、合同管理”模块，不仅企业应用没什么效果，而且还给系统实施过程带来一堆麻烦。

下图表达了当前ORACLE产品系统的应用架构层次性与实践应用的可伸缩性：

（注: EGO 高级产品目录，IGC 合同履行管理，IEP 预测管理，ZPB 企业计划与预算管理）

毫无疑问，“财务”居于核心地位，与之仅仅依靠、高度集成的是“核心业务”，随着企业信息化实践的深入，逐步向“非核心业务”及“事务”应用领域外延扩张。前两年，国内某ERP专业网站曾组织过一个有关“如何提高国内ERP生产制造水平”的讨论，有人在抱怨国内ERP产品水平低时，将原因怪罪到国产厂商“财务软件”的出身，这种说法实际并不成立。看看SAP/ORACLE（还有自称世界第三的SAGE），全是做财务软件出身，反而是靠HRM成名的Peoplesoft、靠生产制造成名的JDE、靠CRM成名的Sieble，最后全部都倒下了。从产品整体设计与应用角度来讲，财务软件的出身不仅不是短处，反而是优势所在。国内产品从财务软件向ERP软件进化所遇到的困难，不是“出身”问题，而是“路径选择”问题。