OBI EE(Siebel Analytics)是一个强大的企业级商业智能/报表/分析工具，它快速地占据市场份额和认可。尽管Siebel的Oracle市场份额所占甚低(而且可能会变得更低)，但是它是个纯粹的显示平台。他们的确是希望能够卖给你，但是这不是他们所关注的。
如果是这样的话，那么他们关注的是什么呢?答案是商业智能应用程序。
无论你是否相信，商业智能应用程序是数据仓库和商业智能的未来。就像过去中型和大型企业采用大型ERP、CRM、Billing 和人力资源应用程序一样，他们也将采用商业智能应用程序。Siebel 是第一批宣扬这个信息的人之一，而现在Oracle 也宣扬这个思想，尽管范围要大得多、并具有更大的进展以及更广泛的市场资源。
这个由两部分组成的文章将一般性地介绍商业智能应用程序，但主要关注于Oracle 商业智能应用程序。它将介绍为什么和是什么、以及预先建立数据仓库和商业智能系统的支持与反对信息。
什么是商业智能应用程序?
一般意义上来说，它是一个完全预先建立的商业智能和数据仓库系统。它涉及ETL、一个数据模型、一个技术平台、元数据和预先建立的分析和报表。下载这个软件和应用程序配置文件，安装、加载数据，然后你就可以开始了，在某些方面它的确就是这么简单。
一个完全的商业智能应用程序，例如Oracle的商业智能应用程序，包含由工程师团队(不只是技术专家，还有行业和功能型专家)专业完成的一切事情。一个基础的商业智能应用程序不仅仅是“行业标准数据模型”，还包含了所有必要的ETL、数据模型、商业智能工具元数据以及预先建立的报表内容。一些可能还包括了改变数据捕获或与其它使用集成，例如前端应用程序、门户、高级数据服务或甚至是其它的商业智能工具。
在Oracle 的应用程序世界中，有一些名称容易让人产生混淆。Oracle 目前销售三个不同的OBI EE基础应用程序;其中两个叫做融合智能(一个是用于Oracle EBS和DBI，另一个是用于PeopleSoft和JD Edwards)。注意这些应用程序不是真正的Oracle 发展方向的一部分，所以不会被积极地关注。相反Oracle 关注于它的商业智能重要产品，它的名字就叫做商业智能应用程序。这些商业智能应用程序包括近50个模块，这些应用程序包括Marketing Analytics、Partner Analytics、Service Analytics和Sales Analytics 等等。
为什么创建商业智能应用程序?
答案与为什么我们现在拥有ERP系统是一样的。SAP、PeopleSoft、Oracle EBS、Baan、Siebel、Clarify等等都是以同样的思想建立的：一个客户可以购买一个功能完全的系统而不是要承受他们自己建立的风险、成本和延误。它只是首先从前端系统开始。现在在财富前2000家企业中大多数企业都有一个或几个的ERP系统，使得他们具有了预先建立商业智能系统的能力。因为在公司里具有定义清晰的数据模型，这些公司就成本高效地获得了预先建立的ETL，而有了预先建立的ETL，就有望从商业智能应用程序获得巨大的受益。
为什么你应该考虑Oracle 预先建立商业智能应用程序?
如果你正在读这篇文章，那么你至少对Oracle商业智能的东西有些兴趣，特别是OBI EE。如果你有一个或多个支持的源ERP包(Oracle EBS、JD Edwards、PeopleSoft、Siebel、SAP和呼叫中心转换数据)，那么Oracle的商业智能应用程序将引起你更大的兴趣。
Oracle的商业智能应用程序能够带来许多好处，但是许多的好处：例如UI集成、安全集成和类似的方面，都归结为同一个事情：它们节省了你的力气。商业智能应用程序所提供的每样东西都可通过使用基础技术平台做到了这点，这意味着你将可以自己来做。不同之处是Oracle 工程为你做了大量的工作。
但是我们实际上正在讨论什么呢?是讨论一个大型数据仓库和商业智能系统所需要的一切，从开始到结束。商业智能应用程序所带来的真实受益是这已经完全地或大部分建立的许多组件和任务不需要或只需要你很少的工作量。这些包括：
需求分析
命名标准
源系统分析
改变数据捕捉设计
提取、转换和加载的设计和编程
ETL编制/架构基础(顺序、记录跟踪、重启、索引管理)
到不支持的数据源的一般集成
强大的目标维度数据模型
商业智能工具和配置元数据
报表和状态面板
警告/发布/ iBots
实时集成
测试
部署打包
作为回报，你将受益于更多的功能或更好的质量使得你自己就可以重新制作：
功能性和行业专家以及行业最佳实践方法带来了功能，从评测标准到状态面板。
UI与源应用程序的简单集成——使得商业智能可以作为一个对象内嵌到你的ERP系统中。
从架构和设计的行业领先专家那里获得受益。
从覆盖了众多用户和平台的各种部署的大量测试和验证过程中获得受益。
设计成为完全可升级以具有新特性、数据集和技术
应用程序技术支持组
可以使用与商业智能应用程序一起使用的相关资源
预先建立第三方集成
这些中的许多项，可能你认为你的数据仓库/商业智能部署是不需要的。当你开始计划一个新的数据仓库或数据智能时，就将需要考虑这些任务了，以便制造一个功能完全的系统。
一个普通的例子是ETL Orchestration。ETL不仅仅是计划一系列源到目标的匹配的。必要的项目例如过程依赖检查、多个时间表协调(例如每日和每周ETL)、重启一个失败进程、并行、改变数据捕获，以及与索引管理集成，这些都是你需要设计、建立、测试和确定怎样监控和管理的事情。有了预先建立商业智能应用程序，这个工作就已经为你做好了。
它们中的每一个任务都需要耗费大量的时间。每一个任务都伴随着很大的风险。这个风险很大程度上取决于你团队在各个领域的能力和经验级别，而且你将开始看到为什么有许多商业智能/数据仓库项目失败，在一小会之后中止，花费的时间比预计的要长得多，或消耗成本比预计的多得多。
购买Vs.开发
这个决策是一个典型的开发vs购买。如果你有一个ERP系统，那么你至少已经有一次是站在了开发的那一边。为什么购买而不是以PowerBuilder、ColdFusion、NET或Java来定制开发它呢?支持购买的一方具有下列众多主要的论点：
部署需要更少的时间&工作量
降低了风险，导致了工作时间减少以及更好的质量
更快的ROI
可升级能力
应用程序支持
与应用程序类似的技术资源可用性
你很难实现的高级特性
由一个强大的工程师团队来开发和测试
这些受益都应用于商业智能应用程序，尽管它们的重要等级不一样。正如你可能已经知道的，数据仓库和商业智能需要的技术集与传统应用程序开发很不一样，并通常需要很多年的实践才能成熟。除了对商业智能活ETL工具的熟练要求，复杂的架构和设计挑战是真正困难的地方。这些挑战发生的地方正是你要应用你最强大资源的地方。当购买一个应用程序时，这些困难的挑战已经被解决了并被彻底的测试和调整了。
购买决策的两个最突出的好处是降低了时间和工作量，还有降低了风险。
安装、调整你的ERP定制、加载数据、制作新的报表，这些你将在几星期之内完成而不是几个月。如果你在开发你的ERP，那么不进行分析、总结和倾向功能的部署可能不是一个好的选择。你能够在部署ERP之后快速实现这样的功能的唯一现实方式是使用商业智能应用程序。
为了降低风险，大量的工作都已经完成了，并进行了彻底的测试和调整。因此，部署商业智能应用程序的风险非常小。
商业智能应用程序的一个很好的地方是它所带来的一切东西不仅仅是简单的在一个商业智能工具中从源匹配到目标。如同上面所描述的，即使你只需要商业智能应用程序的一小部分，你的架构和基础构建也是工业极强度的。这使得你在之后可以很容易地增添新模块和功能，而不必重新进行构建基础组件和过程。
第一部分着重于商业智能应用程序所带来的好处，第二部分将关注于对商业智能应用程序的一些误解和不赞同信息。
在第一部分中，我们讨论了什么是商业智能应用程序以及为什么需要它。在第二部分中，我们将更多地专注于你与商业智能应用程序的一些密切关系。
普遍的误解
在开始介绍购买决策的一些反对意见之前，我想讨论一些普遍的误解。
它只作用于预先建立的数据源：
Oracle商业智能应用程序完全设计为用比一个开发场景中少得多的工作量就可以添加新的数据源到商业智能应用程序。使用一个发布——订阅模型，数据可以从任何与商业智能应用程序中的已有对象相匹配的源应用程序中提取。在提取之后，一个叫做Universal Adapters 的特性会使用这个数据并继续转换和加载它到目标商业应用程序中去。
我会受限于我所购买的应用程序：
商业智能应用程序是建立在一个百分百开放的平台上的;没有不能扩展的东西。你是否对与你所购买的商业智能应用程序没有关系的一些数据具有报表需求呢?那么只要像你一般所做的——简单的开发这些映射，并将它们插入到强大的基础构建中作为另一个工作流。
这里关键的地方是他们不会以任何方式或形式将你束缚于你所购买的代码。实际上，你可以购买一个商业智能应用程序，删除所有的商业智能应用程序特殊代码，并使用这个平台和基础构建来建立一个百分百定制的数据仓库。这产生了重复工作：你可以将这个平台简单地作为一个预先建立的基础构建并做任何你想对它做的(假设你有正确的许可证)。如同在第一部分中所说的，在建立一个新的数据仓库时，通常会忽略ETL基础构建。
实际上，大多数商业智能应用程序部署从其它的来源带来了其它数据，例如其它的一些ERP、外部数据、电子数据表、或定制开发的内部应用程序。如果复杂性是第一关注的焦点，那么你完全可以将商业智能应用程序看作是一个着手点，而最终方向是由非商业智能应用程序内容和需求所决定的。
应用程序供应商的商业智能应用程序是轻量级的：
这对于许多商业智能应用程序来说确实如此。事实上Oracle在它的商业智能应用程序7.9出现之前它自己所提供的就是如此。但是，现在Oracle所提供的商业智能应用程序远远超出轻量级范围。这些应用程序是使用行业最佳方法建立在范围和数据库可以处理的一样广泛的关系型平台上的。
不像从其它供应商那里拿来的预先打包的商业智能应用程序那样，Oracle 使用了与你一开始想使用的相同设计技术、工具和平台。如果你对于关系型数据库、维度模型和Informatica感觉很好，那么你也会觉得商业应用程序很好的。对于这些工具你想自己在一个开发环境中所做的一切事情你都可以对购买的Oracle商业智能应用程序去做。此外，Oracle 添加了Informatica所没有的一些功能，叫做ETL Orchestration(以数据仓库管理控制台——“DAC”的形式)。
有一个复杂的例子，如果必要的话你可以构建到你的商业智能应用程序系统中去，就是例如一个跨国公司有两个不同类型的ERP，每一个都放在世界各地的6个数据中心里。此外，在各地较小的应用程序中有更多的客户数据。这所有的12个ERP实例需要顺利地集成到一个数据仓库中，还要克服潜在的数据问题，例如在不只一个的ERP上数据随机显示，在ERP间链接记录，以及一个复杂的安全模型。实际场景是对商业智能应用程序进行适当的扩展和定制以处理更多的逻辑。许多用户需求是和预先开发的代码和配置非常不同的，但是商业智能应用程序可以调整以处理非常复杂的需求。
对于商业智能应用程序的复杂性，关于关系OLAP vs 多维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可以做到，那么商业智能应用程序也可以。如果你需要在后台建立它，那么可以使用包含在商业智能应用程序中的工具来做到这点。特殊情况的解决方案例如名称和地址过滤可以集成到整个加载过程中去以扩展功能。
商业智能应用程序vs EDW
继续刚才的思路，想一下如果一个公司的一个或多个Oracle ERP继续发展，那会发生什么，增添新的模块、产生不要了的历史系统。最终，可能在你的ERP里有了大量的操作数据。
那么这时一个集中的企业数据仓库(EDW)和商业智能应用程序中的数据仓库(叫做商业分析数据仓库，或BAW)间的区别是什么?这时它们所能做的就非常类似了，因为它们都有从ERP获得的原子级数据。一个EDW可能具有其它添进来的数据源，使得它的覆盖面比BAW广泛。但是等下，这些数据源也可以添加到BAW。
如果确实如此，那么EDW和商业智能应用程序数据仓库就没有区别了。BAW可以成为EDW吗?如果这样，那么就不需要一个集中EDW了，但是更重要的，就不需要开发它了。实际上，可以购买一个EDW。
尽管对于大多数客户来说这只是拓展，因为他们只有一部分数据是在他们的ERP中的。然而许多中等规模的公司发展得非常快速以至于他们没有一个EDW，或顶多有一个较差的。考虑到要转移到Oracle 的ERP系统，他们就有机会通过购买商业智能应用程序来获得一个预先建立的EDW了。当然也需要其它额外的东西，但是获得的受益是它所带来的灵活性和能力。
尽管这对于一些人来说听起来很荒谬，但是它确实可以并将发生于一些客户身上。如同在几年前，没有人会想到打包的应用程序会支配这个世界一样，对预先建立的标准化商业智能系统也应该抱持相同的想法。