以下文章來源于貓說信息化 ，作者苗峰79

來源：貓說信息化

導讀：其實我的看法正好相反，成熟的ERP產品應該做自己專業和擅長的事情。

客商主數據（客戶、供應商、既是客戶也是供應商）是企業最常用的主數據類型之一，因在主數據管理層面客戶和供應商思路基本一樣，所以本文以供應商為例介紹。

先說供應商數據，供應商主數據除了真正在供應商關系管理系統SRM、采購系統、電商等系統或者模塊中管理的典型供應商數據外，在財務管理中，只要是我方需要向其支付款項的都是供應商，那么部分業務場景下企業需要向個人支付時，這類個人也是供應商的角色（以下簡稱“個人供應商”），也需要按主數據管理。此外，在一般情況下，主數據是業務實體數據的子集，比如在SRM系統中對供應商做全方位管理時會包括大量的字段，而屬于主數據范疇的字段可能只是其中二十幾個。

進行主數據管理時常規希望是單一數據源，即主數據直接在主數據管理（MDM）系統輸入或者來自于一個前端應用系統（比如供應商數據來自SRM系統），如果是多源則會較大的增加主數據管理和MDM系統應用（包括集成）的復雜度。以下將先介紹在MDM系統中輸入供應商主數據的場景，之后介紹在類似SRM等第三方系統中輸入供應商主數據并與MDM系統集成的場景。

在MDM系統中輸入供應商主數據

一般情況下，新增供應商時建議用戶先在MDM中查詢主數據是否已存在，因為很多時候其他用戶此前已輸入過，但現實中用戶往往還是會習慣性的直接輸入。無論用戶是否會先查詢，在用戶輸入時MDM系統應首先在數據庫中查詢該供應商主數據是否已存在，如存在則提示用戶主數據已存在是否需要修改等。

此前輸入供應商主數據時，供應商名稱、統一社會信用代碼等內容的準確性檢查一直是件頭疼的事，嚴謹的企業會要求上傳供應商的工商營業執照等掃描件，在審核時人工比對，在數據量比較大的情況下，主數據管理人員的工作負荷比較大，人工比對也會難免出現較多失誤，此前見過的一些案例，大型集團企業在處理全集團的主數據時有些情況下需要第二天才能審核通過。于是后來應用了OCR，影像識別后將掃描件上的企業名稱等結構化，之后與用戶手工輸入的名稱進行主動比對，只有比對發現異常時才提示管理人員干預，處理效率和準確性大大提高。

以下的案例來自于我幾年前看過的《國家電網公司主數據管理系統功能優化研究》一文。當用戶對供應商主數據提出申請后，將通過省（市）公司運維和總部主數據運維兩級審批，審批通過后將創建或更新主數據。經統計，僅2014 年通過主數據管理平臺申請創建和更新的供應商主數據就有82000 條， 其中公司類數據占到90%以上， 而該類數據需上傳的信息包括組織機構代碼證、稅務登記證、營業執照三類電子掃描圖片， 兩級審批人員都需對這三項信息進行人工對比審核，效率低且需大量的人力支持。總部運維情況如表1 所示。[1]

在供應商主數據審批功能優化中， 利用兩種技術對一副圖片的識別審批速度都在1 秒左右， 對應于供應商的公司類數據三份必須資料， 利用兩項技術獨立串行審批需6 秒左右，并行審批只需3 秒左右。對于這三份必須資料，兩次自動審批都通過的比率大概占到60%左右，而轉人工審批的資料文件中，存在關鍵字段字體重疊、印刷位置錯誤等現象而無法自動審批的文件占50%左右。即機器總的審批數能占到80%左右。機器輔助審批工作量統計見表4，效率提升統計見表5。[1]

上邊是一個例子，接著介紹，當近些年企業征信服務出現后，基于上述對主數據準確性、風控及自動化等更多現實需要，主數據管理領域也出現了與企業征信服務集成應用的方案，典型的征信服務商包括企查查、啟信寶、天眼查等（多家大型銀行也有，但服務內容側重和價格不一樣）。企業的MDM系統通過與征信服務的集成，在用戶輸入時自動調用征信服務接口，用戶只需要輸入一部分數據即可自動從征信服務平臺獲取到準確的多個內容，一是大大減少了輸入的內容，同時自動獲得的還是準確的數據，比如輸入供應商的18位信用代碼，MDM通過接口自動從征信平臺獲取企業名稱、企業所屬地等數據。原則上，企業檔案類的數據以征信平臺的為準，于是相關字段在MDM的錄入界面上是只讀的，即只能從征信平臺獲得，不允許用戶編輯。

上圖是南京英諾森軟件科技有限公司MDM系統介紹材料中關于征信接口及OCR的內容。

因為征信平臺提供的商業服務可被信任，于是按上述方式獲得的數據是準確的，所以在主數據管理層面或許可以不再上傳供應商資料影像件，不再需要基礎性的審核。但對個人供應商和境外供應商通常還是需要人工審核的，個人供應商一是數量相對較少，二是沒有常規的個人征信服務，那么在輸入姓名和身份證號等信息時存在出錯的可能性，而大多數的情況下也不能拿到個人供應商的身份證原件，那么對身份證影像件的OCR可以一定程度上實現自動化，但人工審核往往還是需要的；對境外供應商，目前也沒有類似國內供應商的18位信用代碼，而國際上雖然有鄧白氏碼，但很多境外供應商因為規模等原因也不一定會注冊鄧白氏碼，那么一般情況下只能通過供應商名稱作為唯一性判斷條件，這就存在輸入錯誤、外文字符等各種異常狀況，一般情況下也需要人工審核。

鄧白氏在中國開展業務的官網頁面

再補充一點MDM系統查重校驗的內容（MDM系統應在軟件功能上最大限度的保證主數據的唯一性），對國內常規的組織機構可以通過機構名稱（如企業名稱）加上18位統一社會信用代碼兩個條件去復合查重；而對境外的組織機構，現階段只能以名稱進行查重判斷；對于個人供應商，因為姓名重名的幾率非常大，所以需要按身份證件的類型，以身份證件號碼做查重判斷，比如居民身份證編號等，綜上，需要根據不同的客商主數據類型按不同的查重規則做判斷。

當主數據經過一系列校驗以及審核，達到規定的數據質量標準后，MDM系統按規則為主數據生成唯一性的主數據編碼（這個操作以下簡稱為“賦碼”），隨后將主數據推送給所有目標系統，主數據新增完成。

征信服務不僅在主數據輸入時有用，因為供應商存在企業名稱等內容的信息變更，那么在主數據的日常管理工作中，可以調用征信服務接口定時對MDM庫內的主數據做檢查，發現庫內數據與征信平臺不一致時要提示管理人員做后續的處理。

順便簡單說一下主數據的日常性管理，除了上邊國網案例中的日常性的主數據審核工作，還有檢查MDM系統對主數據的接收和分發狀態、對異常情況的處理、參考數據及各類編碼表的更新，等等。對參考數據更新的工作略作展開介紹，類似于國別地區、幣種等參考數據一般變化很少，日常維護工作相應也很少，而供應商有一些數據往往需要時不時的維護，這個就是輸入供應商銀行賬號數據時的銀行編碼表（常規至少包括兩個字段：銀行名稱、聯行號）。

在較多的場景下，對供應商做銀企直連的在線付款時需要供應商收款的銀行和賬號（供應商的銀行信息也常常被多個系統所需要，所以納入供應商的主數據范圍），需要把銀行的名稱和聯行號發給銀企直連接口才能實現在線支付，聯行號是銀行類似于個人身份證號的官方編號，各家銀行新增營業網點時就會有新的銀行及聯行號需要維護到MDM系統中，此外也有銀行網點更名的情況，也需要對銀行編碼表做更新。所以，除了維護主數據本身，相關的參考數據和編碼表也是主數據管理的工作內容。

在第三方系統中輸入供應商主數據

如果把第三方系統作為主數據的輸入端，那么第三方系統應具備上述MDM系統輸入主數據時所需的全部功能，并在此基礎上開發與MDM系統集成的一系列接口和功能。首先，因為第三方系統與MDM系統是獨立的兩套系統，數據庫也是各自的，那么就可能存在兩個數據庫中數據不一致的情況，特別是如果有多個供應商主數據入口（含個別直接在MDM系統輸入主數據的情況），很可能出現兩個數據庫中數據數量不一樣的情況，比如第三方系統中沒有的主數據但在MDM系統中有，那么第三方系統判斷主數據是否存在的功能就不能只檢查自己的數據庫，還需要開發一個接口去MDM系統中做查詢（查重邏輯與MDM系統中的一致），如果在MDM系統中沒有才認為是真的沒有，如果有，則需要一個機制做數據同步。

當供應商主數據在第三方系統中經過一系列校驗成功錄入后，需要由第三方系統進行如上的審核使主數據進一步符合質量要求，這個審核可能需要管理或者業務方的參與，比如財務部門。當主數據審核通過后，第三方系統需要開發一個接口把主數據推送給MDM系統，無論采用同步接口還是異步接口，都需要保障數據推送的可靠性，只有第三方系統成功的從MDM系統收到正確的反饋時才認為主數據被成功送達。為此，需要第三方系統開發有接口監控的功能，以監控向MDM系統推送和接收數據的狀態，在包括網絡、系統、企業服務總線等出現異常時可以掌握情況并做處置。

這個接口還需要支持實時或者定時的推送控制，常規情況下，達到標準的供應商主數據應實時推送給MDM系統，之后再由MDM系統推送給各個用戶系統，有些業務場景對主數據的時效性是有要求的。并且，當推送遇到異常時，第三方系統可以批量的重新發起推送。此外，第三方系統應記錄所有與MDM系統的交互日志，一旦交互異常，可以加以分析和處理。

在第三方系統作為主數據輸入的情況下，主數據編碼的產生也需要予以重點關注。如果第三方系統是明確唯一的主數據入口，那么原則上主數據編碼可以由第三方系統賦碼，如果不能確保主數據入口的唯一性，即當前第三方系統不是唯一的供應商主數據入口，那么通常就只能由MDM系統賦碼了。對于后一種情況，相當于在第三方系統中產生的主數據是半成品，因為缺少最關鍵的主數據編碼，主數據編碼必須由MDM系統賦碼并返回給第三方系統，于是就需要再開發一個接口用于返回主數據編碼。

此時又分為兩種情況，第一種是第三方系統有自己的編碼體系，并且這個編碼體系作用于第三方系統的業務功能，只能使用第三方系統自己的編碼，只是為了需要與其他系統集成應用，與其他系統數據交換時需要采用主數據編碼，于是主數據編碼可被認為是第三方系統中供應商數據的一個功能性字段，當第三方系統按供應商主數據的標準把數據推送給MDM系統后產生了主數據編碼后，通過接口把主數據編碼反填至第三方系統的對應字段中，這個對主數據編碼字段的反填接口通常是需要按非主數據編碼的一個字段進行判斷的（因為此時第三方系統還沒有主數據編碼），比如國內供應商可以按18位信用代碼，此時需要第三方系統和主數據系統務必做好數據唯一性的管理。

另外一種情況是，第三方系統可以不使用自己的編碼體系，完全依賴于MDM系統的賦碼，此時，第三方系統剛錄入的供應商主數據可以采用一個臨時編碼，臨時編碼與數據一并發給MDM系統，MDM系統成功返回主數據編碼后，第三方系統根據這個臨時編碼去查找到對應的供應商數據并把臨時編碼替換為正式的主數據編碼。這兩種情況適用于不同的應用場景，具體按系統情況決定，但無論哪種情況，主數據編碼返回到第三方系統后的更新接口需要特別的嚴謹和可靠，需要納入到接口監控的范圍中，以保障主數據和主數據編碼的唯一性。

上述是供應商主數據新增時的一些管理內容，那么因為第三方系統是供應商主數據的入口，那不僅是新增時的管理，對主數據修改的管理也是第三方系統需要承擔的工作內容，也需要第三方系統開發一系列接口用于數據的修改，主數據修改的接口可以直接使用主數據編碼在第三方系統和MDM系統中定位到數據，同時仍然需要對接口做重點的監控，保障MDM系統中的主數據成功得到了修改才行。

綜上所述，本文以供應商主數據為例，介紹了在MDM系統和第三方系統中輸入主數據時常規的一些管理內容，在具體實踐中，在不同企業、不同系統情況、不同應用場景下，會有更多的技術細節需要具體關注。

參考文獻：

[1] 馬思碩, 張冰, 張瑩. 國家電網公司主數據管理系統功能優化研究[J].大眾用電. 2015,(S2)

轉自公眾號：ERP之家