エグゼクティブサマリー
大規模な Salesforce Field Service (SFS) 環境では、外部コントラクターネットワークを管理するためにプラットフォームセキュリティとスケジュールパフォーマンスの微妙なバランスが必要です。このガイドでは、従来のテリトリーベースのパターンと、外部コントラクターのアクセスと管理を管理するための新しいアカウントベースの共有パターンの2つの主要なアーキテクチャパターンを比較します。このホワイト ペーパーでは、組織が業務目標を最も適切にサポートする基盤構造を選択できるように、また、各オプションのトレードオフを理解するために、両方を詳しく確認します。
このパターンの選択は、スケジュール効率、リソース稼働率、派遣担当者の生産性に影響します。適切なアプローチを選択することで、企業は内部スタッフと外部パートナーの両方にシームレスな体験を提供しながら、ソリューションの長期的な拡張性を維持できます。
この基本的な選択によって、すぐに運用面のメリットが得られるだけでなく、自律サービスに対する組織の準備状況も決まります。取引先ベースの共有パターンでは、Agentforce、特に Field Service のスケジューリングエージェントが人工的なデータサイロに制限されることなく総合的な評価を実行するために必要な統合データの可視性が提供されます。また、取引先ベースの共有により、Data Cloud でコントラクターのパフォーマンス評価指標をより効果的に集計できるため、マルチベンダー環境で必要とされる厳格なデータの分離を維持しながら、シームレスな競合ベンチマークを実施できます。
ポイント
- **競合の重なりに基づいてパターンを選択します。**外部コントラクターが共有テリトリーで内部リソースや他の外部リソースと競合する場合、取引先ベースの共有がアーキテクチャ的に正しい選択である可能性があります。テリトリーベースの共有は、コントラクターが重複しない専用のサービスエリアやジョブを担当する場合にのみ適用されます。
- **テリトリーの無秩序な拡大を回避します。**不要な場合にデータの分離を実現する専用のコントラクターテリトリーを作成すると、階層が肥大化し、スケジューリング効率とパフォーマンスが低下し、管理オーバーヘッドが大規模に増加します。取引先ベースの共有では、この問題パターンが排除されます。
- **AI主導のスケジュールの基盤を構築します。**Field Service のスケジューリングエージェントと最適化エンジンは、リソースプールが完全に可視化されている場合、より高いパフォーマンスを発揮します。テリトリーベース共有のサイロ化された構造はこれを妨げ、アカウントベースの共有が望ましいアーキテクチャの基盤となります。
はじめに - コントラクターネットワークの進化
過去 10 年間で、フィールドサービスのコントラクターネットワークは、内部チームのアドホックな拡張から、通信、公益事業、在宅サービスなど、さまざまな業種にわたる戦略的で意図的に構造化されたエコシステムへと進化しました。多くのフィールド業務は、フルタイムの従業員と共にコントラクターに依存しているため、アクセス、表示、派遣管理に関する明確なルールが必要です。
組織が Salesforce Field Service で拡張する場合、テリトリースタイルのパターン、取引先中心の共有、ハイブリッドのいずれを使用しても、これらの外部リソースを設計および管理する方法によって、混在する従業員全体で安全かつ効率的に作業をスケジュールする方法が直接決まります。
利用者
このガイドは、Salesforce Field Service 実装の設計、パフォーマンス、拡張性を担当する技術的および戦略的な関係者を対象としています。
- ソリューションアーキテクトおよびテクニカルアーキテクト: さまざまな共有パターンがスケジュールと最適化の効率に及ぼす影響を評価します。
- フィールドサービスオペレーションリーダー: 指定コントラクター、コントラクター企業、臨時作業員など、さまざまなコントラクターの種類間のトレードオフを理解します。
- Salesforce 管理者: サービステリトリーとプラットフォーム共有テーブルを使用して複雑なセキュリティ要件を管理する方法に関するインサイトを取得します。
SFS コントラクターの定義
対象となるコントラクターペルソナは、適切な共有アーキテクチャを直接決定します。各カテゴリは、レコードレベルのアクセス権の構造、Optimizer によるリソースの対応可能状況の認識、ソリューションの拡張方法に個別に影響します。
- 指定コントラクター: 内部従業員と同様に扱われる個々の外部リソース。指定コントラクターには、専用のユーザーライセンスが必要です。共有モデルは内部の技術者のアクセスパターンを反映するため、サポート対象のコントラクターペルソナは最も複雑度が低いものとなります。
- コントラクター企業: 自社の従業員を管理するサードパーティのエンティティ。SFS では、コントラクター企業は業務量ベースのリソースとして表され、親組織は特定の個人ではなく会社に作業をスケジュールして割り当てます。
- 臨時ワーカー: 複数のテリトリーで一時的に業務を行うユーザー。最もアーキテクチャ的に複雑なペルソナ。一時的な複数テリトリー間の関係は、テリトリーベースの共有境界が崩れることを意味するため、可視性は静的な地理的割り当てではなく、レコードレベルで動的に管理されます。
コントラクターの複雑さについて
コントラクター管理が複雑な理由
これらのパターンは、親組織とコントラクターの目標が技術的に対立している場合が多いため、複雑です。
-
多様な目標: 親組織は、顧客満足度と契約上の作業/合意に主に焦点を当てます (リソースの希望設定、迅速かつタイムリーなサービス、コントラクター間での作業と時間の配分方法の管理など)。一方、コントラクターは通常、割り当てられた作業を最大化しながら、移動時間と運用コストを最小限に抑えることに集中します。
-
競合: 社内の従業員とは異なり、異なるコントラクター企業が直接的な競合であることが多くあります。親組織はリージョンの全体像を把握する必要がありますが (透明性)、コントラクターは互いの業務を厳格に分離する必要があります (分離)。
-
ブランドの整合性: エンドユーザーにとって、従業員はブランドを表します。そのため、多くの場合、親会社はリアルタイムで状況の更新を確認する必要があります。ただし、コントラクターは多くの場合、内部業務を「ブラックボックス」と呼ばれる閉じたシステムで保護します。
-
可視性とセキュリティ: 通常、共有サービステリトリーでは、割り当てられたすべてのリソースを包括的に把握できますが、マルチコントラクター環境では、より細かなセキュリティパターンが必要になります。競争力のある整合性とデータプライバシーを維持するためには、コントラクターが互いの固有名、スケジュール、リソース情報にアクセスできないようにすることが不可欠です。
コアとなる緊張関係 ― 透明性 対 分離
| ロール | 要件 |
|---|---|
| 組織 | 外部 (コントラクターを含む) と内部のすべての技術者の可視性を確保する必要があり、スケジュール設定および最適化エンジンでそれらを一括して考慮し、リージョン全体の最適化を実現したい。 |
| コントラクター | 独自の業務を保護し、同じ地域で事業を展開する競合他社や組織の内部技術者に対して厳格に分離するために、クローズドシステム (「ブラックボックス」) として運用します。 |
| 課題 | パートナーに必要な表示とアクセスを維持しながら、組織の効率性と透明性の両方を提供するシステムを設計します。 |
コントラクターの複雑さマトリックス
Salesforce Field Service 内のコントラクター設計は、3 つの異なる運用モデルにまたがっており、それぞれがリソースの可視性、派遣の所有権、ライセンスに影響します。
- 外部業務量割り当て
- パートナーのセルフスケジュール
- 内部主導の派遣
外部業務量割り当て（プラットフォーム外業務量）: コントラクターは、従業員を外部で管理し、個々の技術者のスケジュールではなく、定義された業務量（例：10時間など）を提供します。この業務量は、スケジュールの目的で時間または作業項目のバケットとして処理されます。
パートナーのセルフスケジュール: コントラクターマネージャーは、エクスペリエンスサイトから Salesforce にログインして、自分のチームをスケジュールします。他のパートナーから厳格に隔離する必要があります。
内部主導の派遣: 内部の派遣担当者がコントラクター技術者を直接スケジューリングします。コントラクターは Field Service Mobile アプリケーションを使用して実行します。
warning: 内部派遣担当者には SFS フルライセンスが必要です。このモデルのコントラクター技術者には、Field Service Mobile ライセンス (またはモバイルアクセスが可能なコミュニティライセンス) のみが必要です。
| ディメンション | 外部業務量割り当て | パートナーのセルフスケジュール | 内部主導の派遣 |
|---|---|---|---|
| リソースの表示 | 容量のみ | パートナー所有 | 完全内部 |
| 誰が派遣するか | コントラクター (外部) | コントラクター (Salesforce 内) | 内部派遣担当者 |
| Salesforce ライセンス | 最小 | Experience Cloud | Full SFS (派遣担当者)、コミュニティ (コントラクター技術者) |
スコープ内のパターン
| パターン名 | 説明 |
|---|---|
| テリトリーベースの共有 | コントラクターは、専用の独立したサービステリトリーに割り当てられます。レコードの表示はテリトリーメンバーシップによって管理されます。各コントラクター企業またはグループは、地理的な境界内で事業を行っています。 |
| アカウントベースの共有 | コントラクターは、内部/他の外部リソースと共に標準の地理的テリトリー構造内で業務を行います。レコードレベルの表示は共有ルールによって管理され、統合リソースプールが有効になります。 |
共有と表示 - テリトリーベースの共有
このパターンでは、サービステリトリーがプライマリセキュリティ境界として機能します。各コントラクター企業は、独自の「子」テリトリーに割り当てられます。
一般的なユースケース
- 小規模パートナーネットワーク
- 地理的に完全に重複しないパートナー
- コントラクター作業が内部リソース作業と根本的に異なり、競争が排除される状況 (たとえば、外部コントラクターは「Type A 設備」のみを担当し、内部リソースは他のすべての作業種別を担当する)
メリット
- シンプルな設定: 標準のユーザーテリトリーの設定と自動化を使用します。
- クリアデータバケット化: 標準のサービステリトリーオブジェクトを使用して、データの可視化とセキュリティ管理のシンプル化を実現します。
欠点と技術的負債
- 最適化効率: エンジンではテリトリー境界を越えてリソースを評価できないため、最適なスケジュールと効率的なルーティングが妨げられます。
- テリトリーの無秩序な増加: 非常に少ないリソース数で多数のテリトリーを作成すると、スケジュールのオーバーヘッドが発生します。
- Gantt Performance: 大規模な階層 (1,000 を超えるテリトリー) では、パフォーマンスのボトルネックが顕著になるだけでなく、プラットフォームの制限に達するリスクがあります。
共有と表示 - アカウントベースの共有
このガイドでは、新しいソリューションアプローチであるアカウントベースの共有 (Salesforce のネイティブの条件に基づく共有ルールを使用して実装され、項目値に基づいてレコードアクセス権を付与するために使用されるのと同じプラットフォームメカニズム) を紹介します。アカウントベースの共有では、表示が場所から切り離されます。テリトリーは大規模で継続的なままで、可視性は取引先リレーションに基づいてプラットフォームの共有テーブルで管理されます。実際には、条件に基づく共有ルールでは、レコードの項目 (ServiceResource.Company など) が評価され、そのレコードが適切なグループと自動的に共有されます。条件に基づく共有は、取引先ベースの共有をレコードレベルのカスタムコードなしで機能させるエンジンです。
一般的なユースケース
- ワークフォースの大部分が外部リソースで構成される大規模なエコシステム
- 複数のコントラクターが同じ郵便番号をカバーする都市部
- 内部リソースと外部リソースの両方が同じ作業を実行でき、ビジネスルールによってリソース選択のロジックが規定されているシナリオ (特定のシナリオでの内部リソース設定など)
メリット
- 最大限の稼働状況とROI: このエンジンはリージョンプール全体を評価し、すべてのジョブに「最適な」リソースを見つけます。
- 拡張性: テリトリー数を増やすことなく、多数のコントラクター／外部リソースをサポートします。
- 統合管理: 内部スタッフは、数百のサイロ化されたフォルダ (子テリトリー) ではなく、1 つのビューを管理する
欠点と技術的負債
- 開発作業: 共有テーブルを管理するカスタム自動化 (フローまたは Apex) が必要
- メンバーシップの共有: サービステリトリーメンバー (STM) レコードの明示的な共有が必要
tip: 拡張性への影響
統合されたリージョンプールのない大規模なコントラクターパートナープールを管理している組織では、カバレッジギャップに直面することがよくあります。この場合、各パートナーは地理的および管理上のサイロで管理されているため、最も近い技術者はスケジューリングロジックから見えません。統合プール (取引先ベースの共有) に移行することで、組織は総合的なスケジュールで移動を 20% 以上削減し、リソースプール全体で対応可能な最も近い技術者を特定することで、サービス提供までの時間を短縮できます。
業務量ベースのリソース
外部従業員(外部業務量割り当てディメンション)の場合、アーキテクトは業務量ベースのリソースを使用してコントラクターの従業員の「概要」を表すことができます。
業務量 vs. 個人：使い分けのタイミング
- 業務量: コントラクターが独自の派遣とルーティングを管理する場合に使用します。主な焦点は、特定の実行者ではなく、実行可能な作業の合計量にあります。
- 個人: 技術者の1日をきめ細かく把握する必要がある場合に使用します。個人ベースのリソースでは、正確なロケーション、リアルタイムの対応可能状況、特定の職務割り当てを内部スタッフのように管理できます。
コントラクター共有パターンの選択
Field Service コントラクターパターンを設計する前に、このディシジョンツリーを使用して適切な共有アーキテクチャを決定します。
コントラクター共有パターン選択決定ツリー
Salesforce Field Service でコントラクターの共有パターンを選択するためのディシジョンツリー。外部リソースが使用されているかどうかから始まり、リソース種別とジョブの排他性によってツリーが分岐し、テリトリーベースの共有またはアカウントベースの共有が推奨されます。
適切なパターンの選択
| テリトリーベースの共有 | アカウントベースの共有 |
|---|---|
| 競合しない排他的なジョブ割り当てを持つ外部リソース | 内部リソースや他の外部リソースと競合する指定外部リソース |
| 同じ地理的エリアの他の外部パートナーと重複しない | 同じ地域内で複数のパートナーが事業を展開 |
| 複雑さの軽減、実装とメンテナンスの迅速化 | より複雑。レコードレベルの表示を実装して維持するために必要な追加の手順 |
Implementation Guidance - Account-Based Sharing Logic (実装ガイダンス - 取引先ベースの共有ロジック)
このパターンのコアは、ServiceResource.AccountIdまたはServiceResource.Company(コントラクター企業)リレーションをプラットフォーム共有レコードに変換する自動化レイヤーです。
アクセスの 3 つの柱
エクスペリエンスサイトで派遣担当者とサービスリソースの適切なアクセス権を検証するには、次の方法でアクセス権を制御する必要があります。
- サービスリソース共有ルール: 条件 (取引先/会社) に基づいてアクセス権を付与します。
- サービステリトリー共有ルール: 条件 (テリトリー名/ID) に基づいてアクセス権を付与します。
高度な考慮事項 - モバイルワーカーエクスペリエンス
アカウントベースの共有を使用する場合、Field Service Mobile 環境を考慮し、割り当てられた技術者の表示を記録します。
- 割り当て済みリソース共有: 標準 SFS 機能では、割り当て済みリソースにサービス予定とその親作業指示へのアクセス権が自動的に付与されます。この設定により、技術者は割り当てられた作業に対して追加のカスタム共有ルールを使用することなく、作業を実行するために必要な情報を取得できます。
- 表示リスク: 割り当てられた作業はネイティブで処理されますが、取引先やテリトリーの関連付けがない未割り当ての予定や今後の予定には注意が必要です。組織の共有設定 (OWD) が厳密に管理されていない場合や、共有セットが広すぎる場合、未割り当ての予定が統合テリトリーのすべてのユーザーに表示される可能性があります。
- Account-Territory Association: すべてのサービス予定が取引先およびテリトリーに明示的にリンクされていることを確認します。このリンクにより、モバイルアプリケーション内でクリーンな絞り込みが可能になり、地域プールに存在する未割り当ての作業でデータ漏洩が発生しないことを確認します。
実践的なビジネスシナリオ
シナリオ 1 - 都市ハブ
- 要件: 10 人の異なるコントラクターがロンドンでファイバーの設置を提供します。
- コンテキスト: テリトリーベースの共有アプローチでは、ロンドンは重複する 10 個のテリトリーに分割されます。派遣担当者は近隣の対応可能状況を確認するのに苦労し、移動時間が長くなっていました。
- **推奨事項：**アカウントベースの共有。アカウントベースの共有を利用して、統一された「グレーターロンドン」サービステリトリーを実装し、きめ細かなデータセキュリティを維持します。取引先ベースの共有により、コントラクター A の管理は各リソースにサイロ化され、SFS Optimizer では、すべての社内および社外の技術者が部門横断的に把握されます。この完全なスケジューリングアプローチにより、より効率的なルーティングロジックが実現され、SFS顧客展開におけるフィールド観測に基づく方向性の推定によって移動距離を20％以上削減できるため、リソースの稼働状況が即座に改善され、サービスの応答性も向上します。
シナリオ 2 - 業務量ベースの可用性
- 要件: ベンダーは、ボイラー修理に毎日最大 40 の「時間枠」を提供しますが、技術者の派遣はベンダー自身が管理します。
- コンテキスト: 40 個の個々のリソースレコードを管理すると、不要なオーバーヘッドが発生します。
- レコメンデーション: 定員ベースのリソースがベンダーアカウントにリンクされています。1つのリソースレコードがベンダーの1日あたりの合計定員を表し、ガントチャートをクリーンに保つことで、個々のコントラクター技術者レコードの管理負荷を軽減します。
シナリオ 3 - 季節ごとの定員スケーリング
- 要件: ある公益事業会社が、高潮の季節に 50 人の小規模な地元のコントラクターを常駐させてサージ修理に対応します。
- 状況: 毎シーズン 50 個のテリトリーを作成および削除すると、管理上の大きな負担となり、スケジュール設定および最適化エンジンの柔軟性に悪影響を及ぼします。
- **推奨事項：**アカウントベースの共有。永続的な「オーバーフロー」地域テリトリーを作成します。コントラクターがオンボードされたら、アカウントを作成し、そのリソースをリンクします。オートメーションレイヤーは、テリトリー階層の再設計を必要とせずに、即座に可視性を確保します。
シナリオ 4 - 複数ベンダーの緊急対応カバレッジ
- 要件: 優先度の高いガス漏れの場合、どのコントラクターで作業しているかに関係なく、最も近い技術者を派遣する必要があります。
- コンテキスト: テリトリーベースの共有では、最も近いテクノロジーが別のテリトリーに存在する可能性があるため、スケジュールロジックに到達できないというカバレッジギャップが生じます。
- **推奨事項：**アカウントベースの共有。ベンダーを 1 つの大きなテリトリーに統合することで、エンジンはマルチベンダープール全体の移動に基づいて完全な検索を実行し、重大な安全インシデントの応答時間を短縮します。
シナリオ 5 - 限定地域フランチャイズ
- 要件: 専門の HVAC パートナーは、遠隔地または地方の郡にサービスを提供する 10 年間の独占的な法的権利を持っています。
- コンテキスト: この地域では他のコントラクターはおらず、パートナーがスケジュールと派遣を完全に管理します。
- 推奨事項: テリトリーベースの共有。このシナリオでは、専用のサービステリトリーが最も効率的です。他のパートナーとの地理的重複がないため、テリトリー境界によって提供される分離は、追加の共有オートメーションを行うことなく、法的要件と運用要件に完全に合致します。
Implementation Guidance (実装ガイダンス) - Sharing Automation Layer (共有自動化レイヤー)
取引先ベースの共有では、ディスパッチャーユーザーとサービスリソースレコード間で共有される共通の取引先/会社識別子にレコードレベルのアクセス権を関連付けることで、表示と地域を分離します。プラットフォームのネイティブの条件に基づく共有エンジンでこの項目が評価され、テリトリー階層を変更せずにアクセス権が自動的に付与または取り消されます。
必要な 3 つのアーキテクチャコンポーネント
必要なアーキテクチャコンポーネントは次の 3 つです。
- ユーザーオブジェクトとサービスリソースオブジェクトをコントラクターアカウントにリンクする、両方のオブジェクトの共通識別子項目。
- コントラクター会社ごとにすべての派遣担当者ユーザーを集計する公開グループ。共有ルールが均一に適用されます。
- 識別子を評価し、適切な公開グループに関連レコードへのアクセスを付与する条件に基づく共有ルール。
公開グループ
テリトリーを境界として使用する代わりに、公開グループを使用して、同じ表示を必要とする派遣担当者を集計します。派遣担当者には、テリトリーベースの公開グループのメンバーシップを介して特定のテリトリー、作業指示、サービス予定が表示されます。
- グループ作成: コントラクター企業ごとに公開グループを作成します。
- メンバーの割り当て: 関連するパートナーコミュニティユーザー（派遣担当者）をそれぞれのコントラクターの公開グループに追加します。
条件に基づく共有ルール
条件に基づく共有ルールを活用して、公開グループに特定のレコードへのアクセス権を付与します。
- サービスリソース共有条件: サービスリソース共有ルールでは、サービスリソースレコードの会社/取引先識別子を対応するコントラクター公開グループと照合することで、コントラクター技術者ごとの表示を適用します。
- アクセスレベルでは、派遣担当者が割り当てをスケジュールおよび更新できるように参照・更新が許可されます。
- サービステリトリー共有条件: サービステリトリー共有条件を使用して、テリトリーによるアクセス制限のロジックを設定します。助成金派遣担当者は、作業権限が付与されている広範な地理的テリトリーにアクセスできます。例:
- 条件: ServiceTerritory.Name が「Atlanta」と一致する。
- 共有先: 関連するコントラクター公開グループ (コントラクター A、コントラクター B、コントラクター C など)。
- アクセスレベル: 参照/更新
実装に関する詳細なガイダンスは、Salesforce の公式ドキュメントを参照してください。
実装結果
アカウントベースの共有を適切に実装すると、次の利点があります。
- 統合表示: 派遣担当者は、テリトリー全体のすべての関連リソースを、手動でテリトリーを再割り当てすることなく確認できます。
- 動的アクセス: コントラクターの割り当てが変更されると、共有ルールによって管理者の介入なしで表示が自動的に調整されます。
- 競合の分離: 各コントラクターは自分のリソースのみを参照し、データプライバシーを維持します。
- スケーラブルなアーキテクチャ: 新しいコントラクターは、アカウントとコントラクター公開グループを作成するだけでオンボードでき、残りは共有ルールで自動的に処理されます。
ROI フレームワーク: 成功の測定
| KPI カテゴリ | 指標 | 対象を絞った影響 (アカウントベースの共有) |
|---|---|---|
| 運用効率 | 移動時間の短縮 | 統合プール (アカウントベースの共有) に移行すると、完全なスケジューリングにより (SFS の顧客展開におけるフィールド観察に基づく方向性の推定) 移動時間が 20% 以上削減され、リソースプール全体で最も近い対応可能な技術者を特定することで、サービス提供までの時間が短縮されます。 |
| リソースの生産性 | 技術者稼働率 | 真の最適なリソースを最適化し、移動を減らすことで生産性を向上 |
| カスタマーエクスペリエンス | 応答時間 / SLA 遵守 | 応答時間が25%以上向上 (SFS の顧客展開におけるフィールド観察に基づく方向性の推定) |
戦略的レコメンデーションと長期的な価値
将来のニーズに対応: AI、自動化、拡張性
フィールドサービス組織が事後対応型モデルから事前対応型モデルに移行するにつれて、そのアーキテクチャパターンの選択が長期的な運用の俊敏性に対する「イノベーションの上限」を設定します。
- AIと機械学習の有効化:アカウント ベースの共有により、データ サイロによって制限されるのではなく、リソース プール全体がエンジンに表示され、最適な一致が見つかることを確認します。非効率的なテリトリーのサイロ化が回避されるため、Field Service のスケジュールエージェント (Salesforce 内の AI を利用したスケジュールアシスタント) では、隔離されたマイクロテリトリーに制限されることなく、より論理的な移動パターンと技術者の割り当てが提供されます。このアプローチにより、完全な最適化が最大限に達成され、移動 KPI と技術者の準備状況が直接改善されます。アカウントベースの共有では、エンジンでリソースプール全体を可視化することで AI 駆動のスケジューリングがサポートされるため、人工的なデータサイロに制限されることなく「真の最善」の照合が可能になります。
- アーキテクチャの拡張性: テリトリーベースの共有は、孤立したテリトリーに依存するため、「パフォーマンスの壁」に直面することがよくあります。コントラクターネットワークが大きくなると、スケジューリングエンジンの効率は、隣接するテリトリーで利用可能な容量に達しない人工的な境界によって無効化されます。さらに、テリトリーベースの共有では新しいテリトリーが必要であり、パートナーごとに手動で調整する必要がある一方、アカウントベースの共有では成長が簡素化されます。組織は、アカウントおよび関連付けられたサービスリソースレコードを作成するだけで、数百のコントラクターパートナーをオンボードでき、コアの地理的テリトリー構造は変更されず、パフォーマンスが維持されます。
最終決定マトリックス: アーキテクチャの比較
| 決定要因 | テリトリーベースの分離 | アカウントベースの共有 (提案) |
|---|---|---|
| スケジュールと最適化の効率 | 低 (サイロ化されたリソース) | 高 (集計済みプール) |
| 運用実績 | 低 (同じ地理的領域をカバーするサイロ化されたテリトリーとリソース) | 高 (稼働率の最大化、移動時間の最小化、応答性/サービス提供までの時間の短縮) |
| テリトリーの拡張性 | 貧弱 (「階層の無秩序な増加」のリスク) | 優秀 (静的地理) |
| 設定の複雑さ | 低 (宣言型/OOTB) | 中 (フロー/Apex が必要) |
| パートナー データ セキュリティ | 高 (ハード境界) | 高 (プラットフォーム共有ルール) |
| 内部管理 | 高 (派遣担当者がビューを手動で切り替える) | 低 (統合されたリージョンビュー) |
Brownfield Migration: テリトリーベースの共有から取引先ベースの共有への移行
このガイドでは、主に新規実装に焦点を当てています。ただし、多くの組織はすでにテリトリーベースの共有を大規模に実行しており、多額のテリトリー階層負債を抱えています。ライブ本番環境でテリトリーベースの共有から取引先ベースの共有に移行すると、移行作業を開始する前に評価すべきアーキテクチャ上のリスクが明確に発生します。このセクションでは、既存のシステム移行の 3 つの重要な側面 (現在の状態の評価、移行戦略の決定、移行リスクの管理) について説明します。
- 無秩序なテリトリーの増加の評価: 移行計画を行う前に、現在のテリトリー階層を定量化します。主な診断質問は次のとおりです。コントラクターの分離のみを目的として存在するテリトリーと、実際の地理的境界として存在するテリトリーはそれぞれいくつありますか？コントラクター専用の子テリトリーと、運用上の親テリトリーの比率はどのくらいですか？内部リソースと外部リソースの間でテリトリーが共有されているものはありますか？それとも、すべて完全にサイロ化されていますか？この監査では、真の地理的構造と累積された分離債務を区別します。パートナー表示制御専用に作成されたテリトリーは、取引先ベースの共有で除外する有力な候補です。実際の業務地域 (スケジュールゾーン、SLA 地域、規制境界) をエンコードするテリトリーは保持され、アクセス制御とは一致しません。
- ハイブリッド移行の実行可能性: 大規模な組織の場合、テリトリーベースの共有からアカウントベースの共有へのフル カットオーバーはほとんど推奨されません。代わりに、ハイブリッド移行では、アカウントベースの共有の下で新しいコントラクターをオンボーディングしながら、従来のテリトリーベースの共有コホートを次の更新ウィンドウまで維持することでリスクを軽減します。取引先ベースの共有の自動化の範囲が取引先/会社 ID に厳密に制限され、その ID を持たないリソースが中断することなくテリトリーベースのアクセスを維持できれば、ハイブリッドアプローチはアーキテクチャ上実行可能です。ハイブリッド状態を永続的な運用モデルではなく一時的なアーキテクチャとして扱います。
- 主な移行リスク: 既存システムの移行には、プロアクティブな軽減が必要なアーキテクチャ上の3つの重要なリスクがあります。まず、新しい条件に基づくルールによってトリガーされる共有テーブルの再構築はリソースを大量に消費します。長時間に及ぶ再計算により派遣担当者の表示にギャップが生じるのを防ぐために、アクティビティの少ないウィンドウにカットオーバーをスケジュールします。2つ目は、移行中に進行中の作業指示の可視性が失われるリスクがあることです。作業指示が完了するまで、並列のテリトリーメンバーシップを維持するか、アクティブなレコードに対して共有設定を事前に行ってください。最後に、子テリトリーを削除するとリソースプールがシフトするため、最適化とスケジュールポリシーを調整します。テスト、ベースラインの実行、評価指標の取得を行い、地理的境界が有効であり続け、実際に効率の向上が実現されていることを確認します。
一般的なレコメンデーション
拡張性と最適化のROIを考慮すると、リージョンが重複する地域で複数の競合コントラクターを管理している成長著しいField Service組織には、取引先ベースの共有アプローチをお勧めします。テリトリーベースの共有ではよりシンプルで宣言型の設定が提供されますが、アカウントベースの共有ではスケジュール設定および最適化エンジンの潜在能力を最大限に引き出すことができます。可視性を地理から切り離すことで、組織はビジネスに合わせて拡張可能なテリトリー設定を維持し、次の成果を実現することができます。
- 運用効率: リソースを 1 つのプールに集約することで、エンジンはすべての作業に対して真の「最適な」技術者を見つけることができます。これにより、移動時間と運用コストを削減できます。
- サービスレベルの強化: 包括的なスケジュール設定により、最も対応可能/最も近い契約リソースを特定し、サービス提供までの時間を短縮して、顧客満足度を直接向上させることで、サービスの遅延を軽減します。
- 派遣担当者の生産性: 内部スタッフは、サイロ化された「子」テリトリーを切り替えるのではなく、統合されたビューを管理できます。
テリトリーベースの共有は、地理的に厳密に重複しないテリトリー/エリアがある高度にサイロ化されたコントラクター業務に最適です。
実装チェックリスト: 次のステップとエンゲージメント
アーキテクチャパターンを選択することが最初のステップです。実行を成功させるには、Salesforce のベストプラクティスおよびプラットフォームの機能と継続的に連携する必要があります。
次のステップ:
- 状況の監査: 現在のテリトリー階層と外部リソースの使用状況を確認します。パートナーの隔離のみを目的として作成された「コントラクターテリトリー」を特定します。階層がサイロ化して乱雑になっている場合は、取引先ベースの共有に移行する利点と労力を評価します。
- Sandbox 検証: Full Sandbox または Partial Sandbox でアカウントベースの共有パターンをプロトタイプし、あらゆる角度からエンドツーエンドで表示をテストします。
- 内部ユーザー (管理者、派遣担当者、内部技術者): 適切なアクセス権があることを確認します。一部の内部ユーザーには、全社的なアクセス権が必要です。
- コントラクターマネージャーユーザー: 表示の範囲が各自の従業員に限定されていることを確認します。
- **コントラクターの技術者 (**外部リソース): アクセス権が割り当てられた作業にのみ適切に制限されていることを確認します。
- 競合するパートナー間のデータ漏洩を防ぐためには、組織の可視性を厳密にテストすることが不可欠です。
- パフォーマンスベンチマークとROI評価: 最適化ハブとField Service Intelligenceダッシュボードを活用して、移動時間の短縮、リソースの使用率、応答時間の改善に関するインサイトを取得し、アーキテクチャの移行を正当化するために必要なデータを関係者に提供します。この before-and-after 分析は、トランジションが進行中に本番でも繰り返すことができます。
- パイロットフェーズ: Sandbox テストが完了したら、内部リソースと外部リソースが地理的に重複する 1 つまたは 2 つのテリトリーでフェーズごとのパイロットを開始します。理想的には、Sandbox でテストされたリソースを反映させます。完全な展開の前に、小規模で制御されたユーザーグループで共有ロジックを検証することが推奨されます。
- ソリューションの拡張性: 共有テーブルとサービステリトリーメンバー (STM) レコードの管理に必要なカスタム自動化 (フローまたは Apex) が、長期的な持続可能性を考慮して設計されていることを確認します。ソリューションでは、モジュラー設計パターン (トリガーフレームワークなど) を使用し、プラットフォームガバナ制限内で大量のリソース割り当てをシームレスに処理するようにロジックを構築する必要があります。
アーキテクチャ上の注意点
このガイドのすべてのパターンは、本番リリース前に Sandbox 環境で検証する必要があります。実装の動作は、組織の設定、データ量、およびビジネスルールによって異なります。
リファレンスと詳細
プラットフォーム本ドキュメンテーション (Salesforce公式):
- Field Service 開発者ガイド: Field Service データオブジェクト、API、およびカスタマイズに関するコアリファレンス
- ServiceResource オブジェクトリファレンス: SR オブジェクトの API ドキュメント
- ServiceTerritoryMember オブジェクトリファレンス: STM オブジェクトの API ドキュメント
- 条件ベースの共有ルール: アカウントベースの共有の基盤となる共有ルールを実装するための公式セキュリティガイド
- Apex Triggers Developer Guide (Apex トリガー開発者ガイド): アカウントベースの共有に必要なカスタム自動化レイヤーのリファレンス
- Apex Trigger Best Practices: 拡張可能なトリガー開発のための Salesforce の推奨パターン
Salesforce ヘルプ記事
- Guidelines for Setting Up Field Service Contractors (Field Service コントラクターの設定ガイドライン): Salesforce Field Service でコントラクターリソースを設定するためのガイダンス
- Define Capacity-Based Resources: 記事で参照されている業務量ベースのリソースを設定するための公式ドキュメント
- Field Service 最適化エンジンのしくみField Service 最適化のリファレンス。最適化の実行に関するガイダンス。記事で参照されている取引先ベースの共有の利点と ROI にも関連します。
- Set Up Optimization Hub (最適化ハブの設定): 「次のステップ」セクションで参照する最適化ハブの設定ガイド
- Experience Cloud の概要: アカウントベースの共有のパートナーコミュニティ設定 (プラットフォーム上管理)
Salesforce Trailhead/Learning
- Field Service の基本: テリトリー、リソース、営業時間をカバーする基本モジュール
- Field Service Scheduling: このガイドの最適化の説明の基盤となるスケジュールの概念
- Field Service Optimization: 最適化の設定とスケジュールポリシーの詳細
- Salesforce Security and Who Sees What: 共有ルールとデータセキュリティの基本
- Build a Partner Portal with Experience Cloud: 記事で参照されている Experience Cloud パートナー設定のハンズオンガイド
業種AND戦略的コンテキスト
- Salesforce State of Service Report第7版: 世界中のサービス担当者6500人を対象とした最新版。このホワイト ペーパーのROIの議論に直接関連する、Field Service、AIの導入、技術者の生産性トレンドに関する専用のインサイトを提供します。
- Agentforce for Field Service: AI を搭載した Salesforce の Field Service プラットフォーム。セクション 13 の AI と将来を見据えた議論に直接関連します。 アカウントベースの共有の統合リソースプールにより、Agentforce のスケジュールインテリジェンスが最大限に高まります。
- Gartner Market Guide for Field Service Management (Field Service 管理向け Gartner 市場ガイド): FSM 市場の展望に関する最新の Gartner 分析 (Gartner サブスクリプションが必要)。
著者について
モール・エプスタイン
Salesforce Field Service、シニアサクセスアーキテクト
ジョージア工科大学で産業工学を学び、MBA を取得した Mor は、ミッションクリティカルな Field Service の実装をブロック解除して加速した実績のある信頼できるアドバイザーです。グローバルな顧客対応経験と実践的なデータ主導の問題解決により、世界中のフィールドサービス組織にとって頼れるリソースとなっています。Mor は、スケジュール設定と最適化のプロセスを通じて顧客を効果的にサポートし、インテリジェントなスケジューリングの可能性を最大限に引き出すことで、効率およびサービス提供における目に見える成果の向上を実現します。
Lee Ephrati
Salesforce Field Service、シニア成功アーキテクト
Lee は、10 年以上 Salesforce の提供とアドバイザリの経験を持ち、Field Service アーキテクチャとモバイルソリューション設計を専門とする経験豊富なテクニカルアーキテクトです。Lee は、複雑な組織構造をネイティブの SFS プラットフォームおよびモバイルアプリケーションに合わせて調整し、グローバル企業の業務 ROI を最大化することに重点を置いています。Leeは、顧客第一の考え方と包括的なプラットフォームKnowledgeを背景に、世界中のSalesforce顧客に永続的な価値を提供するコンサルティングアプローチを展開しています。