[ザ・プロジェクト]

2012年12月19日(水)川上 潤司（IT Leaders編集部）

顧客情報が社内に散在、マスターの不整合が業務を阻害

─ERPとWMSを導入し、製造と物流というビジネスのバックエンドを支える基盤を整えた？

前田：そういうことです。それが一段落したので、次のステージに移ることにしました。顧客情報管理のあり方の改革です。2009年10月に検討を開始しました。

─それまでの顧客情報管理に、何らかの課題があったんですか。

渡辺：ええ。顧客管理がチャネルごとにバラバラだったんですよ。具体的に言うと、当社の販売チャネルは電話（インバウンドのコールセンター）、ハガキ、実店舗、ネットショップと、大きく4系統あります。従来は、購買履歴や美容・健康に関する問い合わせ履歴といった顧客情報をチャネルごとに、個別に収集・管理していたんです。

─チャネルごとにシステムを構築・運用していたとしても、受注内容は最終的に販売・在庫管理や請求処理といった共通システムに引き渡されるんですよね。

前田：それはもちろんそうですが、誰がいつ、何と何を買ったかといった明細情報は、チャネル別の受注システムで管理していました。

─それで、どんな問題が発生していたんですか？

渡辺：販売チャネルをまたいだデータ分析が難しいという問題です。各システムが持つマスター項目はまちまちで、あっちのシステムにはあるデータがこっちのシステムにはない、といったことがよくあった。例えば店舗におけるマーケティング施策が、オンライン販売にどんな影響を与えているかを分析しようにもできませんでした。

前田：このほか、パーソナル・カウンセリングを実現するニーズに対応できないという問題もありました。どのチャネルで購入したとしても、あるいはコールセンターに相談したとしても、当社としてはそのお客様の情報を把握した上で、最適な商品を提案したい。でも、それが難しかったわけです。

統合マスターDBを構築し、データ構造を柔軟に

─チャネルを作った時期も、当然、システムを作った時期も違うので、生じやすい問題ですね。それをどう解消したのか、プロジェクトの詳細をお聞かせください。

前田：ステップ1として、マスター統合に着手しました。プロジェクトをキックオフしたのは、2010年6月です。

渡辺：まず計画フェーズとして、現状のマスターにどういう課題があるのかを、社内ユーザーの声を聞きながらあぶり出す作業を実施しました。

─どんな課題が浮かび上がりましたか。

渡辺：データモデルや構造に関する課題です。マスターの持ち方が硬直化していたんですよ。

─というと？

渡辺：例えば、各システムが持つ商品マスターです。商品の売上単価や在庫単価のほか、種別を大分類、中分類、小分類といった項目で管理しています。「サプリメント→ビューティーサプリ→コラーゲン」といった具合です。しかしこの分類は、何がどれだけ売れたかという実績をとるためだけのものでしかない。でも、どの顧客セグメントに何を提案するかの仮説を立案するマーケティング担当者は、もっと別の分類でデータを見たいんです。「ヒアルロン酸は30歳以上の女性向け」とか。

─いろいろな切り口で商品や販売動向を見たいというニーズがあった。

渡辺：ええ。ところがシステムの仕様上、マスター項目を追加登録するにはプログラムを新規開発するしかありませんでした。

前田：顧客マスターも同様です。新たな顧客属性を収集しようとしても、マスター項目の追加に費用や時間がかかってしまう。これでは仮説を検証するためのテストマーケティングを素早く実施できません。

─マスターデータの設計は難しい問題ですよね。どう解いたんですか。

渡辺：議論を重ねた結果、全チャネルの商品・顧客マスターを集約し、重複を排除して整理したデータベースを別途構築。そこからマスター情報を情報系に渡す、という方法を採用しました。

─“マスターオブマスター”のイメージですね。全システムのマスターゼロから設計し直して、一本化する方向は？

渡辺：それだと大規模すぎます。下手をすると業務が止まるリスクもあり、それはできませんでした。