SAP SF 事業部門
SAP SF 事業部門
事業部門は、SuccessFactors Employee Centralにおける第3レベルの組織マスタデータオブジェクトであり、標準的な組織チェーンにおいて、ビジネスユニットの直下、部門の直上に位置します。ビジネスユニット内の部門や原価センタを、製品ライン、機能領域、または地理的なサブリージョン(例:東日本営業部門、コンシューマプロダクツ部門、製造部門)にグループ化します。コンサルタントが設定するすべての部門(事業部門レベルが有効な場合)は、最終的に1つの事業部門に割り当てられます。この記事では、事業部門とは何か、より広い階層における位置づけ、およびEmployee Centralコンサルタントが設定するすべてのフィールドについて説明します。
パート 1: 事業部門 — 中核概念(全モジュール)
1.1 事業部門とは

Division(ディビジョン)は、Business Unit(ビジネスユニット)の2階層下に位置するファンデーションオブジェクトです。これは、主要な事業ラインの境界そのものを表すのではなく、その境界を製品ライン、機能領域、またはサブリージョンにさらに細分化したものです。Business Unitが「組織のこの部分は、どの主要な事業ラインまたは地域に属するか」に答えるのに対し、Divisionは「その事業内で、組織のこの部分はどの製品ライン、機能、またはローカルサブリージョンに属するか」に答えます。Department(部門)とCost Center(原価センタ)は、そのグループをさらに細分化するために、その下にネストされます。
| 項目 | 詳細 |
|---|---|
| 役割 | 組織階層の第3レベル — 1つ以上の部門を単一の事業単位の下にグループ化し、通常は製品ライン、機能領域、または地理的サブリージョンを表します |
| 使用するモジュール | エンプロイーセントラル(所有者 — ファンデーションオブジェクトフレームワーク)、リクルーティング(求人は多くの場合、事業部門ごとにスコープ設定またはルーティングされます)、報酬管理(資格ルールと予算プールは多くの場合、事業部門ごとにセグメント化されます)、ピープルアナリティクス / レポーティング(事業部門は通常、デフォルトの組織図表示および人員数レポートレベルです) |
| トランザクション | 管理センター → 「組織、給与、ジョブ構造の管理」(ファンデーションオブジェクトレコードの作成/編集);「データのインポートとエクスポート」(CSVによる一括ロード);ビジネスルールは、他の雇用フィールドから事業部門を自動的に導出できます |
| キーテーブル | OData APIエンティティ FODivision(ファンデーションオブジェクト) — SuccessFactorsには従来のABAPテーブルはありません;各レコードはテーブル行ベースではなく、有効日付ベースです |
| S/4HANAに関する注意 | 事業部門には単一の汎用的なS/4HANA対応物はありません — クライアントは様々に、機能領域、利益センタにマッピングするか、S/4HANAに同等のグループ化が存在しない場合はSuccessFactorsネイティブのままにします |
1.2 事業部門設定パターン

部門は固定のSAPタイプコードから選択されるわけではありません。しかし、すべての導入において、稼働前に2つの独立した次元を決定する必要があります。すなわち、レベルが編成される設計軸と、そのレベルが使用されるかどうかです。
| パターン | マーカー | ユースケース | 主要な動作 |
|---|---|---|---|
| 製品ライン別部門 | 製品ライン | クライアントがビジネスユニット内の部門を主に製品またはサービスラインで編成している | 部門名は製品/サービスラインを反映(例:「コンシューマ製品部門」);その下の部門は通常、そのライン内の機能チームを表す |
| 地域別部門 | 地域 | クライアントが単一のビジネスユニット内の部門を主に地域で編成している | 部門名はサブ地域を反映(例:「東日本部門」);その下の部門は通常、その地域内の機能または製品チームを表す |
| 部門レベル有効化 | 有効 | ビジネスユニットに、部門の上位グループ化を正当化するのに十分な組織的複雑性がある | すべての部門は部門に割り当てられる必要がある;部門がチェーン内の必須リンクとなる |
| 部門レベルバイパス | バイパス | 部門がビジネスユニットに直接紐付く、よりシンプルな組織 | 部門ファンデーションオブジェクトタイプはシステムに設定されたままであるが、それを参照するアクティブなレコードはゼロ;組織図とレポートはビジネスユニットから部門へ直接スキップされる |
設計原則: 設計軸(製品ライン別 vs. 地域別)を決定し、そのレベルをブループリント時に一度だけ有効化する。その後作成されるすべての部門はその軸を継承する。どちらかの決定を後から変更するには、すべての部門を新しい事業部コードの下に再親設定する必要がある。
1.3 組織レベルとデータ階層

具体的な例を用いたデータ階層
Client (SuccessFactors Instance)
│
└── Legal Entity "LE_JP01" — Japan Legal Entity, Company Code JP01
│
└── Business Unit "BU_Sales" — Sales HQ, of LE_JP01
│
└── Division "DIV_East" — East Japan, of BU_Sales
│
├── Department "DEPT_S01" — Sales Team 1, of DIV_East
│ │
│ └── Cost Center "CC_1000" — Sales cost center, of DEPT_S01
│
└── (external sync) ──> S/4HANA Profit Center / Functional Area
Location "LOC_TKY01" — Tokyo HQ, Asia/Tokyo TZ
(independent tenant-level master — not nested under Division)設計原則: ビジネスユニット → 事業部門 → 部門 → 原価センタは、ビジネスユニット以下の厳格な単一親チェーンです。事業部門レベルがスキップされる場合(1.2参照)、部門は代わりにビジネスユニットに直接接続されますが、使用されるレベル以下のチェーンは全体を通じて単一親のままです。
1.4 他のマスタデータオブジェクトとの統合

事業部門は単独で存在するものではなく、上位のビジネスユニットへの必須のリンクであり、その下に編成されるすべてのものを必須でグループ化する下位の単位です。
| オブジェクト | 関係性 | 実務上の注意点 |
|---|---|---|
| 事業部門 | 直接の親 (N:1) — すべての事業部は、必ず1つの事業部門に割り当てられる | 稼働後に事業部の事業部門割当を変更すると、その下位のすべての部門および原価センタの親が再設定されるため、ルーチン的な編集ではなく正式な組織再編として扱う必要がある |
| 部門 | 直接の子 (1:N) — 事業部レベルが有効な場合、すべての部門は必ず1つの事業部に属する | 事業部の下で最初に必須となるステップ。事業部レベルをスキップする場合、部門は1階層上の事業部門に直接アタッチされる |
| ポジション | 部門チェーンを介した間接的な関係 — ポジション自体は事業部ではなく部門を参照する | 事業部で区分した人員数や要求伝票レポートを作成する際に関連する。集計パスは部門を経由し、ポジション上の直接フィールドではない |
| 報酬予算 | 予算オブジェクト自体は部門を参照するが、配分とレポートは事業部レベルで行われることが多い | 報酬チームは、システムフィールドが部門を指しているにもかかわらず、年次計画サイクルのレポート作成のために部門レベルの予算を事業部レベルにロールアップすることが一般的である |
| S/4HANA 利益センタ / 機能領域 | マッピングが存在する場合、S/4HANA COを実行するクライアント向けの外部同期元/先 | ブループリント時に、クライアントの事業部がS/4HANAのどのオブジェクト(利益センタ、機能領域、またはなし)にマッピングされるかを確認する。事業部には、法人が持つような明確な1:1の会社コード相当物がないためである |
パート 2: SF 固有のフィールド詳細
2.0 SFの所有範囲

| データセクション | SF関与 | 備考 |
|---|---|---|
| コア識別情報 | ◎ オーナー | 外部コード、名称、有効開始日 |
| 事業部門割当 | ◎ オーナー | 親事業部門、部門長、ソート順 |
| ステータス&ライフサイクル | ◎ オーナー | 有効/無効ステータス、有効日付による変更履歴 |
| S/4HANA統合 | ○ FI/CO/Basisと共有 | 外部コードマッピング、同期方向、同期頻度 |
凡例: ◎ = オーナー / クリティカル、○ = 直接関与
2.1 コア識別

コア識別情報は、事業部門が存在するために必要な最小限のレコードであり、それに属するすべての部門が「上位」の事業部門を参照する際に使用するものです。
| フィールド | 説明 | 実務上の使用例 |
|---|---|---|
| 外部コード | 事業部門の一意識別子 | 下流のすべての参照(部門、統合ペイロード)が指すキー値です。統合チームとコーディング規則を一度決定してください。本番稼働後に変更すると、古い値に基づくミドルウェアマッピングがすべて壊れます。 |
| 名称 | 事業部門の表示名 | グローバルインスタンスでは言語パックごとにローカライズ可能です。同期されたS/4HANAの利益センタまたは機能領域が存在する場合、財務部門と人事部門が同じグループをシステム間で認識できるよう、命名規則を統一してください。 |
| 有効開始日 | このバージョンのレコードが有効になる日付 | すべてのフィールド変更は上書きではなく、新しい有効日付行として記録されます。これにより、特定日付時点の組織図クエリで過去の構造を再構築できます。監査や組織再編の履歴にとって重要です。 |
| 有効日付履歴 | この事業部門レコードの以前のバージョンの連鎖 | 「日付Xにおけるこの事業部門の名称/ステータス/ビジネスユニットは何か」という質問に答えるために使用します。コンサルタントは履歴行を削除せず、新しい有効日付エントリで前方修正する必要があります。 |
2.2 事業単位の割当

このセクションでは、事業部門レコードをその親となるビジネスユニット、およびコンサルタントが組織図目的で設定する表示/所有権属性に結び付けます。
| フィールド | 説明 | 実務上の使用例 |
|---|---|---|
| 事業部門 | この事業部門が所属する親のビジネスユニット | 必須の単一値割り当て。この事業部門の下に作成されるすべての部門は、間接的に同じビジネスユニットコンテキストを継承します。事業部門を別のビジネスユニットに再割り当てする場合は、正式な組織再編としてモデル化する必要があります。これは、下流のすべての部門/原価センタに対して暗黙的に示される事業ラインコンテキストを遡及的に変更するためです。 |
| 事業部門長 | 事業部門の責任者/所有者として指定された従業員(設定されている場合) | ポジションベースの組織図表示を駆動し、ワークフローファンデーションルールにおけるエスカレーション承認者を指定するために一般的に使用されます。クライアントが正式な事業部門レベルの所有者ロールをモデル化しない場合は、空白のままにします。 |
| ソート順 | 事業部門を兄弟組織と一緒に表示する際に使用される表示順序 | 純粋に表示上の設定です。組織図や選択リスト表示での順序を制御しますが、データ階層自体には影響しません。例えば、クライアントが主力製品ラインの事業部門をサポート機能よりも前に表示したい場合などに、一貫性を保つために役立ちます。 |
2.3 ステータスとライフサイクル

ステータスは、事業部門が新しい割り当てに利用可能かどうかを管理します。このセクションでは、コンサルタントが組織再編、合併、および製品ラインの統合を処理します。
| フィールド | 説明 | 実務上の使用例 |
|---|---|---|
| ステータス | 有効/無効フラグ | 事業部門を無効に設定しても、既存の部門割り当ては削除されません。今後作成される新規レコードでその事業部門が選択できなくなるだけです。無効化は、管理者がシステム上で変更を行った日付ではなく、実際の組織再編日と一致するように有効日付を設定する必要があります。 |
| 無効化の影響 | 無効な事業部門による下流への影響 | 無効化する前に、その事業部門を参照している部門がないか確認してください。組織再編や製品ライン統合のシナリオでは、それらの部門をまず存続する事業部門に再割り当てする必要があります。 |
2.4 S/4HANA 統合

S/4HANA CO と SuccessFactors Employee Central を併用しているお客様の場合、S/4HANA には単一の専用「事業部門」オブジェクトがないため、事業部門の調整は法人に比べて標準化されていません。
| フィールド | 説明 | 実務上の使用例 |
|---|---|---|
| 外部コードマッピング | SuccessFactors外部コードとS/4HANAソースオブジェクト値の相互参照 | ブループリント時に、クライアントの事業部門がS/4HANAのどのオブジェクト(利益センタ、機能エリア、またはなし)にマッピングされるかを確認します。この判断により、マッピングテーブル自体が必要かどうかが決まります。 |
| 同期方向 | S/4HANAがマスタシステム(SFへのインバウンド)か、事業部門がSuccessFactorsネイティブか | 多くのクライアントは、法人や原価センタが同期されている場合でも、事業部門をSFネイティブとして扱います。これは、S/4HANAがこのレベルで同等のクリーンなグループを常に保持しているとは限らないためです。メンテナンス時の曖昧さを避けるため、所有権を明示的に確認してください。 |
| 同期頻度 | 同期を使用する場合の、バッチ(スケジュール) vs. ニアリアルタイムレプリケーション | 通常、法人/原価センタの同期に使用されるものと同じ統合コンテンツまたはミドルウェアを介して提供されます。バッチ同期のみの場合、新しく作成されたS/4HANAソースオブジェクトはEmployee Centralですぐに使用できません。組織再編の本番稼働は、同期スケジュールに合わせて計画してください。 |
次に読むべきもの
L1) Big Picture
| ID | Category | Title |
|---|---|---|
| sf-001 | Overview | SAP SuccessFactorsとは何ですか? |
L2-A) Master Data
| ID | Category | Title |
|---|---|---|
| sf-a01 | Overview | SAP SuccessFactors マスタデータ:概要、階層、関係性 |
| sf-a02-01 | Master Data | SAP SF 法人 |
| sf-a02-02 | Master Data | SAP SF ビジネスユニット |
| sf-a02-03 | Master Data | SAP SF 事業部門 📍 |
| sf-a02-04 | Master Data | SAP SF 部門 |
| sf-a02-05 | Master Data | SAP SF 原価センタ |
| sf-a02-06 | Master Data | SAP SF ロケーション |
| sf-a02-07 | Master Data | SAP SF ジョブファミリー |
| sf-a02-08 | Master Data | SAP SF ジョブコード |
| sf-a02-09 | Master Data | SAP SF 給与グレード |
| sf-a02-10 | Master Data | SAP SF ポジション |
| sf-a03-01 | Master Data | SAP SF 権限グループ |
| sf-a03-02 | Master Data | SAP SF 権限ロール |
| sf-a03-03 | Master Data | SAP SF 休日カレンダー |
| sf-a03-04 | Master Data | SAP SF 勤務スケジュール |
| sf-a03-05 | Master Data | SAP SF タイムタイプ |
| sf-a03-06 | Master Data | SAP SF 時間プロファイル |
| sf-a03-07 | Master Data | SAP SF 評価尺度 |
| sf-a03-08 | Master Data | SAP SF 目標計画テンプレート |
| sf-a03-09 | Master Data | SAP SF パフォーマンスフォームテンプレート |
| sf-a03-10 | Master Data | SAP SF ルートマップ |
| sf-a03-11 | Master Data | SAP SF 報酬計画 |
| sf-a04-01 | Master Data | SAP SF 担当者 |
| sf-a04-02 | Master Data | SAP SF エンプロイメント |
| sf-a04-03 | Master Data | SAP SF 従業員プロファイル |
L2-B) Transaction
| ID | Category | Title |
|---|---|---|
| sf-b01 | Overview | SAP SuccessFactors トランザクション:プロセスフロー、階層、関係性 |