应用系统中的报表开发成本值多少？

报表看起来是数据分析处理领域中的一个并不起眼儿的边缘业务，数据工程师的关注点一般会在后端的大数据平台和数据仓库，即使是前端，架构师们也会更关注BI可视化等时髦的概念，报表则经常作为一个部分被湮没在呈现模块中，即使有时被单拎出来也就是在架构图上放一个报表工具而已。

这种忽视态度很可能造成对报表开发的成本估算严重不足，而应用中的报表又常常没完没了，总会有新的改的需求，导致整体开发成本被大幅度推高，任务完成也变得遥遥无期。

事实上，在应用系统中，查询分析的结果大都会以报表的形式呈现出来，外围的线下跑批看似与报表没有直接关联，但大部分也是为了进一步出报表而服务的。报表在应用中可以说是无处不在的，它的开发成本在应用建设中也有着非常重要的占比。

这些都是应用中的报表

说到报表，大部分人想到的可能是这样的表格：

其实很多报表并没有表格的样子，比如这种列表式的呈现

还有报表格式也并不完全都是这种比较规整的，比如下面这个考场分布和验收报告

另外报表不仅关注外观，还会关注统计功能，比如这种分组统计的列表和多数据来源的分组分片汇总统计

只要是和数据相关，要用于呈现和输出的都可以广义地算作报表

报表很难做吗？

这些报表，看起来无非就是些HTML了，写个页面加点JS，应该难不倒程序员，这会有很高的开发成本吗？

其实不然，那些报表样子看起来简单，但实际动手做起来就不简单了

先看格式，大部分的报表格子都不少，用HTML单纯的让那么多格子对齐就不是一件易事，而且报表往往还有斜线和各种合并格，处理起来难度就会更大，耗费的时间也会更多，后期用户如果发现格式不太对，得修改，牵一发动全身，那改一次基本相当于得重新做一遍了

但不管怎么说，格式只是个费劲的事，并不是难事，多花点时间总会把格式调整好，而格子中的汇总统计就是个难事了

报表很多时候并不是只需要罗列数据就可以，还需要统计汇总，比如前面的分组统计的例子，数据如果来自单表还好说，来自多表甚至多库的做起来就复杂的多了

另外分组的需求也有很多种，并不仅仅是简单的按地区，按部门分组这些，比如按段分组，按不同的区间分组

还有只按某些指标分组，其他都统计到“其他”里的

这些在页面中也很难处理，放到SQL中去算也不简单

还有统计也不仅仅只是汇总，还有占比、同比、环比、排名、累积等等，这些如果手工开发，难度又如何，又得占用多少工作量呢？

这么稍微一分析拆解，确实发现不是那么简单了，有点麻烦了

那么那种简单的列表总是比较容易做吧?

是，没问题，对于开发人员来说是基本功了，没多大工作量

但是，报表是会变化的，它会越来越复杂，因为需求是在不断的发掘并改变的，并不是一开始就能想的非常周全的

比如刚开始只需要我们做一个订单列表，后面发现还得加一些查询的参数才行，比如按时间段，按地区，按销售，再后来又发现想看具体订单内容情况时看不了，又得加一个钻取功能，钻取到订单明细页面，订单明细为了美观又需要有固定格式，比如每页显示多少行，不够的补空行，再后来又想到还得有分组汇总表，可以按地区，按部门统计不同时间段的业绩，最好再加一个伸缩功能

就这样，需求变的越来越多，报表也就越做越多，越做越复杂了

然而复杂化还不止于此，报表不光是用来看的，大部分时候还得打印成纸质的，或者导出成其他常见格式的本地文件才可以

打印功能就不容易做了，HTML直接打印的精度通常不会被接受，这就需要控制打印机，而且不同浏览器不同版本，支持的打印方式不同，该怎么才能做到周全，有些单据类的比如纸质发票，物流单等，需要精准的打印在打印纸上，又该如何控制，还有其他的比如一次打印多张，有的需要预览，有的不要预览，都是头疼的问题

再看导出，基本代码网上可以找到，但是改造成自己的也得费挺大劲，关键是用户并不是只导出一种格式，EXCEL,PDF,WORD,WPS,CSV都会用到，这需要多大工作量

如果再遇上下面这种少见的需求，需要生成动态的既有文字，而且有严格的排版要求，又得有实时数据的表格和图形的WORD报告，专门开发一个这个功能得付出多少成本呢

所以，简单的、少量的表格，写代码直接开发还可以，复杂的，大量的报表，全靠写代码的话从能力上说是难不住开发人员，但从成本上算就代价太高了，效率太低了

报表工具来了

草坪总需要修剪，人工剪效率低，割草机就来了

庄家每年都得种，人工种效率低，播种机收割机就来了

报表总得做，总得改，人工做效率低，报表工具就来了

而且人工开发报表效率低这事情，其实并不是现在才有的，从20多年前各企业刚开始信息化建设时就普遍存在了，所以，报表工具在20年以前就已经诞生并流行了

报表工具的诞生，不仅解决了那些我们可以想到的，常规常见的报表需求，同时也解决了许多应用中少见罕见的不太像传统报表的特殊报表需求，不管需求如何变化，也不管遇到的报表有多么复杂，它都可以轻松应对，持续发挥它降本增效的作用

而且报表工具的出现还在一定程度上优化了原本的应用结构，降低了后期维护的成本

报表工具制作的报表是模板化的，数据和表格的信息都存在模板中，报表的业务稳定性是比较差的，总需要修改数据或者样式，在模板中修改这些就很方便，修改完以后替换到应用中，直接就可以不用重启做到热切换，如果是全手工开发的，那报表和应用的耦合度就会比较高，修改起来动的地方就会很多，就会比较麻烦

                      报表工具的大致工作流程
1

工具也有成本

工具确实能提升效率降低开发成本，但工具本身也有成本，报表工具需要多少成本呢？

谈一个软件类产品的成本，对于大多数开发人员来说，都应该是零才对，因为有开源啊，不想用开源的开发不是一个好开发

报表产品也有开源的，一直都有，但不幸的是，开源的报表都是外国的，而且大都不好用，

简单的列表还能做，但格式稍微复杂一些的，就做不了了，比如前面提到的多数据源分片报表，还有其他的什么不规则分组、动态列、动态合并单元格、折叠报表等，开源的基本都做不了，做不了那就得通过api手工做，实际应用中这类复杂的报表又不是少数，那就相当于大部分都得写代码开发了

开源报表工具虽然不要钱，成本是零，但细算下来，复杂情况下多耗费的人工成本其实早就超过商用工具的成本了

商用报表成本又如何呢？

商用的，各家情况都不一样，但能做这些复杂报表的大都比较贵，目前主流报表工具中，只有润乾报表相对便宜而且透明，性价比高，1W一套，3W就可以一年随便用，

1W的版本有些什么功能呢，够用吗，答案是够用，报表呈现环节的需求，只需要这1W的版本就可以全部满足了，具体的功能可以看这个帖子

润乾报表版本解析 —- 朴实无华的功能列表背后藏了哪些不为人知的东西

至于更深层次的润乾为什么便宜呢，为什么会有这样的战略决策，可以看这里

我们公司没销售——疫情下企业软件的互联网营销

小结：开源的不一定真的成本低，商用的也不一定就都成本高，有润乾报表这样的标准存在，工具本身的成本，都没有工程师2周的工资高了

自助报表怎么样？

传说有种自助报表，可以让业务用户自己拖拖拽拽做出报表，那些BI工具都是这么宣称的，零编码，不需要技术人员，也不需要自己懂技术，只要有需求就谁都能做…

这不就能把工作和成本都转给业务部门或用户了吗？还落个灵活方便的好处

且慢！想得美

一是BI、自助报表没有这么神

自助报表和BI的定位是由业务人员去灵活的进行一些简单的数据分析，格式简单，计算简单时，BI还勉强可以胜任

能力强一些的工具也可以做一些涉及格间计算的同比，环比这些

格式和计算更复杂的时候，BI工具和业务人员就都应付不来了，还得用报表工具才可以

关于BI能做什么，可以参考：
自助报表和 BI 能解决多少事？

二是BI的成本更高

当然，BI和自助报表多少也有点用的，能上一套这东西，确实也能省一些事

但是，我们还要再说一句“但是”，BI的成本可不低，这概念时髦，虽然没太大用，但价格通常比报表工具要贵得多

国内商用的都是几十万一套，这个成本不管是谁来承担，那都不是一个小数目，是选一个1W成本就能解决问题的报表工具呢，还是选一个成本高又解决不好问题的BI呢？

BI就没开源的吗？

有，GitHub就有好多评分不错的，虽然说大都是国外的，但是国内的同学想用也可以拿来，只是界面改造麻烦一些，因为BI是页面为主的产品，那么多英文的页面都得改，工作量会大一些，成本依然比较高

改造成本比较低的开源BI有没有？

之前没有，现在有了，润乾报表里就有一个开源BI

润乾报表在业界口碑好，BI和报表本是同源，润乾的BI也一样，功能全面好用，这样使用成本就会比较低，不需要自己开发补足功能，另外页面是中文的，改造成本也很低，改改就成了自己的BI模块了

润乾零成本开源 BI 套件，不再掏钱给厂家

小结：BI和自助报表并不是解决报表需求的好工具，它做不了复杂报表，而且商用的成本要远高于报表工具，即使真有BI多维分析需求，也可以找开源好用的，这样才能既解决问题又控制成本

使用的成本

继续回到开发报表的成本话题上来

工具除了价格成本外，还有使用的成本，其实就是开发效率的高低

简单的报表可能看不出效率差异，格式和计算复杂一些后，差异就出来了，同样的报表，用A工具做半小时，用B工具做3小时，那B工具的使用成本就是A的6倍了

选一个工具，价格其实是次要因素，最主要的因素还是它用起来效率高不高，做的好不好

润乾报表用户多，大家选它也并不只是因为价格低，而更是因为它的开发效率是经历过无数个项目实战检验过的，能解决问题，又性价比高，才是大家选择润乾报表的原因

而一个工具的开发效率并不是那么轻易能考察出来的，有一些工具把易于初学者学习的一步步的可视操作当成卖点，宣传点，宣称开发效率高，零编码，考察人员也觉得这样确实很好用，很简单，但其实有可能掉进陷阱中，那就是开发报表的大都是技术人员，技术人员是很容易从一个初学者变成熟手的， 对于一个熟手来说，几秒钟写个表达式，要远远比一步步的通过对话框设置各种计算条件要简单的多，各种可视化设置就成了初学者之蜜糖，熟手之砒霜了

那到底开发效率怎么考察，所谓的零编码是不是真的，怎样才能找到使用成本低的工具，感兴趣的可以看下面的帖子

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

零编码制作报表真地可能吗？

这里也小结一下：开发效率高的工具，使用成本才低

进一步的成本

在报表的开发过程中，有时候我们还会发现，有一部分报表本身的制作并不难，工具能很快做出来表样来，但还是会耗费掉很多的时间去开发和维护，仔细分析后我们会发现，是数据源的准备过程和性能问题占用了过多的时间，这一下就又让开发成本增加了不少

数据源准备的成本

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

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

有人可能会想到，数据源准备，也不属于报表的能力范畴啊，所以这个开发困难的锅不能让报表工具来背，确实是的，数据源准备太困难不能怪报表，但不属于报表的范围就不用解决吗？有能力的，还是要替用户想办法解决的

润乾报表内置了开源SPL计算引擎，就可以很好的解决数据准备的难题，极大的提升数据准备过程的开发效率，节省大量的人工成本

具体的数据准备的难点在哪里，开源SPL是怎么解决数据准备的难题的，可以参考：

为什么用了大牌工具后报表开发依然头痛

再小结：有数据源准备工具的，开发难度就会低很多，成本也会低很多

性能问题解决成本

性能问题也是一个直接影响成本高低的重要因素，没有性能问题还好，如果遇上了，那人工成本就会急剧上升，而且性能问题，一般都得派高级的技术人员去救火才行，搞不搞得定是另外一回事，没完没了的持续投入就谁也受不了

报表的呈现周期中，大致可以分为下图的 4 个环节，4 个环节都有可能造成报表的性能问题，但概率较高的是前两个环节，数据准备和数据传输（图中黄色电池电量图，代表了出问题的程度）

数据准备就是前面说过的，它不仅开发困难，而且开发出的东西性能基本也不好，很多时候我们会发现上百行的SQL和存储过程已经完全没办法再优化了，遇到性能问题就只能硬挺

数据传输一般是由JDBC传输速率慢导致的，这个可以通过并行的方式解决，但大部分报表工具也并没有这个功能，只能是坐着等数据慢慢传了

后两个就是报表工具的基本工了，得计算引擎做的好，函数设计的好，才能算的快，跑的快

所以报表工具要想性能好，就得既要打铁自身硬，把后两个环节解决好，还得有解决外围难题的金刚钻，把前两个环节也一并解决好才行

报表的性能问题，具体的可以参考

怎样提高报表呈现的性能

再小结：性能好的工具，投入的人工成本才少

总结

仔细分析后，我们发现，使用报表工具能有效降低开发成本，而开发报表的总成本中，工具本身的成本其实并不高，尤其是现在润乾报表这样的主流工具降价后成本都比不上一个初级工程师两周的工资了

真正占大头的，其实是购买后隐形的使用成本以及遇到困难解决困难的人工成本，所以想要成本低，就得选一个开发效率高，性能好，又能协助解决数据准备难题的工具才可以，这样才能做到真正的低成本

润乾报表资料

• 润乾报表官网
• 润乾报表下载

欢迎对润乾报表有兴趣的加小助手（VX号：RUNQIAN_RAQSOFT），进技术交流群