運用バックエンド データ (ミドル オフィスをバックエンドとして扱わないでください。消化不良を引き起こし、簡単に人々を怒らせてしまいます)

ミドルオフィスをバックオフィスのように扱わないでください。消化不良を引き起こし、簡単に人を怒らせてしまいます。

はじめに：前回のデータミドルプラットフォームの実践記事「データミドルプラットフォーム実践：Yuanyuan Buyerを例に、0から1までのリアルタイムラベリングエンジンの構築方法について語る」では、著者はリアルタイムラベリングプラットフォームの構築方法について説明しました。この記事では、ミドルプラットフォームプロジェクトを実行する際の失敗事例と、ミドルプラットフォームプロジェクトの失敗を回避する方法について説明しました。

アリババが2009年に分散型アーキテクチャの変革を完了すると、タオバオプラットフォームの全体的な機能が質的に向上しました。しかし、新たな課題と問題が発生しました。タオバオ加盟店の取引量が爆発的に増加し、大規模小売業や日用消費財業界がタオバオや天猫に参入するにつれ、従来のプラットフォームが提供する商品管理、在庫管理などの機能は不十分になり、加盟店の業務効率に大きな影響を与えているようです。

ある意味、これら何百万もの商人たちは、Taobao と Tmall の生命線です。これらの商人が Taobao や Tmall に店舗を開設しなければ、電子商取引プラットフォームの存在価値はなくなるでしょう。そこで、これらの販売業者の要求に応えて、Taobao チームは、当時の ERP および CRM 業界で最も専門的なチームを直ちに動員し、Taobao と Tmall の販売業者に統合 CRM サービスを提供するプラットフォームを開発し、商品、在庫、プロモーション、物流の面での販売業者の運用能力を強化しました。

約 100 人の人々が数か月間懸命に取り組んだ結果、Taobao の統合 CRM プラットフォームがすぐにリリースされました。 CRM サービスを利用する際に加盟店に求められるサービス料金も非常に低く、無料のサービスを提供している加盟店もありました。これにより、加盟店の出店体験が大幅に向上し、Taobao プラットフォームに対する満足度が大幅に向上すると誰もが考えていたが、結果は驚くべきものだった。ほとんどの商人は、Taobao が構築した統合 CRM プラットフォームについて不満を抱いていました。 Taobao チームは一定期間、CRM プラットフォームの最適化と改善に全力を尽くしましたが、CRM プラットフォームがオフラインになるという結果は変わりませんでした。

その理由は、統合 CRM プラットフォームが構築される前は、サービス対象となる顧客のニーズが明確に理解されていなかったためだと思います。当時、タオバオには約200万の加盟店があり、家電、サービス、デジタル、生鮮食品、玩具など、何百もの異なる業界の加盟店がありました。ダブル11のように1日の取引額が10億元を超える大手商店もあれば、年間の取引額がわずか数千元程度の商店もありました。これらの顧客間の違いにより、CRM プラットフォームに対する需要に大きな違いが生じます。そのため、需要に大きな違いがあるユーザー グループを統一されたプラットフォームで解決しようとすると、最終的には全員が不満を抱くことになります。

プロジェクトが失敗した後、Taobaoチームはプロジェクトを見直し、失敗の原因を要約して特定し、痛い経験から学んだ後、Taobaoオープンプラットフォームの構築を開始しました。 Taobao Open Platform は、Taobao と Tmall のマーチャントのバックエンド データを、マーチャントが認可した技術チームに公開します。マーチャントバックエンドシステムによって開かれた権限に基づいて、マーチャントは製品、在庫、注文、物流、顧客サービスなどのパーソナライズされたビジネスプロセスを実装できます。

マーチャント自身の開発チームまたはサードパーティの開発者は、マーチャントのさまざまなニーズを満たすために、Taobao によって公開されたマーチャントデータをカスタマイズおよび拡張し、それによってマーチャントが長い間悩まされてきた運用効率の問題を根本的に改善します。

数年前、データミドルプラットフォームプロジェクトに取り組んでいたときにも同じ間違いがありました。当時、運営チームは、特定のリストの上位 10 人のユーザーに定期的にクーポンを送信して、再購入を促す必要がありました。ランキングルールは比較的複雑なため、ビジネスラインの製品開発チームだけで対応するのは難しく、データミドルプラットフォームチームがランキングデータを提供する必要があります。定期的なクーポン発行業務であるため、ビジネスチームからはランキングユーザー表示やデータエクスポート機能の作成を提案しました。

当時はまだデータミドルプラットフォームプロジェクトの初期段階であり、データミドルプラットフォームにはビジュアルコンポーネントさえありませんでした。このランキングリストを作成するためにはまだ一定の作業が残っており、ランキングリストの表示とエクスポート機能の責任者を誰が担当すべきかについて、私たちのチームは非常に悩んでいました。当時、ビジネス製品開発チームは、このような複雑なランキングリストのデータを自分で計算するのであれば、表示やエクスポート機能を開発するのは非常に簡単ではないかと考え、これを行いたくありませんでした。彼らはただこの仕事を私たちに押し付けたいだけなのです。

私たちのチームも当時は同じことを考えていました。こんなに複雑なランキングアルゴリズムを解明したのに、そのデータを他のチームに引き渡したら、私たちのデータプラットフォームの価値はどのように反映されるのでしょうか？最終的に、このアイデアに駆り立てられて、データ ミドル プラットフォームは歯を食いしばってそれを実現しました。

しかし、今ではこれがミドルオフィスチームが犯す典型的な間違いだと考えています。

自分を舞台裏の人間として扱い、すべてをやり遂げたいと思う。ミドルオフィスとは何ですか？中間プラットフォームは、集中型の機能再利用プラットフォームです。ビジネス ミドル プラットフォームとデータ ミドル プラットフォームはどちらも、基盤となる共通機能を提供します。

実は、上記のランキングのケースには大きな間違いがあります。データ ミドル プラットフォームとしては、自分が何をすべきか、ビジネス チームが何をすべきかを明確にする必要があります。ランキング機能に関しては、データミドルプラットフォームはビジネスチームにランキングデータインターフェースのみを提供し、ビジネスチームは表示機能とエクスポート機能を担当します。

現在、データ ミドル オフィス チームがこれを担当しているため、運用チームがこのアクティビティを実行するたびに、データ ミドル オフィスにログインしてデータを取得し、ビジネス システムにログインしてクーポン アクティビティを構成する必要があります。ビジネス チームは、アクティビティを実行する際にビジネス システムを使用することに慣れています。これは時間の無駄ではないでしょうか?また、この業務ラインのデータミドルプラットフォームで開発されたランキング機能は、本当に他の業務チームでも再利用できるのでしょうか？それは実は非常に難しいです。

反省した後、同じ間違いを繰り返さないように、チームにいくつかのルールを設定しました。

• データを使用して開発される機能により、ビジネス チームの時間を 2 時間以上節約できますか? （データセンターで開発された機能が業務チームの効率を向上できることを保証する）
• データミドルプラットフォームによって開発される関連指標は、企業の問題に直接フィードバックしたり、企業の成長に貢献したりできるでしょうか? （データセンターで開発されたデータ指標が会社にとって価値のあるものであることを確認する）
• データミドルプラットフォームで開発された機能は、将来的に加盟店に公開される予定でしょうか？ （電子商取引プラットフォームとして、データセンターの再利用性を確保するために、ビジネス担当者向けに開発された機能を商人が再利用する必要がある）

Alibaba は CRM プロジェクトでも同じ間違いを犯しました。同社は自らをミドルオフィスではなくバックオフィスとみなしていた。数百人のチームで 200 万人の商人のあらゆるニーズを満たすというのは、単なる希望的観測でした。

アリババが導入したサードパーティ開発者の新しい役割は、まさに天才的なひらめきです。当初の数百人からなるチームから、数千人、あるいは数万人のサードパーティ開発者と連携して 200 万の商人に共同でサービスを提供するチームへと変貌し、商人のほとんどのニーズに応えられるようになりました。

ここで私は「協力」というキーワードに言及しました。ミドルオフィスチームにとって、連携能力は非常に重要です。協調能力は個人の限界を決めるだけでなく、チームの限界も決めます。

ミドルプラットフォームは、会社全体の視点からシステムを構築するため、会社の下にある特定の部門の利益に影響を与えることになります。ビジネスミドルオフィスプロジェクトに携わっていると、なぜこの機能を開発してもらう必要があるのか​​とよく聞かれます。自分でやった方が早いんじゃないでしょうか？データ ミドル プラットフォーム プロジェクトで発生する最大の問題は、「なぜデータを提供しなければならないのか?」ということです。

この一連の問題をどのように解決すればよいのでしょうか?

実際のところ、それはすべて協力の問題なのです。ミドルプラットフォームを構築するときは、ミドルプラットフォーム システムをビジネス ライン チームにプッシュするだけでなく、会社がミドルプラットフォームを構築する必要がある理由、ミドルプラットフォームがビジネス部門にどのように役立つかなどの質問で彼らを洗脳する必要があります。

彼らを洗脳するだけでなく、中間プラットフォームを通じてビジネス部門が問題を解決できるように真に支援する必要もあります。この方法でのみ、ゆっくりと彼らと協力することができ、彼らは中間プラットフォームにますます依存するようになります。そうでなければ、頑固ですべてを自分でやりたいのであれば、結局何もうまくいかず、人々の集団を怒らせることになります。

当時、同社のeコマースプラットフォームは一定の段階まで発展しており、レコメンデーションシステムの導入が必要でした。推奨システムの核となるのは実際にはアルゴリズムであり、これはデータ ミドル プラットフォーム チームが主導する必要があります。しかし、データ チームの強みはアルゴリズムの作成にあり、ビジネス ラインの製品チームと運用チームはビジネス フローとデータ フローをより深く理解しています。

当時、ビジネス ラインの製品技術チームがすでに軽量なレコメンデーション システムを開発し、試験運用していたという状況に遭遇しました。これはもっと難しい質問です。ビジネスラインの製品および技術チームが構築した推奨システムを覆し、ゼロから始めるべきでしょうか? (彼らが構築した推奨システムは彼ら自身のビジネス向けに設計されており、あまり普遍的ではないため) それとも、彼らの基盤の上に構築すべきでしょうか?せっかく構築したレコメンデーションシステムを覆して最初からやり直すとなると、事業ラインの製品チームや運用チームは絶対に満足しないだろう。まるでトランプゲームをしているときに、突然データセンターがやって来てテーブルをひっくり返したような感じです。誰もが怒るでしょう。

当時、既存のシステムを整理したところ、ユーザー行動（訪問、閲覧、カートに追加、注文）の重み付けの設定など、レコメンデーションシステムの機能の一部が再利用できることが分かりました。これらの関数では、同期データの方法を使用して、演算子によって設定された重みを読み取ります。一方で、これにより、ビジネス製品技術チームによって開発された機能が無駄にならないことが保証されます。一方、オペレーターが参加して、初期のユーザー行動の重みを設定することもできます。こうすることで、参加意識が生まれます。

しかし、彼らが作成したアルゴリズム モジュールは実際には良くなく、あまりにもパーソナライズされており、普遍的に使用することはできません。推奨システムは、想起、並べ替え、フィルタリングの標準的なプロセスに従って、大きなブロックに分割して設計する必要があります。これは、推奨システムを後で他のビジネス チームが再利用できるようにする唯一の方法です。そこで、データミドルプラットフォームのアルゴリズムチームが主導し、アルゴリズム面からゼロから始めることにしました。当時、なぜそうしなければならなかったのかを明確に説明するトレーニングも、ビジネスラインの製品運用チームに提供しました。

また、ドライアルゴリズムだけでは不十分で、ビジネスライン製品や運用チームとの連携も必要です。ビジネス ラインの製品技術チームは、コア ビジネス フローとデータ フローを整理し、新しいバージョンの推奨事項に必要なデータ ポイントを補足するのに役立ちました。事業ラインの運用チームは、ビジネスをより深く理解します。たとえば、ファストファッションの電子商取引プラットフォームとして、新しいモデルに高い重みを与える必要がある、ユーザーのピーク訪問期間はいつなのか（計算時間を決定する）、返金率の高い販売者をどのように扱うかなど、これらすべての要素が考慮され、アルゴリズムに追加されます。

最も重要なのは、データミドルプラットフォームチームとビジネスライン製品・運用チームです。当時の目標は、複数の並列スロットのうち 1 つを推奨スロットとして選択し、この推奨スロットのコンバージョン率 (訪問数/支払い) が、手作業で組み立てられた商品がある並列スロットのコンバージョン率と少なくとも同等である必要があるというものでした。最終的に、私たちは協力して3つのメジャーバージョンを作成し、半年で、手動で編成された並列スロットの2〜3倍の推奨スロットのコンバージョン率を達成しました。

これはミドルオフィスチームと他部門との連携の典型的な事例であり、結果は非常に良好です。最終的な効果が良かったのは、各チームが非常によく協力し、それぞれが自分の強みを生かし、全員が強い参加意識を持ち、全員が自分に価値があると感じたため、1+1 が 2 よりも大きな効果を達成したからです。

ミドルオフィスとして働くときは、常に象を蛇のように飲み込んで何でもやろうとするバックオフィスだと考えてはいけません。これは簡単に消化不良を引き起こし、人々を怒らせる可能性があります。

ミドルプラットフォームを運営する上で、他部門との連携能力は非常に重要です。協力する能力は、ミドルプラットフォームチームの上限も決定します。孫であるべきときには孫であるべきであり、祖父であるべきときには我慢するべきである。結局、目標を達成することが最も重要です。

Wilton Dong Chaohua、WeChat パブリックアカウント: 世界を変えるプロダクトマネージャー、『Everyone is a Product Manager』のコラムニスト。ベストセラー書籍『データミドルプラットフォーム実践』の著者であり、かつてはiFLYTEKに勤務し、現在はR&F Global Commodity Trading Portでデータミドルプラットフォームのプロダクトマネージャーを務めています。主にビジネス、製品、運用、データセンターに関するオリジナル記事を共有します。

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

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