一、數據標準概念介紹

1、數據標準的概念

首先，我們要明白什么是數據標準概念，根據中國通信院的定義：數據標準，是指保障數據的內外部使用與交換的一致性和準確性的規范性約束。

我們可以簡單理解，數據標準，就是組織內部各個部門，各個數據相關人，共同使用的一個語言，達成的一個共識。

比如一個部門內部在開會，有人說方言，有人說英語，有人說普通話，大家由于語言不一致，導致溝通費時費力。而如果制定統一的標準，比如統一使用普通話，那么溝通會順暢很多。

秦始皇統一六國之后，要求國內統一文字，貨幣，度量衡，本質就是制定社會的標準規范，目的是讓社會能夠更加高效運轉。

所以，對于企業來說，數據標準，為業務運營和管理決策提供相應的保障。如果沒有標準，那么企業的運營管理將會混亂不堪。

2、數據標準管理不善導致3大問題

很多組織在發展初期，因為數據量不足，導致數據標準缺乏整體規劃，等組織發展壯大，發現各個部門的各個系統由不同廠商和商品搭建，導致數據共享困難，理解歧義，無法有效分析。組織，通常因為沒有制定嚴格的數據標準，管理不善出現以下3種問題：

（1）數據共享難以實現

由于各個系統的數據存儲結構不一致，分布在多個系統的不同數據，沒有統一的標準，無法關聯整合和分析，影響不同系統之間的數據共享。比如一家大型企業，老部門使用老的A系統，新部門使用新的B系統，不同系統的存儲結構不同，導致數據共享困難。

（2）數據名稱，標準不規范，語義不清

沒有數據標準，不同系統對同一種數據，有不同的命名，業務含義，取值范圍，容易造成同義不同名，同名不同義，讓數據使用者產生誤解的情況。比如同一銀行的不同網點，有的系統把客戶叫做用戶，有的把客戶叫做客戶，有的把客戶叫做開卡客戶，指的都是同一含義，但因沒有數據標準，導致有不同名稱，讓業務數據統計分析，部門之間溝通理解費時費力。

（3）數據理解溝通成本高

數據沒有統一規范和標準，對于同一數據，不同人員的理解不一致，導致溝通交流成本增加，降低企業組織內部的運轉效率。比如同一家公司的北京和武漢業務部門，北京部門把消費金額超過10萬的客戶設定為vip客戶，武漢部門把消費超過5萬的設定為vip客戶。兩個部門對vip客戶的理解不一致，也導致總部系統管理分析用戶數據混亂，無法對用戶進行系統歸類運營。

3、數據標準規范3大分類

在企業日常管理和業務發展中，我們一般會從業務，技術，管理維度去分析和拆解數據標準。

（1）業務標準規范

業務標準規范，一般包括業務的定義，標準的名稱，標準的分類等。比如企業的CRM系統，要判斷客戶是否為老客戶，我們要通過用戶消費金額，消費頻率，消費日期等維度做判斷，這個維度就是數據判斷標準。對于業務人員而言，數據標準化建設，可以提升業務的規范性，提升自己的工作效率；同時，保障了數據含義的一致性，降低了溝通成本，給業務的數據分析，挖掘，信息共享提供了便利。

（2）技術標準規范

技術標準規范，是從技術角度，看待數據標準包括了數據的類型，長度，格式，編碼規則等。比如企業員工要在公司系統填寫客戶信息，那么客戶的姓名，手機號這些數據，都需要設定相應類型，長度規范，如果你把姓名輸入手機號框，系統就會顯示錯誤。對于技術人員來說，有了數據標準規范，工作效率可以大幅度提升，降低系統的出錯率，有助于提升數據質量。

（3）管理標準規范

管理標準規范，是從管理角度，看待數據標準。比如數據標準的管理者是誰，如何增添，如何刪減，訪問標準條件等，都是一個數據規范要求。對于管理人員來說，數據標準建設，保證了數據的完整，準確，為數據安全，經營決策都提供了支持和保障。

二、企業數據標準建設現狀

國外數據標準化工作起步較早，不少國際大型企業已將數據當作企業的重要資產來對待，其中大部分企業均以數據標準為核心，確保數據標準能夠融入企業的每個業務環節中。 但國內企業大多數系統的建設都是直接依據業務需求建立，并沒有一個整體的規劃，另外不同系統的建設廠商可能也不一樣，所以不同系統之間數據的不一致性難以避免，究其根源，還是沒有一套統一的數據標準來進行約束。企業在對數據的使用過程中，出現的很多數據問題，都是由于缺乏標準約束和整體規劃設計造成的，如下：

數據存儲結構不一致，調用多系統的數據時，由于某些數據在不同系統中數據存儲結構不同，導致數據無法直接關聯，影響不同系統之間的數據共享。

數據定義不一致，不同系統對數據的命名、業務含義、取值范圍等定義不同，比如同名不同義、同義不同名等

數據理解不一致，不同人員對數據的理解不一致，導致在數據使用時浪費很多溝通時間。

數據來源不一致，數據存在多個來源，在數據使用時，不清楚應該取哪個系統的數據。

通過數據標準的建設，可消除數據跨系統的非一致性，從根源上解決數據定義和使用的不一致問題，為企業數據建設帶來諸多好處：

數據標準的統一制定與管理，可保證數據定義和使用的一致性，促進企業級單一數據視圖的形成，促進信息資源共享。

通過評估已有系統標準建設情況，可及時發現現有系統標準問題，支撐系統改造，減少數據轉換，促進系統集成，提高數據質量。

數據標準可作為新建系統參考依據，為企業系統建設整體規劃設計打好基礎，減少系統建設工作量，保障新建系統完全符合標準。

同時，數據標準建設也為企業各類人員提供相應的支撐：

對業務人員而言，數據標準建設可提升業務規范性，保障人員對數據業務含義理解一致，支撐業務數據分析挖掘以及信息共享；

對技術人員而言，有數據標準作為支撐，可提升系統實施工作效率，保障系統建設符合規范，同時降低出錯幾率，提升數據質量；

對管理人員而言，數據標準建設可提供更加完整、準確的數據，更好的支撐經營決策、精細化管理。

三、基于模型驅動的標準落標方案

1、落標關鍵點剖析

根據筆者的經驗與實踐，數據標準的落標需要重點考慮三大問題： 問題1：什么數據需要制定哪些標準？ 問題2：什么系統落什么標準？ 問題3：什么人與什么時間執行？ 如果這三個問題沒有想清楚，基本數據標準的梳理會停留在Excel層面，標準的政策會停留在墻上，無法走入每個設計者的頭腦和每個系統的每個字段。我們先來說第一個問題，什么數據需要制定標準，首先我們回到數據標準所要解決問題的初衷，數據標準主要解決數據在共享，融合，匯集應用中的不一致問題。好的，那么我們看哪些數據會出現在這個這三個環節中，以及哪些容易出現問題。對于與一個企事業組織來說，按照價值鏈，一般關注三大要素：客戶，產品，大運營。IBM和TD將銀行業劃分為九大概念數據，也是圍繞客戶與產品的大運營活動細分。那么有如下幾類數據會在數據應用過程中，會更多出現融合和匯總的機會，需要格外注意。

第二個問題和第三個問題是實際工作中非常困擾的，落標的大多數困難與此有關，因此我將其放在一起來說明。一般我將系統與數據分列如下列表：

通過這個表格的內容，我們發現數據標準從源頭落地，會減少數據的處理成本，提高數據應用的效益，缺點是對于存量系統和外購系統存在較大改動風險和成本。如果從數據的倉庫層進行落標，比較容易著手處理，落標后的下游數據系統則自動統一數據標準，然而數倉層的報表應用與業務系統的報表存在口徑不一致性在所難免，仍然需要源數據層進行必要調整。

無論從哪一層入手，模型的優良設計環節都是必要條件，否則整個落標過程會沒有抓手，流程也不順暢。

2、落標整體方案

無論是原系統數據還是數倉數據，都是不同的開發團隊負責，遵循軟件開發標準的流程包括設計，開發，測試，上線，維護等環節，因此我們需要在這個過程中，將數據標準這個優良的炮彈，送到最前線，同時，管理團隊需要參與這個過程的關鍵節點中，這需要企業在數據管理上提高管理和執行水平。

鑒于普通銀行當前的數據基礎水平，數據的落標同樣受到人力和財力的制約。所以一個自動化水平非常高的落標方案是非常切合我國普通銀行的發展階段的。因此，本落標方案的關鍵思想是在開發階段由模型設計人員進行落標，標準管理和架構管理人員進行評審和核準，同時，自動檢測能力來提高執行水平和激勵環節的落地。

《自動化落標方案》

2.1標準的定位

這里主要是在系統的需求設計和準備過程中，我們對數據標準需要準備好一些前提條件：

· 標準的技術規范已經準備好

數據標準已經具有詳細的技術規范，包括物理數據類型，可以直接應用的物理層上，并已經準備好邏輯數據類型到不同數據庫的類型映射。這里數據類型在DDM中是邏輯數據類型，具備自動類型轉換能力。

· 標準的主題已經準備好

標準的主題其實是標準的應用范圍和檢索目錄，對于具備條件的銀行應該設計出邏輯模型，對數據標準進行業務組織。這樣在落標過程中，這是重要的選擇依據。

· 標準已經權威發布

標準已經經過討論，進行了公開發布，具有流程上的正式性和權威性。

2.2模型設計中的落標

數據模型是一個更好的數據字典，其向上承接業務語義，向下實現物理數據，它不但包含了數據字典，更重要的是包含了業務的主題，業務主對象，數據關系，以及數據標準的映射。所以模型及其工具的運用不但是企業數據管理是否成熟的重要標志，也是數據標準落標的重要依托。不進行模型設計和管理，落標操作則事倍功半，因為失去了管理的最佳時機。通過創新一個模型工具，在開發階段，自動管理數據字典和模型，實現下面三個落標操作。

建立標準和數據的映射

標準落地的屬性繼承

一般情況下，數據字段落地標準時要引用標準中上述內容，另還包含數據的標準代碼，其中強制性一致的是標準中的技術規范。

物理字段的落地衍生

對于一個標準落地的物理字段，如果語義本質是相同的，并且業務規則沒有變化，不過滿足系統環境，而加上特定限定環境。比如“電話”在供應商的表里叫“供應商電話”，這是一種落地衍生情況，并不需要創建一個新的標準。如前一節所示有一些則需要新的標準或新的子類標準。

建立代碼的標準引用

對字段中的數據類型的引用進行標準化，堅決杜絕Comment里手工寫枚舉代碼的情況。

標準化命名

2.3模型的評審

在模型的開發基本完成后，在系統的測試階段，我們加入模型的評審環節，這個作為系統上線的前奏，避免上線前的修改造成時間緊張等情況。模型評審前需要創建模型基線，評審包含以下幾個內容：標準的落標引用模型工具應該自動提供報告，重點檢查是否有重要的標準沒有引用和落地，通過自動化的工具，智能發現落標的潛在問題。

自定義標準與詞典的評審和轉化

DDM模型工具具備自定義數據標準和詞典等能力，通過與開發團隊評審，提高自定義標準的轉化率，完善標準庫。

元數據的充足率

模型工具應該自動提供報告，列出中文名稱沒有填寫的字段。

其他模型質量

比如檢查模型主題覆蓋率等。

2.4上線的核準

一般情況下，系統的上線過程需要一個更加標準的流程，提交設計，文檔，測試報告，升級步驟等內容，有專業的團隊和流程工具來審核。在這個過程中，我們并不主張此環節進行落標的核準，因為此環節已經太晚，我推薦在評審環節完成落標工作，在此環節中，只需要提交落標和模型報告作為過審文檔。模型核準環節包含以下幾個工作要做：

模型生產庫基線與封板

根據評審時建立的模型分支，建立模型的生產庫基線，并進行封板操作。

模型基線報告

提供模型標準數據字典，標準落標報告，模型質量報告。

2.5自動監測變化

對于已經發布的模型，隨著進入維護期，某些升級的情況下，可能會有徒手修改庫表結構的情況發生，為了保證模型與生產庫的一致，在自動檢測階段，主要負責定期發現不一致的情況，并發出預警郵件，過程如下。

3、新增和變更流程

在實際落標過程中，需要新增或修改標準的情況是必然出現的。因此在設計階段或者模型評審階段，進行變更流程。

4、角色與人力安排

根據銀行當前的組織結構，需要有建立“標準和架構組”，至少2人編制，可以是虛擬組織結構和兼職角色。 數據架構師（1人）：由企業資深（10+年數據開發經驗）數據設計人員或管理人員擔任，熟悉行業數據模型和企業主流業務邏輯模型，比較熟悉各系統模型情況。主要負責模型管控，落標評審，模型質量等工作。標準管理員（1人）：由高級（5+年數據管理經驗）數據標準設計和管理人員擔任，比較熟悉標準和企業業務邏輯模型。主要負責標準維護，標準評審，模型質量提高等工作。

5、存量數據如何落標

存量系統的落標是很多企業進行標準化第一障礙，前面也進行了痛點分析，那么如何解決落標問題呢？我建議遵循下面方法。

存量系統先管理好數據模型和字典，這作為未來統一數據標準的基礎。

摸清模型存量系統不符標準的情況，尤其是那些標準代碼，編碼規則，存儲格式等嚴重影響數據指標和拉通匯集的情況。

根據非標問題的影響程度，制定未來的落標計劃，選擇合適的升級版本時機，進行逐項的落標。

未落標前，可以先落標ODS層或API層，這樣可以糾正后期應用的標準化問題。

6、標準代碼的多標準處理

企業里存在多套標準是非常有可能的，比如一個客戶類型的代碼，原系統一套標準，數倉一套標準，報送EAST模型可能又是一套標準，那么怎么管理這多套標準呢？

建議對標準進行有效范圍的定義，以明確每套標準的用途，比如原系統的標準作為地方標準，數倉的作為中央標準，EAST模型的標準作為對外標準。建立標準之間的映射管理，做好數據拉通的依據解決。這樣設計標準的維護和變更就可以重點選擇哪里進行新增，以及如何進行統一等。