組み込みアナリティクス究極のガイド: 組み込みBIのためのスターターキット

1. 目標に対して予算は現実的であるか。
2. 投資収益率はプロジェクトへの着手を正当化しているか。

顧客フィードバック: まずはこちらから着手しましょう。顧客はアナリティクスに興味を示しているでしょうか。彼らはアナリティクスソリューションから十分な利益と価値を得ることができるでしょうか。

データセキュリティはアナリティクスアプリケーションの重要な要素です。まず、既存のソフトウェアに設定されたデータセキュリティは、シームレスかつ自動的にアナリティクスアプリケーションに反映されなくてはいけません。価値創造の大きな領域のひとつは、あるユーザーを他のユーザーに対してベンチマークする能力です。これは、顧客レベル、部門レベル、または店舗間の地域比較で行われます。この場合、自身のデータと他のデータを比較して表示するために、他のデータにアクセスできなくてはいけません。このような場合、粒度の細かいデータには標準的なセキュリティを設定し、集計されたエンティティには、オープンなアクセスを提供することが望まれます。

ビジネス目標への影響を理解: ほとんどのソフトウェアベンダーは、高度なアナリティクスがいつどこでビジネス目標に影響を与えるかを理解していないため、新しいソリューションを導入するタイミングが分かりにくく、価値の低い基本的なクエリーやレポート作成ソリューションを安易に初期設定にしてしまいがちです。

将来への備え: 現在だけでなく、将来的な要件にも合致することを確認します。アナリティクスプラットフォームの柔軟性は重要です。製品ロードマップが、新しい分析機能により達成可能であることを明確にします。

機能的な選択肢: 顧客のニーズに合わせて、アナリティクス製品に搭載されている機能を提供できることが重要です。コラボレーションBI、ロケーションインテリジェンス、モバイルBI、ダッシュボードなどの機能は、顧客に最高のユーザーエクスペリエンスを提供するために考慮すべき機能です。ただし、既存製品の新機能開発に注力すべきであり、顧客要件に対応するためのアナリティクスアプリケーションの開発に注力すべきではありません。

組み込み: BIベンダーがどのように組み込み機能を提供するかを把握しておくことは極めて重要です。また、製品ビジョンを達成するために、既存のアプリケーションにどのようにアナリティクスを組み込みたいのかも把握しておく必要があります。関係者と協力して、利用可能な組み込み機能のビジネスバリュー、コスト、メンテナンスの意味を理解します。

継続的な関係: アナリティクス製品の組み込みは単純な決定とは異なり、結婚に近いものがあります。そのため、一緒にプロジェクトに携わるベンダーを時間をかけて知ることが大切です。長期的なパートナーシップを築くために、彼らの文化が自分たちとうまく融合できるかを確認します。これは難しいことですが、セールスプロセスを評価し、技術チームと会話をして、彼らがどのように対応するのかを確認しましょう。彼らのセールスサイクルが遅く、こちらの負荷が大きいのであれば、重要なサポートが必要な局面で何ひとつ改善されない可能性が予測できます。

高幌なるベンダー一覧の作成: データアナリティクス業界は、多数のベンダーが台頭し、成長を続けています。ベンダーのウェブサイトや、オンラインビデオ、サポートサイトなどを通して、彼らが基準を満たしているかどうかを素早く判断しましょう。ベンダーとお互いを紹介する打ち合わせを行い、可能であれば、彼らの顧客とも話をしてみましょう。ベンダーとデモを実施し、要件に最も適合するベンダーを探します。

POCを実施し製品を選定: POCは、使用したいアプリケーションをテストする最高の機会です。しかし、POCは実際の導入を完全にテストするものではありません。POC はひとつ、または2つの製品に限定し、最初の製品が基準を満たさない場合は、すぐに次の製品の検討へ移行できるように準備しておきましょう。

エンドユーザーにとって、コンテンツはアナリティクスアプリケーションの最初で最後の印象を与えるものなので、確実に成功を導くためには優れた情報のデザインに注力しましょう。以下に、優れたアナリティクスアプリケーションをデザインするための重要ポイントをいくつか示します。

もし、アプリケーションがこれらのニーズをすべて満たすことができなければ、プロジェクトは失敗に終わるでしょう。ユーザーがアプリケーションを使用することはないため、投資対効果は著しく低下します。

幸いなことに、これまでのペルソナ構築を通して、このステップの準備はかなり整っているはずです。必要な機能や必要なアナリティクスインタラクション、ユーザーに提供すべきデータについて十分に理解しなくてはいけません。あとは、デザインに注力し、それを魅力的なものへと昇華させるだけです。しかし、それはどのようにすればよいのでしょうか。よくぞ聞いてくれました！

ダッシュボードのデザインでは、シンプルであることが成功へのカギです。複雑なインターフェースは、技術者ではない一般的なユーザーを対象としたアプリケーションやソフトウェアには不適切です。デザインの核となる機能を絞り込むようにしましょう。理想のユーザーのためではなく、既存のユーザーのためのデザインです。つまりこれは、たとえ機能を犠牲にすることになったとしても、直感的で分かりやすいUIを構築すべきことを意味します。一般的なユーザーの立場に立って、アナリティクスインタフェースに何を必要としているのかを自問しましょう。

まずは、データを分析に適した形式で準備します。トランザクションアプリケーションは、多くの場合、レポートや分析の負荷に最適化されません。ユーザーは、より大規模なデータセットや、時間の経過とともに集計されたデータへのアクセスを求めるようになるでしょう。そのため、コアアプリケーションのパフォーマンスに悪影響を与えることなくこの分析負荷をサポートするために、特別なレポートテーブルを構築したり、データウェアハウスを開発したりする必要が出てくるかもしれません。

分析負荷に対応するためにデータを変換する場合、高度なデータ品質の維持を保証しなくてはいけません。ダッシュボードやそこに含まれるグラフは、元になるデータの品質があってこそ、その良さを発揮します。データ品質の欠如は、アナリティクスプロジェクトが失敗する主な理由のひとつです。この罠にかかってはいけません。データソースや構築したダッシュボードのテストを繰り返して、品質に問題がないことを確認します。

次に、優れたダッシュボードデザインの検討を始めるためのガイドラインをいくつか紹介します。これはあくまで出発点に過ぎません。Yellowfinのダッシュボードギャラリーなど、ユーザーにとって最高のアナリティクスコンテンツを構築するために役立つリソースが数多くあ ります。

プラットフォーム全体で一貫したエクスペリエンスを実現するために、アナリティクスコンポーネントが既存のアプリケーションの他の部分と同じであるように見えることが重要です。このプロセスは、ホワイトラベルアナリティクスと呼ばれています。

前述したように、完全にホワイトラベル化されたソリューション (顧客はサードパーティ製製品であることにまったく気が付きません)、グレーラベル化されたソリューション (自社製品としてブランド化しますが、サードパーティ製ツールであることを明確に示します)、または、サードパーティ製ツールのブランドを維持したソリューションを組み込むことができます。プラットフォーム全体で一貫したデザインを採用することで、セキュリティ、パフォーマンス、サポートなど、他の製品を使用する際にユーザーが抱く潜在的な懸念を抑えることができます。

ホワイトラベル化では、基盤となるアナリティクスプラットフォームのプロバイダーがエンドユーザーに明らかにされることはありません。すべてのラベルや、ユーザーメッセージ、エラーメッセージには、アナリティクスを提供するサードパーティについて言及する文言がないか、削除されています。もうひとつの選択肢として、ブラックラベル化があります。これはアナリティクスプラットフォームをエンドユーザーに明確に開示します (例: 提供Yellowfin)。

既存プラットフォームへのアナリティクスアプリケーションの統合方法を考える際には、以下のようにいくつかの選択肢があります。

既存の製品とアナリティクスアプリケーションを統合する場合、以下の領域でプラットフォーム間における統合の構築を検討するとよいでしょう。

アナリティクスアプリケーションが既存アプリケーションのデータセキュリティに抵触することなく、アナリティクスモジュールのユーザーが本来見ることのできないデータにアクセスできるようにならないようにしなくてはいけません。また、BIモジュール内のユーザーを、既存のアプリケーション内のデータ権限にリンクさせることで、アプリケーションが持つロウレベルセキュリティを複製する必要があります。

マルチテナント: 既存のアプリケーションにマルチテナントが設定されている場合、クライアントベースをどのようにアナリティクスアプリケーションに複製するのかを検討しなくてはいけません。既存のアプリケーションに導入したマルチテナント設定を、アナリティクスプラットフォームがサポートしていることを確認しましょう。

オンプレミスへの導入: オンプレミスに導入する場合、アナリティクスアプリケーションをサイレントインストーラーとして既存のインストールプロセスにバンドルすることを検討します。これにより、ユーザーをシームレスにアップグレードし、インストールの一部としてパッケージ化されたレポートを提供することができます。

ここまでのステップから分かるように、優れたアナリティクスアプリケーションをデザインするためには、数多くの事項が関係しています。

素晴らしく、達成可能な目標だとしても、始めからうまくいくことは非常に稀です。問題は、デザインに対する意見は人それぞれに異なるため、ここで取れる最善の手段は、あらゆる段階で (まず始めに) 顧客からフィードバックを収集し、(次に) 関係者からフィードバックを得るというプロトタイプのサイクルを繰り返し実施することです。

プロトタイプとベータテストを使用することで、何がうまく機能し、何がうまくいかなかったのかを評価します。ここでは、エンジニアリングのような単一の意見だけでなく、すべての関係者の目的と成功基準を考慮しなくてはいけない点に注意しましょう。

ベータテストは、技術的な検証のためだけに実施するのではありません。ベータテスト実施ユーザーへのインタビューを含め、マーケティングによる評価も重要です。アナリティクスコンテンツが満たそうとしているニーズを再度確認しましょう。エンジニアリングは、顧客から多くを学ぶことができます。ダッシュボードは今でも顧客のニーズに応えているでしょうか。製品にアナリティクスを統合することで、顧客が学んだ驚くべきインサイトとは何だったのでしょうか。ベータテストに参加する最も誠実な顧客を特定したら、彼らのポジティブな経験をリリース時に活かすことを忘れないでください。マーケティング、PR、アナリスト、ソーシャルメディア、その他様々な努力によって、彼らは成功を後押ししてくれるでしょう。

マーケティングのためのベータテストは3つのパートに分けて考えます。

パート1 - 検証: これは、マーケティングによるポジショニングとバリュープロポジションの検証、および新製品の技術的な検証を含みます。ベータフェーズのこのパートは、メッセージを洗練させ、ターゲットユーザーが適切であることを確認し、最終的に製品を日々使用することになるユーザーから検証することができます。これこそ、マーケティングチームが作り上げたハイプを実現するものです。

パート2 - フィードバック: アナリティクスコンテンツが満たそうとしているニーズを再度確認します。エンジニアリングは顧客から多くを学ぶことができます。ダッシュボードは今でも顧客のニーズに応えているでしょうか。製品にアナリティクスを統合することで、顧客が学んだ驚くべきインサイトとは何だったのでしょうか。この貴重な情報を、製品開発チー ムだけでなく、マーケティングチームにも共有しましょう。

パート3 - 参照性: ベータテストに参加する最も誠実な顧客を特定したら、彼らのポジティブな経験をリリース時に活かすことを忘れないでください。すべてのフィードバックを確認し、リリース素材として活用しましょう。様々なマーケティングキャンペーンに膨大な費用をかけることもできますが、顧客からの優れた意見がもたらす価値は、企業の成長にとってかけがえのないものです。マーケティング、PR、ソーシャルメディアなど、様々な活動の原動力になります。

ここで考慮すべき主なポイントは、購入しやすい価格設定にすることです。顧客が理解するのに何時間もかかるような分かりにくい価格モデルほど悪いものはありません。多くの場合、購入者が最初から価格モデルを理解していないときは、内部的に提示をする必要があります。

この新しく優れたアナリティクスアプリケーションを、できるだけ多くの顧客に見てもらいたいと思うでしょうが、価格が高すぎたり、位置付けが悪かったりして、顧客がアナリティクスアプリケーションの追加を選択するのを妨げているとしたらどうでしょうか。実際にアナリティクス機能を見ることがなければ、顧客は得られる価値に気付くことがないため、アドオンとして選択する可能性は極めて低いでしょう。

顧客にアナリティクスの価値を紹介する方法はたくさんあります。無料評価版の試行や、限定された機能範囲内でのプレビューだけを得ることもできます。アナリティクスは、販売用パッケージの一部として、個人または限られたユーザーグループに提供し、人々がその価値を見出し始めたら、組織全体に普及させることもできます。

価格設定をシンプルにすることで、セールスチームは自信を持って製品を販売することができ、顧客も満足するでしょう。ここでの基本的なオプションは以下の通りです。

組み込みアナリティクスソリューションの構築、維持、およびさらなる開発にかかる継続的な投資を常に考慮しましょう。特に、既存のアプリケーションの一部としてコストを包含することを計画している場合は、投資に対する明確なリターンが計画されていることを確認します。コア製品の潜在的な売上がアナリティクスへの投資を相殺するでしょうか。これを無料で提供することで、組織はアナリティクスを費用がかさむだけで収益を生まないアイテムであるとみなし、CFOが将来の開発のために投資を許可しない可能性があることに注意してください。

既存の価格モデルを考慮し、これを新しいアナリティクスアプリケーションにも反映しましょう。既存の強みと、既に顧客が把握し、理解していることに基づきましょう。例えば、既存の価格モデルがフルタイム当量 (FTE) に基づいている場合、サーバーコアやデータ周りに価格モデルを設定すると、販売チームは混乱し、さらに重大なことに、顧客も混乱させてしまうことになります。

価格設定の最重要点は、顧客を混乱させないことです。顧客がどのアプリケーションを使用しているのかを把握しましょう。情報に基づく価格モデルの違いは、顧客が取引の選択肢から排除しかねない交渉ポイントを作ることになります。素晴らしい分析的価値を提供できる機会を、顧客が選択肢から外すのは避けたいはずです。既存顧客は、新規顧客としてアナリティクス製品を彼らの既存アプリケーションに統合することで、同等またはそれ以上の価値を得ることができます。情報に基づく意思決定を行うためにビッグデータを制御することが、今日の勝者を導きます。

製品導入の段階を考慮する場合、使用状況をトラッキングし、ユーザーがいつ次のレベルに移行したかを特定することが不可欠です。ユーザーベースの価格モデルであれば、これは非常に単純なプロセスです。ユーザーが次のレベルの機能を希望する場合、そのユーザーの権限を有効化し、それに合わせて請求額を調整します。

使用状況を監視することで、顧客がアナリティクスアプリケーションをどの程度使用しているのかを把握し、その情報に基づきアクションを起こすことができます。アナリティクスアプリケーションのパワーを理解するために追加でトレーニングが必要でしょうか。彼らは、他のユーザーの参考顧客になり得るパワーユーザーなのでしょうか。どのダッシュボードが使用されており、どれが使用されていないのでしょうか。似たような顧客は、利用していない機能から、よりビジネス利益をもたらす価値を得ているでしょうか。これらの情報は、顧客が製品を最大限に活用するために、どのようなサポートをすればよいかを把握するうえで、非常に重要な知識を提供します。

オーディエンスを理解し、適切なコンテンツを構築するための調査を重ねても、あるレベルのカスタマイズや特別なサポートを必要とする顧客は必ずいます。サポートを提供する場合、まず誰がその作業を行うのかを理解しなくてはいけません。もし、自社でこれを実施する能力がないのであれば、信頼できるビジネスパートナーに、このようなサポートサービスを実行してもらい、組み込みソリューションに対する顧客満足を維持できるようにしていきます。

ユーザーが決して必要としない、または使用しないかもしれない機能で混乱したり、圧倒されたりするのを防ぐために、製品の階層化を検討するのも良いでしょう。さらにこれは、ユーザーがアナリティクスパッケージを購入し、アップグレードや新機能など、それに付属するすべてのものを手に入れたというマインドセットを作り出します。

このステップは、ビジネスに必要な場合にのみ検討してください。例えば、製品の方向性が、顧客が必要なすべての機能にアクセスできることを確認することであり、それが競合製品と比較して有利である場合は、製品層が適切ではないかもしれません。

これがビジネス要件である場合は、ユーザーに基づき製品を階層化することを推奨します。企業レベルに基づきユーザーを階層化するのではなく、以下のような方法が考えられます。

ビジネスアナリティクスを始めたばかりのユーザーもいれば、日々の売上数値やレポートを閲覧するだけのユーザーもいるでしょう。彼らの職務は、積極的な分析課題の追及や、高度なアナリティクスツールの使用を必要としません。彼らは、データの詳細な掘り下げや試行に興味がありません。このような場合は、基本的な閲覧専用のダッシュボードや、限られた機能しか提供できないかもしれません。例えば、営業担当者は月次目標を達成できたかどうか、マーケティング担当者は特定のソーシャルメディアキャンペーンをクリックした人数を確認したいだけかもしれません。

中級ユーザーもまた、閲覧専用のダッシュボードを必要とするかもしれません。しかし、彼らに自信が付いてくると、より多くの機能や、事前に定義されたデータガバナンスルールとガイドラインに基づき、限定的にデータの試行を始めたいと思うかもしれません。例えば、使用率や、サポートコール数、リピート購入や、返品など、様々な変数に基づいて、顧客の満足度を確認したいと考えるかもしれません。

こちらの層は、テクノロジーや分析されるビジネス課題を十分に理解しているパワーユーザー向けです。彼らはアナリティクスの課題を積極的に追求し、アドホッククエリーを実行して、売上の変化やウェブサイトの傾向、全体的なカスタマーエクスペリエンスに紐づく根本原因の理解に注力します。また彼らは、自身のインサイトやアナリティクスを他のユーザーが利用できるように公開するためのプラットフォームとして、ダッシュボードやスコアカードを活用します。ユーザーは、それぞれの役割や自信の程度に応じて、これらの層の間を頻繁に移動します。彼らの継続的な使用を促すためには、彼らの使用パターンを測定し、エクスペリエンスを調整することで、彼らが業務で卓越できる手段が必要になります。

そのためには、マーケティングコミュニケーション、プロダクトマーケティング、セールスマネジメント、セールストレーニングスタッフ、セールスマネジメントの代表者からの全面的なサポートが必要になります。このプロセスは早い時期に開始し、これまでのステップと並行して実施しましょう。その際には、次のような厳しい質問を投げかけます。この新製品に適した販売チャネル (直販部隊、またはパートナーチャネル) はあるでしょうか。既存のチャネルパートナーや直販担当者は、この新製品を販売するために必要な知識を備えているでしょうか。もし不足している場合は、継続的に彼らをトレーニングする準備をしましょう。長期的な機能強化の積み重ねは、大きな製品変更につながる可能性があるため、まずはチャネルの準備が整っていることを確認しましょう。

製品機能が変化したり、製品ラインが成熟・拡大したりすると、販売チャネルの能力を再評価し、販売に適したスキルセットを備えているかどうかを確認する必要があります。これは定期的に見直すべきことですが、特に新製品のリリース時には重要です。ほとんどのリリースは、単なる不具合改修やマイナーチェンジでない限り、少なくともある程度のトレーニングが必要で、より重要な改良や次世代製品の場合には、さらに多くのトレーニングが必要になります。製品の種類を増やす場合や、まったく新しい市場をターゲットにした製品をリリースする場合は、チャネルを完全に再評価することが適切です。このようにチャネルを率直に評価することは、製品リリース計画において最も見落とされがちな要素のひとつであり、現在の販売チャネルが新製品を「販売できない (販売しない)」という失望を招く可能性があります。

製品が変化し、成熟し、拡大するにつれ、販売チャネルが販売に必要な知識やツールを備えているかどうかを、常に評価し続ける必要があります。このようにチャネルを率直に評価することは、製品リリース計画において最も見落とされがちな要素のひとつであり、現在の販売チャネルが新製品を「販売できない」という失望を招く可能性があります。ほとんどのリリースは、単なる不具合改修やマイナーチェンジでない限り、少なくともある程度のトレーニングが必要になります。また、製品の種類を増やす場合や、まったく新しい市場をターゲットにした製品をリリースする場合は、チャネルを完全に見直す必要があるかもしれません。

現在の経済情勢では、企業はコスト抑制に重点を置いており、購買担当者は大規模な支出をする前にCFOの承認を得なければならないことが頻繁にあります。このような状況では、あるテクノロジーと他のテクノロジーとを比較した従来の特徴や機能レビューや競合分析が、そのレベルの経営層には伝わらない可能性があります。

今日、プロバイダーは、自社の製品がどのように顧客の問題を解決し、ビジネスの俊敏性を高めるのに役立つかを示さなくてはいけません。そのためには、機能や特徴の知識に加えて、ソリューションセールス、ペルソナ (購入者のプロフィール作成を含む、顧客セグメンテーションのより深い形態) の使用、ポートフォリオ全体のバリュープロポジションの確実な把握が必要になります。この課題は、間接チャネルが含まれるとさらに複雑化します。それは、チャネルのための販売トレーニングが間接的に行われることが多いためです。そのため、資料は自己完結型で自明でなくてはいけません。

直販するにしても、チャネルを通じて販売するにしても、あるいはこの2つを組み合わせて市場に投入するにしても、この新しい市場の現実の中で競争するために、製品を販売する人々をトレーニングしなくてはいけません。

セールスサポート、プリセールステクニカルサポートチーム、およびプロフェッショナルサービスチームが徹底的にトレーニングを受け、リリースに向けて準備が整っていることを確認します。ベータプログラムを実施している場合は、実際のカスタマーエクスペリエンスや、問題の解決に関する重要なインサイトを得ることができます。また、(チャネルを含む) プリセールスチームや潜在顧客が、評価/デモ部門 (プロトタイプではなく製品部門) を利用でき、簡単にアクセスできることも確認します。これには、彼らをサポートするための、すべてのデモプログラムやスクリプト、付帯資料が含まれます。

製品の導入に関する最高のシナリオをサポートするインフラが整っていることを確認します。予期せぬ需要の高まりに対応する計画はあるでしょうか。システム (ウェブサイト、発注、サポートなど) は、あらゆるシナリオに対応できる堅牢性を備えているでしょうか。SaaS製品を提供している場合、クラウドサービスとサポートの両方に十分な人員を配置し、不具合による中断に対処しているでしょうか。また、インフラプロバイダーによる十分なバックアップや冗長システムを備えているでしょうか。サービスおよびサポートチームは、コンサルティング、評価、ワークショップ、インストール、メンテナンスなどのプロフェッショナルサービスを提供できる体制を整えているでしょうか。製品を成功させ、優れたカスタマーエクスペリエンスを提供できるようにしましょう。

人的サポート: 電話やライブチャットを通して、専門家と話をすることができます。製品のリリース当初は、サポートに関する問い合わせが最も多くなるため、対応できる体制を整えておきましょう。

非人的サポート: ウェブサイトのヘルプや、チュートリアルビデオ、製品ドキュメントやFAQなどを通じて行います。これらのリソースの長所は、いつでも自由に利用できることです。

サポートに関する問い合わせを、社内のより高いレベル、またはBIベンダーにエスカレーションする、シームレスな体制を確保しておきましょう。

サポートに関するすべての問い合わせは、SLA (サービス品質保証) に裏打ちされたものでなくてはいけません。多くの顧客は、問題が発生した時に、合理的な期間内で解決することを企業側から約束されるように、SLAが設定されていることを想定しています。

BIベンダーと連絡を取る方法や頻度を明確に定義しなくてはいけません。サポートに課題が発生した場合には、必ずベンダーにエスカレーションしなくてはいけないため、そのプロセスを両者が理解していることが重要です。

アナリティクスアプリケーションの新規ユーザーをトレーニングする場合、製品の使用率を向上させるために、できる限り簡単にできる方法を検討しなくてはいけません。そのためには、製品に関するトレーニングも可能な限り簡単にする必要があります。顧客にどのようなセルフトレーニングオプションを提供することができるでしょうか。以下は、その一例です。

顧客にトレーニングを行う場合、50%は自社データを使用して構築したコンテンツを使用し、50%はさらなるコンテンツの構築方法をユーザーにトレーニングすることを考慮します。この比率を守ることで、ユーザーがすぐに使用できるコンテンツをトレーニングしてビジネスに迅速な価値を提供するだけでなく、将来的に価値あるインサイトを自ら作成できる能力もバランスよく身につけることができます。

ユーザーによっては、さらに詳細なトレーニングが必要な場合もあることを理解し、リソースを最大限に活用することが重要です。

BIツールだけを販売しているのではないことを覚えておきましょう。市場には数多くの製品があります。そこで、既存アプリケーションと新しく実装されネイティブに組み込まれたアナリティクス機能との間の相乗効果を販売します。新しいツールの価値についてユーザーを教育することの重要性に留意しなければ、ユーザーがツールを使用することを保証できず、製品の価値と信頼を失うことにつながります。

そのため、既存プラットフォームに加えて提供できる付加価値に基づき販売しましょう。データ分析やデータドリブンなインサイトを既存の製品に組み込むことで、具体的なビジネス上のメリットが得られることを強調しましょう。

アナリティクスアプリケーションが組み込まれたプラットフォームのバリュープロポジションを詳細に説明することは、マーケティングメッセージを定義する上で重要なステップです。この段階でバリュープロポジションを正しく理解することで、営業活動やマーケティングコンテンツ、需要の創出をより生産的に行うことができます。メッセージングが顧客のニーズを満たしていることを確認することが重要であるため、ペルソナに対する調査がここで極めて重要になります。

組み込みアナリティクスのバリュープロポジションを定義する際に、最大の差別化要因は以下の通りです。

新製品のブランディングを十分に行うために、すべてのマーケティング素材を準備できたでしょうか。セールスチームは販売活動に必要なすべての資料を入手していますか。以下は、準備を考慮すべきマーケティング素材の一例です。

イベントスポンサー: これは、把握している世界の外側にいるターゲットに到達するための素晴らしい方法です。業界に関連するイベントのスポンサーになることで、その分野の知識を得たいと考えているオーディエンスに、ブランドをアピールすることができます。

ソーシャルメディア: 製品の認知度を高めるのに役立つ素晴らしいツールであるソーシャル メディアチャネルは、ターゲットとするユーザーに到達するために、企業によって益々活用さ れるようになってきています。

もちろん、セールストークを正しく伝えるには、ちょっとした科学的な方法があります。例えば、40%の人は、文字で書かれた情報よりも視覚的な情報に反応をすることを知っていますか。

見込み客に説得力のある形式でバリュープロポジションを提供することは、多くの場合、最大の課題になります。セールスプレゼンテーションは、バリュープロポジションを伝え、アナリティクスアプリケーションが見込み客に最適である理由を実証する最高の機会です。

成功するセールストークには6つの重要な要素があります。この要素は様々な形式で再利用することができ、新製品の認知度を高めるためにメディアへの説明の基盤とすることができます。

セールスサイクルを定義する事で、セールスチームは新しいアナリティクスアプリケーションを顧客に紹介する時期を理解することができます。これは、製品の方向性と、新しいユーザーをターゲットにするのか、それとも既存のユーザーベースをターゲットにするのかに関連します。

間接的なモデルを検討し、パートナーのネットワークを通じて販売する場合、定義したセールスとマーケティングのメッセージングで、パートナーをトレーニングする方法を検討しなくてはいけません。彼らは会社の代表であり、彼らの成功があなたの成功を決定することになるため、パートナーに投資する時間が多ければ多いほど、目標を達成しやすくなります。アプリケーションにアナリティクスを組み込むことは、他の新製品と同様、既存のセールスサイクルとプロセスを根本的に変えることになることを覚えておいてください。セールスチームがこの変化を受け入れる準備が整っているか、必要な情報が提供されているかを確認します。また、ライセンス要件など、必要なすべての情報をBIベンダーから入手しましょう。

チームが製品を販売したら、彼ら (すべてのチャネルパートナーを含む) が、製品の発注や配送のプロセスにおいて、次のアクションを把握しているかを確認しましょう。注文は会計チームに集約されるのでしょうか。それとも、セールスチームが発注書や請求書を発行するのでしょうか。後者の場合、そのプロセスや、規約と条件、問題が発生した場合の選択肢を理解しているかどうかを確認します。セールスチームは、これらすべてを新しい顧客に伝えることができなくてはいけません。

製品リリースの目的は、市場にアナリティクス製品を紹介することであり、多くの場合これには、「リリース」という言葉が最も良く当てはまります。

製品は真空中に存在しませんし、製品リリースも同様です。製品リリ ースを計画する前に、このリリース計画が全体の中でどのように位置付けられるかを理解する必要があります。時期はいつになるでしょうか。リリ ースの規模や形式はどのようになるでしょうか。そして、これらの要素は全体像の中でどのように位置付けられるでしょうか。

この規模かつ重要度のプロジェクトでは、組織とコミットメントが不可欠です。こちらのステップでは、必要なすべての事前情報を収集し、リリースの大まかな目標を明確にして、これらの情報と目標に照らし合わせて販売チャネルを評価し、リリースにおける全社的なコミットメントを確認します。このステップは、経営陣や様々な部門からの情報とともに、リリース責任者が主な責任を負います。最終的には、すべての事前情報とその現状をまとめた準備マトリックス、リリースのタイミングと規模に関する明確な声明、プロジェクトに対する全社的なコミットメントを確認するチームレベルおよび管理レベルの承認となります。

それでは、計画プロセスを開始しましょう。

マーケティングの観点から、測定可能なリリース目標と成功指標の定義からリリース計画を始めましょう。これらは、リリースプロセスを監視し、管理するためのツールとしてだけでなく、将来的なリリースにおける「全社的」な整合性を改善するための、リリース後の幅広いフィードバックとしても重要です。例えば、市場機会を逸した製品リリースの遅れは、リリース 敗の理由としてよく挙げられますが、これがデザイン変更や製造遅延によるものであれば、マーケティングリリースが非常にうまくいったことを覆い隠すかもしれません。

これまでは、リリース責任者が最も積極的な役割を担いながら、すべての事前計画や準備を行ってきました。しかし、ここからは問題の核心である実際のリリース計画の作成に入ります。このステップでは、リリースチームのメンバー全員が積極的に参加し、時には周辺部門にも働きかけます。よくある失敗を避け、凡庸な製品リリースの歴史を繰り返さないためには、このプロセスに全体的なアプローチを取ることを目指します。従来のマーケティング活動からひとつずつタスクをこなしていくのではなく、製品に最も適した要素は何か、リリースを構成する各人が本当に必要としているものは何かを注意深く探ります。こちらのステップは、リリースの規模に応じますが、3 - 6か月程度をかかることが想定されます。

製品のリリース準備が整ったら、次は外部リリースを詳細に計画します。多くの場合、この作業は販売準備と並行して行われます。最終的な製品仕様や、ベータ版試行のフィードバックの結果、洗練された最終的なポジショニングやベネフィット、バリュープロポジションに基づいてリリースメッセージを作成します。

ソフトウェアベンダーとして、製品をリリースするタイミングにはいくつかの戦略的な選択肢が考えられます。また、最終的なリリース計画に影響を与える外的要因や内的要因は複数あります。

まず、リリースの目標を定めることから始めましょう。スケジュール通りにリリースする、予算を遵守する、販売準備を整えるなど、社内に焦点を当てた目標もあれば、顧客の認知度、メディアでの取り上げ、主要なカンファレンスなど、社外に焦点を当てた目標もあります。しかし、リリース時期を決定する主な要因は3つあります。それは、リリースカテゴリー、競合市場や環境などの外的要因、リリースを取り巻く特別な状況などの内的要因です。

リリース目標の優先順位を決め、外部の市場環境の潜在的な影響を特定するのは難しいプロセスですが、タイミングの観点から適切な対応を行えるよう、競合環境を理解しなくてはいけません。タイミングは、製品が「リリース」されたときに単に物流の準備が整っていることよりも複雑です。新製品は既存の製品にどのような影響を及ぼすでしょうか。キャッシュフローは非常に重要です。そのため、タイミングを間違えたり、コミュニケーションを誤ることで、中核となる収益に悪影響を及ぼすことは望ましくありません。

すべてのリリースが同じように実施される訳ではありません。中には、戦略的に重要で、より多くの注意や活動を必要とするものもあります。リリースする製品の戦略的重要性、複雑さ、潜在的な差別化により、スタイルとトーンの大部分が決まります。製品によっては、準備が整えばいつでもリリースできる (例: 軽微な機能強化など) ことが理にかなっている場合もありますが、それを前提にするべきではありません。

リリース時には、外的要因も影響します。競合製品との位置づけはどのようなものになるのでしょうか。この機能強化は、競合の先を行くものになるのでしょうか、それとも、競合に追いつくためのものなのでしょうか。または、競合を凌駕するアーキテクチャーの進歩なのでしょうか。あるいは、広く知られるようになった買収の結果かもしれません。このように、リリースの規模や範囲は、これらの検討事項に影響されます。

外的要因に加え、特別な状況についても検討し、調整をしなくてはいけません。例えば、競合が類似の製品や機能でリリースを先取りしている (または先取りしようとしている)、自社の機能強化が遅れて市場に投入される、自社のリリースと同時に競合がメディアの注目を集めるような重大な発表を行うなどです。市場や競合の大きな発表を避けてリリースのタイミングを計ることが、成功か失敗の分かれ目となります。

上記をすべて考慮し、組み込みアナリティクスガイドの数段落では、製品をとりまくすべての状況を網羅できないことを理解した上で、戦略的な選択肢は以下のようになります。

これらの選択肢を、特定の状況に合わせた組み合わせとして検討することもできます。また、ひとつの地域に絞ってリリースをしたり、地域ごとに異なる戦略を取ったりすることもできます。あるいは、最初は特定の市場や顧客に向けてリリースを行い、状況に合わせてそこから範囲を拡大していくことも可能です。

最初のステップは、ベータ版のリリース時期や、その後の提供範囲の拡大、そしてフィードバックを行うタイミングなど、主要なイベントがいつ行われるかを詳細に示すロールアウトタイムラインを構築することです。

このタイムラインを計画する最善の方法は、ロールアウトを段階的に行い、各ステージ間でユーザーからのフィードバックを得て、製品やプロセスに必要な変更を行う時間を確保することです。

このロールアウトでは、これまでに検討してきた製品リリースのあらゆる側面をテストします。これには、以下のように、組み込みアナリティクスアプリケーションのフィードバックが含まれます。

フィードバックはアナリティクスアプリケーションに対してだけでなく、オンボーディングやトレーニングプロセス、契約交渉など、関連するプロセスについても行わなくてはいけません。

リリース計画では、ユーザーからフィードバックを受けた後に必要な変更を行えるよう、十分な時間を確保することが重要です。変更は少ないに越したことはありませんが、最悪の事態を想定して計画を立てるのがよいでしょう。

ベータ版リリースには、どの顧客を選ぶべきでしょうか。すべての顧客を対象にした完全なリリースをテストしている場合は、すべてを網羅したいと考えるでしょう。そのため、技術的な限界に挑戦したいパワーユーザーと、アナリティクスニーズをあまり持たないライトユーザーの両方を含めることを検討しなくてはいけません。両方の視点を得ることで、全顧客を対象としたリリースの際に完全な視野を持ち、ユーザー全体を網羅できるようになります。

ベータ版のリリースでは、顧客数を少なくすることで、各ユーザーと協力し、フィードバックを受けて、必要な変更を修正する時間を確保しなくてはいけません。

ベータ版を顧客に展開し、製品やプロセスに関するあらゆる問題が解消されたことを確認したら、次のステップとして、段階的なアプローチにより、残りの顧客へリリースを行います。推奨する方法は、残りの顧客を地域別、製品ライン別、またはランダムなグループに分けることです。

しかし、規模や売上で顧客をグループ分けするのは避けた方が良いでしょう。これは、顧客への展開に何か問題が発生した場合に、ビジネスへの潜在的なリスクを高める可能性があるからです。もうひとつ考慮すべきなのは、製品に馴染みのない新規顧客のグループ全体に展開するのを避けることです。これは、サポートチームに課題を生み出します。

このように、グループ分けをした顧客に対して段階的に製品をリリースする場合、どのように連絡を取るかを検討し、新しいアナリティクスアプリケーションで何が期待されるかを伝える必要があります。新しい機能やそのアクセス方法、問題が発生した場合の対処方法、予想されるダウンタイムや契約内容への影響についても伝える必要があります。これは重要なプロセスであるため、顧客との対応は適切な担当者により行われることを確認しましょう。

製品のリリースが成功したかどうかを把握する方法を定義することは、プロジェクトが有意義であったのかどうかを理解するうえで非常に重要です。リリースに先立ち評価指標を設定することは、進捗状況を追跡し、成功を確認するうえで重要なステップです。これらを日々追跡し、この情報を社内の関係者と共有することで、プロジェクトのビジネス的な評価を高めることができます。

リリースにおける評価指標のもうひとつのオプションは、これらのKPIが適切なレベルに達していない場合に検知するアラートを設定することです。アラート検知後、これらの指標が達成されない場合のアクションの方針を決定できます。このようにアラートを設定する利点は、リリース後の段階的なレビューを待つことなく、何か重大な問題が発生した時点で即座にアクションを実行できることです。

プロジェクトマネージャーになることもできるリリースリーダーを選ぶことが有効であり、リリースプロセスを管理して、関連するチーム全体と常に連絡を取り合います。リリース準備の整っていないチームがひとつでもあれば、これをすべての部門に伝えるのがリリースリーダーの仕事です。すべてのチームがリリースに合意し、リリースリーダーが承認した時点でリリースを実施することができます。

この段階では、ビジネス要件を明確にして修正し、分析出力の形式や配信方法を確認します。基礎となるデータに関する問題を解決し、導入のためのソリューション環境を準備します。

導入フェーズでは、ビジネスプロセス内に実用的なソリューションを実装し、継続的な運用、管理、ガバナンスのための環境を整えます。

製品リリースが完了したらリラックスできると思ったら大間違いです!今こそ、リリースした製品やプロセスをどのように改善し続けられるかを考える時です。プロジェクトは目標を達成したでしょうか。この製品をさらに成長させることができるでしょうか。競合はその栄光に安住することなく、常にアナリティクス製品を改善し続けられるよう、その方法を模索していることを認めなくてはいけません。

リリース計画は、リリース後にそのプロセスと効果を総合的に評価することなしに完了しません。リリース後、関連するすべてのKPIから結果を収集します。これらの結果は、マーケティングオートメーションプラットフォームや、ウェブサイトの統計、セールスCRMなど、様々なソースから得ることができます。

測定可能な評価指標を設定しましたが、プロジェクト開始時に設定した目標に対して、どのように追跡したのでしょうか。主要な関係者とともに、機能別にそれぞれの結果を確認します。関係者は、何が成功し、何が成功しなかったのかを全員で把握するために、マーケティングやセールス、運用や開発など、様々な部門の人々で構成します。そして、その知識を次のリリースのバージョン.01に反映させることができます。

より詳細な情報はこちら: PlexureはYellowfinとToustoneの連携により業界トップクラスのア ナリティクスプラットフォームを解放します

より詳細な情報はこちら:  North Tees and Hartlepool NHS Foundation TrustはYellowfin プ レゼントでリアルタイムの患者報告を実現します

Yellowfinを組み込むことで、以下を実現することができます。