PART4 マスターデータ統合の難所と　実践へのアプローチ

唯一無二の正確なマスターデータは、業種業態や企業規模を問わず、すべての企業にとって最重要資産である。しかし、重要性や必要性は論を待たないにもかかわらず、マスターデータの品質や管理レベルが万全であると断言できる企業は少ないのではないだろうか。マスターデータ統合は、古くて新しい課題なのである。拙速なシステム導入に走ることなく、理想的なマスターデータ統合を実現するためのアプローチを明らかにする。（本誌）

マスターデータ統合が注目を集める背景

どのような業種であれ、およそ企業活動は、何らかのインプットを処理プロセスを経てアウトプットする一連の業務活動と、その流れで構成されている。こういった活動のなかを流れる血液に相当するのがデータであり、現代ではこの血流をコントロールするためにITが果たすべき役割が大きくなってきている。そして、企業活動を的確に把握するためには、企業規模や業種を問わず必要とされる共通のデータ群がある。顧客、製品、組織、資産、サプライヤー、パートナーといったデータ群は経営の根幹を成す最重要資産といってよい。

また、経営者や事業部門長、管理者や担当者の別なくすべての役割や階層にとって必要性の高いものであり、たとえば代表的なデータ資産については以下のような要求が業種を問わずにあげられるだろう。

• 組織の垣根にとらわれず共通的な顧客データが識別できること。
• 組織間で販売されている製品・サービスの情報がライフサイクルで整合していること。
• 事業運営において必要な組織・ロケーションのコード体系や階層が共通化されていること。
• 組織間で、サプライヤー、パートナーの情報が一元化されていること。
• 購買に関する情報がグローバルで集中化されていること。

そして、こういったデータ群を正確かつ一元的に管理するためのキーとなるのがマスターデータである。唯一無二の正確なマスターデータは、もはや「あればよい」ものから「持つべき」ものとなっているのである。

なぜマスターデータ統合は難しいのか

しかし、現実には多くの企業で以下のような切実な問題が発生している。

1同一品目、同一原料であっても異なるコードを与えてしまっており、双方の紐付けもできていない。

2意味づけされた品目コードの採番ルールが徐々に破綻してきている（例：品目を所掌する組織を品目コード体系の一部に取り込んでいるが、組織改正がたびたび実施され、意味をなさなくなっている）。

3ERPと周辺システムのマスターを維持するために、多重のメンテナンスが発生している。

企業は、これまでマスターデータについて手をこまねいていただけでなく、解決に向けた努力を続けてきた。例えば、ERP、CRM、SCM、PLMといった製品の導入を契機とした顧客や製品のマスターデータ統合が典型である。しかし上記の例のように、ERPパッケージの導入がさらに問題を複雑化させただけに終わってしまったかに見えるケースも珍しくない。単体の企業はともかく、企業グループやパートナー間までを一枚岩のERPなどのパッケージアプリケーションで統一することは非現実的であり、R&D、マーケティング、製造、営業、財務、保守サービスとライフサイクルを通じた多岐にわたるシステムが、単一のアーキテクチャで同一時期に刷新され、結果としてマスターデータ統合が実現できたケースは稀だろう。

そのため、全世界の拠点へのシステム展開が必須となっているグローバル企業を中心に、異なるシステム間でマスターデータの統合や同期化を図る取り組みが実施されてきている。グローバル企業では、マスターデータ統合は標準装備であり、難しいからやらないでは済まされないからである。例えば、Bayer、Chevron、Dupont、Nestle、HP、IBM、Intel、Nokia、P&Gといった企業では、今でいうMDM（マスターデータ管理：Master Data Management）を10年以上前から標準装備してきた。

その後もマスターデータ統合のソリューションは進化を続けており、従来はなんらかの独自開発で対応せざるを得なかった機能も、チェーン型、ハブ型のMDM製品やミドルウェアの活用により提供できるようになってきている（図１）。なお、マスターデータ統合の方式はひとつだけでなく、チェーン型とハブ型のハイブリッドで実装されるケースもあれば、従来から利用されているDWH（データウェアハウス）型でマスターデータの品質を徐々に向上させながら、段階的なアプローチとしてチェーン型やハブ型への配分を高めるといったケースもある。

日々進歩するITをどのタイミングでどの範囲まで取り込んでいくかといったことも課題ではあるが、むしろマスターデータ統合で難しいのは技術的な側面ではなく、組織と人のマネジメントや標準化といったガバナンスに関わる側面であると、ITRでは考えている。一例をあげよう。

あるグローバルのハイテク企業は、顧客、製品／部品のマスターデータについては、正本となっている独自開発の統一コード管理システムから全世界に配信される仕組みを早くから実現できていた。一見なんの問題もない先進事例であるが、この企業ではヒドゥン・コードに悩まされていたのである。ヒドゥン・コードとは、正本のマスターデータをユーザーがローカルのPCやシステムにコピーして、マスターデータのコード体系や属性を変更・追加してしまい、マスターデータの管理者から見えない状態で利用されている、いわばマスターデータ管理の混乱を象徴する用語である。

ひとたびこのような状態になってしまうと、気がつけば数十もの異なったコードが、それぞれのユーザーの用途に応じて利用されていることもある。なぜこういった状態になってしまうかの理由については、マスターデータのキーとなるコードのソート順が業務ニーズと異なる、コードの桁数が長く扱いにくい、無意味コードでは扱いにくい、逆に、前述のように有意コードが意味をなさなくなっている、MDMでは基本情報しか管理されておらず必要な項目が属性として含まれていない、など多岐に渡る。

ヒドゥン・コードの存在が統合を難しくする

ヒドゥン・コードは、マスターデータ統合の難しさを物語っており、マスターデータをデータ資産として維持していくための社内体制や役割が十分に確立していないことから生ずる問題である。IT部門が主導し、ユーザー部門の理解を得て協力をもらいながら維持管理していくためには、マスターデータを可視化していくガバナンスのプロセスと、スチュワードシップと呼ばれる協業体性を両立させていく必要がある(図２)。

スチュワードシップ（Stewardship）とは、財産管理の職務、世話役を務めることといった意味である。欧米ではマスターデータのスチュワードシップを確立するための役割をデータ・スチュワードと呼称し、ベンダーのカンファレンスなどでもあたりまえに利用されている用語である。さらに、データ・スチュワードを、人事上の職制とまではいかないが、職務分掌として明確にしているグローバル企業も珍しくない。統計などは存在しないが、なかには、数十人から数百人規模でデータ・スチュワードを配置する例も報告されている。

一方、ガバナンスの側面であるが、図2ではマスターデータ定義書というドキュメンテーションを通じて標準化をしていく事例を簡略化して図式化しているが、これをベースとして考察してみよう。「顧客コード」と簡単に書いているが、いったい自社には顧客を表すマスターデータがいくつあり、どのような名称で呼ばれ、どのような目的や背景でそうなっているのか、そしてどこのシステムのどの機能で利用されているのかを明らかにするなかで、マスターデータの棚卸しをしていかなければならない。

マスターデータのオーナーシップ問題

さらに、難しいのは顧客コードの利用者が複数の部門である場合、どの部門が所有者としてのオーナーシップを持つべきなのかである。このオーナーシップの議論も難物となることが多い。売掛金管理は、営業部門が売上として責任を持つべき機能なのか、経理部門が与信管理も含めてオーナーシップを主導すべき機能なのかである。よく見られる傾向として、どの部門も権限は持ちたいが責任はできるだけ抱えたくないため、ユーザー部門同士の責任の押し付け論になってしまうか、決着がつかない場合は標準化の活動や議論の時間がムダとなり、それぞれ個別に管理するという現状方針が踏襲されてしまう。それを避けるために、所有者と管理者という役割を分けて、責任の分散を図ることでそれぞれの矛先を収めるといったケースもある。

ではマスターデータの標準化を単なるデータ分析や文書化および規約化といったガバナンスだけで息切れさせることなく、スチュワードシップも両立させていくためには何が必要か？メタデータ、グループ共通／本社共通、部門共通といった共通のマスターデータ情報、本社個別／部門個別といった個別のマスターデータ情報を管理し、統合マスターから配信・同期するMDMをセットで検討するのが有効だ（図3）。

この時、単なる項目やレイアウトの変換といったシステムの機能面だけでなく、履歴情報の有無や変更・削除といったことに関するデータ管理ポリシーの設定、およびそもそものマスターデータ管理体制をどのように組み込むべきなのかといった難易度の高いハードルをクリアしていく必要がある。

こういった現状分析やシステム化を検討するにおいて、外部のコンサルタントを活用する際には、コンサルタントの使い方に留意しなければならない。一般に、MDM製品ベンダーは製品の知識やスキルはあるものの業務ノウハウには乏しい傾向があり、コンサルティング・ファームなどの場合はその逆となる。いずれにしろ全て丸投げにした場合は、常駐での作業を含め高額な費用が生じることになりがちであるため、目的に応じた使い分けを推奨する。

マスターデータ統合の導入に向けて

導入に当たっては、マスターデータ統合におけるスポンサーシップを獲得する努力も必要である。品目コードの管理の例で述べたとおり、マスターデータが統合されていない企業では、個別のマスターデータを個々にメンテナンスする作業が冗長となっているはずである。これを削減するという期待効果はあるものの、直接的なコスト削減につながらなければ経営者の賛同が得られるかどうかは定かではない。例えば、以下のような経営者のありがちな依頼に対して、自社のシステムは即時に対応可能かどうか問うてみるべきである。

このようなニーズに対応するためには、MDMベンダーの製品を導入するだけでなく、企業間の親子関係やグループ関係を最新の状態として提供している外部データサービスの活用も検討すべきだ。企業の統廃合やM&Aが激しい昨今、自社だけでの標準化やマスターデータのメンテナンス作業では限界がある。経営者にとってはあたり前の感覚で「できているはずの情報管理」が提供できるようになるためにも、マスターデータ統合への注力が注力だけに終わることなく実装までつながる動向となっていくためにも、今マスターデータ統合に改めて注目すべきである。

最後に、マスターデータ管理を運営する部門の機能や役割について触れておこう。図4がそれである。

このような専任部署を設け、専任担当者を配置できるかどうかは、データ活用の必然性や企業文化によるが、一度はぜひマスターデータ管理部署が果たすべき役割と重要性を評価すべきである。そのうえで、可能なら組織としての設立を検討する価値があると考える。