CRM システム製品運用 (目標、ポジショニング、実装の 3 つのレベルから CRM 製品方法論について説明します)

目標、ポジショニング、実装の観点から、CRM製品の方法論についてお話しします。

はじめに: CRM (顧客関係管理) は、企業と既存および潜在顧客とのやり取りを管理するシステムです。 CRM は、顧客データの履歴の蓄積と分析を通じて、企業と顧客の関係を強化し、企業の売上収益を増やし、顧客維持率を向上させることができます。この記事の著者は、目標、位置付け、実装という 3 つのレベルから CRM 製品の方法論について語っています。

過去 2 年間、製品作業の中核は基本的に CRM を中心に展開してきました。この記事では、CRM の目標、位置付け、実装という 3 つのレベルから CRM の製品方法論を体系的にまとめます。

CRM システムの構築と反復の前提は、次の 3 つの点に基づいています。

目標設定は戦略レベルでのビジネス上の意思決定です。その影響要因は内部リソースや組織構造に限定されず、外部の市場動向や競争環境にも関連しています。テクノロジー企業にとって、ビジネス目標は基本的に、収益の増加、ユーザーの増加、ユーザー行動データの増加という 3 つのカテゴリに分類できます。

CRM システムの場合、主な目標は通常、収益の増加を実現することです。ユーザーおよび行動データの増加は収益増加の基礎となりますが、システム レベルでの目標は主に、このデータを活用してチームが期待される収益をより効果的に達成できるようにすることです。

収益の内訳に関しては、ビジネス モデルごとに定義が大きく異なります。一般的には、収益 = 特定の特性を満たすユーザーの数 × そのようなユーザーが支払った金額として抽象化できます。通常、この式は次のように表されます: 収益 = ユーザー数 × ユーザーあたりの平均収益 (ARPU)。 ARPU 値に影響を与える要因は通常、ユーザーに製品を提供する頻度と期間に関連しています。

ユーザーライフサイクルの概念を導入すると、収益 = ユーザー数 × ライフサイクルバリュー (LTV = LT × ARPU) として最適化できます。簡単に言えば、LTV とは、ユーザーを獲得してからそのユーザーを完全に失うまでに製品が得る総収益です。アプリケーションの観点から見ると、LTV は特定のタイプのユーザーの平均生涯価値であるはずなので、一定期間の収益は、ユーザー数 × 解約率 × ARPU になります。

上記の式に基づくと、次の要因が収益の増加に役立つことが推測できます。

• ユーザーの増加
• 質の高いユーザーの成長
• サービスの頻度と期間を改善する
• オペレーターのサービス効率（人的効率）を向上させる
• ユーザー離脱率を下げる

運用スタッフの数や勤務時間は、対応する製品マネージャーによって決定されないことがよくあります。したがって、CRM システムレベルでは、プロダクトマネージャーが効果的に改善できる要素は労働効率です。労働効率を向上させるための最も重要な方法は、ビジネス行動をデジタル化し、そのデータを活用して業務上の意思決定を支援することです。

CRM システムを業務運営の観点からどのように見ていますか?

従来の考え方では、CRM は運用担当者が業務を遂行し、ビジネス データを分析するためのシステムです。デジタル経営と洗練されたオペレーションという現在の経営理念、そして顧客獲得コストが徐々に上昇している市場状況を考慮すると、CRM システムはデータの運用と分析のプラットフォームであるだけでなく、ビジネス戦略を実行するための中核要素でもあります。

さらに、あらゆるシステムは人々に役立ちます。ビジネス担当者のモチベーションを高めることも、目標を達成する上で重要な要素です。したがって、CRM システムの位置付けは次のように分類できます。

上記の位置付けに基づき、製品実装のロードマップは次のようになります。

CRM システムの実装は、ビジネス行動のデジタル化に基づいています。全体的なプロセスは以下の図に示されています。

まず最初に注目すべき点は、システム全体の開始点と終了点は、システム外の人々から来ているということです。製品の自動化の度合いは高まっていますが、基本的なデータを提供したり、システムフィードバックを通じて意思決定者のアイデアを最適化したりしてビジネス価値を生み出すには、依然として人間の参加が必要です。

収益目標を達成するための前提条件は、業務上の意思決定者による戦略的思考です。 CRM システムが企業のビジネスモデルにおいて不可欠な位置を占めると、システムの価値がより発揮されます。

したがって、プロダクトマネージャーは、現在のビジネスモデルにどのような問題が存在するかについて深く考える必要があります。収益成長のボトルネックとなっているのはどれですか?ボトルネックをシステムレベルで改善することはできますか?システムを経由しなくても改善できますか？

プロダクトマネージャーは、このようなビジネス上の課題について業務上の意思決定者と高いレベルの合意を形成するとともに、組織内外のリソースの現状やロードマップの進捗状況を踏まえて実現可能な実施戦略を整理し、その後の業務の推進や反復プロセスにおいて関係者全員から十分な信頼と支援を得られるよう最大限に努める必要があります。

戦略の実行フェーズは、CRM システムに製品ソリューションを実装し、オペレーターによるその使用を促進するプロセスとして理解できます。対応する機能を実行するシステムがすでに存在する場合は、古いシステムと新しいシステム（または機能）間の移行戦略を検討する必要があります。このプロセスでは、少なくとも次の主要な問題に対処する必要があります。

• ユーザーの観点から、古いシステムと新しいシステム間の移行コストはいくらですか?最小化するにはどうすればいいですか?
• 古いシステムが直面していたビジネスシナリオと問題を新しいシステムでどのように解決するか?新しい経験を最大限に活用するにはどうすればよいでしょうか?
• 新旧システムが並行して稼働する期間中、すべてのビジネス関係者の利用を徐々に促進するためのグレースケール戦略をどのように策定すればよいでしょうか。
• 移行プロセス中に問題に迅速に対応し、反復するための適切なフィードバック メカニズムを構築するにはどうすればよいでしょうか。
• 反復プロセス中に、問題の優先順位を決定するための標準と原則は、ビジネスの変化にどのように適応しますか?

新しいシステムをゼロから構築すれば、関係者全員の合意に基づいて進めやすくなります。同時に、製品マネージャーのアーキテクチャ計画能力に対する要求も高まります。柔軟でスケーラブルな製品アーキテクチャの構築に関する質問については、この記事の最後のセクションを参照してください。

オペレーターは CRM システムを使用しながら複数の機能モジュールにアクセスできます。オペレーターは常に意思決定を行い、次の目標を思い出す必要があるため、集中力を失いやすくなります。

労働効率を向上させ、オペレータがシステム運用ではなく業務そのものに集中できるようにするために、基幹業務プロセスを「タスク」として抽象化し、統一された運用入口を「タスクリスト」として固定化することができます。操作頻度の高いリンクを「タスク」としてグループ化し、操作に必要なユーザー情報を提供することができます。従来、複数のモジュールで実行する必要があった分析、連絡、記録などのリンクを 1 つの「タスク」に統合して、労働効率を向上させることができます。

各ユーザーと他のユーザーとの連絡先レコードは、CRM システム全体の統計データを生成するためのデータ ソースとして使用できます。コンタクト後のユーザーの行動データの変化と組み合わせることで、運用上の意思決定者が分析できる程度までユーザーの業務パフォーマンスを反映し、現在のビジネス状況を判断し、意思決定者やチームが戦略的なアイデアを反復するのに役立ちます。これにより、基本的なビジネス データのクローズド ループが形成されます。

詳細レベルでは、CRM システムの高頻度操作プロセスは、図の 3 つのコア ノードに抽象化できます。

以下では、これら 3 つのノードに基づく対応するエクスペリエンスについて説明します。

高頻度操作の第一歩はユーザーを見つけることです。この問題を解決する最も簡単な方法は、多次元の検索およびフィルタリング条件を提供することです。オペレーターは、さまざまな検索条件とフィルター条件を組み合わせて対象ユーザーを検索します。この方法は、JD.com や Taobao でのショッピングに似ており、明らかに非効率的な解決策です。

この非効率性は、ビジネス開発中のエントロピーを増加させる複雑なスクリーニング項目と反復的な検索動作に起因します。より良い解決策は、複雑なフィルター項目をシステム レベルでビジネス ロジックに抽象化し、ユーザーが検索せずに対象ユーザーを見つけられるようにすることです。このロジックに基づいて、「ユーザーの検索」を「ユーザーの割り当て」に変換できます。

図に示すように、オペレーターの動作は左側のサイクルから右側のサイクルに変わります。一見単純な変更は、労働効率を向上させる上で不可欠な改善です。

割り当てロジックに関しては、ビジネスモデルの違いに応じて、「固定ビジネスロジック」と「自動リコールロジック」の 2 つのカテゴリに分類できます。

固定ビジネス ロジックとは、指定された割り当てロジックに従ってユーザーを異なるオペレーターに割り当てることを意味します。例えば、地域別販売や利益分配の特性を持つビジネスの場合、チャネル実績の精算、営業リードの割り当て、戦略調整などに関わると、システム全体に影響が及び、契約の再締結も必要になります。

より広く受け入れられている解決策は、固有のチャネル リンクを通じてチャネルによってもたらされたリードまたは有料ユーザーを追跡することです。

さらに、地域、業種、およびさまざまなユーザーのその他の属性特性に基づいて、「グローバル リード プール」を構築し、対応するチャネルの「ローカル リード プール」に割り当てることもできます。直販、流通、フランチャイズなどのビジネスモデルに応じて、固定ビジネスロジックの割り当て戦略は異なりますが、ここでは詳しく説明しません。

自動リコール ロジックは、ユーザーの属性と特性をオペレーターの属性と特性と組み合わせてサンプル データを呼び出し、オペレーターとユーザーを一致させ、CRM システムで「タスク」を生成します。

このモデルが解決する問題は、運用管理者が定期的に幹部にタスクを再割り当てする回数を減らすことです。この自動割り当てルールの中核には、リコール戦略、マッチング戦略、頻度、有効期間という 4 つの側面が含まれます。

• ユーザーとオペレーターをリコールするためにどのようなロジックが使用されますか?
• リコールされたユーザーとオペレーターを一致させるためにどのようなロジックが使用されますか?
• リコールとマッチングを実行する頻度
• この規則はどのくらいの期間有効になりますか?

具体的なルールロジックには、自社のビジネスやユーザーの特性に基づいたデータ分析と意思決定の繰り返しが必要ですが、ここでは詳しく説明しません。

割り当てロジックに基づいて、各割り当てのフォローアップの「優先度」を設定することもできます。つまり、タスク リスト内のユーザーの行動データに基づいて、フォローアップ価値の高いユーザーが最上位に配置されたり、わかりやすいラベルが付けられたりするため、オペレーターは結果を生み出す可能性が高いユーザーを優先的にフォローアップし、意思決定コストを削減できます。

ユーザーが優秀であればあるほど、分析にかかる時間は長くなります。

このプロセスは、医師が患者を診断するプロセスに似ています。かつて、中医学の医師は「観察、聴診、問診、触診」という3つの方法で患者を治療していましたが、これは医師に高い負担を強いるだけでなく、医師の時間を有効に活用できないものでした。さらに、主観的な要素の影響が大きいため、異なる医師が同じ症状について合意に達することは容易ではありませんでした。

現代医学では診断と治療が分離されており、診断は機械（CT、B-超音波、X線など）と看護師によって完了し、結果は非常に正確です。医師が診断データに基づいて患者の治療に集中できるようにします。日常の発熱や風邪などの簡単な診断結果であれば、一般の方でも自分で対応できます。

現代医学の診断アイデアを活用し、顧客分析レベルで、製品マネージャーはパレートの法則 (80/20 ルール) に基づいて実証済みの効果的な分析プロセスを製品化し、運用効率を向上させることができます。

ユーザー分析を製品化するための第一歩は、複雑なユーザー属性や行動データを標準化し、グラフや表の形式で表示して情報の可視化を実現することです。基本的なトレーニングを通じて、オペレーターは標準的な分析方法を通じて一般的な問題を解決し、タスク処理の効率を向上させることができます。

可視化されたユーザーデータを基に、「ユーザー離脱分析」「有料ユーザー分析」「ユーザー行動分析」など、実績のある効果的な分析手法をモジュール化することで、運用者が現在のユーザーの問題点を特定できるように支援します。

さらに、システムは一般的な問題に対して対応するガイダンスや提案も提供できます。たとえば、解約しようとしているユーザーの場合、システムは、ユーザーの以前のアクティブ ステータスに基づいて、運用部門に異なる連絡戦略を採用するよう提案できます。新規ユーザーの場合、システムは、ユーザーの登録チャネルと登録後の行動に基づいて、ユーザーに連絡する際に異なる言葉遣いを採用することを運営側に提案することができます。アクティブユーザーの場合、システムはユーザーのアクティブな行動に基づいて、適切なタイミングで有料コンバージョンを行うオペレーションを提案できます。

ユーザーを正確に位置付けることは、非常に複雑な分析プロセスです。スクリーニング条件のほとんどは、ユーザーの消費量や頻度などの静的なユーザーデータに基づいています。しかし、ビジネスシナリオにおけるユーザーの理解と分析は動的であり、製品マネージャーが過去のデータの変化傾向に基づいてすべての時間ディメンションの特性をフィルター項目に統合することはほぼ不可能です。

すべてのフィルタリング条件を単純にシステムに追加したとしても、その内部ロジックはオペレーターにとって理解しにくく、ユーザーエクスペリエンスは悪くなります。

したがって、フィルター項目の複雑な組み合わせによる分析が必要なビジネス シナリオでは、実証済みの効果的な分析プロセスを、ユーザーがフィルター処理するためのオプションとして全体的なリコール ルールに抽象化できます。

簡単に言えば、ビジネス チームとの綿密なコミュニケーションを通じて、ビジネス分析ロジックが製品ソリューションに分類され、フィルター項目に統合されます。オペレーターはオプションをクリックするだけで、分析プロセス全体を完了し、視覚的な結果を得ることができます。

このロジックの典型的な応用例は「ユーザー セグメンテーション」であり、これは特定の次元に基づいてターゲット ユーザーをさまざまなグループに分割することです。性別、年齢、地域などの人口統計属性に応じて分類することも、活性化対象ユーザー、アクティブユーザー、離脱ユーザーなどの次元など、データ分析の結果に基づいて区別することもできます。

さまざまな業界は、その事業特性に応じて分類することもできます。たとえば、教育業界は、体験ユーザーグループ、購入ユーザーグループ、リピート購入ユーザーグループに分けることができます。企業サービス分野は、顧客の購買段階に応じて、未経験者、潜在顧客、見込み顧客、契約顧客などに分類できます。

ここで注意すべき点は、各グループ化ロジックは相互に排他的である必要があるということです。ユーザーが「アクティブ ユーザー グループ」に分類されている場合、同じ期間中にそのユーザーは「解約ユーザー グループ」または他のユーザー グループに分類することはできません。

CRM システムは、システム レベルでのユーザー グループ化に加えて、各オペレーターが「ユーザー タグ」をカスタマイズするのにも役立ちます。ユーザーのグループ化とは異なり、ラベルは、ユーザーとビジネス ニーズに関するオペレーターの主観的な理解に基づいて人為的にマークされた特性識別子です。

タグは相互に排他的ではなく、同じユーザーに複数のタグを付けることもできます。作業中のオペレーターのマーキングが正確であればあるほど、効率は向上します。製品マネージャーは、調査中にオペレーターが追加したラベル機能に基づいて分析を実行し、ユーザーポートレートを改善したり、分析オプションにグループ化するのに適した抽象的な機能を使用したりすることもできます。

ビジネスレベルでは、経営陣が業務スタッフの行動を分析することも目標を達成するために重要です。製品のデジタルクローズドループに基づいて、オペレーターのデータ分析は、一般的に、タスクの実行と記録、およびパフォーマンス基準を満たすユーザーの数の増加に重点を置いています。

タスクの実行記録は、オペレーターの処理時間、記録の完全性、使用頻度などのデータ次元に基づいて、ある程度の労働効率を測定できます。さらに重要なのは、運用がユーザーに届いた後のユーザー行動データや決済コンバージョンデータの改善です。

製品マネージャーは、実際のビジネス状況に基づいてそのようなデータを視覚的なチャートに統合し、運用マネージャーがチームの全体的および個別の作業状況を評価できるようにすることができます。

ユーザーの観点から見ると、プラットフォームのリーチは、ユーザー主導型と受動的受容型の 2 つのタイプに分けられます。マーケティングの電話や WeChat の友達リクエストを受動的に受け取るユーザーの体験は比較的悪いです。ユーザーに真のニーズがない限り、コンバージョン率は極めて低くなります。

ユーザーが開始するインタラクションは、次の 2 つのカテゴリに分けられます。

1 つは、製品の使用中または体験中に問題が発生し、プラットフォームに相談する必要がある場合です。このシナリオでは、インテリジェントな Q&A を使用して、一般的な質問を構造化されたカスタマー サービス メッセージに整理し、ユーザーに自動的に返信することができます。これは、Taobao で買い物をするときに自動的にポップアップ表示されるサイズや配送に関する相談メッセージに似ています。さらに、China Mobile のカスタマー サービス電話番号と同様に、対話型音声質疑応答 (IVR) を使用して、ユーザーが一般的な問題を解決できるようにすることもできます。

もう 1 つのタイプのプロアクティブ インタラクションは、現在の教育および消費の分野でより一般的であり、近年非常に人気のあるプライベート ドメイン トラフィック操作モデルでもあります。プラットフォームは一般的に、独占的なサービスや優遇ポリシーを提供することで、ユーザーにWeChat上でサービススタッフを追加するよう誘導します。友情関係を築いた後は、ソーシャル グループ、友人サークル、オンライン アクティビティ、その他の操作を通じてユーザーのアクティビティを増やし、有料コンバージョンを促進できます。

プライベート ドメイン トラフィック操作に関しては、製品反復のこの部分は実際には CRM のカテゴリに分類されます。ただし、WeChat のインターフェースの制限により、WeChat クライアントがオペレーティング システム レベルでハッキングされない限り、内部システムに接続することはできません (この操作はブロックされるリスクが高くなります)。

昨年、企業向けWeChat 3.0バージョンが顧客連絡先や顧客友人サークルなどの関連APIを徐々に公開するまで、企業向けWeChatと社内システムを接続することは、プライベートドメイントラフィック操作のほぼ標準的な構成となっていました。今後、WeChat for Business は、企業がユーザーとの関係を構築するのに役立つモバイル CRM ワークステーションとして使用できます。

エンタープライズ WeChat とプライベート ドメイン トラフィック操作に関しては、これは別の大きなトピックであるため、ここではこれ以上説明しません。

一般的に、ユーザーにリーチする場合、ユーザーによって開始されたインタラクションの方が、ユーザーとの関係を確立する上でより高い価値があります。ますます充実するCRMシステムを基盤として、いかにしてターゲットユーザーが積極的に商品とつながり、その後の一連の価値交換行動をとれるようにするかは、プロダクトマネージャーがもっと考えるべき課題です。

従業員に対する前向きな動機付けが生産性を向上させるというのは自明の理です。

CRM システムでユーザーに達成感と価値を感じてもらうにはどうすればよいか、これもプロダクト マネージャーにとって検討する価値のある問題です。コアビジネスの運用や分析と比較すると、従業員のモチベーションに関連する機能は優先順位が低くなることがよくありますが、これはプロダクトマネージャーの考え方や計画には影響しません。過去 2 年間の製品実践において、モチベーションの観点から、以下の点が一定の参考価値を持っています。

従業員にとって、ビジネス成果の重要性は自明です。ユーザーの作業パフォーマンスをシステム内でリアルタイムに表示できれば、士気の向上に大きな意義があるでしょう。

ビジネス目標が収益増加であるか、ユーザー行動データ増加であるかにかかわらず、オペレーターの個人センターまたはよりわかりやすいダッシュボードに表示する前に、プロダクトマネージャーは、表示される数値と計算ロジックがビジネスレベルのインセンティブ原則に沿っているかどうか、および具体的な更新頻度、有効期間、および決済ロジックを運用上の意思決定者と明確にする必要があります。

同時に、R&D レベルで業務データの決済をどの程度リアルタイムに実現できるか、また、最終的に表示されるデータが実際の決済と一致するように、途中でどのデータフローノードを通過する必要があるかを考慮する必要もあります。事業と研究開発チームの現状を総合的に考慮することによってのみ、効果的なインセンティブ プランを作成できます。

製品レベルでは、掲示板は非常に単純なロジックを持つ機能です。プロセス全体は、明らかな表示エントリとコンテンツ編集モジュールのみで完了できます。

ビジネスレベルでは、掲示板は情報の同期において重要な役割を果たします。プラットフォームが推奨するものや反対するもの、最新のビジネス展開、ポリシーの変更などの重要な情報はすべて掲示板にリアルタイムで公開できます。

ビジネス チームと連携するプロダクト マネージャーは、ビジネスのダイナミクスを積極的に理解し、ビジネスのあらゆる側面を詳しく調べて、それぞれのビジネス需要を理解する必要があります。優れたソリューションは、製品ロジックの厳密さを反映するために必ずしも複雑である必要はありませんが、可能な限りシンプルである必要があります。これをプログラミング言語で表現するには、「クラス」を作成する必要があるのか​​、「インスタンス」を作成する必要があるのか​​を考慮する必要があります。

掲示板を例にとると、業務上の要求としては、業績発表やスケジュール同期機能などが考えられます。製品マネージャーは、これが「インスタンス」レベルのビジネス担当者によって提案されたソリューションであり、その背後にある実際のニーズは、複数の人が共同作業を行う際の情報同期の問題を解決することであることに留意する必要があります。

このとき、単にビジネスアイデアに従って機械的にソリューションを実装するのではなく、そのようなすべてのシナリオに対応できる製品ソリューションを「クラス」レベルから可能な限り抽象化する必要があります。

「自動リコールロジック」を使用してタスクを割り当てる CRM システムの場合、ビジネス レベルにユーザーに対する対応するインセンティブ ポリシーがある場合は、対応するビジネス ロジックをオペレーターのリコール ロジックと、インセンティブ ポリシーに基づいてリコールされたユーザーとオペレーターをマッチングするロジックに追加できます。

たとえば、パフォーマンスが平均を上回るオペレーターには質の高いユーザーの割合が多く割り当てられ、パフォーマンスの低いオペレーターにはより単純なタスクが割り当てられます。割り当ての重みを調整することで、運用担当者は自分の行動の結果をより明確に認識できるようになり、ビジネス全体で適者生存をより適切に実行できるようになります。

製品を作ることが仮想ビットの世界で建物を建てることに例えられるとすれば、アーキテクチャは建設を始める前に必要な設計図です。スケーラビリティ、再利用性、QPS、TPS などのシステムの非機能特性は、通常、R&D チームによって設計および反復されます。

プロダクトマネージャーの役​​割は、チームの現状とビジネスの将来の発展期待を総合的に考慮し、ビジネス開発のあらゆる段階で標準化され、柔軟性、拡張性、再利用性に優れた製品ソリューションを提案することです。

製品を作ることはエントロピーを増大させるプロセスです。ユーザー規模とビジネス規模の拡大に伴い、一連の新しいシナリオと新しい要求が必然的に導入され、製品の複雑さもそれに応じて増加します。

この観点から見ると、アーキテクチャとは実際にはビジネス構造に基づいてルールと制限を設定することです。このため、正しいアーキテクチャも間違ったアーキテクチャも存在せず、1 つのアーキテクチャをすべてのビジネス シナリオに適用できるわけではありません。製品マネージャーは、反復を通じて継続的に改良し、改善することしかできません。

まず第一に、アーキテクチャに関して最も重要なことは、それがビジネスに適合していることです。

これは全体から部分へのプロセスです。企業がユーザーに提供するサービスが何であるか、ビジネスがどのように展開され、拡大されるかを明確にし、トップレベルの戦略を決定して初めて、製品の境界を定義することができます。一度これが決まってしまうと、基本的に変更するのは困難です。

次のステップは、全体計画に基づいてソリューションを各部分に分割し、そのコア機能と部分間の関係を定義し、最終的な製品構造図を形成し、ビジネスの発展と同期して反復することです。

システム実装レベルでは、製品マネージャーはまず組織構造に基づいて適切な権限管理メカニズムを定義する必要があります。最も単純かつ残酷な方法は、ユーザーに読み取りおよび書き込み権限を直接付与することです。ここで紹介する問題は、すべてのユーザー権限の変更は管理者が手動で行う必要があり、複数レベルの権限管理がサポートされていないことです。

そのため、システムの実践では、「ロール」という概念が導入され、つまり、ユーザー セットと権限セットの間にロール セットが確立され、各ロールは対応する権限のセットに対応します。ユーザーに適切なロールが割り当てられると、そのユーザーにはそのロールのすべての操作権限が付与されます。これは、権限制御理論における古典的なロールベースのアクセス制御 (RBAC) です。

より複雑な使用シナリオでは、ロールをユーザーの属性と見なすと、より多くのユーザー属性を追加でき、属性ポリシーを調整することでユーザーの権限を制御できます。これが属性ベースのアクセス制御 (ABAC) です。

上記の権限管理方法は、権限管理に関するあらゆる企業の基本的なニーズをほぼ満たすことができます。興味のある友人はさらに調査を行うことができます。

権限管理メカニズムを決定した後、製品管理者は、権限によって制御される各業務モジュールを抽象化して分類し、重複度の高い業務シナリオを持つ機能をモジュール化し、それらを統一された入口に統合して、製品レベルでの機能の高度な集約を実現し、モジュール間の複雑な接続を最小限に抑え、プログラミング言語で高凝集性、低結合性として記述する必要があります。

このプロセスはコンポーネント化とも呼ばれます。この記事では、CRM システムのコア プロセスについてのみ説明します。実際のビジネスでは、システムにはマーケティング管理、注文管理、プロセス管理、ナレッジ ベースなどの多くのサブシステムが含まれることもあります。 1 つの機能ポイントを変更すると、複数のサブシステムの変更が必要になる場合があり、製品の迅速な提供にはつながりません。

そのため、プロダクトマネージャーは、安定して長期間使用される機能を可能な限りサブシステムに分割し、さらに機能ポイントに応じてサブシステムを分割する必要があります。

例えば、クーポンや割引などのマーケティング機能を備えた CRM システムの場合、割引の属性設定をマーケティング管理サブシステムに集中させ、具体的な配布プロセスを前述の「タスク」に追加することができます。オペレーターは、マーケティング管理で複雑な設定をすることなく、タスク内で割引配布を完了するだけで済みます。マーケティング ツールのその後の反復も、より迅速な研究開発の提供につながります。

コンポーネント化によってもたらされるもう 1 つの問題は、カスタマイズ、つまり、さまざまな人にさまざまな製品を提供することです。

システムのユーザーごとにカスタマイズされた製品を提供できれば、労働効率は確実に向上します。しかし、コストの観点からこれは現実的ではありません。したがって、構成可能なアプローチを検討して、ユーザーが自分のニーズに合ったプラグインを選択して問題を解決できるようにすることができます。

構成は、CMS（コンテンツ管理システム）の中心的な考え方です。設定可能な機能を備えたシステムの場合、新しい機能の導入や古い機能の更新に追加の開発作業は必要ありません。クライアントがリリースされた後、システム管理者は簡単な構成を実行するだけでこれを実現できます。 CRM システムもこの考え方を利用して、主要な構造と機能の詳細が比較的頻繁に変更されない製品モジュールを、ユーザーが使用できるように柔軟に構成可能なコンポーネントに反復することができます。

上記は、過去 2 年間の製品作業における CRM 製品方法論の体系的な要約です。これが関連業務に従事するプロダクトマネージャーにとって参考になれば幸いです。

システムが使いやすく効果的かどうかは、最終的にはチーム次第です。プロダクトマネージャーも、総合的な視点でプロダクトを反復し、高い実行力、前向きな思考、革新的な思考を持つチームを一緒に構築し、共に成長していけることを願っています。

『Everyone is a Product Manager』のコラムニスト、Uncle Liu 氏。フリーランスのプロダクトマネージャーは、平坦な道をジグザグに進んでいます。エンタープライズサービス分野における製品企画、UX、ユーザーリサーチ、データ分析に注力します。首都に位置し、コミュニケーションを歓迎します。

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

タイトル画像はUnsplashより、CC0契約に基づき提供