報表為什麼會沒完沒了？怎麼解決這個問題？

可以先想一下自己的部門或專案組是否面臨這些問題：
1. 投入很多技術力量做報表，卻還是疲於應付
2. 用了高階報表工具和敏捷 BI，卻還是不夠用
3. 技術高手用來做報表，感覺很浪費
4. 對於頻繁多變的報表需求，需要低成本應對方案

專門用於統計分析的報表業務有一個特點，就是業務穩定性非常差。在業務開展過程中會催生很多新的查詢需求，而且已實現的查詢需求還會經常變化，這就造成了沒完沒了的報表。所以經常會有這麼一段對話

報表沒完沒了是需求使然，無法規避，只能適應，而目前主要的是問題是普遍缺少一種低成本的方案來適應沒完沒了的報表。

為什麼報表開發成本一直居高不下？

我們知道，報表工具的主要作用是將報表呈現階段的開發工具化，使用報表工具可以將原本需要硬編碼的工作透過工具來提高生產效率；但報表開發的另一個階段：資料準備，卻仍然在使用原始的硬編碼方式處理，有時我們要編寫非常複雜的 SQL、儲存過程和 JAVA 程式，這樣的工作通常要依賴高水平的技術人員才能完成。

另外，採用過於原始手段會帶來報表維護困難，複雜的程式碼無論從編寫還是修改都比較困難，這樣又會加劇報表開發成本居高不下！

除了技術原因外，還有應用結構和團隊管理方面的因素也會造成報表開發的成本居高不下。在許多應用系統中，報表是耦合在其中的一些功能，而業務系統的技術環境很複雜，這就迫使報表開發人員也要熟悉這些東西，也就很難把報表開發人員和業務系統的開發人員分開，業務系統上線之後，開發人員仍然要繼續堅守開發報表，很難把這項工作轉交給客戶方的運維人員。

開發過程中的有效溝通也會影響工作量。我們經常會發現這樣的現象：業務人員提出報表需求，等技術人員做好後才發現某些概念術語的理解有誤，統計口徑不一致，結果並不是業務人員想要的，然後也只能重做，甚至反覆多次才能正確實現，嚴重浪費開發資源。

---

如何解決報表開發成本過高？如何低成本地應對沒完沒了的報表？

可以嘗試透過如下五個步驟來解決這些問題。

1. 引入報表工具

先把最容易解決的問題解決掉，透過引入專業的報表工具解放報表資料呈現階段的人力，報表工具可以完成包括中國式複雜報表在內的各種圖表呈現。選擇成熟且價效比高的工具是這個階段的主要目標。

2. 增加計算模組

引入報表工具後，解放了資料呈現階段的人力，降低了一定的成本，但佔主要部分的報表資料準備階段仍未解決。

資料準備階段的特點是：
1. 編碼困難，沒有普適的工具
2. 對人員要求高，需要高水平技術人員完成
3. 實現週期過長，難以適應多變的報表需求
4. 硬編碼耦合性高，依賴資料庫和 JAVA 都都會造成緊耦合
5. 運維過於複雜，修改維護成本提高

這時，我們需要沿著第一步的方向繼續前進，將資料準備階段也工具化。比較好的方式是
在報表工具中增加用於資料準備的計算模組，將原來使用 SQL/ 儲存過程 /JAVA 實現的資料準備演算法，全部透過計算模組完成，使得報表開發徹底工具化，簡化開發，降低成本。

計算模組的能力可以透過指令碼來實現，在指令碼中內建各種豐富的計算類庫，讓報表開發人員獨立就能完成資料準備階段的工作，從而全面接管報表的開發，而不再依賴其他專業程式設計師。

這裡尤其要注意，報表計算模組需要具備這樣一些能力。

1. 易於編碼
包含豐富的計算類庫，可以很方便地完成各類資料計算任務；必要時還能提供視覺化的編輯除錯環境進一步簡化這個階段的開發；

2. 支援熱切換
計算模組需採用解釋執行機制，這樣可以很好地和前端報表呈現模板結合在一起，報表修改後可以實時生效，無需重啟整個應用；

3. 支援多樣性資料來源
提供 RDB、NoSQL、文字、Excel、hadoop 等多樣性資料來源介面，報表直接基於多言行資料來源開發，也可以進行混合計算（如 Excel 和 RDB 的表 join）；

4. 高效能
計算模組的計算效能不能低於原來 SQL/JAVA 的計算效能，最好高於原來的實現方式。

報表開發全面工具化以後，就可以獲得更高的報表開發效率，進一步降低報表開發成本。

3. 獨立報表模組

報表開發全面工具化以後，就可以著手梳理應用結構，獨立報表模組，從而將報表模組從業務系統中解耦出來。

1. 梳理資料來源
首先梳理資料來源，將報表業務相關的資料來源都整理出來，以後的報表開發只需要和這些資料來源打交道；同時為下一步剝離報表業務做準備。

2. 剝離報表業務
將資料來源和業務應用中與報表相關的資料準備（複雜 SQL、儲存過程、中間彙總表、自定義 JAVA 類）全部轉移到報表工具中實現；同時將這些內容從資料庫和業務應用中清除，完成報表業務剝離。

3. 獨立報表模組
報表業務完全剝離後，在報表工具中實現的報表在物理上就可以獨立於資料來源和業務模組儲存，不再與業務系統和資料來源緊密耦合，完全獨立報表模組

4. 調整應用結構
獨立報表模組後，報表模組與業務模組共享資料儲存；應用系統呼叫報表模組為使用者輸出報表結果；同時解釋執行報表模組支援熱切換，即改即用，無需重啟應用。

獨立報表模組以後，報表就可以單獨修改和維護，清晰的應用結構會進一步降低報表開發成本。

4. 建設報表團隊

報表模組獨立後，建設專門的報表開發團隊，不再需要高成本應用程式設計師或 DBA 參與報表開發，進一步降低報表開發成本。

報表開發人員就無需應對紛繁複雜的應用環境，更無需關係應用架構，只需根據已有架構開發報表就可以了。半年以上工作經驗的技術人員就能勝任（其實，理工科應屆畢業生就可以了，甚至高中學歷都行）。

簡化報表開發後，還可以嘗試將持續的報表開發工作移交給客戶方的本地運維人員，這樣不僅能降低開發商的成本，還能提高對客戶的響應速度。

5. 完善溝通機制

最後就是建立有效的溝通機制，減少交流中的誤解。

一個簡單可行的辦法就是建立企業內部的報表知識庫，技術形式上搞一個論壇即可。把以前做過的報表收集到論壇上加以評註，並提供搜尋功能。

當有了新的報表需求時，可以搜尋歷史庫中是否曾經做過類似的報表（出現過相同的業務術語）。歷史報表中保留有相關程式碼或公式，而這些形式化的資訊不會有歧義，這就能幫助新的開發人員正確理解業務術語。

甚至許多報表部分還可以被直接複用，在人員變動時也可以最大限度地保證業務知識的繼承。

---

應對報表沒完沒了是一個長期的過程，是涉及技術、管理等諸多方面的綜合性事務。當這些步驟完成以後就可以全方位應對沒完沒了的報表了。

擴充套件閱讀：

一勞永逸地“解決”沒完沒了的報表開發