前のページへ サイトマップへ ホームへ
 
DOAコラム一覧へ次のコラムへ
                             MDM
DOA Evangelist:小見山 昌雄

 1.MDM

 MDMは、マスターデータマネージメントの略だそうですが、マネージメントと言うからには、例によって、マネージメントの対象となるものの良い状態と言うものが、ある程度明らかになっていなければ成りません。
 しかし、マスターデータの良い状態を云々する前に、マスターデータとは何かと言うことについて、明らかにする必要があるでしょう。
 今まで見てきたシステムで、マスターと呼ばれるデータは、その範囲から概ね3つのパターンに分かれます。
 最も範囲が狭いのが、ビジネス上の存在を記録した部分のみをマスターとするパターンです。
 顧客マスター・商品マスター・仕入先マスターなどが対象となります。
 二番目は、ビジネス上の行為・出来事の記録部分もマスターに加えるパターンです。
 受注マスター・契約マスター・入金マスターなどが加わります。
 最も範囲が広いのは、コードやフラグ・区分などの定義情報まで含んでマスターとする場合ですが、これは、思うにハードディスクへの常駐ファイルをマスターと呼ぶ習慣があった所に、データの常駐化が進んだ結果ではないかと思われます。
 どうやら、マスターと言う表現自体に大した意味は無いらしいので、その求める良い状態は、結局データ管理と同じく一元管理された状態と言うことになります。
 また、いわゆるMDMツールと言う分野の製品説明にも、特にデータの特長による適不適は読み取れなかったので、一元化支援ツールとの理解で問題無いようですが、元がCRMツールのものなどは、顧客マスターに関する機能が特別に充実しているものなどがあるようです。

 2.MDMの背景

 今までもMDMのように、データ中心指向をベースとするデータ管理の提案は間欠的にありました。
 と言うか、データが一元管理されている方が良い事は自明なので、基本的にはその方向で色々と工夫が重ねられていると言うことのようです。
 近い所では、CRMとかマスターデータクレンジングや、コード整備など、SCMも広義には同系統の考え方です。
 更に広く考えると、データウェアハウスやEAIとかETLも、背景に対象スコープの一元化モデルが存在しないと、単に便利なストレージとか変換ツールとしての利用価値しか無いので、本来はデータ中心指向の具体化ツールの一翼を担っていると考えられます。
 ここでは、これらデータ中心指向のアクションがなぜ部分的にしか提案されないのかについて考えて見たいと思います。
 第一の原因は、何と言っても現行情報資産と言う事になるでしょう。
 膨大なデータ量、膨大なアプリケーション、膨大なユーザインターフェースが、システム・サブシステム・ファンクション・アクティビティ・タスクと階層化されたプロセス構造の中に巧みに隠蔽・重複して存在し、実体を把握する事すら困難な状況です。(もちろん十分管理の行き届いたシステム運営を実現されている所もありますが⇒そのような行き届いたデータ管理レベルにあるシステムでは、もちろん取り立ててMDMなどと言う事も無いでしょうが)
 そんな状態で、データ一元管理を言われても、その重要性や必要性を理解しこそすれ、情報整備のポリシー・段取り・技術などがあいまいでは、あまりの実現可能性の低さに、自分が在籍する間だけは着手しないで欲しいとしか思えないと言うのが本音でしょう。
 確かに、データもアプリも重複が進み、更に重複に加速度が掛ろうとしている状況で、これに対抗してデータの一元管理を主張しても、言ってるそばから重複が増える状況を変える事は困難です。
 実際は、データ中心指向として確立された考え方と統合手順および統合基盤技術としてのデータモデリングが確立しているので、まず、データ管理ポリシーを策定して、QMSやISMS同様に、能力に応じて段階的に進めれば良いのですが、それらの前提知識が無ければどうしようもありません。
 QMSやISMSも、最初は何の事か分からず「マネージメントシステムとは」と言うところから始めましたよね。
 しかし、データの一元化がビジネスへも、ビジネスシステムの運営にも大きなプラス効果をもたらす事は、今さら議論するまでも無いことなので、容易に実現可能なツールの形で提供されると魅力的だと言うことです。
 確かに、MDM製品とかMDM支援ツールと言うソフトウェア製品は、機能も盛りだくさんでなかなか魅力的です。
 このようなアプローチは、一面で、PCの登場から綿々と続いているユーザインターフェース洗練の成果と見る事も可能です。
 統合データの設定や割り付けが、分かりやすい画面から簡単に操作できると言う訳です。
 要するに物理的なデータ一元管理は困難としても、その操作性の良さを使って、実装データの関連を整理すれば、見かけの一元管理は実現すると言う考え方のようです。
 

 3.MDMの本質

 もちろんMDMは、マスターデータマネージメント、マスターデータ管理なので、ツールの導入や使用が目的ではありません。
 これらが目指す、マスターデータの良い状態とは何かを明らかにしないと話が前に進みません。
 マスターデータに限らず、データ管理の悪い状態と言うのは、今まで何度も困った経験をしているので、容易に想像出来ます。
 例えば、異音同義語や同音異議語の存在です。
 このように、話が論理的な段階に入った途端にツールは無力になります。
 更に、一覧表が無い、定義が無い、型・桁がまちまち、名称表記がまちまち、実装箇所が不明、実装時期が不明、導出タイミングが不明などが、主なデータの悪い状態でしょうか。
 と言うことは、これら悪い状態で無いことが、データの良い状態になります。
 データ利用者は、データ管理の悪い状態に遭遇した場合には、そのままではデータを利用できませんから、個別に調査し、問題を解決しなければなりません。
 データ管理が一元化されていないと、それら調査結果は、アプリケーションの仕様として記録されることになるので、別の機会に同じデータを利用しようとするデータ利用者は、基本的に更に複雑に成っている環境で同じ調査を繰り返すことになります。
 これが、システムの劣化とか、システム寿命などと表現されているシステム保守性低下の仕組みです。
 と言うことは、物理的にすでに重複しているものをまとめることはさておき、少なくともデータ管理に関する「情報」は一元化することで、データの完全性と可用性の低下を防ぐことが可能ではないか、と言う辺りがMDMの目的ではないでしょうか。 

 4.データ一元管理

 と言うことで、やはり話は一元管理へとまとまる訳です。
 一元管理とは何か、つまり、異音同義語がありましたと言う場合、あれとこれとは実は同じですよと言う場合、あれとこれは何かと言うことを、どう認識すれば良いでしょうかと言うことです。
 一元管理とは、一覧表にまとめて、同じ名前があれば一つにすれば良いと言うことではありません。
 これはもうビジネスの中にある存在や、起こった行為・出来事に対する関係や従属性から見て行くしかありません。
 お名前と言ったり、顧客氏名と呼んだりしているが、どちらもお客さんの名前なのねと言う訳です。
 逆に、物理的にどう見ても同じものであっても、ビジネスの都合で扱いを分けているものもあります。
 同じお客さんでも、年間数百万も買ってくれる層は、一人ひとりに専任の担当者が付くお得意様と言う訳です。
 ビジネス上の事実に沿って一元的に管理すると言う事です。
 となれば、マスターデータの統合化とか一元管理の対象となる、ビジネス上の事実とは何かを把握していなければ話になりません。
 当然、データ分析/データモデリングの出番となる訳ですが、MDMにかんしてはその部分をコンサル支援として表現されているようです。
 どうも、この辺りは、他のデータ中心指向をベースとする一元化アプローチも含めて、本質的な問題解決のポイントがデータ分析/データモデリングの実施とその品質にある事が、明確に語られることがありません。
 他で語られる事が無いので、ここではっきりさせておきたいと思います。
 結局、MDMの作業品質は、ツールの出来や機能ではなく、如何に段階的にデータ管理の充実を図るかと言う、データ管理ポリシーと、ビジネスの中で発生するデータを如何なる単位で記録すれば良いかと言うデータモデルの品質によって決まります。
 と言うことで、データ管理の中核には、やはり(きちんとビジネスをモデル化した高品質の)データモデルは欠かせません。
 ツールの機能を云々する前に、ビジネスのデータ構造の把握度合いが問われると言う事です。

 5.データ一自体の整備

 さて、最後に忘れてならないのが、データがビジネスの記録であると言うことによって生じる不整合への対応です。
 もちろん、行為・出来事の記録については、単純に起こった事を記録すれば、その後更新が発生する事はないので不整合が発生する心配は無いのですが、存在の記録の方は、現実の方が変わって行くので、必要に応じて、事実と記録の乖離を検知して、新しく記録する、つまり履歴管理を行う必要があります。
 データがシステムに入力されてからの完全性が保証されていても、ビジネスの実態が記録と乖離していたのでは、正しい結果は望めません。
 この場合、ビジネスの中で頻繁に接触している存在であれば、自ずと必要な更新は行われます。
 営業担当者が頻繁に訪問している先の情報は、タイムリーに入手可能だし、継続的にやり取りがある相手の情報は、変われば相手から連絡があるので、データが現実を反映するのは容易です。
 反対に、情報収集時以外に接触の機会が無い存在に関しては、事実との乖離も認識される事も無いので困ってしまいます。
 アンケートで収集したデータや、フェーア・セミナーなどで収集した見込み客データなどがこれに該当しますが、基本的には人に関するデータが中心なので、住所や電話番号から、会社の所属や役職、事業所の所在、場合によっては会社自体が変わる可能性もありますし、趣味・嗜好の類は時間の経過とともに自ずと変化します。
 年齢・性別などをターゲット選定の目安にすれば良い場合(入学/進学・受験・成人・結婚・葬儀関係など)はともかく、経済状態や信用度、趣味嗜好によるマーケティングに使うための賞味期間は案外短いものです。
 しかし、提供する商品やサービスには、タイミングが重要なものも少なくありません。
 例えば、アプリケーションプログラムの自動生成ツールを売ろうとする場合には、新しいシステム開発やシステムの再構築を計画しているタイミングでの働きかけが効果的ですが、接触する相手が都合良く、システム開発を始めるタイミングである事はほとんどありません。
 都合の良いタイミングの見込み客は少なくても、システムを運営していれば、いつかの時点でその機会が巡る事は明らかです。
 相手との継続的に接触を保ちながら、機会が巡って来た事を見逃さない対応が必要と言う事になります。
 E-mailだけの接触では、相手からの申告でも無ければ、なかなかタイミングをつかめません。
 一つ売れると数億円と言う商品を扱っているのであれば、必要な数だけ営業担当者を揃えてと言う対応も有りでしょうが、単価が下がるとそのような対応が難しい事は言うまでもありません。
 と言うことで、今回は、この悩ましい問題へのソリューションとして、株式会社ジャンヌさんのリストクリーニングサービスをご紹介して
http://www.jeanneinc.co.jp/
終わりたいと思います。
ページトップへ