ORACLE EBS 系统架构与应用实践6072466354(2)

就企业广义的“财务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软件进化所遇到的困难，不是“出身”问题，而是“路径选择”问题。

四、ORACLE EBS的系统集成性

这里的所谓系统“集成性”，既非指“技术层面”的集成，也非指模块“应用层面”的集成，而是指企业管理发展过程中内在“核心要素”的集成。有人以为，一个ERP产品

所包含的模块数量足够多、企业上线的模块数量足够多，就意味着“集成性”高，这实际上是一种误解。

一个企业从小到大的发展壮大过程，在不同阶段企业管理所要关注的重点因素是不同的。我们常说企业大则有规模经济效益，但实际上企业规模愈大，相应的管理成本也在急剧上升，如果因规模扩大而获得的生产率的提高，不能超过或抵消因规模扩大而导致的管理成本的升高，则就是所谓的“做大但没有做强”。有些人抱怨国外产品（SAP/ORACLE）系统刻板、流程僵化，这实际上是不懂企业管理精髓的外行话。想想看，尽管我们经常取笑国外大公司做事拖拉、流程死板、官僚主义，是资本主义的“国企”，但实际上这些大公司的“生产率”（以人均营收或人均公司GDP计）常十倍于国内同行业。所以说，管理的标准化、流程化是企业发展的必然选择。

一个高度集成的应用产品系统要适应企业管理的发展需要，必须同时考虑以下三大核心要素：数据集成、流程集成、管理集成。但需注意的是，这三大核心要素对于前述企业三大管理领域“财务、业务、事务”的影响与侧重点是有所不同的。

所谓“数据集成”比较好理解，即通常所说的“消除信息孤岛”是也。它可以分为两个方面：“静态数据共享”与“动态数据传递”。“静态数据”主要指类似“物料、供应商、客户”等基础数据，由各模块调用共享；“动态数据”则主要指诸如“采购订单、制造工单、销售订单、发票”等随时间不断累积的业务数据，它们之间需要遵循一定规则进行数据传递。

相较于传统的手工业务模式，现代的计算机技术与数据库技术在解决企业管理“数据集成”方面易如反掌。在系统“静态数据共享”方面国内外产品差距不大，但在系统“动态数据传递”方面，由于有些国内主流产品采取的是“模仿手工单据”的实现方式，导致数据冗余，传递、同步非常困难，使用效果非常糟糕。

ORACLE产品在“数据集成”方面有一个突出的“亮点”是各模块几乎都有集成第三方系统的接口（API），其内部各模块之间的数据集成也基本上采取类似集成第三方系统的“松耦合”方式。有人将之认作是ORACLE比SAP灵活、易用的优点。这可能是与ORACLE产品早期还不完善时，不得不考虑所谓“最佳配置实施方案”有关（详情见“ORACLE ERP的前世今生”有关内容）。这也许可以说是ORACLE的“因祸得福”。

所谓“流程集成”也可以分为两个方面：“流程传递的自动化”与“流程识别的自动化”。ORACLE在其产品宣传中经常讲到一点“用户只需很少的干预与击键操作，其它都由系统自动替你完成”，说的正是这个意思。

所谓“流程传递的自动化”，例如ORACLE“内部申购”，如果是向其它公司的库存组织申请物料，则该采购申请PR被自动导入OM，OM发货后循发运网络被接收，系统自动在两公司间生成应收、应付。再如OM中的直接发运（Drop shipment）物料，系统自动生成PR，客户收货后，一旦PO作接收，则OM系统自动作发货确认并生成AR等。

所谓“流程识别自动化”，ORACLE系统通过大量的“参数”设置（SAP的参数设置有七、八千，ORACLE也不遑多让），使得不同的物料、业务类别，在各模块间循不同的业务流程自动得到相应处理。这无疑使得单个用户在面对大业务量且流程复杂的情况下能够轻松应对，应付自如，获得高的生产率。

参数多，设置复杂，令人生畏，实施困难，向来是SAP R/3产品早年开始就一直遭不少人诟病的地方。ORACLE的实际情况不比SAP好多少，但ORACLE产品作为后来者，在系统流程“参数”设计的层次性、使用的方便性方面，还是做了很多努力，相对而言可能要比SAP容易掌握一些。ORACLE在系统业务流程方面相较于SAP也做了一些简化，但这种“简化”往往是以牺牲某些不怎么常用或使用意义不大的“功能”为代价的。这或许正如有人评价的：SAP求严求全，ORACLE求实求用。现代企业管理的发展方向是追求企业管理的整体效益，要 …… 此处隐藏：2691字，全部文档内容请下载后查看。喜欢就下载吧 ……