主數據(MD Master Data)

主數據(MD Master Data)

目錄 1 什麼是主數據 2 主數據的因素 3 主數據管理 4 主數據管理問題存在的根源 5 主數據管理的成熟度 6 主數據管理方案的構建

 

什麼是主數據

　　主數據是指在整個企業範圍內各個系統(操做/事務型應用系統以及分析型系統)間要共享的數據， 好比，能夠是與客戶(customers), 供應商(suppliers), 賬戶(accounts)以及組織單位(organizational units)相關的數據。

　　主數據一般須要在整個企業範圍內保持一致性(consistent)、完整性(complete)、可控性(controlled)，爲了達成這一目標，就須要進行主數據管理(Master Data Management ，MDM)。須要注意的是，主數據不是企業內全部的業務數據，只是有必要在各個系統間共享的數據纔是主數據，好比大部分的交易數據、賬單數據等都不是主數據，而像描述核心業務實體的數據，而像客戶、供應商、賬戶、組織單位、員工、合做夥伴、位置信息等都是主數據。主數據是企業內可以跨業務重複使用的高價值的數據。這些主數據在進行主數據管理以前常常存在於多個異構或同構的系統中。

主數據的因素

• 企業績效管理報告(如利潤或收入計劃隨產品、客戶、帳戶等產生的變化)要求綜合多個系統的主數據。

• 聽從報告(如辛巴賽爾協定關於運營風險的報告)要求一致性主數據。

• 同步交易系統處理特定客戶(如提供具體報價)或供應商(如指定採購的首選供應商)。

主數據管理

　　主數據管理(Master Data Management ，MDM)是指一組約束和方法用來保證一個企業內主題域和系統內相關數據和跨主題域和系統的相關數據的實時性、含義和質量。這是從深層次來講來講明主動主數據管理(MDM)的深度和複雜性，簡單的說，主數據管理(MDM)保證你的系統協調和重用通用、正確的業務數據(主數據)。一般，咱們會把主數據管理做爲應用流程的補充，經過從各個操做/事務型應用以及分析型應用中分離出主要的信息，使其成爲一個集中的、獨立於企業中各類其餘應用核心資源，從而使得企業的核心信息得以重用並確保各個操做/事務型應用以及分析型應用間的核心數據的一致性。經過主數據管理，改變企業數據利用的現狀，從而更好地爲企業信息集成作好鋪墊。

　　主數據管理(MDM)能夠幫助咱們建立並維護整個企業內主數據的單一視圖(Single View)，保證單一視圖的準確性、一致性以及完整性，從而提供數據質量，統一商業實體的定義，簡化改進商業流程並提供業務的響應速度。從變化的頻率來看，主數據和平常交易數據不同，變化相對緩慢，另外，主數據因爲跨各個系統，因此對數據的一致性、實時性以及版本控制要求很高。

　　主數據管理其實在很早以前就一直存在，只不過如今隨着業務發展以及監管的須要，對主數據的實時性、準確性、一致性有了更高的要求，才被業界普遍接受，各個廠商相應的推出了一系列的主數據管理集成與基礎套件以及特定領域的解決方案。近年來最明顯的變化是，客戶在之前的時候常常問的問題是：「主數據管理是什麼?」，而如今客戶常常問的問題演變成了：「咱們的業務的確存在一些問題，主數據管理正好能夠解決這個問題，咱們怎麼開始?」。與之前相比，客戶對主數據管理(MDM)的認識有了巨大的進步，並開始嘗試用主數據管理(MDM)解決他們在整個企業範圍內進行跨業務、跨主題域時趕上的各類挑戰和問題：好比稅務行業，稅務局在按納稅人在一些分析統計時，就發現關於納稅人的基本信息分佈在覈心徵收管理系統、發票管理系統、我的所得稅系統、增值稅管理系統等多達幾十個系統中，使得統計分析變得困難起來，在好比在醫療設備公司，因爲沒有按照供應商進行產品層次的分類，各個產品的描述也很不同，使得產品目錄的維護十分困難。隨着業務的發展，對各行各業來講，生成並維護一個統一的主數據系統變的十分迫切和必要，特別是對一些跨國公司，如何在不一樣的地區(各個國家和地區)的業務系統之間維護關於客戶、產品目錄、供應商等信息的單一視圖更是重要。

　　須要注意的是，主數據(Master Data)和元數據(Meta Data)是兩個徹底不一樣的概念。元數據是指表示數據的相關信息，好比數據定義等，而主數據是指實例數據，好比產品目錄信息等。好比，某省地稅開發了一套徵收管理軟件，以市爲單位部署了17套，每套徵收管理軟件中的元數據都是同樣的，可是主數據仍是須要進行管理的。主數據管理和傳統數據倉庫解決方案不是一個概念，數據倉庫會將各個業務系統的數據集中在一塊兒在進行業務的分析，而主數據管理系統不會把全部數據都管理起來，只是把須要在各個系統間共享的主數據進行採集和發佈。相對於傳統數據倉庫解決方案的單向集成，主數據管理正注重將主數據的變化同步發佈到各個關聯的業務系統中(主數據管理數據是雙向的)。

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

　　對於大多數的企業都存在主數據管理的問題，我的覺得這是因爲業務發展的漸進性以及IT技術發展的漸進性形成的，正是因爲這種漸進性，各大企業的業務系統從經歷了從無到有，從簡單到複雜，從而造成了一個又一個的業務豎井。從根本上來講，不可能只使用一個業務系統就能覆蓋企業的全部業務，即使對一些國際大型的公司提供的套件來講也是一個不可能完成的任務(即使對套件來講，常常也存在一個跨國企業在不一樣的國家或地區部署多個實例的現象，也就是沒有集中部署該套件，而是在不少地方分散部署了該套件)。對企業來講，業務系統的構建更可能是以項目爲中心，從下而上的構建系統，而不是至上而下的構建系統，必然缺少整個企業範圍內的統一規劃，從而使得一些須要在各個業務中共享的數據(主數據)被分散到了各個業務系統進行分別管理。分散管理的主數據因爲沒有不具有一致性、準確性、完整性，使得各個企業廣泛存在着產品管理不力、供應商管理不力、訂單管理不力等現象。解決這一問題的根本方法就是引入主數據管理(MDM)，主數據不光指須要共享的數據，更包含須要共享的業務規則和策略。

 

主數據管理的成熟度

根據主數據管理實施的複雜程度，參照Jill Dyche, Evan Levy的觀點大致能夠把主數據管理能夠分爲五個層次，從低到高反映了主數據管理(MDM)的不一樣成熟度。下面咱們簡單介紹一下這五個層次：

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

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

　　Level 1 ：提供列表

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

　　MDM Level 1比MDM Level 0的不一樣就是，各個部門雖然仍是獨立維護各自的關鍵數據，但會經過列表管理維護一個鬆散的主數據列表，可以向其餘各個部門提供其須要的數據。在MDM Level 1中，數據變動決定以及數據變動操做都是由人來決定的，所以，只有人完成數據變動決定後纔會變動數據。在實際狀況中，雖然數據變動流程有嚴格的規定，可是因爲缺少集中的、基於規則的數據管理，當數據量比較大時，數據維護的成本會變的很高，效率也會很低。當主數據，好比客戶信息、產品目錄信息等數量比較少時，列表管理的方式是可行的，可是當產品目錄或客戶列表出現爆炸式增加之後，列表管理的變動流程將變得困難起來。MDM Level 1 依賴於人的協做。若是產品經理須要更新事後的產品價格列表，那須要聯繫ERP系統全部者，讓其發送郵件給她。在企業範圍內實現客戶或產品列表就如同維護不一樣部門之間人們的關係同樣。若是客戶或產品存在層次或分組，列表將很難提供，而且一般在Level 1由於過於複雜難以被管理。

　　Level 2 ：同等訪問(經過接口的方式，各個系統與主數據主機之間直接互聯)

　　MDM Level 2與MDM Level 1相比，引入了對主數據的(自動)管理。經過創建數據標準，定義對存儲在中央知識庫(Central Repository)中詳細數據的訪問和共享，爲各個系統間共享使用數據提供了嚴密的支持。中央知識庫(Central Repository)一般會被稱爲「主數據主機(Master Data Host)」。這個知識庫能夠是一個數據庫或者一個應用系統，經過在線的方式支持數據的訪問和共享。

　　建立、讀取、更新和刪除(CRUD)是處理基本功能的典型編程術語。即使在MDM中，CRUD處理也是基本功能。你的數據庫若是僅僅支持CRUD處理並不意味着你實現了MDM。MDM Level 2引入了「同等訪問」(peer-based access)，也就是說一個應用能夠調用另外一個應用來更新或刷新須要的數據。當CRUD處理規則定義完成後，MDM Level 2 須要客戶或「同等」應用格式化請求(和數據)，以便和MDM知識庫保持一致。MDM知識庫提供集中的數據存儲和供應(provisioning)。在這個階段，規則管理、數據質量和變動管理必須在企業範圍內做爲附加功能定製構建。

　　好比，一個數據庫或一個打包應用(好比一個銷售自動化系統)對外部應用提供數據訪問功能。當一個外部應用(好比呼叫中心應用)須要增長一個客戶，這個外部應用將提交一個事務，請求數據全部者增長一個客戶條目。主數據主機(Master Data Host)將增長數據並告知外部應用。CRUD處理方式比紙上辦公有了很大提升，其是基於會話的數據管理。在MDM Level 1，數據變動是基於手工的方式。在MDM Level 2， 數據變動是自動完成的—經過由具體技術實現的標準流程，容許多應用系統修改數據。MDM Level 2能夠支持不一樣的應用使用和變動單1、共享的數據知識庫。MDM Level 2 須要每一個同等應用理解基本的業務規則以便訪問主列表、與主列表進行交互。所以，每一個同等應用必須正確恰當地建立、增長、更新和刪除數據。受權應用有責任堅持數據管理原則和約束。

　　Level 3 ：集中總線處理

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

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

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

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

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

　　舉例來講，在一個HMO內，須要多個應用來支持一個病人的護理。一個單一的訪問(visit)可能包括入院、房間和牀位分配、監控設備、化驗、身體檢查以及其餘程序等。一旦一個病人準備離開醫院，出院流程須要確保和這個病人相關的全部活動、資源都被結清。MDM技術在召集多個應用系統一塊兒保證病人辨識方面是十分有效的，處理是正確的。雖然病人辨識很重要，業務規則整合一樣重要。臨牀系統依靠一系列的業務流程和數據規則來辨別全部顯着的病人詳細資料。這包括返回全部基於房間的資源(監護設備、牀位等)以獲得有用的詳細目錄，當病人要出院時分解其全部的費用。MDM保證當John Smith出院時，正確的房間和設備放入到該John Smith的詳細目錄中，而不是其餘的John Smith(正在另外一個樓層作身體治療)。

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

　　好比，若是一個商店經理更新一個產品的價格，總線系統須要可以和一個可信系統(好比，商品管理系統)進行協商以便使規則生效。詳細規則將支持另外一個系統中存在產品價格的變動—總線須要可以理解可以處理和批准變動的權限系統或方法。這些規則可能涉及到複雜性或隱私限制，禁止它們直接在總線上存在。在 MDM Level 4， 一個企業能夠支持一套步驟或任務，在一個特殊的建立、讀取、更新和刪除任務被容許以前這些步驟或任務必須遵照。工做流自動化常常用來支持發生在總線上的事件或活動的受權。可是變動管理遠遠不只僅是工做流：它能夠包括基於邏輯的流程和基於人的決策。變動管理的存在能夠支持動態業務，容許變動。舉例說明，在 911以前，任何人均可以在美國國內的航空公司運載貨物。沒有規定之外的其餘某種形式的鑑定和付款方式。911以後，美國聯邦航空協會(FAA)指導創建了一個更加全面的規定，指示一我的是否被容許運載貨物。在這個特殊的例子中，要求各個系統都部署FAA對託運人的要求是不現實的。部署一個規則管理系統 ，爲全部的系統(包括MDM總線)集中托運人批准規則，更加容易實現(也更現實)。集中數據定義和標準化在MDM Level 2就已經引入，與MDM Level 4的集中規則管理相比，相對簡單。業務流程越複雜、業務流程越多，對總線的需求就越多，以便對針對共同數據的跨職能、異構規則進行更好的支持。重要的是 MDM Level 4支持集中規則管理，可是規則自己和相關的處理是能夠分開的。換句話說，MDM總線須要保證規則是集中應用的，即使這個規則是在總線外居住的。

　　Level 5 ：企業數據集中

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

　　從MDM Level 4到MDM Level 5意味着MDM功能性不是在一個應用內被特殊設計或編碼的。這還意味着主數據傳播和供應不須要源系統專門的開發或支持。全部的應用清楚的知道他們並不擁有或控制主數據。他們僅僅使用數據來支持他們本身的功能和流程。因爲MDM總線和支持的IT基礎架構，全部的應用能夠訪問主參考數據。一個公司在完成MDM Level 5後將使他們全部的應用連在一塊兒—既包括操做的也包括分析的—全部訪問主數據是透明的。舉例說明，當一個客戶更新她的狀態—不要管註冊該變動的系統—數據變動將被廣播到全部的應用平臺(所以一致起來)。MDM Level 5是把數據概念做爲一種service來實現。MDM Level 5保證了一個一致的主數據主題域企業映像。定義「客戶」和其餘應用接受客戶主數據業務規則變化其實是一回事。MDM Level 5移走了主數據的最後一個障礙：統一採用數據定義、受權使用和變動傳播。

主數據管理方案的構建

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

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

• Party ：能夠反映任何合法的實體, 不管是個體仍是組織。

• Product ：既包括物理存在的貨物，也能夠是任何服務。

• Account ：包括期限和條件，以及相關的各類關係。

• Location ：既能夠獨立存在，也經常與其餘主數據域共存。

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

• 數據採集和發佈是否實時，最小的響應時間是多少。

• 數據轉換規則可否讓客戶定製，而不是硬編碼。

• 若是根據數據質量標準清理主數據域中的主數據。

• 權限控制。

• 主數據的歷史版本控制以及變動監控控制(當主數據變化時，要能記錄該變化，另外還要對主數據造成層次並記錄其不一樣的版本值)。

　　第四步，開發部署測試。