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

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

事業単位は、固定のSAPタイプコードから選択されるわけではありません。しかし、すべての導入において、本稼働前に2つの独立した次元を決定する必要があります。すなわち、レベルが編成される設計軸と、そのレベルが使用されるかどうかです。
| パターン | マーカー | ユースケース | 主要な動作 |
|---|---|---|---|
| 機能事業部門 | 機能 | クライアントが主に製品/サービスライン(例:営業、製造、研究開発)で組織化されている | 事業部門名はビジネス機能を反映。その下の事業部は、通常、その機能の地域別内訳を表す |
| 地域事業部門 | 地域 | クライアントが単一の法人格の下で主に地域別に組織化されている | 事業部門名は地域または市場を反映(例:「APAC事業部門」)。その下の事業部は、通常、その地域内の製品ラインまたは機能を表す |
| 有効化された事業部門レベル | 有効化 | 法人格が、事業部の上位に中間グループを設けるのに十分な組織的複雑性を持つ | すべての事業部は事業部門に割り当てられる必要がある。事業部門はチェーン内の必須リンクとなる |
| バイパスされた事業部門レベル | バイパス | 事業部(または部門)が法人格に直接紐付く、より単純な組織 | 事業部門のファンデーションオブジェクトタイプはシステム上に設定されたままであるが、それを参照するアクティブなレコードはゼロ。組織図とレポートは法人格から事業部へ直接スキップされる |
設計原則: 設計軸(機能別 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 Organizational Management (Org Unit / Business Area)設計原則: 事業単位 → 事業部門 → 部門 → 原価センタは、法的エンティティの下での厳格な単一親チェーンです。事業単位レベルがスキップされる場合(1.2参照)、事業部門は法的エンティティに直接アタッチされますが、使用されるレベルより下のチェーンは全体を通じて単一親のままです。
1.4 他のマスタデータオブジェクトとの統合

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

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

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

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

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

S/4HANA HR/OM と SuccessFactors Employee Central を併用しているお客様の場合、S/4HANA には単一の専用「事業部門」オブジェクトがないため、事業部門の調整は法人の調整ほど標準化されていません。
| フィールド | 説明 | 実務上の使用例 |
|---|---|---|
| 外部コードマッピング | SuccessFactors外部コードとS/4HANAソースオブジェクト値の間の相互参照 | ブループリント時に、クライアントのビジネスユニットがどのS/4HANAオブジェクト(PPOME経由の上位組織ユニット、事業領域、またはなし)にマッピングされるかを確認します。この判断により、マッピングテーブル自体が必要かどうかが決まります。 |
| 同期方向 | S/4HANAが記録システム(SFへの受信)であるか、ビジネスユニットがSuccessFactorsネイティブであるか | 多くのクライアントは、法人や原価センタが同期されている場合でも、S/4HANAの組織構造が常にクリーンな同等のグループを保持しているとは限らないため、ビジネスユニットをSFネイティブとして扱います。メンテナンス中の曖昧さを避けるために、所有権を明示的に確認します。 |
| 同期頻度 | 同期が使用される場合の、バッチ(スケジュール) 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 トランザクション:プロセスフロー、階層、関係性 |