前言

報表工具是一個接近 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報告式報表的需求，這點是必須拿來專門去問問各廠商的

對這個技術感興趣的，可以看下這個帖子

大屏 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 效能等。

所以千萬不要被這些話述矇蔽，也不要問這樣的問題！！！

對效能知識感興趣的可以看看下面的幾篇文章，看完以後會對資料的效能問題產生一個更科學的認識

然後我們再來看報表工具的效能和容量，

在有報表參與的資料分析專案生命週期中，對報表效能的理解誤區，是容易強調報表工具的效能， 其實報表效能的主要問題在資料來源，報表工具本身的效能是次要的

資料來源的效能

大部分的效能問題，都出在資料來源上，也就是資料準備階段！！！！但這時候考查報表工具的效能並沒有意義

為什麼？

因為這個時候的效能問題多出現在下面的環節

• 資料量太大，不會非同步載入

• 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 功能點能支撐這麼高的價格體系呢

附錄

下面是整理的目前比較新的指標列表，因為不管怎樣，大家最終還是得拿一個列表去驗證的，只不過這個列表和別的不太一樣，就是把本文中提到的驗證重點，都加到各驗證項後面了，專門做了標註和解讀，拿著這個列表就可以有重點的去驗證了