MDM
この記事は大言壮語的な記述になっています。 |
MDM（通称：マスターデータ管理）は、Master Data Managementの略で、ITにおいて使用されるマスターデータの管理を行うための手法またはそれを実現するソフトウェア製品である。
概要
編集背景と意義
編集
通常マスターデータは個々の情報管理アプリケーション内で定義されるが、マスターデータが適切に管理されていない場合や、複数の情報管理システムで同じマスターデータを使用する場合には、マスターデータ間の整合性が保たれない、または重複が存在するという事態が発生しうる。マスターデータの重複や不整合は、そのマスターデータと関連するデータが検索・同定できなくなる、といった不都合を生むため、マスターデータ自体を管理する必要からMDMという概念が生まれている。
MDM は、メインフレーム時代から続く古い課題であり、システム開発の度にそのアプリケーションにおいて整合性をとり品質を保つ仕組みを実装してきた。情報システムにおけるパッケージソフトウェアの適用が拡大することで、アプリケーション側でのマスターデータ管理が困難になってきたことから、MDMを行うためのパッケージソフトウェア製品も開発されてきた。
以下で行う MDM の説明は、主にコンピュータ上で管理されるマスターデータを中心に記述するが、MDM やマスターデータの広義な概念としては、コンピュータで管理されるデータだけとは限らない。個人のノートや手帳に、手書きで書いた顧客情報でもマスターデータであり、MDM の対象である。そういった意味では、保存方法や規模こそ違えど、MDM の考え方は昔から存在していたと言える。
MDM が出来ていない例題
編集
・データ反映 例
社員Aさんが営業部から業務部へ、部署を移動した。
人事部で扱うAさんのデータ→﹇業務部Aさん﹈︵データ反映済み︶
営業部で扱うAさんのデータ→﹇管理部Aさん﹈︵データ反映したが間違えた︶
経理部で扱うAさんのデータ→﹇営業部Aさん﹈︵データ反映し忘れorデータ反映が遅れている︶
Aさんの部署データを見る場合、どのデータベース︵システム︶を見ても、本来は全て﹇業務部Aさん﹈でなくてはならないのに、データの乖離が起きている。
データ自体の間違いによる問題発生もあるが、1つのデータ変更作業を、複数のデータベース・システム・部署に渡って更新作業を行わなくてはならず、非効率である。
・データ重複 例 顧客の﹇山田 花●様﹈から注文と入金があったので、お客様の各種情報(名前、住まい、電話番号、携帯番号、取引履歴、契約)を調べようとした。 Aデータベース内の﹇山田 花●様﹈‥ 鈴木 花●、東京住まい、03-0023-45XX、090-0012-34XX、取引履歴0件、契約0件。 Aデータベース内の﹇山田 花●様﹈‥ 山田 花●、大阪住まい、06-0023-45XX、090-0012-34XX、取引履歴3件、契約0件。 Aデータベース内の﹇山田 花●様﹈‥ 山田 花●、大阪住まい、06-0023-45XX、090-5678-90XX、取引履歴5件、契約3件。 同じデータベースを参照しているにもかかわらず、同じ顧客データが重複して複数登録されてしまっており、どれが最新でどれが正しいのかが、すぐに分からない。 また、重複している事自体を認識せずに対応した場合、本来反映すべきでないデータにデータ対応してしまうなど、サービス品質自体にも問題が発生してしまう。 特に結婚などで名前が変わってしまっている場合や、引っ越しで住所や電話番号が変わってしまっている場合、同一人物なのに別人物として扱われてしまう危険がある。 ︵消えた年金記録問題などは、上記例題のような問題が一因となっている︶
・コード体系 例 仮に顧客から見積依頼や注文があり、商品コードから商品Aの在庫を調べようとする。 東京事業所で扱う製品Aの商品コード‥SYOHIN-00001A 大阪事業所で扱う製品Aの商品コード‥SYOHIN-00100A 香港事業所で扱う製品Aの商品コード‥Product_0001A 商品コード体系がバラバラのため在庫を正確に調べられず、機会損失したり、納品遅れしたり、在庫があるのに商品を再調達・製造して無駄が発生したりする。
・同音異義語 例 営業部門が取り扱う﹇取引先﹈→﹇お客様﹈という意味の取引先。 調達部門が取り扱う﹇取引先﹈→﹇仕入先﹈という意味の取引先。 経理部門が取り扱う﹇取引先﹈→﹇請求先﹈という意味の取引先。 ﹇取引先﹈と同じ言葉を使っているにもかかわらず、部署やデータベースによって意味が異なってしまっている。
・異音同義語 例 営業部門が取り扱う﹇商品﹈→﹇商品﹈という意味。 調達部門が取り扱う﹇物品﹈→﹇商品﹈という意味。 経理部門が取り扱う﹇製品﹈→﹇商品﹈という意味。 部署やデータベースによって﹇商品﹈﹇物品﹈﹇製品﹈と違う言葉を使っているにもかかわらず、実は同じ意味で利用している。
・データ型︵データベースにおけるデータの扱い方法︶の相違例 A商品(税抜き￥9,980)から、税込みの合計金額を求める。 営業部門が取り扱うA商品の﹇税込み合計金額﹈→ ￥10,778︵日本円管理、小数点切り捨て︶ 業務部門が取り扱うA商品の﹇税込み合計金額﹈→ 10778︵数値管理、小数点切り捨て︶ 経理部門が取り扱うA商品の﹇税込み合計金額﹈→ ￥10,778.40︵日本円管理、小数第2位まで管理︶ 元データ自体は同じだが、データベース内﹇税込み合計金額﹈のデータ型によって、データ表示のされ方や数値結果が異なってしまう。
・桁数︵データベースにおけるデータ桁数︶の相違例 営業部門が取り扱う社員Aさんの﹇従業員番号﹈→12345 経理部門が取り扱う社員Aさんの﹇従業員番号﹈→012345 人事部門が取り扱う社員Aさんの﹇従業員番号﹈→0012345 社員Aさん(従業員番号12345)のデータ自体は同じだが、データベース内﹇従業員番号﹈の管理方法によって、同じデータでも桁数が異なってしまう。
・名前付け基準の相違例 営業部門が取り扱う商品﹇ABC﹈→ABC Version 2.0 Professional 32bit Workstation 業務部門が取り扱う商品﹇ABC﹈→ABC バージョン2.0 プロフェッショナル32ビット ワークステーション 経理部門が取り扱う商品﹇ABC﹈→ABC 2 Pro 本来は同じ商品﹇ABC﹈を扱っているのに、名前付けの基準や運用がバラバラで、商品名が統一されていない。
・データ重複 例 顧客の﹇山田 花●様﹈から注文と入金があったので、お客様の各種情報(名前、住まい、電話番号、携帯番号、取引履歴、契約)を調べようとした。 Aデータベース内の﹇山田 花●様﹈‥ 鈴木 花●、東京住まい、03-0023-45XX、090-0012-34XX、取引履歴0件、契約0件。 Aデータベース内の﹇山田 花●様﹈‥ 山田 花●、大阪住まい、06-0023-45XX、090-0012-34XX、取引履歴3件、契約0件。 Aデータベース内の﹇山田 花●様﹈‥ 山田 花●、大阪住まい、06-0023-45XX、090-5678-90XX、取引履歴5件、契約3件。 同じデータベースを参照しているにもかかわらず、同じ顧客データが重複して複数登録されてしまっており、どれが最新でどれが正しいのかが、すぐに分からない。 また、重複している事自体を認識せずに対応した場合、本来反映すべきでないデータにデータ対応してしまうなど、サービス品質自体にも問題が発生してしまう。 特に結婚などで名前が変わってしまっている場合や、引っ越しで住所や電話番号が変わってしまっている場合、同一人物なのに別人物として扱われてしまう危険がある。 ︵消えた年金記録問題などは、上記例題のような問題が一因となっている︶
・コード体系 例 仮に顧客から見積依頼や注文があり、商品コードから商品Aの在庫を調べようとする。 東京事業所で扱う製品Aの商品コード‥SYOHIN-00001A 大阪事業所で扱う製品Aの商品コード‥SYOHIN-00100A 香港事業所で扱う製品Aの商品コード‥Product_0001A 商品コード体系がバラバラのため在庫を正確に調べられず、機会損失したり、納品遅れしたり、在庫があるのに商品を再調達・製造して無駄が発生したりする。
・同音異義語 例 営業部門が取り扱う﹇取引先﹈→﹇お客様﹈という意味の取引先。 調達部門が取り扱う﹇取引先﹈→﹇仕入先﹈という意味の取引先。 経理部門が取り扱う﹇取引先﹈→﹇請求先﹈という意味の取引先。 ﹇取引先﹈と同じ言葉を使っているにもかかわらず、部署やデータベースによって意味が異なってしまっている。
・異音同義語 例 営業部門が取り扱う﹇商品﹈→﹇商品﹈という意味。 調達部門が取り扱う﹇物品﹈→﹇商品﹈という意味。 経理部門が取り扱う﹇製品﹈→﹇商品﹈という意味。 部署やデータベースによって﹇商品﹈﹇物品﹈﹇製品﹈と違う言葉を使っているにもかかわらず、実は同じ意味で利用している。
・データ型︵データベースにおけるデータの扱い方法︶の相違例 A商品(税抜き￥9,980)から、税込みの合計金額を求める。 営業部門が取り扱うA商品の﹇税込み合計金額﹈→ ￥10,778︵日本円管理、小数点切り捨て︶ 業務部門が取り扱うA商品の﹇税込み合計金額﹈→ 10778︵数値管理、小数点切り捨て︶ 経理部門が取り扱うA商品の﹇税込み合計金額﹈→ ￥10,778.40︵日本円管理、小数第2位まで管理︶ 元データ自体は同じだが、データベース内﹇税込み合計金額﹈のデータ型によって、データ表示のされ方や数値結果が異なってしまう。
・桁数︵データベースにおけるデータ桁数︶の相違例 営業部門が取り扱う社員Aさんの﹇従業員番号﹈→12345 経理部門が取り扱う社員Aさんの﹇従業員番号﹈→012345 人事部門が取り扱う社員Aさんの﹇従業員番号﹈→0012345 社員Aさん(従業員番号12345)のデータ自体は同じだが、データベース内﹇従業員番号﹈の管理方法によって、同じデータでも桁数が異なってしまう。
・名前付け基準の相違例 営業部門が取り扱う商品﹇ABC﹈→ABC Version 2.0 Professional 32bit Workstation 業務部門が取り扱う商品﹇ABC﹈→ABC バージョン2.0 プロフェッショナル32ビット ワークステーション 経理部門が取り扱う商品﹇ABC﹈→ABC 2 Pro 本来は同じ商品﹇ABC﹈を扱っているのに、名前付けの基準や運用がバラバラで、商品名が統一されていない。
MDM の実施・手法
編集
理想的な MDM は、マスターデータを全て1つのデータベースに集約することである。
複数のデータベースを1つに統合することで、上記で挙げた例での問題の殆どを解決する事ができる。
しかし複数のデータベース統合は、既存の関連するシステム・アプリケーション・プログラム・サーバ・業務・人への影響範囲が非常に大きく、最もハードルが高い。
MDM の効果は落ちるが、以下のような対策であれば、データベース統合に比べてハードルを下げて実施することができる。
・全社システムの中央に、マスターデータ用のデータベースを1つ追加し、既存のデータベースはそのままに、マスターデータだけを連係・共有する。
・社内での聞き取りや、ツールを使ってデータベースを現状把握︵可視化︶し、異音同義語・同音異義語などを洗い出し、名前を1つに統一し、社内専用の辞書を作り共有する。
・言語の壁や、現場での名前の覚え直しが多くて難しいなど、名前を統一するのが難しければ、無理に変更はせず名前のマッピングを行い、辞書を作り共有する。
・複数のデータベースに存在する同じデータ項目︵従業員番号・郵便番号・住所など︶は、同じ名前付け基準・桁数・データ型になるように、1カ所で統一管理する。
・主キー︵Primary Key︶の設定に、(基本)変化しない・廃棄含めて重複のない・一意の番号を付与する。︵マイナンバーなどが良い例︶
・複合キー︵﹇氏名﹈と﹇生年月日﹈の組み合わせなど︶は、データの信用性が落ちるため、可能な限り避ける。
・同じデータが複数登録されないよう、データ登録前に重複チェックをするなど、運用やルールを決める。
・既に存在する同じデータを、1件1件 手動でマージする。
組織やデータにもよるが、スモールスタートでツールなし・1人でも出来ることから、組織全体の協力が必要なことや、技術的にツール・ソフトウェア・パッケージ製品でないと難しいこともある。
主な製品
編集- TIBCO EBX（NTTコム オンライン・マーケティング・ソリューション）
- Biz∫MDM（株式会社JSOL）
- ASTERIA MDMOne（インフォテリア）
- Infosphere Master Data Management Server（日本アイ・ビー・エム）
- Netweaver MDM（SAP）
- Oracle MDM Data Hub（日本オラクル）
- Sun MDM Suite（サン・マイクロシステムズ）
- CircuData(ランドスケイプ）
- Informatica MDM (インフォマティカ・ジャパン)
- Kaseya (Kaseya Japan）
- MobiControl (SOTI Inc ペネトレイト・オブ・リミット株式会社（日本総代理店))
- MoMa (SUA Biz モマ スアビズ)
- ER/Studio (日揮情報システム株式会社)
- ERwin (日揮情報システム株式会社)
- STEP Trailblazer (Stibo Systems)
- Master Data Hub（Boomi）
関連項目
編集
 | この項目は、ソフトウェアに関連した書きかけの項目です。この項目を加筆・訂正などしてくださる協力者を求めています（PJ:コンピュータ/P:コンピュータ）。 |