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

SAP SF 事業部門

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


パート 1: 事業部門 — 中核概念(全モジュール)

1.1 事業部門とは

事業部門を中心に、ビジネスユニット、部門、S/4HANA利益センタ/機能エリアに接続されたハブアンドスポーク図

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 事業部門設定パターン

製品ライン vs 地域の設計軸、および有効化 vs バイパスされた事業部門レベルを比較する2x2マトリックス

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

パターンマーカーユースケース主要な動作
製品ライン別部門製品ラインクライアントがビジネスユニット内の部門を主に製品またはサービスラインで編成している部門名は製品/サービスラインを反映(例:「コンシューマ製品部門」);その下の部門は通常、そのライン内の機能チームを表す
地域別部門地域クライアントが単一のビジネスユニット内の部門を主に地域で編成している部門名はサブ地域を反映(例:「東日本部門」);その下の部門は通常、その地域内の機能または製品チームを表す
部門レベル有効化有効ビジネスユニットに、部門の上位グループ化を正当化するのに十分な組織的複雑性があるすべての部門は部門に割り当てられる必要がある;部門がチェーン内の必須リンクとなる
部門レベルバイパスバイパス部門がビジネスユニットに直接紐付く、よりシンプルな組織部門ファンデーションオブジェクトタイプはシステムに設定されたままであるが、それを参照するアクティブなレコードはゼロ;組織図とレポートはビジネスユニットから部門へ直接スキップされる

設計原則: 設計軸(製品ライン別 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 Profit Center / Functional Area

Location "LOC_TKY01" — Tokyo HQ, Asia/Tokyo TZ
   (independent tenant-level master — not nested under Division)

設計原則: ビジネスユニット → 事業部門 → 部門 → 原価センタは、ビジネスユニット以下の厳格な単一親チェーンです。事業部門レベルがスキップされる場合(1.2参照)、部門は代わりにビジネスユニットに直接接続されますが、使用されるレベル以下のチェーンは全体を通じて単一親のままです。


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

ハブアンドスポーク図。中央に事業部門があり、ビジネスユニット、部門、ポジション、報酬予算、S/4HANA利益センタ/機能エリアに接続されている

事業部門は単独で存在するものではなく、上位のビジネスユニットへの必須のリンクであり、その下に編成されるすべてのものを必須でグループ化する下位の単位です。

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

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

2.0 SFの所有範囲

従業員セントラルの所有権を示すチェックリスト(部門データセクション別:識別、事業部門割当、ステータス、S/4HANA統合)

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

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


2.1 コア識別

主要部門コア識別フィールドのチェックリスト: 外部コード、名称、有効開始日、有効日付レコードチェーン

コア識別情報は、事業部門が存在するために必要な最小限のレコードであり、それに属するすべての部門が「上位」の事業部門を参照する際に使用するものです。

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

2.2 事業単位の割当

事業部門割当フィールドのチェックリスト: 事業単位、事業部門長、ソート順

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

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

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

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

ステータスは、事業部門が新しい割り当てに利用可能かどうかを管理します。このセクションでは、コンサルタントが組織再編、合併、および製品ラインの統合を処理します。

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

2.4 S/4HANA 統合

S/4HANAの利益センタ/機能エリアからSuccessFactorsの事業部門への同期フローを示すスタック階層図:マッピング、方向、頻度

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

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 トランザクション:プロセスフロー、階層、関係性