ホワイトペーパーデータ移行を成功させるマスターデータ管理の活用方法本文書には Informatica Corporation (Informatica) の機密情報、専有情報および企業秘密情報 (以後、｢機密情報｣とします) が含まれており、Informatica による事前の書面による承認を得ることなく、いかなる手段においても、本文書をコピー、配布、複製、複写することを禁止します。本文書の情報が正確かつ完全であるようにあらゆる試みを行っていますが、誤植または技術的に不正確な部分が存在する可能性があります。Informatica は、本文書に含まれる情報の使用から生じるいかなる損失に対して一切の責任を負いません。本文書に含まれる情報は、予告なく変更されることがあります。こうした資料で検討している製品特性を Informatica ソフトウェア製品のリリースやアップグレードへ採用することは、リリースやアップグレードの時期と同様に、Informatica が独自に決定します。以下の米国特許の 1 つまたは複数の特許によって保護されています : 6,032,158; 5,794,246; 6,014,670; 6,339,775; 6,044,374; 6,208,990; 6,208,990; 6,850,947; 6,895,471;または以下の申請中の米国特許: 09/644,280; 10/966,046; 10/727,700。 2014 年 11 月発行ホワイトペーパー目次データ移行に MDM が不可欠な理由 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 問題 1: 「リンゴとリンゴ」を比較する . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 予定通りに本稼働するために必要な中間ステップ . . . . . . . . . . . . . . . . . . . . . 3 事例: 無数の製品 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 問題 2: 品質の重要性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 事例: 本店と支店のシステムを統合 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 高付加価値な MDM を手に入れるための出発点 . . . . . . . . . . . . . . . . . . . . . . . 5 データ移行を成功させるマスターデータ管理の活用方法 1 本ホワイトペーパーは、データ移行プロジェクトにおけるマスターデータ管理 (MDM) の重要性、有用性、最適な導入方法およびその事例について説明しています。データ移行に MDM が不可欠な理由どのような新システムでも、データがなければ稼働できません。しかも多くの場合、新しいシステムは膨大な量のデータを必要とします。私たちは今日、多数のレガシーソースから新しいシステムにデータを移行しています。また、新しいシステムのデータをエンリッチ化するために、郵便局の住所ファイルなどの外部ソースを利用します。インフォマティカのデータ移行ツールキットは、こうした現代のデータ移行シナリオで生じるさまざまな課題を解決できるテクノロジーとベストプラクティスのプロセスを提供します。まず初めにデータ移行における課題について説明します。移行先となるターゲットシステムはさまざまな業務分野に対応できる包括的なシステムかもしれません。しかし、データが存在しているソースシステムは、さまざまなビジネス要件を満たすためだけに設計されていることが多々あります。例えるなら、各業務を支えるシステムは、ストーブの煙突のように垂直型のソリューションです。ターゲットシステムには、一貫性のあるデータを移行したい一方で、レガシー環境はデータ構造やコンテンツに一貫性がありません。ここで、2 つの問題が発生します。しかし、どちらの問題にも MDM なら最適に対応できます。問題 1: 「リンゴとリンゴ」を比較するでは、新しい生産計画アプリケーションをインストールするというシナリオで問題点を考えてみましょう。新しい生産管理アプリケーションは、会計アプリケーションと人事アプリケーションをリンクさせることで、生産現場の管理を強化し、効率化することができるシステムです。しかし、会計部門と人事部門、生産管理、また各部門が使用するアプリケーションは、実世界では全く同じにしか見えないモノを、全く異なる視点で見ています。会計担当者は、新しい生産管理アプリケーションを導入する生産現場を、コストセンター、利益センター、減価償却、資本資産、営業資産として捉えています。生産技術担当者は、自動／半自動／手動プロセス、ワークフロー、保全スケジュール、生産量といった属性で捉えます。人事部門は、社内スタッフ、社外スタッフ、トレーニング要件、スキルレベル、賃金契約、医療の観点から見ています。このように、全く同じものを違う視点から見ているのです。当然の結果ですが、各部門はそれぞれに最適だ思うシステムを選択し、全く異なるシステムを設計していたことになります。どの部門の判断も間違っていません。ただ、必然的に一貫性が欠けているのです。その結果、データ移行の段階になった時に、彼らは互いの要件を「リンゴとリンゴ」という同じ対象で比較していなかったことに気付きます。言い換えれば、リンゴとナシを比較していたのです。移行を成功させるには、同じ種類の果物を比較しなければ意味がありません。ただし、どれかをあきらめれば良いという事でもありません。各部門の選択は、いずれも間違いではないのです。生産部門の視点が (本ケースでは、生産部門の要件が新システムの重要なドライバーな為に) 最も適切だと判断したとしても、他部門が利用しているデータストアにあるデータを、生産部門のモデルに適合するように無理矢理変更すべきだと主張することもできません。いずれにしても、各部門のレガシーデータストアは、それぞれの業務分野をモデル化している点で適正であるという考え方になります。生産の観点では生産部門の言い分が正しく、人事の観点では人事部門が正しい、ということです。従って、こうした全ての視点に対応できるモデルが必要となります。このように、既存システムにおける見方の違いは、ターゲットシステムについても全く同じことが言えます。それでは次に、ターゲットシステムの受け入れ準備が整うまで待ってからデータのギャップ分析を実行すべきでない理由について説明します。 2 予定通りに本稼働するために必要な中間ステップ移行に際して最初に直面する問題が、断片化したデータの調整だと仮定します。通常、どのように移行プロジェクトは進行するでしょうか？新システムの設計とインストールに 1 年かかると仮定した場合、少なくともターゲットシステムが使用できるのは 8 カ月目以降であり、しかも完成形ではありません。(これは、プロジェクト立ち上げ準備、現状分析、新システムのコンフィグレーション設定、ビジネスプロセスの再構築作業を含む標準的なプロジェクトを前提としたシナリオです)。経験上、ターゲットシステムの安定稼働には、10 カ月かかります。しかも稼働開始ぎりぎりまで変更が発生するでしょう。さらに経験上、データのギャップ分析、抽出、変換、ロード、ロードスクリプトの記述／テストの実施には、たった 2 カ月しかありません。これでは、レガシーデータストア間の構造的な差異に関して高品質な分析を行っているような余裕はありません。ましてやロードファイルに必要な合成データ項目を生成できるはずもありません。このような時間の制約を解決できる 1 つの方法は、中間モデルを作成することです。(インフォマティカはこれを移行プロトタイプと呼びます) 各レガシーデータストアとプロトタイプを比較してその差異を記録し、データをクリーンアップする作業から開始します。次に、ターゲットソースが最終的に完成したら、プロトタイプとターゲット間の差異を確認します。このように移行プロトタイプを介することで、レガシーデータストアとターゲットデータストアの変換要件を個別に定義しておけば、最も忙しく、プレッシャーの大きいプロジェクトの最終段階で大幅に作業を簡素化できます。つまりこれは巧妙なトリックです : ターゲットシステムの未来形を推測した最も妥当な移行モデルを構築し、レガシーと移行モデルの間の差異を分析し、データの変換、エンリッチ化、拡張を行います。次に、本物のターゲットが完成したら、細かいレベルで精度を向上するために変換を微調整します。このように、プロトタイプモデルを 80% の (経験上は、さらに高い)適合率で作成しておけば、プロジェクト最後の厳しい数週間が来る前に、変換ロジックの 80% の設計が完了していることになります。では、本モデル作成の過程で、マスターデータ管理ソリューションが役立つ理由は何でしょうか？ウィキペディアからの引用 (英語版の翻訳) 「MDM は、組織全体を通じてデータの収集、集約、マッチング、統合、品質保証、維持、提供を行い、これらの情報を継続的に保守し、アプリケーションで利用できるように、一貫した制御能力のあるプロセスを提供することを目的としています。」例に挙げた 3 つの部門(会計、生産、人事) の異なるビューは、関連するデータストア内では、コード値としてインスタンス化されます。つまり今回のプロジェクトでは、MDM の「収集、集約、マッチング、統合、品質保証プロセスを提供する」ことが大いに関係します。一方で、本プロジェクトの目的を考慮すると、MDM の「組織全体を通じたデータの維持、提供」は直接的には関係ないことになります。「これらの情報を継続的に保守し、アプリケーションで利用できるように、一貫した制御能力のあるプロセスを提供すること」が、今回の移行プロジェクトの最も重要な課題となります。まとめると、本プロジェクトの目的がシステムの拡張ではなくリプレイスであることから、移行したデータを元システムに戻すというプロセスは不要であり、それ以外の部分で MDM のアプローチを採用するということです。データ移行を成功させるマスターデータ管理の活用方法 3 事例: 無数の製品ここまで述べてきたことをより明確に理解するために、実例を挙げます。ある大手通信会社がデータ移行を実施しました。顧客が数千万人、インストール数が数億あり、さらに個別製品数が最大 10 万点もある大規模な移行プロジェクトでした。また、関連製品を次々と開発するために多様な部品が爆発的に増加し、それに対応する必要がありました。さらに、レガシーシステムの数が多いことも移行の障害でした。同社は、注文、設計、提供、請求処理が、物理的にも論理的にも複数レイヤーにわたるため、各段階に複数のポイントソリューションを構築してきました。その結果、約 400 を超えるレガシーシステムの中から、1 インストール当たり約 30 のレガシーシステムに対処することが求められました。もちろん、同社のレガシーシステムは、業務プロセス全体の流れのどこに位置するか、論理的、物理的あるいは財務的な見方をするのかといった違いによって異なるビューを持っていました。ではここで、同社の製品構造における問題点とそれを MDM ソリューションで解決することが不可欠であった理由について考えてみます。同社は、何十万点もの製品がある上に、ある製品が他の製品の構成品であったりするために、非常に多くのルールが存在していました。また同社のレガシーシステムには、単純な電話設置だけを管理するシステムもあれば、受話器や発信音、発信ダイヤル、着信拒否、着信履歴ダイヤル、留守電機能を含めたセットを管理するシステムもあり、言い換えればひとつの家に固定電話を設置するだけでも、非常に多くの製品が関連していました。言うまでもなく、音声ネットワークやデータネットワーク向けの製品に至っては、より複雑でした。プロビジョニングプロセスにあるシステムによって、「電話」というデータの捉え方が異なっていたのです。まずは一貫性を確保するために、できるだけ早くデータの差異に着手する必要がありました。移行先となるターゲットシステムが利用できるようになるまで待つ余裕はありませんでした。この問題を解決したのは、製品および構成品のマスターデータ管理ハブを作成することでした。変化の激しい同業界で、絶えず新製品が設計、追加されるといった要件には、週 1 回の更新処理で対応しました。また MDM ハブを使って、レガシーデータストア内をチェックして一致する製品を確認するとともに、デリバリチェーンの各ポイントで製品に対して表現に差があっても、ひとつのビューで把握できるようにしました。移行の各フェーズで、ソースシステムとターゲットシステムの構造差異を理解できていたので、必要に応じてマッピングと変換を再コーディングすることができました。問題 2: 品質の重要性では第 2 の問題であるコンテンツ／データ値について考察します。レガシーデータストアに同一ビジネスオブジェクトを複数構造で持つことができるように、複数の値を持つことも可能です。よくある例をいくつか挙げてみます。全てのマーケティング部門の悩みの種と言えば、複数のデータストアから収集した顧客リストには、常に重複データがある事です。簡単に見つけて排除できるものもあれば、同音異義語や同義語が関わる厄介なものもあります。例えば、John Smith さんは J Smith さんと同一人物なのか、J Smith さんは J P Smith さんなのか、あるいは全く別の Jonnie Smith さんかもしれません。移行の際も、同じ問題に直面します。こうした問題は、同一データストア内に同一人物のデータコピーが複数存在するような環境でよく見られます。 4 また多くの場合、データ構造の問題によってさらに複雑化します。例えば、B2B (企業間) 環境では、誰が顧客なのかについて混乱することが多々あります。法定上、階層の最上位に位置する組織を顧客と捉えるべきなのか (つまり、訴訟問題となった場合に法廷に召喚される組織)、あるいはその組織の傘下にある実際の取引相手を顧客とすべきなのか、それともデポや店舗なのか、といったことです。この場合も、業務全体のどの部分を担当しているかによって見方が異なります。ロジスティクス部門であれば供給元であり、請求部門であれば供給元と請求先の詳しい住所を知る必要があるでしょう。また、地域担当の営業チームとは別に、大手顧客に対しては戦略的関係を構築するために管理者層がついていることもあります。このように、法的には 1 つの法人であっても、地域によって何百もの異なる受注先、配送先、請求先が存在することになります。このような場合、特にソースシステムが間違って登録している訳ではないので、単純に例外として処理できないかもしれません (もちろん、プロセス上のミスで、同一顧客のデータが 2 回作成されるような単純な重複もありますが、それはレガシーデータストアでも明らかに間違いなので修正できます)。では、どこからどのように始めれば良いのでしょうか？また、MDM ソリューションはどのように役立つのでしょうか？まず、主要なエンティティのマスターデータを作成するのに MDM が最適なソリューションであることは言うまでもありません。ここでは、少なくともレガシーデータセットに存在すべきではない重複に関して、MDM が「情報を継続的に保守し、アプリケーションで利用できるように、一貫した制御能力」を提供するというミッションのもとに提供できるほぼ全ての機能を利用します。事例: 本店と支店のシステムを統合もう 1 つの実例を使って、この問題を明確に説明します。ある中規模の金融機関が移行を必要としていました。同行は、さまざまな地域に支店があり、各支店が本社システムの異なるインスタンスとなっていたため、バッチ処理で本店へデータをリンクしていました。ここでの問題は 2 つありました。構造的な解釈が地域によって異なっていたこと、そして支店内および支店間でデータに重複があったことです。そこで MDM テクノロジーを利用して、唯一真実の情報を把握できる単一ビューを構築し、関連するソースシステムにリンクを貼り直すことにしました。目標は、関連性の高いデータを一貫したデータ構造に当てはめること、そして本稼働する際には、支店内および支店間のデータ重複を排除することでした。同行は、移行完了後も唯一真実の情報を提供するコーポレイトビューとして MDM を活用し続けています。インフォマティカについて Informatica Corporation (NASDAQ:INFA) はデータ統合ソフトウェアおよびサービスにおける世界 No.1 独立系プロバイダーの 1 社です。インフォマティカのソリューションによって、世界中の企業がデータから可能性を引き出し最も重要なビジネスニーズを満たしています。業界初にして唯一の埋込み型仮想データマシン (VDM) である Informatica Vibe は、「一度マッピングすれば、どこでも適用可能」というユニークな機能を備えたインフォマティカのプラットフォームです。現在、世界中の 5,800 社を超える企業が、社内だけでなくクラウドやソーシャルネットワーク全般を網羅しながら、デバイスからモバイル、ソーシャルからビッグデータに至るまでの全ての情報資産から最大限の価値を引き出し、活用することに成功しています。インフォマティカに関する詳細はインフォマティカ・ジャパン株式会社 ( 代表 : 03-5229-7211) までお問い合わせいただくか、インフォマティカ We b サイト http://www.informatica.com/jp/ をご覧ください。高付加価値な MDM を手に入れるための出発点データ移行という重要なイベントは、MDM 実現の最適な出発点であり、また移行後も MDM を持続的に利用できるというメリットもあります。移行のためにデータの準備をする過程では、重複データを削除し、構造的な差異に関するセマンティクスの問題を解決する必要があります。これまでは、使い捨てのアプリケーションを作成して、プロジェクトに必要な情報の単一ビューを作ることも多々ありました。しかし、業界先進的な MDM ソリューションを利用して MDM を完成させ、最終的には貴社のアーキテクチャに完全統合するという考えの元にデータ移行に取り組めば、より一層高い成果を得られます。本書では、MDM テクノロジーの価値について説明しました。MDM の適用に伴うセマンティクス上の問題とテクノロジーの両方についてご理解いただければ幸いです。データ移行を成功させるマスターデータ管理の活用方法 5 〒162-0845 東京都新宿区市谷本村町 1-1 住友市ヶ谷ビル 13 階電話: 03-5229-7211 (代表) FAX: 03-5229-7623 www.informatica.com/jp linkedin.com/company/informatica twitter.com/InformaticaCorp © 2015 Informatica Corporation. All rights reserved. Informatica® および Put potential to work™ は、米国およびその他の国における Informatica Corporation の商標または登録商標です。その他すべての企業名および製品名は、各社が所有する商号または商標です。 IN09_1114_02752