1.2 主數據管理的局限

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

但是，隨著主數據管理平臺的逐漸推廣和使用，一連串的問題就出現了，這也導致了目前很多企業實施主數據管理項目后，數據質量并未顯著改善。

1.2.1 主數據的動態性問題

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

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

其實，為什么我們老是想盡一切辦法去識別主數據呢？難道就是為了讓我們的主數據管理員未來別閑待著？數據治理的核心是要解決數據質量、安全、服務以及相關的環境等問題，費了九牛二虎之力識別出了所謂的主數據，沒過多久因為業務系統的變化出現了倒逼主數據必須改變的情況，這不是相當于給自己設置障礙？必須要認識到主數據是動態的這一特性。

某核電集團，2013年實施了某國外廠商的MDM（Master Data Management，主數據管理）平臺，2014年中期，該企業領導發現主數據管理員在不斷地調整花了幾百萬元費用制定的主數據模型標準，要知道此時平臺上線才近1年時間，不該出現這種狀況。經調查發現，是由于業務系統的擴充和變更造成的。不改變主數據模型標準，數據就無法順利分發出去；改變模型就要管理員自己去琢磨如何識別主數據字段，識別出來后還要確認元數據標準等，一連串的問題。

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

1.2.2 主數據管理無法滿足業務場景需求

主數據的核心管理理念就是實現數據的“單一視圖”，是共享性數據的統稱。但是，要管理業務場景的數據（業務場景數據指針對某一業務實體對象在特定業務場景下的描述信息，不包含主數據部分，如某產品在不同生產線的描述，以及針對不同區域的價格描述等）就會增加業務場景視角的數據管理，因此業務場景數據管理和主數據管理是兩個層面的問題。但是從數據治理的角度出發，如果我們無法管控業務場景數據，就可能無法很好地保證業務場景的數據對現有業務以及未來數據中心的有效支撐。

某電工集團，2016年開啟了主數據管理項目的一期工作（頂層管理型主數據的治理），選型了國內某主數據管理平臺，2017年開啟項目二期實施后突然發現此平臺架構根本無法滿足業務部門的業務場景數據的管理需要，二期項目只得暫停。2018年甲乙雙方反復溝通尋求解決此問題的方案，無奈平臺無法替換，項目最終只能不了了之。

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

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

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

1.2.3 主數據管理項目實施后運維難以保障

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

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

舉個例子，企業實施主數據管理項目后進入運維階段，當需要增加某一新的數據的模型時，理想狀態是大家（數據管理組織成員）坐下來一起討論數據應該如何分類，模型如何制定，或者說主數據管理員提出具體建議后提交會議再討論，至少也是通過相應的辦公系統線上提交建議給企業負責人審核然后定稿。所有過程都似乎是非常嚴謹、合理的，但是大多數企業負責人并不了解數據分類、建模的思路，并無依據進行討論，而可能直接拍板定稿，這種討論往往空具形式，沒有實際意義。

有人會說，企業負責人只需要審核批準即可，主數據管理員是從項目一路跟下來的，肯定了解當時的設計思路，但如果主數據管理員是新來的怎么辦？如果主數據管理員把思路忘了怎么辦？主數據管理員又能依據什么來制定出合理的模型呢？答案只能是“拍腦袋”。

綜上所述，這樣就出現了主數據管理項目實施后的數據運維管理和項目建立的主數據管理體系之間是脫節的狀態，數據的運維和管理無法達到數據治理項目的目標。

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

1.2.4 主數據管理項目實施后數據質量并未改善

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

貌似合情合理，實則忽略了幾個核心的問題，純技術的驗證手段真的可以發現所有的質量問題嗎？如果寫了錯別字怎么辦？所謂的同名詞庫等手段也只能是判斷曾經發生過的且預置在平臺內的錯別字，以往從沒有出現過的錯別字出現了怎么辦？另外，諸如數據放錯類別等問題也是主數據管理平臺無法避免的問題。有人說，沒關系，這樣的情況不會很多，并且我們還有嚴格的審核機制。但審核真的管用嗎？負責人（領導）真的有時間審核嗎？負責人（領導）真的對所有數據的質量了解嗎？多年來多家企業驗證和審核只是一種“擺設”，只是一種行政的知會，對數據質量的把關幾乎沒有太大用處。這些問題似乎我們都可以不在乎，但時間久了就會造成數據質量產生問題。

某能源集團，2012年實施某國內的MDM平臺，項目順利驗收，甲方也花了近半年的時間進行了歷史數據質量的全面清洗，但是2015年初突然發現60多萬條的物料數據有20多萬條出現了不同形式的數據質量問題（包括名稱叫法的不一致、各種錯別字、數據描述的不完整等），且分公司及集團兩級審核機制形同虛設。目前該主數據管理平臺淪為了只是為ERP等業務系統提供賦碼功能（生成編碼并傳給業務系統），整個數據治理項目很不成功。