Ｍ－ＯＬＡＰ ～ ＩＴコンサルティング

ＯＬＡＰツールは、Ｍ－ＯＬＡＰとＲ－ＯＬＡＰの二種類の製品があります。 両方ともＯＬＡＰツールですが、その考え方、 使用方法はかなり異なります。

今回は、Ｍ－ＯＬＡＰです。 Ｍ－ＯＬＡＰは、Multi-dimensionsのＭです。 日本語では多次元分析ツールと呼ばれていることがおおいようです。 多次元データベースとかとも呼ばれています。

多次元分 析ツールは、分析軸を自由(事前に用意されている５～６この軸)に選択できて、分析するツールです。

軸の例としては、支店(店舗、外販スタッフ、通販・・・)、商品(商品群、価格帯、色・・・)、顧客(性別、年齢層、居住地、年収、・ ・・)などです。 これらの軸から任意の２軸で、分析することが可能なツールです。

たとえば、赤い色の携帯電話を購入している人は、 どんな人(東京西部で女子高生でアルバイトでお小遣いを稼いでいる人)がメインユーザとかが一発で、いとも簡単に分析することが可能です。

軸を変更することは、いとも簡単なので、分析スタッフが思いつくままに、軸を変更して、どんな傾向があるのか、 瞬時に把握することが可能なツールなのです。 

ＯＬＡＰツール ～ ＩＴコンサルティング

ＢＩ(Business Intelligence)のツールは、基本的には、Ｍ－ＯＬＡＰとＲ－ＯＬＡＰの２種類に分類されます。 広義のＢＩツールは他の製品もありますが、二種類のＯＬＡＰツールに分類するのが一般的です。

まず、ＯＬＡＰというの は、On-Line Analytical Processingの略で、 オンラインで、ＩＴ担当者以外のスタッフが、複雑な分析データを入手できるツールのことです。

分析データがほしいスタッフ(マーケティングスタッフや商品開発スタッフ)が、これまでのように、 情報システム部門にデータ作成をリクエストするのではなく、自分自身でシステムに必要なデータをリクエストして、 データをつくれるように仕組みです。

情報システム部門に任せる方法は、時間がかかったり、さらに一歩踏み込んだ分析データが必要な場合に、 もう一度リクエストしなおさなければならなかったり、定型の分析しかできなかったり、というような制限がありました。 これをなくすのが、 ＯＬＡＰツールです。

オンラインという単語が含まれているように、ＯＬＡＰは短時間(５秒～１分以内)で、分析データを作成することが可能ですし、 使用するユーザがＩＴ担当者ではないので、データベースの専門知識がなくても、分析が可能になるようなツールでもあります。

ＢＩツール ～ ＩＴコンサルティング

ＢＩツールは、Business Intelligenceの略称です。

ＢＩツールの基本は、データベースやデータウェアハウスに蓄積されているデータを、ＩＴシステム要員に分析を任せるのではなく、 マー ケティング担当者や商品企画担当者、 あるいは役員などが自分で直接分析できるような機能を提供するツールです。

むかしは、分析したいデータがあったら、情報システム部門でデータ作成を依頼して、何週間も待たされているのが現実でしたが、 変化が早いこの日本では、そんな悠長なことをいっていられないので、 実際に分析する担当者が自分でオンラインで分析できるようにする必要性が高まってきて、でてきたツールです。

オンラインで分析できる、ということから、ＯＬＡＰ(On-line Analytical Processing)とも呼ぶことがあります。

考え方の基本は、ＩＴ担当者に分析を依頼しないで、データを必要している担当者本人が、システム関連の知識がなくても、 データを取り出すことができるシステム全般を指し示すこともあります。 広義には、ＳＱＬを使用しないで、 データ分析が可能なツールをすべて指し示すことになります。

有名どころは、Business ObjectsやHyperionがあげられます。

丁目ごとの分析 ～ ＩＴコンサルティング

住所コードが付番できるシステムであれば、丁目単位の分析も簡単です。

丁目単位の分析は、新聞折り込み広告などを出した場合、新聞販売店がだいたい丁目単位で販売しているので、 折り込み広告の有効範囲を知るための分析に有効です。

物販であれば 、それほど居住地に依存はしませんが、どこかの店舗に集まってもらって、 販売する形態の場合は、新聞折り込み広告での販売でも、どこまでが販売エリアとして有効なのか、を知る手段になります。

丁目単位の分析は、ＩＴというよりも、マーケティングの世界ですから、 マーケティング担当者がＩＴの知識がなくても分析できる仕組みが提供できるかが、重要です。

ＩＴ担当者が分析するのであれば、ＳＱＬを使えばよいのですが、マーケティング担当者の場合は、ＳＱＬやデータ格納の知識がないので、 ツールが必要になってきます。

これが、ＢＩツールというツール群です。 ＢＩは、Business Intelligenceの略です。 製品は、 ５～６種類でていて、それぞのの製品がＭ－Ｏｌａｐ(多次元分析)とＲ－Ｏｌａｐの２種類の製品をだしています。

次回は、このＢＩツールについてのお話です。

住所コードのお話の続き

住所コードは、１１桁のコードで、日本を北から付番しています。 北海道が'01'で、沖縄が'47'です。

東京の場合は、'13'になります。 東京の市区町村は、市区町村別の地図と同じように、「千代田区」「港区」と付番されています。 千代田区は'13101'、港区は'13102'という具合です。

さらに 、細かくみていくと、コードは覚えてしませんので、間違えているかもしれませんが、 住所コードの上８桁が町名です。 たとえば、東京都新宿区西新宿が'13115123'という具合です。 西新宿５丁目となると、 １１桁のフル桁で、 '13115123005'というコードになります。

プログラムを開発して、住所の文字列が住所コードになれば、あとは、住所コードの何桁目かで集計すれば、 自分の必要な集計データが計算できますので、非常に便利なコードです。

顧客データは、Oracleなどのデータベースか、なんらかのデータウェアハウスに保持していることが多いので、 ＳＱＬで集計しますが、

select substr ( addresscode, 1, 5 ), count (*) from kokyaku-data group by 1 order by 1 ;

などのＳＱＬで、市区町村ごとの集計値が一発でとることが可能になります。 レスポンスはそのサーバーの能力しだいですが、 通常の分析サーバーであれば、５秒とかからないはずです。

住所コード ～ ＩＴコンサルティング

住所コードというのは、国土地理院が設定している、日本全国を丁目単位でコード化しているものです。

実際の販売は、国土地理院は行っていませんので、住所コードを取り扱っている業者を探しましょう。 たとえば、アグレックスという会社が取り扱っています。

住所コードは、ＪＩＳ１１桁コードで、日本全国を丁目単位で、１１桁のコードを付っているものです。 便利なことに、１１桁のうち、上２桁は都道府県を表し、上５桁は市区町村を表しています。

住所の文字 列から、この住所コードに変換するには、プログラム開発が必要ですし、住所コード自身がけっこう高価なので、 登録されている顧客数が１０万件を超える業者の場合に有効です。

ここ何年か市区町村の合併・統廃合が続いていますので、住所コードもできれば、毎月更新をしたいところです。 国土地理院も毎月住所コードを改訂しています。 先のアグレックスも毎月住所コード表を更新するサービスをもっています。 ただ、 けっこう高額なので、予算とご相談になります。

お客さまが入力したり、電話申し込みでテレコミュニケーターが入力した住所の文字列から、住所コード１１桁が付番できれば、 後はコードでの分析になりますので、分析サーバーでの分析が非常に簡単になります。

市区町村別分析 ～ ＩＴコンサルティング

② 市区町村ごとの分析

   都道府県別の分析ができたら、次は市区町村ごとの分析です。 ネット通販といっても、 購買している人たちは結構首都圏の人たちがおおいはずです。 ですから、市区町村ごとの分布を調べることは非常に有効です。

 市区町村ごとの分析をする場合、住所の文字列で分析することは、かなりめんどくさいことです。 ソートする場合も、 文字コードの小さい順に並んでしまいますので、統計局や都道府県が発表しているデータと順序がそろわなくて、 手作業で並べなければならなくなってしまったり・・・。

 郵便番号の上３桁でソ ートするのは、ひとつの手です。 お客さまは住所の文字列だけではなく、 郵便番号も入れてきますから、それを利用するのです。

 もうひとつは、住所の文字列から住所コードに変換する方法です。

 もしも、顧客データが１０万件以上あるのでしたら、住所コードに変換することをおすすめします。

次回は、住所コードのお話です。

居住地での分析手法 ～ ＩＴコンサルティング

通信販売の場合、商品発送のため、顧客の住所が必ずわかるはずです。

データがあれば、居住地での分析が可能になります。

次はどこまでの分析をするか？ です。 分析したい内容で、都道府県がわかればいい場合、市区町村がわかればいい場合、 一丁目単位までが知りたい場合があります。 最終住所が、電子地図(ＧＳＰ)にマッピングしていく場合もあります。 それぞれによって、データの取り方がかわってきますので、 注意が必要でする

① 都道府県単位とい うのは、サマリーデータの場合が多いのです。
    まず一番最初は、細かい分析をすると、なにがなんだかわからなくなってしまうので、 まずは一番荒い都道府県単位で分析します。 総務庁統計局からだされているデータと比較して、どうして？ なんで？ というふうに考えていきます。

ネット販売であれば、都道府県別のインターネット人口とある程度比例するはずです。 そうなっていないのであれば、 なにか理由があるので、考えてきます。 都道府県別の年齢層データや職業別人数などのデータもありますので、それらと比較していったり、 の分析になります。

ちなみに、統計局のデータは、Excelデータですし、無料なので、ぜひとも活用していきたいデータです。

商品グループごとのＲＦＭ

いままでみてきたように、ＲＦＭ分析は有効な分析ツールなのですが、一工夫が必要です。

まずは商品グループごとの分析が必須ということです。 基幹系システムでは、販売している商品のマスターをもっているはずですが、 そのマスターでは商品グループができることもありますが、できないこともあります。

商品グループごとに分析する場合は、分析システムで、別個に商品グループマスターをつくって、グループ化するのが有効です。

たとえば、ビール・酒類というグループは、基幹系システムでもあるかもしれませんが、 ビールと発泡酒の違いというのはないかもしれません。 また、高めの発泡酒のグループ、安い発泡酒のグループというのは、 たぶん商品マスターにはないでしょう。

この場合、マスターを作るのはめんどくさいのですが、分析システムに有効なマスター類をつくっていく必要があります。

商品だけではなく、お客さまを分類するマスター類も必要です。 たとえば居住地です。

居住地の話は、次回詳しくみてみます。

第三の発泡酒のターゲット顧客

最近は沈静化しているようですが、第三の発泡酒のケースを考えてみます。

また先ほどと同様に、発泡酒の購買者で、ＲＦＭ分析をしてみました。 (5,5,5)の方が一番ヒットの可能性が高いのでしょうか？

発泡酒の中でも、価格に差があります。 ちょっと高めの発泡酒、安い発泡酒です。 単純にＲＦＭ分析をした場合は、 (5,5,5)でカテゴライズされるお客さまは、 きっと高めの発泡酒を買っている人の比率が高いはずです。同じ頻度で同量購買している 場合、高めの発泡酒を買っている人が、 Ｍ５の評価を得られるからです。

でも、注意がいるのは、第三の発泡酒を購入するのは、高めの発泡酒を購買している人よりも、 きっと安い発泡酒を買っている人のはずです。 値段勝負という第三発泡酒なのですから。

ということは、M５の人よりも、金額が少ないＭ３とかＭ２／Ｍ１とかの方が可能性が高そうです。 最新購買日や購買頻度は高い方がよいので、(5,5,1)とかの人が、第三発泡酒のターゲットになります。

必ずしもＲＦＭ分析をして(5,5,5)の方がターゲット顧客ではない、ということです。

ビールのターゲット顧客

さて、プレミアム・ビールのＤＭを出すのは、(5,5,5)の顧客がよいのでしょうか？

答えは「否」です。 単純なＲＦＭ分析は、あらゆる商品の購買データがまじっていますので、(5,5,5)のお客さまは、 毎晩お弁当とお茶のみを買っていくお客さまかもしれません。 お弁当はコンビニでも高額商品の部類(600円)だし、 本当に毎晩のように購入し ている人がいますので、(5,5,5)になる可能性かあります。

このお弁当顧客は、ビールを買うのでしょうか？ お弁当とお茶のみしか買わないお客さまであれば、ビールを買う可能性は少ないですね。 また、ビールといっても、エンドウ豆ビール(安い発泡酒)のみを買っているお客さまもプレミアムビールを買う可能性は低いといえまえ。

プレミアム・ビールのセールスをするのであれば、本当のビール(発泡酒ではなくて)を購入している人や、 えびすビールを購入している人の方が可能性は高いはずです。 もちろん、実験でセールスしてみないとわかりませんが。 でも、 少なくとも未成年者は、外すべきです。

ビール購買履歴がある方で、ＲＦＭ分析をしてみて、この中で(5,5,5)の顧客を抽出して、セールスしてみるのがよいでしょう。 それ以外の商品の購買金額は含めてはいけないということです。

ＲＦＭ分析の誤解

ＲＦＭ分析は有効な分析ツールですが、誤解をしている方が結構いるのも現実です。

三次元のまま考えますが、もっともＲＦＭが低い(大昔に買ったきり、１回のみ、購買金額も低い)という人を(1,1,1)で表します。 逆に、ＲＦＭがもっとも大きい方は、つい最近購入している、週に何回も購入している、購買金額も高い、 という人を(5,5,5)と表します。 各軸５段階評価です。

誤解している人がいるというのは、 優良顧客は(5,5,5)の人である＝セールスのターゲットになる人(5,5,5)と考えている人です。 確かにお店や企業にとって(5,5,5)の人は優良顧客であり、逃してはいけない人です。

でも、その人が 、次の商品を買ってもらえそうな、セールスのターゲット顧客になるかというと、別問題です。 ごっちゃにしている人がいますが、明確に分けて考えることが必要です。

では、例を考えてみます。 コンビニで、ビールのセールスを行う場合です。 最近プレミアム・ビールが増えてきているので、 コンビニでもプレミアム・ビールを販売しようと、買ってくれそうな会員にＤＭしようと考えたケースです。 コンビニでもファミマのように、 会員カードを発行しているところは、ＤＭも発行できます。

ＤＭ出せるといっても、買ってくれそうなターゲット顧客に絞り込む必要があります。 無作為では、 効率的なヒット率は望めないからです。

ＲＦＭの二次元化

ＲＦＭは、最新購買日・購買周期・購買金額という、３次元なのですが、Excelとかのツールでさらに分析をする必要があるので、 ＲＦ－ＭとかＲ－ＦＭとか、３軸のうち、２軸をひとつにまとめて２次元にする方法がよく行われています。

この二次元化ですが、あてづっぽうにするのではなく、その商品特性を考えて、最新購買日と購買周期は１軸にまとめられるとか、 商品単価がほとんど同じなので、購買周期と購買金額はリニア(直線の比例関係)な関係にあるのでまとめる、 とか論理的に行いま す。

購買周期が極端に短いもの(月に何回も買う場合)や、逆に購買周期が長いもの(２～５年に１回か２回)の場合は、Ｆを無視ししたり、 Ｒの範囲でＦも考慮するという方法をとることもあります。

いづれにしても、ＲＦＭの３軸から、どれかの軸を省いたり、まとめたりすることで、二次元化することが重要なのです。

もしも、会社でデータウェアハウスを使っているが、いまひとつ使用方法がわからない、と言う場合や、使い方のアドバイスをしてほしい、 というような場合は、ＩＴコンサルティング会社に依頼することをおすすめします。

当社(青山システムコンサルティング)でも、 このサービスをしていますので、お気軽にお問い合わせください。

ＲＦＭ分析の面倒な部分

ＲＦＭ分析は、非常に便利なツールなのですが、反面面倒な部分もあります。

Ｒ・Ｆ・Ｍと分析軸が３つあるので、三次元になってしまうことです。 たぶんみなさんは、Excelを使っていることと思いますが、 Excelは二次元(行と列)しか扱えません。 ＰＣで三次元のデータを扱えるツールはありませんし、三次元の表は紙でも表現しづらいのが、 難点なのです。

そこで、ＲＦＭ分析をする場合、ＲＦをまとめて、ＲＦ・Ｍの二軸で分析したり、Ｒは別の分析で固定化しておいたり、 Ｒ値は直近値だけを採 用して、ＦＭで分析表を作ったりします。 Ｍがあまり有効ではない業界では、ＲＦで分析したりすることもあります。 Ｍが有効ではない業界というのは、商品の価格がピンキリまである業界で、たとえば家電業界(あるいは家電の小売り)のように、 100円の電池から、数十万円の大画面テレビまでの商品ラインナップがある業界です。

Ｍ(Monetary)の分析が有効のは、高額商品から低価格商品まで、ある程度差の場合です。

もちろん、家電業界のように、商品によって価格帯が大きく違う場合でも、Ｍの分析はまったくできないわけではありません。 たとえば、 商品ジャンルごとにＭ値を分析するという方法があります。 1,000円未満の商品群での分析や、数万円代の商品での分析です。 他にも、 Ｍ値がそのジャンルの商品の平均価格との乖離度などで、高級品志向なのか、バーゲンセール目当てなのか、というような分析には、 使用可能です。

ＲＦＭ分析 ～ データウェアハウスを使用した分析手法

データウェアハウスを利用した分析手法に、ＲＦＭ分析という分析手法があります。

ＲはRecency、ＦはFrequency、ＭはMonetaryの略です。 Ｒは最新利用日、Ｆは利用頻度、 Ｍは購買金額ということです。

コンビニのお客さまを例に考えると、優良顧客というのは、いつも利用してくれていて、購買金額も高い顧客ということになります。 最近利用 がなくなってしまった顧客というのは、引っ越したり、趣向が変わったりして、 このコンビニに来なくなってしまったので、Ｒ値が古いお客さまは、利用頻度が高くでも、購買金額が高くても、 現時点では優良顧客ではなくなっていると考えられます。ＲＦＭ値がどれも高いお客さまが、優良顧客ということになります。

コンビニやラーメン屋さんのように、利用頻度が週に何回とか、毎月何回という頻度の場合は、 Ｆは週や月単位の頻度で考えればよいのですが、たとえば家具とか旅行とか車の購入などのように、何年かに１回というものは、 平均購買頻度の期間での購買回数と、読み替える必要がでてきます。

Ｒ値も同様に、利用頻度により、変える必要がでてきます。 このように、ＲＦＭ分析では、業種により、 ＲＦＭの定義をする必要があるのですが、そのあたりを書いてある書籍が非常に少ないのが、 実際の分析をする社員にとって辛いものになっています。 ちなみに、私自身、 この手の具体例が書かれている書籍をまだ読んだことがありません。 どの本も一般論(抽象的な)のみです。

経年変化の分析

データウェアハウスのもう一つの使い方は、経年変化の分析です。 過去のデータがすべてそろっているので、 長期間の分析が可能になります。

たとえば、顧客層の変化です。 むかしは若い顧客が多かったが、現在はシニアな顧客が増えている、とかの分析が可能になります。 この場合、たぶん固定客で、顧客自身が年をとってきたので、昔は若かったものの、現在はシニアになっていることが多いようです。 このケースでは、安定して経営ができているとしても、固定客はいつか死んでいくので、会社にとっては、非 常にまずい事態です。

あるいは、新規顧客とリピータの比率なども分析できます。 どの程度の新規顧客がいればいいかは、業界によりけりなので、 業界紙などで情報を入手する必要があります。 たいていの場合、新規顧客は２０～３０％、リピータが７０～８０％ぐらいだとよいようです。 新規顧客の獲得コストは、リピータの何倍にもなりますので、できればリピータが多い方がよいのですが、あまりにもリピータのみですと、 先ほどの例のように、固定客はいつか死んでしまうので、新規顧客が必要なのです。

分析できる期間は、今の日本の状況の変化が早いので、２～３年で充分かと思うかもしれませんが、実際に分析するには、 できる限り長い期間の分析ができる方がよいのです。 できれば２０年間はほしいところです。 ３０年以上の分析が可能であれば、 オイルショックやバブルの影響などが分析できて、よいのです。

有望顧客のターゲティング

有望顧客のターゲティングの方法の続きです。

有望顧客にピントをあわせて、ピンポイントでセールスするのは、たくさんのメリットがあります。

１つは前回お話にでましたとおり、コスト削減です。 メルマガ以外は、発行部数とコストはリニアな関係にあるので、 発行部数を削減で きれば、コストはダイレクトに削減できます。

もうひとつは、暴露面積の拡大です。 たとえば電話帳みたいなカタログから、自分のほしいものを見つけることは大変なことですね。 もしも、ほしいものが決まっているのであれば、索引から探すことも可能ですが、なにかいいものはないかな？という感じで、探すのであれば、 何十ページも見る気にはなりませんね。

その人が欲しそうなものが、わかっているのであれば、その人が欲しそうな物だけをセールスすれば、とっても見つけやすいはずです。 どこに埋もれているかわからないカタログにするのではなく、その人が欲しいものだけをピンポイントで表示できることを暴露面積が大きい、 と表現します。

後は、商品開発が楽になる←買う人のイメージがわくから、商品をつくりやすいとか、電話セールスでもピンポイントで話ができるので、 話が顧客に合わせやすいとか、がメリットになります。

データウェアハウスの２通りの使い方

データウェアハウスの使い方は、２パターン大きく分けてあります。

１つは、年ごとの経年変化をみて、パターンを知ることです。 もうひとつは、有望顧客をターゲットすることです。

この２つは、両方ともデータウェアハウスを使用することが多いのですが、分析方法が変わります。

まずは、有望顧 客のターゲティングです。 顧客をターゲットするのは、販売をあげるためと、 コスト削減するためです。メルマガの場合は発行コストは量によってもあまり変わりませんが、 紙媒体(ＤＭやカタログなど)を発行する場合は１部の制作費と配送費がかかってきます。 配送費は郵便よりも安い宅配便メール会社がでてきましたが、それでも媒体の重さにより４０～２００円かかりますから、 １万部の発行を削ることができたら、それだけコスト削減が可能なのです。

単純に発行部数を削減すれば、売上高も同じ比率で減ってしまうのですが、データウェアハウスを使って、 顧客の購買パターンを捕まえることができれば、買う見込みのない顧客への媒体送付を止めれることで、 発行部数を減らしても売上高を減らさずにすませることができます。

いかに、発行部数を減らしながら、売上高を維持できるかが、１つのポイントになります。

使いにくいデータウェアハウス

今回は、逆に使いづらいデータウェアハウスのお話です。

データウェアハ ウスは、過去のすべてのデータが残っているのが、その利点でもありますが、 逆にそれが欠点でもあります。 というのは、基幹系のデータベースのデータは正しいデータ、今現時点の顧客情報が入っています。 ところが、データウェアハウスでは、過去のデータがすべて残っているのですが、裏を返すと、 もう死んでいる顧客(実際に死んでいる場合と、もう商品を買うことのない死に筋の顧客)のデータもたくさん入っています。 その会社の顧客にもよりますが、一般に年間０．５％～１％ぐらいの世帯は引っ越しています。 ５年や１０年データを蓄積していけば、５～１０％のデータは、不確かな住所データになってしまうということです。

データウェアハウスを活用している企業は、ネット販売(ＢｔｏＣ)や通信販売、 多数の顧客をもつ小売業(特に会員カードを発行している会社)が多いのですが、お客さまは引っ越したからといって、 いままで使ってきた企業に連絡してくることは、めったにありません。

メルマガとかを使っている場合は、送信エラーになるし、引っ越した場合はしばらくは郵便が転送されますが、期間がたてば転送も止まり、 宛先不明で返送されてくるようになってはじめてわかります。

データウェアハウスに格納されているデータが１００％の信頼性がないのです。

便利なデータウェアハウス

基幹系システムのデータベースとは異なるデータウェアハウスがあると、いくつか便利な点があります。

分析用のデータウェアハウスがあると、非常に重たいＳＱＬをばんばん分析システムに投げることができます。 基幹系のデータベースしかない場合は、オンライン処理に負荷がかからないように、気をつけながら、ＳＱＬを発行する必要があるのですが、 独立したデータウェアハウスがあると、そんな心配はありません。

第二には、複数の ＳＱＬを同時に発行しても、デッドロックしたり、 レスポンスがそんなに悪化しないことです。特に大人数でシステムを使用している場合、 たまにデッドロックしてしまうことがあるのですが、データウェアハウスでの分析では、そんなことにはあまりなりません。 その大きな理由は、リードオンリーで、共通データにはライトしないからです。基幹系のデータベースであれば、 オンラインでデータの更新(ライト)をしているので、分析のＳＱＬしだいでは、デッドロックしてしまうことがあるのですが、 独立したデータウェアハウスでは、心配は不要です。

第三には、その他の分析システムと相性がよいことです。 ＢＩツールとよばれている多次元分析システムなどや、 統計分析システムなどとの相性がよく、ＯＤＢＣとかが準備されていることです。

最後は、過去のデータをすべてもっているので、基幹系システムが更新されたとしても、 データウェアハウスにはデータが残るということです。 汎用機からオープンシステム(UnixやWindows Serverなどに)に基幹系システムがかわっても、データウェアハウスのデータは一元的に保持されるように設計するからです。

データウェアハウスのお話

データウェアハウス(ＤＷＨ)は、リレーショナルデータベース(ＲＤＢ)の一種です。 ＲＤＢといえば、 OracleやSQLサーバー、あるいはMySQLなどを思い浮かべるかもしれません。 ＳＱＬという言語で、データを検索する、 表型のデータベースということでは、ＤＨＷも一緒です。

違うのは、ＤＨＷは大量のデータを取り扱えること(Oracleの１０倍、SQLserverの１００倍)と、 検索能力が高いということです。 同じ 程度のＣＰＵであれば、ＤＷＨは、通常のＲＤＢよりも高速にデータを検索できます。 では一般的なＲＤＢの代わりにＤＷＨを使えばいいじゃないか？と思うかもしれませんが、普及していない理由がいくつかあります。

高価であること。 ＤＷＨのシステム構築をできるソフトウェア開発技術者が少ないこと(OracleやSQLserverに比べると格段に少ないです)、 オンラインの更新(ＯＬＴＰ)にはあまり向かないことです。 だから、通常の基幹システムのように、在庫を引き落としたり、 顧客データを登録／更新したり、預金の残高を引き落とすといった業務には使えないためです。

基幹系のＲＤＢから夜間にその日のトランザクションをバッチジョブで、データをもらい、夜間にＤＷＨに登録すると、翌日はＤＷＨでは、 高速で分析することが可能です。 また、ＤＷＨでさらに使いやすくデータを加工すれば、データマートや多次元データベースなどで、 詳細の分析を簡単に処理することもできるようになります。

基幹系システム→ＤＷＨとデータを夜間に流すのが、基本的な使用方法になります。

データベース・マーケティング

データベース・マーケティング(ＤＢＭ)は、データベースを使ったマーケティングの総称です。 基本は、 前述のデータマイニングに近いものですが、ＣＲＭ(Customer Relationship Management)やＳＦＡ(Sales Force Assistant)なども含んできています。

顧客データを利用 して、よりよいマーケティングを目指すというものの総称と考えてください。

ＤＢＭには、データウェアハウス(ＤＷＨ)を使います。 リレーショナルデータベース(ＲＤＢ)のカテゴリに含まれますが、 データの倉庫としての機能を提供します。 通常のＲＤＢ(Oracleなど)と異なるのは、オンラインの更新処理は苦手ですが、反面、 膨大な量のデータの検索は得意というシステムです。 ＤＷＨについては、明日、詳細をアップしますので、ここでは、そんなシステムがある、 とだけ覚えておいてください。

さて、ＤＢＭですが、キャンペーンのヒット率を上げるとか、顧客の離反率を下げる、 商品の入れ替えをＰＯＳデータや勘や経験や度胸(ＫＫＤ)だけではなく、もっと立体的に検討するというものでもあります。

このコンサルタントに要求される能力は、ＤＢＭの構成・データの持ち方などを熟知していることと、 クライアントの商品ラインナップやクライアントの商売の方法に精通していることがあげられます。

ＤＢＭを提供している会社は多々ありますが、ハコだけを提供している会社が多いので、 クライアントと一緒に問題解決をはかれるコンサルタントが必要不可欠なのです。 

テキスト・マイニング

次はテキスト・マイニングです。 ここ２～３年の間に成長してきている分野です。

テキスト・マイニングは、データ・マイニングが顧客情報や過去の購買データという、主に数値情報を取り扱い、 次のキャンペーンに役立てる仕事に対して、顧客のアンケートや電話やメールとやりとりという、 話し言葉や文章というテキストからマイニングして、商品開発や保守・サポートに役立てようというものです。

同じマイニングなのですが、データマイニングとテキストマイニングでは、その用途が違います。

テキストマイニングの難しいことは、言葉や文章が対象ということです。まずは同じものを指すのにいろいろな単語や動詞を使うことです。 例示しますと、「スーツ」「ブレザー」「背広」「ジャケット」「スリーピース」「ビジネスウェア」などは、同じ商品を指し ています。 このような、同じ意味の単語は同じグループとしてくくる必要があり、それはクライアントの商品ラインナップによって、変わってくるので、 それぞれのクライアントごとに適切なグルーピングする辞書が必要になってくるということです。

もう一つは、肯定文と否定文があり、長い文章では、それを判読するのがむずかしいということです。 「おいしかったけど、 ちょっと高かった」という文章は肯定文なのか、否定文なのか、どう判断するかが、コンピュータではむずかしいということです。

この大変さがコンサルタントを必要とする要因になっています。

データマイニングのコンサルタント

だんだんマイナーな部類に入ってきました。

データマイニングのコンサルタントです。 データマイニングというのは、Ｅコマースや通信販売で、 ＢｔｏＣを商売としている会社が対象です。 顧客の個人情報や購買情報から、未来の購買確率をマイニングする仕事です。

マイニングというのは、「掘る」という意味ですが、金脈を探り当てる、という感じの仕事です。 顧客データや過去の購買 データから、その顧客の購買パターンや趣味・嗜好を探り当て、効率的に広告宣伝して、 ヒット率を高め、広告コストを減らそうというものです。

なぜコンサルタントが必要かというと、一般的なソフト開発会社ではクライアントの業務に深く関与しないので、 業務にべったりのマイニングができない。 逆にクライアントのマーケティング部門では、自社の業務や商品展開はわかるが、 システムの使用方法がよくわからないというギャップが存在するためです。

この溝をコンサルタントが埋めます。 マイニングツールはいろいろと販売されていて、販社のエンジニアもいるのですが、 やはりクライアントの業務自体にには興味があまりなく、ツールを使うことに専念してしまう傾向がありますので。

クライアントの業務や商品、社内の人間関係などを熟知した上で、さらにシステム(データの持ち方)を知り抜いて、 マイニングする力が要求されます。

システム・アドバイザリー

今使っているシステムを小改修してこれからも使っていくのか、それとも、この際新しいシステムに切り替えるのが得策なのか、 などをアドバイスするコンサルタントです。

やはり、クライアントの現状を調査・把握して、さらにこれから２～３年後のビジネスを推測して、 そのとき(将来)に適切であるシステムが稼働していることを見通す力がいるので、これもしんどい仕事です。

ここ数年間の日本は、ビジネス体系がはげしく変わってきているので、 今後２～３年の間にクライアントのビジネスがどう変わっているべきか、を判断するのは、一種の戦略コンサルタントともいえます。

さらに、そのときに陳腐化していないシステム技術を導入しつつ、 新しすぎる技術をふんだんに使うというリスクもバランスしなくてはなりません。 新しい技術は、それだけでも楽しいものですが、 本当に問題なく、すんなり使えるのか？という疑問がありますし、２～３年後にも保守サービスを受けられているのか、 という疑問があるからです。

小さな独立のベンチャー企業の新技術というのは、２～３年後には大化けして、業界標準になっていることもありますし、逆に倒産して、 サポートもされないという事態になっているかもしれません。

このことは、みなさんが使っているシェアウェアやフリーソフトでも同じことで、ある日突然サポートがなくなったりして、 大あわてになることもありますから。

ＩＴベンダー評価

三番目として、ＩＴベンダー評価があります。

クライアントが今使っているベンダーの費用が適切なのか、あるいは業務委託内容が適切なのか？ というベンダーの評価であったり、 これからシステム開発する場合、相見積りをとっているが、単に安い開発費でベンダーを選定してよいのか？ などのコンサルティングをする人たちです。

コンサルティング内容によっては、ソフト開発会社にクライアントが必要としている機能を適切にアドバイスして、 開発コストを削減したりすることもあります。

あるいは、パッケージソフトの評価をしたりもします。 クライアントが本当に必須な機能を備えているのか？ 価格での評価などです。 たとえば、市販の会計ソフトを導入する場合、勘定奉行がよいのか、弥生会計がよいのか、それとも・・・、というように、 数種類のパッケージソフトを機能や価格で評価するものです。 クライアントの規模や必要としている機能が異なるので、 クライアントの業務を調査して、ＴｏＢｅモデルを構築してから、最適なパッケージを評価・選定するので、けっこう大変な仕事です。

単純に、パッケージの機能と価格をExcelの表にまとめているだけではありませんので。

パッケージのコンサルタント

③ ＥＲＰなどのパッケージのプログラミングをする人たちも、コンサルタントと名乗っていることが多くなりました。 単なるプログラマー(通常はＥＲＰパッケージのパラメーターをきっているだけ)なのに、名刺には「ＥＲＰコンサルタント」と書いてあります。

ＥＲＰパッケージだけではなく、パッケージの開発をしている人たちは、コンサルタントと呼べないと、考えています。

理由は、コンサルティングの定義は、クライアントの抱えている問題を発見して、それを解決することだから、担いでい るパッケージで、 クライアントの問題解決ができるとは限らないからです。 解決策(パッケージ)ありきでは、クライアントからヒアリングして、 ベストな解決策をとれるはずはないからです。 この人たちがコンサルタントを名乗っているのは、 プログラマーやＳＥの人月単価が下がってきているので、それを食い止めるために、単に偉そうなコンサルタントを名乗っているように感じます。

ちなみに、人月単価ですが、クライアントに請求するベースでは、プログラマーであれば月額５０～１２０万円、 ＳＥであれば月額８０～１５０万円、コンサルタントであれば１５０～４００万円とひらきがあります。 同じ職でも、単価が異なるのは、 会社の規模や当人のスキルに依存するからです。 会社の規模や有名な開発業者(アクセンチュアや野村総研など)はそれなりに高い月額になっています。 弱小のソフト開発業者や個人事業主であれば、格安になってきます。

高額だから、安心して頼めるという簡単な図式ではありませんので、注意が必要です。

プロジェクト・マネージメントのお仕事

② プロマネをすることもあります。 ソフトウェア開発会社だけでは、プロジェクト全体の管理ができないことがありますので、 そのマネージメントをするコンサルタントです。

クライアントとソフトウェア開発会社の間に入って、要求定義をしたり、ソフト開発のスケジュール管理、要員管理などをする仕事です。

プロジェクト・マネージメントは、ＰＭＰ(Project Management Professional)の資格や、情報処理技術者の資格があるとおり、ＩＴ業界ではあたりまえの仕事です。 ただし、 資格をもっていなくてもプロマネの仕事はできますし、逆に資格をもっていたからといって、 その人ならプロマネがしっかりこなせるかは別問題です。 単なる認定資格と考えましょう。 でも、公認資格ですから、 もっているにこしたことはありませんので、もしプロマネの業務をしているのでしたら、是非試験を受けましょう。 情報処理技術者試験は実務経験がなくても、試験を受けることができますが、ＰＭＰの方は、実務経験がないと、受けられませんので、 注意が必要です。

ＩＴシステム開発の場合、システム開発がうまく当初予定していたとおり、実施できる可能性はけっこう低いものです。 約１／ ２のプロジェクトは、なんらかの問題が発生しています。 スケジュールが遅延する、クライアントの要求通りの仕様になっていない、 プロジェクトのコスト(たいていの場合はソフト会社が負担)が大幅に超過してしまった、などなどです。

ということで、良いプロジェクト・マネージャはひっぱりだこです。

ＩＴコンサルタントという仕事

ＩＴコンサルタントというのは、ＩＴ関連のコンサルを職業としている人たちです。

コンサルについては、いままでブログで書きてきましたとおり、クライアントの相談にのって、的確な解決方法をアドバイスし、 改善プランを実行・サポートする仕事です。

ＩＴコンサルは、ＩＴ業界でのコンサルで、中を細かくみていくと、だいたい次のような仕事があるよう に思えます。わたしが知らない世界があるかもしませんので。

① 業務系アプリケーション・コンサルタント

    主にクライアントの業務系のシステムを導入する際に、お手伝いするコンサルタントです。 ソフト開発会社だけでは、業務改善の提案が不足しているのがふつうなので、クライアントと開発会社の間にはいって、 クライアントが抱えている問題点や要望をわかりやすく開発会社のＳＥに伝えて、間違えなく、そして、適切な価格、 適切な開発期間でカットオーバーさせるのが仕事です。 たぶん、この仕事をしているＩＴコンサルタントが一番人数的には多いはずです。

 ソフト開発会社に雇われる場合もありますし、開発会社選定の段階でクライアントから雇われる場合もあります。

クライアントから、システム開発の委託を受けて、コンサル会社がソフト開発会社を雇って、システム開発する場合もありますので、 形態はいろいろとあります。

継続的なコンサルティング

最終の総仕上げが無事終了したらといって、このクライアントと縁が切れるわけではありません。

この後、フォロー・コンサルティングといって、月に１回程度取締役や社長と解決策がうまく稼働しているか、話をしていきます。 まぁ、 しばらくはお茶友達という感じですが…。 ただし、このフォロー・コンサルティングでも、適切なコンサルティング費用をいただいています。 しばらくはお茶友達なのですが、情報の収集はちゃんとしているからです。 なにか小さいトラブルとかがあったら、その兆候を見つけて、 改善指導するからです。 的確に、そして、すばやく改善ができるかは、次回のコンサルティング案件がもらえるかの、分かれ目なので、 しっかりと情報収集に努めます。

どんなにしっかりした解決策であっても、２～３年すると、またうまくいかない部分がでてきます。

当然、日本の環境が変わってきているので、それに合わせて、ときどきは、ビジネスモデルの変更が必要だからです。 もちろん、 業界にもよりますけど。 携帯電話の業界やソフト開発、Ｗｅｂ開発の世界は動きが速いので、半年に１回ぐらいは、 ビジネスモデルの修正やおおはばな変更が必要です。 製造業ですと、今の日本では、 そんなに頻繁にビジネスモデルを変更する必要はありません。 逆にあまり頻繁にビジネスモデルを変えていくと、 社員がついてこられなくなってしまいます。

これで、１回分のコンサルティングの流れの説明は終了です。 次回からは、ＩＴコンサルティングについて、 アップしていきたいと思います。