包括的なデータ分析システムの構築

今日のデータ主導のビジネス環境では、包括的なデータ分析システムを構築することが企業にとって重要です。この記事では、ビジネス プロセスを概観し、さまざまな部門にまたがってデータ分析作業が企業の意思決定を完全にカバーしてサポートできるようにするために、「垂直と水平」の 2 つの次元からこのようなシステムを構築する方法について詳しく説明します。

今日は、企業レベルのあらゆるシナリオを網羅する、最も包括的なデータ分析システムを紹介します。これを参考にして、どこに重点を置くべきか確認できます。システム全体は、垂直方向が 1 つ、水平方向が 1 つと要約できます。

さっそく本題に入りましょう。

01 垂直：成果の観点から仕事を見る

シンプルだが重要な質問をします。データ分析の用途は何ですか?

回答: ビジネスの観点から見ると、データ分析には6つの主な用途があります

1. 目標設定：定量的な目標を決定し、目標を細分化して配分する
2. トレンド予測: 通常のトレンドを予測し、意思決定の参考資料を提供します
3. プロセス監視: ビジネス開発を監視し、プロセスの問題を発見する
4. 結果レビュー: パフォーマンスをレビューし、結果と経験を要約します
5. 原因分析: 問題の原因を分析し、解決策を探る
6. メソッドテスト: 最適化メソッドをテストし、より良いプラクティスを選択する

（上記の部分を読んで暗記することをお勧めします）

これら 6 つのシナリオはビジネス プロセス全体にわたって実行され、データ分析の価値を最もよく反映します。したがって、データ分析で何ができるかを考えるとき、まずはこの 6 つのシナリオについて考え、現在の作業でニーズがどの程度満たされているかを検討します。他に何ができるでしょうか (以下を参照)?

注意: データは代替不可能なものではありません。ビジネス側は、データがなくてもこれら 6 つのステップを実行できます。

たとえば、典型的なシナリオは次のようになります。

1. 目標設定は上司の指示により財務部門によって行われました。
2. トレンド予測は、リーダーがその場で即座に行います。
3. 結果を検討した結果、事業自体が自らを甘やかしていたことが判明しました。
4. メソッド テストはまったく存在しません (存在すると言いましたが、存在します!)

おそらく、問題発見後のプロセス監視と原因分析のみがデータ分析に残されるでしょう。しかし、この場合、仕事は受動的になりすぎます。目標、基本的なビジネストレンド、方法の背後にあるビジネスロジックを明確に理解していなければ、数字だけを見て理由を分析することは困難です。そのため、多くのデータ部門は個々のデータしか監視できない状態に陥っています。数字だけを言うこともできます。

年初に計画を立てる際には、このような消極的な状況をできるだけ避けるべきです。

今戦わなければ、いつ戦うのですか?

この時点で、次のことが可能です。

1. 大物上司に働きかけ、「全プロセスデータ管理」の概念を浸透させ、業務シナリオを増やします。
2. 業界のデジタル成功事例を組み合わせ、データの価値を広く一般に広め、業務を拡大します。
3. 各部門の作業スタイルを観察し、どの部門との交渉が容易か、どこに協力の機会があるのか​​を確認します。

そのためには、企業内の部門間の分業を注意深く研究する必要がありますが、これには「1 つの水平」という概念が含まれます。

02 1本の水平線: 部門の観点から機会を見る

簡単な質問をしてください: すべての部門がデータを同等に重視していますか?

回答：もちろん違います！

部門の責任の観点から、部門は次の 4 つのカテゴリに分類できます。

1. 経営

代表的な例としては、社長室、戦略開発部、財務部などが挙げられます。これらの部門は、会社の経営陣と直接コミュニケーションを取り、多くの主要な開発計画、年間KPI目標、運用タスクは、これらの部門の参加によって策定されます。これらの部門はデータを非常に真剣に受け止めています。

すべての目標、タスク、計画を定量化する必要があるためです。彼らに共通する問題は、特に財務部門では、事実はわかっていてもその背後にある理由がわかっていないことです。彼は会計がとても得意ですが、ビジネスの詳細についてはあまり知りません。

この時点で、これらの部門と仲良くなりたいのであれば、基礎データを提供することで突破口が開けます。データを提供しながら、主要なビジネス プロセスを整理し、通常のビジネス ベースラインを明確にし、ビジネス理解のギャップを埋めるお手伝いを積極的に行います。これにより、コラボレーションの機会がさらに増えます。 （下図参照）

2. 収入

典型的な例としては、営業部門、配送部門、成長部門などが挙げられます。これらの部門は主な収益業務を担い、業績と利益の主な源泉となります。しかし、これらの部門では一般的にデータを重視しません。タスクの目的と完了率を確認できれば十分です。彼らは、事例分析、運用ガイド、具体的な実践例を見ることを好みます。

つまり、良いものは使えるものなのです。

この時点で、これらの部門と仲良くなりたい場合は、ツールから始めることができます。複雑なレポートを準備するのではなく、閲覧者の興味に基づいて階層的にデータを提供します。草の根レベルが高いほど、表示されるデータが少なくなるため、主要な KPI のみを保持するのが最適です。機能面ではCRMなどのツールと連携し、データを提供しながら直接的にアクション可能な機能を提供しているため、現場のユーザーに人気があります（下図参照）。

3. コストタイプ

代表的な例としては、調達、研究開発、設計などが挙げられます。これらの部門は基本的にコストを消費しており、直接的な成果を見ることは困難です。これらがうまくできていないと、ユーザーからの反感を招き、製品のバックログや在庫不足を引き起こし、売上にも影響を及ぼします...しかも、これらの部門は営業やマーケティングの影響を受けるため、免れることは困難です。

現時点では、次のように異なる扱いをする必要があります。

調達、生産、供給など、ハード損失が発生しやすい部門では、ローリング データ予測とデータ監視に重点が置かれます。上流の供給、下流の需要、プロモーション活動などから影響要因をタイムリーに収集し、供給の進捗と在庫状況を組み合わせ、バックログ/在庫切れの問題が発生する可能性を予測します（下図参照）。

ソフトロスが発生しやすい研究開発、設計、製品などの部門では、テスト プラットフォームとテスト サービスに重点を置くのが最適です。定期的な監視を使用して問題を特定し、適切なテストを使用して改善効果を確認します (以下に示すように)。

4. ハイブリッド

典型的な例としては、マーケティング部門や運用部門が挙げられます。これらの部門はデータを見るのが好きで、その作業結果が売上に重ね合わされているため、観察が困難になっています。そのため、分析を行うことは特に困難です。幸いなことに、彼らの仕事はほとんどがプロジェクトベースなので、一つずつ取り組むことができます。

一般的なプロジェクトには次のようなものがあります:

• 大プロモーション
• ユーザーインサイト
• ブランドコミュニケーション
• コミュニティ運営

これらは以前の記事で何度も共有されているので、ここでは繰り返しません。深い洞察を得て徹底的な分析を行いたい場合、ビジネス部門で良い習慣を養い、強固なデータ基盤を築くことが重要です。例えば：

1. ユーザー タグ、製品タグ、コンテンツ タグ、チャネル タグなどのタグ ライブラリを改善および維持します。
2. 活動ラベルと分類情報の管理、活動評価基準の記録、事前参照グループの設計。
3. コミュニティ運営、ニューメディア運営、ショート動画販売、ライブストリーミング販売に関する基礎データ収集

基本的な作業が完了すると、その後は大量のデータを分析できるようになります。

基礎作業がしっかりできていないと、事後分析しても意味がありません...

03 全体計画：段階的プロジェクトとベンチマークプロジェクト

注: 上記の作業には、ビジネス部門内での優先順位があります。

1. 一般的に、1 月、2 月、3 月が年間計画を立てる月です。
2. 上半期は、新たな人材を採用し、チームを編成し、小規模なパイロットプロジェクトを実施しました。
3. 主要なプロモーションやフェスティバルは下半期に集中している

ビジネス部門の行動を明確にした後、データ部門の全体的な配置は非常に明確になります。

1. 年初は、予測、目標設定、システム構築といった基礎的な業務に重点を置きました。
2. 上半期は基礎力強化を優先し、基礎データ、テストプラットフォーム、ラベルライブラリなどのツールを可能な限り強化していきます。
3. 下半期は主要プロジェクトに注力し、プロジェクトのサポート、監視とレビュー、ユーザーインサイトの提供などを行っていきます。

出力目標は、毎月プロジェクトを開始/更新することです。こうすることで、四半期ごとに四半期レポートを書くのが簡単になり、翌年の年次概要について心配する必要がなくなります（下図参照）。

以上がデータ部門計画の全体的な考え方です。もちろん、それぞれの事業の具体的な状況は異なります。学生は自分の特定の状況に応じて計画をカスタマイズし、調整することができます。