自助报表和 BI 能解决多少事？

常做数据信息化、数据分析的同学基本都遇到过这个问题，看着不起眼的报表任务，做起来却占用了很多时间，总是不断的有新报表要做，老报表要改，总是有难缠的数据准备要去写复杂SQL或者存储过程甚至JAVA代码，原本以为初级工程师就可以搞定的事情却始终都得有高级工程师跟着， 报表给人的感觉像是没完没了的，资源的投入也没完没了，成本始终居高不下，一个简单的报表模块，却每每成了项目的拖累。

一、报表为什么没完没了？

报表没完没了确实是存在的，也是一个无法规避的事实，因为报表的业务稳定性本身就比较差，在统计和分析的过程中，总会碰撞和催生出新的、或者更合理的需求，那就需要修改或者做新的才可以，这与实施方和用户的经验无关，谁都避免不了。

有同学会说，BI不就可以解决用户的报表没完没了的问题吗，给客户上一套BI，有需求用户自己去做就可以了，我们就解脱了，确实有人这么做过，但还是解决不了，因为BI有局限性，感兴趣的同学可以参考这个帖子，这里就不细说这个话题了。

二、自助报表和 BI 能解决多少事？

报表没完没了无法规避，开发成本就只能居高不下吗？

不然。我们先来分析一下开发成本高的地方在哪里，然后再看有没有办法降低成本。

三、开发成本为什么居高不下？

1、工具开发效率低

被报表没完没了困扰的开发团队，基本上都会用报表工具来提升开发效率，不用工具的很少。报表工具也的确不负众望，可以很大程度的提升效率，节省开发成本，但是报表工具本身也有差异，效率也就有高低之分，就算是效率稍微差那么一点点，长年累月无数个项目累积下来，也是一个不小的数字。

开发成本居高不下的原因，很有可能就是选了开发效率低的工具。

2、数据源准备开发难

好的报表工具确实可以很好地提升制表方面的效率，降低成本，但是报表开发的难题，并不全在制表上，还有相当一部分在数据准备上应用中的报表，有 80% 的数据来源和计算都比较简单，很多一个简单的 SQL 语句就搞定了，但还有 20% 的情况中，数据准备工作就没有那么好做了，一些过程式的多步骤复杂计算，常常要写很长的多层嵌套的 SQL 或者存储过程才能搞定，如果数据来源再复杂一些，要对各类数据源混算，一些非关系数据库或者文本数据源都不支持 SQL 了，那还得用 JAVA 等语言来写，SQL 10 几行能写完的，JAVA 恨不得写出几百行来，编码难度和效率就更糟糕了。

然而恰恰就是这仅占 20% 的需要硬编码来做复杂数据准备的报表，可能会占去我们 80% 的工作量，让开发成本徒增。

有人可能会想到，数据源准备，也不属于报表工具的能力范畴啊，所以这个开发困难，成本高的锅不能让报表工具来背，确实是的，数据源准备太困难不能怪报表工具，但仍然属于报表开发的范围，我们也得解决，报表工具解决不了可以寻找其他工具！

3、系统维护成本高

上面说到的，有些报表会涉及很长的存储过程和自定义JAVA代码，这样会造成报表模块和整个业务系统的高度耦合，维护修改报表的时候，整个应用系统可能都得一起停摆、重启，维护起来不方便，成本就会高。

4、高级人员成本高

而且这些复杂的SQL，存储过程，自定义JAVA，以及性能问题的排查，全部都得高级技术人员去做才可以， 什么都用高级人员，成本自然又会变高。

5、沟通和管理成本高

除了技术原因外，沟通和管理上的问题也会导致开发成本上升，比如用户要求做表，做完以后才发现用户说的概念术语和我们理解的有偏差，统计的不对，那就得修改，返工。再比如有些报表是可以复用的，或者稍加改动就可以吻合新的报表需求，就不需要重做了，但是开发人员太多，如果报表管理做的不好，就每个表都得做一次，浪费很多开发量。

这些就是成本居高不下的主要原因，找到原因后，我们就可以挨个想办法去解决了。

四、解决方案

1、使用高效报表工具

用报表工具，尤其是高效的工具，可以显著提升报表设计与呈现的效率，降低开发成本。

要用高效的，大家都知道，但怎么选高效的，却不是一件简单的事情，验证工具的效率，需要一套科学严谨的的方法，有需要的可以仔细看看这篇帖子。

2、怎样考察报表工具的开发效率？

具体的方法帖子里都有详细说明，本文就不展开聊了，只说一个验证时候最容易掉的陷阱—初学者陷阱

有一些工具把易于初学者学习的一步步的可视操作当成卖点，宣称开发效率高，零编码，考察人员也觉得这样确实很好用，很简单，但这样就掉进陷阱中了，初学者易上手绝对不等于效率高！反而一步步的可视化的引导操作会成为提升开发效率的很大障碍。

因为开发报表的大都是技术人员，技术人员是很容易从一个初学者变成熟手的， 对于一个熟手来说，几秒钟写个表达式，其表达能力要远远比一步步的通过对话框设置各种计算条件要强大得多也简单的多，各种可视化设置就成了初学者之蜜糖，熟手之砒霜了。

当然如果没有时间详细考察也无妨，选一些老牌的大家常用的工具就可以，像润乾报表这样的，已经有20年经验和历史的，经历了无数用户验证的，开发效率都是远高于其他工具的。

3、引入计算工具

高效的报表工具，可以提升报表设计和呈现的效率，但对报表数据准备阶段的开发压力却仍旧无能为力。

这就需要有新的工具才可以解决，一种比编写复杂SQL，存储过程，JAVA更高效，成本更低的计算工具才可以。

这样的工具其实并不新鲜，早就有了，润乾出品的集算器SPL就是专业的计算工具，因为简单高效，而且开源免费，已经是比较流行的工具了，它有如下几个特点。

① 易于编码

SPL包含丰富的计算类库，可以很方便地完成各类数据计算任务；提供可视化的编辑调试环境,初级工程师就可以很快上手，不需要全程都得高级工程师跟进了。

② 支持热切换

SPL采用解释执行机制，可以很好地和前端报表呈现模板结合在一起，报表修改后可以实时生效，无需重启整个应用。

 ③ 支持多样性数据源

支持RDB、NoSQL、文本、Excel、hadoop json等多样性数据源，可以进行混合计算（如 Excel 和 RDB 的表 join）；

④ 高性能

SPL的性能在大部分场景下都已经被验证过是高于甚至是远高于 SQL的

当频繁复杂困难的数据准备过程，也有了趁手的工具可以解决以后，开发就变的简单轻松了，成本也自然就低了。

另外再强调一点，SPL是开源免费的，是一个通用的计算工具，不仅润乾报表可以用它，其他报表工具以及各类前端应用，也都可以用它。

3、独立报表模块

报表与业务系统的高度耦合，导致报表不易维护，还影响了业务系统的稳定，那我们就想办法把报表模块独立出来，原先是没有这个条件，现在有了计算工具以后，存储过程，各种中间表，JAVA程序就可以慢慢剥离开了，报表就完全可以和业务系统解耦了。

① 梳理数据源

首先梳理数据源，将报表业务相关的数据源都整理出来，以后的报表开发只需要和这些数据源打交道；同时为下一步剥离报表业务做准备。

② 剥离报表业务

将数据源和业务应用中与报表相关的数据准备（复杂SQL、存储过程、中间汇总表、自定义JAVA类）全部转移到报表工具，计算工具中实现；同时将这些内容从数据库和业务应用中清除，完成报表业务剥离。

③ 独立报表模块

报表业务完全剥离后，报表就可以独立于数据源和业务模块存储，不再与业务系统和数据源紧密耦合了，解释执行报表和计算模块支持热切换，即改即用，无需重启应用；不管报表要怎么加怎么改，都不会影响到业务模块了，而且独立的报表+计算模块，维护起来也更简单了，不需要投入太多成本了。

④ 建设报表团队

原先因为总有困难的数据准备任务，不是得写大段复杂的存储过程，就是得做JAVA开发，处处离不开高级工程师，有了计算工具后，困难的事情都变简单了，复杂的数据准备工作不存在了，疑难的性能问题也没有了，自然就不需要浪费高级人员了。

 不需要去应对复杂的应用环境，也不用管什么架构，只需要专注开发报表就可以，那建设一支应届生报表团队就完全没问题了，既节省了成本，还让新人挑起了重担，历练了新人。

另外报表开发简化后，还可以尝试将持续的报表开发工作移交给客户方的本地运维人员，这样不仅能降低开发商的成本，也可以让客户更自由方便一些，对双方都是好事情。

⑤ 完善沟通和管理

沟通成本高，而且总有偏差，可以通过建立知识库来解决，比如统计好行业常用的指标计算方式，记录好每个客户业务术语的含义。

比如用户要做一个大客户信息表，我们就可以先查一下知识库中有没有记录“大客户”是怎么定义的，这样就可以有效的避免偏差返工，节省成本。

 报表总是重复去做，也可以通过报表知识库来解决，把历史的报表都保存好，做好注释备注，遇到同样的或类似的报表时，就可以直接拿来改改用了。

至此，导致成本过高的几个难题，就都一一击破了，一套组合拳打出后，回头再看，只剩下一地纸老虎了。

五、总结

报表总是得做新的改旧的，总是没完没了的，这的确是一个让人头疼的事情，而且这还是一个合理的、让人无法规避的事情。躲不了，那就得想办法解决，不能让它一直困扰我们，更不能让成本白白被消耗掉，传统的单一报表工具形式已经明显无力解决这个难题，而要采用文中提到的组合拳才可以有效应对。

而且这套组合拳，不仅可以把高昂的开发成本打下来，还能让我们在工具成本上也大省一笔，虽然多了一个计算工具，但它是开源免费的，配上1W一套，3W随便用的润乾报表，就可以去随便KO各种报表开发难题了。