(关于本书的其它详细内容，请参考dwz.cn/408pnZ)
第一章 ORACLE EBS系统架构与应用实践
0.1 从ERP到EBS
从上世纪70年代晚期的物料需求计划MRP（Material Requirements Planning），到80年代的MRP II，再到90年代的企业资源计划ERP（Enterprise Resource Planning），企业管理软件的发展已经走过了三十多年的历史。尽管今天的所谓ERP，在很多场合下被当作了“企业管理软件”的代名词，但事实上我们也会发现，业界还有诸多关于管理软件产品的名词概念，常常被拿来与ERP相提并论，诸如HRM、CRM、SRM、SCM、PDM、PIM、PLM、BIS、EPM等等，以至于使一些刚入行的初学者感到非常困惑。
有关企业管理软件产品的细分类别的划分方法，尽管在业界并无绝对、统一的标准，但从企业的管理实践与信息化发展的历史进程来看，涉及企业的核心业务过程，诸如财务、采购、库存、订单、计划、生产制造等领域，属于所谓“Back Office”的应用范畴，习惯上统称为ERP；属于所谓“Front Office”的应用范畴，主要是与客户相关，涉及客户关系管理方面的内容，包括市场营销、销售管理、售后服务、渠道管理、电话或网上销售等，习惯上统称为CRM。
而主要是与供应商相关，涉及供应商关系管理的内容，包括供应商搜寻、资格认证、绩效评估与考核等内容，习惯上称之为SRM；涉及与供应商的业务协同、网上采购询/报价、招投标等相关内容，则通常将之名曰SCM；但需注意的是，关于供应链管理SCM的概念与内容，业界通常又有所谓“狭义”与“广义”之分，狭义的SCM主要是指与供应商之间实现业务系统协同的特定领域，而广义的SCM，则通常是指涉及企业“价值运营”的物流业务全过程，包含了计划、采购、库存、制造、订单履行，以及与供应商/客户进行网上业务协同等系统在内的所有物流领域的总称。
属于产品研发过程管理，涉及产品数据管理的相关内容，习惯上统称为PDM。如将PDM的范畴缩小到仅包括相对比较简单的产品（物料）信息管理范围，则可以称之为PIM，而如将PDM的范畴扩大到包含产品生命周期管理的相关内容，则统称为PLM；属于人力资源管理范畴，包括人事、培训、工资管理等内容，习惯上统称为HRM；相对于主要涉及“业务过程管理”范畴，而主要针对业务过程的结果进行数据分析的应用软件产品，则名曰BIS（商务智能分析），而将BIS的范围进一步扩大到企业绩效管理的范畴，则称之为EPM。
ORACLE将其所有管理软件统称为“应用产品（Applications Product）”，是相对于其数据库（Database）产品而言的称谓。ORACLE的应用产品早期（11i之前）曾被简单地划分为四大部分：财务、制造、分销、人力资源。其中的所谓“分销产品”（Distribution），有人或许会将之与企业的产品“直销、分销”概念相混淆，但实际与企业的产品分销管理并没有直接的关系，它只是“采购、库存、订单管理”产品系统的总称。不过，若针对不涉及生产制造的商业企业而言，ORACLE“分销产品”因其库存系统已经包括了“库存计划”功能，是一个相对比较完整的应用软件系统，故而称之为适用于贸易型企业的“分销产品”也还比较贴切。
2000年ORACLE发布其管理软件第11i版时，将其所有应用产品统称为“电子商务套件”（E-Business Suits，EBS），不仅解决了其应用产品的统一命名问题，同时也搭上了“电子商务”这个时代潮流的便车，可谓一举两得。实际工作中，基于管理方便或使用习惯等方面的原因，属于传统ERP范畴的“计划、采购、库存、订单履行”产品加在一起又常被业界统称为“供应链SCM产品”。由于这容易和供应链SCM的本来涵义（广义或狭义）产生混淆，故本书将之特指为“供应链核心系统”产品，以示区别。
0.2 ORACLE EBS的系统组成
0.2.1 EBS系统的早期组成分类
早期的ORACLE EBS 11i曾将其整个系统主要划分为五个大类组成部分，包括：
财务应用产品：总账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等。
0.2.2EBS系统的近期组成分类
随着EBS产品系统的日臻完善与发展，应用范围的不断扩大，后期的EBS 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（Product Information Management）等；
租赁管理部分：Lease Management等；
项目管理部分：Project Costing、Project Billing、Project Management、Project Source等；
高等教育管理：Student、Self-service等；
客户数据管理：Customers Online、Data Librarian等；
商务智能：BIS、Balanced Scorecard等。
与早期组成部分的大类划分相比，“采购、订单履行、供应链计划”由于功能的完善增强，应用范围的扩大丰富，故得以脱离原所属的“制造系统”，自成体系。“合同和服务”脱离原“客户关系管理”，自成一脉，情况也类似。
0.2.3 EBS系统的最新组成分类
2007年ORACLE所发布的最新版本EBS R12，其系统组成的划分与EBS 11i最近版本R11.5.10相比仅略有调整，差别不大，主要表现在新增了“物流（Logistics）”大类部分，实际也就是将原来的“库存INV、仓库Warehouse、运输Transportation”模块归在了一起，单独出来成为一个大类；原先的相关大类划分中“新增”了不少模块，其中的部分所谓“新增”，仅是因为某些重要功能经“增强完善、发展壮大”后，从原先所属的系统模块中独立出来自立门户，例如Leads Management、Partner Management等；有些则是原模块系统在大类间做了移动调整，例如iStore从“客户关系管理”移动到“订单履行管理”（Order Fulfillment）中等。
如图1‑1所示，形象地表达了ORACLE应用产品过去二十多年来“从小到大、由弱到强”的发展历史进程。
图1‑1EBS的发展历程
以上之所以不怨其烦地介绍EBS系统组成内容的发展变化，做系统相关模块组成的罗列，主要是想说明以下两个问题：
一是经过的多年的发展与完善，ORACLE应用产品范围的广度、内容的深度，已经“由小到大、由浅入深”形成了庞大的产品组件家族。ORACLE应用产品发展与成熟的过程，同时也与企业管理信息化必须“分层分级”，必然是由“初级阶段”向“高级阶段”逐步过渡、完善的历史进程高度吻合，这或许正是ORACLE产品之所以强大，有高度的可扩展性与适应性，全球应用市场非常广阔的原因所在；
二是尽管ORACLE应用产品家族迄今已经包含300多个功能模块，乍一看令人生畏。但其最核心、最基础的应用仍是早年就开始做的包括财务、制造、分销（或曰供应链核心系统）等在内的十来个基本模块。与SAP今日的“MySAP套件”仍然是以二十多年前开发的R/3系统（MM/FI/PP/SD/CO）为核心相类似，ORACLE最初的那十来个核心模块仍然是今日EBS产品大厦的坚实基础。现在如此，将来还会是如此。研究与掌握这些核心的基础模块，并能在企业管理实践中充分发挥其功用，是学习与应用EBS系统的关键之所在。
0.3 ORACLE EBS系统的应用架构
0.3.1 EBS系统的基础功能架构
这里的所谓“系统架构”非是指“技术层面”而言，而是指从企业实际应用的角度来看的“应用架构”。借用马斯洛的“需求层次论”，企业与“人”一样，其信息化的应用需求也有一个从低到高，从“核心（Core）”到“增强（Enhance）”再到“高级（Advance）”的客观过程，不可能一蹴而就。图1‑2所示，是一个有关ORACLE产品核心基础模块应用的示例图，它与SAP R/3的内容(FI/MM/PP/SD/CO)相比，高度近似，其核心内容实际在SAP R/3内容基础上有进一步的精简。
图1‑2EBS基础功能架构图
企业的现实目标是盈利，利润是企业存在的最初理由。对于一个典型的制造型企业而言，简单来说，它至少包括两个最基本的业务过程：其一是所谓“价值增值”过程，即买进原材料、进行加工生产出产品，再以更高的价值卖出去，这个过程通常属于“业务运营管理”范畴；其二是所谓“价值实现”过程，即从客户回收货款，向供应商支付购买材料的费用，再根据国家的会计法规，扣除相关费用如设备折旧等等，剩下的就是利润（或曰股东价值），这个过程通常属于“财务会计管理”范畴。
如果一个企业的“业务运营”与“财务会计”管理的核心过程能够实现信息化、IT化，那么按照国内的说法就是实现了“财务/业务一体化”。图1-2示例中的13个模块恰好实现了对“业务运营”与“财务会计”管理这两大核心业务过程的全覆盖，符合“财务/业务一体化”的标准，是一个最小的、也是基本完整的“企业级”应用。以国内最早的ORACLE ERP用户之一“华为”为例，其1997年上线R10.6时，就仅选择了这13个最核心、最基础的模块，因此其当时的企业信息化也仅是“财务业务一体化”的水准。细心的读者可能已经发现，“质量管理QA”对于一个制造型企业的重要性是怎么强调也不过分，为何这核心的13个模块中当初却没有将之包括？另外，人力资源管理也很重要，为何核心应用也不包括？
0.3.2 EBS系统的应用层次架构
一个成熟完善的企业应用管理系统，若从系统所处理的对象或范围来划分，可以归纳为三大部分：财务Finance、业务Business、事务Transaction。它们分别对应于“资金流、实物流、信息流”这三个领域。实现“财务+业务+事务”的高度集成，是一个企业信息系统的终极理想，然而要做到这一点，基于系统的实现成本、设计复杂性、实施方便性等相互背离的因素综合考虑则绝非易事。
就企业广义的“财务Finance”的内涵而言，它通常包括属于日常的、基础性的“会计Accouting”工作，以及属于非日常性的、狭义的“财务管理”工作。
就企业广义的“业务Business”的内涵而言，它可以划分为“直接业务”与“间接业务”两大部分。直接业务，亦可称之为“核心业务”，它体现的是价值增值的运营过程，例如“采购、库存、制造、订单履行”等，它们的显著特点：一是实际工作与系统应用均缺一不可，二是同时与“财务”的链接关系十分紧密，必须高度集成；间接业务，亦可称之为“专业业务”或“外围业务”，它们通常是为“核心业务”提供支持与服务，例如“HRM、CRM、QAM、APS、EAM”等，从系统应用的角度来说，没有它们对应用的完整性或整体效果影响不是太大，它们的共同特点是与“财务”的链接关系不是太紧密。
就企业广义的“事务Transaction”的内涵而言，它可以划分为“特定事务”（Specific Transaction）与“行政事务”（General Transaction）两大部分。“特定事务”通常需要一些专门知识，涉及的部门或人员范围较小，例如“编码管理、预算管理、合同管理”等等，此类“事务”通常是为核心的“业务”与“财务”活动提供支持与服务，但在系统中与“业务、财务”的集成性、紧密性要求相对比较低。而“行政事务”基本上属于OA的范畴，特点是涉及的部门或人员范围广大，一般是围绕“人的活动”来展开，其中虽有部分可能会与“财务/业务”发生一定关系，例如：“行政申购管理、费用报销管理”等等，但对核心的“业务/财务”系统应用影响比较有限。
企业的信息化发展进程实际上也就是从核心的“财务/业务一体化”，逐步向非核心的“业务、事务”扩展与深入，并不断提高系统应用层次的过程。与之相适应，软件产品的应用架构规划，产品设计的优先级选择，各模块之间的链接关系，也均必须考虑从“财务会计”向“核心业务”、“非核心业务”乃至“事务”领域逐步扩展、丰富、完善的路径选择问题，否则会对产品的未来发展前途产生致命的影响。图1‑3表达了ORACLE EBS产品系统的应用架构层次性与实践应用的可扩展性。
图1‑3EBS可扩展的应用层次架构
图1-3中，有关缩写代码如“AME、i-Pro、EGO”等所代表的系统模块，可参考EBS系统内部“应用产品”的“注册”菜单功能的列表显示的“简称”，但需注意的是，习惯上所使用的系统模块“简称”，可能与系统内部的“注册”代码并不完全相同，例如“订单管理”模块习惯上简称为OM，但系统内部注册代码却是ONT。
毫无疑问，在企业信息化实践过程中，ORACLE EBS“财务”系统的应用居于核心地位，与之紧紧依靠、高度集成的是“核心业务”的相关应用。而随着企业信息化实践的不断深入，EBS系统产品的应用将由里向外，逐步由核心的“业务/财务”领域向“非核心业务”及“事务”应用领域外延扩张。
0.4 基于ORACLE EBS系统的集成供应链管理
0.4.1 EBS的集成供应链管理系统（ISC）
现代企业之间的竞争已经从过去传统的“产品竞争、市场竞争”，扩展到更大范围的“供应链”与“供应链”之间的竞争。随着企业社会化分工与合作业务模式的发展与完善，传统的制造型企业越来越多地通过“代工”方式，将其“制造业务”外包出去而成为一个所谓的“供应链管理型”企业。
广义的供应链SCM概念包含了属于企业“价值运营”范畴的内、外部物流业务全过程。一个构建于高度集成的信息化平台之上，具有高的内外部业务流程协同效率，低的全流程运作综合成本的企业供应链运作体系，常又被特称为“集成供应链（Integrated Supply Chain，ISC）”管理系统。集成供应链管理系统在企业总体信息系统框架中的核心地位与作用，如图1‑4所示。
图1‑4企业总体业务系统框架
一个以自身企业为核心、向上下游（供应商/客户）延伸、完整且高度集成的企业供应链管理系统，包括“内部供应链核心业务系统”与“外部（供应商/客户）供应链业务协同应用系统”两大组成部分，如图1‑5所示。
图1‑5EBS集成供应链管理系统框架
需注意的是，图1‑5中所示的企业“外部（供应商/客户）供应链业务协同系统”通常又被划入所谓“供应链高级业务系统”的应用范畴，不同企业的应用需求与管理方式可能差别较大，而本书将重点讨论的企业“（内部）供应链核心业务系统”，作为“（外部）供应链高级业务系统”的应用基础与前提，实际不同企业的实践之间，则通常可能具有较高的相似性。
0.4.2 EBS的供应链核心业务系统
对于一个典型的“供应链管理型”企业来说，其内部供应链管理的核心业务流程体系中，“计划”环节总是居于统帅地位，一头连着“需求（客户）”，一头连着“供应（供应商）”，决定着其它业务环节的运行方式与工作状态；“物流（库存）”环节则处于基础与保障地位，是其它业务环节运作结果得以实现的物理平台；而“采购”与“订单”业务环节则是实现供应链价值运营目标的主体与关键。有关EBS的供应链核心业务系统组成框架，如图1‑6所示。
图1‑6企业供应链核心系统框架
本书的所谓“EBS供应链核心系统”所要讨论的内容，正是包含了如图1-6中所示的“计划、采购、库存（物流）、订单”产品系统的全部核心业务范畴，它们作为一个整体，基本覆盖了企业供应链核心业务的全部过程。
而在企业供应链核心业务流程体系中，EBS系统以“计划流程（Plan Process）”为“枢纽”，连接“销售订单流程闭环Order Life Cycle”（Order to Cash）与“采购订单流程闭环PO Life Cycle”（Purchase to Pay），所构建的供应链核心业务系统流程框架，将是我们所要讨论的系统业务流程的主轴与骨干，如图1‑7所示。
图1‑7EBS供应链核心业务流程框架
0.5 ORACLE EBS系统的应用实践
历经过去二十多年尤其是近十年的快速发展与完善，ORACLE电子商务套件（EBS）作为一个大型的、高端的管理软件程序包，已经在全世界范围内有着广泛的应用，拥有数万家不同类型的用户，涉及高科技、制造、商业、化工、航空、金融、公用事业等各行各业。ORACLE EBS系统作为高端ERP系统的代表之一（另一是SAP），事实上已经成为全世界范围内众多不同类型企业信息化“系统选型”的首选目标之一。
一个公司选择什么样的ERP产品搭建自己的企业信息化平台，并不是如有些人所说的“主要考虑当前的企业管理水平与成熟程度，适合就好”，而是应当立足当前、放眼未来，考虑企业的长远发展规划与愿景目标。企业信息化是一项重要的基础性管理工作，与企业管理水平的提高是相辅相成、相互促进的关系，也有一个不断完善、逐步积累的过程。ORACLE EBS系统的应用架构设计如前所述，从企业应用角度来看，从内到外、从初级阶段到高级阶段有很强的可扩展性，可以适应企业不同发展阶段管理进步的需要；即使是具体到EBS每一个业务模块内部，其系统实现功能也有“基础应用、增强应用与高级应用”之分，可以适应不同企业，以及同一企业在不同发展阶段的业务需要。
0.5.1EBS系统的应用集成性
衡量一个企业信息化应用水平高低的重要标志，是企业对于自身关键业务信息管理的集成应用能力。一个高度集成的企业信息化管理系统，必须在系统应用集成方面同时考虑以下三大核心要素：数据集成、流程集成、活动集成。
所谓“数据集成（Data Integretion）”比较好理解，即通常所说的“消除信息孤岛”是也。它可以分为两个方面：“静态数据共享”与“动态数据传递”。“静态数据”主要指类似“物料、供应商、客户”等基础数据，由各系统模块调用共享；“动态数据”则主要指诸如“采购订单、制造工单、销售订单、应付/应收发票”等随时间不断累积的业务数据，它们之间需要遵循一定规则进行数据传递与共享。
相较于传统的手工业务模式，现代的计算机技术与数据库技术在解决企业管理的“数据集成”方面，总的来说还是比较容易。在系统“静态数据共享”方面国内外产品差距不大，但在系统“动态数据传递”方面，由于有些国内产品采取的是“模仿手工单据”的实现方式，导致系统的单据“实体”数量众多，不同单据实体之间的数据传递、同步的工作量巨大，实现起来就非常困难，因而实际无法有效地实现真正的动态数据集成。
ORACLE EBS系统一方面通过所谓“事务处理工作台”的设计，尽可能地减少了相关“业务单据实体”的数量，另一方面又借助工作流、后台并发流程等系统工具，实现了不同业务单据实体之间数据传递的自动化与高效率。此外，EBS产品在“动态数据集成”方面还有一个突出的“亮点”是各模块几乎都有集成第三方系统的接口（API），而其内部各模块之间的动态数据集成也基本上采取类似集成第三方系统的“松耦合”方式，因而在保持相关业务数据具有高度集成性的同时，还兼有数据集成方式非常灵活的优点。
所谓“流程集成”也可以分为两个方面：“流程传递的自动化”与“流程识别的自动化”。ORACLE在其产品宣传中经常讲到一点“用户只需很少的干预与击键操作，其它都由系统自动替你完成”，说的正是这个意思。
所谓“流程传递的自动化”，例如ORACLE的“内部申购”，如果是向其它公司的库存组织申请物料，则该采购申请PR可被自动导入订单管理OM系统，OM系统发货后循“发运网络”被接收，系统自动可在两公司间生成应收、应付会计信息。再如OM系统中的直接发运（Drop shipment）物料，系统可自动生成采购PR，客户收货后，一旦PO作接收，则OM系统自动作发货确认并生成AR发票等。
所谓“流程识别自动化”，ORACLE系统通过大量的“参数”设置（可设置的系统参数仅所谓“配置文件”就有七、八千之多），使得不同的物料、业务类别，在各模块间循不同的业务流程自动得到相应处理。这无疑使得单个用户在面对大业务量且流程复杂的情况下能够轻松应对，应付自如，获得高的生产率。
所谓“活动集成”主要是针对非核心业务或其它“事务”性工作领域，系统所能提供的“过程管理与控制”功能而言。这些领域的共同特点是，不象核心的“业务/财务”领域那样与“实物流”（价值增值）、“资金流”（价值实现）紧密相关。有很多人在学习ORACLE时，都曾会有一个疑问：新增物料、新增供应商、新增销售订单等等，系统的标准操作功能几乎都不考虑这些数据是怎么来的“过程”问题，而实际情况肯定不可能是这样的！为什么核心系统的有些单据界面感觉纯粹只是提供一个“最终结果”的录入功能？
原因在于ORACLE核心的业务/财务系统“以价值为中心”（物与资金都属价值）的应用架构设计，本来就不太擅长于处理“以关乎人或组织的行为活动信息为中心”的事务过程，鱼与熊掌不可兼得。故为了保证核心系统在数据与流程方面的高度集成性，必须对核心系统的“活动集成性”作适当取舍。为了弥补核心供应链业务系统的这一不足，ORACLE EBS系统另外还提供了诸多相关的非核心业务或事务领域的外围系统供用户选择使用。例如“新增物料”过程活动管理，EBS有“Product Information Manangement”产品可以提供支持等等
0.5.2 基于EBS的企业信息化战略规划框架
对于一个典型的供应链管理企业来说，其基于ORACLE EBS的信息化战略规划通常可能具有类似如图1‑8所示的系统组成框架。
图1‑8基于EBS的企业信息化规划系统组成框架
众多企业的信息化实践与正反两方面的经验表明，基于企业在“财务、业务、事务”领域，对于信息管理系统的“数据、流程、活动”集成方面的不同要求，任何厂商的ERP套件系统都不可能完全满足企业的所有管理需求。因此，从企业信息系统应用选型的角度来考察，通常又可能具有如图1‑9所示的系统选型组成结构。
图1‑9基于EBS的企业信息化规划系统选型组成结构
尽管对于不同企业信息化规划的“EBS系统+第三方系统+自建系统”的构成比例可能有所不同，但EBS的核心及外围系统的构成比重通常都会占最大部分（一般可能在70%左右）。相对于EBS核心系统，周边系统（自建、第三方或EBS外围）作为核心系统必不可少的补充组成部分，随着企业信息化建设水平的提高与应用层次的深入，尤其是在企业管理信息化从初级阶段向高级阶段进化的过程中，对于企业整体管理水平的提高，往往会发挥越来越大的重要作用。
在企业管理实践的核心“（供应链）业务+财务”领域，系统的“数据集成与流程集成”的重要性是怎么强调也不过分。在“财务”领域，系统的数据集成是重点，因为该领域流程本来就不是很复杂（这也是企业信息化往往先从实现财务信息化开始的原因）。而在核心“（供应链）业务”领域，系统的流程集成是重点，因为该领域业务环节多、流程长，涉及部门与人员众多，只有实现高度的流程集成才能达到高的生产率。ORACLE EBS产品之所以强大，正是首先在于其核心“（供应链）业务与财务”系统内部及系统相互之间的高度的数据集成性与流程集成性。
而针对“行为与活动”的事务过程管理，各行各业、不同企业的习惯做法或制度规定差异很大，客观上进行系统标准化的难度也很大。由于非核心的业务系统、事务管理系统，与核心的业务/财务系统在“数据与流程”两方面，集成性、紧密性的要求并不是太高。尽管ORACLE也在尽力鼓吹、游说企业只使用其同一家的所有产品，以达到应用系统高度的“活动集成性”，但很多企业还是乐于使用第三方产品或自己开发，原因就是完全使用一家的所有外围产品于实际的使用效果或管理效益，很多时候综合优势并不明显。
纵观国内ERP使用比较成功的企业，诸如联想、华为、中兴等，无不是以SAP或ORACLE的核心系统搭建自己的企业信息化平台，原因就在于外围系统（非核心系统、事务管理系统）可以策略性地使用第三方系统或自己开发，但“核心系统”基于数据与流程高度集成性的要求则往往别无选择。反过来，从产品研发的角度来看，核心系统也是不可能通过收购或集成第三方产品取得成功的，ORACLE过往所收购的补充性质的应用产品几乎全是外围或周边应用产品（同类产品收购看重的仅仅是市场份额）。
0.5.3 EBS核心业务系统实施的有关经验数据
最后，引用美国BOSS咨询顾问公司2001年时关于ORACLE EBS核心业务模块实施的难易程度的经验数据，供读者参考，其中假定总账GL系统的难度系数为100，其它都是相对数。
表1-1：EBS核心系统实施难易程度
注：1、难易程度相对于不同行业、不同企业以及不同业务背景的人来说有一定差别。
2、系统实施上线的难易程度与学习掌握的难易程度可能不尽相同。
0.6 结语
回顾ORACLE应用产品的发展历程，有两个值得重视的具有里程碑意义的重大事件：1993年决定基于C/S技术架构将过去的所有应用产品重写，并在当年发布R10版本；2000年基于B/S技术架构的EBS 11i版本的发布。前者为ORACLE真正打开了管理软件的市场之门，后者则为ORACLE最终奠定了在高端企业应用市场的江湖地位。有关ORACLE应用产品发展历程的详情请参考本书（下部）附录“ORACLE ERP的前世今生”。
在上述两个重大事件之中，表面看来技术因素（C/S、B/S架构）似乎是起着决定性作用，但如果我们将EBS在不同历史阶段的R10、R11、R12版本，从“系统应用架构与企业实践”的角度作横向考察与比较，我们或许能够发现，无论计算机及软件技术在过去二十年间的发展变化是如何巨大，但ORACLE产品规划设计与开发人员于早期阶段就融入软件的那些于企业核心业务运作所至关重要的管理思想、业务流程模式、功能应用层次结构等核心内容其实变化并不大，它们今天依然是支撑企业高效运作的核心与基础，并且它们也在随着时代的发展而与时俱进、不断得到充实与完善。
本章有关ORACLE EBS系统架构与应用实践的讨论，一个重要目的就是试图说明，所谓“高端ERP”其实并不在于其使用的技术有多么先进，对于广大EBS的学习与研究者来说，重要的是应当更多地关注其在系统应用架构层面，是如何将企业的具体管理实践融入到系统业务功能的设计之中的。不仅要学习相关系统功能是如何实现的，而且要研究系统为什么要这么设计。