Loading article…
マスターデータ管理（MDM ）は、企業の公式共有マスターデータ資産の均一性、正確性、管理責任、意味的一貫性、および説明責任を確保するために、ビジネスと情報技術が協力する分野です。[ 1 ] [ 2 ]
しかし、データ品質、分類、および照合に関する問題が発生すると、データ変換が必要になる場合があります。他の抽出、変換、ロード（ETL）ベースのデータ移動と同様に、これらのプロセスはコストがかかり非効率的であるため、プロジェクトの投資対効果が低下します。
事業部門や製品ラインのセグメンテーションの結果、同じエンティティ（顧客、サプライヤー、製品など）が異なる製品ラインに含まれることになります。これはデータの冗長性や混乱を招きます。[ 7 ]
例えば、顧客が銀行で住宅ローンを組んだとします。マーケティング部門とカスタマーサービス部門が別々のデータベースを使用している場合、顧客が既に登録済みであっても、広告が送られてくる可能性があります。銀行の2つの部門はそれに気付かず、顧客には無関係な情報が送られてしまいます。レコードリンケージを使用すれば、同じエンティティに対応する異なるレコードを関連付けることができ、この問題を軽減できます。
マスターデータ管理における最も一般的な問題の一つは、合併や買収による企業の成長です。既存のアプリケーションはマスターデータベースに依存しているため、これらの別々のマスターデータシステムを統合するのは困難を伴う場合があります。理想的には、データベース管理者は合併の一環としてマスターデータの重複排除を行うことでこの問題を解決します。
時間の経過とともに、合併や買収が繰り返されるにつれて、問題はさらに深刻化する可能性があります。データ照合プロセスは極めて複雑になり、信頼性が低下することさえあります。組織によっては、10個、15個、あるいは100個もの独立した、統合性の低いマスターデータベースを抱えることになる場合もあります。これは、顧客満足度、業務効率、意思決定支援、および規制遵守において深刻な問題を引き起こす可能性があります。
もう一つの問題は、マスターデータスキーマに含めるべき適切な詳細度と正規化レベルを決定することです。たとえば、統合された人事環境では、エンタープライズソフトウェアは従業員のデータを現在のステータスとして保存することに重点を置き、採用日、最終昇進日などを識別するためのフィールドをいくつか追加するかもしれません。しかし、このような簡略化は、計画や予測を行う依存システムに業務に影響を与えるエラーを引き起こす可能性があります。このようなシステムの利害関係者は、新規採用者のオンボーディング、計画退職、および事業売却を追跡するために、新しいインターフェースの並行ネットワークを構築せざるを得なくなる可能性があり、これはマスターデータ管理の目的の1つに反します。
マスターデータ管理はテクノロジーによって実現されますが、それを可能にするテクノロジーだけにとどまりません。組織のマスターデータ管理能力には、人材とプロセスも含まれるべきです。
MDM（マスターデータ管理）においては、複数の役割を担う人材を配置する必要があります。中でも最も重要なのは、データオーナーとデータスチュワードです。それぞれの役割には複数の担当者が割り当てられ、各担当者はマスターデータのサブセットを担当することになります（例えば、従業員マスターデータを担当するデータオーナーと、顧客マスターデータを担当するデータオーナーなど）。
データオーナーは、データ定義、データ品質、データセキュリティなどの要件、およびデータガバナンスとデータ管理手順の遵守について責任を負います。また、要件からの逸脱が生じた場合、データオーナーは改善プロジェクトへの資金提供も行う必要があります。
データスチュワードは、データ所有者に代わってマスターデータ管理を実行し、おそらくデータ所有者へのアドバイザーとしての役割も担っています。
マスターデータ管理は、データガバナンス組織によって定められた方針と手順によって定義される「専門的な品質改善のための規律」 [ 8 ]と見なすことができます。その目的は、マスターデータを組織全体で収集、集約、照合、統合、品質保証、永続化、配布するためのプロセスを提供し、そのデータの継続的な保守とアプリケーションの使用において、共通の理解、一貫性、正確性、および制御[ 9 ]を確保することです。
マスターデータ管理で一般的に見られるプロセスには、ソース識別、データ収集、データ変換、正規化、ルール管理、エラー検出と修正、データ統合、データストレージ、データ配布、データ分類、タクソノミーサービス、アイテムマスター作成、スキーママッピング、製品コード化、データエンリッチメント、階層管理、ビジネスセマンティクス管理、データガバナンスなどがあります。
マスターデータ管理ツールは、重複データの削除、データの標準化（一括メンテナンス）[ 10 ] 、システムに誤ったデータが入力されないようにルールを組み込むことで、マスターデータの信頼できる情報源を作成するなど、マスターデータ管理をサポートするために使用できます。マスターデータとは、ビジネス取引が完了する製品、アカウント、および関係者のことです。
技術的なアプローチによって「ゴールデンレコード」が作成される場合や、「記録のソース」または「記録のシステム」に依存する場合、データが「マスターされている」場所について語られるのが一般的です。これは情報技術業界では受け入れられている用語ですが、専門家とより広範な利害関係者の両方に対して、「マスターデータ」の概念と「データのマスタリング」の概念を混同しないように注意する必要があります。
マスターデータ管理のためのテクノロジーソリューションを導入するには、いくつかのモデルがあります。これらは、組織の中核事業、企業構造、および目標によって異なります。具体的には、以下のようなモデルが挙げられます。
このモデルでは、単一のアプリケーション、データベース、またはより単純なソース（スプレッドシートなど）を「記録のソース」（または、アプリケーションデータベースのみに依存する場合は「記録システム」）として識別します。このモデルの利点は概念的な単純さですが、大規模組織における複雑なマスターデータ配信の現実には適合しない可能性があります。
記録のソースは、属性のグループ（マスターデータエンティティの異なる属性が異なる記録ソースを持つように）や地理的なグループ（組織の異なる部門が異なるマスターソースを持つように）などによって統合できます。統合は、どのレコードのサブセットがどのソースに存在するかが明確に区別されている特定のユースケースでのみ適用可能です。
マスターデータを収集し、他のシステムに配布する方法はいくつかあります。[ 11 ]これには以下が含まれます。
大規模組織におけるマスターデータ管理の導入における課題は、多くの場合、関係者が「唯一の真実」という概念に同意せず、各自のマスターデータの定義が必要だと考える場合に発生します。例えば、在庫管理に使用される製品階層は、マーケティング活動や営業担当者への報酬支払いに使用される製品階層とは全く異なる可能性があります。何よりもまず、異なるマスターデータが本当に必要かどうかを特定する必要があります。必要な場合は、導入するソリューション（テクノロジーとプロセス）は、複数の真実が存在することを許容しつつ、必要な差異をシンプルかつ透明性の高い方法で調整できるものでなければなりません。必要でない場合は、プロセスを調整する必要があります。多くの場合、マスターデータの整合性を維持しつつ、ユーザーがニーズに合った方法でアクセスできるソリューションを見つけることができます。例えば、営業担当者は製品をサイズ、色、その他の属性でグループ化したい場合があり、購買担当者はサプライヤーや原産国でグループ化したい場合があります。このような積極的な管理が行われないと、代替バージョンを必要とするユーザーは公式の手続きを単に「回避」するようになり、結果として企業のマスターデータ管理プログラム全体の有効性が低下する。