想像してみてください。今まさに、社内向けBIソリューションの長い開発期間を終えようとしているところです。顧客にこのシステムをリリースすれば、残る仕事は楽なものだと思うのではないでしょうか。しかし残念ながら、そうはいかないかもしれません。

開発の段階では、大抵の場合、多くの時間と手間をかけて最初のバージョンリリースまでこぎつけます。しかし、ユーザーが実際にBIを使い始め、彼らが業務の中で様々な分析を必要としてくる中で、改めて必要となる作業もあります。

例えば、下記のようなシナリオを想定してみましょう。

1. 最悪のケース：作ったソリューションをユーザーが使ってくれない
   理由は様々ですが、実装のクオリティが低い、ユーザーのニーズに沿えていない、とにかく使いにくい、などが挙げられます。
   この場合、リリース時に比べて多くのシステム改修が必要となるでしょう。
2. 最良のケース：作ったソリューションがユーザーの役に立ち、会社に多くの利益をもたらし、経営における議論で活用されている
   当然のことながら、ユーザーや関係者は開発者の指導のもとでの、新たな機能の追加や変更のリクエストをしてくることでしょう。
3. 両者いずれかの中間的な状況

いずれにしても、システムの変更やアップグレードの準備をしていく必要があることがおわかりかと思います。

顧客の期待

ソリューションは、課題解決のために提供する一種の製品/サービスと捉えられます。それを使うエンドユーザーや利害関係者ステークホルダーに対して、満足させる必要があると考えられるでしょう。

この考えを念頭に置いてシステムを稼働させていれば、組織にとってより生産性と利便性を維持できるソリューションとなります。

このガイドでは、BIソリューションのライフサイクルにおける様々なステージでサービスを提供していく中、重要となるいくつかの側面（管理の改善、展開、データの信頼性など）を解説していきます。主に、中～大規模組織での社内向けBIソリューションを例として取り上げますが、多くの部分が他のシナリオにも当てはまるでしょう。また、理論的な説明よりも、ビジネス的な視点に沿って説明していきます。

成功を握る3つの鍵

1．計画と管理

次の要件やリリース、修正に向けて準備をする必要があります。
ここでは、システムに変更を加えるにあたって留意しておきたいいくつかのポイントを確認しましょう。

データの整合性を保証し、顧客の信用を得る

まず念頭に置く必要があるのが、BIソリューションとは、組織がダッシュボードに表示されたKPIやチャートを使い、そのデータを意思決定に役立てるものであるということです。
もしそのデータが不正確なものであれば、正しい判断をすることはできないでしょう。

Sisense Elasticube などのデータマートやデータウェアハウスを使い、一か所に全てのデータを集め、信用できるデータ源を一つに絞ることで、ある程度の正確性を保証できるようになります。
しかし、これだけではそのデータがいついかなるときも正確で一貫した内容だと証明するには不十分です。

一貫性を保つことができない例は以下の通りです。

1. KPIの測定基準がフロントエンドで異なる場合
   (外貨を含む収入計算時に、月初めの為替レートと別の時点での為替レートでの計算をする際、基準をあわせるために月末の為替レートを使用する場合など）
2. 大企業などで、データの定義や計算基準に合わせて複数のデータウェアハウスが存在する場合
3. そもそもデータウェアハウスに入っているデータが不正確な場合
4. 企業の目的を達成するためのデータをダッシュボードで表示する際に、計算式や導出法があまりに複雑な場合

一貫性と整合性の問題を解決するには、全てのエンドユーザーと利害関係者、一時的な参照者がアクセスできる、全てのKPI定義と全ての計算ロジックが集まる場所を用意する必要があります。

これらのデータ整合性について留意すべき点があれば、それをユーザーに説明する資料をダッシュボードに表示するのも良いかもしれません。その場合、tipsやオンラインドキュメントのリンクなどを活用しましょう。

エンドユーザーと利害関係者の役割・責務を理解する

BI製品ライフサイクルのどの時点の話でも当てはまりますが、特に最初のリリース時に重要となるのが、いかにユーザーのことを私たちが知っているかという点です。誰が意思決定の権限を持つのか、誰がこのソリューションでもっとも得をするのか、誰がヘビーユーザーで、誰が業務の流れやニーズに詳しいか、そして、誰がソリューション構築に協力的であるか(逆にいうと、誰がソリューション構築の障害となりうるか)をしっかりと把握しましょう。

BIソリューションを構築する前に、まずはユーザーそれぞれが持つ権限、役割、責務を理解するために、あらゆる情報を使い、組織マップを作ります。

利害関係者をまとめた組織マップを作成したら、それぞれが持つ、BIのアカウントに該当する権限を付与していきましょう。この方法を使えば、それぞれのアカウントに対してどのような権限を持ったロールを付与すべきか確認していく作業を省くことができます。

下の例のようなものを作成しましょう。

運用方法の確立

組織の文化とBIの目的に合わせて、BI製品に関連するサービスの提供方法、業務の流れや基準、データ管理などを定義しましょう。

サービスを提供するからには、その組織の文化にマッチした方法で行いたいものです。これには、主に二つのアプローチ方法があります。

1. 集権化アプローチ
   ソリューション全体に、業務課題にあわせた全ての流れと分析軸をあらかじめ盛り込んでしまい、エンドユーザーに細かい調整などの余地を与えない方法です。このアプローチは、ユーザーが自身の見たいものをよく理解しており、かつ分析すべき対象があまり変化に富んでいないような業務に向いています。
   この場合、ユーザーに対する教育やドキュメントの作成に注力する必要があるでしょう。
2. 分権化アプローチ
   サービス提供を行っていく上で、いわゆる「標準的」な、ユーザーによる調整を許す方法です。このアプローチは、BI開発チーム外のビジネスチーム側のダッシュボードデザイナーが一時的なレポートを作成したり、日々の分析の中でさまざまな分析ツールを使い分ける必要のある上級アナリストに対して相性がよい方法です。この方法を採用する場合、ユーザーのフィードバックをできる限り取り入れ、短いサイクルでのリリースを繰り返すべきです。また、ユーザーがより製品を使いやすく感じるような設計を心がけることも重要です。

ほとんどの場合、上記2つの中間的なアプローチを採用すると上手くいきやすいでしょう。集権化と分権化のどちらに寄るべきかは組織の業務傾向から判断すべきです。

サービスの提供方法を理解することで、ソリューション開発のどこに注力すべきかを判断できます。例えば、エンドユーザーのことを考えてソリューションを設計するのか、ダッシュボードデザイナーやアナリストのことを考えて全体の運営やトレーニングの統制を優先するのかなどです。

また、開発者と設計者の間で認識の齟齬が起きないよう、開発業務の流れや基準を設けておくことも大切でしょう。

最後に、データの信頼性を保証する工夫として、データソースの処理管理概要を作成すべきです。

例）
・BIの管理者が説明責任を果たすとともに、責任者の承認を持ってのみBIに関連するデータソースに変更を加えることができることとする
・週次や月次でデータベース管理者やその他データソース管理者とのすり合わせを行う

運用管理改善　-バージョンリリース適用戦略-

会社の製品が顧客の要望やニーズに合わせて変化していくように、BI製品にも同じことが言えます。ライフサイクルの間でソリューションの変更要求、新たな機能のリクエスト、バグや計算の不備などが出てくるでしょう。

ここでは、効率的な改善実装の方法について述べます。

優先順位をつける
いくつかのリクエストは他のものに比べて緊急度や重要度が高いものがあります。リリース戦略の一部として、組織の文化に合わせてリクエストに優先順位をつけると良いでしょう。優先度の決定方法は、例えば、それぞれのリクエストにおける特徴やユーザーの背景から、費用や時間などのコスト圧縮や新たな成長の機会創出、または企業に与える影響を考慮する、などが挙げられます。他にも、そのリクエストがチーム・部署・組織のビジョンや戦略に合っているかどうか、または工数見積もりによるROIなどを優先順位の指標とすることもできます。さらに、ソリューションそのものの安定性を上げることに貢献するようなリクエストであるかどうかも判断材料となるでしょう。一般的にこの手のリクエストは、開発チーム内から出てくる新たな機能の追加やパフォーマンス改善の提案であることが多いです。

リクエストの優先順位は、利害関係者がその優先度の背景となる理由を理解し、協力できるように透明性を確保することです。

バージョン管理
一人が実行した変更は全てのユーザーに適応されるべきです。これらの変更をしっかりと管理するために、どこがどのように変更されたのかを管理できるよう、バージョン管理システムを導入するのが定石でしょう。

リリースサイクル、変更要求とホットフィックス
短いサイクルでのリリースはそれだけ一度あたりの変更の幅・量が少なくなります。早いリリースを心がけるアプローチと、一度のリリースを大きく、有意にするというアプローチはトレードオフの関係にあります。

顧客にあわせて、短いリリースサイクルと長いリリースサイクルを組み合わせることができますが、その長さはリリースされる機能に見合った期間である必要があります。

次のリリースにどの機能のリクエストを反映させるのかは、ソフトウェアマネジメント方法（アジャイルやカンバン方式など)や、優先順位に基づいて定めることができます。

大きな変更は、普段のリリースサイクルよりも多くの時間を要します。

例えば、隔週ペースでバージョンリリースしていたところに、6週間の開発期間が必要な変更リクエストがあったとしましょう。この場合、可能であればそのリクエストを細かい機能に分解してみましょう。もし分解ができないのであれば、他のリクエストをこなす傍らで平行して開発を行い、準備が整ったら次のリリースに加える手段もあります。

もしとても重要で緊急性の高い要求(障害対応など)があれば、ホットフィックスバージョンをリリースすることも考えられます。これを行うか否かの基準は事前に定めておく必要があるでしょう。

文書化
それぞれのリリースでどのような変更を施したか(容量の拡大、計算方法の追加、新たなKPIなど)は文書化しておきましょう。

これらのリリース効率化手段に加えて、それぞれのリリースをトレースする場所(内部の開発チームと、外部のダッシュボード使用者双方が利用できるもの)を設けておくべきでしょう。

2．ロールアウト計画

ロールアウトは開発が終了してから開始します。

ロールアウトを成功させることは、ユーザーの信頼を得るためにもっとも重要な要素であり、最初に良い印象を得ることができなければ二度目はありません。

ロールアウト成功のためには以下の要素が必要となってきます。

1. ユーザー審査と利害関係者の承認。製品のロールアウトに関連する全ての関係者を含めてコミットメントを得る必要があります。
2. 本番環境で製品が運用スタートするまで、他環境にある開発は全てストップしなければなりません。
3. 対象の顧客に対して展開しましょう。
4. ダッシュボードの概要、目的、使い方を記した資料を配布しましょう。メール、ツールtips、ミーティングなどの手段で伝えると有効です。
5. オンボーディング(リリースするだけでなく、トレーニングプログラムも必ず盛り込みましょう)。
6. 開始から数週間は緊密なサポートをするよう提案しましょう。

また、リリースの方法として、最初にBIを扱うことになれた熟練のユーザー向けにリリースし(ベータ版などの位置づけにするとよいでしょう)、彼らのフィードバックを受けた上で他の全ユーザーにもリリースする(もしくはそのあとも徐々にリリース範囲を拡大し、次に日常的にデータを扱うユーザー、さらにその次はマネージャークラスにリリースする)といった漸進的リリースも有効な手段です。

オンボーディングプロセス

例えユーザーが技術やプラットフォームに詳しかったとしても、作成したソリューションが最初にリリースされた際は、誰にとっても新しく、全ての機能を直感的に扱うことができるわけではないでしょう。

リリースノートに加えて、(特に最初のリリース時は)トレーニングプログラムを設けるとことをおすすめします。

さらにソリューションのライフサイクルの中で新規ユーザーが参加することもあるでしょう。新たなユーザーを考慮に入れ、個人トレーニングセッションや講義の録音・録画、オンラインチュートリアルやユーザーが製品知識を深められるような資料を用意することを考えてみましょう。

3．活用されるためにプッシュする

なにを測りたいのか？

リリース時に実装する典型的なKPIとしては、売上利益、マーケットシェア、成長率などが挙げられます。これらの指標は、製品の売り出しに成功しているか否か、顧客が製品に対してよい反応をしてくれているか否かを測ることができます。しかし、リリースしたBI製品に関してはこのような指標を用いることはできないため、何か別の基準を設けて、ソリューションが正しい方向に向かっているのか、それとも別の方策を練る必要があるのかを判断し、次回のリリースの前に何を改善していくべきなのかを決める必要があります。

BIの成功判断基準は、ユーザーの数や使用頻度などの潜在的なユーザーのレベルや、組織にどれだけソリューションが根付いているのかを土台とすると良いでしょう。

ここでは成功基準を決める際のいくつかの例を示します。

1. 利益
   コスト削減への貢献度(BIを使ってどれだけのコストを削減できたか？)。例としては数値の可視化によって組織の運営コストや金融コストの無駄を削減した値などが挙げられます。また、データの組み合わせによって新たなビジネス機会を創出し、そのビジネスシナリオを可視化することで得ることのできる利益も成功の基準となるでしょう。あるいは、これまでマニュアルで行っていたETLなどの作業を、ソリューションによって月単位どれくらい短縮できたのかといった点も基準に使えます。
2. ソリューションの使いやすさと、業務への適合率
   毎月どのくらいの数のユーザーがBIを使っているのか？その数は潜在的ユーザー数の何割なのか？先週に比べて使用率に増加が見られるか？ユーザーの使用頻度は？（月1回/週1回/毎日/毎時間）ソリューションがユーザーの業務の助けとなっているか？重要な意思決定に役立っているか？ユーザーそれぞれの個人目標や会社の目標を達成するために役立っているか？などの基準を設けましょう。

成功を判断するスマートな方法

フィードバックはユーザーから届く贈り物です。見逃さないようにしましょう。

BIソリューションの成否を判断するKPIを決めたなら、次に考えるべきは、それをどのように測るかです。

ソリューションを組織にとって利益あるものとするため、BIに対するユーザーの満足度、理解度などをトレースし、彼らが抱える問題に対する第一人者となった上で、それに対する改善策の実行を繰り返していきましょう。

これを行うために、以下のメソッドを使ってみましょう。

1. 改善策提案の共有リストを作成する
2. リアルタイムでフィードバックを見ることができるシステムを構築する
3. 中間管理職層や高次管理職の人間と会う
4. フィードバックを得るため、該当部署のミーティングに参加する

分析を分析する
BIのメタデータを入手できるならば、どの領域のデータが頻繁に使われているのかなどを分析することができます。

評判を広めるのが「あなた」の仕事です！

ソリューションを作ったからには、より多くのユーザーを増やし、組織に対する利益を拡大したいものです。そのためには、自らが声をあげてBIを広めていきましょう！以下のような手段をとってみるとよいでしょう。

1. 定期的なコミュニケーションを意識する
2. リリース時の話や、組織がBIによってどれだけ利益を得ているか、導入前と後でどのくらい変わったか、ユーザーの感想、などの成功体験を広める
3. 特定の人に対して、業務プロセスに沿ったダッシュボードの使用をデモンストレーションする
4. トレーニングデイを設ける – ユーザーが製品に対する満足度を自分で上げることができる上に、組織内での流行りを生み出せるかもしれません
5. 新たな別の部署にソリューションを提案する
6. 新たな潜在顧客に対して、経営情報をまとめたお試しダッシュボードをサンプルとして送る

 

まとめ

サービスの提供は全てのBIソリューションにとって重要なステージであり、開発前にも開発中にも入念に計画を練って動く必要があります。ここで計画したサービスの提供形態が組織にもっとも大きな影響を与えるでしょう。BIソリューションを内部製品として長期間扱い、目に見える形で重要な位置づけであると証明できれば、業務改善への非常に有効な手段として組織のツールセットの中核を担う存在になります。

 

この投稿に記載されているすべてのデータは情報提供のみを目的としており、正確ではありません。前もってご了承ください。
本記事は、Sisense社の許諾のもと弊社独自で記事化しました。
https://www.sisense.com/blog/the-ultimate-guide-to-delivering-bi-solutions/

※ Sisense は、Sisense Inc の商標または登録商標です。
※ その他の会社名、製品名は各社の登録商標または商標です。
※ 記事の内容は記事公開時点での情報です。閲覧頂いた時点では異なる可能性がございます。