報表到底應該歸誰管，OLAP or 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團隊去做一堆單系統資料來源的報表，然後投入大量的精力去跟上游系統核對資料。現在數字化如火如荼，資料技術一日千里，也許我們可以做出一些改變。