オンライン教育製品プロモーションの実践

この記事では、データプロダクトプロモーションの実装方法について紹介します。一緒に見てみましょう。

1. はじめに

データ製品だけでなく、すべてのBサイド製品は実装の有効性の問題に直面します。ここで言及するBサイド製品には、ToBエンタープライズサービスの商用Bサイド製品だけでなく、企業内で構築されたBサイド製品も含まれます。

自社で構築した B サイド製品の実装の難易度は、ユーザーが周囲の同僚であるため比較的低くなりますが、大規模なプラットフォームを自社で構築する場合は、実装チームも必要になります。

エンタープライズ サービスを提供する企業にとって、大規模な実装チームを維持することは避けられません。ファーウェイはすでにエベレストに5G基地局を展開しており、実装に関しては最も優れた企業かもしれない。しかし、すべての企業がファーウェイのような財務力と組織管理の効率性を備えているわけではない。

かつて、オペレーションの同僚からこんなジョークを言われたことがあります。彼の前の会社の上司が Sensors の競合企業 (名前は言いません) を買収することにしたのですが、1 年後には、オペレーション スタッフの誰もシステムのログイン アドレスを知りませんでした。おそらく、そのアドレスを使用していたのは上司だけだったのでしょう。別の観点から見ると、実施効果を最大化するために、当事者 A と当事者 B の両者が協力する必要があり、内部要因が依然として主な要因となる可能性があります。

Sensors 製品機能の利点は、その柔軟性です。growingio や Umeng などの類似製品に比べると、開始が困難です。弁証法的に言えば、これは利点でもあり欠点でもあります。欠点を補うために、センサー実装チームは懸命に取り組んできました。私が見たところ、最前線のアナリスト チームは、問題を報告した人々に操作方法を教えているところでした。ただし、運用スタッフが多すぎて、テキストを確認するように全員に目を通すことはできません。

データ製品が展開された後、それは釣り竿と釣りの方法を与えることに相当しますが、各人の認知と実践能力が異なるため、釣り竿で魚が釣れるかどうかはわかりません。

では、どうすればユーザーが方法とツールを統合し、魚釣りのやり方を本当に教えることができるのでしょうか? この記事では、私自身の実際の経験をまとめ、この行き詰まりを打破しようとします。

この記事も前回の記事の考え方を引き継いでいます。問題を分析する - 解決モデルを提供する - 反復を実践する。この記事では、製品実装の初期段階で直面する問題の分析、実装とプロモーションのアイデア、コアユーザーへのプロモーション方法、標準化された使用メカニズムの確立について説明します。

2. 初期使用時の問題の分析

1. 使用意欲が低い

誰もが仕事の報告をする際にはデータ駆動型の業務について話しますが、実装となると、ほとんどの人は仕事の惰性のために変更を嫌がります。システムを与えて自分で使ってもらうというのは、実は導入段階での作業コストが上がってしまうのです。「始めることから諦めることまで」という言葉を聞いても不思議ではありません。

初期段階では、自主的に利用する人が広告やWebサイトの運用などのチームに集中しており、人数も10人未満でした。これらのチームは、名刺数、登録ユーザー数、PV、UV など、KPI のコア指標のみに焦点を当てています。分析モデルの使用は、イベント分析、ファネル分析、ユーザー属性分析に重点を置いています。

2. 基本的な機能を理解していない

初回の社員研修では非常に熱心に取り組んでいたものの、その後実際に製品を使用しなくなった方々を対象にアンケートを実施したところ、基本的な機能を十分に理解していないどころか、深い理解も得られていないことがわかりました。チュートリアルを読んでも、使い始めるのが難しいと感じた人もいれば、使用中に理解できない問題が見つかったものの、質問するのが恥ずかしかった人もいました。もちろん、使用するには業務が多すぎて、使用する時間がない人もいました。

結局、始めてから諦めるまで、結果は同じです。

3. ビジネスシナリオとの統合が難しい

上記の分析から、初期段階で意識的に使用していた運用担当者も、いくつかの共通分析モデル機能に注目していたことがわかります。また、分析指標も自社のKPIに注目しており、最終的なKPI結果に影響を与える各リンクの指標の分析が不十分で、業務プロセスを整理して定量化する能力が不足していました。

システム機能をいかに巧みに活用し、ビジネスシナリオに適用するかは、まさに難しい問題です。

4. 異なる統計的基準

統計的品質の不一致は、主に 2 つの側面に反映されます。1 つ目は、業務担当者がセンサー分析で確認したデータが社内の業務システムと一致しておらず、ポイント トラッキング エラーが発生していることです (前の記事のポイント トラッキング キャリブレーションのセクションを参照)。

ただし、この記事で取り上げたい状況は人為的なものであり、一部の運用パートナーがアトミック インジケーターとディメンションを十分に理解していないため、異なるシステムでのクエリ中にアトミック インジケーターまたはディメンションの選択が一貫していないという問題があります。

もう 1 つの状況は、同じシステム (すべて Sensors Analysis で照会) 上の同じインジケーター (同じ名前) に対して、異なる人が異なる定義を持っている場合です。

3. 実施と推進のアイデア

上記の分析により、全体的な問題が明確になりましたが、それをどのように解決すればよいでしょうか?早速解決策を見てみましょう。下の図をご覧ください。

1. アルファ作戦

上記の解決策から、Operation Alpha がその中核にあることがわかります。

このアクションには何ら不思議なところはありません。ただ名前がかっこいいだけです。その本質はコアユーザーを育成することです。これについては後の章で説明します。コアユーザーのトレーニングは、使用環境の改善に役立ち、データシステムの使用に関する会社のトレーニングと評価のメカニズムを探求し、それを新入社員のトレーニングシステムに組み込みます。

2. プロモーションと反復

コアユーザートレーニングを数回繰り返した後、予想外のことが起こらなければ、会社のデータ駆動型の運用環境が改善され、コアユーザーの数が増え、需要が自然に増加し、システムが肯定的な反復段階に入ることが促進されます。

3. ガバナンスの推進

コアユーザーが拡大すると、アナリストロール権限を持つ人が増え、イレギュラーな利用が増えます。混乱を避けるために利用プロセスを統制する必要があるため、主要な利用リンクを標準化する必要があります。

4. アルファ作戦

1. アクションの概要

アルファアクションを組織する目的は、コアユーザーグループを育成・拡大し、データ駆動型の運用環境を宣伝・強化し、アクションの複数回の実装と反復中に定期的なトレーニングと評価のメカニズムを確立することです。

Operation Alpha の具体的な実施手順を下図に示します。

1) 行動チームを結成する

行動を開始するには、上級管理職の支援が必要です。上級管理職に権限を与えることで、その行動の正当性が明確になるだけでなく、会社内での影響力と注目度も決まります。

メンバーは次のとおりです。

• スポンサー、製品マネージャー、またはオペレーションマネージャー。
• ビジネスコンサルタントは、会社の業務に精通し、業務運営において業務指導を行う主要人物です。
• テクニカル サポート: ここでのテクニカル サポートとは、システム機能に精通した人を指します。社内の製品マネージャーでもかまいません。もちろん、アナリストを招待できればさらに良いでしょう。
• 参加者: 研修生は、最初の数回のセッションでは、比較的学習能力が高く、新しいことを受け入れられる、成長の可能性がある若者を選ぶことが推奨されます。

2) 実践的な研修コースの開発

コース計画の策定は、会社の業務と組み合わせる必要があり、研修生の実際の仕事内容からテーマを見つける必要があります。これにより、実践的な効果が得られるだけでなく、研修生に余分な作業負荷をかけません。

簡単なものから難しいものまで、2つのテーマを設定することをお勧めします。毎週定期的に会議を開催し、活動を見直し、パターンを要約し、欠点について検討します。推奨期間は3～5週間です。

3) レビューの共有と評価

このセッションはイベントの最後のクライマックスです。全従業員が公開でアクションをレビューして要約し、会社内のすべてのオペレーターを招待して事例、成果、経験を共有します。

レビューと共有の後、優秀な学生が選ばれ、会社のリーダーによって表彰され、社内のニュース宣伝に使用され、データ駆動型業務の概念がさらに強調されました。

2. 小さな行動でもPDCAが必要

Operation Alpha はソフトウェア開発を伴わず、トレーニング活動のみですが、プロジェクト管理の観点からも見て、失敗のリスクを減らすために PDCA プロジェクト管理アプローチを採用する必要があります。結局のところ、イベントを企画するのは簡単ではありません。

1) P（計画）

方針や目標の決定、活動計画の策定などが含まれます。

2) D (Do) 実行

既知の情報に基づいて、具体的な方法、計画、計画レイアウトを設計し、その設計とレイアウトに基づいて、計画の内容を実現するための具体的な操作を実行します。

3) C（チェック）

最終結果をチェックするだけでなく、プロセスを途中でチェックポイントに設定して、問題をタイムリーに検出する必要があります。たとえば、Operation Alpha の実施中、各トピックは約 2 週間続きます。約 1 週間後、グループ内での研修生の進捗状況を尋ね、分析のアイデアが正しいかどうかを確認するためにマインド マップを送信するように依頼します。

4) A（アクション）処理

中間結果を処理し、成功した経験を確認して標準化します。失敗の教訓も要約して注意を払う必要があります。未解決の問題は、解決のために次の PDCA サイクルに提出する必要があります。

上記の 4 つのプロセスは 1 回の実行で完了するのではなく、複数のアクションで何度も繰り返す必要があります。 1 つのアクションが完了すると、いくつかの問題が解決され、未解決の問題が次のアクションで使用されます。このようにして、段階的に前進することができます。

V. 標準化された使用メカニズム

コアユーザーが拡大すると、アナリストロール権限を持つ人が増え、イレギュラーな利用が増えます。混乱を避けるために利用プロセスを統制する必要があるため、主要な利用リンクを標準化する必要があります。

1. ユーザーの階層化と責任と権利の明確な分割

Operation Alpha のトレーニングに参加する人員は、次の責任を持つアナリストの役割に割り当てられます。

• アナリストの役割は、部門内の専任の担当者によって指定される必要があります。
• 部門内でのセンサー システムの使用を担当します (レポートの作成、特定のシナリオ分析)。
• 内部部門システムの使用に関するトレーニング。
• 部門の内部データ指標システムの確立。
• フィードバック要件を要約します。

2. 需要フィードバックプロセス

• フローチャートに示されているように、各部門はアナリストの役割を指定する必要があります。
• 部門内で生成されたデータのニーズは、まずセンサー システムに依存するアナリストによって解決されます。
• アナリストが解決できない要件は、要件カードの形式でデータ プロダクト マネージャーにフィードバックする必要があります。

3. アカウント管理の仕組み

1) アカウント申請の仕組み。社内の特定の役割や担当者に関わるため、詳しく説明するのは不便なので、ここでは簡単に説明します。アナリスト アカウントは割り当てられ、空き数は部門の人員数によって異なります。特別なデータ アナリスト アカウント (権限) を申請する人は、部門リーダー (または VP) の承認を受ける必要があります。

2) 退職する社員に対する権限変更・権限停止の仕組み

3) アカウントの定期的なスクリーニングとクリーニングのメカニズム。非アクティブなアカウントは脆弱性攻撃の標的になりやすいです。センサーシステムには大量のビジネスデータがあり、一度漏洩すると、その影響は想像を絶するほど大きくなります。データセキュリティを考慮して、対応するアカウントの定期的なスクリーニングとクリーニングのメカニズムが確立されています。

• 最近のログイン時間が 30 日を超える通常の許可アカウントはキャンセルされます。
• 最近のログイン時間が 15 日を超えるアナリスト権限アカウントは、一般権限にダウングレードされます。
• 一般的な機能のためにダッシュボードのみを使用するアナリスト アカウントは、通常の権限にダウングレードされます。

4. 統計的品質の標準化

各業務部門の調査結果とAARRRモデルに基づいて、「よく使用される原子指標の統計的口径基準」をまとめ、運用担当者に公開しました。特に初心者にとっては必須のツールです。

スクリーンショットは次のとおりです。

5. 研修と評価の定期化

定期的なトレーニングと評価の仕組みが確立されています。特筆すべきは、このトレーニングと評価の責任者は、オペレーション アルファの第 1 フェーズの優秀な生徒であるということです。

1) トレーニングスケジュール

• 第 1 週: トレーニング + Q&A + 問題のコミュニケーション。
• 第 2 週: 評価 + 最初の採点ラウンド。
• 第 3 週: 2 回目の追試試験 + 最終合格者リストの確認。

2) 評価方法

• 評価方法：完了率（20％）+客観問題のオンラインテスト（30％）+データフォーム作成レポート（50％）。
• 評価基準: 合計 100 ポイント、合格点は 70 ポイントです。データ フォームが提出されない場合、このトレーニング評価ラウンドを放棄したものとみなされ、アカウントは直ちに閉鎖されます。
• 賞罰方式：第 1 ラウンドの評価に不合格になった場合、3 日以内に追試を受けることができます (追試合格条件: 第 2 ラウンドの客観テストのスコアが 80 点以上であり、提出されたデータ フォームが評価後に大きな反復を持っていること)。追試後、このラウンドの脱落者リストが確認され、対応するビジネス ライン マネージャーが xx 日に同期され、アナリスト アカウントが閉鎖されます。

6. 最後に

記事はここで終わりになります。この記事では、私がこれまで推進してきたデータプロダクトの導入・推進の実践プランをまとめて整理し、各リンクを体系的に解説します。各記事では、私の個人的な実践プロセスから始めて、それをオンライン教育ビジネスの背景や当時の客観的な制約と組み合わせて、できるだけ詳しく説明するように努めています。

これまで 3 つの記事で、基盤構築から MVP ソリューション、そして推進と実装まで、エンタープライズ デジタル化への道筋を説明してきました。この記事は、その結節点として機能します。

次回のコンテンツシリーズでは、私が担当している別のマーケティング CRM 製品ラインの観点から、オンライン教育のマーケティングビジネスシナリオと組み合わせて、データがマーケティングビジネスラインにどのように力を与えるかをまとめ、整理したいと思います。

著者: タイガーフー

出典: データ担当者の私有地