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

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

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

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

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

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

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

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

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

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

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

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

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

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

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