不熟悉業務可能是部分資料治理相關廠商的明顯短板

一段時間以來，與在企業中做資訊化或者資料治理的同行們交流，發現選擇資料治理相關的廠商(以下簡稱”資料廠商“)感覺挺不容易的，一個較為突出的現象是部分廠商好像不太熟悉企業的業務，而企業做資料治理或者實施資料管理類系統雖然工作的直接物件是資料，但資料來自於業務和系統，對資料的工作其最終目的也是在業務方面體現價值，所以資料類專案必然包含深度的業務內容，而現階段所接觸的部分資料廠商在企業的業務知識方面可能是存在短板的。

資料治理等工作在很多企業中也是近幾年才被更重視起來的，那麼從資料治理角度上開展工作，對企業來說很多想法或許也不成熟，有若干空白領域，企業一是要自己努力想清楚要做什麼、做成什麼樣子、怎麼做，二也是希望有專業資料廠商協助來梳理思路和找到方法，但廠商因為不太熟悉企業的業務，導致雙方交流時，往往不能立刻明白企業說的內容，也不能給出呼應企業想法的初步建議，如果單純的聊資料治理的知識體系和軟體工具，企業不能馬上明白這些知識和工具怎樣應用才能解決資料和業務問題，於是企業就容易產生資料廠商不熟悉業務的感覺。

熟悉企業的業務確實也比較困難，因為各行各業、各種型別、各種規模的企業的業務和管理差異都非常大，即便是開展同類業務的企業，差異往往也很大，這給資料廠商熟悉企業的業務就帶來了巨大的挑戰，這是困難的基本根源之一。其中有一點或許值得關注，就是部分資料廠商也有一些企業的成功案例，但具體交流起業務時雙方往往還是找不到感覺，這是為什麼呢?

如果深入交流案例，可能會發現是案例中企業自身把很多事想得比較清楚，即案例企業的內部專家熟悉自己所在企業的業務，也具備一定的資料知識和能力，把業務需求到資料需求的轉化這個關鍵性的內容自己完成了，可以把比較清晰的資料治理需求和設計告訴資料廠商，由廠商實施落地，專案就比較成功。

那麼在這種資料專案中，相當於與業務密切相關的內容大部分是企業自己完成的，資料廠商完成的是後端具體的技術性內容，沒有足夠多的機會去深入熟悉企業的業務。一旦專案結束，企業的資料工作人員還在企業，而廠商因為只做了後端內容，還是不熟悉業務，那麼雖然有這樣一個成功的資料治理案例，但透過專案得到的成長很有限。

即便資料廠商有機會熟悉了一個專案的業務，但如果下一個專案的行業與此前專案不同，面對新的行業，資料廠商依舊會面對著陌生的業務。這也是某些行業領域內有領先的資料廠商，但跨行業的領先資料廠商卻比較少的原因之一，比如一個熟悉電商行業的資料廠商，面對能源行業的專案可能基本要重頭開始了。

成為企業的業務專家是挺不容易的，就是在企業內部，可以把自己企業的所有業務說清楚並且可以轉化為資訊化或者資料管理語言的專家也不太多(成長為專家需要在企業足夠長的時間、需要足夠多足夠大的專案實踐、需要足夠好的學習和總結、……)，更何況因專案才開始接觸企業初來乍到的外部廠商呢。

就是在與業務關係相對更密切的ERP領域，沉澱數量足夠多的資深業務專家有時也並不容易(比如部分國產系統廠商在此前和現在的生態下就不容易)，好歹ERP類的系統本身功能就體現著業務邏輯，要用就必須要知道業務，跑通軟體功能就已開始入門企業的業務了，因此熟悉企業的業務或許相對更有天然的便利性。而資料管理類系統，往往都是與業務無關的純技術支撐類的功能，就像面前擺著一大堆各式各樣的工具，但因為不懂汽車所以縱然有工具但還是不能維修汽車是類似的。

現階段從行業內以某種角度看，資料廠商因熟悉的工具不同或許可以分為兩類，一類是掌握理論工具，一類是掌握軟體工具。第一類資料廠商熟悉資料治理的理論、方法論、標準、案例，如DAMA、DGI、DCMM等，主要提供資料治理的諮詢服務(文件是強項);第二類則是資料產品廠商，有較為豐富和紮實的資料管理類軟體產品，熟悉產品和使用。但這種情況類似於是資料治理工作全過程的兩個端點，即最前端的理論和最後端的軟體，而恰恰在熟悉企業的業務方面可能都缺失了一塊，導致其能力與企業需求結合時往往會遇到困難。

綜上，因為行業和企業的各種差異，熟悉各家企業極具個性化的業務確實非常不容易，那麼對一些通用的業務內容呢?比如相對來說對企業最基本、最標準、最需要的財務資料管理領域，我談一下遇到過的兩個相關專案。

首先是幾年前經歷過的一個BI專案，當時同期實施的系統較多，因資源不足所以不容易每個系統都盯的非常細，後來BI出現了一個問題，BI上關於財務的若干分析主題跨年後資料都亂了，廠商團隊查詢問題後初步反饋是資料重複導致的，財務系統和介面都沒有變化，現象比較奇怪，於是我們親自參與問題排查，發現真正的原因是ODS層的財務記賬憑證表中沒有“年份”這個欄位，因為憑證資料來自於SAP ERP系統，而SAP ERP系統的記賬憑證是按年重新開始新的憑證編號，所以第一年憑證編號無重複，而新的一年憑證編號重新開始，在沒有年份欄位的情況下，兩年中相同編號的憑證顯得就是重複了，而且BI對應各資料層的邏輯中都沒有年份條件，所以跨年後肯定出問題。而對財務資料中最基本的記賬憑證資料，年份又是最基本的內容(對部分國產ERP系統的月份也是)，屬於財務資料的基本常識，只是因為資料廠商的工程師此前未涉及過企業的業務，無業務基礎，資料只是資料，導致設計和實現時出現了這種問題。

然後是近兩年的一個也涉及財務資料的專案，關於企業應用資料中臺，可能也屬於一言難盡的內容，本質都是資料管理的工具，只是說各種相關功能可能會以不同的身份、不同的組合出現在不同名稱的系統中(比如平臺、中臺、……)。那麼利用資料中臺的資料處理能力，可能作為整合異構財務系統中財務記賬憑證的工具，當時也接觸了幾個資料廠商的團隊，把需求與廠商工程師交流後，發現這些資料治理工程師並不知道什麼財務憑證，本身企業希望透過廠商獲得更多的思路和解決方案，但這些工程師因為不熟悉企業的業務，資料仍舊只是資料，所以，一想到要給廠商講什麼是財務記賬憑證、憑證的結構化資料是什麼樣的，當時心裡確實有點涼。

不過當時也轉而側面去了解了幾位工程師的情況，發現此前主要做的是很多ETL、資料物理模型層等等工作的，總的來說是偏技術、偏後端的，那麼不熟悉資料管理過程最前端的業務內容或許也可以理解了，畢竟技術上各個領域是細分的，都是專業的，都很有深度。那麼關於資料治理，其實整個工作鏈條是很長的，比如有做資料需求分析的、資料架構設計的、資料標準編制的、資料建模的、資料儲存的、ETL的、BI程式碼開發的，等等很多領域，雖然都是做資料治理相關工作，但具體在細分領域上差異往往還是顯著的。就像我每次強調專業化時常常舉的例子，都叫廚師，一位西餐廚師與一位川菜廚師其實是兩個概念;都叫醫生，但並不能讓牙醫去做心臟手術;同理，雖然同樣都是從事資料治理相關工作的專家，但一位資料儲存專家，其實很難去對接使用者談業務需求的。

其實還經歷過若干次與上述內容類似的情況，時不時都有些感觸。資料治理，一些領先的大企業多年前就有紮實的開展工作(一是理解資料的價值因而重視，二是願意投入大量的人員和資金，此前和現在能做到這些的企業或許也並太多)，但對大部分企業來說，也是近幾年才開始關注，相應的，因為此前需求少，所以提供資料治理服務的各類廠商之前也不是很多，面對現在有點井噴增長的資料治理專案，資料廠商的數量、規模、綜合的專業化能力也都需要同步得到發展，後續也很希望企業與廠商透過大量的實踐在資料治理領域一起成長。

成為資料治理全域專家，特別是成為熟悉企業業務的專家都需要努力，在這個過程中，或許可以從一些通用的業務內容著手，比如財務、人力資源等。