7.9 マスターデータと参照データの管理

概要と動機

組織に顧客が何人いるかを五つのシステムに尋ねると、五つの異なる数字が返ってきます。一つはメールアドレスを数え、一つは契約を数え、一つはログインを数え、二つは「Acme Corp」と「ACME Corporation」が同じ会社かどうかで意見が分かれます。マスターデータ管理(MDM)は、ビジネスが共有する中核のエンティティ、顧客、製品、サプライヤー、従業員、場所を、すべてのシステムが信頼できる一つの権威ある版へと突き合わせる規律です。

まずデータを三つの種類に分類してください。必要とする扱いが異なるからです。マスターデータは、ビジネスの名詞を記述します。多くのプロセスが参照する人、場所、物。参照データは、それらのプロセスが使う統制された語彙です。通貨コード、国コード、単位のリスト、製品カテゴリー。トランザクションデータは動詞を記録します。行われた注文、なされた支払い、送られた出荷。マスターデータと参照データはトランザクションよりも量が少ないですが、あらゆる所で参照されるので、そこでの誤りは下流のすべてを汚染します。

間違えるコストは具体的です。同じ顧客が少しずつ異なる四つのレコードとして存在すると、カタログを四通郵送し、保つ価値のある一つの関係を見られず、顧客あたりの収益の数字は静かに間違います。ゴールデンレコード、つまり多くの源から組み立てられたエンティティの単一の信頼できる版が、それらの衝突するコピーを置き換えるので、すべての統合が同じマッチングの問題を解き直すのをやめます。

数十年の成長と買収で蓄積されたシステムを突き合わせる企業にとって、MDMは、一貫した顧客ビューと、永続的な突き合わせの税の違いです。政府にとって、賭け金は上がります。三つの機関で三人の異なる人物として現れる市民は、給付を拒否されたり、二重に課税されたり、部門の間で見失われたりしえます。本章は、所有と方針を設定するデータ戦略とガバナンス(7.1章)、エンティティが何を意味するかを定義するデータモデリングとセマンティックレイヤー(7.7章)、レコードを時間にわたってきれいに保つデータ品質とオブザーバビリティ(7.8章)を補完します。

主要原則

データをマスター、参照、トランザクションに分類します。それぞれに異なる扱いが必要です。
現実世界のエンティティごとに一つのゴールデンレコード。偶然に発見されるのではなく、意図して組み立てられます。
流行ではなく、制御とレイテンシのニーズに合うMDMのアーキテクチャのスタイルを選びます。
マッチングとサバイバーシップはビジネスルールです。書き留め、スチュワードが調整できるようにします。
参照データは共有の語彙です。APIのようにバージョンを付けて公開します。
ガバナンスとスチュワードシップがMDMのエンジンです。ソフトウェアは単なるツールです。
ゴールデンレコードをイベントとして伝播し、下流のシステムが古くならず同期を保つようにします。
MDMを、読み込まれたレコードではなく、改善された決定と取り除かれた重複で測定します。

推奨事項

まずマスター、参照、トランザクションのデータを分類する

分類していないものは管理できないので、データのドメインを分類することから始めます。マスターデータの有用なテストは、間違った値が伝播するかです。一つの悪い住所が請求、出荷、法的な通知に波及するなら、マスターデータを見ています。これが投資を駆動します。注文の明細行ではなく、顧客のエンティティのためにマッチングエンジンを築きます。ドメインに明示的に名前を付け、その重複がどれだけの痛みを引き起こすかで順位づけし、最も痛い一つか二つから始めます。通常、収益に直接触れるので、顧客と製品です。

MDMのアーキテクチャのスタイルを意図して選ぶ

一般的なアーキテクチャのスタイルが四つあり、正しいものは、どれだけの権限を集中でき、変更がどれだけ速く伝播しなければならないかによります。レジストリのスタイルは、データを源のシステムに残し、マッチした識別子のインデックスだけを築くので、データを動かさずに「これら五つのレコードは同じ顧客だ」に答えられます。安く低リスクですが、読み取り専用で、源を直せません。統合のスタイルは、コピーを中央のハブに引き込み、レポーティングのためにそれらをゴールデンレコードにマージしますが、訂正を押し戻さないので、源は乱雑なままです。共存のスタイルはさらに進み、きれいにされた値を源のシステムに同期して戻すので、源は独立して運用されながら、時間とともに改善されます。集中型あるいはトランザクション型のハブのスタイルは、MDMのハブ自体を記録のシステムにし、そこでエンティティが直接作成され編集され、他のすべてのシステムがそこから消費します。最も強い一貫性と制御を与えますが、仕事が行われる場所を変えるので、採用が最も難しい。多くの組織は、価値を証明するレジストリから、信頼が育つにつれて共存へと進み、異なるドメインにわたって複数のスタイルを動かします。

マッチ、マージし、サバイバーシップのルールを明示的に設定する

MDMの核心は、二つのレコードが同じ現実世界のものを記述するのはいつかを決めることです。これはレコードリンケージで、実際のデータは誤字、略語、欠けた項目だらけなので、正確なキーの一致ほど単純であることはまれです。決定的マッチングは、選んだ項目に正確なルールを使います(同じ納税者ID、あるいは同じメールプラス郵便番号)。確率的マッチングは、近似文字列マッチングと重みを使って多くの項目にわたる類似度を採点するので、「Bob Smith, 12 Main St」と「Robert Smith, 12 Main Street」は、閾値を超える可能性の高い一致と判断できます。どのレコードが同じエンティティを指すかを決めることはアイデンティティ解決と呼ばれ、顧客ビューから不正検知まであらゆるものを動かします。

レコードがマッチしたら、どの値がゴールデンレコードに生き残るかを決めなければなりません。これらのサバイバーシップのルールはビジネスロジックなので、明示的にします。電話番号には最新の値、住所には最も完全な値、法的な名前には最も信頼できる源を好む。マッチが自動でマージされる閾値の帯、自動で却下されるより低い帯、人間が決める中間の帯を設定し、それがスチュワードシップの住む所です。すべてのマージを元に戻せて記録されるようにしてください。二人の本物の顧客を融合する間違ったマージは、見逃しより悪いからです。

参照データをバージョン管理された共有の語彙として扱う

参照データは、システムが話す共有の語彙で、ずれる語彙は静かな不整合を引き起こします。あるシステムがISOの国コード「GB」を使い、別のシステムが「UK」を使うと、結合は失敗し、数がずれます。各参照のリストを一か所の統治された場所で維持し、すべての消費者のために公開し、決定的に、バージョンを付けます。コードは時間とともに追加され、退役し、分割され、統合されるので、リストをその場で上書きすると、古いコードのもとで正しかった過去のレポートを壊します。

参照データセットを、コントラクトを伴うAPIのように扱います。消費者が「この日付に有効な地域コードは何だったか」と尋ねられるよう、有効日付とともに公開し、削除するのではなく退役したコードを保ち、コードの意味が変わったときの対応づけを記録します。ISOの国と通貨のコードのような、存在する所では認められた外部の標準を好みます。標準は相互運用性をただで与え、3.8章のオープン標準の規律につながるからです。

フラットなレコードだけでなく、階層と関係をモデル化する

マスターデータは独立した行の山ではなく、関係の網です。顧客は世帯と企業の親会社に属します。製品はカテゴリーとブランドに集約されます。これらの階層は本物のビジネス上の意味を運びます。企業の親会社で売上を集約すると、個々のアカウントで集約するのと全体像が変わります。消費者が、各チームが独自の集約を発明するのではなく、これらの関係を一貫してたどれるよう、明示的にモデル化します。

一つのエンティティが複数の階層を同時に必要とするケースに注意してください。製品は、財務には一つの方法で、商品企画には別の方法で集約されることがあり、どちらも正当なので、一本の真の木を強いるのではなく、複数の名前付きの階層をサポートします。ドメイン間の関係も重要です。どのサプライヤーがどの製品を提供するかなど。

ゴールデンレコードをセマンティックレイヤーとデータ品質に配線する

MDMが生み出すゴールデンレコードは、7.7章のセマンティックレイヤーが指標を定義するときに参照する、信頼できるエンティティです。「アクティブな顧客」は、「顧客」が曖昧でないときにだけ意味を持ちます。ゴールデンレコードをセマンティックレイヤーに供給し、すべての指標が同じ重複排除され解決されたエンティティを数えるようにします。

MDMとデータ品質(7.8章)は、一枚のコインの表裏です。品質のチェックが、MDMが解決する重複、ヌル、形式の違反を検知し、MDMのマッチングは、チェックが見逃した品質の問題を表面化させます。マスターデータそのものに、継続的な品質監視を実行します。重複率、マッチの信頼度の分布、主要な項目の完全性、レビューの待ち行列のサイズ。そうすれば、ずれが消費者に見える前に表面化します。

イベントを通じてゴールデンレコードを伝播する

下流のどのシステムにも見えないゴールデンレコードは、誰も助けません。最も強いパターンはイベント駆動の伝播です。エンティティが作成、マージ、訂正されたとき、MDMのハブが変更イベントを公開し、購読するシステムがローカルのコピーを更新します。これはイベント駆動アーキテクチャと7.2章のストリーミングのパターンの上に築かれ、全員を一日古いままにする脆い夜間のバッチ同期なしに、数十のシステムを一貫して保ちます。

イベントを、役立つだけの文脈とともに公開します。エンティティの識別子、何が変わったか、新しい生き残った値、消費者が更新を順序づけ、見逃したものを検知できるバージョン。消費者を冪等にして、イベントの再生が害をなさないようにし、購読できないシステムにはAPIを提供します。データアーキテクチャとストレージ(3.4章)の原則が当てはまります。ゴールデンレコードが流れるよう設計します。誰も消費しないものは、高価なスプレッドシートにすぎないからです。

ツールの前にスチュワードシップとガバナンスを割り当てる

MDMは技術プロジェクトとして失敗し、ガバナンスのプロジェクトとして成功します。重要な役割はデータスチュワードで、特定のドメインの品質とルールに責任を負う人です。曖昧なマッチを解決し、サバイバーシップのルールを調整し、二つの部門が「サプライヤー」が何を意味するかで意見が分かれるとき調停します。スチュワードは通常、エンジニアではなく、深い領域の知識を持つビジネスの人々で、本物の権限と割り当てられた時間を必要とします。権限のないパートタイムのスチュワードシップは、MDMが止めるはずだったまさにそのずれを生むからです。

スチュワードを、7.1章のガバナンスの構造で包みます。各ドメインに責任を負うデータ所有者、ドメイン横断の論争を解決する評議会、誰がマスターレコードを作成あるいはマージしてよいかの明確な方針。顧客のマッチングのルールは、人員の入れ替わりを生き延びなければならない組織の知識なので、決定を文書化します。ツールはガバナンスに仕えます。スチュワードに名前を付ける前にMDMのプラットフォームを買うことは、運転手のいないエンジンを買うことです。

トレードオフ: 長所と短所

MDMのスタイル	長所	短所
レジストリ(インデックスのみ)	安く、低リスク、源は手つかず	読み取り専用。源のデータを直せない
統合(中央のコピー)	分析のためのきれいなレコードを素早く	源は乱雑なまま。書き戻しなし
共存(源に同期して戻す)	源が改善される。バランスの取れた制御	統合が増える。管理すべき同期の競合
集中型/トランザクション型のハブ	最も強い一貫性と制御	最高のコスト。仕事が行われる場所が変わる
決定的マッチング	予測可能、説明可能、監査可能	誤字、変種、乱雑なデータを見逃す
確率的マッチング	現実の変動を捉える	調整が必要。不注意だと誤ったマージ

MDMの中心的な緊張は、制御対混乱です。最もきれいで一貫したデータを与えるスタイル(共存と集中型のハブ)は、まさに源のシステムとその所有者の働き方に最も侵入するもので、その侵入こそ、MDMのプログラムが行き詰まる所です。実用的な道は、低リスクのスタイルで信頼を稼ぎ、ビジネスケースが明確な所でのみ、より強い制御へ動くことです。マッチングのトレードオフは並行しています。決定的なルールは監査可能だが脆く、確率的な採点は強力だが、スチュワードシップと、ときどきの誤ったマージへの許容を要求します。成熟したプログラムのほとんどは両方を混ぜます。

チームで議論すべき問い

どのマスターデータのドメインが実際に痛みを引き起こしていて、すべてを一度に扱うのではなく、コストで順位づけしましたか。 多くのMDMのプログラムは、自らの野心の下で崩れます。企業内のすべてのエンティティを一度にマスターしようとして、二年間何も届けない。生産的な動きは、重複と衝突が本物のお金や信頼を犠牲にしている一つか二つのドメイン、通常は顧客か製品を見つけ、そのコストを定量化することです。無駄なメール配信、突き合わせの時間、間違った収益の数字、監査の指摘。システムにわたって同じエンティティが複数の形で現れる具体的な例を持ち込み、その順位づけに、どこから始めるかを教えさせてください。狭く測定可能な勝利が、拡大するのに必要な信頼性を築くからです。
各マスターデータのドメインを誰が所有し、スチュワードは仕事を実際に行う権限と時間を持っていますか。 権限を持つスチュワードシップのないMDMのツールは、運転手のいない車で、最もよくある失敗のモードは、スライドの上でスチュワードに名前を付けながら、本物の権限も割り当てられた時間も与えないことです。曖昧なマッチを解決し、「顧客とは何か」の論争を解決する人々は、領域の専門知識、決定の権限、守られた時間を必要とします。組織図を持ち込み、最上位のドメインについて、二つのレコードが同じ人物かを正確に誰が決め、営業と財務が意見が分かれるとき誰が調停するかを問ってください。その人を名指しできず、その割り当てられた時間を指させないなら、プログラムを沈めるギャップが見つかりました。
二つのレコードをゴールデンレコードにマージするとき、決定を説明して元に戻せますか。そして生き残る値はどこから来ますか。 サバイバーシップのルールは、ほとんどのチームが書き留めたことのないビジネスロジックで、それは、マージが読み込みの順序やツールの既定の偶然で起こり、二人の本物の顧客を融合する間違ったマージは元に戻すのが苦痛だということを意味します。本物のマージされたレコードを持ち込み、生き残る各項目を、その源とルールまでたどってください。なぜこの住所、なぜこの名前、なぜこの電話番号か。すべてのマージが記録され元に戻せること、不確かなマッチの中間の帯が、自動でマージされるのではなく人間に回ることを確認してください。特定のゴールデンレコードを説明できないなら、スチュワードは監査人にも不当に扱われた顧客にもそれを擁護できません。
計画しているドメインごとにどのMDMのアーキテクチャのスタイルが合い、源のシステムの所有者に課す混乱に対して、その選択を擁護できますか。 選ぶスタイルは、データをどれだけきれいにでき、源を所有するチームにどれだけ侵入するかを決め、流行やベンダーの売り込みで、制御対混乱の現実ではなく選ぶことが、プログラムが途中で行き詰まる方法です。レジストリは安く価値を証明しますが、源を決して直さず、集中型のハブは最も強い一貫性を与えますが、レコードが作成される場所を移し、それは技術的な変更に装った組織的な変更です。各候補のドメインについて、源の所有者に実際にどれだけの権限を持つか、下流のコピーがどれだけ新鮮でなければならないか、書き戻しが既存のワークフローで何を壊すかの誠実な見立てを持ち込んでください。企業と政府の設定では、記録のシステムを移す移行と変更管理のコストを加えてください。日々の仕事が移るチームは、相談されなかったハブに抵抗し、止まった共存の展開は、出荷される控えめなレジストリより高価だからです。
マッチングの閾値をどう調整し、各ドメインで耐えられる誤ったマージと見逃したマッチの率に合意しましたか。 すべての確率的マッチングエンジンは、誤ったマージ(二つの本物のエンティティを融合する)と見逃したマッチ(一つのエンティティを分割したままにする)を交換し、そのバランスは、ツールに誰かが残した既定ではなく、ビジネスの決定です。自動マージと自動却下の帯を広く設定しすぎると、ゴールデンレコードを静かに破損し、狭すぎると、人間のレビューの待ち行列が、スチュワードが片付けられるより速く育ちます。現在の信頼度の分布、レビューの待ち行列のサイズと経過日数、両方の種類の誤りのサンプルを持ち込み、部屋が各方向の本物のコストを見られるようにしてください。政府のアイデンティティのドメインでは、見逃したマッチと人間のレビューに強く傾けてください。間違ったマージは、給付を拒否したり、ある市民のデータを別の市民に露出したりしえ、その誤りの異議申し立てと監査のコストは、スチュワードが来週解決する重複のコストをはるかに上回るからです。
下流のシステムは、ゴールデンレコードが変わったことをどう知り、決定が間違う前に、それぞれがどれだけ古くてよいですか。 完全に解決されたゴールデンレコードも、どのシステムも消費しなければ高価なスプレッドシートで、伝播の仕組み、変更イベント、購読API、夜間のバッチのいずれであれ、すべての依存する決定がどれだけ最新かを静かに設定します。イベント駆動の伝播は、数十の消費者をほぼリアルタイムに保ちますが、冪等な消費者とバージョン管理されたイベントを要求し、夜間の同期はより単純ですが、全員を一日古いままにし、それはマーケティングのリストには問題なくても、不正のチェックには危険かもしれません。消費するシステムの一覧、それぞれが実際に必要とする鮮度、今日更新を見逃した消費者がどう回復するかを持ち込んでください。大きなあるいは公的な組織では、これらのイベントのコントラクトを誰が所有し、購読者が落とされたメッセージをどう検知するかを名指ししてください。一つの機関に届かずに静かに失敗するエンティティの変更は、MDMが取り除くために資金を出された断片化そのものを再現するからです。

セクター別の視点

スタートアップ。 少数のエンジニアと余裕のない猶予なら、MDMのプラットフォームは買わないでください。数字を損なっている一つのエンティティ、通常はセルフサービスと営業にわたって重複した顧客を、すでに動かしているウェアハウスのマッチングのジョブと、毎週不確かなマッチをレビューする一人でマスターしてください。悪いルールが顧客との関係ではなく午後を犠牲にするよう、すべてのマージを記録して元に戻せるようにし、手作業のレビューの待ち行列が一人のレビュアーを超えて育ったときにだけ、より重いツールを見直します。

小規模事業者。 データスチュワードも予算もないので、買うか作らないかの決定として扱い、無料で得られる標準に頼ってください。保守できないオーダーメイドのハブよりも、すでに連絡先を重複排除し、ISOの国と通貨のコードを話すツールを好み、重複が本物のお金を犠牲にするドメイン、通常は顧客か製品を一つ選びます。一人の週のごく一部であっても、責任を名前のある所有者に割り当ててください。誰も見ていないのにずれる語彙が、レポートを静かに壊すものだからです。

大企業。 買収を通じて蓄積された十数のERPとCRMのシステムにわたって、仕事はポートフォリオのガバナンスです。その重複のコストでドメインを順位づけし、ビジネスに権限を持つスチュワードを立ち上げ、グループが同じマッチングの問題を解き直すのをやめるよう、サバイバーシップのルールと参照データのバージョニングを標準化します。統合と恒久的なスチュワードシップのコストを明示的に予算化し、源が時間とともに改善されるよう、ゴールデンレコードをバージョン管理されたイベントとして伝播し、MDMを、一度きりの掃除ではなく、重複率とレビューの待ち行列の指標を備えた測定されるプログラムとして管理します。

政府。 調達規則、厳格なデータ共有法、公的な説明責任があらゆる選択を形づくります。人物のエンティティを統治された国の識別子でキーにし、参照データを有効日付でバージョン管理して過去のレコードが正しく保たれるようにし、アイデンティティ解決を意図して保守的にします。不確かなマッチは、自動化されたマージではなく、訓練を受けたスチュワードに回します。間違ったマージは、給付を拒否したり、ある市民のデータを別の市民に漏らしたりしえるからです。監査と異議申し立てのためにすべてのマッチを記録し、ベンダーにデータの可搬性とマッチングロジックの開示を求め、機能全体を、公共部門がすでにコミットしている相互運用性の標準の内側に保ってください。

事例

スタートアップ。 急成長するソフトウェア会社は、セルフサービスの登録と営業チームの両方を通じて販売しており、二つのチャネルが少しずつ異なる会社名で同じ顧客を二度作ります。アカウントあたりの収益は間違って見え、営業チームは既存のユーザーに飛び込みの電話をかけ続けます。重いプラットフォームを買う代わりに、軽量なレジストリから始めます。メールのドメインと正規化された会社名でレコードを結びつける、ウェアハウスのマッチングのジョブと、毎週不確かなマッチをレビューする一人のパートタイムのスチュワード。コストは小さく、レポーティングの誤りを直し、成長につれてさらなる投資を正当化する価値を証明します。

大企業。 世界的な製造業者は、買収を通じて成長し、十数のERPとCRMのシステムを動かしており、それぞれが独自のサプライヤーのレコードを持つので、同じサプライヤーが十五通りに現れ、会社は一つの買い手として交渉することも、本当の支出を見ることもできません。サプライヤーと製品のドメインのために、共存型のMDMのハブを立ち上げ、税と登録の識別子に決定的マッチングを、名前と住所に確率的な採点を使います。調達の名前のあるスチュワードがサバイバーシップのルールを調整してレビューの待ち行列を処理し、ゴールデンレコードは変更イベントとして公開されて各ERPに戻って流れるので、きれいにされたデータが源を改善します。統合された支出の可視性が、より良い契約条件を開き、財務が四半期ごとに消費していた突き合わせの税は大きく減ります。

政府。 ある国の政府は、データ共有への厳格な法的制限を尊重しながら、機関が市民を、すべての窓口で見知らぬ人としてではなく、一人の人として扱うことを望みます。人物のエンティティのために、統治された国の識別子をキーとする集中型のマスターデータのハブを築き、参照データは有効日付でバージョン管理して過去のレコードが正しく保たれます。アイデンティティ解決は意図して保守的です。不確かなマッチは、自動化されたマージではなく、訓練を受けたスチュワードに回されます。間違ったマージは誰かの給付を拒否したりデータを露出させたりしうるからで、すべてのマッチは監査と異議申し立てのために記録されます。見返りは、重複したレコードの減少、分割されたアイデンティティによる不正の減少、そしてすべての窓口で自分が誰かを証明する必要のない市民で、3.8章の相互運用性の標準の内側で達成されます。

ビジネスケース: 動機、ROI、TCO

MDMの見返りは、ほとんどの組織が名指しせずに払っている税を取り除くことから来ます。重複して衝突するレコードは、明白な形でお金を犠牲にし(同じ人への五回の無駄なマーケティング、古い住所による出荷のエラー、逃した大口割引)、それほど明白でない形でも犠牲にします(カウントを突き合わせるアナリスト、静かに間違った数字で決定する経営者、どのレコードが本物か解きほぐすのに時間を請求する監査人)。統合されたサプライヤーのビューは、より良い契約条件だけで、プログラム全体の元を取ることがよくあります。

総所有コストには三つの部分があります。プラットフォームあるいは構築、源と消費者への統合、そして時間とともに最大のものとして、継続的なスチュワードシップ。十数の古い源のシステムをつなぐことがMDMのプログラムがスケジュールと予算を失う所なので、統合のコストは過小評価しやすく、スチュワードシップのコストは、一度きりの構築ではなく恒久的な運用費なので、忘れやすい。リーダーシップに論拠を示すには、MDMを彼らがすでに追跡している数字に結びつけます。収益の正確性、マーケティングの効率、調達の節約、監査のコスト、規制上のリスク。それから狭く始め、高い痛みの一つのドメインでの測定された勝利に、拡大の資金を出させます。

アンチパターンと落とし穴

海を沸かすスコープ: すべてのドメインを一度にマスターし、何年も何も届けず、最初の勝利の前にスポンサーシップを失うこと。
ガバナンスの前のツール: スチュワードと所有者に名前を付ける前にMDMのプラットフォームを買い、エンジンに運転手がいないこと。
権限のないパートタイムのスチュワード: 本物の権限も守られた時間も与えずに、スライドの上でスチュワードシップを割り当てること。
静かなサバイバーシップ: 書面のルールもなく、ゴールデンレコードを説明する方法もなく、ツールの既定や読み込みの順序でレコードをマージすること。
元に戻せないマージ: 取り消しなしに不確かなマッチを自動でマージし、二つの本物のエンティティの間違った融合が恒久的な損害になること。
その場で上書きされる参照データ: バージョニングなしにコードのリストを編集し、古いコードのもとで正しかったすべての過去のレポートを壊すこと。
誰も消費しないゴールデンレコード: どの下流のシステムも購読しない純粋なハブを築き、きれいなデータが決定に届かないこと。
標準のコードの再発明: ISOの標準が存在するのに独自の国や通貨のリストを作り、理由なく相互運用性を失うこと。

成熟度モデル

レベル1、開始: マスターデータと参照データは管理されていません。同じエンティティが権威ある版なしに何度も存在し、コードのリストは分岐し、マッチングは手作業で反応的で、誰も問題を所有しないので、中核のエンティティのカウントが食い違い、どれが正しいか誰も言えません。
レベル2、発展: 主要なドメインが認識され、誰かがそれらを、しばしばレポーティングのためにウェアハウスで重複排除します。基本的な決定的マッチングが存在し、参照のリストが集められ、数人が非公式のスチュワードとして働きますが、実践はチームごとに異なり、源は乱雑なままで、ルールは紙ではなく人々の頭の中に住んでいます。
レベル3、標準化: MDMは、組織全体で一貫して適用される統治されたプログラムです。マスターのドメインには名前のある所有者と権限を持つスチュワードがおり、マッチングとサバイバーシップのルールが文書化され徹底され、ゴールデンレコードが生成されて消費者に伝播され、参照データはバージョン管理され、APIのように有効日付とともに公開されます。
レベル4、管理: プログラムが、ベースラインに対して測定され、制御されています。重複率、マッチの信頼度の分布、誤ったマージと見逃したマッチの率、主要な項目の完全性、レビューの待ち行列のサイズと経過日数が指標として追跡され、閾値は感覚ではなくそれらの数字に対して調整され、MDMの価値(収益の正確性、調達の節約、レビューのコスト)が定量化されて、決まった周期で所有者に報告されます。
レベル5、オーケストレーション: ゴールデンレコードは、バージョン管理されたイベントとしてほぼリアルタイムに流れ、セマンティックレイヤーに供給し、組織全体で信頼されます。マッチングは測定された成果に対して継続的に改善され、マスター化は繰り返し可能な能力として新しいドメインに及び、MDMはガバナンスとリスクの計画と統合されるので、源、標準、エンティティの状況が移るにつれて、プログラムが適応します。

議論のためのアイデア

二つのシステムが顧客の数で食い違うなら、どちらが正しく、それをどう証明しますか。
どのマスターデータのドメインを最初にマスターすれば、最大の測定可能な勝利をもたらし、その勝利の価値はいくらですか。
今日、確率的マッチングはどこで役立ち、それが意味するときどきの誤ったマージに納得していますか。
参照データをどうバージョン管理し、コードの意味が変わったとき、過去のレポートで何が壊れますか。
最も重要なエンティティの名前のあるスチュワードは誰で、その人は仕事を実際に行う権限と時間を持っていますか。
ゴールデンレコードが変わったとき、下流のシステムはどうやって知り、それが傷つく前にどれだけ古くてよいですか。

要点

データをマスター、参照、トランザクションに分類し、重複が最もコストのかかる所にマッチングとガバナンスを投資します。
現実世界のエンティティごとに一つのゴールデンレコードを、明示的で、元に戻せて、記録されるサバイバーシップのルールで組み立てます。
制御と混乱への意欲に合うMDMのアーキテクチャのスタイル(レジストリ、統合、共存、集中型のハブ)を選びます。
参照データをバージョン管理された共有の語彙として扱い、認められた標準を好み、コードのリストをその場で上書きしてはいけません。
MDMはツールではなく、ガバナンスとスチュワードシップで成功します。ゴールデンレコードをイベントとして伝播し、プログラムを改善された決定で測定します。

参考文献とさらなる読み物

David Loshin, Master Data Management
Alex Berson and Larry Dubov, Master Data Management and Data Governance
Dan Power, The Definitive Guide to Master Data Management
John Talburt, Entity Resolution and Information Quality
Peter Christen, Data Matching: Concepts and Techniques for Record Linkage, Entity Resolution, and Duplicate Detection
Ivan P. Fellegi and Alan B. Sunter, “A Theory for Record Linkage,” Journal of the American Statistical Association
DAMA International, DAMA-DMBOK: Data Management Body of Knowledge
Ralph Kimball and Margy Ross, The Data Warehouse Toolkit