BI 建设效果和工具平台的关系有多大？
BI 建设的目标
随着“大数据”时代的全面到来，企业在经历了多年的信息化建设和积累后，也进入了自己的“大数据”时代，这些从日常经营中产生、积累的海量真实数据，就成了企业的宝藏，一座隐藏着的，需要挖掘才能得到的宝藏
BI 建设的目标，就是帮助企业挖掘这座数据宝藏
通俗点说，就是通过分析这些数据，找出数据背后的逻辑，然后再指导企业怎么赚更多钱、省更多钱
书面点说，就是通过分析数据，为企业决策提供依据，让管理和决策有数、有理可依，减少盲目性，使企业的管理和经营更科学、理性更有效，从而达到降本增效的目的
这就是企业建设 BI 的目标，也是期望达到的效果，那通过什么方式才能实现目标，达到效果呢？这其中又和工具平台有多大关系呢？
BI 多维分析工具 华而不实名难副
要建设 BI，最先想到或者上网搜到的就是 BI 多维分析工具了，然而，在众多 BI 工具中，对 BI 建设效果最差的，就是这个多维分析了
BI 多维分析，号称可以让业务人员摆脱对技术人员的依赖，自己在页面中灵活拖拽分析的能力，然后再根据分析的结果，进行科学的决策，这个功能设想的很好，用户对它的期待也很大，但最后的结果却是，这个 BI 多维分析工具，经常都成了摆设，只能起到少得可怜的作用
出现这样的结果，主要是因为 BI 能力差导致的，这个能力差并不是指页面端的多维分析能力不够，针对一个事先准备好的数据源进行切片、钻取、旋转等分析，这些能力对于 BI 来说是足够的，业务人员也都可以轻松驾驭，BI 能力差，是差在数据处理能力上
我们来通过一些常见的分析需求 ，来看看 BI 工具的数据处理能力
分类汇总可以做
l 统计全班同学各科的总分和平均分
l 按地区、省份、城市，分组统计客户的数量
l 移动公司统计北京各区 1 季度新开通了多少电话号码
l 仓库统计各类产品库存量以及和年初的差值
l 查看每个销售每月的订单量以及是否付款
l 等等。。。。。。
这类的分析大多数业务人员用 BI 工具都可以拖拽出来，因为它们基本都是对同一个数据表内的数据进行分类汇总，数据逻辑比较清晰，相对简单不过，这样的简单分析，业务意义也比较小，在分析需求中占比也少，估计也就 10%
然后在这类“分类汇总”的分析中，通常还会有排名、占比、累积、同环比这类的需求，比如
l 学生单科排名，总分排名，比去年同期
l 各省客户数量排名、占比
l 销售额的环比，累积等
这些就稍有点难度了，虽然大部分 BI 工具也都能做出来，但功能做的不好的，业务人员理解和使用都会很费经
再复杂一些的，比如: 学生成绩求出比去年同期后，再排个名，看谁的进步最大，很多工具就做不了了，就连这 10% 的场景也胜任不了了
说白了，BI 多维分析能干的活，在数据能力上并不超过 Excel 透视表多少，只不过界面操作更流畅顺手，画出来的图表也更花哨
关联分析做不好
上面的分析基本都是基于单表的，占比不大也比较简单，多表关联的分析场景就难一些了，占比也多一些，大约能到 20%-30%，比如：
l 查询北京号码打给上海号码的通话记录，需要通话记录表和账户记录表重复多次关联
l 查询中国经理的美国员工，需要员工表和部门表相互关联
l 一些表中有父 ID 和子 ID 查询时需要自己和自己关联
l 按日期统计合同额、回款额和库存金额，如果没有事先准备好宽表，又会涉及多个表的关联
l 等等。。。。。。
这些复杂的关联分析，各个 BI 工具也都宣称自己是可以做的，但实际效果却和宣传相差甚远，有兴趣的读者可以拿这些题去考一考 BI 工具
大部分的 BI 工具解决关联分析的方法有两种，一种是：先由技术人员建模来消除关联，做成宽表或者类似宽表的 CUBE，然后再能给业务人员去拖拽分析，本来是要马上做的分析，结果还得找技术人员给建模，等建好了，可能好几天都过去了，这样的方式不仅保证不了时效性，做什么都得求人也失去了灵活自助分析的意义
第二种是：干脆把数据直接暴露给业务用户，让用户自己去拖拽关联，这不就及时了也灵活了吗，但是连技术人员都可能被绕晕的关联关系，又怎么可能是业务人员能拖拽清楚的呢，就更没法用了，没意义了
所以实际结果就是，大部分的 BI 工具其实解决不好占 20%-30% 的关联分析的需求，只有润乾报表的 DQL 是一个例外
润乾的 DQL 引擎可以把复杂、难懂的各种关联自动处理成业务人员轻松就能看懂的树状目录数据，就可以不求助技术人员，自助进行拖拽制表了，解决难题的同时也在一定程度上拓宽了 BI 分析的使用场景
多步计算做不了
即使做到了关联分析，仍然也只能解决小半部分交互数据分析任务
更常见的分析任务中还会涉及多步计算，比如
l 列出销售额累计占到一半的前 n 个大客户
l 查看一下语文、英语和数学成绩都在前 10 名的学生都有谁
l 查查哪些半年不出单的客户在更换了销售人员后半年就出单了
l 找出 3 年内的销售冠军以及他们卖的最好的产品
l 计算某支股票最长连续涨了多少交易日
l 等等。。。。。。
还是上面的话，有兴趣的读者可以拿这些问题去考 BI 工具，看看谁能让业务人员自行解决这种运算？
这类计算，通常都得分多个步骤才能算出来，遇到这样的分析需求，当前的 BI 工具基本就全偃旗息鼓了，没有能做的了，而这些分析，恰恰才是更有业务意义的分析，才是企业真正需要的分析，在 BI 应用中也是占比最大的任务类型
从这些例子一个个看下来我们会发现，BI 多维分析工具，虽然叫 BI，感觉和 BI 建设最贴近，但却盛名难副，华而不实，能做的很少，大部分的 BI 工具居然仅仅只能胜任占 10% 的简单分析需求场景，稍复杂一些的关联分析就只有少数工具能做了，更复杂的有多步计算这类复杂计算的，就全军覆没了，所以最后基本都被用户束之高阁、成了摆设了，对 BI 建设的效果并没有起到多大的作用
这些任务在 BI 应用中占到 **70%** 以上的、更有业务意义的多步分析需求，BI 工具做不了，那就只能求助技术人员来做了，不管怎样，分析还得继续
报表工具少不了
请技术人来做，通常会把数据运算的结果做成一个报表提交给业务人员，数据分析任务就变成了报表开发的任务
要做报表，那提高技术人员工作效率就很重要，得有一把趁手的工具才可以，既能做，还得快，这样才能让 BI 建设的效果更好，所以报表工具的制表能力以及数据准备能力很关键，而且数据准备更重要
多步计算的分析，BI 做不了，并不是因为格式复杂，而是因为计算过程复杂，而这些复杂的计算，即使放到报表工具中让技术人员来做，其实也不简单，就拿其中一个例子来看：计算 ** 某支股票最长连续涨了多少交易日，这样的分析，在页面端呈现，也就几个格子就能放下所有信息，但数据准备却很难，没有几年经验的同学写不出来
而且企业多年积累的这些数据，有 RDB，有 NOSQL，有文件、json，有 MPP、 Hadoop，常常会涉及多源混算，有时候不得不用 JAVA 来写，数据准备就会更难
所以面对这些复杂的计算，有良好的数据准备能力更重要
但不幸的是，并没有多少报表工具在数据准备上下过功夫，大部分还得是技术人员去硬写硬算，目前只有润乾报表有专门的数据准备工具
在润乾报表中，多了一个SPL 集算器的数据计算层（SPL 本身是一个流行的开源计算工具），这个计算层就是专门用来做数据准备的，它支持多样性数据源的混算，可以高效的代替 JAVA、存储过程，以及上面的多步计算中的复杂 SQL, 甚至还能代替 ETL，数据中台和治理，实现它们整理准备数据的功能和效果
而且这个数据准备能力，不仅可以给报表提供数据，同样也可以给 BI 准备数据，它可以把 BI 工具不擅长的分步计算以及某些关联运算，在计算层内做好，然后提供给 BI 来用，也能在一定的场景下提升 BI 的能力
想了解SPL是怎么简单的做多步计算的同学，可以看这个帖子，帖子里有很多高效计算的例子：
很多 BI 项目中同时会把分析可视化也考虑进来，引入好的报表工具不仅可以做复杂的分析报表，同时也可以分析可视化搞定了，报表工具一般都有良好的图形能力，或者是集成了优秀的第三方图形包，图形可视化就不在话下了
至于大屏，梳理业务、需求调研、制定指标、整理数据、绘制原型、动画美工等环节，该人工做的都得人工去做，用不用工具其实都一样 ，并省不出多少工作量来，而且大屏工具往往价格还很高，就显得作用更小了
专门为交互分析设计的 BI 工具却作用不大，反到是不起眼的报表却默默地承担起很多，又能做报表，又能可视化，但毕竟交互能力比较弱。那么，能够让业务人员交互分析的 BI 功能就搞不定吗？
经验加持才会好
BI 交互分析依然很有希望，依旧很有前景，但企业级 BI 需要由有丰富行业经验的软件开发商来主导才行，而不是通用 BI 产品来解决
有了行业经验才知道这个行业需要分析什么，业务用户关心什么、常用的是哪些，需要哪些数据，就可以把常用分析需要的数据源提前准备好，避免临时修改或者重新做 CUBE（如果用润乾报表 DQL，做这一步会更方便）
有了行业经验才知道哪些参数指标需要做活或做死，界面才会方便，比如现在有很多标签属性（是否值，客户是不是大学生，有没有信用卡），数量可能达到几百上千，通用 BI 会把这些都当成维度统一处理，让用户对着成百上千个维度去拖拽，不仅界面难用，能不能找到想要的标签都是个问题，有行业经验的开发商则会把标签按业务合理分类后再呈现出来供用户拖拽，，就会好用很多。还有些标签、维度是联动的，选了某个，其它维度的可选范围会跟着变，有经验的行业开发商就会把它提前做好联动，选起来就会更快捷方便，而通用 BI 产品是不会知道这些的（或者就需要很复杂的表达式甚至脚本来定义）
有了行业经验才会更了解用户的使用习惯，更懂用户，有些维度或条件可能还会有行业甚至用户特有的输入方式，比如股票区间可能希望看着 K 线图去找，这些都有强烈的行业特色，对行业了解足够深才能把握用户这些习惯，并根据习惯来优化功能，还可以把一些行业内常见的多步计算事先封装好，业务用户可以直接引用。各行业还有自己的内部文化、知识、语境等，深耕行业常和用户泡在一起的软件企业才会感知到这些细节，更懂用户才能做出业务人员更容易理解、更方便使用的界面，而通用 BI 则不可能做到这一点，它的普适定位和行业专精本来就是冲突的，只会提供通用抽象的技术术语和统一的界面，这就会造成不管是哪个行业用起来都不是很贴近的感觉
有了行业经验还能防范技术风险，数据开放给用户后，很有可能会做出不规范、不合理的拖拽，这就会带来性能问题，造成卡顿，或者直接把后台数据仓库给拖死了，行业经验支持下的交互界面，对应的后台计算是设计过的，计算量可控，定制界面还可以对计算量巨大的动作做出限制，这样后台数据仓库也能撑住了，避免了性能问题隐患
但是，想要把这些行业知识和经验融入到 BI 工具中，却不容易
行业软件开发商自己从头去做一个 BI，工作量和难度都太大，不太现实。CUBE 虽然简单，但其数据处理和界面仍然有不少的内容，BI 厂商也耕耘了不少年头，完整复制并没那么容易。如果能基于现成的通用 BI 产品再来改造定制，那就轻松多了，可惜，商用的 BI 工具大都是不开源，对外接口也很简单，无法支撑深度改造定制的可能性。幸好开源 BI 还挺多，国外的有不少，国内的也有润乾的开源 BI，中文页面更好改，而且润乾专注于 BI 报表行业 20 年，也更懂国人的 BI
在行业经验的加持下改造过的 BI 解决方案就会比通用的 BI 产品更好用，业务用户能做的交互分析也就更多更轻松了，BI 的作用也就更大了, 未来的前景也就更广阔了
总结
通用的 BI 工具的数据能力其实是挺弱的，看着华丽，但名不符实，大部分的情况下都成了摆设，为企业 BI 建设期望效果所做的贡献其实很小，而且，选谁都差不多
想要 BI 能达到期望的效果，首先得提升 BI 自身的能力，比如关联分析，让 BI 可以胜任更多的分析场景，然后还得找一个有经验的行业专家来改造、协助实施，就好比，能不能剪一个好看的发型，一把趁手的剪刀固然重要，但找一位有经验的 Tony 老师 来剪才更重要
当然还离不开其它分析工具的补充，比如报表工具，单靠 BI 工具是支撑不起完整的分析系统的
