BI（ビジネスインテリジェンス）や、DWH（データウェアハウス）のシステム構築は、

6割が失敗すると言われます。

※BIとDWHについては、この記事の一番下に用語解説を用意しました。

かけるコストを考えると、あんまりな比率です。

今日はBIシステム構築の失敗パターンと対策例を紹介します。

紹介する失敗例は次の３点です。

　失敗パターン１：何を分析したいのかをよく分かっていなかった。
　失敗パターン２：運用上無理があった。
　失敗パターン３：データベースの設計が実ビジネスモデルに適合しない。

失敗パターン１：何を分析したいのかをよく分かっていなかった。

　びっくりする方もいるかと思いますが、
　実は、もっとも多い失敗はこのパターンです。

　これは一時期、DWHの用語が先行して流行ったために起きた現象かとも思えます。

　もちろんこれはシステム化の目的を明らかにしていないことが原因です。
　具体化された経営方針や対策に対して実行するのなら良いのですが、
　目的があいまいな場合や、とにかくBIシステムを構築するなどの用語先行の場合は

　注意が必要です。

　DWHは、「さまざまな分析ができるようにデータを蓄積」の目標もあるのですが、

　具体的な目標を欠いたDWH構築は、コストばかりがかかりお勧めできません。

　特に「やること自体が大切です。まず始めましょう。」等の考え方には
　乗らないほうが賢明です。

　DWHは規模を大きく取ると湯水のようにコストが膨らみ、費用対効果が
　合わなくなります。

　よほど明確かつ具体的な目標があり予算が十分な場合はともかく、
　通常は、費用対効果が最大になるように設計を進めるとよい結果が
　生まれやすくなります。

　BI/DWHはスモールイン（小さく始める）が正解です。
　業務プロの方が、完成したシステムを使うことで
　次の素晴らしい案が見えるようになります。

失敗パターン２：運用上無理があった。

　手入力すべきデータを入力する手間が割けなかったり、
　夜間バッチの処理時間が足りないなどの問題です。

　この問題はDWHに限らず一定規模以上のシステムでたまに聞く話です。

　DWHは大量のデータを扱うことが多いため、比較的この問題が
　発生しやすいと言えます。

　運用作業に関わる部分は作業量に無理がないかを
　初期段階からよく考えておくことが必要です。

失敗パターン３：データベースの設計が実ビジネスモデルに適合しない。

　これはビジネスにおけるものごとの構造がベンダーに伝わっていないことが原因です。

　発生させないようにするには、ベンダーの成果物の良し悪しを把握する必要があります。

　そこで、
　BIのDB設計は、データの実モデルを反映する点が特徴的なので、

　このDB構造は業務プロの方も理解されることをお勧めします。

　そうすることで初めて設計の良し悪しが評価できるようになります。

　プロジェクトの初期段階からベンダーが用意する設計書の見方や設計技法について
　よく説明を受けるようにしてください。

　このDB設計を理解できるまで説明するのはベンダーの責務だと思います。

-- 以下、用語解説です。 --

※１　BIとは

　　　ビジネスインテリジェンスの略で、

　　　データ分析をビジネスのために活用するソリューション（問題解決手段）のことです。
　　　さまざまな技術を組み合わせて実現します。

　　　用語としては、DWHを包含する単語です。

※２　DWHとは

　　　データウェアハウスの略で、直訳では「データの倉庫」です。

　　　企業をはじめとする組織活動から発生するデータを集めて、
　　　分析するためにそのデータを蓄積するデーターベースを指します。

　　　DWHシステムと呼ぶシステムを考える場合、蓄積部分だけではなく、
　　　分析部分も含めて考えることがほとんどです。