- 產品
- 產品解決方案
- 行業解決方案
- 案例
- 數據資產入表
- 賦能中心
- 伙伴
- 關于
時間:2024-02-19來源:在這個世界瀏覽數:73次
通常,當我們考慮數據治理時,我們會從小事開始,或者至少是“容易限制在幾個表中”的事情。當我們尋求元鏡像和反映現實的數據的目標時,我們需要從數據所代表的大目標驅動的事情開始。
數據資產是數據業務控制的基礎。這是關于資產的元數據樹的開始,該樹需要跨越資產生命周期的每個部分及其所有表現形式。
我們不詳細討論細節,而是嘗試構建挑戰,以便我們能夠以連貫且可管理的方式應對這些挑戰,從業務角度而不是數據庫表的角度開始。
數據資產不是數據產品,數據資產的目的不是成為可部署的元素,它有不同的目標:
數據資產是具有已知業務價值的數據的可治理邊界。
我們這里的重點是定義組織邊界而不是模式。關于數據作為資產,我們想要了解的只是幾件事:
它是什么
哪個業務領域“擁有”該資產
哪些業務領域從資產中獲得價值
我們將如何衡量價值
大多數數據工作都犯了直接深入細節的錯誤,并選擇“簡單”的東西(例如“客戶”)作為非常清晰的數據資產。我永遠不會說主數據不重要,但正如我一直所說的, MDM 是聯邦世界中的外部參考。我們應該從資產入手,了解我們想要治理的現實世界,以便它準確地反映現實。不要從底部開始向上工作,而是從頂部開始向下工作。
以下是數據資產的一些良好起點的示例:
市場需求——對正在發生的事情的外部看法
銷售需求——來自市場、銷售和接受訂單的內部觀點
新產品——將新產品推向市場所需的信息
產品執行——在市場上銷售、分銷和維護產品所需的信息
碳影響——衡量整個內部和外部生命周期的碳影響
我建議從這個高層次開始的原因是,當您解構這些元素時,這提供了一種更簡單的方法來映射價值。例如,“客戶”是市場需求、銷售需求、產品執行和碳影響的核心。這并不意味著客戶不會成為數據資產,它絕對會成為數據產品,這意味著當你接觸到客戶時,你已經在定義它所在的數據資產上下文。
人們在看待數據價值時犯的另一個明顯錯誤是以兩種方式看待問題
端到端流程
業務部門
這些不是好的數據資產,它們使用數據資產,它們可以是數據資產提供價值的方式,但它們不應該是對數據資產的看法。數據資產需要明確的企業所有權嗎?是的。數據資產是否需要明確的方式來實現其價值?是的。
但僅僅將結構模型從一種方法復制到另一種方法并不是一個好主意。正如流程模型會產生糟糕的服務模型一樣,服務模型和流程模型也會產生糟糕的數據資產結構。但簡單的說法是數據資產:反映企業的運營和戰略現實。
數據資產的目標是與現實相匹配,這是唯一真正的質量衡量標準,因此它需要存在能力來實現這一目標,但它本身并不是一個“可操作”的東西。它用于行動,驅動決策。為此,我們可能在資產中擁有復雜的人工智能模型,計算指標并提供消費者可以訂閱的信息流。
要成為數據資產,我們需要知道它如何提供價值,以及如何衡量該價值。那么對于市場需求,我們為什么將其視為資產?它將如何幫助我們提高營收價值或降低營收成本?該數據資產將影響哪些組織 KPI?我們如何將資產與這些 KPI 連接起來?
后一點至關重要,這不僅僅是說“市場需求將影響營銷支出”或“市場需求將減少未售出的庫存”,而是繪制從資產到 KPI 的界限。一開始這些可能很模糊,但需要盡快變得具體。
如果數據資產不具有可衡量的價值,則不應將其視為資產。確定該價值以及如何衡量它可能是一項復雜的任務,因此從高級資產開始是有意義的,因為我們可以將它們鏈接到更高階的元素,并且當我們進一步分解價值時,我們可以將其鏈接到特定的子資產和實際操作數據產品本身。
因此,在考慮數據資產時,不要首先考慮“流程 X 使用哪些數據”或“部門 Z 創建哪些數據”,而是首先考慮如何解構業務運營和戰略現實。這將包括內部數據和來自協作數據生態系統的外部數據。想想如何從數據角度劃分現實,而不是當前報告幾小時或幾天前發生的事情的表格。
以業務為中心的數據之旅需要從實現元鏡像的目標開始。數據資產的一個重要特點是它們可以在較低級別的數據資產和它們使用的數據產品中重疊。當我們將資產分解為產品時,治理不會是線性的,因此為什么從頂層開始是至關重要的。