為什麼資料資產管理首先從頂層設計開始

通常，當我們考慮資料治理時，我們會從小事開始，或者至少是“容易限制在幾個表中”的事情。當我們尋求元映象和反映現實的資料的目標時，我們需要從資料所代表的大目標驅動的事情開始。

資料資產是一棵大樹的根

資料資產是資料業務控制的基礎。這是關於資產的後設資料樹的開始，該樹需要跨越資產生命週期的每個部分及其所有表現形式。

我們不詳細討論細節，而是嘗試構建挑戰，以便我們能夠以連貫且可管理的方式應對這些挑戰，從業務角度而不是資料庫表的角度開始。

什麼是資料資產

資料資產不是資料產品，資料資產的目的不是成為可部署的元素，它有不同的目標：

資料資產是具有已知業務價值的資料的可治理邊界。

我們這裡的重點是定義組織邊界而不是模式。關於資料作為資產，我們想要了解的只是幾件事

1. 它是什麼

2. 哪個業務領域“擁有”該資產

3. 哪些業務領域從資產中獲得價值

4. 我們將如何衡量價值

從有目的的大事開始

大多數資料工作都犯了直接深入細節的錯誤，並選擇“簡單”的東西(例如“客戶”)作為非常清晰的資料資產。我永遠不會說主資料不重要，但正如我一直所說的， MDM 是聯邦世界中的外部參考。我們應該從資產入手，瞭解我們想要治理的現實世界，以便它準確地反映現實。不要從底部開始向上工作，而是從頂部開始向下工作。

以下是資料資產的一些良好起點的示例

1. 市場需求——對正在發生的事情的外部看法

2. 銷售需求——來自市場、銷售和接受訂單的內部觀點

3. 新產品——將新產品推向市場所需的資訊

4. 產品執行——在市場上銷售、分銷和維護產品所需的資訊

5. 碳影響——衡量整個內部和外部生命週期的碳影響

我建議從這個高層次開始的原因是，當您解構這些元素時，這提供了一種更簡單的方法來對映價值。例如，“客戶”是市場需求、銷售需求、產品執行和碳影響的核心。這並不意味著客戶不會成為資料資產，它絕對會成為資料產品，這意味著當你接觸到客戶時，你已經在定義它所在的資料資產上下文。

資料資產不是流程或服務

人們在看待資料價值時犯的另一個明顯錯誤是以兩種方式看待問題

1. 端到端流程

2. 業務部門

這些不是好的資料資產，它們使用資料資產，它們可以是資料資產提供價值的方式，但它們不應該是對資料資產的看法。資料資產需要明確的企業所有權嗎?是的。資料資產是否需要明確的方式來實現其價值?是的。

但僅僅將結構模型從一種方法複製到另一種方法並不是一個好主意。正如流程模型會產生糟糕的服務模型一樣，服務模型和流程模型也會產生糟糕的資料資產結構。但簡單的說法是資料資產：反映企業的運營和戰略現實。

資料資產的目標是與現實相匹配，這是唯一真正的質量衡量標準，因此它需要存在能力來實現這一目標，但它本身並不是一個“可操作”的東西。它用於行動，驅動決策。為此，我們可能在資產中擁有複雜的人工智慧模型，計算指標並提供消費者可以訂閱的資訊流。

目的需要有價值的措施

要成為資料資產，我們需要知道它如何提供價值，以及如何衡量該價值。那麼對於市場需求，我們為什麼將其視為資產?它將如何幫助我們提高營收價值或降低營收成本?該資料資產將影響哪些組織 KPI?我們如何將資產與這些 KPI 連線起來?

後一點至關重要，這不僅僅是說“市場需求將影響營銷支出”或“市場需求將減少未售出的庫存”，而是繪製從資產到 KPI 的界限。一開始這些可能很模糊，但需要儘快變得具體。

如果資料資產不具有可衡量的價值，則不應將其視為資產。確定該價值以及如何衡量它可能是一項複雜的任務，因此從高階資產開始是有意義的，因為我們可以將它們連結到更高階的元素，並且當我們進一步分解價值時，我們可以將其連結到特定的子資產和實際運算元據產品本身。

著眼大局而不是區域性

因此，在考慮資料資產時，不要首先考慮“流程 X 使用哪些資料”或“部門 Z 建立哪些資料”，而是首先考慮如何解構業務運營和戰略現實。這將包括內部資料和來自協作資料生態系統的外部資料。想想如何從資料角度劃分現實，而不是當前報告幾小時或幾天前發生的事情的表格。

以業務為中心的資料之旅需要從實現元映象的目標開始。資料資產的一個重要特點是它們可以在較低階別的資料資產和它們使用的資料產品中重疊。當我們將資產分解為產品時，治理不會是線性的，因此為什麼從頂層開始是至關重要的。