對于主數據，最初的定義為：表示業務實體對象的基準數據以及其被引用的關聯屬性信息。主數據的概念引入中國并加以調整改善，更加通俗易懂。通俗化后的主數據定義為：描述某一業務實體對象時，基礎數據（靜態或相對靜態的數據）中被兩個及兩個以上業務系統共同使用的屬性字段。此定義很快被證明了其的合理性，短期內被各廠家推廣使用，這也就是目前國內主數據廠商對主數據的統一標準定義。

但是，隨著主數據管理平臺的逐漸被推廣使用，一連串的問題就來了，這也導致了目前很多企業實施主數據管理項目后，數據質量重蹈覆轍的悲劇。

1．主數據的動態性問題凸顯
隨著企業業務系統的新增和更換，原來被主數據廠商咨詢出來的主數據已經無法滿足新的業務系統的上線需求，需要重新進行主數據的擴充識別和相關模型、流程等的變更操作，從而造成了主數據管理平臺后期運維成本的居高不下，嚴重違背了實施主數據管理平臺的初衷。

甚至目前很多主數據項目的招標現場招標方就非常嚴肅地問投標方“你們的主數據平臺未來調整模型中的某個屬性字段需要多久？”，仔細想想這個問題還真的很嚴肅，因為未來這個調整是會頻繁發生的，為了應標很多人不負責任的脫口而出 “1小時”、“2小時”等等，難道我們加一個屬性字段不需要確定它的元數據標準？不需要補充它的歷史取值？不需要找業務部門的“大爺們”討論、協商？?

其實，為什么我們老是想盡一切辦法去識別主數據呢？難道就是為了讓我們的主數據管理員未來別閑呆著？難道就是因為老外提出了這個理念就無法動搖？數據治理核心要解決的是數據質量、安全、服務以及相關的環境等，費了九牛+二虎之力識別出了所謂的主數據，沒多久因為業務系統的變化出現了倒逼主數據必須變化的情況，何苦呢！干嗎要自己給自己設置障礙？干嗎非要先去貼標簽再去解決數據質量、數據安全等問題？

負責任地講，在數據治理行業，外企不值得我們去迷信。

某核電集團，2013年實施了某國外MDM（Master Data Management）平臺，2014年中期，該企業領導發現主數據管理員在不斷地調整花了幾百萬費用制定的主數據模型標準，一怒之下徹查原因，最終發現是由于業務系統的擴充、變更造成的。

其實主數據管理員也很委屈，不改變主數據模型標準，數據就無法順利分發出去，改變模型還要自己去琢磨如何識別主數據字段，識別出來后還要確認元數據標準等，一連串的問題忙得不可開交，最后還被領導痛罵，想想就挺可憐的。

這樣的情況不是個例，隨著大家對主數據的概念認識得越來越清晰，對主數據管理的理解也會越來越深刻，尤其是當真正走到主數據項目后更應該能體會到主數據動態性造成的“麻煩”會有多大。

2．主數據管理無法滿足業務場景需求
主數據的核心管理理念就是實現數據的“單一視圖”，是共享性數據的統稱。但是，要管理業務場景的數據（業務場景數據：指針對某一業務實體對象在特定業務場景下的描述信息，不包含主數據部分，如某產品在不同生產線的描述，以及針對不同區域的價格描述等），就是增加了業務場景視角的數據管理。

因此業務場景數據管理和主數據管理有是兩個層面的問題，但是從數據治理的角度出發，如果我們無法涉及業務場景數據，可能就無法很好的保證業務場景的數據對現有業務以及未來數據中心的有效支撐。目前很多實施了傳統主數據管理平臺的企業只是在頂層管理解決了部分數據問題，開始數據中心等的建設時又被迫重新開始數據的全面治理工作。

某電工集團，2016年開啟了主數據管理項目的一期工作（頂層管理型主數據的治理），選型了國內某主數據管理平臺，2017年開啟二期項目實施后突然發現此平臺架構根本無法滿足業務部門的業務場景數據的管理要求，甲乙雙方還因此拍了桌子，差點對簿公堂，無奈項目二期暫停。2018年中甲方領導特意來乙方公司探討此問題的解決方案，2018年底我們也特意去了一趟甲方現場再次溝通，無奈平臺無法替換，最終只能不了了之。

某石化控股集團，2016實施了國內某主數據管理平臺，2017年該集團的二級公司就提出因業務管理的需要獨立進行業務場景的主數據管理。

某煤集團，2011年實施了國內某主數據管理平臺，2013年開始二級公司陸續因業務場景數據治理的需要獨立開展主數據管理項目。

這樣的情況不是個例，尤其是隨著企業對數據管理的要求越來越高，業務場景越來越多樣化，主數據管理無法滿足業務場景導致的數據治理障礙會越來越明顯，推倒重來或者亡羊補牢會成為一種常態。

3．主數據管理項目實施后體系運維難以保障
數據管理體系的運維（如制度的重修、流程的調整、新的數據類型或類別的模型新增等）是項目后運維管理的兩大任務之一（另外一個是數據質量的日常監測）。

企業都很重視數據管理的運維工作，不少企業甚至專門設置了數據管理組織，配備了相關人員等，但是目前實際管理中大部分還是以主數據管理員為數據管理工作的核心，包括平臺的維護，工作的協調等，所謂的數據管理組織根本就沒有發揮出應有的功效。

舉個例子，企業實施主數據管理項目后進入運維階段，當需要增加某一新類型的數據時，傳統的方式的是讓大家（數據管理組織成員）坐下來直接討論該數據應該如何分類，模型如何制定等，或者是主數據管理員提出具體建議提交會議后再討論，或者說通過相關系統線上提交領導審核然后定稿，以上所有過程都似乎是非常嚴謹、合理，但是我們有沒有想過這里討論的合理性，因為領導根本不了解同類相關數據的分類、建模思路，領導依據什么來和咱們討論，依據什么線下或線上給我們審核定稿？為了慎重起見領導一定會擱置等待，直到主數據管理員參考業務人員建議提出更加合理的解釋。當然也會出現領導被主數據管理員以阻礙業務進度為“要挾”草草審核定稿。

有人會說，領導不知道沒關系，主數據管理員是從項目實施跟過來的，肯定了解當時的思路，肯定能直接說服領導，如果主數據管理員如果是新來的怎么辦？如果主數據管理員把思路忘了怎么辦？主數據管理員又能依據什么來制定出合理的模型呢？答案只能是“拍腦袋”，如果這樣我們得給咱們的主數據管理員配上頭盔才行。

綜上所述，這樣就出現了項目后的數據運維管理和項目中主數據管理體系咨詢的思路是脫節的狀態，導致數據運維管理階段根本無法延續當時的思路。

某化工集團，2015年實施某國內MDM平臺，項目順利驗收，2016年底集團擴展業務，主數據管理員面對需要新增的一些數據模型一籌莫展，組織召開數據管理組織會議討論時各業務領導成員以出差、忙等各種理由拒絕參加。2017年增加了線上標準審核機制，甚至還用上了移動審批，各業務領導迫于考核的壓力草草審核定稿，其實最終還是主數據管理員和相關業務人員討論后的結果，所謂的數據管理組織也就成了一個擺設。導致主數據管理體系逐漸脫離該有的擴展思路，1-2年后最終成為“體系兩層皮”（運維前中運維后）。

這樣的情況不是個例，應該在每家企業中都有存在，其實這不是企業領導的不作為，是我們太理想化，設置的模式太不切合實際。

4．主數據管理項目實施后數據質量重蹈覆轍
自從主數據管理平臺面世后，很多人就把解決數據質量的問題寄希望于此了——通過制定標準的主數據模型以及全面的驗證機制實現數據采集（如錄入等）環節的統一、規范，再加上理想化的多級次的數據質量審核，實在是太Perfect（完美）。

貌似合情合理，實則忽略了幾個核心的問題，純技術的驗證手段真的可以發現所有的質量問題嗎？如果寫了錯別字怎么辦？所謂的同名詞庫等手段也只能是判斷曾經發生過的且預置在平臺內的錯別字，以往從沒有出現過的錯別字出現了怎么辦？另外，諸如數據放錯類別等問題也是主數據管理平臺無法解決的問題。

有人說，沒關系這樣的情況的不會很多的，并且我們還有嚴格的審核機制，審核真的管用嗎？領導真的有時間審核嗎？領導真的對所有數據的質量了解嗎？多年來多家企業驗證了審核只是一種擺設，只是一種行政的知會，對數據質量的把關幾乎沒有太大用處。這些問題似乎我們都可以不在乎，但時間久了就造成了數據質量的重蹈覆轍。

某能源集團，2012年實施某國內MDM平臺，項目順利驗收，甲方也花了近半年的時間進行了歷史數據質量的全面清洗，且分子公司及集團兩級審核機制，集團有6個人分別對不同大類的物資數據進行審核，但是2015年初突然發現60多萬條的物料數據有20多萬條出現了不同形式的數據質量問題（包括名稱叫法的不一致、各種錯別字、數據描述的不完整等），導致目前主數據管理平臺淪為了只是為ERP等業務系統的賦碼功能（生成編碼并傳給業務系統），SAP ERP等業務系統中一物多碼、一碼多物問題大量重現，讓整個集團上上下下真正體驗到了“回到解放前”（回到主數據管理項目前）的感覺。

這樣的情況當然也不是個例，曾經聽到有甲方說“問題在于我們自己沒有管理好，是我們的人不行，不能怪主數據管理平臺”，不知這是甲方的無奈還是乙方的無能！