データマネジメント知識体系(DMBOK)第10章「参照データとマスターデータ」
イントロダクション
ビジネス上の意義
ビジネス上の意義は、マスタデータにおいて重要なインプット。
マスターデータの可用性と品質向上は、データの全体品質と業務データの信頼性に劇的な影響を与える。付加的な恩恵としてIT環境の簡素化・効率化・生産性の向上、さらに顧客体験価値も向上する可能性がある。
組織のデータ要件を満たす
組織内の複数部署が、完全で一貫性があり信頼できる共通データセットにアクセスする必要がある。マスターデータをもとにして、このようなデータセットが作られることが多い。
データ品質管理
データの不整合、不良、欠落は誤った意思決定や機会損失につながる。マスターデータ管理により組織の重要な業務対象が一貫して評され、このリスクが軽減される。
データ統合コスト管理
すでに複雑になってしまった環境に新しいデータソースを統合する場合、マスターデータなしではよりコストがかかる。マスターデータにより重要な業務対象を定義し識別する方法に一貫性が生まれる。
リスクの削減
マスターデータを使用すると、データ共有アーキテクチャが簡素化され、複雑な環境につきもののコストとリスクを削減できる。
ゴールと原則
マスターデータのゴール
組織の業務プロ背う全体にわたり、完全で一貫性があり最新で信頼できるマスターデータを持つことが保証される
全社の業務機能とアプリケーション間でマスターデータが教諭できる
データ標準、共通データモデル、統合パターンを使用してコストを削減し、データ利用と統合の複雑さを軽減する
マスタデータの管理
共有データ:
マスターデータは組織全体で共有できるよう管理するデータ所有権:
マスターデータは組織に属し、特定のアプリケーションや部門に属さない品質:
継続的なデータ品質の監視とガバナンスを必要とするスチュワード任務:
データスチュワードはマスターデータの品質を管理し保証する責任を負う変更管理:
マスターデータは、ある時点において正確で最新であると組織が判断したものを反映。値の変更を富まぬルールは慎重かつ注意を払って適用する権限:
マスターデータの値は、正式記録システム（MDMシステム）からのみ複製する
本質的な概念
データの分類
参照データ:
コードとその意味
分類や、システム外部で管理されている情報を識別するエンタープライズ構造データ:
勘定科目、組織など
参照データに類似しているが、階層構造を持つトランザクション構造データ:
顧客、商品など
いわゆる伝統的なマスターデータ
（参考）Malcolm Chisholmの分類法を調べると以下のようになっている
マスターデータと参照データ
国内では特に区別している人にほとんどあったことがないが、海外メンバと会話すると区別してる人がぼちぼちいた
共通点
どちらもエンタープライズレベルで管理しなければならない共有リソース
同じデータを複数持つべきではない
データ間の不整合、そこから生じる曖昧さ → リスク
相違点
参照データは頻繁に更新されない、構造が単純で、インスタンス数も少ない
参照データは、企業外部で定義されるものであり、企業内では共同利用のために責任部署を決め、その取り込み・最新化を行う必要がある
参照データ管理では、値リスト（コード地とその名称・意味）を管理する
マスターデータでは粒度が課題となる
顧客を法人単位とするか？事業所単位とするか？
リファレンスデータの格納と構成
格納
構造
様々なリファレンスデータ
リファレンスデータの共通化と柔軟性のバランス
顧客ステータスの取りうる値を全社共通 vs. 個別システムのために柔軟に価追加
業界標準データ
業界団体や政府機関によって作成・維持されるデータ
データ共有と相互運用性の必要条件
演算用リファレンスデータ
例: 外国為替交換レート
タイムスタンプ付き（更新頻度に留意する必要あり）
マスターデータとゴールデンレコード
マスターデータはビジネスエンティティ（従業員、顧客、製品、財務構造、資産、場所など）に関するデータ
DMBOKに限らないが、欧米のデータモデルでは「パーティ（Party）: 人と組織の汎化概念」がよく登場する
マスターデータ管理
技術的に支えられた分野であり、業務とITが連携して、企業の公式共有マスターデータ資産の一貫性、正確性、スチュワード制、意味上の一貫性を実現し、結果責任を全うする。
マスターデータは、一貫性を持ち統一された識別子と拡張属性のセットであり、企業のコアエンティティを記述する。
コアエンティティには、顧客、見込顧客、国民、サプライヤ、サイト、階層、勘定科目などが含まれる
MDMの要件の評価
どの役割、組織、場所、ものが繰り返し参照されているか
人、組織、場所、ものを記述するためにどのデータが使われているか
人、組織、場所、ものというのが、まさにマスターデータとして管理したい領域。
ものに加えてサービスも含めたほうが良い
どのようにデータが買定義され、構造化されているか
どこでデータが作成/収集され、保存され、利用可能となるか
データがシステムを移動する際に、どのように変化するか
誰が、どのような目的でデータを利用するか
データ品質のために、どのような基準が使われるか
MDMはライフサイクル管理プロセス
MDMはライフサイクルの管理プロセスであり、以下アクティビティが必要
関連属性の定義と使用条件を含むマスターデータ・エンティティの環境の確立
同じ実態を示す複数のインスタンスを識別する→情報統合
ソース間でデータを統合する
不適切なインスタンスを判別した後、それが解決され、正しく関連付けていることを確認する
マスターデータに複数アプリケーションからアクセスできる方法を確立する
組織内で確実にマスターデータ値が使用されるようにする
マスターデータの主要処理手順
データモデル管理
明確で一貫した論理データモデル
全社レベルで使用される用途と定義
ソースと異なってもよい
データの取得
繰り返し可能プロセスであること
新しい要求に対応する
データ品質アセスメント
データ取得とマッチングの影響確認
担当者の決定
データの検証、標準化、強化
検証: デーtの間違い、欠落を特定する
標準化: リファレンスデータ値、書式、にデータ値が合致することを保証する
強化: エンティティ解決サービスの適用
エンティティの解決
実世界に存在する実態に対して複数の参照があった場合、それは同じ実態なのか異なる実態なのかを判断すること
一つにまとめるか、同等であることを示す値を介してリンクする
マッチング
アイデンティティの解決
マスターデータID管理
親子関係や提携関係の管理
データ共有とスチュワード制
ツールで自動化してもスチュワードの介在は必要
スチュワードの作業をもとにプロセス改善し自動化につなげる
代表的なマスターデータ
マスターデータ共有アーキテクチャ
アクティビティ
MDMアクティビティ
目的と要件の定義
難しいのは、アプリケーション間でマスターの標準要件を定義すること
まずは簡単なカテゴリから始める
データソースの評価と査定
属性がそろっているか？（メタデータ）
データ品質
アーキテクチャ的アプローチの定義
データの利用とモデルの共有を考慮する
ソースシステム数、利用システム数
SoRがあいまいな場合はデータ共有HUBが有用
マスターデータモデル作成
対象領域のエンティティと属性の定義を全社レベルで共有できる
スチュワード制と捕手プロセスの定義
マスターデータの継続的な品質維持が可能でなければならない
ソースシステムへのフィードバック
MDMソリューションに適用されるアルゴリズムの改善
マスターデータの使用を強制するガバナンスポリシーの確立
利用システムにマスターデータを入力する仕組み
ロードマップ
値の一貫性を維持する連携
リファレンスデータ
基本的な流れはMDMの場合と同様のため省略
ツールと技法
データ統合ツール
データ修復ツール
ODS
データ共有HUB
MDM専用アプリケーション
製品、勘定科目、パーティを管理するパッケージソリューションなど
導入ガイドライン
マスターデータとリファレンスデータ管理はデータ統合の1形態
データ統合と相互運用性に適用される実施原則がMDMとRDMにも適用
組織と文化の変革
局所管理 -> 全体管理 で仕事がより複雑になる
手順と習慣を変えるので、その意義、氏名、将来のビジョンとニーズを共有し、実践する
ガバナンスが最も困難な文化的変革（責任と判断）
データスチュワード
アーキテクト
マネージャー
チーム
プログラム運営委員会
データガバナンス評議会
リファレンスデータとマスターデータのガバナンス
リファレンスデータとマスターデータは教諭リソース
ガバナンスなしでは、データ統合ソリューションを新たに追加するだけに終わる
明確にすべきポイント
統合すべきデータソース
強制すべきデータ品質ルール
従うべき利用規則の条件
データスチュワード制の取り組みの優先度と対応レベル
プライバシー
セキュリティ
評価尺度
データ品質とコンプライアンス
データ変更アクティビティ
データの取り込みと利用のモニタリング
サービスレベルの合意
データスチュワードの責任範囲
総所有コスト
データ共有量と使用量
この記事が気に入ったらサポートをしてみませんか？