BI是软件工程还是OFFICE？

一次和同事聊天，说到为啥银行电信行业的报表完全依赖IT或外包开发，而非业务人员自己开发。后来达成一个一致看法，一是垄断企业的工作作风，认为这是IT人应该做的，我拿成果就是了，二是他们数据量过大，非专业人员开发的报表可能性能有问题，当然还有其他因素。

不过我认为报表还是要业务人员开发为好，其他阻碍因素都可以作为解决的对象，没有做不到的事情。

我们在做项目的时候都会发现，来自转手的2手需求，往往会使你事倍功半，甚至白白干活做出错误的开发，那么我们来看看常见的BI事实关系：业务部门需求->IT部门汇总需求->咨询商给出解决方案->实施商实施->给业务部门使用

这就有很大的问题，最终开发的人员来的需求可能是2手甚至3手需求，他们真的知道业务部门想要什么样的报表，用来干嘛，用户对象是谁，报表是否合理？他们不知道，但他们坚信，这是BI圈子的合理分工，他们照做就OK了。不过实践证明，他们开发出来的报表，很可能要么不是用户真正需要的，要么是已经过时的报表（报表需求者可能已经换人了）。那么重新开发、测试、上线，结果又过去了几周时间。

其实很简单的报表问题，业务部门想要什么就拖拽下就OK了，是不是自己想要的，看看就知道。这就是把一个office问题当作一个软件工程来看，是不恰当的事情。有人问，业务人员怎么知道自己这样非专业IT人员开发出来的报表是否OK呢？我觉得这是引导问题，成为开发报表平台的系统，再去开发报表，已经不是软件问题了，而是OFFICE问题，不应该IT部门来做，除非出了性能或数据质量问题，那才是IT部门的责任。

所以我认为BI业界的进化，首先是BI实施与用户的共同进化，将BI分为软件工程与OFFICE应用两个阶段，然后分工重新划分，将其作为标准，彻底去掉用户想当然认为报表开发还是IT人应该做的事情，自己只负责看报表的观念。

那么软件工程就是大家常见的数据仓库构建(包括数据仓库模型、ETL、数据质量监控等)、BI展现模型构建（可以为ROLAP或MOLAP），到这里软件工程就完成了，剩下的报表开发应该属于OFFICE应用（数据挖掘SAS/SPASS等属于高阶分析应用，应用不普遍，成功案例也少，不在此讨论之列）。

那么这样的划分清晰之后，也将出现革命性的分工和流程实施。

首先IT人员由烦琐的反复的报表开发解脱出来，专心做好平台事宜，同时对数据质量、业务模型进行更好的管理与整合，以满足更多用户的需求。他们也将有更多时间和精力思考BI在企业的更多应用。

其次业务部门可以对业务需求进行快速反映，由原来做一张报表少则几天，多则几周的报表开发周期缩短到一天甚至一个小时以内，使得BI里的信息实现了“大象跳舞”，让业务人员融入业务分析的快乐之中。这样由BI直接需求者->BI需求分析师->BI平台设计开发者，然后快速进行反应。试想10个报表开发人员一个月可能开发300张分析报表，当成软件工程来做，经过开发、测试等工序，还忙得要死。但如果300名业务人员自己开发，一个月就可以开发3000张甚至更多报表，而且每张都能得到及时应用。

再次对于成本将会大副降低，同时减少含金量低的不必要的岗位。目前大家也知道开发大量不必要的报表，那是浪费资源，如果开发为其所用，就不会存在成本浪费。而且单纯做报表开发的岗位即使工资再低，这样的人员组合也没有业务人员自己开发来的性价比高。

最后对于BI价值的体现，是最好的证明。大家知道BI如果由IT部门开发，势必重点在形式（报表开发人员只会考虑是否符合报表需求），而业务人员会切实考虑我用这个报表来干嘛，我的用户又将作何反应。而我们企业中需要整理、整合报表的人有很多，如果发挥了他们的能动性，那么整个企业的最终用户将能得到更快速的信息反应和应用。这样我们把BI的用户由业务人员/中低层干部，转换为用户+开发者，直接服务他们的用户：他们自己+高层+低层人员或客户，这样的深入程度和推广速度将更快。

上面所说，为我认为的趋势。而实际操作中，我们BI人仍然要做一些报表，他们主要是对性能有要求的、复杂又需要技巧的、高层立刻要求要的报表，这样BI人也能切实了解用户的需求目的和作用。如果说用户不愿意做或抵触心理，那其实是对用户培训和引导不到位，其实用BI开发分析性报表，和他们玩office一样简单，只要你们平台做得足够好，指标和维的属性，以及他们之间的matrix足够清晰，又有什么难的呢？除非你们的用户连OFFICE也不会玩，那还是你们自己开发报表吧。我接触到的用户中，有的由抵触，变到每天把各种事实数据与维的MATRIX拿来研究组合，经常能开发出有趣的分析报表，后来简直爱不释手。

习惯成自然了，想把开发报表的工作推出去，尤其是推给业务人员自己，很难。