在第一部分中我们讨论了什么是商业智能应用程序以及为什么需要它。在第二部分中，我们将更多地专注于我们与商业智能应用程序的一些密切关系。

　　普遍的误解

　　在开始介绍购买决策的一些反对意见之前，我想讨论一些普遍的误解。

　　它只作用于预先建立的数据源：

　　Oracle商业智能应用程序完全设计为用比一个开发场景中少得多的工作量就可以添加新的数据源到商业智能应用程序。使用一个发布——订阅模型，数据可以从任何与商业智能应用程序中的已有对象相匹配的源应用程序中提取。在提取之后，一个叫做Universal Adapters 的特性会使用这个数据并继续转换和加载它到目标商业应用程序中去。

　　我会受限于我所购买的应用程序：

　　商业智能应用程序是建立在一个百分百开放的平台上的;没有不能扩展的东西。你是否对与你所购买的商业智能应用程序没有关系的一些数据具有报表需求呢?那么只要像你一般所做的——简单的开发这些映射，并将它们插入到强大的基础构建中作为另一个工作流程。

　　这里关键的地方是他们不会以任何方式或形式将你束缚于你所购买的代码。实际上，你可以购买一个商业智能应用程序，删除所有的商业智能应用程序特殊代码，并使用这个平台和基础构建来建立一个百分百定制的数据仓库。这产生了重复工作：你可以将这个平台简单地作为一个预先建立的基础构建并做任何你想对它做的(假设你有正确的许可证)。如同在第一部分中所说的，在建立一个新的数据仓库时，通常会忽略ETL基础构建。

　　实际上，大多数商业智能应用程序部署从其它的来源带来了其它数据，例如其它的一些ERP、外部数据、电子数据表、或定制开发的内部应用程序。如果复杂性是第一关注的焦点，那么你完全可以将商业智能应用程序看作是一个着手点，而最终方向是由非商业智能应用程序内容和需求所决定的。

　　应用程序供应商的商业智能应用程序是轻量级的：

　　这对于许多商业智能应用程序来说确实如此。事实上Oracle在它的商业智能应用程序7.9出现之前它自己所提供的就是如此。但是，现在Oracle所提供的商业智能应用程序远远超出轻量级范围。这些应用程序是使用行业最佳方法建立在范围和数据库可以处理的一样广泛的关系型平台上的。

　　不像从其它供应商那里拿来的预先打包的商业智能应用程序那样，Oracle使用了与你一开始想使用的相同设计技术、工具和平台。如果你对于关系型数据库、维度模型和Informatica感觉很好，那么你也会觉得商业应用程序很好的。对于这些工具你想自己在一个开发环境中所做的一切事情你都可以对购买的Oracle商业智能应用程序去做。此外，Oracle添加了Informatica所没有的一些功能，叫做ETL Orchestration(以数据仓库管理控制台——“DAC”的形式)。

　　有一个复杂的例子，如果必要的话你可以构建到你的商业智能应用程序系统中去，就是例如一个跨国公司有两个不同类型的ERP，每一个都放在世界各地的6个数据中心里。此外，在各地较小的应用程序中有更多的客户数据。这所有的12个ERP实例需要顺利地集成到一个数据仓库中，还要克服潜在的数据问题，例如在不只一个的ERP上数据随机显示，在ERP间链接记录，以及一个复杂的安全模型。实际场景是对商业智能应用程序进行适当的扩展和定制以处理更多的逻辑。许多用户需求是和预先开发的代码和配置非常不同的，但是商业智能应用程序可以调整以处理非常复杂的需求。

　　对于商业智能应用程序的复杂性，关于关系OLAP和多维OLAP(立方体)有一点需要讨论。要以对商业智能应用程序添加新的维度以进行度量分析，只要对现有的可以处理许多丰富维度的事实表添加一个新的维度就可以了。基于立方体的系统一般不以这种方式操作;对你在一个立方体确定下来之前能够添加到它其中的维度属性是有限制的，而且要删除一些其它的东西。企业级ROLAP引擎就不像OBI EE。

　　最后，有了OBI EE的功能，OBI应用程序受到了广泛的关注。当CRM宣布客户的360度查看时，这个咒语再次在商业智能应用程序上开始实现了。360度查看意味着深度和广度，而且在OBI EE平台上具有广泛和深入的分析功能，并在商业智能应用程序中获得了利用。实际上，这使得可以对各种不同的度量进行分析，每一个都是从不同的源获得，而且同时对不同的过程进行分析。这是在商业智能应用程序中严重缺少的能力，因为技术平台的限制或他们的应用程序弱点所造成的。此外，OBI EE平台的这个能力是这篇文章存在的原因。

　　反对意见

　　无论什么决定，都会有反对意见的，特别是在现实世界中。

　　与购买决策相关的最大和最普遍的反对意见是成本、对你特定的商业需求的适用性，以及满足未来购买功能之外的需求的灵活性。

　　成本

　　关于成本的争论一般是基于与软件和基础构建相关的高资金成本，以及实施中伴随的较少成本。商业智能应用程序状态面板的许可证要比空的Oracle状态面板的基本许可证贵得多。但是这当然是苹果与苹果派的对比;一个是未加工的原材料而另一个是完成的产品。

　　为了更好地比较，可以考虑下如果建立一个比不上它的、在功能、灵活性、丰富的特性和可扩展性方面都稍逊一筹但可以满足你实际需求的系统的实际成本。不要忘了添加你需要的基础构建组件。这里不适合使用那个苹果比喻，但是可以比喻为一个房子vs原材料和工具。如果你要自己建一个房子，那么它会和专家盖的一样好吗?它会拥有那些建筑公司和建筑师会加入进去的所有特性、高级材料以及高级工程吗?不可能的。所以即使将你自己盖的房子和预先盖的房子做比较不是一个很公平的比较，但是如果你采取购买决策那么你确实会得到一个更好的房子。

　　在大多数情况下，当你添加任何东西的时候，你会发现商业智能应用程序和相关许可证的成本远远低于你自己建立这些东西所花费的成本。当你花费劳动成本来定制基于你特定环境和需求的应用程序时，这个应用程序只改变一点点。而且，你自己开发的应用程序缺少的功能会耽误时间以及它的不可扩展架构造成的困难都会使得成本增加。

　　解决你现在和未来需求的能力

　　很显然，每一个商业智能/数据仓库需求都有很大不同，即便是在同一家公司。然而，当讨论你的ERP的分析能力时，可能性的范围就大大降低了。你的需求与OOB商业智能应用程序的不同主要在三个方面：

　　你的ERP很大程度上是定制的：如果确实如此，那么OOB商业智能应用程序是非常有益的，即便你需要对它们做相应的修改。基础构建仍然可以使用，而且事实上，在开发你的商业智能应用程序过程中，你的大多数数据对象不需要修改或稍稍修改一下，需要少量或根本不需要定制。

　　你的报表和分析要求是不同的：这会导致什么?商业智能应用程序在事务级别通过一个事务传送数据对象，以便所有适当的信息都在商业智能应用程序数据仓库中可用。因为这个数据将被提取，可以对它进行调整以改变它的结构来支持一组不同的分析需求而不必花很大的力气。在预先建立的报表和状态面板之间的任何隔阂都可以以最小的代价快速地解决。事实上，许多执行根本就不使用预先建立的报表和状态面板;而是在已经利用的很大一部分数据堆栈之上创建他们自己定制的内容。改变报表内容，与这个项目其它更花费力气的部分相比，就像是给房子重新刷上另一种颜色一样。

　　额外的数据或复杂的度量：如果你的许多需求是来自于预先建立的ERP映射之外的，那么你将需要决定它们是否映射到商业智能应用程序中已有的相同对象(例如，客户、雇员、订单、合作商，等等)。如果是这样，那么你可以使用Universal Adapters功能并利用现有基础构建的95%。如果不是，而且是有很大一部分不是，那么可能这个受益不是这么大。但是，不要忽略整个商业智能应用程序包所带来的基础构建组件。复杂的度量通常是用一个结合或ERP与非ERP数据创建的，并可以插入到现有的大型数据模型中。

　　总之，如果OBI EE可以做到，那么商业智能应用程序也可以。如果你需要在后台建立它，那么可以使用包含在商业智能应用程序中的工具来做到这点。特殊情况的解决方案例如名称和地址过滤可以集成到整个加载过程中去以扩展功能。

　　商业智能应用程序和EDW

　　继续刚才的思路，想一下如果一个公司的一个或多个Oracle ERP继续发展，那会发生什么，增添新的模块、产生不要了的历史系统。最终，可能在你的ERP里有了大量的操作数据。

　　那么这时一个集中的企业数据仓库(EDW)和商业智能应用程序中的数据仓库(叫做商业分析数据仓库，或BAW)间的区别是什么?这时它们所能做的就非常类似了，因为它们都有从ERP获得的原子级数据。一个EDW可能具有其它添进来的数据源，使得它的覆盖面比BAW广泛。但是等下，这些数据源也可以添加到BAW。

　　如果确实如此，那么EDW和商业智能应用程序数据仓库就没有区别了。BAW可以成为EDW吗?如果这样，那么就不需要一个集中EDW了，但是更重要的，就不需要开发它了。实际上，可以购买一个EDW。

　　尽管对于大多数客户来说这只是拓展，因为他们只有一部分数据是在他们的ERP中的。然而许多中等规模的公司发展得非常快速以至于他们没有一个EDW，或顶多有一个较差的。考虑到要转移到Oracle 的ERP系统，他们就有机会通过购买商业智能应用程序来获得一个预先建立的EDW了。当然也需要其它额外的东西，但是获得的受益是它所带来的灵活性和能力。

　　尽管这对于一些人来说听起来很荒谬，但是它确实可以并将发生于一些客户身上。如同在几年前，没有人会想到打包的应用程序会支配这个世界一样，对预先建立的标准化商业智能系统也应该抱持相同的想法。