可以先想一下自己的部门或项目组是否面临这些问题：
1. 投入很多技术力量做报表，却还是疲于应付
2. 用了高端报表工具和敏捷 BI，却还是不够用
3. 技术高手用来做报表，感觉很浪费
4. 对于频繁多变的报表需求，需要低成本应对方案

专门用于统计分析的报表业务有一个特点，就是业务稳定性非常差。在业务开展过程中会催生很多新的查询需求，而且已实现的查询需求还会经常变化，这就造成了没完没了的报表。所以经常会有这么一段对话

报表没完没了是需求使然，无法规避，只能适应，而目前主要的是问题是普遍缺少一种低成本的方案来适应没完没了的报表。

为什么报表开发成本一直居高不下？

我们知道，报表工具的主要作用是将报表呈现阶段的开发工具化，使用报表工具可以将原本需要硬编码的工作通过工具来提高生产效率；但报表开发的另一个阶段：数据准备，却仍然在使用原始的硬编码方式处理，有时我们要编写非常复杂的 SQL、存储过程和 JAVA 程序，这样的工作通常要依赖高水平的技术人员才能完成。

另外，采用过于原始手段会带来报表维护困难，复杂的代码无论从编写还是修改都比较困难，这样又会加剧报表开发成本居高不下！

除了技术原因外，还有应用结构和团队管理方面的因素也会造成报表开发的成本居高不下。在许多应用系统中，报表是耦合在其中的一些功能，而业务系统的技术环境很复杂，这就迫使报表开发人员也要熟悉这些东西，也就很难把报表开发人员和业务系统的开发人员分开，业务系统上线之后，开发人员仍然要继续坚守开发报表，很难把这项工作转交给客户方的运维人员。

开发过程中的有效沟通也会影响工作量。我们经常会发现这样的现象：业务人员提出报表需求，等技术人员做好后才发现某些概念术语的理解有误，统计口径不一致，结果并不是业务人员想要的，然后也只能重做，甚至反复多次才能正确实现，严重浪费开发资源。

如何解决报表开发成本过高？如何低成本地应对没完没了的报表？

可以尝试通过如下五个步骤来解决这些问题。

1. 引入报表工具

先把最容易解决的问题解决掉，通过引入专业的报表工具解放报表数据呈现阶段的人力，报表工具可以完成包括中国式复杂报表在内的各种图表呈现。选择成熟且性价比高的工具是这个阶段的主要目标。

2. 增加计算模块

引入报表工具后，解放了数据呈现阶段的人力，降低了一定的成本，但占主要部分的报表数据准备阶段仍未解决。

数据准备阶段的特点是：
1. 编码困难，没有普适的工具
2. 对人员要求高，需要高水平技术人员完成
3. 实现周期过长，难以适应多变的报表需求
4. 硬编码耦合性高，依赖数据库和 JAVA 都都会造成紧耦合
5. 运维过于复杂，修改维护成本提高

这时，我们需要沿着第一步的方向继续前进，将数据准备阶段也工具化。比较好的方式是
在报表工具中增加用于数据准备的计算模块，将原来使用 SQL/ 存储过程 /JAVA 实现的数据准备算法，全部通过计算模块完成，使得报表开发彻底工具化，简化开发，降低成本。

计算模块的能力可以通过脚本来实现，在脚本中内置各种丰富的计算类库，让报表开发人员独立就能完成数据准备阶段的工作，从而全面接管报表的开发，而不再依赖其他专业程序员。

这里尤其要注意，报表计算模块需要具备这样一些能力。

1. 易于编码
包含丰富的计算类库，可以很方便地完成各类数据计算任务；必要时还能提供可视化的编辑调试环境进一步简化这个阶段的开发；

2. 支持热切换
计算模块需采用解释执行机制，这样可以很好地和前端报表呈现模板结合在一起，报表修改后可以实时生效，无需重启整个应用；

3. 支持多样性数据源
提供 RDB、NoSQL、文本、Excel、hadoop 等多样性数据源接口，报表直接基于多言行数据源开发，也可以进行混合计算（如 Excel 和 RDB 的表 join）；

4. 高性能
计算模块的计算性能不能低于原来 SQL/JAVA 的计算性能，最好高于原来的实现方式。

报表开发全面工具化以后，就可以获得更高的报表开发效率，进一步降低报表开发成本。

3. 独立报表模块

报表开发全面工具化以后，就可以着手梳理应用结构，独立报表模块，从而将报表模块从业务系统中解耦出来。

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

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

3. 独立报表模块
报表业务完全剥离后，在报表工具中实现的报表在物理上就可以独立于数据源和业务模块存储，不再与业务系统和数据源紧密耦合，完全独立报表模块

4. 调整应用结构
独立报表模块后，报表模块与业务模块共享数据存储；应用系统调用报表模块为用户输出报表结果；同时解释执行报表模块支持热切换，即改即用，无需重启应用。

独立报表模块以后，报表就可以单独修改和维护，清晰的应用结构会进一步降低报表开发成本。

4. 建设报表团队

报表模块独立后，建设专门的报表开发团队，不再需要高成本应用程序员或 DBA 参与报表开发，进一步降低报表开发成本。

报表开发人员就无需应对纷繁复杂的应用环境，更无需关系应用架构，只需根据已有架构开发报表就可以了。半年以上工作经验的技术人员就能胜任（其实，理工科应届毕业生就可以了，甚至高中学历都行）。

简化报表开发后，还可以尝试将持续的报表开发工作移交给客户方的本地运维人员，这样不仅能降低开发商的成本，还能提高对客户的响应速度。

5. 完善沟通机制

最后就是建立有效的沟通机制，减少交流中的误解。

一个简单可行的办法就是建立企业内部的报表知识库，技术形式上搞一个论坛即可。把以前做过的报表收集到论坛上加以评注，并提供搜索功能。

当有了新的报表需求时，可以搜索历史库中是否曾经做过类似的报表（出现过相同的业务术语）。历史报表中保留有相关代码或公式，而这些形式化的信息不会有歧义，这就能帮助新的开发人员正确理解业务术语。

甚至许多报表部分还可以被直接复用，在人员变动时也可以最大限度地保证业务知识的继承。

应对报表没完没了是一个长期的过程，是涉及技术、管理等诸多方面的综合性事务。当这些步骤完成以后就可以全方位应对没完没了的报表了。

扩展阅读：
应对报表没完没了的五个步骤
一劳永逸地“解决”没完没了的报表开发