JinJin48
JinJin48
SAP Consultant | BTP · S/4HANA · US Global Rollout
· 12 min read

SAP SF ビジネスユニット

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


パート 1: 事業領域 — 中核概念(全モジュール共通)

1.1 ビジネスユニットとは

ハブアンドスポーク図。中央にビジネスユニットが配置され、法的エンティティ、事業部門、S/4HANA組織管理に接続されている

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 ビジネスユニット設定パターン

機能設計と地域設計の軸、および有効化とバイパスされたビジネスユニットレベルを比較した2x2マトリックス

事業単位は、固定のSAPタイプコードから選択されるわけではありません。しかし、すべての導入において、本稼働前に2つの独立した次元を決定する必要があります。すなわち、レベルが編成される設計軸と、そのレベルが使用されるかどうかです。

パターンマーカーユースケース主要な動作
機能事業部門機能クライアントが主に製品/サービスライン(例:営業、製造、研究開発)で組織化されている事業部門名はビジネス機能を反映。その下の事業部は、通常、その機能の地域別内訳を表す
地域事業部門地域クライアントが単一の法人格の下で主に地域別に組織化されている事業部門名は地域または市場を反映(例:「APAC事業部門」)。その下の事業部は、通常、その地域内の製品ラインまたは機能を表す
有効化された事業部門レベル有効化法人格が、事業部の上位に中間グループを設けるのに十分な組織的複雑性を持つすべての事業部は事業部門に割り当てられる必要がある。事業部門はチェーン内の必須リンクとなる
バイパスされた事業部門レベルバイパス事業部(または部門)が法人格に直接紐付く、より単純な組織事業部門のファンデーションオブジェクトタイプはシステム上に設定されたままであるが、それを参照するアクティブなレコードはゼロ。組織図とレポートは法人格から事業部へ直接スキップされる

設計原則: 設計軸(機能別 vs. 地域別)を決定し、そのレベルをブループリント時に一度だけ有効化します。その後作成されるすべての事業部門はその軸を継承します。どちらかの決定を後から変更するには、すべての事業部門を新しいビジネスユニットコードの下に再親付けする必要があります。


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

SuccessFactorsマスタデータランドスケープのゾーン切り抜き:組織ファンデーション階層におけるゾーンA — 事業部を示す

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

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 他のマスタデータオブジェクトとの統合

ハブアンドスポーク図:中央にビジネスユニット、そこから法人、事業部門、ポジション、報酬予算、S/4HANA組織管理に接続

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の所有範囲

Business Unitデータセクション全体におけるEmployee Centralの所有権を示すチェックリスト:識別、法人割当、ステータス、S/4HANA統合

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

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


2.1 コア識別

主要ビジネスユニットの中核識別フィールドのチェックリスト:外部コード、名称、有効開始日、有効日付レコードチェーン

コア識別は、ビジネスユニットが存在するために最低限必要なレコードです。これは、それに属するすべての事業部門がビジネスユニットを「上位」として参照する際に使用するものです。

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

2.2 法的エンティティ割当

事業単位割当フィールドのチェックリスト: 法人、事業単位責任者、ソート順

このセクションでは、ビジネスユニットレコードをその親となる法的エンティティ、およびコンサルタントが組織図目的で設定する表示/所有権属性に結び付けます。

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

2.3 ステータスとライフサイクル

ビジネスユニットのステータスとライフサイクルフィールドのチェックリスト:ステータス、有効日付による非アクティブ化、下流への影響

ステータスは、ビジネスユニットが新しい割当に利用可能かどうかを管理します。このセクションでは、コンサルタントが組織再編、合併、事業ラインの閉鎖を処理します。

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

2.4 S/4HANA 統合

S/4HANA組織管理からSuccessFactors事業部への同期フローを示すスタック階層図:マッピング、方向、頻度

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

IDCategoryTitle
sf-001OverviewSAP SuccessFactorsとは何ですか?

L2-A) Master Data

IDCategoryTitle
sf-a01OverviewSAP SuccessFactors マスタデータ:概要、階層、関係性
sf-a02-01Master DataSAP SF 法人
sf-a02-02Master DataSAP SF ビジネスユニット 📍
sf-a02-03Master DataSAP SF 事業部門
sf-a02-04Master DataSAP SF 部門
sf-a02-05Master DataSAP SF 原価センタ
sf-a02-06Master DataSAP SF ロケーション
sf-a02-07Master DataSAP SF ジョブファミリー
sf-a02-08Master DataSAP SF ジョブコード
sf-a02-09Master DataSAP SF 給与グレード
sf-a02-10Master DataSAP SF ポジション
sf-a03-01Master DataSAP SF 権限グループ
sf-a03-02Master DataSAP SF 権限ロール
sf-a03-03Master DataSAP SF 休日カレンダー
sf-a03-04Master DataSAP SF 勤務スケジュール
sf-a03-05Master DataSAP SF タイムタイプ
sf-a03-06Master DataSAP SF 時間プロファイル
sf-a03-07Master DataSAP SF 評価尺度
sf-a03-08Master DataSAP SF 目標計画テンプレート
sf-a03-09Master DataSAP SF パフォーマンスフォームテンプレート
sf-a03-10Master DataSAP SF ルートマップ
sf-a03-11Master DataSAP SF 報酬計画
sf-a04-01Master DataSAP SF 担当者
sf-a04-02Master DataSAP SF エンプロイメント
sf-a04-03Master DataSAP SF 従業員プロファイル

L2-B) Transaction

IDCategoryTitle
sf-b01OverviewSAP SuccessFactors トランザクション:プロセスフロー、階層、関係性