BIの導入手順
BIの導入手順は基本的には業務システムの導入と同様に、要件定義→設計→構築→テスト→移行・トレーニングといった流れとなる。
特徴的なのは、繰返し型のプロジェクトとなるという点である。業務システムでもアジャイルなどの反復型の開発手法がとられることがあるが、まだ主流ではないであろう。繰返し型のプロジェクトでは要件定義から移行・トレーニングまでを1サイクルとし、それを繰り返し行なう。1つのサイクルの中でシステムを構築し、それをユーザーが利用し、その結果を反映しシステムを追加・修正していくのである。
BIは業務システムと異なり、意思決定を行なうための戦略型のシステムであり、時間の経過に伴い求められる要件が変化していく。また、分析ニーズも高度化していく。こうした変化をシステムに反映させるためにこのような繰返し型の方式がとられるのである。
ここでは繰り返しの単位となる要件定義から移行・トレーニングまでのサイクルのうち、主に要件定義・設計について説明する。
要件定義
BIの導入プロセスで最も重要なのはこのステップである。BIを導入したが、役に立たないといった不満を聞くことがあるが、その主な原因は要件定義の失敗にある。
どのようなシステムもそうだが、システム化の目的を明確にし、その目的達成に向けてプロジェクトを進めていく必要がある。BIの場合、データを出力することが目的ではない。そのデータを利用して正しく意思決定を行ない、会社の利益が上がるための行動をとることができるようにすることが目的である。
まずこれらの目的を明らかにし、そうした目的を満たすためにはどのような情報が必要なのかという順序で要件を検討していくべきである。
具体的には次のような作業を行なう。
必要な分析対象・情報の抽出
何を分析するか、分析の際に利用する情報にどのようなものがあるかを明確にする。この時重要なのが、利用者の観点から情報を利用する目的や、その情報を利用して行なうアクションを明確にすることである。そうしないと、分析自体が目的となってしまう危険がある。このステップでのユーザーと開発者の主な役割は次のようになる。
- ユーザー
- 既存の帳票や日常の業務の中での課題などから分析対象・情報のニーズを出す。
- 開発者
- ユーザーから出されたニーズを整理、分析し、必要なものに絞り込む。
抽出した分析対象ごとの分析の切り口
分析する数値の決定
具体例で説明しよう。売上を分析したいという場合、売上が分析対象となる。売上を分析する際に顧客別に分析したい・商品カテゴリ別に分析したいという場合、顧客・商品カテゴリが分析の切り口となる。また、売上金額が分析する数値となる。分析の切り口はディメンジョン・テーブルの、分析する数値はファクト・テーブルの数値カラムの元となる。
このステップでのユーザーと開発者の主な役割は次のようになる。
- ユーザー
- 検討用資料に基づき、要件を出す。
- 開発者
- 抽出した分析対象・情報を分析し、分析の切り口、分析する数値を検討するための資料を作成する。その資料をもとにユーザーにヒアリングを行ない、過不足などを洗い出す。
ディメンショナル・モデリング
分析の切り口の分類・階層化と、分析する数値を分類する。分析の切り口の分類とは、分析の切り口をディメンジョンに分類する作業である。
たとえば次のような分析の切り口があるとする。
- 年別、月別、日別、商品別、商品カテゴリ別、顧客別
これをディメンジョンに分類すると、次のようになる。
- 時間ディメンジョン=年別、月別、日別
- 商品ディメンジョン=商品別、商品カテゴリ別
- 顧客ディメンジョン=顧客別
分析の切り口の階層化とは、分類したそれぞれのディメンジョンを階層化する作業である。上記の例の時間ディメンジョンを階層化すると、次のようになる。
- 年→月→日
分析する数値の分類とは、分析する数値をファクトに分類する作業である。1つの分析対象に対し、ファクトが1つであれば、分類作業は発生しない。しかし、ファクトが複数必要となることがある。このような場合は分類作業が必要となる。
たとえば次のような分析する数値があるとする。
- 売上金額、売上数量、予算売上金額、予算売上数量
これをファクトに分類すると、次のようになる。
- 実績売上ファクト=売上金額、売上数量
- 予算売上ファクト=予算売上金額、予算売上数量
実績と予算とではデータの粒度、分析する切り口との組み合わせなどが異なる。そのため1つのファクトとして定義することができないのである。
このステップでのユーザーと開発者の主な役割は次のようになる。
- ユーザー
- モデルを検討し、認識の違いや漏れなどがないかの確認を行なう。
- 開発者
- ここまでで定義した分析の切り口、分析する数値をもとに、モデルのドラフトを作成する。そのドラフトをもとにユーザーにヒアリングを行ない、モデルを完成させる。
元データの分析
ディメンジョン、ファクトのデータをどのシステムから取得するかを分析する。このステップでのユーザーと開発者の主な役割は次のようになる。
- ユーザー
- 社内のシステムやデータと、ディメンジョンおよびファクトの各項目との対応についての情報を提供する。
- 開発者
- ディメンジョンおよびファクトの各項目を一覧にまとめ、それをもとにユーザーにヒアリングを行なう。
設計
次に、要件定義で明らかになった要件を実現させるためのシステムを設計する。具体的には次のような作業を行なう。
- ディメンジョン・テーブル、ファクト・テーブルの設計
- 要件定義で決定したディメンジョナル・モデリングに基づき、ディメンジョン・テーブル、ファクト・テーブルの設計を行なう。
- 画面設計
- 分析画面、レポート出力画面などの各画面のレイアウトなどを設計する。
- レポート設計
- 定型レポートなどのレイアウトや表示項目、計算方法などを設計する。
ここまででBI一般について説明してきた。次回からはオープンソースBIのPentahoを使い、実際のBIツールについて具体的に説明していきたい。
著者紹介:鹿取裕樹
SAPジャパンにて会計コンサルティングを担当。その後、ビーブレイクシステムズの設立に参画する。
現在は、業務システムのパッケージソフトMA-EYESおよびBIソリューションの導入を担当する。
この連載の記事
-
最終回
ソフトウェア・仮想化
インタラクティブなBIダッシュボードを自分で作る -
第6回
ソフトウェア・仮想化
ついにBIのレポートを作成!どんどん実践的に使おう -
第5回
ソフトウェア・仮想化
いよいよキューブを作ってWebブラウザから閲覧開始! -
第4回
ソフトウェア・仮想化
DWHを自分で作ろう!環境構築からデータ登録まで -
第3回
ソフトウェア・仮想化
あなたのパソコンで、BIを実地体験してみよう -
第1回
ソフトウェア・仮想化
「先輩、BIって知ってますか?」― 知識ゼロから学ぶBI -
ソフトウェア・仮想化
BIとは? 基礎からわかる最新BI事情 - この連載の一覧へ