必要な要件・機能を見極め、適材適所で活用する

　企業内にはさまざまなスキルレベル、職務のユーザーが混在している。誰にどのタイミングで、どの情報を、どのBI機能で提供するのか、あるいは使わせるのかを明確化することが重要になってくる。ここで留意すべきは、ユーザーに対して短期間で過度の期待をすることは禁物ということだ。情報リテラシーは徐々に向上しているとはいえ、まだまだというのが実態だろう。情報や機能の公開は段階（フェーズ）を踏んで進めることが肝要となる。

　これと同じく、BIシステムを開発する場合も、ウォーターフォールモデルではなくプロトタイプモデルが推奨される。要件定義に基づき、ある限られた要件（代表的なパターンをいくつかピックアップするのもいいだろう）に関して、プロトタイプを作成し、ユーザーに試使用させ、フィードバックをもらい、本番開発に着手する手法だ。机上の説明だけでは分からず、見て触って初めて実感できるのがBIの特性であり、手戻りを最小限にし、使えるシステムにするための鉄則とも言えるだろう。

　また、BIツールに対する過度の期待も禁物だ。前編でも述べたように、BIは統合化・スイート化され、機能も毎年拡張されてはいるが、決して万能ではない。自社の要件に見合う機能の見極めと活用法が重要になってくる。

　前述した、「どのBI機能で」というポイントに関して、数多くの機能の中から1つ、「多次元分析（OLAP）」について考察してみよう。

多次元分析（OLAP）はRかMか？

　多次元分析は大きく分類するとROLAP（リレーショナルOLAP）とMOLAP（マルチディメンショナルOLAP）に分類される。ROLAPは、ドリルダウンやダイシング操作を行うたびに、データウェアハウスにアクセスしてデータを検索し結果を返すタイプである。データウェアハウス内に直接アクセスするため、全てのデータが分析可能だが、対象のデータボリュームによってはレスポンスが遅くなる場合がある。

　一方、MOLAPは独自に構築された多次元データベース（多次元のデータマート）にアクセスし、結果を返すタイプだ。あくまでもデータウェアハウスから切り出された部分集合であるため、対象のデータが含まれていれば、パフォーマンスよく分析できる。言い換えれば、対象のデータが含まれていなければ分析できないということを意味している。

　つまり、多次元分析要件がある場合、まず必要となるのはROLAPなのだ。パフォーマンスに関わらず、分析できなければ意味がないからだ。そして、ある限定されたデータに関して分析のパフォーマンスを向上したい場合に、MOLAPを二次的に活用するのが1つの考え方となる。

　ただ、ROLAPを提供するベンダーでは、都度データウェアハウスにアクセスするのではなく、検索したデータをキャッシュし、レスポンスを向上する仕組みを搭載している。さらに、近年では多次元データベース並み、あるいはそれ以上のパフォーマンスを発揮するデータウェアハウス技術が開発されており、企業がROLAPによる効果を最大化できる環境が整ってきている。

　このように多次元分析一つをとってみても、特性の理解と適用領域の見極めが重要になってくる。

パフォーマンスマネジメント実装の勘所は、「データ統合」にあり！

　パフォーマンスマネジメント（全社業績管理）要件には、KPI（重要業績評価指標）の可視化手段としてダッシュボードやスコアカードが用いられることになるが、その際の勘所となるのは、データ統合だ。「業績管理」と「データ統合」は一見無関係のように思われるが、実はそうではない。

　従来のように財務指標だけをとらえて経営判断を下すのであれば、財務システム内の財務データのみをしっかりと管理し、可視化すればよかったのだろうが、近年日本においても実装段階に入ったといわれるBSC（バランススコアカード）を例に見ても、経営トップが把握しなければならない指標は多岐に渡る。

　なぜなら、BSCの4つの視点上の各KPIは、さまざまな業務プロセスの結果が集約されたものだからだ。例えば、財務の視点のデータはERPの財務・会計アプリケーション内にあり、顧客の視点のKPIはCRMアプリケーション内に、内部プロセスはSFAやSCM内にあり、学習と成長はHRアプリケーション内、と、それぞれ異なる種類のデータベースに蓄えられているかもしれない。もちろん、これはあくまで一例だが、どの企業においても必ずといっていいほどKPIの元データは異種データソース内に散在している。

　つまり、4つの視点上のKPIごとに、異なるデータソースからの抽出や集計が必要になるということだ。こうした要件に対応するために、可視化を提供するフロントエンドツール側で、それぞれのKPIごとに対象となるデータソースから必要なデータを抽出・集計し、結果を1画面のスコアカード一覧や戦略マップ上に表示する手法も考えられるが、この手法は、大きな課題を抱えている。それは、情報の信頼性や整合性の問題だ。

　異なる各データソースから得られた結果がスコアカード上に表示され戦略マップで因果関係が示されたとしても、これらのKPI（の値）間には、何の整合性の保証もない。こうした課題を解決するためには、企業内に散在するデータを統合した信頼あるデータ基盤の構築が必要になってくる。

　まず、企業内に散在する蓄えられたデータの中から必要なデータを抽出する。それから、異なるコード体系の統一やゴミデータの排除などを施し、その上で全社的なデータウェアハウス、あるいはBSC専用（業績管理用）のデータマートを構築する。これによってデータの一元性・一貫性が確保され、データの品質は向上し、整合性のとれた信頼あるデータに基づく経営管理を実現することができる。

　もちろん、既に紙ベースや表計算のシート上で管理しているKPIをまずはWeb上で可視化することや、フロントエンドツール側で個々に抽出した結果を1画面に集約する手法も、テンポラリーのソリューションとして活用することはできる。しかし、あくまでも統合データ基盤整備を念頭においたパフォーマンスマネジメントのシステム化が肝要であるということをお忘れなく。

BIを使った情報活用を促進するためには

　情報活用に関するリテラシーも少しずつ向上してきているとともに、ユーザーのリテラシーを向上させたいという企業側の目論見もあり、従来は、IT部門主導であらかじめ作成された定型レポート（帳票）を見るだけという形態が主流だったのが、昨今の国内導入事例を見ても、その多くでは、大量に作成・提供されていた定型レポートが大幅に削減され、ユーザー自身による非定型なデータ検索やレポート作成、既存レポートをカスタマイズして利用する形態への移行が見受けられる。

　しかし、これにはユーザーに対する継続的な啓蒙活動とトレーニングが欠かせない。「BIツールを活用することによって」ではなく、「情報を活用することによってどんなメリットがあるのか」をまず理解してもらうことが先決だ。BIツールはその手段に過ぎない。

　次に、BIツールを使いこなしてもらうためのトレーニングを実施する。よく行われているのは、IT部門あるいはビジネス部門のキーマンが、ベンダーサイトでトレーニングを受講後、その内容をベースに、実データを使用したトレーニングテキストや操作ガイドを独自に作成し、実データを使用したハンズオントレーニングを社内向けに実施する手法だ。

　ただし、ベンダーサイトでのトレーニングはあくまでもサンプルデータに基づくものであるため、実際のユーザー向けには実データによる講習が強く推奨される。しかし、実施には1点課題がある。それは、トレーニングの実施工数だ。特に全国に拠点を持ち、各拠点のユーザーに対する講習が必要なケースでは、多大な時間と工数が必要になる。その場合には、トレーニング担当者が全国を行脚するか、各拠点のユーザーを数回に分けて本社に集め、実施しなければならない。

　こうした課題を解決する手段の1つとして、eラーニングがある。eラーニングを活用することによって、ユーザーは自席に居ながらにして、空いた時間にトレーニングを受講できる。もちろんベンダー側が提供するeラーニングのほとんどはサンプルデータを使用したものになってしまうため、企業ごとの実データでカスタマイズできるタイプのeラーニングが望まれる。

　また、運用開始後は、BIツール側で自動的に取得されるアクセスログを解析し、利用状況を把握するとともに、定期的にユーザーに対するアンケート調査を実施し、満足度向上に向けた継続的な利用環境の改善が肝要である。

　以上、「失敗しないBI導入術」と題した本連載では、企業の要件（目的）に見合ったBIツール（機能）の見極めと選定、そして各ユーザー層への段階的な公開と、全社で一貫した情報活用のためのBI標準化の必要性を説いてきた。また、どんなに優れた統合BI製品を手段として使用したとしても、活用対象であるデータ基盤が信頼あるものでなければ効果的な活用はできないということは、今回述べたとおりだ。そして最後に、ユーザーへのトレーニングと継続的な利用環境改善の必要性を紹介した。

　LTV（顧客生涯価値）をいかに高めるかが議論されることがあるが、企業にとって社員は顧客、BIシステムにとってユーザーは顧客である。ユーザーが情報を効果的に活用することによって得られる企業としてのメリットをいかに高めるか、いかにユーザーのLTVを高めるかが鍵となる。