SAP サービス機能場所

SAP サービス機能場所
機能場所とは、保守・サービス作業が実行され、履歴が追跡される、固定された階層的な技術的または組織的な位置であり、その時点でそこに設置されている設備とは独立しています。これは、サービスマスタデータ設定のフェーズ3における3つの技術オブジェクトマスタの最初のもの(機能場所 → 設備 → 部品表)であり、技術的な位置をサービス可能にするための販売先(Sold-To Party)割当を保持するオブジェクトです。この記事では、そのカテゴリ、組織階層内での位置、周辺マスタとの統合、およびコンサルタントが設定する必要があるサービス固有のフィールドレベルの詳細について説明します。
パート 1: 機能場所 — 中核的概念(全モジュール共通)
1.1 機能場所とは

機能場所は、物理的な資産ではなく、恒久的な構造上の位置(建物、プラントセクション、機械ベイ、プロセスステップなど)を表します。物理的な資産(設備)はそこに設置され、時間の経過とともに交換、修理、または置き換えられますが、機能場所自体と、それに対して記録された保全/サービス履歴は、それらの変更を超えて存続します。
| 項目 | 詳細 | |
|---|---|---|
| 役割 | 特定の設備が設置されているかどうかに関わらず、保守・サービス作業が実行され、履歴が追跡される、固定された技術的/組織的なポジションを表します。 | |
| 使用するモジュール | PM(プラント保全 — 主な所有者:構造、計画、保全履歴)、Service(顧客向けサービスオブジェクトの販売先割当、サービスオーダー/契約の参照オブジェクト)、Field Service Management(派遣およびモバイルマップの参照) | |
| トランザクション | IL01(作成)/ IL02(変更)/ IL03(照会)/ IL05(一覧照会);Fioriアプリ「機能場所管理」 | |
| 主要テーブル | IFLOT(機能場所マスタデータ)、IFLOTX(ショート/ロングテキスト) | |
| S/4HANAに関する注意点 | データモデルはECCから変更なし。Fioriアプリ「機能場所管理」が、従来のIL01~IL03トランザクションよりも推奨されるエントリポイントです。地理座標フィールドは、Field Service Managementのモバイルマップ表示やルート最適化で以前より頻繁に使用されるようになりました。 |
1.2 機能場所カテゴリ

カテゴリはカスタマイジング定義された1文字のコードであり、機能場所が構造的に何を表すか、およびその下にどの参照構造(設備 vs. 品目)が期待されるかを決定します。初期段階で誤ったカテゴリを選択すると、後からその構造をコピーするすべてのサイトで階層が歪んでしまいます。
| カテゴリ | コード | ユースケース | 主要な動作 | |
|---|---|---|---|---|
| 機械/技術 | M | 個別の技術資産ポジション(特定の機械ベイ、空調ユニットのポジション) | 通常、構造の最下層ブランチ。設備はここに直接設置される。 | |
| プロセス | P | 連続プロセスプラント(生産ラインの工程、ユーティリティ回路) | プロセス産業で一般的。設備を物理的な機械ではなく、プロセスステップごとにグループ化する。 | |
| ロケーション | L | 技術的機能を持たない純粋な地理的/サイトラベル(建物、フロア、部屋) | 「どこにあるか」を提供するが、それ自体では保全責任を意味しない。子ノードが技術的な意味を追加する。 | |
| 機能/組織 | F | 組織的または機能的な役割(制御室、原価関連ゾーン) | 物理的な構造ではなく、レポート作成や原価配分のために機能場所をグループ化するために使用される。 |
設計原則: カテゴリコードセットは小さく標準化し、各構造インジケータセグメントを1つの主要カテゴリにマッピングすることで、企業が運営するすべての拠点で命名規則が予測可能な状態を維持します。
1.3 組織レベルとデータ階層

具体的な例を用いたデータ階層
Client 100
│
FUNCTIONAL LOCATION "FL-BLDG-01" — HQ Bldg. 1F, Category M
│ Sold-To Partner ── assigned to ──> Business Partner "1000001" (Zone A — reference, not an org-level child)
│
↓ (Equipment installed at this Functional Location)
EQUIPMENT (parent) "EQ-10001" — Air Conditioner A, Plant 1000
│ Warranty ── assigned to ──> Warranty Master "WTY-001" (Zone D — reference, via Equipment, not owned by FLoc)
│
├── EQUIPMENT (sub) "EQ-10001-A" — Compressor Unit
│ └── BOM ITEM "10 · Filter x2" ── references ──> Material "SP-FILTER-01" (Zone D)
│
└── EQUIPMENT (sub) "EQ-10001-B" — Fan Unit
└── BOM ITEM "10 · Fan Blade" (no spare-part reference)設計原則: 機能場所はポジションを所有しますが、部品表や保証を直接所有することはありません。これらはすべて、現在設置されている設備を介して間接的にのみ到達します。上記の矢印は、包含関係ではなく「割り当て先/参照元」として読んでください。
1.4 他のマスタデータオブジェクトとの統合

機能場所は単独で存在するわけではありません。他の技術オブジェクトやサービスマスタが、直接、またはその機能場所に設置された設備を介して紐づくためのアンカーとなります。
| オブジェクト | 関係 | 実務上の注意点 | |
|---|---|---|---|
| 設備 | 設備は機能場所に設置される(設置履歴) | 機能場所は固定され、そこに設置される設備は時間の経過とともに交換(修理、交換)される可能性がある一方、機能場所とその履歴は変更されない。 | |
| ビジネスパートナー(販売先) | 機能場所は、販売先パートナー機能を介してビジネスパートナーを参照する | この機能場所に対するサービス指図/サービス通知作成の必須前提条件 — 販売先がない場所は、トランザクション入力時に拒否される。 | |
| 部品表 | 機能場所に設置された設備を介してのみ間接的に到達する | 機能場所自体が部品表を持つことは決してない。スペアパーツ構造は常に設備レベルでモデル化される。 | |
| 保証マスタ | 設備を介してのみ間接的に到達する | 保証範囲は設備(または品目)に割り当てられ、機能場所には割り当てられない。1つの機能場所は、複数の設備保証サイクルよりも長く存続する可能性がある。 | |
| 保全計画(PM) | 機能場所は、定期保全計画の参照オブジェクトになり得る | 場所ベースの予防タスク(「建物1Fの設備を点検する」)は、特定の設備ではなく、機能場所に対して計画されることが多い。 | |
| サービス契約テンプレート(オブジェクトリスト) | 機能場所は、サービス契約のオブジェクトリストに表示され得る | 契約範囲を1つの設備ではなく場所に追従させることができる。施設管理タイプの契約で一般的。 |
パート 2: サービス固有のフィールド詳細
2.0 サービスオーナーシップの範囲

| データ区分 | サービスの関与 | 備考 | |
|---|---|---|---|
| 一般データ・構造データ | ○ PMと共有 | PMが構造インジケータ/カテゴリの設計を担当。サービスコンサルタントは、カテゴリと階層の深さが、サービス指図がオブジェクトを参照する方法と整合していることを確認する。 | |
| 組織割当 | ○ PMと共有 | 保全/計画プラントと作業区はPMが所有するカスタマイジング。サービスは、派遣ルーティングと原価割当のためにこれらに依存する。 | |
| パートナデータ | ◎ 所有者 | 販売先(およびその他のパートナ機能)は、サービスコンサルタントが直接保守・検証するフィールドであり、サービス指図/サービス契約処理の前提条件である。 | |
| ロケーション/住所データ | ○ PMと共有 | 住所と地理座標は、サービスのフィールド派遣およびモバイルアプリで使用される。フィールドの基本保守はPM/データガバナンスのタスクである。 |
凡例: ◎ = オーナー/重要、○ = 直接関与
2.1 一般データ & 構造データ

一般データと構造データは、機能場所が何であるか、および多階層の機能場所階層内のどこに位置するかを定義します。
| フィールド | 説明 | 実務上の使用例 | |
|---|---|---|---|
| 機能場所 (TPLNR) | 構造インジケータの編集マスクから構築される英数字キー | キー自体が階層をエンコードします(例:FL-BLDG-01 は建物 > 1階を示す)。その下に機能場所が存在する状態で編集マスクを変更すると影響が大きいため、ブループリント時に各サイトの命名規則に対してマスクを検証する必要があります。 | |
| 説明 (短テキスト / 長テキスト) | 機能場所の業務上の名称 | フィールドエンジニアやディスパッチャは、キーよりも説明でモバイル検索することがはるかに多いため、IDだけでなく短テキストもグローバルに曖昧さがないようにしてください。 | |
| カテゴリ | 1文字コード (M/P/L/F、1.2参照) | IL01/IL02でどの追加ビューが利用可能か、またこのノードの下でどの参照構造(設備 vs. 品目)が期待されるかを決定します。 | |
| 構造インジケータ | この階層ブランチの編集マスク(セグメント長、区切り文字)を定義します | ブループリント時にサイト/事業領域ごとに一度設定され、その下に機能場所が存在する状態ではデータ移行なしに変更できません。セグメントのサイズを過小評価する(例:フロアに2桁)ことは、よくある高コストなミスです。 | |
| 上位機能場所 | 多階層階層における親機能場所 | このフィールドはFLoc間の構造(例:FL-BLDG-01 の上の FL-BLDG)を保持します。サービスオーダーのオブジェクト選択リストが現場で使い続けられるよう、階層の深さは浅く保ってください。 | |
| オブジェクトタイプ / クラス | 検索とレポート作成のためのオプションの分類 | クラス(例:「建物設備」、「ユーティリティ回路」)を割り当てることで、コンサルタントは構造インジケータの階層とは独立して機能場所を検索/レポートできます。 | |
| 稼働開始日 | 機能場所が運用を開始した日付 | 設備ベースのサービス契約における保全履歴とSLAレポートのベースラインとなります。 | |
| ABC指標 | 業務/保全上の重要度分類 | 重要度の高い(A)機能場所は、通常、サービス契約設定でより厳しいSLA応答時間が設定され、サービスオーダーのディスパッチで優先的に処理されます。 |
2.2 組織割当

組織割当フィールドは、この機能場所に対して実行される作業について、誰が計画し、誰が実行し、コストがどこに計上されるかを決定します。
| フィールド | 説明 | 実務上の使用例 | |
|---|---|---|---|
| 保全プラント | この機能場所の保全を担当するプラント | 適用されるPM/サービスのカスタマイジング(指図タイプ、通知タイプ)を決定します。複数拠点のサービス組織の場合、法的なプラントだけでなく、実際に技術者を派遣する拠点と一致していることを確認してください。 | |
| 計画プラント | この場所の保全/サービス作業を計画するプラント | プラント間計画設定(中央計画部門が遠隔地で実行される作業をスケジュールする場合)では、保全プラントと異なる場合があります。サービス指図のデフォルトロジックは、このフィールドを読み取り、責任計画者を提案します。 | |
| 計画グループ | この場所を担当する計画者のグループ | ワークリストの割り当てと通知のルーティングを決定します。サービス組織が実際にテリトリーを分割する方法が、PMの元のプラントベースのグループ化と異なる場合は、それに合わせて調整してください。 | |
| 作業区 | この場所での作業のデフォルト作業区 | 機能場所に対して作成された新しいサービス指図/通知に自動的に提案され、手動入力を削減します。技術者チームが再編成された場合は、同期を維持してください。 | |
| 事業領域 / 原価センタ | 原価収集のための管理会計割り当て | 保全/サービス原価がデフォルトで決済される場所を決定します。場所がサービス契約を通じて請求される場合は、顧客請求モデルと照らし合わせて確認してください。 |
2.3 パートナーデータ

パートナーデータは、フィールドサービスコンサルタントが完全に所有するものです。これは、純粋に技術的なポジションを、サービス可能で請求可能な顧客オブジェクトに変えるものです。
| 項目 | 説明 | 実務上の使用例 | |
|---|---|---|---|
| 得意先 | このロケーションの顧客として機能するビジネスパートナー | サービス指図/通知作成の必須前提条件 — これがないと、この機能場所に対するトランザクションはブロックされます。技術オブジェクトを商業面(誰に請求するか、どの契約が適用されるか)に結び付ける項目です。 | |
| 納入先 | このロケーションに関連する物理的な納品(スペアパーツ、交換ユニットなど)を受け取るビジネスパートナー | 個別に管理されていない場合は得意先がデフォルトになります。請求関係と納入先住所が異なる場合(例:施設管理会社が一括請求されるが、部品は現場に配送される場合)に明示的に設定します。 | |
| 連絡担当者 | 派遣調整のための現場連絡先 | ビジネスパートナーの連絡担当者関係から自動設定されます。派遣スケジューラやフィールドテクニシャンは、現場訪問のたびにこれを参照します。 | |
| パートナー決定手順 | このオブジェクトに対してどのパートナー機能が必須/許可されるかを制御するカスタマイジング | ブループリント時に、機能場所のカテゴリに割り当てられた手順で得意先が必須としてマークされていることを確認してください。手順が誤って設定されていると、得意先なしでサービス指図が作成できてしまい、下流の請求処理に支障をきたします。 |
2.4 ロケーション / 住所データ

ロケーションと住所データは、機能場所を物理的な場所に結び付けます。これは、ディスパッチやモバイルアプリが直接利用する情報フィールドです。
| フィールド | 説明 | 実務上の使用例 | |
|---|---|---|---|
| 住所 | 通り、市区町村、地域、郵便番号、国 | フィールドサービス派遣やルート計画で主に使用されるフィールドです。関連するビジネスパートナーの住所と同期を保ち、技術者が誤った場所に案内されないようにしてください。 | |
| ロケーション / 部屋 | 住所内の自由テキストまたはコード化された位置(建物、階、部屋) | カテゴリ(1.2)と組み合わせて、大規模なサイト内で技術オブジェクトが正確にどこにあるかを特定します。キャンパスや産業顧客で、1つの住所に数十の機能場所がある場合に重要です。 | |
| 地理座標(経度 / 緯度) | 正確な地図上の位置 | フィールドサービス管理のモバイルマップビューとルート最適化で使用されます。モバイルアプリ経由で派遣されるすべてのロケーション(大規模サイトだけでなく)に入力してください。 | |
| 参照機能場所 | 新規作成時に構造をコピーできるテンプレートとなる機能場所 | 標準化されたサイトレイアウト(例:同一の施設構造を持つ小売店舗チェーン)の展開を迅速化します。新しいサイトごとに階層を再入力する代わりに、参照機能場所をコピーしてください。 |
次に読むべきもの
L1) Big Picture
| ID | Category | Title |
|---|---|---|
| srv-001 | Overview | SAP Serviceとは何ですか? |
L2-A) Master Data
| ID | Category | Title |
|---|---|---|
| srv-a01 | Overview | SAP サービス基本データ:概要、階層、および関連性 |
| srv-a03-01 | Master Data | SAP サービス品目マスタ |
| srv-a04-01 | Master Data | SAPスペアパーツマスタ |
| srv-a03-02 | Master Data | SAP サービス価格決定条件 |
| srv-a05-01 | Master Data | SAP サービス機能場所 📍 |
| srv-a05-02 | Master Data | SAP サービス設備 |
| srv-a05-03 | Master Data | SAP サービス部品表 |
| srv-a06-01 | Master Data | SAP サービス サービス契約テンプレート |
| srv-a06-02 | Master Data | SAP サービス サービスオーダーテンプレート |
| srv-a07-01 | Master Data | SAP サービス保証マスタ |