編輯導語：主數據（MD Master Data）指系統間共享數據（例如，客户、供應商、賬户和組織部門相關數據）。與記錄業務活動、波動較大的交易數據相比，主數據（也稱基準數據）變化緩慢。主數據必須存在並加以正確維護，才能保證交易系統的參照完整性。本文作者就從主數據管理出發，剖析了主數據管理的侷限性。
從主數據的概念定義上理解，主數據表示業務實體對象的基準數據以及其被引用的關聯屬性信息。例如每個人的身份證號碼就是主數據編碼，而對應的性別、年齡等就是屬於被引用的關聯屬性信息。
我們再進一步理解，在信息化領域對於主數據定義：
主數據：對於某一個業務實體對象中，包含基礎數據（靜態或相對靜態的數據）中被兩個及兩個以上業務系統共同使用的屬性字段。
這個定義是相對合理的，短期內也被各廠家推廣使用，這也是目前國內主數據廠商對主數據的統一標準定義。
但是我們會發現，不少企業將主數據管理平台進行了推廣和使用，還是沒有從根本上解決數據質量的問題。反而投入的人力物力越來越多，收效甚微。
一、主數據靜態性與動態性的悖論前面講到主數據的一個特徵便是業務實體對象的屬性字段是需要靜態或者相對靜態的，這實際上也是主數據的核心特徵之一。
如果要確保各個業務系統能夠進行匹配拉通，那麼對於業務實體對象的主數據定義必須是要靜態的。例如：我們每個人的身份證號碼，它一定是不能隨意更改，確保唯一性的。
但是在企業實際的發展過程中——特別是目前企業的轉型的過程中，企業業務系統的新增和更換，原來被主數據廠商識別出來的主數據已經無法滿足新的業務系統的上線需求，需要重新進行主數據的擴充識別和相關模型、流程等的變更操作。
從而造成了主數據管理平台後期運維成本的居高不下，嚴重違背了實施主數據管理平台的初衷。
例如：房地產行業從粗放型轉為精細型管理的過程中，需要擴充主數據項。原本管理的維度可能是項目、分期、樓棟的維度，接下來需要對於每一户進行管理。
那麼實際上原本固定靜態的主數據層級架構就會發生調整，在調整的過程中，我們可能會想當然的認為其實只是加一個”户”的主數據項。
但是問題來了，增加一個主數據維度真的那麼容易麼？對於户的主數據屬性字段、元數據管理的範圍定了嗎？不需要補充它的歷史取值？不需要找業務部門的主管們討論、協商？數據OWNER是誰？
我們會發現花了九牛二虎之力識別的主數據管理範圍和主數據字段，沒過多久就因為業務需求，場景變更進行了調整。
我們所謂的主數據靜態性並不是那麼靜態，甚至還具備動態性的特徵；而主數據項的增減，以及對於主數據項的屬性字段的擴充都無疑增加了額外的工作量。
我們瞭解到主數據的這個特徵後會發現，隨着企業的發展，業務場景越來越多樣化，動態性的影響也會讓我們對於主數據管理工作更加頭疼。
二、主數據無法滿足所有的業務場景我們在做數據治理的時候往往會和主數據治理混為一談，但是實際上這兩者只是包含的關係。
數據治理的範圍應該是更為寬泛的範圍，如果我們理解完成主數據平台搭建後，就能實現各個系統各個場景的數據拉通，實際上是有失偏頗的。
所以我們説業務場景數據管理和主數據管理是兩個層面的問題，這兩者的重要性沒有高低之分。
從數據治理的角度出發，如果我們無法管控業務場景數據，首先主數據管理將變成一件沒有意義的事情，第二個問題就是業務場景的數據對現有業務以及未來數據中心的不會起到有效支撐。
例如：在做房地產主數據管理的過程中，樓棟以及面積需要解決的問題其實無非就是：數據OWNER、錄入時點、數據標準等問題。
但是實際上管理了樓棟和麪積也並不能解決貨值管理的業務場景，對於業務數據和指標體系而言，主數據只是邁出了第一步，接下來業務場景數據管理才是最為關鍵的一步。
總之，主數據管理並不能輻射到系統所有的業務數據質量，同樣主數據管理無法滿足業務場景導致的數據治理障礙也越來越明顯。所以可以判斷的是，亡羊補牢甚至推倒重來會成為主數據管理的一種常態。
三、主數據逐漸淪為賦碼平台企業在上主數據平台進行管理的初衷之一，就是寄希望於通過主數據拉通改善數據質量。
但是目前絕大部分企業反饋的都是收效甚微，原因就是主數據管理作為多條線多部門協作的事情，從數據驗證機制、巡檢機制、管理規範、主責部門、錄入依據等等環節上都體現了管理的難度。
主數據項的屬性字段有沒有維護？維護的質量怎麼樣？
——這是主數據運維的核心。
但是受限於上游系統，主數據真的能管理好麼？還是逐漸淪為了各個業務系統賦碼的一個平台。
以上就是我對於主數據管理的一些侷限性思考，任何產品平台我相信都會存在一些侷限性。沒有一味藥可以治百病，核心還是要對症下藥，搭配其他的管控機制以及治理方式，才能最終實現數據價值。
作者：成於念，微信號：415864696，感興趣的事情很多，歡迎一起溝通交流。
本文由@成於念 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Pexels，基於CC0協議