SAP MDG入門｜マスタデータガバナンスで実現する全社データ品質の底上げ

はじめに：マスタデータが業務品質を決める

SAPの世界で「マスタデータが汚いとすべての業務が崩れる」というのは経験者全員の共通認識です。同じ取引先が3つの異なるコードで登録されていたり、商品マスタの単位がgとkgで混在していたり、勘定科目に重複があったり──こうした小さな不整合が、決算遅延・与信判定ミス・在庫不整合といった大きな問題に育ちます。

なぜこれほどマスタが乱れるのか（why so）。多くの企業ではマスタ登録のルールが文書だけで存在し、実際の登録は各部門が個別の判断で行っているからです。誰が承認したのか、何を確認したのか、いつから有効になるのかが追えない状態では、品質を維持する仕組みそのものが存在しません。

ではどうすべきか（so what）。マスタの登録・変更を申請ベースのワークフローに乗せ、承認・監査・配信を一元化するのが現代の答えです。これを担うのがSAP Master Data Governance（MDG）です。本記事ではMDGの全体像と主要ドメイン、典型的な業務フロー、S/4HANA移行時の活用法を整理します。

SAP MDGとは何か

SAP MDGはS/4HANAの一部として提供されるマスタデータガバナンス製品です。単独で動くツールではなく、S/4HANAのトランザクション基盤とビジネスパートナー・製品・財務マスタを共有しながら、上に「申請・承認・配信」のレイヤを被せる構造になっています。

主要ドメインは次のとおりです。

なぜドメイン別にコンポーネントが分かれているか。マスタごとに登録項目・承認者・参照先業務がまったく異なるため、共通の枠組みでは現実の業務に合わせきれないからです。MDGはドメインごとに専用のUI・データモデル・ワークフローを提供し、業務にフィットさせます。

MDGが解決する3つの問題

1. 重複登録

同じ取引先が異なる事業所から別々に登録される問題は、グローバル企業でほぼ確実に発生します。MDGは登録申請時に名称・住所・税番号などをキーにファジー検索を行い、重複候補を提示します。これにより登録者が「すでに存在する取引先を別コードで作る」事故を構造的に防げます。

2. 未承認の変更

経理・税務・与信に関わる項目を、現場担当が予告なく変更してしまう事故は監査の指摘対象になります。MDGは項目単位で承認者を分岐できるため、たとえば「銀行口座は経理マネージャー承認」「住所は営業アシスタント承認」といったルールを実装でき、勝手な変更を防げます。

3. システム間の不整合

S/4HANAだけでなく、CRM・SCM・BIなど複数システムにマスタを配布している企業では、配信遅延や失敗による不整合が頻発します。MDGは承認後に各システムへ自動配信し、配信状況をモニタリング画面で追跡できます。配信失敗時はリトライ操作も画面から行えます。

なぜこの3つを1つの製品で解決する必要があるか。重複防止だけ、承認だけ、配信だけを別ツールで作っても、結局「申請から配信完了までの一気通貫」が分断されてマスタ品質が劣化するからです。MDGの本質的価値は「申請→承認→配信→監査」の一気通貫をひとつのプラットフォームで実現することにあります。

標準フロー：取引先登録の例

MDG-BPでの取引先登録ワークフローを図にすると次のようになります。

flowchart LR
  A[申請者
新規登録依頼] --> B[重複チェック]
  B --> C[与信担当
与信枠付与]
  C --> D[経理
銀行口座承認]
  D --> E[マスタ管理
最終承認]
  E --> F((自動配信))
  F --> G[S/4HANA]
  F --> H[CRM/SCM等]

ポイントは、承認者が固定された一直線のフローではなく、項目内容や金額レンジによって動的に承認者が決まることです。MDGはBRFplusというルールエンジンと連携しており、コードを書かずに承認分岐を定義できます。

S/4HANA移行とMDG

MDGはS/4HANA移行プロジェクトでも重要な役割を果たします。多くの企業がECCからの移行時に直面するのが「マスタが汚すぎてそのまま移行できない」問題です。重複・欠損・不正値を抱えたまま移行すると、S/4HANA側で数年がかりの後始末が必要になります。

MDGを移行プロジェクトに組み込むメリットは2つあります。第1に、移行前のクレンジングをMDGの重複検出・データ品質ルールで実施できる点。第2に、移行後の運用フェーズで同じMDG基盤がそのまま「マスタ品質を維持する仕組み」として継続稼働する点です。なお、この発想はClean Core戦略とも親和性が高く、マスタ品質を外側のガバナンスレイヤで担保することで、コア側のカスタマイズを増やさずに済みます。

なぜ移行プロジェクトで一度きりのクレンジングをするだけでは不十分か。マスタは生き物で、何もしなければ移行直後から再び劣化を始めるからです。「クレンジングは1回、ガバナンスは永続」という発想転換が、S/4HANA投資を長期で守るカギになります。S/4HANA Cloudのエディション選定についてはPublic vs Private比較も参考になります。

ユースケース3例

ユースケース1：グローバル取引先統制

世界各国の販売拠点が独自に取引先を登録していたグローバル製造業では、同一企業が10以上のコードで存在する状態が常態化していました。MDG-BP導入後は、本社マスタ管理チームが最終承認を握り、ファジー検索で重複候補を事前に潰す運用に変更。年間で数千件の重複登録を防止できました。

ユースケース2：商品マスタの単位統制

食品メーカーで「g」「kg」「ケース」が混在していた商品マスタを、MDG-Mの登録ルールで強制的に基本単位＋換算係数の形に統一。在庫差異の調査時間が劇的に減り、需要予測の精度も改善しました。

ユースケース3：連結勘定科目の一元管理

複数の子会社で別々に勘定科目を定義していた企業が、MDG-Fで親会社主導の科目体系に統一。各子会社は自社固有の科目を子コードとして持ちつつ、連結時には親科目に自動マッピングされる構造になり、決算プロセスが大幅に短縮されました。

導入時に気をつけたいこと

• 全ドメイン同時導入を避ける。BP・M・Fのうち、もっとも痛みの大きいドメインから始める
• ワークフローを最初から完璧に作ろうとしない。3〜5段階のシンプルな承認から始め、運用しながら拡張する
• 既存マスタのクレンジングを甘く見ない。MDGを入れる前の棚卸しが工数の半分を占めることもある
• 配信先システムの改修も視野に入れる。MDG側で配信できても、受信側がIDocを受け取れなければ意味がない
• マスタ管理組織を作る。ツールだけ入れても「ガバナンスを担う人」がいなければ成立しない

なぜここまで「人と組織」を強調するか。マスタガバナンスの本質は技術ではなく業務統制だからです。MDGはガバナンス組織を支える道具であって、ガバナンスそのものを生み出してくれるわけではないと理解することが、導入失敗を避ける最大のポイントです。

よくある疑問（FAQ）

Q. MDGはS/4HANAが必須ですか？ A. 現行のMDG on S/4HANAはS/4HANA上で動きます。ECCユーザー向けにはMDG on ECCも存在しますが、新規導入ならS/4HANA前提が現実的です。

Q. MDGはアドオンですか、標準機能ですか？ A. S/4HANAに含まれる標準機能ですが、利用するには別途ライセンスが必要です。

Q. ワークフロー設計にABAPは必要ですか？ A. 基本的な承認分岐はBRFplusでノーコード設定できます。複雑なバリデーションを書く場合のみABAPの知識が必要になります。

Q. MDGとSAP Datasphereは何が違いますか？ A. Datasphereは分析向けのデータ統合・モデリング基盤で、MDGはトランザクション系マスタの登録・承認・配信を担います。役割が異なるため共存が前提です。Datasphereの詳細はSAP Datasphere入門を参照してください。

Q. クラウド版MDGはありますか？ A. S/4HANA Cloud Private Editionでは利用可能ですが、Public Editionでは現時点で限定的です。導入前にエディションの最新サポート状況を必ず確認してください。

まとめ

• SAP MDGはS/4HANA上で動くマスタデータガバナンス製品で、BP・M・F・Sの主要ドメインをカバー
• 重複登録・未承認変更・システム間不整合という3つの古典的問題を一気通貫で解決する
• BRFplusによるルールベースの承認分岐で、コードを書かずに業務に合わせたワークフローが組める
• S/4HANA移行ではクレンジングと永続ガバナンスの両方を担い、Clean Core戦略と相性が良い
• 導入は1ドメインから段階的に。組織と運用体制の整備が技術導入と同じくらい重要

マスタデータの品質は、企業の業務品質そのものです。「データ移行が終わったら勝手に整う」ことは決してありません。MDGのような仕組みでガバナンスを継続的に回す体制を、S/4HANA導入と同じタイミングで設計することが、長期的なERP投資を守る唯一の方法です。

MDGのデータ品質をさらに活かすには、BTP上のDatasphereやIntegration Suiteとの連携が鍵になります。BTPの全体構成をハンズオンで学べる講座を紹介します。