前言
報表工具是一個接近 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 配合工作。
是以選型的時候就得問清楚自己
我們有沒有系統？
是要買個能內建到系統中的報表，還是要弄兩套系統？
我們的系統什麼架構，語言，能內建什麼樣的報表
想清楚了，再帶着結論去選
至于內建還是獨立，這裡也簡單說一下各自的優缺點
無縫嵌入式內建
友善項目管理，報表作為整個系統的一部分，統一使用使用者系統的權限，流程等
大部分 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 報表工具産品選型名額和驗證重點