SAP与ORACLE比较之技

慨述
SAP体现了德国人的管理风格：求精求全；ORACLE体现了美国人的管理风格：求简求易。
体系结构比较



mySAP.com 不是一个internet结构的应用套件，需要一个附加服务器，R/3仍然是产品的核心。

ORACLE的电子商务套件是100%的INTERNET结构。

SAP的整个产品线正在经历一个痛苦的从陈旧的客户/服务器架构向基于互联网的结构转变。直到一个真正的多层WEB结构实现前，mySAP 的功能将在可扩展性，集成和性能方面大大的受到牵制。
行业分析家们也指出SAP系统架构的局限性。Gartner这样评说说SAP的架构，“SAP的架构，虽然改进了WEB功能方面的友好性，仍然严重的依靠过时的客户/服务器模式。当销售ERP产品时，SAP会受到缺少弹性的架构的影响和挑战，因为客户将会把架构的模块化和开放性作为评价的标准，SAP独有封闭的结构不能很好的迎合ERP的基本，除非客户确信SAP可以单独提供所有的ERP功能和接口（用来支持ERP和协同商务的接口）”。
迁移到SAP mySAP产品带来额外的冗余和可靠性方面的问题。Lance Travis，AMR的分析师说，迁移到mySAP.com需要在服务器端增加30%到50%的空间，但仅仅是“复制原来所做的事情”，这可能带来几百到上千G的磁盘空间。
"SAP的互联网交易服务器 [ITS] 非常难以部署；我们很少听到有人成功过," AMR的Travis说. "大部分公司已经花了6个，9个或12个月的时间来部署，但从来没有正确的部署过。在正常启动和运转方面非常困难"他指出了配置的复杂性，还有ITS的可靠性，都是主要的障碍点。
Oracle的多层架构和模块化的功能保证了整个解决方案的优越性能，同时提供了高安全性。遵从开放的标准使得更加易于集成和拓展。
SAP基于WEB的客户端 (SAP GUI for HTML) 有着严重的性能和可用性方面的问题。SAP在将旧的客户/服务器界面转向WEB界面方面是不成功的。SAP的WEB界面速度慢，迫使客户大量的使用鼠标（对财务用户来说是一个很现实和严重的问题），使得用户很混乱，无法集中注意力—几乎没有SAP的用户使用这个基于WEB的客户端。
只有一部分SAP的业务（除了在SAP CRM 3.0里面的新产品）能通过WEB浏览器执行。
许多功能必须通过传统的客户/服务器界面。实际上SAP GUI for HTML 只是一个SAP客户服务器系统的HTML效仿外衣。
SAP GUI for HTML 是动态的将客户/服务器系统的数据转化为HTML和Javascript；这种处理需要大量的时间，导致了用户界面性能的低下。
SAP GUI for HTML 生成的HTML页面试图模仿客户服务器GUI的外表和感觉。这一点非常复杂，WEB浏览器花了大量的时间来生成他们。这个在降低性能方面更加严重。
没有快捷键，所以用户必须使用鼠标，甚至象打开一个值列表这样简单的业务。这会使用户非常劳累。
许多包含图形和流程的屏幕在 SAP GUI for HTML里面不支持。
Oracle的产品是完全基于WEB的，界面直观，容易在企业内部推广。SAP的难以使用和失败的WEB客户端，使得最终用户对SAP会形成负面影响，从而影响ERP实施的效果。
Oracle的基于WEB的客户端有着极好的性能，而且因为易于使用而备受称赞。ORACLE的界面是完全基于WEB的，所有用户都只需要一个浏览器。在INTERNET上，安全的通过HTTPS协议在标准端口80使用系统。
多数据模型

SAP 的mySAP.com有六套独立的系统:
R/3(传统系统)
APO（计划优化的产品）
CRM
商业智能
企业采购（Enterprise Buyer ）
门户（Portal ）


这个阻止了SAP提供实时分析,例如，“每日商务智能”。当信息从一个系统传输至另外一个系统的过程中，信息已变得过时。
SAP分割的数据模型基本上基于不同的技术，从而不能进行实时的分析，并且数据需要从一个系统拷贝到另外一个系统，容易导致信息失真。在SAP系统内，模块之间的集成是在程序层面上集成，而不是在数据层上集成。
Oracle存储所有的信息在一个单独全面的数据模型里面。这点保证了所有应用模块里面的信息是一致的，避免了信息的冗余或者失效。SAP通过并购试图建立一个完整的应用系统套件，从而有着多个数据模型。结果分割的数据源使得企业几乎不可能获得共享的信息，因为没有一个统一的“事实之源”。
无论从在一个系统里面成功实施的案例还是因此给客户带来的效益来看，ORACLE都证明了一套全面集成系统的重要性。在所有的ERP产品供应商中，ORACLE的这种架构是独一无二的。
在系统集成性上

就算在自己的系统模块之间，SAP也是在应用层次上集成，而不是在数据层次上集成。这意味着大量信息对象有多个版本，存放在不同的系统里面(e.g. HR 的工作中心和后勤里面的工作中心是重复的).因为不能提供一个版本的“事实真相”，这会导致数据不一致的问题。
至于和外部系统的集成，SAP通过和webMethods组成合作伙伴关系来支持XML（在Business Connector），而不是重新改写程序来满足互联网的存取和集成。然而，这不是一个好的方法。正如Gartner所说：“Business Connector支持XML的文档和SAP软件集成；然而，可以看出SAP的基石仍然建立在超过两千个BAPI和ALE技术上，Business Connector置于它们之上然后把XML的内容转换为BAPI。SAP说这样可以行得通，但是，整体性能却比纯粹的BAPI要慢。” SAP最近发布的WEB服务不成熟，并且需要更多的时间变得可靠。
在实际中，SAP的用户仍然主要依赖BAPI。虽然有成百个合作伙伴使用它们，但关键问题是合作伙伴们是否愿意。首先，SAP的BAPI不完整并且不易扩展，许多重要的业务对象没有包括近来。并且许多BAPI功能有限（例如，没有创建一个新员工的BAPI）。基于这些功能限制，许多客户被迫拷贝BAPI然后修改它们以满足公司需要。
还有，BAPI是用ABAP编写的，ABAP是一个SAP独有的技术。SAP提供“Connectors”允许应用系统通过一些指定的技术调用BAPI，如微软的COM或JAVA。但是如果一些第三方的产品或传统系统不是基于BAPI支持的技术，那么用户就要用缓慢笨拙的批导入方式来解决集成问题。
Oracle电子商务套件所有子系统内各模块的集成完全没有问题。不象SAP，所有ORACLE的系统都是在相同的架构上开发的，使用同一个数据库。
在和第三方产品的集成方面，ORACLE提供一整套完整的API：
为系统内每一个业务对象的业务视图提供了一个稳定、可扩展和容易使用的机制，用于从其他系统取得数据。
开放的接口和导入工具提供了理想的方式来处理大量数据的插入、更新或删除业务对象（以一种异步的形式）。
PL/SQL API 提供了一种实时的方法，完整处理一个业务对象的单个环境。
所有的集成不需要任何客户化和维护后端的不同版本兼性，保证了集成投资的一致性。Oracle的APIs 是建立在数据库服务器一层，很容易从其他系统存取数据，只要其他系统支持和关系型数据库的连接。这意味着客户可以选择众多的集成技术。
Oracle的新9i 应用服务器 (Oracle9iAS) 提供了新的，内置的集成能力，包括业务流程管理，EAI和B2B集成。Oracle9iAS提供给客户一个标准的集成点和优秀的多方面集成解决方案，使得公司能够虚拟的和任何应用系统、领先B2B的沟通标准和涌现出来的WEB服务标准集成。
Oracle优秀的、经过考验的集成技术被大量的公司用来和SAP的系统集成。
在软件的开发性上

软件业一个主流的趋势是由封闭系统向开放系统转变。封闭的硬件和软件在扩展性、总体拥有成本和可支持能力方面都非常不利。实际上SAP的基本技术仍然是用ABAP（一个SAP独有的开发技术，可追溯到70年代），表明SAP错过了过去十年的主流开发技术。SAP已经开始意识到这一点，采取了一些紧急措施来追上时代。
甚至在新的产品里面，例如CRM 3.0、 业务仓库和企业采购员，都是采用了混合的技术。CRM 3.0, 是一个ABAP在应用层的混合，在展示层是SAP称为业务服务页 （Business Server Pages ，BSP），BSP是一个独有的，发展自JSP，用来与ABAP组件交互。
Giga公司说: "虽然SAP声明‘无上的开放集成', SAP CRM产品仍然基于R/3平台………并且当SAP重新用JSP开发最终用户界面时，导致SAP CRM有三种不同的开发环境-传统的ABAP，J2EE和开发现场销售和服务系统的VB"。
提到SAP最近J2EE和JAVA的发布，容易让人误解，因为这个发布没有构成一个产品。在Gartner的技术摘要里面提出：“这些在2002年晚期和2003年早期的计划集成项目必须评价发布的产品，但是必须和现有的方案比较功能和成熟度（ “those planning integration projects in late 2002 and early 2003 should evaluate the announced products but should compare their features and maturity with established solutions”） ，Gartner 清楚的意识到这些技术仍处于幼儿期，需要大量的开发工作。
Giga 同时说：“SAP的mySAP HR产品是基于复杂、特有的R/3架构。更多的应用系统逻辑是用独有的ABAP写的，需要一个非常有经验和技巧的专家来维护或修改程序代码。SAP通过使用J2EE正在进化到更加模块化和开发的结构。但这些改革花了几年的时间，对HRMS的产品只有很有限的影响。”
在另外一个报告里面，Gartner说， “缺少JAVA的支持，限制了SAP提供互联集成的能力，在ERP II战略方面。目前，4.6不支持Java Database Connectivity (JDBC), Enterprise JavaBeans (EJBs), Java Server Pages (JSPs) 和其他的JAVA开放标准。然而，在2001年11月，SAP发布了计划中的J2EE支持，提供一个一个开放的选择给 ABA) 环境和BAPIs。J2EE直到2002年中期仍然不会出现，然而，后续的逐步采用可能花费的时间更长。“
比较而言，ORACLE的电子商务套件完全是使用开放的标准技术开发的，无论在服务器层还是在中间层。ORACLE的开发工具是商品化的工具，并且独立于电子商务套件之外，有着广泛的工程师基础。这个使得ORACLE的客户可以从数百万的工程师当中轻易的找到自己需要的技巧。
Oracle 9iAS， Oracle已经发布的一个世界级应用服务器，被市场许多用户认为比任何一个应用服务器都好。 Oracle 9iAS有着强大成熟的J2EE，JAVA和WEB服务支持能力。Oracle 9iAS是ORACLE数年开发的结晶。比较而言，SAP在这方面的努力非常小，几乎没有什么经过证明的价值。


开发工具的比较



SAP独有的开发代码 (ABAP/4)-不易于扩展，大多数在德国开发，代码、表用德文注释。

专用的，复杂的，基于德语使用习惯的开发工具。
没有第三方厂家的应用软件产品是用ABAP工具开发的，没有非SAP用户使用ABAP。
资料表明，近年来开发人员的雇佣成本增长率突破了25%，导致许多公司到学校去雇请还未毕业的学生以减低成本。
近年来，SAP有越来越多的模块采用非ABAP语言开发。例如销售配置管理模块—Sales Configurator）用C和C++开发，给R/3新老产品集成带来了一些新的问题。
ORACLE则为开放的代码和通用的开发工具。

开放, 稳固性和易理解。
针对企业建模和开发需求的市场领先产品。
超过50万个有资质证书的开发员开发正在使用Developer。
应用产品是用Oracle Developer、Designer等数种ORACLE 数据库的专用开发工具开发的,配合各种先进的报表开发工具，开发的产品运行在业界性能最优ORACLE数据库平台上，将ORACLE数据库内核技术的精华发挥至极限，在运行性能和速度上都领先于SAP R/3产品。


在产品线的完整上
ORACLE提供从核心关系数据库（RDBMS）、系统开发工具、应用级软件产品，适用于中层人员的分析支持工具（OLAP，OSA，OFA），为领导提供商业智能系统（BIS）。
Oracle的客户关系管理系统（CRM）、电子商务（E—Business）、专业的设备管理（MRO）解决方案等等，利用ICA 和Web Customers, Web Employees, 及 Web Suppliers等软件, Oracle 是唯一提供此类技术产品的供应商，也满足不同的客户要求。
SAP仅有应用级软件产品和专用的ABAP4开发工具。业务框架结构部分由第三方厂家开发， 这种结构的概念是为基于推广R/3产品和第三方软件产品的协作性而提出的。


软件实施成本和复杂性上比较

SAP的成本和复杂已经是众所周知，SAP自己也承认产品很难实施。
SAP 天生就受到独有的语言和界面的限制，使得客户化和扩展很难。SAP采用标准的努力刚刚开始，还要数年才能成熟。这意味着一个现在的客户想要扩展和客户化系统（几乎所有的SAP客户都要大量的客户化），他们必须雇佣昂贵、难找和非常精通SAP技术的专业人员。
就象上面提到一样，SAP的结构非常复杂，SAP提倡一个由不同子系统组成的架构，每个都有着不同的数据模型。
这些系统通常需要在单独的服务器里面上安装。这个迫使客户分裂了系统功能，导致：
分割的数据模型。
不准确的数据：例如，一张销售订单如果在CRM系统里面输入，ERP系统不能马上得到更新。
需要高的系统性能：所有的系统需要客户采购和管理不同的机器，增加了运营成本。
Gartner报告指出SAP在过去两年结构转型的努力只是使得更加复杂：“SAP的用户发现SAP正成为一个更复杂的公司，产品线更复杂，使得用户的SAP战略计划和实施都更加困难”。
SAP的应用产品特色是大量的预先设置好的配置，需要复杂的规则和关系，难以维护和使用。客户化在依赖于结构的系统方面显得特别困难，象总帐和人力资源。在薪资方面也是一样。
总的来说，正如Gartner 所说：“SAP的实施高成本，并且时间长。SAP实施的成本基本上是初始6到10倍许可证费用。需要12到24个月实施完成。”
相比较而言，ORACLE开发的产品功能允许广泛的客户化，不需要写代码，并且开放的结构允许ORACLE的应用系统和众多的系统可以集成。ORACLE有着一个统一的架构使得客户可以在一个平台里面实施需要的功能模块，大大减少实施的复杂性。ORACLE有着许多参考客户都成功的实施了ORACLE的产品，并且在减少拥有成本方面取得了巨大的成功。


从方便使用的角度来看，ORACLE的产品本质上容易设置、使用和维护。简单来说，ORACLE的应用系统只要经过简单特定的步骤设置。ORACLE的业务用户不需要了解表之间的关系、程序和配置步骤来调用业务功能。他们简单的使用系统，管理业务，并从系统方便地获取管理信息。
例如，ORACLE的权限能够简单的设置并且由一般用户维护。另外，工作流是嵌入在应用产品里面，好过由程序员开发或维护。ORACLE也提供附带文件的能力，通过点击按钮即可，而不用复杂和耗时的配置，ORACLE的用户马上就知道有个附件。


ORACLE的其它优势



Oracle的应用系统提供大量的弹性和可扩展性。
Oracle 提供给客户桌面集成器（ Application Desktop Integrator，ADI）, 允许用户集成非ERP系统，例如EXCEL，直接到ORACLE的应用系统（总帐，预算和固定资产）。ADI允许一个最终用户简单导入总帐、预算或者转换主数据和期初数据。SAP没有类似ADI的产品或工具。
Oracle 也提供描述弹性域在所有的应用产品内。ORACLE描述弹性域可以在任何屏幕上简单的定义任何字段，而不用任何写程序工作。所以他们能够被跟踪和报表统计。用户可以使用描述弹性域来简单的跟踪任何额外的信息，而不用修改ORACLE的应用产品，只要五分钟就够了。在SAP里面，用户搜索需要通过可用的字段，尽量希望找到一个字段或标签来满足需要。
Oracle也提供一些用户定义的段，例如会计科目表 。没有任何使用段的限制，因此也没有报表的限制。用户定义的段和会计科目表存放在一个表中，从而修改只需在一个地方。另外，设置时任何一个段可以能够用做报表的维度，并且可以和其他段结合使用。
对比而言，SAP有着一个刚性的会计科目表，用户必须在一个模块内定义可用字段（公司，业务范围和科目）的值，而在另外一个模块定义成本中心和费用信息，同样另外一个模块定义预算数据。难以维护不同模块之间的对照关系，当向最终用户解释之间的关系时候，他们往往要被复杂的逻辑和流程所击倒。
Oracle的电子商务套件超越了SAP，通过在主要的业务流程里面支持工作流，包括采购到伏款，定单到现金和产品设计。用户能够简单的裁剪系统来满足他们的需要，通过简单拓展工作流的流程，不需要编程，只要使用简单拖和拉的界面。虽然SAP提供工作流技术，但是很少的业务流程支持工作流的。
最后，ORACLE提供调整搜索屏幕的能力通过使用文件夹工具来满足个人的参数设置，移动屏幕上的列，简单调用查询，排序数据，导出到EXCEL。

原文：http://erptruth.blog.ccidnet.com/blog-htm-itemid-178361-do-showone-type-blog-uid-42967.html

术篇