日本においても、B to Bデータベース・マーケティングを志向する企業が増加している。しかし、その基盤となるデータベース構築に成功している企業は必ずしも多くはない。

そこで今回は、データベース構築に当たっての留意点を考えてみたい。

情報システム部門には売るための仕組みは作れない

「データベース・マーケティング」「ダイレクトマーケティング」「CRM」「SFA」「PRM」「IMC」「One to One マーケティング」・・・。データベースを使ったマーケティングの呼び方は実にさまざまだが、これらのソリューションを導入したり、顧客や見込客のデータを格納するデータベースを構築しても、期待通りには運用できていない事例が多い。

これは導入する企業側にデータベース・マーケティングに対する正しい理解が不足したまま導入してしまったことが原因で、パッケージやシステム会社の責任ではない場合が多い。特にデータベースの開発やカスタマイズの設計段階で失敗し、それが原因で運用できなくなってしまうケースが圧倒的に多いのである。

マーケティング用のシステムであれば、実際に使うのはマーケティング・チームや営業の後方チーム（営業支援・販売推進）である。それなのに導入段階でパッケージソフトの選定や要件定義などに参加するのは、ほとんどの場合、情報システム部門だけである。しかし、売ったことのない人たちに「売る人たち」を支援するシステムが作れると考えていることが間違いだと思う。

導入の初期段階で営業サイドの人間が参加しない主な理由は、情報システム、つまりコンピュータに関する専門知識がないことだ。しかし、本当にそれが必要なのだろうか・・・。答えは「NO」である。もっと言えば、営業やマーケティングの現場がわかっていない人たちが主導権を握っていることのほうが、はるかに失敗の確率が高いミスキャストなのだ。

データベースは“脇役”

このことを「マーケティング」という言葉の定義から考えてみよう。
よく使われるわりに意味のわからない言葉の代表格が、この「マーケティング」である。そのため、私の会社では「マーケティング」を「売るための戦略的な仕組みを作ること」と定義している。使うメディアによってマーケティングを「マスマーケティング」と「ダイレクトマーケティング」に分けることができる。

マスマーケティングは言うまでもなくテレビや新聞、雑誌などの不特定多数をターゲットにしたマスメディアを使う手法で、コンシューマー（一般消費者）を狙ったマーケティングでは絶大な効果があり、法人営業でもブランディングには効果的に使うことができる。

法人や官庁しか購入しない製品を扱っている会社、例えばシスコシステムズや、日本ヒューレット・パッカードがマスメディアを良く使うのはこの理由からである。

一方、ダイレクトメールや電話、FAX、eメールなどのダイレクトメディアを使い、特定少数のターゲットを狙う手法がダイレクトマーケティングである。届けたい情報と、それを伝えたいターゲットのリストがあれば、eメールやDM、電話などでピンポイントのアプローチができる。

また、特定のターゲットのニーズに合わせて具体的でエッジの鋭い「ドキッ」とするようなメッセージを送り、潜在的なニーズを揺り動かすこともできる。不特定多数の人たちにマスメディアを使ってアプローチする手法に対し、このようにある特定のターゲットだけにピンポイントでダイレクトにアプローチする手法が「ダイレクトマーケティング」なのだ。

その中で、顧客や見込客のデータをデジタル化してデータベースに格納し、データをメンテナンスして肉付けをしながらコミュニケーションを繰り返す手法が「データベース・マーケティング」である。このマーケティングにおいてデータベースは非常に重要ではあるが、あくまで「脇役」でしかない。主役は言うまでもなく、その中に格納される「データ」であり、そのデータに対するアプローチのプランである。

データベースが主役なら情報システム部門が主導してもいいが、主役が顧客や見込客の「データ」だとすれば、主導権はその情報に最も詳しい人たち、つまりマーケティングや営業部門の人でなければならないはずである。

データベースはアウトプットから考える

難しく考える必要はないのだ。毎日のように車を運転する人が、車やエンジンのメカニズムに詳しい必要があるだろうか？　eメールで友人や家族とやりとりする人が、コンピュータ・テクノロジーやネットワーク、通信プロトコルなどの知識を持つ必要があるだろうか？

単純に理解すればデータベースは「箱」である。データを貯める箱なのだ。機能は「入れる」「貯める」「出す」だけである。極論すれば「インプット」と「アウトプット」しかない。情報システムに詳しい人が主導権を握ると「インプット」から考える。実はこれが違いの元なのだ。

社内のどこにどんなデータがどういう状態で存在する、それらはそれぞれどういうタイミングで更新・上書きされて、誰が（どの部門が）管理している・・・。システムに詳しければ詳しいほど、そこをつなげることを徹底的に考える。その作業があまりにも大変なので、「アウトプットはデータベースが完成してから後で考えればいいや」となってしまう。

しかし、そうして作られたデータベースが実際に営業の役に立つことはほとんどない。
では何が正解なのか・・・。「アウトプットから設計」すればいいのだ。何に使う、どんな検索をする、どんなレポートをどんなタイミングでしたい、それをどんなインターフェースで見たい・・・。これだけを徹底的に考えて設計すれば、活用される可能性は飛躍的に高まる。マーケティング部門のユーザーの視点でデータのアウトプットの流れを見て設計するのだ。

データベースを「活用」するということは「アウトプットする」ことなのだ。eメールを配信する、ラベルを出力してDMを出す、特定の検索条件に絞り込みテレマーケティングでアプローチする・・・。

こうしたアウトプットだけが活用と呼べるもので、インプットで止まっているとしたら、残念ながら活用していることにはならない。鮮魚並みに腐りやすいと言われている顧客や見込客のデータを、ただ安全な箱に貯めるためだけに数千万円を使うことのバカバカしさを考えてみて欲しい。
さて、では実際にインプットからデータベースを設計して、運用がままならなくなってしまった症例を見てみよう。

医療機器のメーカーであるK社は、全国に50人の直販営業のスタッフと、20社の代理店を持っている。この営業スタッフが過去に集めた名刺と、年に数回出展する展示会で集めた名刺リスト、セミナーや商品説明会の参加者リストなどを合わせて約3万件の見込客データを持っていた。これをデータベース化するプロジェクトが3年前にスタートし、数千万円をかけてシステム会社に発注し、1年がかりでデータベース・システムを開発・構築した。

このプロジェクトは社内の情報システム部が主導し、マーケティングや営業チームは数度のヒアリングを受けたのみで、ほとんどかかわらないまま進められた。そのヒアリングもあらかじめ設問が決まっていて、「データベースがあれば何がしたいですか？」といった曖昧なものだった。

しかし、曖昧な設問には曖昧にしか答えられない。具体的な答えが欲しかったら具体的に聞くしかないのだが、情報システム部門に営業の経験者がいなければ、それはかなり難しいだろう。
K社は、こうしたヒアリングから出てきた曖昧なニーズをデータベースの設計に取り込んでしまったのだ。

「役職で検索して部長クラスだけをセミナーに呼びたい」「部署で検索して興味を持ってくれそうな部署にだけアプローチしたい」「商談を重ねてから取り引きできない会社だとわかると辛いので、与信情報を入れて欲しい」「過去の取引情報や納品した製品の状況を紐付けて見たい」「自社の複数の部署がアプローチしているケースが多いので、自社の誰が何を売り込んでいるのかリアルタイムにわかるようにしたい」・・・。

こうしたよくあるニーズをユーザーサイドの要件として精査もせずに取り入れ、開発・構築されたデータベースは、残念ながらほとんど活用されないまま2年が過ぎようとしている。加えてそれが原因で、社内の情報システム部門とマーケティング・営業部門はすっかり不仲になってしまった。情報システム部門は、せっかくヒアリングして要望を最大限取り入れてやったのになんで使わないんだ…と怒っているし、営業サイドはデータの不正確さに呆れてとても使えないとさじを投げている。
なぜ情報は「不正確」なのか。

4年前の展示会に来場してくれた時には課長だった人が、今では事業部長になっているのに、データベース上では課長のままである。退社した人もそのままデータベースに残っている。社名変更、部署名変更もなされていない。与信に至ってはさらに悲惨だ。信用調査会社の2年前の企業評価点を各企業マスターに記入しているが、2年前の評価は当然のことながらその前の年の決算情報をベースにしているので、この与信情報は単に「この会社は3年前には元気だった」ことを示しているに過ぎない。

このような正確性を欠く情報の塊は、現場の営業チームにはストレスになってしまう。そのため次第に誰もこのデータベースを使わなくなり、使われないがためにますます情報が陳腐化し、不正確の塊になるという負のスパイラルに陥っていった。

データベースは最後に上書きした時点で時が止まる。例えば入力した時点でその人が課長であれば、その後、新しいデータが上書きされない限り、その人が部長になろうが常務になろうがデータベースの中では課長のままである。最後に名刺交換をした時の役職が「最新」なのだ。その後、メールマガジンを定期購読してくれようと、Webを頻繁に見てくれようと、その人の役職が変わったことを誰かが入力しない限り、データ上は課長のままである。

与信も然りだ。入力した時点で評価点がいくら高くても、2年後に業績が急激に悪化して倒産することは決して珍しくない。必ず変化するに違いない情報と、比較的変化しにくい情報を分けなければ、情報は最も速く変化する項目に引きずられて腐っていく。これがインプットからの発想なのだ。

今は確かに名刺データを持っている。その名刺には「課長」という役職情報が入っている。しかし、その役職情報を入力後、誰がどうやってメンテナンスしていくのか、という基本的なことについて、誰も真剣に考えていない。

これが取り引きのある顧客であればまだいい。担当営業が付いているだろうし、定期訪問もするはずだ。
そもそも担当営業が顧客担当者の最新の役職を知らないことは、別の意味であってはいけないことだろう。しかし、まだ取り引きのない見込客の場合はどうだろう。定期訪問もしないし、担当がはっきり決まっているわけでもない。与信管理もしていないし、購買履歴もない…。セミナーや展示会に1度か2度来てくれただけの人であれば、その後のコンタクトはないのだ。

データを2万件持っていれば、顧客が500件で残りの1万9,500件は見込客というケースが多いはずだ…。
97.5％のデータのメンテナンス方法が決まっていないのだから、この「役職」という項目のデータは活用できるわけがない。

余談だが、日本企業の役職の多さを考えたことがあるだろうか？　係長、課長、部長だけならいいのだが、主査や主務、参与や参事などのわけのわからない役職があり、「次長・部長代理・副部長・部長補佐」などに及んでは上下関係がさっぱりわからない。

これは高度経済成長という戦後の特殊な経済事情が生み出した、終身雇用という本質的に「いびつ」な人事制度の弊害だが、これのお陰で日本では「役職」というデータを機能的に管理することが非常に難しくなっているのだ。

このままではせっかく1年と数千万円をかけたマーケティング・データベースが死んでしまう。早急にデータの運用・管理の考え方にメスを入れ、運用ルールを変えなくてはならない。導入してからの2年間に起きた事実――誰が、いつ、どんな検索をしたか、しなかったか、どんなデータがインプットされ、どのような形でアウトプットされたかを注意深く見ていけば、業務フローの改善に必要な情報を手に入れることができるだろう。

アウトプットから発想し、設計する。その情報が必要になるタイミングやシーンを考えて、必要かそうでないかを精査する。与信ならば、必要になるのは通常、最終見積りを提出する段階か契約の時だろう。しかもその段階で与信の評価点数が基準以下であったとしても、多くの場合は支払い条件を変えるなどの調整で取り引きは継続する。ならば、まだ案件にもなっていない数千件、数万件の見込客の企業マスターに与信情報を入れること自体がナンセンスだと言えるだろう。

いつ、どのタイミングでどんなアウトプットが必要なのか…。ここから発想するとデータベースの構造はずいぶんシンプルにできる。検索条件に使わない情報は極力入れないことも重要である。企業マスターに資本金を入れるケースをよく見かける。しかし、「資本金」を検索条件にして検索をかけたことがあるかと言えば、一度もない、という企業が多いのだ。

企業を規模で分けて管理したい場合に良く使うのが「資本金」「売り上げ」「社員数」などだが、どれも情報を入手するのが困難な上に、常に最新の正しい情報に保つのはさらに難しいのだ。
メンテナンスできない情報は入力しないか、したとしても非表示の設定にし、間違ってもメールやラベルに印字して送らないようにすることだ。入力するのならば、その情報は参考程度に使うような社内コンセンサスをとっておくべきだろう。

マーケティング用のデータベースであるならば、その情報がなければマーケティングができないという情報に限定して入力すべきだ。しかし、一方で、すべての営業やマーケティングのスタッフが自由にアクセスできたほうがいいという考え方は正解とは言えない。

社内の多くの人に名刺入力などのルールを守らせることは不可能に近いし、上書き権限を持たない人に、肩書きや所属部署の不正確なデータを見せればストレスやクレームになるに決まっているのだ。
データベースの管理業務を再設計するならば、いつの段階で誰がアクセスするのかを限定したほうが、はるかにやりやすい。社内ユーザーが欲しいのは、アウトプットされたレポートや、重複や配信停止依頼や不達をきれいにメンテナンスしたeメールアドレス・リストなどである。

だから、アウトプットからの設計なのだ。データの構造を変えるのは次データベースを開発するまで待つとしても、管理の業務フローだけでもすぐに設計し直さないと、このK社のデータベースは完全に死んでしまうだろう。