JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

July 17, 2026 · 11 min read

SAP Service Cloud チーム

チームとは、SAP Service Cloudにおけるケース割り当てのための従業員グループです。「テクニカルサポート」のような名前付きプールであり、ケースを個人ではなく、そのグループ単位でルーティングできます。これは、フェーズ1の他の2つのマスタ（従業員と組織ユニット）からデータを取得しますが、どちらかの真の子オブジェクトではありません。従業員の組織ユニットを変更しても、その従業員のチームメンバーシップは自動的に移動せず、チームと従業員のリンク（チームリーダーとメンバー）は、包含関係ではなく、別個の相互参照として管理されます。フェーズ1の他の4つのオブジェクトとは異なり、チームはアクセス制御やIDレコードではなく、ケースルーティングにグループターゲットを提供するためだけに存在します。また、このフェーズにおいて、実際に文書化された下流のコンシューマ（ケースルーティングルール）を持つ唯一のオブジェクトです。この記事では、その依存関係、他の従業員＆組織マスタとの関係、および管理者がサービスチームを構築・保守する際に設定するすべてのフィールドをマッピングします。

パート 1: チーム — 中核概念（全モジュール）#

1.1 チームとは何か#

チームは、ケース割り当てのプールを表すものであり、組織図のノードでもログインでもありません。これは、複数の従業員をグループ化し、ケースをグループ全体に割り当てられるようにするもので、通常はエスカレーションと監督のために1人のメンバーがチームリーダーに指定されます。これにより、正式な組織単位階層や個々の従業員のワークロードとは独立して、ケアルーティングが作業グループを直接対象とできるようになります。

1.2 チーム構成パターン#

Service Cloud は固定の「チームタイプ」フィールドを提供しません。以下の実践的なパターンは、チームレコードが作成された後に実際にどのように人員配置され、使用されるかを説明しています。これを誤ると、ルーティング対象が人員不足になり、未割り当てのケースが滞留するか、メンバーが多数の重複するチームに分散され、どのプールが特定のケースに対して実際に責任を持つのか誰にもわからなくなります。

設計原則: ケースが実際にどのように引き取られるべきかに基づいてチームを構築し、形式的な組織図に基づいて構築しないこと。組織単位を一対一で反映したチームは、実際のルーティングニーズを解決するためではなく、反射的に作成されたことを意味することが多い。

1.3 組織レベルとデータ階層#

データ階層の具体例（ゾーンA · 従業員＆組織 — テナントレベル；SAP Service Cloudには、これを上位とする会社コード/プラントのスコープはありません）

Client (SAP Service Cloud Tenant)
   │
   └── Organizational Unit "SVC-ORG-001" — Service Dept (3-level hierarchy: HQ → Dept → Section)
          │
          ├── Employee "EMP-001" — Taro Yamada (external sync from SuccessFactors Employee Central)
          │      │
          │      └── Business User "YAMADA01" — system login for EMP-001
          │
          └── Team "SVC-TEAM-01" — Technical Support (5 members)

Business Role "SVC_AGENT" — Service Agent · Standard (independent master, no prerequisite)
Business User "YAMADA01" ── assigned to ──> Business Role "SVC_AGENT"
Team "SVC-TEAM-01" ── references ──> Employee "EMP-001" (team lead / member)
Case Routing Rule "RT-001" ── targets ──> Team "SVC-TEAM-01" (Phase 6 · downstream case-assignment consumer)

設計原則: チームは、実際の下流コンシューマが既に配置されているフェーズ1の従業員および組織マスタです。ケースルーティングルール「RT-001」は、チーム「SVC-TEAM-01」を直接ターゲットとしています。チーム自身の上流リンク（リーダー/メンバーに対する従業員、組織コンテキストに対する組織単位）は参照であり、包含ではありません。組織単位「SVC-ORG-001」を編集したり、従業員「EMP-001」を別の組織単位に再割り当てしても、チーム「SVC-TEAM-01」の所属メンバーが自動的に変更されることはありません。チームメンバーシップはチーム自体で管理されます。

1.4 他のマスタデータオブジェクトとの統合#

チームは単独では存在しません。これは2つの上流マスタからデータを取得し、正確に1つの文書化された下流コンシューマにデータを提供します。このフェーズでは、2つのアクセス制御オブジェクトとはまったく関係がありません。

パート 2: SC固有のフィールド詳細#

2.0 SCオーナーシップの範囲#

凡例: ◎ = オーナー / クリティカル、○ = 直接関与

2.1 コア識別子とステータス#

これらのフィールドは、このチームが何であるか、その表示名、および現在新しいケースの割り当てを受け付けるかどうかを定義します。以下のリード、メンバーシップ、組織コンテキストの各フィールドは、これらが設定されて初めて意味を持ちます。

2.2 チームリーダーとメンバーシップ#

これらのフィールドは、チームを監督する責任者と、そのチームにルーティングされたケースを実際に引き受けられる従業員を決定します。どちらも、従業員自身の組織単位割当とは独立して管理されます。

2.3 組織コンテキスト#

このフィールドは、チームを組織単位に関連付けるもので、報告目的のみに使用されます。この関連付けによってチームがその組織単位の子になるわけではなく、各メンバー自身の組織単位と一致する必要もありません。

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction