- 產品
- 產品解決方案
- 行業解決方案
- 案例
- 數據資產入表
- 賦能中心
- 伙伴
- 關于
時間:2022-05-13來源:青袖瀏覽數:282次
生產型報表的特點是占比很高,數據來源單一,以直接看數獲得信息為主,雖然生成的業務邏輯可能復雜,但理解數據的門檻較低,OLTP團隊更有可能做好。
很多企業的報表質量備受業務人員詬病,要么數據不準確、不一致或不及時,諸如此類困擾著數據團隊的表哥表姐,有些問題是數據團隊自己能解決的,無非是資源問題,如果老板真想解決,總是能逐步推進解決,只是一個優先級的問題。但一旦報表優化涉及到跨部門、跨系統的協同,不可控因素就會大幅增加,特別是作為下游系統的報表,受上游系統的影響太大了,有時候不是數據團隊不想解決,而是上游系統不給解決或者解決速度很慢,數據團隊為了出報表,為上游系統擦屁股的事情太多。從筆者的經驗看,報表歸屬OLAP團隊來做管理,有天然的組織缺陷,主要體現在四個方面:
第一、業務需求管理復雜對于業務部門來說,報表需求跟其它功能需求一樣,都是為了解決一個業務問題,無論是營銷問題,銷售問題或是其它問題,比如業務部門希望能有個營銷系統做精準營銷,也希望營銷后能馬上看到數據,對于業務來說,這些都屬于營銷需求的范疇。現實情況是,業務開發團隊往往只做營銷功能需求,數據管理團隊則負責營銷報表需求,一個業務人員會同時對著兩個IT團隊提需求,也許同一個事情業務還要說兩遍,一遍側重業務,一遍側重數據,而這兩個團隊獲得的信息往往還不一致,這帶來了管理成本。報表人員經常碰到的一個尷尬問題是:業務人員會對著CRM菜單上的某個指標說,能否幫忙統計下這個數據?但報表人員根本不知道這個菜單的指標對應著后臺哪張表。
第二、報表開發效率不高報表口徑跟業務開發實現有很大的關系,為了確保統計準確,報表人員不僅要拿到數據,也要了解數據的業務生成邏輯,但這些知識往往掌握在OLTP開發人員的腦子里,報表人員找開發人員咨詢口徑是常有的事,但對于OLTP開發人員來講,由于利益不相關,馬上告訴答案是情分,不說或者晚點說似乎也沒什么好指責的,特別是有時自己也要翻代碼。OLTP團隊和OLAP團隊的開發節奏也是不一致的,OLTP可能都上線了1個月了,也許報表還沒開發呢,為了在上線后能看到數據,業務人員得找OLAP團隊來臨時取數,這都是組織割裂惹的禍。
第三、數據質量難以保障數據質量是報表的生命線,做報表的經常罵上游的業務系統的數據質量太差,因為數據質量的六性(一致性、完整性、及時性、準確性、有效性和唯一性)大都跟源頭的業務系統有著千絲萬縷的關系,但上游的OLTP似乎很少去搞什么數據質量管理,下游的OLAP搞數據質量提升倒是如火如荼,無論是元數據管理,數據質量管理,數據標準管理等等,但這些活動只能解決部分的數據質量問題,但治不了上游或跨域數據質量的根。究其根本,還是組織職能的問題,OLTP團隊不會對數據質量負責,其基因里只有事務成功,即使短期內糾正了下,但馬上又會恢復原樣,現在企業數據治理的重點,就在于組織、機制及流程的重塑。
第四、數據無法有效采集傳統OLTP團隊數據驅動的意識不高,數據架構設計的時候一般不會考慮數據采集和分析需求,以前這類問題還不嚴重,但數字化時代到來后,OLTP團隊的轉型似乎也勢在必行。比如互聯網公司通過埋點來實現APP操作日志的高效采集是常規動作,但很多傳統企業做APP的時候普遍缺乏埋點經驗,等到要分析體驗的時候才發現沒有數據,但要讓OLTP團隊擁有數據意識不是那么容易,必須賦予實際的職能,報表就是很好的切入點。既然報表歸屬OLAP團隊會帶來很多問題,那么全部讓OLTP團隊管又如何呢?答案是也不太行。OLTP管理報表也有其劣勢,特別是在需要融合多源數據的情況下,這個時候,OLTP也成為了其它OLTP系統的下游,會碰到OLAP做報表時同樣的問題,那么,還不如讓OLAP繼續發揮數據倉庫做報表的優勢。那么有沒有兩全其美的方法呢?將報表分為生產型報表和分析型報表,也許我們可以找到最佳歸屬模式。生產型報表的特點是占比很高,數據來源單一,以直接看數獲得信息為主,雖然生成的業務邏輯可能復雜,但理解數據的門檻較低,OLTP團隊更有可能做好。分析型報表的特點是數據多源,集成難度較高,需要多維分析的技能,使用數據的門檻較高,適合放在OLAP實現。雖然數據質量也會受到OLTP上游的影響,但由于OLTP報表已經實現了大多的業務邏輯,因此OLAP團隊可能會輕松很多。當然OLTP去做報表會受到數據技術、歷史習慣的挑戰,但的確具有相當的合理性,數據倉庫從來不是為了做簡單的報表而生的,現在商業智能還沒怎么玩明白,報表的職能倒全部接過來了并且越做越多,似乎背離了初心。現實中我們也會拆分報表,但往往是按照技術能力、時間粒度來拆分的,比如實時的報表應該在OLTP生成,離線的報表在OLAP生成,Count的操作要在OLAP實現,Update的操作要在OLTP實現,但這些都不是業務驅動的思維,解決不了報表的深層次問題,生產型月報讓OLTP來做似乎有些奇怪,但卻是合理的。很多公司也許已經這么做了,但大量的公司,還在機械的讓OLAP團隊去做一堆單系統數據來源的報表,然后投入大量的精力去跟上游系統核對數據?,F在數字化如火如荼,數據技術一日千里,也許我們可以做出一些改變。
下一篇:數字化轉型的框架與路徑...