製品運用システム（0から1まで、計画から実装まで、この記事ではステップバイステップで説明します）

指標管理システムを0から1まで、計画から実装まで、この記事ではステップバイステップで説明します

指標管理を適切に行うために、企業は指標管理システムを導入して問題を解決しようとするかもしれませんが、実際には、指標管理を適切に行うことは想像するほど簡単ではないかもしれません。事前に避けなければならない落とし穴はたくさんあります。この記事では著者が解釈をしているので、見てみましょう。

企業のビジネスが急速に発展し、データの活用が重視される時代に、適切なシステムがなければ、必ず以下のような問題に徐々に直面することになります。

1. 何があるのか​​分からない: 企業のデータ資産は数多くありますが、適切なデータを把握して見つけることは困難です。
2. ニーズの満足が遅い: 自分が何を望み、何を探しているのかを把握すると、会社のビジネスが急速に変化しており、要求が多く、データを取得するための人材が不足していることがわかります。
3. 指標が整合されていない: データの変更が速く、変更記録がタイムリーではなく、データ ソース、データ処理担当者、キャリバーが多く、データの複数のコピーが整合されていません。
4. トラブルシューティングが遅い: システム データに問題があり、データ処理チェーンが長く、人員の入れ替わりや引き継ぎがあるため、問題のトラブルシューティングが遅く、修復に長い時間がかかります。

データの問題を発見し、その場所を特定し、その問題を解決することは、多くの場合、草の根レベルの従業員にとって大きな負担となります (草の根レベルで働いたことがある人なら、それはまさに天と地に向かって助けを求めて叫んでいるのに誰も助けてくれないようなものです)。 1000マイルのダムが一つの蟻の穴によって破壊される。一見重要ではないように見えるこれらの小さな問題は、徐々に蓄積されて大きな問題となり、組織全体の日常業務、戦術目標の達成、戦略的ビジョンの実現に深刻な影響を及ぼす可能性があります。後方生産性と需要が深刻に不一致であり、非技術的な管理とリーダーシップが問題の深刻さを感じ取ることができれば、トップからボトムまで、積極的な最適化とガバナンスのプロジェクトを開始することができます。

このような企業情報のアップグレードは、広い意味では、データガバナンスとデジタル変革への道であると言えます。一般的に言えば、誰もが効率的でインテリジェントなデータ ミドル プラットフォームの構築について話し合っており、データ ガバナンスも議題に上がる可能性があります。データガバナンスの中核は何ですか?核となるのは、データのキャリバーを統一することです。データ品質の鍵となるのは[指標]です。

製品の観点から見ると、指標管理の最終的な目標は、誰にとってもわかりやすく、使いやすくすることです。

[指標システムを構築する方法]については、市場には多くの方法論があります。相対的に、指標管理システムの構築方法について言及している方法は少ないです。しかし、辛抱強く探せば、大手メーカーの競合製品が見つかるはずですし、ドキュメントも比較的充実しています。この参照情報を入手したら、機能とインターフェースの相互作用は簡単にコピーできるため、システムの 80% が実装され、必要なのはシステムの開発を支援するエンジニアだけです。

しかし、実際には、指標管理システムをうまく運用するのは簡単ではありません。システムが構築され、指標管理が実施された後、特にビジネスがすでに発展している場合は、さらに多くの問題が発生する可能性があるからです。

古い製品で故障経験も多いので、些細な経験をいくつかシェアします。

まず、問題を特定する必要があります。

このシステムがどのような問題を解決しようとしているのか、そして現在の状況はどうなっているのかを把握する必要があります。指標管理と指標ガバナンスを推進しているのは誰ですか?

多くの場合、この問題を推進するのは、研究開発やデータ分析のバックグラウンドを持つリーダーですが、これらのリーダーは、これをどのように計画すればよいのかあまり明確ではありません。おそらく、他の同僚による共有セッションを見て、そのケースのストーリーに納得したため、事前にこの件を計画し始めました。しかし、問題を解決するためのシステムを計画する前に、問題は実際に特定されていますか?問題がいかに深刻で、現在の損失がいかに大きいかを定量的に説明するのは簡単ではないかもしれませんが、定性的な説明をした人はいますか?

この問題に対する指導部はどのように理解していますか?理解がなければ、どんな問題を解決する必要がありますか?これらの質問は、あなたにこの作業を任せた人に尋ねることができます。この問題がより高いレベルで認知を広げることができるかどうか、問題を解決するためにどれだけの時間枠とリソースを獲得できるか。

不死であることは良いことだと誰もが知っていますが、名声と富を忘れることはできません。 「データガバナンスをしっかり行い、指標を科学的に管理し、データを使ってビジネスを推進します。」誰もが、やった後に利益を得るためにスローガンを叫びますが、実際にそれを実行できる人は多くありません。多くの場合、私たちはあえて質問したり問題を提起したりしません。私たちは組織から求められたことは何でもやるだけです。これらの問題が明らかにされず、私たちがその価値や重要性を知らずに物事を始めたら、結局、私たちが問題を解決することの価値を誰が認識するのでしょうか?

次に、ハンドルが必要です。

最初の問題定義と価値に関する質問が終わったら、開始する準備は完了です。本当に実行したいのであれば、全体の状況から始めて、一歩踏み出し、数歩先まで考えなければなりません。アジャイル反復方式で実行する場合、最初のバージョンの MVP はどのようなものになるか、どのような問題シナリオに対してどのようなコンテンツを提供する必要があるか、ユーザーはどのようなアプリケーションを作成できるかなどについて考える必要があります。このシステムの価値はどのように反映されるべきでしょうか?

コンテンツレベルでは、どの指標を管理範囲に含めるべきか、また、これらの指標をどのように使用するかを検討する必要があります。指標データはどこから来るのでしょうか?アプリケーションレベルでは、アプリケーションシナリオは何ですか?指標の口径だけを見るべきか、それとも指標データをすぐに入手すべきか?価値レベルでは、これらの指標が実際にビジネスで使用されているかどうかをどのように判断するのでしょうか?ユーザーは何回クエリを実行し、いくつのレポートが作成されましたか?私たちが持っている情報に確信を持つ必要があります。現在、どのような情報がありますか?たとえば、どの指標がダッシュボードに作成され、どの指標が作成されていないのでしょうか?次に、他にどのような情報を知りたいですか?将来についても考慮する必要があります。戦略レベルで会社が展開しているその他の事業は何ですか?全体的な状況はどうですか?指標分析は必要ですか?これについては、事業状況に基づいて大まかな見積もりしか出すことができません。

一般的に、行動を起こす前に 1 ～ 3 日かけて詳細な情報を収集し、戦略を立て、慎重に検討した上で行動します。

データ プロダクト マネージャーは、データの結果とそのプレゼンテーションに関心があるものの、テクノロジーを理解していなかったり、テクノロジーについて気にかける時間がないビジネス関係者に対応する必要があります。 99% の人々、特にビジネスに携わる人々は、データがどこから来るのか、データがどのように処理されるのかに注意を払っていません。彼らはデータの結果だけに注目します。結果を取得する際に問題が発生した場合、技術スタッフに直接問題を投げかけて解決します。

オンラインフォームではもはや会社の管理ニーズを満たせないことがわかり、指標管理システムの計画を開始しました。いくつかのことを行う必要があります:

1. ビジネスニーズに関する洞察を得て、ユーザーの習慣をターゲットにし、システムの価値を明確にします。
2. 組織の管理要件を理解し、人間とコンピュータの相互作用と基盤となるデータ システムを設計します。
3. 技術担当者と調整し、需要シナリオを伝え、システム構築を完了します。
4. ビジネスシナリオ、業務、推進体制に着目し、最終的にビジネスに活かします。

ここで注意点があります。MVP段階では、追加、削除、変更、確認のためのバックグラウンド管理を行う必要さえありません。データを初期化する、つまりデータをバッチで直接データベースに入力するだけです。なぜなら、MVP の段階では、非常に完成度の高い管理背景を作ることよりも、まずデータを使えるようにすることの方が重要だからです。

2 つのモジュールの下で、システムはビジネス アプリケーションの機能とバックグラウンド管理の機能の 2 つのモジュールに分けられます。

コアには 2 つの部分が含まれます。

インデックス データの取得とインデックス クエリは相互に因果関係があります。データを取得したい場合は、指標が何であるかを知る必要があります。指標が何であるかがわかれば、データを取得する方法がわかります。

初期段階では、ビジネスが単純な場合は、複雑なビジネスドメインやデータドメインを考慮する必要はありません。指標システムを考慮する必要はありません。実際、データアナリストやデータ開発者に SQL テンプレートの作成を依頼できるため、指標データ取得システムを構築する必要はまったくありません。さまざまな状況で、入力条件パラメータを変更して実行するだけです。組織内の人数が一定レベルに達すると、R&D 担当者はビジネスのさまざまな複雑なデータ ニーズに迅速に対応できなくなります。ある程度の再利用性が得られると、組織構造が分割され始め、データの権限も分割され始めます。指標データ収集は、SOP ベースのデータ要求処理の自動化プロセスです。

次の 5 つのモジュールが含まれています。

1. 原子指標管理。
2. デリバティブ/複合指数管理;
3. ディメンション管理。
4. 修飾子と修飾子タイプの管理。
5. ビジネスドメインとデータドメインの管理。

指標システムと業務に基づいて構築されたデータ ウェアハウス テーブルは切り離せないため、ポイント 3 と 5 はデータ ウェアハウス モデリングと組み合わせて使用​​できます。繰り返しになりますが、複雑な業務がなく、業務、技術、運用保守の各レベルから統一的に管理する必要がある指標が多数存在しない場合は、指標管理システムを構築する必要はありません。

1) インデックスデータの収集

①指標データ収集シナリオの分析

次の 2 つのシナリオのうち、指標データ抽出を使用して解決する方が適切なのはどちらですか?

シナリオ A: 製品に新しい機能が設計されており、この新しい機能の露出クリック、コンバージョン効果などのデータを確認したいと考えています。

シナリオ B: 運営者はプラットフォーム上で生放送を行う新しいアンカーを募集しており、このアンカーと生放送室のさまざまな状況を確認したいと考えています。

個人的にはBの方が適していると思います。シナリオ A の場合、機能計画段階から追跡ポイントを計画し、オンラインになった後にポイントやイベントを通じて指標を確認できます。機能イベント分析シナリオの場合、一般的に、指標は人数、回数、比率など比較的固定されています。

指標データの抽出は、完全にセルフサービスの探索的分析とは異なります。これは固定された指標ターゲットを持つようなものですが、特定のディメンション変数を変更するだけで、より広い範囲の指標をカバーできます（埋め込みポイントの指標やビジネス統計指標から取得できます）。

②指標獲得プロセスの分析

ビジネスで次のような要件が上がったとき：xxx 生放送ルームのアクティビティ、DAU、新規ユーザー、アクティブユーザーを確認したい。データを取得するための一般的なプロセスは何ですか?

a.インジケーターのスコープ（ディメンション、修飾子）を確認する

たとえば、ビジネスパーソンが「DAU を確認したい」と言った場合、データ アナリストは「それはプラットフォーム全体のものですか、それとも各エンドのものです」と尋ねます。 （WEBとモバイル）。企業が新規ユーザーの数を確認したい場合、データアナリストは実際の状況に基づいてフィードバックを提供します。現在の新規ユーザーには情報フロー（TikTok、Kuaishouなど）、非情報フロー（携帯電話メーカーのアプリストア）が含まれ、どのチャネルが接続されていないか、新しいチャネルの場合は、チャネルがデータを送り返すのを待ってから確認する必要があります。最初のステップは、インジケーターのスコープ（通常はディメンションと修飾子）を確認することです。

b.データの適時性と範囲を確認する

口径が確認された後、データの適時性を確認する必要があります (リアルタイムかオフラインか? オフラインのレベルはどのくらいか、時間、日、週?)。さらに、データの時間範囲が過去 1 日間、過去 7 日間、過去 30 日間、または現在までの履歴期間であるかどうかを確認するために、期間を確認する必要があります。

紀元前結果の伝達とデータの提示方法を確認する

データを確認したら、次はそれをどう届けるかです。たとえば、毎日または毎週上司に報告するために、データを手動で抽出して Excel にエクスポートする必要がありますか。それとも、自動的に更新されるデータを含むダッシュボードを作成したり、ユーザー入力パラメータをサポートするデータ抽出テンプレートを作成したりするなど、自動化されたセルフサービス表示をサポートする必要がありますか。

② 指標データの製品化

一般的に、データ担当者がデータ ウェアハウスのベース テーブル、ディメンション、および修飾子を構築すると、セルフサービス インジケーター データの取得を実行し、それを体系化して製品化できるようになります。相互作用プロセスは次のように表すことができます。

企業はさまざまなディメンション、修飾子、期間を組み合わせて、独自のクエリ条件を設定できます。指標データ取得のコア機能: ユーザーがディメンションに基づいて指標を選択し、即時クエリを実行し、指標の結果をダウンロードすることをサポートします。バックエンド システムで必要なのは、これらのユーザーの対応するディメンション、修飾子、および期間の使用権を管理することです。

指標を選択するためのインターフェースは次のように参照できます。

ディメンションとインジケーターを選択した後、データ取得インターフェイスでクエリをクリックしてデータを取得できます。

指標抽出の出力結果は次のとおりです。

BI システムと連携して、さまざまな相関分析をサポートできればさらに良いでしょう。たとえば、特定の指標に対して折れ線グラフや棒グラフを作成できます。トレンド予測などの自動分析機能も追加できればさらに良いでしょう。

比較インジケーターとラベルから数値を取得する原理は同じです。ただし、ラベルカウントの結果はすべて人数です。このグループの人々についてさらに詳細な分析を行う必要があります（これについては後で詳しく説明します）

2) インデックスクエリ

インデックスクエリは、ショッピングモールの案内デスクとして理解できます。

大きなショッピングモールに到着すると、目的の店舗がどこにあるのか分からないことがあります。目が回ってしまったら、ガイドさんが目的の店舗が何階でどの方向にあるか（左折、右折、直進、東南西北は言わない）を教えてくれます。

インジケーター クエリについても同様であり、次のシナリオで役立ちます。

• 混乱している場合は、現在システム内にどのような指標があり、誰がその責任者であるかをお伝えします。
• インジケータ権限がない場合、システムからフィードバックされたインジケータ担当者情報に基づいて、IM システムを通じて対応する連絡先を見つけることができます。
• データに問題があったり、指標にエラーがあったり、システム障害があったりした場合は、調査する担当者を見つけることができます。

例えば、過去 1 日間の視聴時間のインジケーターを見ると、この時間の単位は何でしょうか?インジケータ名に表示されない場合は、インジケータの詳細から時間、分、秒のいずれであるかを確認できます。

例えば、一人当たりの平均視聴時間の分子と分母は何でしょうか?分子は視聴時間なので、分母は過去 1 日間にプラットフォーム上でアクティブだったすべてのユーザー、または視聴したユーザー、あるいは実際に視聴したユーザーでしょうか?これにも説明が必要です。

たとえば、ユーザーがデータ マップ内のインジケーターをすばやくクエリできるようにすることができます。

もちろん、データ取得インターフェース上で必要な情報を直接表示してプロンプトすることもできるので、別のインターフェースでクエリを実行する必要はありません。

ビジネスにおいては、システムがシンプルであればあるほど良く、また、ジャンプする必要のあるページ数が少ないほど良いです。 NLP システムを組み合わせて、企業で使用されるビジネス言語を技術言語に変換し、データを取得することもできます。

例えば、元夢星の最近の生放送の状況を知りたいです。どのようなディメンションとインジケーターがあるのか​​教えてください。そして、データを直接取得し、結果を Excel 形式で提供できるように支援してください。その後、システムはクエリ操作を自動的に決定して実行し、Excel 形式で提供します。

しかし、システムの基盤となるデータが適切に管理されておらず、事例が蓄積されていない場合には、実現は困難です。さらに重要なのは、中規模企業向けのモデルを実装することで得られる収益が投資コストをカバーできるかどうかです。

ビジネスアプリケーションの機能を設計した後、管理とサポートのためのバックエンド機能を検討します。

まず自分自身に質問してください。MVP 段階では複雑な管理機能が必要ですか?どのようなデータサポートが必要ですか?この質問に答えるには、ある程度の技術的な背景が必要ですが、テクノロジーを理解していなくても大丈夫です。

まず、指標がデータを取得できるようにするには、データ ソースが必要です。第二に、業務担当者が設定したさまざまなデータ収集条件を、データソースからデータを取得するための言語（データ収集スクリプト）に変換することが必要になる場合があります。

ここで必要なのは、特定のテーブル データ(データ ソース) と、データ取得構成を説明するもの(データ取得スクリプトを生成するロジック) の 2 つです。これら 2 つの項目は、コード内で事前に設定しておけば、管理機能がなくても、インターフェース上でのユーザーの操作によって結果を得ることができます。設計機能により、基礎となるテーブル、インジケーター、ディメンション、修飾子、その他の情報が複雑になった場合でも、クエリと管理が容易になります。

次に、どのような機能が必要なのか見ていきましょう。

1) 原子指標管理

ここでは、アトミック インジケーターがソース ファクト テーブルを指定する必要があるかどうかに基づいて、2 つのアプローチを区別できます。この点はさておき、まずは公的な部分についてお話ししましょう。

原子指標を説明するには、指標の中国語名、英語名、単位、指標のビジネス上の意味、およびビジネスの担当者をユーザーに伝える必要があります。さらに、ビジネスドメイン、サブジェクトドメイン、ビジネスプロセス、データドメインなどの指標を分類することもできます。（細かく分けすぎると、実際にはかなり見つけにくくなるので、あまり細かく分けることはお勧めしません）

次に、2つの異なるアプローチについてお話ししましょう。

まず、アトミック インジケーターはソース ファクト テーブルを指定します。

ここで重要なのは、データ ウェアハウス内のどのファクト テーブルのどのフィールドに基づいてどのような計算を実行し、最終結果を得るかというインジケーター フィールドを指定することです。

2 番目に、アトミック インジケーターはソース ファクト テーブルを指定しません。

アトミック インジケーターはテーブル間の関係を記録せず、共通部分のみを記録します。インジケーターとテーブル間のバインディング関係は、派生インジケーターで設定されます。

次の図は、新しく追加されたアトミック インジケーターを示しています。

2) デリバティブ/複合指標管理

それに応じて、管理方法も 2 つあります。式を覚えておいてください:派生指標 = 次元 + 修飾子 + 期間 + アトミック指標

最初のもの。アトミック ポインターを介してテーブル関係をバインドします。デリバティブ指標の核となるのは、次元、修飾語、期間、その他の情報を追加することである。

2番目。

ここでの管理の中核は、特定のファクト テーブルのいくつかのフィールドと、それらがどの派生/複合指標に対応するかを記録することです。

依存関係があるため、派生指標では指標間の血縁関係がわかり、可視化することができます。

指標管理の概要:

実際、どの方法を使用する場合でも、重要なのは、どのテーブルのどのフィールドからインジケーターを取得するか、つまりインジケーターとテーブルの関係をシステムに伝えることです。この情報を記録することによってのみ、将来この論理関係に基づいてデータ取得スクリプトを生成できるようになります。

これは、前の記事で述べたことと一致します。つまり、表には原子インジケーターがありません。アトミック インジケーターは、インジケーターを定義する最も基本的なビジネスの意味とデータ収集方法にすぎません。ファクト テーブルが指定されている場合でも、テクニカル セマンティクス (いわゆる SQL ベースの計算方法の定義) に基づくインジケーターのスコープのみが定義されます。

3) ディメンション管理

ディメンション管理の中核は、ディメンション ロジックと特定のディメンション物理テーブルをマッピングすることです。

たとえば、データ ウェアハウスの最下層にはさまざまなカテゴリが構築されており、対応するディメンション テーブルがあります。次に、カテゴリディメンション（またはファクトテーブルのディメンション属性フィールド）を入力します。

ユーザーがさまざまなパーティションのライブ ブロードキャスト データを表示する場合、カテゴリの視聴時間などのパーティション ディメンションの下のインジケーターを選択すると、データ抽出スクリプトが最終的に生成されるときに、ディメンション属性フィールドがグループ化フィールドに配置されます。

たとえば、最終スクリーニング中に、企業は Honor of Kings と Dream Star という 2 つのゲームを選択し (ディメンションの値の範囲を決定することに相当)、where 一致条件にマッチャー (たとえば、tag_id = 1 または 2) を追加しました。

したがって、最終結果は次のとおりです。

派生インジケーター = ディメンション + 期間 + 修飾子 + アトミック インジケーター。

次に、派生インジケーターを構築した後、オプションの派生インジケーターをディメンションを通じて逆にフィルタリングできます。

4) 修飾子と修飾子タイプの管理

この部分は、修飾語と修飾語タイプの追加、削除、変更、およびクエリを含む語彙管理に相当し、派生/複合指標を構築する際の関連付けに使用されます。ライブストリーミングの一般的な修飾子には、有効な視聴、有効な放送、ギフトフロー消費量内のギフトフローが含まれます。

5) ビジネスドメインとデータドメインの管理

この部分は語彙管理、ビジネスドメインやデータドメインの追加、削除、変更、確認にも相当し、指標の分類にも使用されます。

たとえば、ユーザーがフィルタリングを行う場合、まずビジネスを大まかに区分し、次にディメンションと指標を探します。

ここまで読んでくると、複雑な気持ちになりますよね？複雑なものを単純化します。ここでは、修飾子、ビジネス ドメイン、データ ドメインについては脇に置いて、インジケーターとディメンションのみに焦点を当てましょう。インジケータ管理をSQL（構造化クエリ言語）の観点から再理解することをお勧めします。

データ プロダクト マネージャーが何らかのテクノロジーを理解する必要があるのはなぜですか?鍵となるのは、 SQL をある程度理解することだと思います。 SQL を理解することによってのみ、SQL (物理モデル言語) の観点からこれらすべてを理解することができます。

実際のところ、SQL を深く理解する必要はありません。最も単純なコードを理解すれば十分です。次の文を見てみましょう。これは、2023 年 12 月 12 日のさまざまな支払いタイプの注文数を数えることを意味します。

支払い方法が WeChat と Alipay の 2 つある場合、最終的な表は次のようになります。

SQL を読んだ後、さらにいくつか質問してみましょう。

SQL におけるディメンションとは何ですか?どこ？ディメンションは、対応するグループ化フィールドです。このフィールドは、ファクト テーブルの主キーから取得することも、ファクト テーブルをディメンション テーブルに関連付けることによって取得されたディメンション テーブルのフィールドにすることもできます。

インジケーターとは何ですか?どこ？ count(order_id)ですか？いいえ、クエリ システムに count(order_id) のみを入力した場合、システムは結果を実行しません。テーブル、テーブル取得の時間範囲（期間）、および指定したディメンションを指定した場合にのみ結果を取得できます。時間範囲を指定しない場合は、テーブルの全範囲（つまり、テーブルが作成された日からのすべてのデータ）になります。ディメンションが指定されていない場合は、完全なディメンション（つまり、すべての注文の合計数）になります。

今の結果表から数字を取得したらどうなるでしょうか?インジケーターとは何ですか?

count(order_id) を定義する必要はありません。SQL は次のように記述できます。

このため、指標は 2 つの方法で管理できます。どちらにしても、最終的に生成された SQL が物理テーブルから正しい結果を取得できれば、問題ありません。 SQL がデータを取得し、インジケーターを記述する方法を理解すると、いわゆるアトミック インジケーター管理、派生インジケーター管理、およびディメンション管理を構築する必要がある理由がわかります。

前述したように、シナリオとユーザーのニーズに基づいて最小限の実行可能な製品を初期化する MVP が必要です。価値を迅速に生み出すために、最初のバージョンの多くの側面はシンプルになっています。しかし、諦めることで得られるものを常に覚えておかなければなりません。

このシステムは、ビジネス要件とレポート開発のこれまでのプロセスを体系化し、プロセス情報（つまり、インジケーター、ディメンション、ファクト テーブルなどのオブジェクトのメタデータ）を記録することと同じです。この管理システムとそれに対応するシステム構築が完了すると、日常的な運用とメンテナンスのみが必要になります。

製品機能が立ち上がると、計画、実行、確認、改善という新しい PDCA サイクルが始まります。システムのコンテンツ (データ資産) をさらに充実できるだけでなく、インタラクションやユーザー ガイダンスの面でもやるべき作業が数多くあります。

もちろん、コンテンツや機能に関する問題にも直面することになります。

例えば、ビジネス側としては、指標を取得する際に新たな指標を追加してもらえることを期待しています。全体的な指標システムが充実するまで、新しい基礎テーブルの開発と指標データの入力が必要になります。例えば、指標が多すぎて、ユーザーが指標を検索したり照会したりするのが不便な場合は、必要な指標の分類、説明文書、操作手順書を作成する必要があります。

たとえば、会社の計画上の理由により、一部のビジネスが停滞し、一部のデータが不要になった場合などです。企業が厳格なコスト管理を行っている場合は、データの実際の適用から始めて、指標システム、データ ウェアハウス テーブル系統などに基づいて、使用されなくなったレポートとそのスケジュール タスク システム全体をオフラインにすることができます。ストレージとコンピューティングのコストを節約するため。

全体として、このシステムが完成すれば、標準化されたデータの収集と表示に関する問題の 50% 以上が解決されるはずです。特定のシナリオの分析には依然として人間のサポートが必要です。人工知能は、知的になる前に人工的なものでなければなりません。

もちろん、解決すべき問題は無限にあり、満たすべき人間のニーズも無限にあります。

計画上の考慮事項から機能計画および実装まで、指標管理の概要を大まかに説明するために多くのことが紹介されています。

しかし、指標管理を実践できる企業は、すべて選ばれる企業だということを改めて認識しておきたいと思います。優秀な人材を集め、時代の発展に合わせて、技術革新と経営革新を基盤に、幾多の試練を乗り越え、数々の困難の中でも大きな取引量を誇る企業へと成長してきました。彼らは本物のビッグデータを保有しており、その価値を実現するためにデータを真に活用しています。これらの障壁を一つでも作ることができなければ、いわゆるデータ駆動型ビジネスの段階には到達できないでしょう。

物理的なビジネスを運営するほとんどの企業にとって、科学的な指標管理はビジネス開発の推進力となります。データの開発とそれに対応するデータ管理システムは、強力なビジネスサポートから切り離すことはできません。ただやるだけのためにやってはいけません。管理指標の目的は、データをより良く表示するだけでなく、より適切な意思決定を行い、より良いビジネス成果を得ることです。

生成 AI が本格化する中、AI を活用してさらに多くのことを実現できるでしょうか?

どのようなシナリオで AI を既存のワークフローに組み込むことで、現在のワークフローを改善し、より詳細な実装を実現できますか?例えば、企業側がデータを見た後、音声やテキストを使ってAIに直接指示を送り、過去30日間にプラットフォームで消費していないユーザーに30元以上の購入で5元割引の消費者バウチャー通知を送るよう依頼し、統計タスクを自動的に生成し、1時間以内に送信された通知の数、クリック数、使用された消費者バウチャーの数、生成された取引額に関するフィードバックを返すことができます。

依然として人が主導的な役割を果たしますが、データに基づいて意思決定、行動、データの回復を行うという全体的なチェーンはより効率的になります。道は長く、障害も長い〜

それだけです。読んでくれてありがとう〜

コラムニスト

Lee、パブリックアカウント: データ製品 Xiaolee、『Everyone is a Product Manager』のコラムニスト。ライブ放送、短編動画、エンターテイメントに重点を置き、データアーキテクチャ、CDP、データガバナンス関連の作業が得意です。

この記事はもともと「Everyone is a Product Manager」に掲載されました。無断転載禁止

タイトル画像はCC0プロトコルに基づいたUnsplashからのものです

この記事で述べられている意見は著者自身の意見のみを表しており、人人士品夢家プラットフォームは情報保存スペースサービスのみを提供します。