JinJin48

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

July 19, 2026 · 20 min read

SAP SF ロードマップ

ルートマップは、承認ワークフローの再利用可能な順序付けられた一連のステップ（自己評価、マネージャ評価、キャリブレーション、最終など）を定義するマスタデータオブジェクトであり、各ステップの承認者決定方法とともに、起動されたレビューフォーム（実際の運用では目標計画）が起動から完了までどのように進むかを制御します。これは、フェーズ2（権限とシステム設定）の「目標とパフォーマンス設定」サブブロックで設定され、モジュールのセットアップフローによると、その唯一の前提条件は権限ロールであり、パフォーマンスフォームテンプレートや目標計画テンプレートではありません。この違いは、以下のセクション1.3のSuccessFactorsマスタデータランドスケープに対して独立して確認されています。この記事では、ルートマップとは何か、その一般的なステップパターンのバリエーション、ランドスケープの「タレント＆報酬」ゾーンにおいて「権限＆時間」ゾーンへの単一の参照を持つ独立したオブジェクトとしてどのように位置づけられるか、そしてAdmin Centerコンサルタントが設定するすべてのフィールドについて説明します。

パート1: ロードマップ — 中核概念（全モジュール共通）#

1.1 ルートマップとは#

Route Mapはクライアントレベル（テナントレベル）のファンデーションオブジェクトであり、それ自体は従業員データを一切保持しません。承認ワークフローの形状（その順序付けられたステップと各ステップの承認者解決ロジック）を定義するものであり、個々の従業員がそのワークフローを実際に進行する状況を定義するものではありません。起動されたフォームや計画は、起動時点のRoute Mapのステップシーケンスをスナップショットとして取り込み、各従業員の個別の進行状況を別々に追跡します。Route Map自体は、再利用可能でバージョン管理された設定オブジェクトとして維持されます。

1.2 ルートマップ ステップパターンバリアント#

ルートマップのステップパターンは、単なる見た目の選択ではありません。起動されたフォームが通過する承認の引き継ぎ回数、評価が確定する前にキャリブレーションが強制されるかどうか、そして実際にレビューサイクル全体が完了するまでにどれだけの時間がかかるかを直接決定します。軽量なチェックポイントに対してステップシーケンスを過剰に構築すると、不要な引き継ぎで評価者を苛立たせます。一方、報酬に連動する年次レビューのためにステップを過小に構築すると、経営陣が実際に必要とするキャリブレーションステップが省略されてしまいます。

設計原則: ルートマップのステップ数と複雑さを、レビューの実際の目的に合わせること — 強制的なキャリブレーションステップを伴う軽量なチェックポイントルートマップは、対応するガバナンス上のメリットがないまま摩擦を生み出します。一方、キャリブレーションなしの報酬連動型年次レビュールートマップでは、報酬プロセスが通常依存するマネージャー間の一貫性チェックを行わずに評価が確定してしまいます。

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

具体的な例を用いたデータ階層

Route Mapは、SuccessFactorsマスタデータランドスケープ（ゾーンD）のテナントレベルの「タレント＆報酬」ゾーンに位置していますが、Rating Scale、Goal Plan Template、Performance Form Template（これらは単一の直列チェーンを形成）とは異なり、他のゾーンDノードとの確固たる親子関係を持たない、スタンドアロンのクライアントレベルオブジェクトです。ランドスケープにおける唯一の接続は、ゾーンC（権限＆時間）への単一のアウトバウンドクロスゾーン参照です。

Client (SuccessFactors Instance)
   │
   ├── Route Map "RM_Std" — Self → Manager → Calibration → Final  ← this article
   │      │
   │      └── references ──> Permission Role "PR_ESS" — Employee Self-Service  (Zone C, see SF-A03-02)
   │
   └── Performance Form Template "PFT_Annual2024" — Annual Review, 4-section, of GPT_2024
          (same Zone D; no landscape data-model connector to Route Map — real-world usage only, see Section 1.4)

【必須】ランドスケープ検証に関する注意事項: モジュールMaster.mdのER図では、Route MapがPerformance Form Templateの子としてネストされています（「Rating Scale → Goal Plan Template / Performance Form Template → Route Map」）。同じ図ブロック内に、別途「Route Map ←── Permission Role」という注釈が併記されています。一方、Setup Flowでは、Route Mapの前提条件として「21. Route Map ← (Permission Role)」の1つだけがリストされており、Permission Role（Performance Form Templateではない）がRoute Mapの唯一の依存関係として記載されています。公開済みのSuccessFactors Master Data Landscape（sf-a01/images/04-sf-a01-master-landscape.html、ゾーンD、本セッションでHTML/SVGソースから直接検証済み、SF-A03-07/08/09で既に記録された独立した検証と一致）は、ER図ではなくSetup Flowと同じ方法でこれを解決しています。Route Map（RM_Std）はゾーンDのRow 4ノード（top:1295px）として独立して配置されており、SVG内のすべての<line>要素をスキャンした結果、そのノードで開始または終了するコネクタは存在しません。ゾーンDの2つの実線チェーンは、その1行手前で終了しています（RS_5pt → GPT_2024 → PFT_Annual2024はx=1060でy=1150に終了、CP_Merit2024 → CT_Merit → ER_FT1Yはx=1360でy=1245に終了）。Route Mapノードに接続されている唯一の要素は、そのカード内のref-chipで「↗ PR_ESS」と表示されており、ゾーンDの凡例ではこれを「Route MapはゾーンCのPermission Roleを参照する」と明示しています。これはゾーン間参照であり、親子コネクタではなく、Performance Form Template、Goal Plan Template、Rating Scaleへの接続でもありません。したがって、このランドスケープに記録されているRoute Mapの唯一のデータモデル関係はPermission Roleとの関係です — セクション1.4を参照してください。 実際のSuccessFactors導入環境では、Route Mapは通常、Performance Form Template（および目標承認ワークフローの場合はGoal Plan Template）のセットアップの一部として選択されバインドされます — セクション2.4を参照してください。ただし、本ランドスケープによれば、そのバインディングは起動時のテンプレート選択であり、保存されたデータモデルコネクタではないため、ここでは統合ではなく使用法として説明されています。

設計原則: ルートマップは、以前の権限ロールと同様に、それ自体には従業員データを持たず、データモデルに真の親オブジェクトが存在しないため、その階層上の位置は意図的に浅くなっています。つまり、単一のクライアントレベルのノードであり、その唯一の構造的関係は、承認者解決のための権限ロールへの外部参照です。コンサルタントにとって重要な複雑さは、すべてルートマップ自体のステップ設定（パート2）にあり、追加の階層ネスティングにはありません。

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

Route Mapは、ランドスケープ内で確認済みのデータモデル関係を1つだけ持ちます — Permission Roleへのアウトバウンド参照です — 視覚的にはRating Scale → Goal Plan Template → Performance Form TemplateのチェーンやCompensationチェーンオブジェクトと同じTalent & Compensationゾーン内に配置されていますが。ER図でRoute MapがPerformance Form Templateの下にネストされているのを見たコンサルタントは、そのネストをランドスケープで検証されたコネクタではなく、実際の使用状況の説明として扱う必要があります。完全な検証についてはセクション1.3を参照してください。

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

2.0 SFの所有範囲#

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

2.1 ルートマップ定義（コア識別）#

Route Map Definitionは、Route Mapが存在するために必要な最小限のレコードです。これは、すべてのPerformance Form TemplateのRoute Map Bindingフィールド（SF-A03-09、セクション2.4）およびすべてのステップレベルのPermission Role参照が解決される対象です。

2.2 ワークフローステップの設定#

ワークフローステップ設定は、起動されたフォームや計画が通過する順序付けられたパスを実際に定義する反復可能な子レコード（ステップごとに1行）であり、セクション1.2のステップパターンバリアントが物理的に構築される場所です。

2.3 ステップレベル承認者割当#

ステップレベル承認者割当とは、各ステップの誰が担当するかを決定するものです。これは、ランドスケープの確定したルートマップを実装するフィールドグループ → 権限ロール参照（セクション1.3/1.4）です。

2.4 テンプレートバインディングでの使用#

ルートマップ自体には従業員データは含まれておらず、単独で起動されることもありません。このルートマップがバインドされたパフォーマンスフォームテンプレート（または実際の運用では目標計画テンプレート）が起動されたときにのみ有効になります。このセクションでは、そのバインドが実際にどのように機能するかを説明し、セクション1.3で確立した「正直さの区別」を意図的に繰り返します。これは実際の運用上の使用法であり、検証済みのランドスケープデータモデルコネクタではありません。

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction