Oracle商业智能应用程序(第二部分)

成本

关于成本的争论一般是基于与软件和基础构建相关的高资金成本，以及实施中伴随的较少成本。商业智能应用程序状态面板的许可证要比空的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了。当然也需要其它额外的东西，但是获得的受益是它所带来的灵活性和能力。

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


Oracle商业智能应用程序(第一部分)