前言

近來報表軟體、商業智慧、OLAP、資料分析等概念非常火熱，作為關鍵基礎環節的報表軟體在市場上也是層出不窮，讓人眼花繚亂，國內外的加起來細數一下，大概有二三十種之多。這些產品看起來實現的功能都差不多，那麼，應當怎樣選一款滿足自己需求的報表軟體? 在選型過程中不被廠商的宣傳和演示牽著鼻子走？

在多年的報表經營過程中，我們發現許多使用者在選擇報表軟體時會有許多認知誤區，本篇將主要針對這些問題提供一些意見和建議供參考。

一個最常見的誤區就是報表中介軟體和報表平臺分不清楚，在演示過程中被平臺類產品豐富的功能吸引，但其實需求卻是要在專案中嵌入使用的報表工具。這一方面可能為多餘的功能買單，另一方面還會帶來難以整合的問題，多餘的功能也如雞肋一般，很難發揮作用。

要想避免這個問題，首先應該弄清楚需求（敲黑板，需求，需求，需求要明確）。是用於在業務系統中做報表，還是要上跨業務系統的報表管理平臺？這兩種需求看起來都是要做報表，但其實差別卻巨大。

需求為前者時，我們要選中介軟體型報表工具。報表中介軟體的特點是報表和中介軟體，除了要有足夠強大的功能將資料以報表和統計圖的方式呈現外，還有個很重要的使命是 - 被 ~ 集 ~ 成 ~，快速被整合，為我們完善業務系統的報表模組提供便利。而當需求為後者的情況下，則需要關注報表平臺型產品。報表平臺是指提供報表、統計圖及其他 BI 元件（儀表盤、資料看板等）的組織管理、許可權控制等功能的軟體系統，重點是功能全面的系統。

在報表行業，廠商提供的產品也大體分為這兩類：以中介軟體形式提交的報表工具和以報表為中心的外圍解決方案即報表平臺。選擇報表軟體時，一定先要搞清備選產品是哪一類的，和需求目標不匹配的，做得再炫也不必考慮了。

報表工具

報表工具是細分領域“專而精”的產物，主要解決固定報表的製作。所謂固定報表，是指由技術人員預先定義好取數規則，運算邏輯的報表，後臺會有一些較複雜的運算；業務人員只在 web 端檢視或簡單的增刪改資料，不涉及報表結構的修改。固定報表是日常報表開發工作中最常用且工作量最大的報表形式。而對應的，另一種報表形式，自助報表，可由業務人員在 web 端自由拖拽指標欄位生成不預先定義好表結構的報表，它能應對一些臨時性的簡單查詢需求。這兩種形式從目標使用者到應用方式兩者都有巨大不同，在選型時一定把固定報表和自助報表分開考慮

表格佈局

目前國內主流報表工具採用的表格佈局都是類 Excel 的單元格式，其好處是繪製簡單方便。而有些早期產品以及國外產品仍採用控制元件拖拽式佈局，就很不好用，繪製帶有合併格的複雜格式報表非常繁瑣。而且，採用類 Excel 式佈局的產品一般都能匯入以前用 Excel 畫的表，也可以不失真地將報表匯出成 Excel，這都是控制元件式佈局產品很難實現的但卻非常必要的功能。

複雜報表

報表工具的主要任務就是減少開發工作量，而複雜報表是工作量的重頭。

對於報表樣式簡單，資料來源單一的簡單報表，如圖 1。幾乎所有的報表工具都可以輕鬆實現（畢竟一個成熟的工具，要是連這樣的簡單報表都搞不定，也就沒啥存在的意義了），沒有區分度。但有些報表樣式複雜，資料來源多樣，統計口徑不規則的複雜報表，就不是每家報表工具都容易做出來的了。如圖 2，用國外或開源的報表工具就很難做出來，程式碼量相當大，完全起不到減輕開發工作量的目的。相比之下，採用了非線性報表模型的國產報表工具對付複雜報表的能力要強大得多，報表工具可能是少有的幾個國產軟體遠勝國外軟體的企業軟體領域了。不過，不同產品在模型細節的支援程度並不一致，還需要針對專案中的複雜報表仔細驗證，弄不好工作程序就可能被一兩個特別麻煩的報表給卡住。重點的考察模型功能有：多源關聯分片、行稱是否對稱、跨行組的同比環比以及排名計算、重疊分組等不規則分組方案、動態分組層次等。

圖 1

圖 2

多資料來源

報表工具也應該與時俱進，支援多樣性資料來源，資訊化應用越來越廣泛了，ERP、CRM、OA、BPM 等系統各種上馬，企業資料越來越大，報表也通常需要取到多個數據庫多個數據表的資料，所以最直接也是效果最好的，就是報表工具直接支援多資料來源關聯，而不是先 ETL 做資料倉庫等工作之後再取數。

整合性

方便易用的整合性是報表工具的重要指標，也是特別容易在選型時被忽略的指標。有些報表工具（特別是國外的產品）功能很強大，獨立使用也是六六六，但在國內跟各個業務系統整合的整體氛圍下就水土不服，因為缺失整合性。方便易用的整合性要求報表工具能對應用程式提供友好全面的介面，方便使用者與各業務系統無縫對接。能夠適應各種環境，能以類庫方式完全整合到應用系統中。這樣不僅可以提高報表獲取資料時與應用系統資料互動的效能，還可以利用伺服器的負載均衡等能力提升使用者體驗。

開放性

靈活的開放性才能適應使用者更多特殊的需求，不管是整合商還是終端使用者都可以通過豐富的 API 介面，全面地對報表應用進行各種操作，以需要的方式靈活地使用報表。滿足使用者各種個性化需求的自定義。

效能與容量

決定報表工具生死的往往是效能和容量指標。隨著大資料時代的到來，選擇報表工具時，效能指標越來越被使用者所關注。網路，報表層等都可能成為效能瓶頸。而一款好的報表工具應該儘量繞開可以避免的瓶頸，如報表層就有很大的優化空間。對於報表內常用的多資料來源對齊，排名等採用更高效能的 Hash 演算法。報表提供快取機制，包括模板快取、結果快取、分頁快取等多種方式，提升報表伺服器效能。提供叢集快取同步機制，實現負載均衡的伺服器之間跳轉訪問時的快取自動同步。

移動端

現在，越來越多的使用者想在移動端隨時隨地檢視企業報表，第一時間掌握企業動態。他們往往是拿來主義，要求報表中介軟體廠商提供完整的移動端 APP 供他們直接使用。但其實這是一個誤區，對於移動端 APP 往往是由系統整合商開發並在提供給使用者時，適當的做一些客戶定製化的功能。而報表只需要具備輸出 HTML5 的能力，支援在移動端輸出即可。作為中介軟體應用時，報表工具廠商直接提供的 APP 是沒有意義的，沒有必要去考察。

美觀性

看似重要的美觀性其實跟報表工具的直接關係不大。圖表是用來直觀的展示資料，方便管理者在紛雜的資料中快速判斷出業務資料的分佈、趨勢、佔比、同比、環比等變化規律，支援管理者決策。圖表型別的數量及是否支援鑽取、聯動等功能也是評估報表工具的指標之一。美觀性對於報表當然很重要，但由於有眾多開源圖形技術，這方面的比拼就已經不再是報表工具的重點了，報表工具廠商與其花時間精力去追趕，不如直接把好的東西為我所用，這就又回到了“專而精”的話題。所以與其用美觀性衡量報表跟圖表，不如衡量報表工具對第三方圖表的整合性更實際。

價格

最後，但不是最不重要的是報表工具的價格。不過考察產品價格時要同時考察後續報表開發製作的成本，要對比實際擁有成本。比如開源的工具雖然沒有購買成本，但實現複雜報表時，背後需要付出很大的工作量，在核算成本時往往是入不敷出，實際擁有成本更高。

報表平臺

報表平臺應該包括的基本功能包括：報表資源管理、使用者管理、資料管理、許可權管理、系統外觀及報表樣式管理、定時排程任務管理以及系統監控等；移動應用，流程填報，也是報表平臺必不可少的功能；還有安全機制，執行報表平臺時不安裝外掛、不改變使用者的安全設定，這樣才對使用者是安全的。這些報表平臺的常規功能基本每家廠商都具備，使用者在考察這些內容時也很少有認知誤區，一般不會踩雷，我們就不細說了。這裡只介紹一些容易被忽略的功能點。

整合能力

不同企業，功能需求也是千差萬別的，即使功能再全面的一款報表平臺軟體，也逃不開個性化行業定製以及跟現有系統的整合。對於報表平臺的整合，主要考慮是否提供相關二次開發介面，可以修改系統風格樣式以匹配現有業務系統，是否提供多種單點登入介面，可以使用現有業務系統的組織機構許可權機制等。

可組裝性

要求平臺中的各個功能模組低耦合，可以像積木一樣隨意拆裝。 這樣“報表 + 的功能太多了，有很多我都不需要，或者我預算有限，買不起這麼多功能怎麼辦？“的顧慮就可以很愉快的解決了。

後續開發方案

報表業務有天生的不穩定性，導致報表總是沒完沒了地要修改和新增，不可能一次性做完。那麼問題來了：如果有新的報表需求或者原有報表的維護工作由誰負責？廠商？整合商？使用者？這個一定要在選型時就考慮清楚這個問題，不然很容易被專案後期維護費用驚到或者出現報表平臺不能真正用起來的情況。這裡要強調一下，不要寄希望於自助報表（後面會講到原因）。

交付方式

對於報表平臺類產品，有兩種交付方式，即產品交付和專案交付。而專案交付，定製解決方案，為平臺類產品的主要交付方式。在當下大環境下，IT 實施團隊的選型已經成為企業資訊化建設成敗的關鍵。但國內供應商不少是報表工具廠商擴大業務而形成的，產品本身還可以，但專案經驗少，管理能力弱，所以需要考察的就不僅僅是報表軟體的功能點，更多是的要考察做實施專案團隊的技術能力，相關行業經驗以及專案管理體系和質量。而國外的供應商實施能力就更弱了，可能是由於國外定製服務成本高導致的吧，在缺乏市場定製化解決方案的需求的前提下，缺乏整合性，難以適應國內需求。

自助報表

最後我們來談一下自助報表。

自助報表也是近年內特別熱門的需求，幾乎所有的報表平臺都提供有這個功能，各大廠商紛紛宣稱可以讓業務人員拖拽製表，不需要技術人員參與了。

但這裡有個巨大的誤區。目前市場上的自助報表（或互動式 BI）雖然可以在頁面上輕鬆實現鑽取、切片、旋轉、分頁、自定義指標、排序、各種基本計算（求和，求平均，最大最小值等），與此同時兼具頁面友好美觀，使用流暢等特點。但是，自助報表能夠解決的業務人員需求其實相當少，例如自助報表完全解決不了過程性計算，而大多數報表都需要過程計算來準備資料，比如報表資料模型支援多源運算就是過程計算的一種。不支援關聯查詢的自助報表，一般只能解決 10% 的業務人員需求，即使有了關聯查詢也只能解決 20% 到 30%。所以不能對自助報表的期望過高。

關聯查詢是絕大多數自助報表產品都不支援的能力。所謂關聯查詢就是需要查詢的資料不在資料庫的一張物理表中，通過某個主外來鍵關係關聯才能獲得需要的資訊，例如：查詢儲存金額在 10 萬以上的本地儲戶資訊，就需要做多個表的關聯運算。傳統自助報表不支援關聯查詢，需要事先建立邏輯或物理寬表把表間關係做死，一旦關聯需要發生變化時，只能重新建模，但這就要求有 IT 人員再次參與，業務人員的自助就失去意義了，而這個功能缺失又很可能被炫酷的介面掩蓋而被忽略。能否支援關聯查詢是是考察自助報表功能的關鍵指標。

有些報表工具也提供自助報表的能力，也可以作為報表中介軟體的功能元件被整合，這時候就要考察其可整合的能力，即也能像報表中介軟體一樣整合到其他應用系統中使用。如果有整合需求，則要重點考察這方面的能力

作者：yangcl
連結：http://c.raqsoft.com.cn/article/1534906944980?r=xiaohuihui
來源：乾學院
著作權歸作者所有。商業轉載請聯絡作者獲得授權，非商業轉載請註明出處。