業務部門がやりたいことの本質を情シスが明確化する
通常、業務部門側が描く構想は、アプリケーションやデータ連携レベルの話まで明確に踏み込んだものではない。
当然、業務部門はその構想段階において、社内システムのアーキテクチャやデータアーキテクチャの理解はいったん脇に置き、「やるべきこと」や「やりたいこと」または「あるべき姿」から構想を始める。食べられようが食べられまいが構わず、いったん、“餅の絵”を書く。
例えば、昨今注目されている「マーケティングオートメーション」はその代表例だ。国内市場にもすでに2ケタ数のパッケージアプリケーションベンダーが存在する。導入したらうまくいくかもしれない、やってみたいと思う業務部門に対し、彼らベンダーは「効果を出すにはCRMシステムとの連携が前提です」という。
そして、「顧客マスタやトランザクションデータなどとの連携を前提にアプリケーションを導入しましょう」ということになる。
ベンダーがどのように説明しようが、それにもとづいて業務部門がどんな餅の絵を描いていようが、この場合、彼らがやりたいことの本質は何なのかというと、連載第1回から述べている通り、以下の3点である。
- 顧客識別
- 顧客理解
- 顧客とのコミュニケーション
アプリケーションは最終的に独自開発やパッケージ製品の導入、という選択肢があっても、活用するデータについては、外部から購入することはできない(サードパーティのデータセラーを除く)。
よって、業務部門は情シスと調整することになるわけだが、業務部門からの相談が舞い込んだ時、上記の3つの本質を情シスが理解できていれば、彼らが業務部門に対してしなければならない重要な質問は以下の通りとなる。
- 顧客識別のために、どんなデータを収集したいのか
- 顧客理解のために、どんなデータをさらに必要としているのか
- 顧客とのコミュニケーションのために、どんなデータを使いたいのか
ここを押さえさえすれば、業務部門がやりたいことを実現するために必要な施策をクリアに整理し、システム的な解を提示することができる。
しかし、現実にはなかなかそうはいかない。業務部門がやりたいことを「データを使う上での本質」の視点で整理する前に、ベンダーと業務部門の間で話し合われるアプリケーション導入の要件との抱き合わせで、議論が進んでしまうことが往々にしてあるからだ。