業務上一般也有各種各樣的報表需求，做報表時我們需要清楚知道自己要甚麼數據。一般我們用的文字報表，有特定樣版，selection criteria，sorting，grouping。用Excel的角度去理解，就是select column, filter row, sorting order 及分類summary table。
為了方便用戶確認需求，第一步建議用Excel形式寫低想要的Report 「樣板」，例如需要甚麼column 資料，通常一開始時也不會想得太仔細，例如customer list, transaction record，但這個也不緊要，可以後續再優化。這一步最重要是大概訂下框架，知道需要哪些類型的資料，預算要造多少份報表。原則上，報表以內容類型為單位，切忌把不同類型的數據放在一起。
再來就是「Filtering Criteria」，包括甚麼，不包括甚麼，這裏最重要是知道Filtering Criteria 將來會不會改變，如果基本上不會變，可以直接code做得較為簡單一點，但如果可見將來都知道要改變，就要做得比較flexible，例如用parameter table 控制，這樣就不需要經常改logic。
然後是「Sorting」，基本上是optional的一步，反正用excel 都可以做得到。「Summary table」 也是差不多，對懂得使用excel pivot table 的用戶意義不大，pivot table 基本上可以做到任何形式的summary table。
確認以上各點後，記緊與用戶確認Report Frequency，是定點時間如Daily, Weekly, Monthly, Quarterly, Yearly等，還是需要adhoc real-time 出，這個按需要去做，沒有用的就不要把所有report 都做daily。還有就是Owner 及Target Recipient，每份Report 都一定要有Owner，作為開發人員，應在開發報表的量上作出適當平衡，能夠重用的盡量重用，但也要考慮將來優化的安排。另外也要為Report 起一個名稱，這個很重要，一個好名稱讓用家一看就大約知道用途，也可以在Report 下面做個remarks 上補上一些例如filtering criteria logic，用的時候會更加方便。最後別忘了給一個Report ID作識別。
對一般用戶來說用Excel來學習整報表會較容易理解，因為Excel上基本上已經把所有數據都平放出來，但系統背後儲存的數據，一般是分佈在不同的table 上，所以要讓用戶明白系統怎樣把數據整合，而不是要把數據抄貼到同一sheet上，起碼要先讓用戶認識Excel 的vlookup。
一般來說，在項目初期並不需要完全確認所有報表的需求，確認了基礎框架和數量，大約每份的內容就好，因為隨著項目的進程，過程中也會有所增減。不過要特別留意的是，用戶一般在開始階段只會想到正常需要有的報表，而根據經驗絕大部份用來做exception handling 的report都不會再初期提出，所以項目團隊宜在項目預算時留有一些buffer 空間，例如就每個模塊或用戶組，預留小量時間作特殊需求用。
不過報表也有它的limitation，業務7x24 在跑，報表某程度上是在某個時間做snapshot，到看報表時已經不是即時數據。如果機構內做PDF format 的報表就更傻，把本來是數字化的數據變回不能容易調用的Format，只有守舊派純粹想印份report 出來tick 才會這樣做，一般想用數據作進一步分析的都應該用excel format。另外也有部份人花大量時間在需求上優化報表，又要做summary table又要做graphic，希望自己用的時候只需要copy and paste。別傻了！這樣requirement 一變就要重做，而且這些用excel 做一定美觀得多，絕對不應浪費開發人員的時間。
以往報表絕大多數是直接在產品平台上做，如果機構內有很多產品平台，用戶就要適應看不同format 的report，體驗就不很好。現在的趨勢是後台透過API 提供即時數據，或批量出batch file，而前端就專門優化顯示，這樣大家可以各司其職，而且亦可更容易處理原始數據來源不同系統的問題。有好些專做output management 的平台就做得十分出色，定義好source data 的分類標籤，end-user 也可以在UI上隨意調用，亦可就report 做返version history，這樣做report 就不用寫code，快捷方便得多。
再來就是「Filtering Criteria」，包括甚麼，不包括甚麼，這裏最重要是知道Filtering Criteria 將來會不會改變，如果基本上不會變，可以直接code做得較為簡單一點，但如果可見將來都知道要改變，就要做得比較flexible，例如用parameter table 控制，這樣就不需要經常改logic。
然後是「Sorting」，基本上是optional的一步，反正用excel 都可以做得到。「Summary table」 也是差不多，對懂得使用excel pivot table 的用戶意義不大，pivot table 基本上可以做到任何形式的summary table。
確認以上各點後，記緊與用戶確認Report Frequency，是定點時間如Daily, Weekly, Monthly, Quarterly, Yearly等，還是需要adhoc real-time 出，這個按需要去做，沒有用的就不要把所有report 都做daily。還有就是Owner 及Target Recipient，每份Report 都一定要有Owner，作為開發人員，應在開發報表的量上作出適當平衡，能夠重用的盡量重用，但也要考慮將來優化的安排。另外也要為Report 起一個名稱，這個很重要，一個好名稱讓用家一看就大約知道用途，也可以在Report 下面做個remarks 上補上一些例如filtering criteria logic，用的時候會更加方便。最後別忘了給一個Report ID作識別。
對一般用戶來說用Excel來學習整報表會較容易理解，因為Excel上基本上已經把所有數據都平放出來，但系統背後儲存的數據，一般是分佈在不同的table 上，所以要讓用戶明白系統怎樣把數據整合，而不是要把數據抄貼到同一sheet上，起碼要先讓用戶認識Excel 的vlookup。
一般來說，在項目初期並不需要完全確認所有報表的需求，確認了基礎框架和數量，大約每份的內容就好，因為隨著項目的進程，過程中也會有所增減。不過要特別留意的是，用戶一般在開始階段只會想到正常需要有的報表，而根據經驗絕大部份用來做exception handling 的report都不會再初期提出，所以項目團隊宜在項目預算時留有一些buffer 空間，例如就每個模塊或用戶組，預留小量時間作特殊需求用。
不過報表也有它的limitation，業務7x24 在跑，報表某程度上是在某個時間做snapshot，到看報表時已經不是即時數據。如果機構內做PDF format 的報表就更傻，把本來是數字化的數據變回不能容易調用的Format，只有守舊派純粹想印份report 出來tick 才會這樣做，一般想用數據作進一步分析的都應該用excel format。另外也有部份人花大量時間在需求上優化報表，又要做summary table又要做graphic，希望自己用的時候只需要copy and paste。別傻了！這樣requirement 一變就要重做，而且這些用excel 做一定美觀得多，絕對不應浪費開發人員的時間。
以往報表絕大多數是直接在產品平台上做，如果機構內有很多產品平台，用戶就要適應看不同format 的report，體驗就不很好。現在的趨勢是後台透過API 提供即時數據，或批量出batch file，而前端就專門優化顯示，這樣大家可以各司其職，而且亦可更容易處理原始數據來源不同系統的問題。有好些專做output management 的平台就做得十分出色，定義好source data 的分類標籤，end-user 也可以在UI上隨意調用，亦可就report 做返version history，這樣做report 就不用寫code，快捷方便得多。
專做 reporting management 的平台的確好，可以把本身在不同 instances 或 DB 牌子 的數據結合處理。
回覆刪除我看到現在最大的挑戰是如何不影響 transactional DB 下 generate 實時 report。數據量大的話 DB replication 成本太高，data transformation 在 source side 做 (ETL) 還是先把所有 data sync 到 big data 平台 (例如 Hadoop HDFS) 做 (ELT) ，也有一些商榷之處。
這個真的要看需求而定，有很多數據其實並不需要用來做Report，例如系統內部數據，直接replicate DB 可能會有浪費。
刪除另外其實有不少Report 也不需要實時數據，真的要讓用戶也明白當中的分別，免得浪費資源。