BI项目如何规避常见困难？

项目范畴制定和管理

很多人会自然地把这个步骤理解为用户需求的收集和制定。其实用户需求只是这个过程中的一个手段和结果。不管是自主开发，还是集成商为商业用户开放的项目，最终目的都是为用户解决工作中的问题，同时提高和改进工作的效果。

而技术人员最常犯的错误，是把用户当成软件设计专家。比如在BI项目里，技术人员往往会问用户，你们需要什么样的报表，什么格式，数据在哪里。而用户就拿出一叠纸面的报表说，就把这些弄到电脑上去吧。本来意在提高商业效率的BI项目，就变成了一个硬生生把纸面文件通过软件重新实现的低效率工作。

所以项目的范畴制定，不能只限于直接用户能够看到的。作为信息处理的专业人士，我们必须首先要了解用户的商业需求。现在在信息应用上遇到什么问题?决策者有没有必要的信息和工具?具体操作人员有没有能力最有效地进行他们的工作?所生成的信息是不是足够相关人员解决问题?用户是否可以主动地分析和发现问题及最佳方案?

对商业问题的解决应该是BI项目范畴的出发点。但即使在用户需求已经确定之后，对项目范畴的管理也是一个需要一直进行的工作。只有在一个明确的指导之下，才能把整个项目的工作和用户的需求完美地结合起来。

设立符合现实的预期

BI项目往往是一个涉及很广的工作。从数据的收集，清理，存储，到数据的计算，呈现，分析，和信息的发布和监控。根据企业不同的现状，BI的实现往往需要分成几个阶段来实现。假设一个企业还没有建立起一套相关的架构，一个BI项目就必须首先解决数据收集和存储，建立数据仓库。在数据得到了保障之后，再进行报表设计，Dashboard，及数据分析等工作。

在一些新引进BI概念的企业里，用户往往会产生一些过度乐观的想法。常常会把目标定得很高。这样不仅会对项目的预算和时间造成影响，在把范围扩大太多后，也常常不能有效地计划和利用人员和资源。

近年来敏捷(Agile)BI的概念开始被大家接受。这里的Agile和软件开发是同一个概念。但应用到BI领域，就包含了一些自己的概念。比如对数据仓库的必要与否，数据清理的方式等等，都有一些不同的理念。这些我们在下一个章节仔细描述。

 了解架构和不同的技术选择

BI作为IT的一个分支，技术上的考虑也是一个很重要的方面。在这里我们讨论几个对项目成败影响最大的几个技术层面。

BI极少是一个独立的系统。首先，作为一个数据处理和信息呈现工具，任何BI的实现都是建立在其它系统的基础之上的。在计划一个BI项目时，我们必须对现有的软件架构有一个十分完整的理解。什么样的产品可以最好的嵌入到现有的架构里?什么接口可以最容易和高效地提取数据?BI工具是否提供了足够的集成功能?

在确定了架构的选择之后，第一个需要面临的是对数据仓库的选择和设计。数据的整合，清理，及存取是BI项目成功与否的决定性因素。传统上BI的最佳模式往往是建立在一个高度集中的大型数据仓库基础上的。在Agile BI的理念影响下，近年来也出现了一些其它的解决方案。比如用全内存数据处理的(Qlikview)及时汇总技术，采用云计算技术的分布式运算系统(Hadoop，StyleScope)。总体来讲，传统的数据仓库最大的优点是技术成熟，但比较复杂和昂贵。新兴的技术往往着重于快速的处理大数据量，但在系统的稳定性上可能还没有这么成熟。

于数据有着同等重要性的是信息呈现和互动功能。作为最终用户直接使用的界面，一个BI软件所提供的前端界面直接决定了商业用户可以得到什么信息和怎么使用信息。如果没有一个强大的客户界面，无论数据处理解决得多好，用户也不可能受益。

在前端功能选择方面，不仅需要考虑当前的用户需求，也应该考虑到以后的扩展。在一个BI项目实现之后，后续工作往往都集中在前端的增强。因为用户使用中会很自然提出很多建议和新的要求，而这些通常都集中在用户面对的界面。所以，在考虑BI功能时不要只是限制在传统的报表层次，同时应该考虑一些更先进的技术，比如可视化，Dashboard，数据预测(Tableau，StyleScope，SAS)等等。

准确定义和服务用户需求

用户勿庸置疑的是任何一个BI项目的中心。但明确谁是最终用户往往并不是一个容易的事情。因为BI系统往往有不同的用户群。从对日常报表使用的大众化用户，到专职进行数据分析的高端用户，大家对BI产品的要求可以说是形形色色。