列表在文章最后有下载方式

 

前言

报表工具是一个接近 20 年的产物了

但是，直到现在，在各种数据信息化的系统中，报表工具的作用，不仅没有褪色，反而是因为信息化需求的增大、数据的增多，以及报表工具本身迭代后越来越方便好用，使得它的使用范围越发的广泛了

报表选型也是一个老生常谈的话题了

但是，直到现在，依然有很多项目组，很多技术人员并不知道该怎样正确的选一个合适的报表，一个不会让自己在项目后期掉坑里的报表

本文全文 9990 字，大概需要 10-20 分钟阅读，旨在把这么多年总结下来的一些选型重点注意事项和验证技巧分享给需要做报表选型的技术同仁们，让我们选型变的更有重点，轻松又有保障

如果有想偷懒同学，也可以直接跳到文章尾部去看结论，也有完整的选型指标，和对应的重点注意事项表格供大家下载使用

常规选型的误区

常规的选型基本都是做一个功能需求列表（也可能从网上搜来），然后去找厂商应答，形式没问题，但很多需求列表却会有很多误区：

l 陈年老列表，体现不出当前的新技术，有些指标还可能是错的

l 没有错但也没有用的废话列表，任何厂商都可以应答全部支持

l 没有想到重点要验证什么的列表，也都会被应答成全部支持，没有区分度

l 厂家散布在网络中的钓鱼列表，有些厂商的还算中肯，但也有些厂商会把把一些看似有用实则无用的所谓独有功能说成重点去误导选型

这是一个常规选型表开头的小部分，在这么短短几行中就能出现两个典型的误区（图中标出的 1 和 2 ）

1. 指标写的不够细致，不知道该验证啥

比如中国式复杂报表这项，哪些是复杂的，哪些需要重点验证，这里就没写清楚，反而写了一些卡片式，分组式这类简单报表，这样就会误导选型的人了，选出来的产品可能根本做不了真正的复杂报表

多数据源支持也是一样的问题，也是说了等于没说，要支持哪些，以及如何支持法，都必须说清楚，否则这样的指标，所有的厂商都会答复支持，那这样的选型还有啥意义？

这类不细致的指标，会导致选型没有区分度，得到的结果都是支持，但如何支持的却会导致完全不一样的后果，这是传统选型表的最关键问题

后面我们会具体说到这两项指标的验证重点

2. 错误无效的指标

像 WEB 设计器和 APP 之类，就属于错误的指标了，为什么呢？

因为 web 设计器出发点是美的，想让做表的人员，不管是技术，还是业务，都可以方便的打开一个网页就可以做表，然而事实上却是没有一个工程师愿意用（不好用），也没有任何业务人员去用（不会用 + 不好用 + 懒）

提供的移动端 APP，看起来似乎是个必要的功能，但其实不然。报表自带的 APP，不能和整体项目的 app 集成，本身又缺少用户组织功能或不合适，没法拿来直接用，也不好二次开发补充功能，结果就是基本上还是没法用

所以这些指标如果列出来，就会误导一些对报表还不太了解的选型人员把它们加到自己的列表中，不仅把好产品给筛掉了，还选了不好用的产品

这里了就只举这两个误区的例子，其他的，会在后面系统详细的给大家展开分析

我们会从报表功能，BI、填报这几大方面，分类分项的去列出这些坑，列出每一项指标中的重点

让我们在以后的选型中，即使随便拿着一个列表，也能有目的，有针对的去验证，带着尖锐的问题去让厂商应答，做到心中了然，手中井然

开发工具

关注本地设计器

BI 页面分析概念逐渐流行后，有些客户就提出了一些新想法，比如是否所有报表都可以在页面上制作，厂商是否可以提供 web 端的复杂报表设计器？这样业务人员就可以摆脱技术人员自己制作复杂报表了

但事实上却是，业务人员根本都搞不定中国式复杂报表，不管是在桌面设计器还是 web 设计器，而且他们也根本不想搞，最终做表的任务还得是要靠技术人员来做，而技术人员则没人愿意用这些 web 端制表的功能的

原因有 2

1）web 端设计器因为技术局限性，很难做到像桌面设计器一样功能全面，很多复杂功能做不了，而且开发效率低下，对于有很多报表的项目，效率就是成本

WEB 编辑界面，看上去很美

2）web 端设计器会让应用变的臃肿庞杂，原本报表的应用基本只有 100 多 M 大小，带上 web 设计器后，就可能到了 600M 以上，而且 web 端功能很不稳定，会影响服务器的稳定

所以报表工具必须提供桌面设计器，所有国内的优秀厂商也基本都是通过桌面设计器来的做报表的。其实你想一下，有没有什么面向程序员的成熟开发工具是基于 WEB 的，复杂报表开发本质上是一种开发工具

清爽快捷的桌面设计器，实际上也很美

布局方式是 Excel 式的还是控件式的？

Excel 式的更直观，易上手，易操作，可以看上面的图，用过 Excel 的人天生就会对这个界面有一种亲近感

国产货大都是Excel风格的，基本都能过关

其他方式的，控件式 条带拖拽式等，都不易摆放，不易对齐，设计不便

国外产品和开源产品很多都这样，可以批量放弃

可以看看下面这俩，看着就有点蒙圈，不知道该怎么弄了，完全和我们平时看到的表格不一样，增加学习成本不说，即使学会了也不好设计

另外还有一点非常重要，大部分的报表都是有原始 Excel 表样，只有类 Excel 的设计器，才可以把历史 Excel 直接转换成报表，而其他形式的，那就得全部重新画，成本太高

控件式操作方式是国外 20 年之前第一代报表工具的制作方式，从来就没有好用过，直到现在一些国外的开源报表仍然延用这一落伍的方式，这也是他们逐渐没落的原因了，现在开源报表论坛基本都沉寂了，无人问津了

数据源

关系数据库怎么验证

Oracle、DB2、SQL Server、MYSQL、INFORMIX 达梦 金仓 Gbase

。。。。。。。。。。。。。。等等 一大堆我都支持

是不是写得越多越牛？

其实这项不用考察，只要是关系数据库，写上的没写上的统统都会支持，因为这是世界标准！列更多并不更值钱！ 如果有某个奇怪的数据库不能被支持，那大概率是数据库的问题而不是报表工具的事情，应该去找数据库厂商的麻烦。

非关系数据源怎么访问

1）不能简单相信“支持 xx 等”的说法，咱们需要什么，必须自己想清楚，然后去验证

2）所谓的支持，是直接做好读取功能，还是只给个二次开发的接口，这二者是完全不同的

比如下面这些常见的非关系数据源，提供直接能连才方便。

如果只是给个二次开发接口也算，那理论上就没什么不能支持的数据源了。然则，如果一切都要自己再二次开发，那买报表工具何用？

txt，xls，xlsx，csv 文件做为数据源支持情况

txt，xls，xlsx，csv 文件做为数据源，大部分国产的都允许，有些开源和免费的不行

但是你的读取方式是啥的，提供流式读取了吗？

如果不是，那大数据量极有可能卡死，怎么解决？

报表模型

分组交叉列表简单报表怎么验证

什么？？？？这么简单的功能也是坑？？？？

对，是

坑是啥，是不要被列表误导去验证这些大家都支持的，在简单报表身上都不用浪费时间，都支持！！！！！

如果哪个报表工具做不了这个，就没资格出来混了，敢拿出来溜的，这种事都不必再问了。就象你没必要去确认一辆车是不是有轮子

是不是支持复杂报表

然而，复杂的报表却不是任何报表工具都支持，或者能支持得比较好的。复杂报表的总数也许不多，但占用的开发工作量会是大头中的大头，一两个报表就可能把整个项目组给憋死。

那么，什么报表才算复杂的呢？

我们来挑几个中国报表中常见的复杂表样，抛砖引玉，只是为了唤醒大家这个意识，带着这些复杂的，再想想自己有哪些复杂的，让厂商去看是否能做出来，以及如何做出来。后一条非常重要，毕竟硬编码时什么都能做出来，但这是不是您想要的结果呢？

多源分片关联：

特殊分组、其他分组：

跨行组计算、同期比、排名

特殊分页，补空行：

每页得有表头表位，中间固定 7 行明细，不足的补空行

特殊分栏：

以上挑选的几个只是作为示例，中国式复杂报表也完全不至于这些，选型的时候记得先找出自己项目中最难的报表去找厂商看就是了

如果还想了解更多复杂报表还有哪些以及到底复杂在哪里，可以看这个帖子

中国式复杂报表复杂在哪里

呈现输出

图形种类是否全

不用考查

很多人喜欢把这个列一大堆，纯属多余。常见图形对任何成熟报表工具全都支持

而且还有很多开源图形包，要啥有啥；太特殊的那是真没有，也是到处都没有，只能自己做

是否支持第三方的统计图，以及是否可以自定义的统计图，才应该是考察重点

集成第三方统计图组件，如 echarts，D3 等，并可导出打印

这个是必须有的功能

为什么必须有？因为第三方的更漂亮 全面 简单，而且还不要钱！！比如 echarts，使用范围非常的广，很多工程师都喜欢也都用的很熟练

这个功能有两个要点要验证：

`1）是否内置支持，而不是开放接口

2）是否可以导出打印，图表不是光看就可以的 `（这点可以就卡掉一部分厂商）

三种打印方式：applet、flash、pdf

3 种方式必须都支持才可以，因为很多浏览器已经不支持 applet 打印了，用户也需要根据项目浏览器要求来实际验证才可以，比如想用 chrome 浏览器，又想用 applet 打印，那就不行了

导出功能

普通的 Excel、Word、PDF 导出

对于网格式工具其实不需要考察，都支持，而且支持的都挺好，真正的做到了所见即所得

控件式的稍微差一些，遇到格式复杂的报表，导出可能会有格式紊乱，失真的情况

特殊一些的导出需求，才是验证的重点

比如近年来比较常见的 Word 报告式报表，这样的报表有几个特点

1 篇幅比较长

2 格式要求严格，各种缩进，对齐，间隔，分页，特殊字体都一点不能差

3 文字基本是固定的，但是表格的数据是实时的

就像上面这个，整个报告会有几十页，如果按照之前传统的办法，在设计器中硬排版，然后导出成 Word，那会非常的费劲，而且导出后的 Word 基本上格式都会有问题，即使后面再怎么微调，也做不到完美

这个其实和在 Excel 中排版一个 Word 文档是一样的道理，Excel 和设计器都不擅长大段文本的排版，它们擅长的是图表

那怎么解决？

如果能同时把 Word 的排版优势和设计器实时图表的优势利用起来，才是好的解决办法，可以在 Word 中先做好文字的排版，然后空出需要实时数据图和表的地方，由报表工具动态的生成实时图表然后插入到 Word 中

所以必须有这种能把图表动态插入到word模板中的能力才能更好的解决word报告式报表的需求，这点是必须拿来专门去问问各厂商的

对这个技术感兴趣的，可以看下这个帖子

怎样自动把报表插入到 word 文档中

大屏 DashBaord

大屏现在很火，很多项目都需要做大屏，那到底报表工具和是个什么关系呢，有没有一些厂商说的那么神奇，买个工具就能轻松做大屏呢？

确实，如果是简单的大屏，在 PC 上显示的，基本上是所有国内报表产品都直接支持的，工程师用报表就可以直接做出来，比如上面这个，就是工程师自己用报表自带的 echarts 统计图做出来的

因为用户的需求强劲，有些厂商会把做大屏专门弄成一个单独收费的模块，但其实这玩意儿并没有增加多少专门的内容，就是常规报表工具再加点布局功能，值不了多少钱

复杂的大屏，在专业 LED 大屏幕上显示的，有的超长，有的很高，因为屏幕分辨率特殊，需求特殊，基本上都是得定制开发的，相当于一个小型的项目实施交付了，这时候，任何所谓大屏模块都没多少用武之地的，那些号称万能的模板适应不了不同的分辨率，全部都得美工手动设计，然后工程师协助完成

所以，不要相信有专门做大屏的工具，没必有专门花钱买，这东西，简单情况报表工具直接就能做，复杂的，也全部是手工定制来对付

移动端该如何支持？

这也是近年的一个热点，报表纷纷上了移动端，似乎对报表工具也提出了新要求

其实，这是个伪需求。因为现在移动端的呈现都是用 HTML5，只要支持 H5 的报表工具都自然适应移动端，而近 20 年来的报表工具都是在 WEB 机制的，也天生就支持 HTML，根本就不存在所谓专门的移动报表功能

一定要考查，也就是一点点分辨率自适应的能力（手机分辨率种类多，还会横屏竖屏），少得可怜，和大屏工具类似，都值不了啥钱

还有一个常常被提出来的指标是有没有成型的 APP，这还是个伪需求。

从两方面来看：

一：项目需要 APP，如果自己已经做了，那你还要另外一个 APP 干嘛？

二：项目需要 APP，自己还没做，那报表厂商给我们的的 APP 能满足需求吗？

满足不了，厂商自带 APP 中的用户管理和功能组织和我们的期望几乎不可能适应。那么，能提供源码给我们改造吗？或者报表厂商能给我们定制开发吗？

答案基本上都是不能满足需求，不能提供源码，不提供定制开发，那你要这个 APP 又有什么用，到时候还是得自己动手

所以，是否提供app，不应该成为一个评测项，只要是报表能发布成H5的就可以

集成部署

集成还是独立？

这个是容易被忽视的一点，许多使用了国外大牌产品的用户，最后经常被集成问题折磨得死去活来，甚至有的 Linux 都不支持，还得专门摆个 Windows 配合工作。

所以选型的时候就得问清楚自己

1. 我们有没有系统？

2. 是要买个能集成到系统中的报表，还是要弄两套系统？

3. 我们的系统什么架构，语言，能集成什么样的报表

想清楚了，再带着结论去选

至于集成还是独立，这里也简单说一下各自的优缺点

无缝嵌入式集成

方便项目管理，报表作为整个系统的一部分，统一使用用户系统的权限，流程等

大部分 java 项目，都愿意报表工具可以无缝集成

 

不能无缝集成，那就只能独立部署，然后一般是通过远程 web 访问来调用

独立部署也有一定的好处，可以把报表和应用分离，互不干扰

但更多的是不便之处

要管理两个应用 两个服务器

要考虑调用的安全性，或者单点登录

报表支持热加载

大部分厂商都可以做到报表热加载了

如果做不到，那就会有大问题，谁的生产机也不可能会让频繁重启

但是如果报表中用到了程序数据源，这个就多半做不到热加载了

现在有一些厂商有数据中间层，把数据源计算做成解释执行的脚本，可以做到热加载。 20% 困难的报表都会用到程序数据源

带有计算层的报表架构，其实和现在的数据中台的概念差不多

对集群的支持

在 WebServer 的帮助下，几乎所有应用都可以部署到集群上的，报表也不例外。但这只是初级阶段

对于报表来讲，真地要支持集群，还得有集群缓存同步的本事才行

访问 A 节点计算完的报表，再通过 B 节点查看就不用再算了，缓存已经同步，直接用就可以了

如果没有缓存同步，那跳转了节点就得重新算，性能会损失很多；这个所谓的集群就不是个整体，只是一堆独立机器的集合而已

安全问题

安全很重要，然而大部分情况却不用考查

因为，报表作为中间件产品，要嵌入到用户系统中，将被用户应用藏在里面或挡在后面

大部分安全问题，就该由主应用系统来负责了，报表工具不用管，也管不了

但是，注意但是，有一个很重要的安全问题，却必须是在报表工具层面解决，那就是SQL植入。

报表需要提供参数，而普通的参数查询，SQL 是固定的，基本无风险

但报表会提供通用查询功能，一般是使用 SQL 语句替换来实现的，这样带来了灵活性，但同时就有可能出现 SQL 植入的风险，泄露数据库信息。有个别厂商还甚至总是使用 SQL 替换的方式来处理普通参数查询。而报表开发人员的数据安全意识和技能一般都不会很高，很可能造成恶劣的后果，所以必须提前做好防范

至于什么是 SQL 植入风险及如何防范的详细信息，可以参考这篇文章

报表的 SQL 植入风险及规避方法

性能与容量

分析性能和容量应该如何验证之前，我们先看两种不专业的验证说法

两种不专业的说法

• 我们可以支撑多大多大数据量

• 千万数据几秒可以响应

不说场景，只说性能是不负责任的。多大数据量是和内存相关的，几秒能响应则相关的因素就更多，比如数据库速度、CPU 性能等。

所以千万不要被这些话述蒙蔽，也不要问这样的问题！！！

对性能知识感兴趣的可以看看下面的几篇文章，看完以后会对数据的性能问题产生一个更科学的认识

1T 数据到底有多大？

最简单的大数据性能估算方法

问产品支持多大数据量为什么不专业

然后我们再来看报表工具的性能和容量，

在有报表参与的数据分析项目生命周期中，对报表性能的理解误区，是容易强调报表工具的性能，其实报表性能的主要问题在数据源，报表工具本身的性能是次要的

数据源的性能

大部分的性能问题，都出在数据源上，也就是数据准备阶段！！！！但这时候考查报表工具的性能并没有意义

为什么？

因为这个时候的性能问题多出现在下面的环节

• 数据量太大，不会异步加载

• jdbc 读取慢

• 计算太复杂，需要复杂 sql 或者长存储过程

这些环节其实并没有报表工具参与，不该归罪于报表厂商，因为没有报表时候它们本身也慢

所以这点上，要问问厂商是否有协助计算的工具和方法，把数据准备阶段的性能提升上来，如果有，那这点上可以给厂商加分，性能问题可不是小问题，也不是谁都能做好的

报表本身的性能

少部分情况下的性能问题，才会体现报表本身的计算性能，那怎样才能测出纯报表的性能？

那就要抛开数据准备的时间，单独统计报表运算的时间了

可以用下面的两个例子来测试对比看看哪家的工具计算能力更强了，这两个更能体现出报表工具本身做计算和渲染的能力

• 多数据集关联的复杂报表

• 带部分明细的分组汇总表

 

这类报表需要由报表工具实现分组和关联对齐的动作，就会考查出报表本身的计算性能。

除了性能，还有容量

大数据量报表

报表中，最能代表容量问题的，就是大数据量的报表了，很多行业，都会有展现明细数据的要求，比如电信行业月底要看本月的全部充值记录，银行业要看当月交易记录清单，数据量会达到百万甚至千万级别

千万级别的数据，如果等全部取出算完再呈现，需要很长时间，没有人可以接受这么恶劣的用户体验，而且还有另外一个限制因素，那就是服务器的内存是有限的，一次装不下这么多数据，都得溢出，所以大部分的厂商都会想到用数据库的分页技术

但是数据库分页是有如下局限性的

也有厂商通过游标取数方式解决，但是游标是一个单向操作，只能向后翻页，不能向前翻页，也不是一个完美的方法

另外各种数据库分页的实现方式不同，每种写法和对应的数据源都是强耦合的，万一换了数据源，那还得重新来一遍

更先进的方法应该是能解决上面的这些问题才行的，具体怎么做，可以参考

海量清单与分组报表的实现

所以对于大数据量报表的验证重点就应该是：问问厂商是怎么处理的，如果是数据库分页机制，那上面的4个问题他们怎么解决？有没有更先进的方式？

BI 自助报表

自助报表不是万能的！！！

首先就必须明确这一点，BI 不是万能的，不是上了一套 BI 信息系统，就能覆盖自己的数据分析需求了，完全不能！

目前市面上的 BI，多维分析，自助报表，都做不了复杂的报表

比如上面提到的中国式复杂报表，就必须得用固定报表工具来做

所以完整的数据分析系统，数据可视化项目，必然是BI+固定报表一起的

然后我们再继续看 BI 选型的一些重点事项

常规的，经典的分析动作 都不用考察，做不了的不配叫 BI

重点要看的是这几方面

支持排名、占比、环比、同比等指标计算

除了一些经典分析动作外，排名，占比这些分析也是常见的分析，但是有些 BI 软件是不具备这个能力的，去实际问问就可以了

环比与同比

如何解决多表关联查询

这个其实是 BI 的通病，CUBE 是个单表，原始数据是多表，需要 JOIN 生成好

如果有漏项，就得重新 JOIN

于是，很多 BI 产品只支持大宽表的后台，这确实是大家常用来对付这件事的手段。但灵活性很差，经常需要技术人员重新 JOIN 建模。

也有些自助报表产品提供有让业务用户做 JOIN 的功能，那一定要试试，感受一下您的业务人员能不能理解得了。如果不行，最后麻烦事还是回到 IT 部门，也还是大宽表

简单几个表关联并不困难，无法考查出效果。要重点针对有同维多关联或自关联的情况

拿下面这种数据结构去试吧，看看业务人员会不会晕，能不能用界面把正确的 JOIN 给拼出来

其实，有些厂商是真正动了脑筋去解决这个难题的

把数据结构呈现成树状就能解决这个问题，让业务人员可理解的方式拼出正确的JOIN

是否可被集成，是否提供源码供改造

选 BI 之前，要先想一想，是需要一个单独的BI，还是需要把自助报表功能嵌入到自己的页面中？

如果要集成，那就要考查自助报表是不是可集成，能不能被改造了

很不幸，大部分厂商提供的产品都无法被集成，也不允许用户自己改造

因为自助报表功能需要元数据支持，是在一个完整应用系统内的东西，很难将这一个功能集成到别的应用中了

不能被集成，又不给源码，那就必须得让厂商给定制了，直到做成自己想要的样子才能放手，否则厂商不给做，自己又开发不了，那就不是尴尬的事情了

有兴趣可以去看看那些实施了国外 BI 的用户，部门级使用问题不大，业务用户也常常会叫好。但是，如果想集成进企业门户体系的话，那去问问当初的实施商经历过的痛苦吧

报表平台

大部分的软件开发商不需要报表厂商提供平台

为啥

因为软件开发商就是做系统的，做平台的，你又给我一个平台干吗？而且你给我的大概率也没有我的行业色彩，不合我用

他们欠缺的是一个性价比高，能替他们节省报表开发工作量和软件成本的中间件

但终端用户，或者有些想急着上马来不及搞开发的软件开发商，是有可能需要一个现成平台的，这倒没毛病，问题在于：能不能让我进一步定制开发，甚至是不是开源

那些所谓的用户组织、权限、调度这些功能统统其实不用考察，因为只要喊报表平台，这些功能一定有

而且这些东西和应用环境，使用场景密切相关，肯定不会全适合，到了现场反正还得改，得去完善，所以，还不如问问是不是开源，或者是不是提供定制修改的服务？要收多少钱？

填写采集

输入控件

控件可以协助用户快速准确的录入数据，比如说下拉日历，下拉树，复选框这些

这些控件怎么考察，种类要多要全？

其实不用考察，号称支持填报的产品都会提供，各种下拉控件，复选框等

但是，某些涉及较大数据量的输入控件的性能，是需要考察的。

比如一些下拉框，下拉树，会涉及非常多的选择项，一般要提供异步加载的能力，否则就把界面卡死了

Excel 导入相关

导入 Excel 填报，

1 是可以把历史数据导入，免去手动输入的工作量，2 是可以很好的支持离线填报场景，不方便在线填，那就生成一个 Excel 模板去填，填完后上传就可以。这里要考查的是能够用填报模板生成带有校验或自动计算的 Excel，也能把填后的 Excel 中的数据填进填报模板，而不需要为每种 Excel 写段代码

但是很多厂商目前其实只能支持最简单的一行一行的标准格式的Excel来填报，稍微复杂一些的，就不支持了，比如下面这个表样

能不能和填报模板对应起来，不写代码就能正确采集数据入库？

就拿着这个表样去问厂家吧，看看能不能基本不写代码就搞定。支持的真没几个，几个老牌国产的还差不多

业务人员自定义填报

有些时候，业务人员希望能自己画个表样就安排下级机构填写，这功能做得到吗？

数据填写不是目的，填写上来的数据还要再分析统计，而分析统计就需要把填写的数据变成结构化数据写入数据库，否则谁也不会对着一团 Excel 文件做统计。

那么，业务人员有能力把表格转换成合理的数据结构吗？

直接用一个表样来说吧

同样的，简单的所有厂商都会，表样一难就做不了了，上面这个表样，入库时必然会对应多个数据表，还有主外键关联！你想业务人员能自己造出数据结构吗？

造不出来，那就还得技术去搞，就不能叫业务填报了

但好的工具，只要能画出表样就可以，工具就能自动构造好数据结构

所以真正能把这样有业务意义的复杂表样让业务人员自己画出来就填的厂商，并且填完的东西能够结构化后再统计，才算是真的做到了业务填报

总结
==

以上就是我们列出的常见验证重点和坑了，大家可以根据自己的项目需求，去思考有哪些是自己会遇到的，有哪些自己没想到，然后重新弄一个重点验证列表，去找厂商逐个验证了

虽然说 20 多年的报表技术早已没有什么壁垒，但也并不是所有的报表都能经的起这份重点列表的考验的

在这里，我们也替大家做一个简短的总结，方便大家能从形形色色的工具中快速的筛掉那么一大批不合格的，然后再从合格的中间，挑选真正适合自己的

国外的基本都不行

功能严重欠缺，复杂展现、填报做不了，使用繁琐，浪费的工作量够买好几套国产工具了。冲着开源免费省钱去的，基本上都被搞的焦头烂额了，去问问老项目经理们就明白了

国产的几家大的老的都行

报表工具，很可能是企业级软件中仅有的、国产货品质远远超过国外货的领域了。国内的几家，大方面找不出什么你能做而他做不了的，虽然外围延伸方向有些注重性能，有些注重美观，但确实找不出什么大的功能和使用差异，市场推广方面倒是差异很大，有的看着轰轰烈烈，有的则比较低调传统

国产的新的也大都不行

市场大了都想来分一杯羹，但是技术活还是技术活，1 得有技术，2 得有沉淀

新产品大都功能不完善，不稳定，项目上天天改 bug 换包，是要人命的，哪个 PM 敢承担这样的风险

怎么区分是不是新冒出的产品，1 问厂家什么时候开始做的，2 去他们的技术群里或者论坛，看看其他用户都问些什么问题，如果问的都是各种报错，那就肯定是不稳定，bug 多了

BI 重点是实施与服务

拖拽分析谁都行，切个片，往下钻，往上返，再旋转下，操作像极了炒土豆片，说自己做不了的，那不配叫 BI 软件

BI 分析这个行业，和传统的咨询公司有些类似，并不是有了工具就能搞好分析的，是得有人给你服务，得有人告诉你这个行业应该去分析些啥指标，有人给你分享经验，做咨询，做好实施才行的

买 BI，千万别想着买个工具就行，一定得拉着厂商或集成商给你做好后续服务才行，否则旧服务器还能卖个二手价，旧 BI 软件，可是没人要的

价格是不用说的重点

筛选出功能差不多，资质差不多的，剩下的当然就是对比价格了，这经济下行的年代，能给公司省点钱，能给项目组挤点奖金出来，是多么大的贡献呢

报表工具 10 年之前，动辄都是上十万几十万的，但现在还有一些厂商要这么高的价格就没有道理了，不管是杀生还是杀熟，都说不过去，也不知道哪个牛 X 功能点能支撑这么高的价格体系呢

附录

下面是整理的目前比较新的指标列表，因为不管怎样，大家最终还是得拿一个列表去验证的，只不过这个列表和别的不太一样，就是把本文中提到的验证重点，都加到各验证项后面了，专门做了标注和解读，拿着这个列表就可以有重点的去验证了

最新 BI 报表工具产品选型指标和验证重点

今天的文章最新BI报表工具对比选型指标及重点注意事项—BI报表工具选型的那些事分享到此就结束了，感谢您的阅读。