ホワイトペーパー データ移行を成功させるマスター データ管理の活用方法 本文書には 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
© Copyright 2024 ExpyDoc
