前言
報表工具是一個接近20年的產物了
但是，直到現在，在各種數據信息化的系統中，報表工具的作用，不僅沒有褪色，反而是因爲信息化需求的增大、數據的增多，以及報表工具本身迭代後越來越方便好用，使得它的使用範圍越發的廣泛了
報表選型也是一個老生常談的話題了
但是，直到現在，依然有很多項目組，很多技術人員並不知道該怎樣正確的選一個合適的報表，一個不會讓自己在項目後期掉坑裏的報表
本文全文9990字，大概需要10-20分鐘閱讀，旨在把這麼多年總結下來的一些選型重點注意事項和驗證技巧分享給需要做報表選型的技術同仁們，讓我們選型變的更有重點，輕鬆又有保障
如果有想偷懶同學，也可以直接跳到文章尾部去看結論，也有完整的選型指標，和對應的重點注意事項表格供大家下載使用
常規選型的誤區
常規的選型基本都是做一個功能需求列表（也可能從網上搜來），然後去找廠商應答，形式沒問題，但很多需求列表卻會有很多誤區：
- 陳年老列表，體現不出當前的新技術，有些指標還可能是錯的
- 沒有錯但也沒有用的廢話列表，任何廠商都可以應答全部支持
- 沒有想到重點要驗證什麼的列表，也都會被應答成全部支持，沒有區分度
- 廠家散佈在網絡中的釣魚列表，有些廠商的還算中肯，但也有些廠商會把把一些看似有用實則無用的所謂獨有功能說成重點去誤導選型
這是一個常規選型表開頭的小部分，在這麼短短几行中就能出現兩個典型的誤區（圖中標出的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植入風險及如何防範的詳細信息，可以參考這篇文章
性能與容量
分析性能和容量應該如何驗證之前，我們先看兩種不專業的驗證說法
兩種不專業的說法
- 我們可以支撐多大多大數據量
- 千萬數據幾秒可以響應
不說場景，只說性能是不負責任的。多大數據量是和內存相關的，幾秒能響應則相關的因素就更多，比如數據庫速度、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功能點能支撐這麼高的價格體系呢
附錄
下面是整理的目前比較新的指標列表，因爲不管怎樣，大家最終還是得拿一個列表去驗證的，只不過這個列表和別的不太一樣，就是把本文中提到的驗證重點，都加到各驗證項後面了，專門做了標註和解讀，拿着這個列表就可以有重點的去驗證了