だからその“分析(BI)プロジェクト”は失敗する(1/3)

コラムカテゴリー:

大企業様への“分析(BI:Business Intelligence)システム”の導入が落ち着きはじめ、そろそろ中堅・中小企業様への導入の波が押し寄せてくる予感がします。
しかし、いざ「分析(BI)システムを導入しよう!」と奮起した時に、皆様はどのようにプロジェクトをスタートしますか?「まぁとりあえず導入してみて…」と考えていると、せっかくの投資が“使われない箱”になってしまう可能性が高いです。
さて、今回のコラムでは、実際に分析(BI)システムプロジェクトの顧客コンサルタントとして携わっている私の実務経験から、分析(BI)システム導入の際の注意点を記載しました(全三回の連載を予定しております)。
これから分析(BI)システム導入をご検討される企業様、“プロジェクトが失敗する前に”是非ご活用ください。

そもそもBIって?(おさらいも兼ねて)

企業内の様々なデータを、収集・蓄積・分析・報告することで、経営上などの意思決定に役立てる手法や技術のことを、BI(Business Intelligence)と呼びます。BIを用いて分析を行うためには、一般的には下記の2つの仕組みが必要です。

データウェアハウス(以下、DWH)
企業内に散らばった様々なデータを、一ヶ所にまとめる巨大な“倉庫”
BIツール
DWH等に格納された大量データを分析する際に使うツール

データサイエンティストに置き換わるもの

分析(BI)システムを導入することによって、特定のスキルのある人に帳票データ作成や分析を依頼しなくても、現場の従業員自身が、独自の視点でデータを分析し、業務上の意思決定を迅速に行うことができます。
データサイエンティストのような優秀な人材が“高度に”分析することももちろん重要ですが、普段現場で作業している方が自在に分析できるようになれば、既に業務知識がある分、より早い気付き・判断が可能となります。

しかし、この “魔法”のような分析(BI)システムは、特に下記の点で注意して導入しなければ、せっかくの投資が無駄になってしまう可能性があります。

分析(BI)システムを構築する上で注意すべきこと

分析(BI)システム自体は最新技術ではなく、実は数年前から存在する技術ですが、残念ながら投資の割に明確な成果を上げられなかったプロジェクトも多く存在します。それには、失敗に至った明確な理由があるのです。
BI分野の良書「分析力を駆使する企業(著:日経BPマーケティング)」では、下記の「DELTA」を定義することが重要だ、と説いています。(※ただし、実務経験に基づき下記()内の解釈を一部変更しています)

  • D…データ(分析のためのデータ材料は揃っていますか?)
  • E…エンタープライズ(会社自身が、分析業務を重要視していますか?)
  • L…リーダーシップ(分析を主体的に行うリーダーを任命していますか?)
  • T…ターゲット(分析対象や目的をきちんと定義していますか?)
  • A…アナリスト(分析可能な人材・ツールがありますか?)

上記「DELTA」を、もう少し具体的な内容で9つ定義しました。より良い分析(BI)システムの導入のために、ぜひご覧ください。(4.~9.は、次回以降のコラムにて掲載いたします)

  1. 分析を行う“目的”を深堀りしましたか?
  2. 分析に必要なデータ材料が揃っていますか?データ同士が繋がりますか?
  3. 成果を定量的に測定できますか?
  4. レスポンス目標を立てましたか?
  5. データの“サイジング”を実施しましたか?
  6. OLAPキューブ(多次元分析)の構築は適切ですか?
  7. BIツール・開発ベンダーの選定は適切ですか?
  8. いつも作っているその帳票、目的は何ですか?
  9. 企業内で “分析業務”を認める風土、活かす風土を形成できますか?

1.分析を行う“目的”を深堀りしましたか?

上記「DELTA」の中でも、最初に考えるべきもっとも重要な事項は「ターゲット」です。目的や対象が不明確なままプロジェクトをスタートするのは大変危険です。分析(BI)システムの導入を検討される際は、まず社内で以下を深堀りしてみてください。“なぜ”“なぜ”と考えることで、あやふやな部分が明確化されます。

(深堀例)
「そもそも何に困っていて、何のために分析するのか」
「分析をして何を(どのKPIを)改善したいのか」
「分析によって得た結果を、既存の業務プロセスにどう組み込むか」
…etc…

目的を明確に定義できれば、分析(BI)システム導入のための“方針”が定まり、開発ベンダーとの意思疎通もスムーズになります。逆に、方針が無く“とりあえず”導入してしまうと、開発ベンダー側も“より汎用的”なシステム/機能を構築せざるを得ず、結果として“何でもできそうで肝心な一歩が足りない”使えないシステムとなりがちです。BIツールは決して万能ではなく、“何をやりたいのか”を明確に定義する必要があります。

2.分析に必要なデータ材料が揃っていますか?データ同士が繋がりますか?

分析する目的を定義したら、次は材料となる「データ」を調査します。ERPシステム(統合業務パッケージ)を導入している企業であれば、分析に必要な材料は既に揃っているかもしれません。しかし、まだまだシステム・データが分散している企業も多いのではないでしょうか(販売管理システム、在庫管理システム、物流システム、顧客管理システム…)。そこで、各システムにバラバラに存在するデータをDWHに格納する際に、データ同士が“繋がる”状態にできるかどうかを調査する必要があります。

(注意点の例)

必要なデータはどこにあるか?システム化されているか?

分析に必要なデータがデータベースとして利用可能になっているか、という点に注意が必要です。意思決定に重要なデータが実はExcelだけで管理されていたり、個人のAccessによって保存・管理されている、というケースも少なくありません。その場合、連携元の仕組みのあり方について再定義する必要がありそうです。

データ粒度は揃っているか?揃っていない場合、どう対処するか?

システム毎に、データの時系列の最小粒度が時間別/日別/週別…と異なる場合があります。異なる場合、どの粒度に合わせるかを決め、それよりも大きい粒度のデータの扱いを検討する必要があります。(週別データを日別に分割する…etc)

システム毎に、“同じ意味でも異なるコード”が割り振られていないか?

例えば会社合併の際、コード統合を怠り独自のルールで運用回避する方針となった場合に、“同じ意味でも異なるコード”(店舗コードが同じで、別の識別ルールで判別している等)が存在する場合があります。

顧客データの“秘匿化”を行っているか?

顧客データを扱う場合は、セキュリティにも注力する必要があります。昨今のインターネットやスマートデバイスの普及により、個人の行動履歴・購買履歴を簡単に収集することができてしまいます。顧客情報をDWHに格納する際は、個人を特定できる情報を回避する“秘匿化”の仕組みが必要です。

<秘匿化の例>

  • K-匿名化…位置情報や年齢、職業などのデータの組み合わせで個人を特定できないよう、データのセットをk個以上にする手法。

“秘匿化”の仕組みを導入することにより、企業が利用者から集めた情報の活用目的を提示する際に、“個人を特定できない”旨を説明しやすくなるメリットがあります。

上記はほんの一例ですが、分析の目的に必要なデータの現状・関連性・意味合い・セキュリティ等について事前に調査することが重要です。

3.成果を定量的に測定できますか?

ビジネスの基本、PDCA(計画・実行・評価・改善)。分析(BI)システムにおいても、導入後の効果を評価(Check)することが重要です。具体的には、「1.分析を行う“目的”を深堀りしましたか?」で定義した目的の“現状”を調査し、“定量的な目標”を設定します。

(設定例)

現状A部門で毎月○時間要しているレポート作成業務を、△時間削減する

現状の作業時間が何時間で、導入後は何時間削減を目標とするか、等を具体的に設定します。

地域別の各店販売状況を分析し、一部で売上好調な商品を同地域他店に展開する。結果、一店舗当たり○%売上を向上させて利益を向上

一言で“利益向上”と言っても、様々な施策があります。(売上を伸ばす/原価を下げる/販管費を抑える…)それぞれに対し、具体的な根拠と目標を設定します。

また、成果を定量的に測定するためには、ユーザー利用状況の確認方法も事前に検討する必要があります。一般的なBIツールであれば、監査情報(誰が、いつ、どの情報にアクセスしたか)を管理・参照する機能を保持しており、それを使って利用状況を確認することができます。しかし、利用状況確認後の“業務改善”までを想定した場合、ユーザーが“具体的にどのような分析を行ったか”までを把握する必要があり、より高度な監査機能が必要です。(「誰が・いつ・どのレポートを開いたか」だけがわかったとしても、その後のAction(改善)に繋げることができません)

しかし、高度な監査機能を常に“ON”の状態にしていると、ユーザー操作の度に膨大なログファイルが作成され、システムのレスポンスに影響を与えてしまうという“ジレンマ”も発生します。高度な監査機能を常にONにしておかなくとも、例えば各部に分析推進者を設け、その推進者が主体となって部内の他の利用者の利用状況を確認してもらう協力を事前に要請しておけば、システム利用開始後の「Check(評価)~Action(改善)」が実施しやすくなります。

終わりに(コラム執筆者の想い)

いかがでしたでしょうか。より良い分析(BI)システムを導入するためには、まず“目的”を明確化する必要があります。そもそもBIに関係なく全てのビジネスにおいて、“なぜ”という理由付けは常に必要だと思います。私は常々、意味も無く実施されている業務や、目的が不明確な指示を出されている場に直面すると、見て見ぬふりはせず質問してしまいます。“なぜそれをやるのか”という具体的な目的があやふやであれば、その後の全てのプロセスやアクションがぶれてしまうからです。

皆さんもきっと一度は、心のどこかで「この作業、意味あるのかな…」と感じながら作業されたご経験をお持ちのはずです。無礼を承知でお伺いしますが、目の前にある皆さんの業務の“目的”は何でしょうか?何のためにそれをやるのでしょうか?「いいからやれ!」と指示された業務には、「なぜそれをやるのですか?」と根拠を聞いてみませんか?

「分析」というキーワードが注目され始めた今こそ、分析(BI)システム導入に合わせて、既存業務を見つめ直すチャンスなのです。あるべき姿(ToBe)を目指し、一緒に業務改善していきませんか?

次回コラムでは、分析(BI)システムの中でも頭を悩ます「レスポンス」についてお話します。

(トラックバック)

だからその“分析(BI)プロジェクト”は失敗する(1/3)
だからその“分析(BI)プロジェクト”は失敗する(2/3)
だからその“分析(BI)プロジェクト”は失敗する(3/3)

関連サービス

2013年09月01日 (日)

青山システムコンサルティング株式会社

その他