報表選型除了看開發難易，還要看運維省不省心

俗話說，報表運維是個坑，有時候被客戶坑，有時候被同事坑，有時候被本身坑，坑來坑去還得本身填坑。

好比說，企業大了，業務種類就多了，這時候就不能依靠手工統計報表，企業就會採購或者開發報表系統，然而在選型時卻發現某些系統看似開發簡單，實際上不管是前期系統的穩定保障、仍是後期的系統優化，根本一塌糊塗，給咱們報表運維人挖了一個大坑；

而一旦系統上線，系統出現的全部問題就會讓咱們報表運維人來背鍋，也就成了名副其實的「背鍋俠」：ERP系統裏的報表有問題了，運維的鍋！報表系統裏的模板有問題了，運維的鍋！查看報表時沒權限了，通通是運維的鍋！

其實背鍋還不是最慘的，最慘的是若是報表出問題了，咱們就要先進行業務分析、跟用戶溝通、而後進行數據測試和修改，整個流程費時費力，把咱們的大部分時間都佔據了，根本無暇處理更深層次的需求，從而影響咱們的運維效率和水平；同時，還會形成其餘人對咱們運維團隊的不信任和懷疑，下降對咱們工做的滿意度，最後咱們的工做就變成了費力不討好。

尤爲是對於大公司而言，業務多、流程複雜、報表冗雜，對於報表系統的要求是很是高的；而對咱們報表運維人來講，一個好的報表系統不僅是要開發簡單、功能強大、靈活快捷，更重要的標準是後期運維難度。

簡單舉個例子，以前咱們公司上線ERP系統以後，通過一段時間的調試，簡單的報表開發是可以知足了，可是慢慢地咱們就發現了問題：

• 根本沒有用戶權限管理，全部報表數據就是一鍋菜，想要實現用戶的分級管理根本不可能；
• 沒辦法管理業務流程，公司的業務部門一旦多了，業務流程和關係就會變得複雜，系統又沒有辦法優化，只能給咱們帶來很大的無效工做量；
• 升級步驟及其繁瑣，根本不知道怎麼升級系統，也基本上不能實現二開；

這些問題也許在報表開發人員的眼裏並不算什麼，可是對於咱們報表運維人來講，報表系統的運維難度越大，出現的bug和問題就會越多，運維的無效工做也會徒增幾倍，以後就不得不從新進行報表選型。

那麼在進行選型時，什麼樣的報表系統運維起來才讓人省心、不被人甩鍋呢？

下面，就拿咱們如今用的FineReport報表系統爲例，從運維的角度出發，列舉一下咱們在選型報表系統的時候須要考慮的點：

一、用戶權限管理

對於系統管理者來講，報表運維的一大難點就是用戶的權限問題，也就是誰能看、誰不能看的問題：

一個報表模板作好了，就要控制誰能看這個模板，也就是用戶，有了用戶就會有登陸的概念，有了登陸就要有權限的概念，有了權限就要進行管理，讓報表模板成爲一個能夠被權限控制的數據。

然而現實狀況是不少系統都是將數據大雜燴般放到系統裏，甚至出現公司老闆與部門員工都能查看公司財務報表的狀況，毫無安全性可言！

因此咱們在選型報表工具時，必定要測試一下是否有權限管理功能，好比可否根據部門職位分配權限、根據角色分配權限、根據用戶分配權限，是否能夠實現分級權限分配、報表編輯權限、權限複用等等，以保證數據的安全性。

其中我要提一下分級權限管理，就拿FineReport舉個例子，所謂分級權限，就是指總管理員（公司領導、系統管理員等）在系統裏開啓分級受權，將一些權限進行下放，讓部門管理員（業務部門經理等）擁有分配權限的功能，而後部門管理員再將相應的權限分配給下屬（通常是普通的部門員工），實現層級的權限管理。

二、數據運轉流程的難易

什麼叫作數據運轉流程呢？簡單點說，對於企業來講，部分重要數據未經審批就提交入庫是有必定風險的，且二次校檢比較複雜，因此此時就須要咱們運維人出場了！

咱們報表運維的工做之一就是對底層工做人員的填報數據進行處理和驗證審批，而後將審批後的數據進行入庫和提交，這種簡單的工做流就是數據運轉，也就是咱們常常說的「數據上報」。

其應用原理圖以下：

看不懂不要緊，我直接拿我工做中的一個例子來講明一下：

咱們公司在全國各個地區均設有辦事處，全部辦事處按照地區分爲華東、華北、華南和華中，每月各地區銷售人員須要上報其每月的月銷售額，通過銷售總監的審批，到達領導處，領導查看全部銷售數據。

這個工做流比較，因而咱們依靠FineReport系統將其上報流程分爲了幾個節點用戶，在系統中設置好統一的報表模板，而後在報表系統添加上報流程和任務，將分好的各個節點進行分配，最後由不一樣的用戶從第一個節點開始往下操做流轉，就能夠實現多級上報了

這個功能的實現，咱們運維人就能夠對底層人員的錄入數據進行覈算、審批，只有通過審批後的數據才能提交入庫，可以大大增長報表系統的安全性和穩定性。

三、定時報表

咱們在運維報表系統的時候，常常會遇到一個問題：不少業務人員的報表是須要按期產生、定時發佈的，好比流水線上的日報、週報，而大多數狀況下他們不得不按期地作一樣的報表，這時候他們就會追問「我們的報表系統爲何不能實現定時發佈」？

因此在選型報表的時候，要注意關注報表系統能不能設置定時任務，也就是可否用服務器定時自動地按照指定好的參數執行報表，而不須要等待漫長的計算時間。

我所瞭解咱們公司的報表系統，其主要的實現過程很簡單：用戶將定時發佈的報表上傳——用戶設置定時任務，選擇發佈時間——服務器在指定時間會自動生成文件——系統將生成結果以郵件、短信等方式通知運維人——運維者進行報表彙總和整理，交給業務人員進行分析

整個過程當中咱們報表運維人幾乎沒必要每天等着，用戶能夠將作好的報表定時發佈出去，從不厭其煩的重複發佈操做中解脫，方便快捷地設置日報、月報、季報、年報等任務，不須要額外的工做。

而咱們運維人只須要等着別人提交報表就能夠了，報表系統能夠幫咱們自動完成數據彙總和整理，咱們惟一要作的就是打開手機，隨時隨地在移動端查看你須要的報表數據。

四、報表運維功能的強大與否

對咱們運維人來講，報表系統就像本身的孩子同樣，看到他健康成長（運維正常），內心充滿知足和自豪；相反的，若是他常常生病（bug頻出），咱們能夠說是寢食難安。

因此咱們要實時把握報表系統的運維信息，來保證系統健康強壯穩定的運行，但這個條件常常在報表選型時被咱們忽略，致使咱們只能摸着石頭過河，每天提心吊膽，生怕報表系統出bug。

這就體現了一個報表系統的運維功能是否強大，這一點我仍是比較佩服咱們如今使用的FR系統的，當前系統內哪些模板有問題，哪些模板有出問題的風險，系統的硬件和軟件配置是否能支撐當前實際場景，是否存在宕機的風險等等，這些相當重要的信息咱們在第一時間就可以準確掌握，保證系統的穩定運行。

除此以外，好比對內存和CPU的使用率進行實時監控和預警，一旦內存達到瓶頸就會當即報警，同時還能夠進行會話的存活、清除等，保障服務器的穩定運行。

再好比，能夠對報表系統進行智能檢測，對服務器配製、報表管理、全局屬性進行檢測，若是出現預覽模板報錯，或者工程所在磁盤剩餘空間不足等問題，系統會當即查出問題並提供建議方案。

再好比，對系統運行的各項請款進行監控分析，包括訪問統計、用戶行爲、模板熱度、性能監控、管理日誌、出錯日誌等等。

五、插件管理等附加功能

咱們都知道在報表系統中常常會用到插件，好比預覽報表、導出格式、插入地圖等等，這些都不可避免要使用web插件來實現。這還只是最簡單的應用，做爲一個合格的報表系統插件，還須要在交互性等報表高級功能方面表現良好。

好比交互式內容、支持自定義函數組織數據集、參數報表、遠程設計報表、報表批量打印、報表調度功能、數據透視功能、多層次彙總報表等等，不少報表系統在這一方面作的不好，不是不能支持，就是交互性不好，沒法知足咱們的需求。

不得不說，Finereport在這一方面作得很是好，管理員不只能夠在插件界面進行安裝、刪除、更新、禁用、啓用插件，同時還在支持報表展出和WEB高級插件功能，能夠說十分方便。

總結

報表系統的選型是一件麻煩事，它須要結合業務部門、IT部門、運維部門等多方面的綜合考量，還須要考慮企業自身的管理基礎，但每每最容易被忽視的就是運維，對咱們的系統運維工做產生極大的困難。因此在報表選型時，咱們不能只看技術開發和業務功能，更重要地是要關注報表系統的運維難度，仍是那句話：一款好的報表工具，要像FineReport同樣不只開發簡單、功能強大、靈活快捷以外，還能替咱們作到最智能的系統運維。