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软件进化所遇到的困难，不是“出身”问题，而是“路径选择”问题。
企业的现实目标是赚钱、盈利，利润是企业存在的最初理由。对于一个典型的制造型企业而言，简单来说，它至少包括两个最基本的业务过程：其一是所谓“价值增值”过程，即买进原材料、进行加工生产出产品，再以更高的价值卖出去，这个过程通常属于“业务运营管理”范畴；其二是所谓“价值实现”过程，即从客户回收货款，向供应商支付购买材料的费用，再根据国家的会计法规，扣除相关费用如设备折旧等等，剩下的就是利润（或曰股东价值），这个过程通常属于“财务会计管理”范畴。
如果一个企业的“业务运营”与“财务会计”管理的核心过程能够实现信息化、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软件进化所遇到的困难，不是“出身”问题，而是“路径选择”问题。
2011-02-10
浏览5218
下载0