プロセス統合を支えるデータベースとデータ統合を支えるデータウェアハウス DBMSとDWHの違い：統合CRMを支える情報基盤（2）

「顧客起点経営」を実現するためには、基幹系システムのプロセス統合のみならず情報系システムとして全社的なデータ統合も忘れてはならない。これをできるだけシンプルな例で説明してみよう。そしてプロセス統合を支えるデータベースとデータ統合を支えるデータウェアハウスのアーキテクチャと役割の違いに言及したい

[泉谷 章，日本NCR株式会社]

基幹系のビジネス・プロセスだけが統合された例

　まずは、以下の事例を見てほしい。

　A社では、ある顧客から複数の製品の注文を受けた。

　受注担当者は直ちに基幹系システムである受注処理システムに、この受注取引データ（受注トランザクション）を入力した。受注処理システムは、与信をチェックし、在庫・出荷管理システムの在庫残高を参照し納期に間に合うことを確認、受注伝票を発行して、受注販売統計のために日別・地区別・顧客別販売実績データ（サマリデータ）を更新した。在庫管理システムは在庫引当を、売掛請求システムはこの顧客の売掛請求明細の更新をリアルタイムに行った。

　在庫・出荷管理システムは納期が近づいたので出荷指示を行い、在庫残高を引き落としたうえ、日別・地区別・顧客別出荷実績データ（サマリデータ）を更新した。売掛請求システムは締め日には請求明細書の発行を行い売掛残高を更新した。

　以上はデイリーバッチ処理ではなく、リアルタイムに基幹系システムが更新される見事なプロセス統合の例である。ところが、次のような要求があった場合、どうだろう。

　グローバル企業のある顧客が、今年度の世界中の地区製品別納入実績明細を求めてきた。この要求を受けた営業担当者が早速調べてみたところ、この顧客の問い合わせに答えられないことを知った。製品別納入実績明細データが残されていなかったのである。

　また、従来の製品に代わる新製品の販売促進を任せられたマーケティング担当者は、この従来製品がどの他製品との組み合わせでどんな顧客層に売れてきたかを分析し、新製品のターゲットセグメントを決めようとした。しかし、彼もそれが不可能であることに気付いた。このような分析にこたえられる明細データがストアされていないためであった。

　以上の問題は、受注処理、在庫・出荷管理、売掛請求システムはリアルタイムにプロセス連携され、各種の定型統計レポートを作成し、そのサマリデータはストアされているが、製品出荷に関する明細データがストアされていないことに起因している。

　本来、基幹系システムのデータ設計はトランザクション処理を短時間に行うように設計されており、詳細な検索や高度な分析用には設計されていない。以上はあくまでも1つの例であって製品出荷明細かどうかにかかわらず、ほかの切り口でも同じような問題が発生するはずである。

明細データが基幹系のデータベースにストアされた例

　B社では、営業部門やマーケティング部門の要求にこたえるために大幅なシステム変更を行い、できる限りの明細データを基幹系のデータベースに履歴として残すようにした。そしてこの明細データの活用のために、営業管理部門やマーケティング部門のパワーユーザーにSQLの講習会を行った。

　顧客や市場の厳しい要求にさらされていた営業部門やマーケティング部門は、同じデータでもシステムによってケタ数が異なっていたり、フォーマットが異なっていたりといった問題を抱えながらも、各自の努力で都度データの整理を行いながら、この情報公開を待っていたとばかりに非定型クエリやレポート作成を多発し始めた。

　クエリの中には多くのテーブルジョインが行われるケースもあり、また大きなテーブルの全件をサーチするようなSQLも発生し、1つのクエリが終了するのに数時間がかかるばかりか、しばしば受注や出荷のデータエントリシステムのレスポンスに重大な影響を与えるようになった。時には基幹系システムが停止する事態も発生するようになった。

　情報システム部門はこれらのパワーユーザーを危険な存在と見なすようになり、数々の使用制限を設け始めた。営業管理部門やマーケティング部門のパワーユーザーたちは会社の方針である「顧客起点経営」を情報システム部門はまったく理解していないのではないかと疑いの目を向け始めた。

目的別のデータマートを構築し始めた例

　C社は「顧客起点経営」の観点からは、ビジネス・プロセスを円滑に処理することによる顧客満足度の向上と、顧客がアドホックに要求する非定型な明細データ要求にこたえることによる顧客満足度の向上の両方が必要であることに気が付いた。そこで基幹系システムで発生した原始データを基幹系システムのデータベースとは別のデータベースにコピーし履歴としてストアし始めた。同時に情報リテラシーとの兼ね合いから、OLAP（Online Analytical Processing）ツールを導入し、多くの社内ユーザーが自由に情報を活用できる情報インフラを構築した。

　この際、営業部門やマーケティング部門などの各部門の使い勝手を考慮して部門別の検索・分析用データベース（データマート）を用意した。また、情報システム部門のメンテナンスコストも考慮して、基幹系システムで採用しているデータベースソフトと同じソフトを採用した。

　その後、部門別のデータマートの数は増える一方でデータの重複も多く発生し、データマートのTCO（Total Cost of Ownership）が問題となり始めた。ユーザー部門からは定型的な部門業績管理のためのレポートやクエリには便利ではあるが、部門横断的な顧客要求にこたえるにはデータマート間で連携ができないこと、自部門の業績管理指標（KPI）で異常が発見されてもプロセスが多部門にまたがるため真因が発見できず、改善のアクションにつなげられないなどの不満が出始めている。

　以上は日本の先進的な企業におけるIT導入の典型的な現状の例である。

　これらの問題を解決するためには、複数の部門別のデータマートを全社的な1つのデータウェアハウスに統合する必要があり、OLTP（Online Transaction Processing）用に設計されたデータベースではなくデータウェアハウス用に設計された仕組みを採用する必要がある。

データベースとデータウェアハウスの違い

　基幹系システムのデータベースとして、一般的には市販のRDBMS（Relational Database Management System）ソフトが用いられている。このRDBMSはいかに短時間に大量のトランザクションを処理するか、いかに短時間に大量の定型クエリを処理するかといったOLTP向けのアーキテクチャの下に設計・開発されている。すなわちオペレーショナルな業務処理をシステム化するためのデータベースは「業務プロセス」を「効率よく回す」ことが求められ、プロセスの「その時点の情報を」ストアするためのものである。

　一方、データウェアハウスに求められる機能はトランザクションや定型単純クエリの高速処理ではない。大量の明細データを対象に、いかに非定型で複数のテーブルジョインが多発する複雑クエリを効率よく処理するかのアーキテクチャが必要となる。

　すなわちデータウェアハウスは、「現在の状況」と「過去のスナップショット」の両方のデータをストアし、それを分析することによって「将来の予測」を行おうというものである。

　既存のOLTP用RDBMSソフトのテクノロジになじみがあるからTCOが安く済むという理由で、同じソフトをデータウェアハウス用にも採用するケースが多く見られるが、目的と求められるアーキテクチャが明らかに異なり、TCOはかえって高く付くことに気が付くべきである（図1）。

図1　基幹系のOLTP用データベースと情報系の意思決定用データウェアハウスの違い
*図の著作権は日本NCR株式会社に帰属

　また、昨今BI（Business Intelligence）ツールとか、OLAPツールと呼ばれたりする分析用のエンドユーザーツールの議論は盛んだが、分析対象のデータ構造やそのデータベース・アーキテクチャに議論が及ばないのはバランスを欠くといわざるを得ない。

ODS、データマート、そしてデータウェアハウス

　一般にデータウェアハウスと呼ばれている仕組みにも、実は「ODS（Operational Data Store）」と「データマート」、そして本来の「データウェアハウス」がある（図2）。

図2　ODS、データマート、データウェアハウスの関係図
*図の著作権は日本NCR株式会社に帰属

　ODSとは、基幹系のビジネス・プロセスを構成する各システムがリアルタイムに明細レベルでデータを共有するためのもので、データウェアハウスに非常によく似ているものの目的が定型的で、短期的にしかデータはストアされない点が異なる。

　データマートは全社的なデータウェアハウスに対して、部門目的を満たすために部門別に用意されたデータの格納庫である。データマートにも独立型データマートと従属型データマートがある（図3）。

図3　データマートの形
*図の著作権は日本NCR株式会社に帰属

　独立型データマートでは、利用部門の増加や目的の拡張に伴い、複数のデータマートが作成されることになる。このような場合、ETL（Extract, Transformation and Load）と呼ばれるソースシステムからのデータの抽出、変換、ロードに重複が発生する。もともとデータウェアハウスを構築するうえでETL部分が最もコストと時間がかかる部分である。そして各データマート間のデータの整合性を保証するためには多大なコストと時間を要する。

　その点、従属型データマートはデータマート層の上位層でデータが一元管理されるためデータマートから見た場合、ソースシステムはあくまでも1つであり問題は少ない。

　データウェアハウスは全社の基幹系システムで発生した全原始データを定期的にロードし、長期的（一般的には3年間から5年間）に履歴として明細データをストアしておき、定型、非定型の両方のレポートやクエリに利用される。特定の目的のアプリケーションに従属するものではなく、アプリケーションからはニュートラルで汎用的な目的のためのものである。

データウェアハウスの現状と進化

　日本では7〜8年前にデータウェアハウスのブームが起きた。大福帳システムという名の下に、ともかく加工前の生データをストアしておけば何かの役に立つという認識であった。

　この時点で多くの企業がデータウェアハウスの導入を競ったが、残念ながら導入目的が不明確でその多くは「データウェアハウス活用の高度化」（図4）の第1段階であるレポ−ティング・ツールとしてとどまっている例が多い。

図4　データウェアハウス活用の高度化（画像拡大）
*図の著作権は日本NCR株式会社に帰属

　また、データウェアハウスと呼ばれてはいるが販売管理部門用に販売履歴データだけがストアされていたり、営業部門用の顧客データだけがストアされているデータマートでしかない例も多い。そして当時のデータウェアハウス（DWH）の利用目的は「全社的な戦略的意思決定のためのDSS（Decision Support System）」といわれ、経営企画部門などの少数ユーザーのためのシステムであると認識されていた。

　その後、DWH導入企業の要求とテクノロジの進化により、DWHは「データウェアハウス活用の高度化」（図4）の第4段階や第5段階に当たるEDW（Enterprise Data Warehouse）やADW（Active Data Warehouse）という概念に発展してきた。EDWとは真の意味でのエンタープライズレベルでの明細データの活用であり、ADWとはソースシステムである基幹系のOLTPシステムからのデータのロードを日単位からニアリーリアルタイム（分の単位）に行うものである。そしてその活用は社内の多くのナレッジワーカーに広がり、刻々と変化する日常業務の中の戦術的意思決定にも利用されるものである（図5）。

図5　DWHからEDW／ADW
*図の著作権は日本NCR株式会社に帰属

　そして、レスポンスタイムなどの当時のテクノロジの限界から発生したODSや目的別データマートはEDW／ADWにいずれ吸収されることになるだろう（図6）。

図6　ODS、データマートの統合
*図の著作権は日本NCR株式会社に帰属

　

EDW／ADWの導入と顧客起点経営のためのビジネス・インテリジェンスの獲得

　「企業の縦割りの業務システムやサマリデータしか持たない制約は企業サイドの問題であって、顧客には関係ない。全面的に顧客の要求に対応せよ」といったところで、全社のすべての業務システムで発生し得るデータをソースとして、すべての顧客やエンドユーザーの要求にこたえるためのデータベースを一気に設計・導入することは現実離れしている。実際には、顧客やエンドユーザーが何を要求するかを事前に予測することも不可能だからだ。しかし、アーキテクチャとメソドロジを混同すべきではない。

　真の「顧客起点経営」を実践するために、顧客目線でビジネス・プロセスの現状を「可視化」することが必要だ。そのためには、データウェアハウスの考え方はEDW／ADWのアーキテクチャの発想であるべきだが、導入のメソドロジは段階的であって構わない。企業が抱える最重要の問題点、顧客の最重要要求を満たす部分からステップバイステップで導入していくことが現実的である。

　このように構築されたEDW／ADWは、統合された唯一のデータという真実の下で、顧客価値創造のための経営レベルの意思決定や顧客価値を最大化するための日常業務上の意思決定、そして顧客視点から見たビジネス・プロセスの問題点の発見につながるBIとして大いに役立つものになるはずだ。

著者紹介

▼著者名　泉谷 章（いずみたに あきら）

日本NCR株式会社 ソリューション統括部 エグゼクティブ・コンサルタント

ERP・SCMの前身であるMRPのソリューション・ビジネスに長年携わり、1996年には日本で最初のコールセンター、SFA、フィールド・サービスなどのオペレーショナルCRMビジネスを立ち上げる。2000年からはアナリティカルCRMに活動領域を広げ、現在は統合CRMのみならずERP、SCMを含む顧客起点経営のためのビジネス・プロセス革新とデータ統合のコンサルティングに従事

「統合CRMを支える情報基盤」バックナンバー

• データウェアハウスがもたらす真の顧客起点経営
• BIツールで構築する「顧客起点」のビジネスプロセス 真の統合CRMを実現するビジネスインテリジェンス
• プロセス統合を支えるデータベースとデータ統合を支えるデータウェアハウス DBMSとDWHの違い
• 顧客起点経営に必要な全社データ統合 プロセス統合を補完するデータウェアハウス