ホーム > ライブラリー > マーケティング・アナリティクス > HAL9000への漸近線 > 第2回: EDWコンセプト: 包括的なデータウェアハウス
HAL9000への漸近線
- データウェアハウスを顧客管理プロセスに適用する
山本 泰史
マーケティング統括部
マーケティング部 スペシャリスト
第2回: EDWコンセプト: 包括的なデータウェアハウス
ここでは、HAL9000 から抽出した要件の 1つ目、「包括的なデータセットを集め、保管する」に照らし合わせて Teradata とそのコンセプトを検討します。この要件に対応する形で Teradata が掲げているコンセプトは EDW: Enterprise Data Warehouse - 全社規模の情報を包括的な形で集め、保管するデータウェアハウスです。既に記述したように、包括性は「広範性」と「一元性」によって満たされます。その企業の内外で発生するデータで利用に値するものは全て格納されなければならず、それらのデータは重複無く、統合的に、関係性も含めて保管されなければなりません。また付随的には、企業内外のデータを必要とする全ての人やシステムにサービスが提供可能でなければなりません。このコンセプトを単一のキーワードとして括ったのが EDW ですが、EDW について説明する前に、何故データベース管理システムなのか、そして何故 Teradata なのかについて簡単に触れます。
キーテクノロジーは SQL
本稿が主張する点の 1つは、HAL9000 のマシンコンセプトを実現するキーテクノロジーは、データベース管理であり、SQLであるという点です。Web2.0 というキーワードを流行させた Tim O'Reilly は、その発端となったレポート "What Is Web 2.0" の中でデータベース管理、そして SQL が Web2.0企業のコアコンピテンシーであることに触れています。情報収集、蓄積、そしてそれを用いたユーザーサービスという包括的なエリアを同時にサポートすることを考える場合、確かにデータベースと SQL は適切なものであると言えるでしょう。目的がインターネットユーザーのサポートであれ、木星探索であれ、ビジネスのサポートであれ、指摘したように包括的なエリアをカバーしなければなりません。また、ジェネリックなデータベースエンジンであれ、HAL9000 であれ、Teradata であれ、このようなマシンコンセプトを実装する必要があります。
特に重要となるのは、SQL です。データを収集するとき、特定のテーブルにそれを配置するとき、演算処理をするとき、処理をキックするとき（それがユーザー起動であれ、自動起動であれ、スケジュール起動であれ、イベントベースの起動であれ）、そして処理結果を指定の場所に連携するとき、全て SQL が用いられます。企業がこのようなマシンコンセプトをビジネスに実装すると考えた場合、SQL こそがビジネスロジックの具体的な姿であり、SQL の量と質、複雑度、順序や構造こそが、その企業の運行能力、状況対応能力を意味していると考えます。
Teradata の合致性
Teradata は、並列型のアーキテクチャをその設計思想としています（このアーキテクチャについて詳しくお知りになりたい方は、Teradataデータベースアーキテクチャ概説の 1及び 2をご覧下さい）。これによって Teradata は「拡張性」と「高いパフォーマンス」という 2つの特徴を有しており、これが要件 1「包括的なデータセットを集め、保管する」への合致性に結びついています。包括性が持つ要素のうち、「広範性」を考えた場合、データは以下のような観点から膨大となります。特に大企業においてこの傾向は加速度的に強まっています。
- データ種類の増加（より様々なデータ： 売上データだけでなく、在庫データも保持したい）
- データ粒度の増加（より明細なデータ： 商品別売上だけでなく、レシート明細を保持したい）
- データ期間の増加（より長期で、より新しいデータ： 5年前のデータ、5秒前のデータも保持したい）
このようなデータ保持欲求は、サービスを享受する利用者のデータ活用欲求によって牽引されます。つまりそれだけのニーズがあり、それらのデータに対してアクセスが発生するということです。これは利用者と利用頻度の増大を意味し、よって「高いパフォーマンス」を必要とするのは自明です。さらにもう 1つの要件である「一元性」を実現させる場合、利用者はデータ間の関係をたどり、データベース的には Join処理を繰り返すことによって欲しいデータを取得します。これがさらに「高いパフォーマンス」を要求します（これを支援できなければシステムを分散化させたり、集約データを作成したりすることが必要になります。つまり管理上の煩雑さを増大させることによって、低いパフォーマンスで対処可能にさせるという「妥協」を余儀なくされる訳です）。そして「広範性」に話を戻すと、膨大なデータを保管し、それを用いてサービスを提供するために、膨大なディスク領域とコンピューターパワーを準備する必要があります。Teradata は単一のシステムでありながら、ペタバイトクラスのデータ容量に対応し、千を悠に超える CPU の疎結合が可能なアーキテクチャです。つまり充分な「拡張性」を有しており、またそれが「高いパフォーマンス」をもたらしているのです。従って Teradata を用いれば、「広範なデータ」を、「一元的」に、保持することが可能となるのです。
EDWコンセプトを分解する
Teradata によって技術的な裏づけがなされるという前提で、広範なデータを一元的に活用するには、まずその全体観を定義する必要があります。図1 は Teradata が標榜する EDW の全体観です。これを下位層から見ていくことにします（Teradata については前述のため、割愛します）。
1.論理データモデル
論理データモデルは、ご覧の業界毎にデータ項目と、データ間の関係を洗い出して網羅／整理した、データベース構造の論理的な雛形です。多くのデータウェアハウス構築実績に基づいて作成された Teradata の知的資産となっています。論理データモデルは、幾つものエンティティとリレーションによって構成され、エンティティは物理データベースにおけるテーブルに、リレーションは物理データベースにおける外部キーと主キーの関係に相当するものです。また、各エンティティは、サブジェクト（主題）エリアでグルーピングされています。例えば商品に関連するデータエンティティは全て同じ「商品サブジェクトエリア」にグルーピングされ、ハイレベルでの重複排除をコントロールします。そしてこのモデルは正規化された形式で設計されているため、最初の導入段階、そして後々の様々なデータ項目拡張段階においても、データの重複が発生しないモデルを実現することが可能となっています。つまり広範性と一元性の両方を確保することが可能となのです。また、様々な活用パターン、データニーズに対しても、柔軟性の高い形で対応することが可能です。
2.ビジネスプロセスのサポート
正確な意味での広範性は、その企業が必要とするデータ種別を完全に備えていることです。この必要性を定義しているのが、ビジネスプロセスです。図1 からご覧いただけるように、企業には顧客管理や財務パフォーマンス管理といった業界を問わず存在するビジネスプロセス、物財を扱う業界に共通して存在するサプライ／デマンドチェーン管理のプロセス、そして業界特有のビジネスプロセスが存在します。ビジネスプロセスは、「管理すべき業務の対象とその流れ」として定義されます。例としてここでは顧客管理を取りあげましょう。顧客管理というビジネスプロセスの目的は、顧客満足を提供しつつ、以下を実現することです。
- 顧客数、つまりマーケットシェアを最大化すること
- 顧客あたり支出、つまりウォレットシェアを最大化すること
- 顧客あたり生涯利益（LTV: Life Time Value）を最大化すること
ここで、顧客管理の「管理」という言葉は、"Control" もしくは "Own" といった意味と誤解されるかもしれませんが、"Management" の対訳です。意味合いとしては「何とかする（Manage）」という意味がもっとも近いです。前述の目的を達成するためには、幾つかの業務を行なっていかなければならず、その過程において克服すべき課題が幾つか存在することでしょう。何らかの手段を用いて「何とかする」ことによって、目標達成へと導くことが求められ、その取り組み一環を指しているのが顧客管理です。言い換えれば「顧客に関する諸問題を何とかする」ことです。また、何とかするための手段の 1つとして、特定課題に対するデータ分析や、それに伴う行動／プロセスの改善がクローズアップされます。これを Teradata では経営改善課題（BIO: Business Improvement Opportunities）と呼んでいます。従い、任意のビジネスプロセスは複数の経営改善課題を内包していると定義づけできます。
また「広範性」と「一元性」を有するべきという、包括的なデータセットの要件は、複数ビジネスプロセス間の関係からも求められます。「顧客に関する諸問題を何とかする」とき、顧客関連のデータのみで必要な知識を全て得ることができるでしょうか。金融業は顧客を評価し、営業活動やマーケティング活動を行なう際に、貸し倒れリスクと向き合わない訳にはいきません。小売業は商品のデータを顧客分析に利用することによって、顧客の嗜好性を理解することが可能となります。通信業や航空業は、ネットワーク運営や航行業務といったプロセスの障害、遅延が顧客満足度にもたらす影響を理解する必要があります。これらは全て図1内に記述された、顧客管理以外のビジネスプロセスとも関連するものであり、ビジネスプロセス間にも分析の対象が潜んでいること、単一のビジネスプロセスに複数のデータを以って対処する必然性があることを示唆しています。このような観点からも単一の、包括的なデータセットが求められます。図2 は通信業を想定したデータ（サブジェクトエリア）と分析の関係です。それぞれの分析は特定のビジネスプロセスに傅きますが、ビジネスプロセス毎にデータ管理を行なった場合、データが重複してしまうことを示しています。
3.経営改善課題
経営改善課題を別の言葉で定義するならば、ビジネスプロセス上のボトルネックです。これを改善することが経営上の課題であり、またそれを行なうことがビジネスプロセスの目標を達成するための機会でもあります。1つの経営改善課題は大きく、以下の 4つで定義されます。いずれの経営改善課題もデータの分析や活用を必要とし、それによってボトルネック改善がもたらされ、定量的な意味でビジネスプロセスの目標達成を実現できるエリアを特定しています。
- 目的 - 課題改善の目的、ポイント。ビジネスプロセスの目的を細分化／具体化させた中間目標
- 分析 - 課題改善のために必要なデータとその活用方法を定義したもの。
- 行動 - 分析の結果として何をすべきか、どのように業務やプロセスを変更すべきかを定義したもの。
- 効果 - 行動の結果としてビジネス上の成果がどのように／どれだけ達成されるのか？
例えば顧客管理に関する経営改善課題を考えた場合、以下の 4つが挙げられます。
- 新規顧客の獲得
- 優良顧客の育成
- 顧客リテンション
- マーケティング経費効率の向上
これらのそれぞれについてはこの連載で追って詳しく触れていきますが、各経営改善課題について目的、分析、行動、効果が規定されることになります。また、各業界、各企業によって置かれた環境は異なり、リストアップされる経営改善課題、そして経営改善課題で規定される目的、分析、行動、効果の有り様は少しずつ異なってくることでしょう。そしてこの経営改善課題、そしてビジネスプロセスの背後に存在しているのが「利用者」です。顧客管理であればマーケティング部門、チャネル関連部門等がその主たる利用者となることでしょう。企業内には様々なデータの利用者が存在し、利用者ニーズの総量がビジネスプロセス、経営改善課題という整理を経て、必要なデータとしてリストアップされます。そしてこれこそが必要なデータの広範性を規定するのです。
次回は、「ADWコンセプト: 能動的なデータウェアハウス」として、HAL9000 から抽出した 6つの要件のうち、残り 5つに関する対比を試みます。
