01什么是主數據管理

主數據是指在整個企業范圍內各個系統(操作/事務型應用系統以及分析型系統)間要共享的數據， 比如，可以是與客戶, 供應商, 帳戶以及組織單位相關的數據。主數據通常需要在整個企業范圍內保持一致性、完整性、可控性，為了達成這一目標，就需要進行主數據管理(Master Data Management ，MDM)。需要注意的是，主數據不是企業內所有的業務數據，只是有必要在各個系統間共享的數據才是主數據，比如大部分的交易數據、帳單數據等都不是主數據，而像描述核心業務實體的數據，而像客戶、供應商、帳戶、組織單位、員工、合作伙伴、位置信息等都是主數據。主數據是企業內能夠跨業務重復使用的高價值的數據。這些主數據在進行主數據管理之前經常存在于多個異構或同構的系統中。主數據管理(Master Data Management ，MDM)是指一組約束和方法用來保證一個企業內主題域和系統內相關數據和跨主題域和系統的相關數據的實時性、含義和質量。簡單的說，主數據管理(MDM)保證你的系統協調和重用通用、正確的業務數據(主數據)。通常，我們會把主數據管理作為應用流程的補充，通過從各個操作/事務型應用以及分析型應用中分離出主要的信息，使其成為一個集中的、獨立于企業中各種其他應用核心資源，從而使得企業的核心信息得以重用并確保各個操作/事務型應用以及分析型應用間的核心數據的一致性。通過主數據管理，改變企業數據利用的現狀，從而更好地為企業信息集成做好鋪墊。

主數據管理(MDM)可以幫助我們創建并維護整個企業內主數據的單一視圖，保證單一視圖的準確性、一致性以及完整性，從而提供數據質量，統一商業實體的定義，簡化改進商業流程并提供業務的響應速度。從變化的頻率來看，主數據和日常交易數據不一樣，變化相對緩慢，另外，主數據由于跨各個系統，所以對數據的一致性、實時性以及版本控制要求很高。近年來最明顯的變化是，客戶在以前的時候經常問的問題是：“主數據管理是什么?”，而現在客戶經常問的問題演變成了：“我們的業務的確存在一些問題，主數據管理正好可以解決這個問題，我們怎么開始?”。與以前相比，客戶對主數據管理(MDM)的認識有了巨大的進步，并開始嘗試用主數據管理(MDM)解決他們在整個企業范圍內進行跨業務、跨主題域時遇上的各種挑戰和問題：比如稅務行業，稅務局在按納稅人在一些分析統計時，就發現關于納稅人的基本信息分布在核心征收管理系統、發票管理系統、個人所得稅系統、增值稅管理系統等多達幾十個系統中，使得統計分析變得困難起來，在比如在醫療設備公司，由于沒有按照供應商進行產品層次的分類，各個產品的描述也很不一樣，使得產品目錄的維護十分困難。隨著業務的發展，對各行各業來說，生成并維護一個統一的主數據系統變的十分迫切和必要，特別是對一些跨國公司，如何在不同的地區(各個國家和地區)的業務系統之間維護關于客戶、產品目錄、供應商等信息的單一視圖更是重要。

需要注意的是，主數據(Master Data)和元數據(Meta Data)是兩個完全不同的概念。元數據是指表示數據的相關信息，比如數據定義等，而主數據是指實例數據，比如產品目錄信息等。主數據管理和傳統數據倉庫解決方案不是一個概念，數據倉庫會將各個業務系統的數據集中在一起在進行業務的分析，而主數據管理系統不會把所有數據都管理起來，只是把需要在各個系統間共享的主數據進行采集和發布。相對于傳統數據倉庫解決方案的單向集成，主數據管理正注重將主數據的變化同步發布到各個關聯的業務系統中(主數據管理數據是雙向的)。

02主數據管理問題存在的根源

大多數的企業都存在主數據管理的問題，這是由于業務發展的漸進性以及IT技術發展的漸進性造成的，正是由于這種漸進性，各大企業的業務系統從經歷了從無到有，從簡單到復雜，從而形成了一個又一個的業務豎井。從根本上來說，不可能只使用一個業務系統就能覆蓋企業的所有業務，即便對一些國際大型的公司提供的套件來說也是一個不可能完成的任務(即便對套件來說，經常也存在一個跨國企業在不同的國家或地區部署多個實例的現象，也就是沒有集中部署該套件，而是在很多地方分散部署了該套件)。

對企業來說，業務系統的構建更多是以項目為中心，從下而上的構建系統，而不是至上而下的構建系統，必然缺乏整個企業范圍內的統一規劃，從而使得一些需要在各個業務中共享的數據(主數據)被分散到了各個業務系統進行分別管理。分散管理的主數據由于沒有不具備一致性、準確性、完整性，使得各個企業普遍存在著產品管理不力、供應商管理不力、訂單管理不力等現象。解決這一問題的根本方法就是引入主數據管理(MDM)，主數據不光指需要共享的數據，更包含需要共享的業務規則和策略。

03主數據管理的成熟度

根據主數據管理實施的復雜程度，可以把主數據管理可以分為五個層次，從低到高反映了主數據管理(MDM)的不同成熟度。

Level 0 ：沒有實施任何主數據管理

在Level 0的情況下，意味著企業的各個應用之間沒有任何的數據共享，整個企業沒有數據定義元素存在。比如，一個公司銷售很多產品，對這些產品的生產和銷售由多個獨立的系統來處理，各個系統獨立處理產品數據并擁有自己獨立的產品列表，各個系統之間不共享產品數據。在Level 0, 每個獨立的應用負責管理和維護自己的關鍵數據(比如產品列表、客戶信息等)，各個系統間不共享這些信息，這些數據是不連通的。

Level 1 ：提供列表

不管公司大還是小，列表管理是我們常用的一種方式。在公司內部，會通過手工的方式維護一個邏輯或物理的列表。當各個異構的系統和用戶需要某些數據的時候，就可以索取該列表了。對于這個列表的維護，包括數據添加、刪除、更新以及沖突處理，都是由各個部門的工作人員通過一系列的討論和會議進行處理的。業務規則(Business Rules)是用來反映價值的一致性，當業務規則發生改變或者出現類似的情況時，這樣高度手工管理的流程容易發生錯誤。由于列表管理是通過手工管理的，其列表維護的質量取決于誰參加了變更管理流程，一旦某人缺席，將會影響列表的維護。

Level 1比 Level 0的不同就是，各個部門雖然還是獨立維護各自的關鍵數據，但會通過列表管理維護一個松散的主數據列表，能夠向其他各個部門提供其需要的數據。在 Level 1中，數據變更決定以及數據變更操作都是由人來決定的，因此，只有人完成數據變更決定后才會變更數據。在實際情況中，雖然數據變更流程有嚴格的規定，但是由于缺乏集中的、基于規則的數據管理，當數據量比較大時，數據維護的成本會變的很高，效率也會很低。當主數據，比如客戶信息、產品目錄信息等數量比較少時，列表管理的方式是可行的，但是當產品目錄或客戶列表出現爆炸式增長以后，列表管理的變更流程將變得困難起來。MDM Level 1 依賴于人的協作。如果產品經理需要更新過后的產品價格列表，那需要聯系ERP系統所有者，讓其發送郵件給她。在企業范圍內實現客戶或產品列表就如同維護不同部門之間人們的關系一樣。如果客戶或產品存在層次或分組，列表將很難提供，并且通常在Level 1因為過于復雜難以被管理。

Level 2 ：同等訪問

Level 2與 Level 1相比，引入了對主數據的(自動)管理。通過建立數據標準，定義對存儲在中央知識庫中詳細數據的訪問和共享，為各個系統間共享使用數據提供了嚴密的支持。中央知識庫通常會被稱為“主數據主機”。這個知識庫可以是一個數據庫或者一個應用系統，通過在線的方式支持數據的訪問和共享。

創建、讀取、更新和刪除(CRUD)是處理基本功能的典型編程術語。即便在MDM中，CRUD處理也是基本功能。你的數據庫如果僅僅支持CRUD處理并不意味著你實現了MDM。Level 2引入了“同等訪問”，也就是說一個應用可以調用另一個應用來更新或刷新需要的數據。當CRUD處理規則定義完成后， Level 2 需要客戶或“同等”應用格式化請求(和數據)，以便和MDM知識庫保持一致。MDM知識庫提供集中的數據存儲和供應。在這個階段，規則管理、數據質量和變更管理必須在企業范圍內作為附加功能定制構建。在 Level 1，數據變更是基于手工的方式。在 Level 2， 數據變更是自動完成的—通過由具體技術實現的標準流程，允許多應用系統修改數據。Level 2可以支持不同的應用使用和變更單一、共享的數據知識庫。Level 2 需要每個同等應用理解基本的業務規則以便訪問主列表、與主列表進行交互。因此，每個同等應用必須正確恰當地創建、增加、更新和刪除數據。授權應用有責任堅持數據管理原則和約束。

Level 3 ：集中總線處理

與 Level 2相比， Level 3打破了各個獨立應用的組織邊界，使用各個系統都能接受的數據標準統一建立和維護主數據( Level 2的主數據主機上存儲的數據還是按照各個系統分開存儲的，沒有真正的整合在一起)。

集中處理意味著為MDM構建了一個通用的、基于目標構建的平臺。大多數公司發現MDM正在挑戰他們現有的IT架構：他們擁有太多的獨立平臺處理主數據。 Level 3 集中數據訪問、控制跨不同應用和系統使用數據。這極大的降低了應用數據訪問的復雜性，大大簡化了面向數據規則的管理，使MDM比一個分散環境具有更多的功能和特點。企業主數據面臨一致性的挑戰。數據在不同的地方存在，數據所代表的含義也是不同的，數據的規則各個系統之間也是不一樣的。集中MDM處理-通過一個公共的平臺作為一個總線(HUB)-說明一個共識，從多個系統整合主題域數據，意味著使用集中、標準化的方法轉換異構操作數據，不管其在源系統中是什么樣子，都會被整合起來。在 Level 3，公司對主題域內容采用集中管理方式。這意味著應用系統，作為消費者或使用主數據，擁有一個共識就是數據是主題數據內容的映像，打破了各個獨立應用的組織邊界。Level 3支持分布主參考數據的存在。

MDM的核心之一就是保證所有系統都能接受 數據表示的唯一公認方法。這有點類似于語言翻譯，通過其他語言的翻譯，英語已經稱為一個全球性的語言。在 Level 3， 一個公司可以讓任意兩個系統共享數據和說對方的語言。Level 3還降低了等同訪問的復雜性。"消費"應用不再需要支持系統定位和操作邏輯。任何與源系統數據相關的分布式細節都會被MDM總線集中處理。在 Level 3自動數據標準意味著：建立目標數據值表示和通過必要的步驟提供精確的主數據值捕獲。在所有的分類中從 Level 3開始第一次支持一致性的企業數據視圖。數據質量規則在這里進行數據清洗和錯誤糾正。

Level 4 ：業務規則和政策支持

一旦數據從多個數據源整合在一起，主題域視圖超越單獨的應用并表現為一個企業視圖，你將獲得事實的單一版本。當事實的單一版本已經能夠提供出來時，來自業務主管和執行人員的必然反應經常是：“證明它”。Level 4可以保證主數據反映一個公司業務規則和流程，并證實其正確性。Level 4通過引入主數據來支持規則，并對MDM總線以及其它外部系統進行完整性檢查。由于多數公司相對比較復雜，影響業務數據訪問和操作的規則以及策略(相對也比較復雜。假定任何一個單一系統可以包含并管理與主參考數據相關的各種類型的規則是不切實際的。因此，如果一個MDM總線真正打算提供企業范圍內數據的精確性，工作流和流程整合的支持是必不可少的。

MDM系統必須不僅支持基于規則的整合，還要能夠整合外部的工作流。這些規則可能包括通過總線與臨床系統交互或等待另一個系統或者人(有權限做出改變的人)審批。通過一個MDM總線，規則定義可以不僅局限在邏輯上，還可以依賴于其他系統的輸入。當然，協調和審計數據意味著可以回退其他系統(或業務流程)來保證數據變化經過嚴格的審批，這樣錯誤可以被發現并且事務在需要的時候可以被回滾。MDM Level 4提出對規則和策略擴展性的支持。通過總線以一個靈活可持續的方式支持任何面向業務的規則集合這很重要。

集中數據定義和標準化在MDM Level 2就已經引入，與MDM Level 4的集中規則管理相比，相對簡單。業務流程越復雜、業務流程越多，對總線的需求就越多，以便對針對共同數據的跨職能、異構規則進行更好的支持。重要的是MDM Level 4支持集中規則管理，但是規則本身和相關的處理是可以分開的。換句話說，MDM總線需要保證規則是集中應用的，即便這個規則是在總線外居住的。

Level 5 ：企業數據集中

在 Level 5 ， 總線和相關的主數據被集成到獨立的應用中。主數據和應用數據之間沒有明顯的分隔。他們是一體的。當主數據記錄詳細資料被修改后，所有應用的相關數據元素都將被更新。這意味著所有的消費應用和源系統訪問的是相同的數據實例。這本質上是一個閉環的MDM：所有的應用系統通過統一管理的主數據集成在一起。在這個級別，所有在系統看起來都是事實的同一個版本。操作應用系統和MDM內容是同步的，所以當變更發生時，操作應用系統都將更新。在那些熟悉的MDM架構風格中，持久總線架構，當一個總線更新所有的操作應用系統將體現這種變更，形成改變的直接操作視圖。在注冊環境中，當數據數據更新時，總線將通過Web服務連接相關系統應用事務更新。因此，MDM Level 5提供一個集成的，同步的架構，當一個有權限的系統更新一個數據值時，公司內所有的系統將反映這個變更。系統更新完數據值后不要單選其他系統中相應值的更新：MDM將使這種更新變的透明。

從 Level 4到MDM Level 5意味著MDM功能性不是在一個應用內被特殊設計或編碼的。這還意味著主數據傳播和供應不需要源系統專門的開發或支持。所有的應用清楚的知道他們并不擁有或控制主數據。他們僅僅使用數據來支持他們自己的功能和流程。由于MDM總線和支持的IT基礎架構，所有的應用可以訪問主參考數據。

一個公司在完成 Level 5后將使他們所有的應用連在一起—既包括操作的也包括分析的—所有訪問主數據是透明的。舉例說明，當一個客戶更新她的狀態—不要管注冊該變更的系統—數據變更將被廣播到所有的應用平臺(因此一致起來)。Level 5是把數據概念作為一種service來實現。Level 5保證了一個一致的主數據主題域企業映像。定義“客戶”和其他應用接受客戶主數據業務規則變化實際上是一回事。Level 5移走了主數據的最后一個障礙：統一采用數據定義、授權使用和變更傳播。

如何構建一個主數據管理(MDM)的解決方案

在開始構建主數據管理(MDM)解決方案之前，首先需要明確我們當前的數據管理現狀是什么樣子的，而我們的目標是什么，具體可以參照上一小節：主數據管理(MDM)的成熟度。

第二步，需要確定我們的每個主數據域的范圍(這也是前期需求分析的一部分)。常見的主題域有：

Party ：可以反映任何合法的實體, 無論是個體還是組織。

Product ：既包括物理存在的貨物，也可以是任何服務。

Account ：包括期限和條件，以及相關的各種關系。

Location ：既可以獨立存在，也常常與其他主數據域共存。

第三步，進行數據管理系統的設計，在設計時要注意以下幾點：

數據采集和發布是否實時，最小的響應時間是多少。

數據轉換規則能否讓客戶定制，而不是硬編碼。

如果根據數據質量標準清理主數據域中的主數據。

權限控制。

主數據的歷史版本控制以及變更監控控制(當主數據變化時，要能記錄該變化，另外還要對主數據形成層次并記錄其不同的版本值)。

第四步，開發部署測試。