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

表紙: SAP FSM 設備階層 — マルチレベルインストレーションの背後にある親子構造

SAP FSM 設備階層

設備階層は、2つの設備(FSM-A03-01)レコードを親子関係で結び付ける構造的なリンクであり、FSMが複雑な設備(例えば、独立して保守可能なサブアセンブリを持つ冷凍機プラント)を、関連のない資産のフラットなリストではなく、ナビゲート可能なツリーとして表現できるようにします。このリンク自体は、そのツリーを構築および検証するために必要なリンク、レベル、および位置のメタデータ以外のフィールドを持ちません。保守可能な資産の詳細自体は、常にそれが接続する設備レコードに存在します。この記事では、設備階層を構築する際にFSMコンサルタントが設定するすべてのフィールドと、それらのフィールドが設備マスタおよびその上に構築されるサービス履歴ロールアップとどのように関連するかを説明します。


パート 1: 設備階層 — 中核概念(全モジュール共通)

1.1 設備階層とは

機器階層を中心に、機器、サービス履歴、ビジネスパートナー、計画・派遣に接続されたハブアンドスポーク図

機器階層は、2つの個別の設備レコード間の有向の親子関係を表すものであり、それ以上のものではありません。これは、ある保守対象資産が物理的または機能的に別の資産のサブコンポーネントであることをFSMに認識させる仕組みであり、これにより、2つのレコードが無関係なものとしてではなく、関連する構造としてナビゲーション、レポート、およびディスパッチの対象となります。

項目詳細
役割親設備を1つ以上の子設備レコードに接続する構造リンクであり、多階層の設置ツリーとサブツリーを考慮したレポートを可能にします。
使用するモジュールFSM(設備管理 — 階層リンクの主要な所有者)、S/4HANA Enterprise Asset Management(設備がEAMから発生する場合のソースシステム概念 — 設備マスタの上位設備割当として表現されます)、S/4HANA Service(間接的 — サービス指図コストを階層内の正しいノードに帰属させる必要がある場合)
トランザクションFSM Web UI「設備管理」アプリ — 構造/階層タブ;S/4HANAソース側では、IE02(設備変更)の構造タブで、上位設備フィールドがレプリケーション前に同じ親子リンクを確立します。
主要テーブルFSM:設備ビジネスオブジェクト(Core API / ODataエンティティ)上の親子参照フィールド — FSMはマルチテナントクラウドソリューションであり、従来のABAPテーブルは使用しません。ソースシステム:S/4HANAテーブル EQUI、フィールド HEQUI(上位設備)(階層がEAMから発生する場合)
S/4HANAに関する注意設備がマスタデータ統合(MDI)を介してS/4HANAから同期される場合、ソースのEQUIレコードの上位設備割当がFSM設備階層リンクを設定します — 階層はFSMで独立して再モデル化されるのではなく、ソース構造から引き継がれます。

1.2 階層パターン

3つの設備階層パターン(単一階層、複数階層ネスト、論理グループ化)の比較表。それぞれの代表的なユースケースとレポートへの影響を示しています

すべての導入で同じツリー構造が必要なわけではありません。不必要に深い構造や、人為的に平坦な構造を選択すると、どちらも後工程で実際の問題を引き起こします。前者はレポート作成やディスパッチロジックを肥大化させ、後者はテクニシャンが現場で必要とするサブコンポーネントの詳細を隠してしまいます。

パターン記述子ユースケース主要な動作
単一レベル(フラット)親 → 1つの子、それ以上のネストなしより大きなユニット内の単一の取り外し可能なサブパーツ(例:ACユニット内の交換可能なフィルターカートリッジ)最もシンプルで一般的なパターン。最小限のレポートオーバーヘッド。親の下に1つの階層レベルを持つ
マルチレベル(ネスト)親 → 子 → 孫、3レベル以上複雑なプラント設備。例:独立してサービス可能なコンプレッサーを持つチラーシステムで、そのコンプレッサー自体にもサービス可能なセンサーサブユニットがある各ノードは依然として直接のルート設備参照を持つため、レポート作成時にチェーン全体を辿る必要がない。深いネストは、派遣とスキル要件マッチングの複雑さを増加させる
論理グループ化親は非物理的な「設置」ノードであり、物理的に関連のない複数の子を持つ単一の顧客プロジェクトのために一緒に設置された複数の独立したユニットをグループ化する(例:3つの別々のポンプユニットが1つのジョブとして納入・試運転される)物理的な包含関係ではなく、レポート作成とプロジェクトレベルのロールアップに使用される。サービスコールは常に個々の子設備に対して発行され、論理的な親自体に対して発行されることはない

設計原則: 技術者やプランナーが確認する必要がある、真に物理的または論理的な包含関係を反映する場合にのみ階層レベルをモデル化すること。人為的に深いツリーは、プランニングボードの設備ビューを読みにくくするだけで、読みやすくはなりません。


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

FSMマスタデータランドスケープのゾーンB部分(設備、設備階層、サービス履歴を表示、ビジネスパートナーおよび住所へのゾーン間参照を含む)

データ階層と具体例(ゾーンB · 設備管理 — テナントレベル;FSMには設備より上位の会社コード/プラントスコープはありません)

Client (FSM Tenant)
   │
   ├── Equipment EQ-001 — AC Unit A (Serial SN-2024-001)
   │      ↗ references Business Partner BP-001 — ABC Corp (Zone A)
   │      ↗ references Address AD-A — 1-1 Marunouchi, Tokyo (Zone A)
   │      │
   │      └── Equipment Hierarchy EQ-001-01 — Sub-unit of EQ-001 (Hierarchy Level 2)
   │
   ├── Equipment EQ-002 — Pump B (Serial SN-2024-002)
   │      ↗ references Business Partner BP-002 — XYZ Ltd (Zone A)
   │      ↗ references Address AD-B — 2-2 Umeda, Osaka (Zone A)
   │      │
   │      └── Equipment Hierarchy EQ-002-01 — Sub-unit of EQ-002 (Hierarchy Level 2)
   │
   └── Equipment EQ-003 — Chiller C (Serial SN-2024-003)
          ↗ references Business Partner BP-002 — XYZ Ltd (Zone A)
          │
          └── Equipment Hierarchy EQ-003-01 — Sub-unit of EQ-003 (Hierarchy Level 2)

Service History (reference log — points back to its own Equipment node, not to the hierarchy link):
   Service History SH-001 ── refers to ──▶ Equipment EQ-001
   Service History SH-002 ── refers to ──▶ Equipment EQ-002

設計原則: 設備階層は、2つの設備レコード間でのみスコープされる純粋な親子リンクです — 親 EQ-001 → 子 EQ-001-01、階層レベル 2 — それ自体がビジネスパートナーや住所を参照することはなく(これらは階層リンクではなく親設備によって参照されます)、サービス履歴も保持しません。サービス履歴は、実際にサービスが実施された設備ノード(親または子)に対する参照ログとして残ります。


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

ハブアンドスポーク図:中央の設備階層が、設備、サービス履歴、スキル要件、計画・ディスパッチングに接続

機器階層はそれ自体に意味があるわけではありません。機器レコードを接続し、その周辺オブジェクトの報告や派遣方法を形成するためにのみ存在します。

オブジェクト関係性実務上の注意点
設備すべての設備階層レコードは、2つの設備レコード(親1つ、子1つ)を正確に接続します階層リンクを作成する前に、親と子の両方が設備レコードとして既に存在している必要があります。再親設定やリンク削除を行わずにどちらかを削除すると、孤立した参照が残ります。
サービス履歴実際にサービスが実行された設備ノード(親または子)で独立して集約されます階層対応のサービス履歴ビューはサブツリー全体で集約できますが、基となるサービス履歴レコード自体は階層リンクに紐づくことはなく、個々の設備にのみ紐づきます。
スキル要件親設備と子設備は異なる必須スキルを持つことができますチラー(親)は一般的なHVAC認定を必要とする一方、そのコンプレッサーサブユニット(子)はメーカー固有の認定を必要とする場合があります。アシストスケジューリングは、サービスコールが発行されたノードのスキル要件を評価し、サブツリー全体は評価しません。
計画とディスパッチング (FSM-B04)階層は、計画ボード上でナビゲート可能な設備ツリーとして表示されますディスパッチャーはツリービューを使用して、正しいノードに対してスケジューリングしていることを確認します。よくあるデータ品質の問題は、実際の障害が特定の子サブユニットに限定されている場合に、親に対してサービスコールを発行してしまうことです。

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

2.0 FSM 所有権の範囲

機器階層データセクション全体におけるFSM所有権を示すチェックリスト: 識別/リンク、レベル/位置メタデータ、有効性/整合性追跡

データセクションFSM関与備考
コア階層の識別とリンク◎ オーナー階層レコード自体と、それが接続する親/子の設備ペア
レベル、位置、構造メタデータ◎ オーナーツリーをレンダリングするために使用される、派生した深さ、ルート設備ルックアップ、および兄弟位置フィールド
有効性、整合性、変更追跡◎ オーナー循環割り当てや重複割り当てを防止し、構造を変更した担当者を記録するフィールドとルール

凡例: ◎ = オーナー/重要、○ = 直接関与


2.1 コア階層の識別とリンク

設備階層のコアリンケージフィールドのチェックリスト: 階層レコードID、親設備ID、子設備ID、割当日

これらのフィールドは、特定の階層エントリが実際にどの2つの設備レコードを接続するかを確立します。

フィールド説明実務上の使用例
階層レコードID親子リンクに対するFSM内部の一意識別子作成時に自動生成されます。親機器IDおよび子機器IDとは異なり、関係性そのものを識別するものであり、どちらかのエンドポイントを識別するものではありません。
親機器ID関係性における上位レベルの機器への参照アクティブな機器レコードとして既に存在している必要があります。技術的には、廃止済み機器を親として割り当てることは可能ですが、プロセス上の規律によりブロックされるべきです。これは、リタイアした資産の下でアクティブな作業が行われることを意味するためです。
子機器ID関係性における下位レベル(サブコンポーネント)の機器への参照1つの機器レコードは、同時に1つの階層リンクにおいてのみ子となることができます。新しい親に再割り当てする場合、競合する2つ目のリンクを作成するのではなく、常に以前のリンクを削除する必要があります。
割当日親子リンクが確立された日付監査目的や、誤ったノードに対して発行された過去のサービスコールを調査する際に「その時点での構造がどのようであったか」を再構築するために使用されます。

2.2 レベル、ポジション、構造メタデータ

設備階層の構造メタデータフィールドを示すスタック階層図:階層レベル、ルート設備、位置/順序、子カウント

これらの派生フィールドにより、FSMはクエリ実行時に毎回すべての親子リンクを辿ることなく、ツリーのレンダリングとレポート作成が可能になります。

フィールド説明実務上の使用例
階層レベル構造内における子要素の派生深度(親 = レベル1、最初のサブユニット = レベル2、以下同様)リンクが作成、移動、削除されるたびに自動的に再計算され、プランニングボードのツリービューにおけるインデントや、構造深度レポートで直接使用されます。
ルート設備ID構造全体の基点となる最上位設備への参照レポートやサービス履歴の集計において、中間レベルをすべて再帰的にトラバースすることなく、インストール全体を集計できるようにします。これは、深くネストされたマルチレベル構造において重要なパフォーマンス上の考慮事項です。
位置 / 順序番号同一親を持つ兄弟子要素間の順序値純粋に表示上の利便性のためであり、テクニシャンのモバイルアプリやプランニングボードツリーにおけるサブユニットの表示順序を制御します。ディスパッチやスキル要件ロジックには影響しません。
子カウントこのノードの子として直接リンクされている設備レコードの派生数有用なデータ品質チェックです。単一のサブコンポーネントインストールであるべきノードで予想外に高いカウントが発生した場合、一括ロード中にサブユニットが誤った親にリンクされたことを示していることがよくあります。

2.3 有効性、整合性、変更追跡

設備階層の有効性と監査フィールドのチェックリスト: 有効開始日、変更者、変更日、循環参照チェック

階層リンクは新しい設備レコードを作成するのではなく、2つの既存の設備レコードの意味を変更するため、リンク自体と同様に、その一貫性と監査可能性を維持することが重要です。

フィールド説明実務上の使用例
有効開始日現在の親子割当が適用される開始日子設備がそのライフタイム中に再親付けされる場合(例:予備ポンプが別の設備に移動された場合)に関連 — 発生時点の正しい構造に履歴サービス履歴を帰属させることができます。
変更者階層リンクを最後に変更したユーザまたは統合アカウント手動による管理者修正と、S/4HANA EAM構造同期による自動変更を区別します — 稼働開始後の予期しない再親付けを調査する際に重要です。
変更日時リンクに対する最新の変更のタイムスタンプ変更者と組み合わせて監査証跡として使用され、特に設備構造の変更を追跡可能にしなければならない規制環境で重要です。
循環参照チェック設備レコードが自身の祖先として割り当てられることを防ぐシステム検証保存時に自動的に適用されます — これがないと、データ入力エラー(例:誤って親と子を逆にする)により、ツリー表示やロールアップレポートで無限ループが発生する可能性があります。

次に読むべきもの

L1) Big Picture

IDCategoryTitle
fsm-001OverviewSAP FSMとは何ですか?

L2-A) Master Data

IDCategoryTitle
fsm-a01OverviewSAP FSM マスタデータ:概要、階層、および関係性
fsm-a02-02Master DataSAP FSM コンタクト
fsm-a02-03Master DataSAP FSM アドレス
fsm-a03-01Master DataSAP FSM 設備
fsm-a03-02Master DataSAP FSM 設備階層 📍
fsm-a03-03Master DataSAP FSM サービス履歴
fsm-a04-01Master DataSAP FSM スキル
fsm-a04-02Master DataSAP FSM 作業時間パターン
fsm-a04-03Master DataSAP FSM リージョン
fsm-a04-04Master DataSAP FSM テクニシャン
fsm-a04-05Master DataSAP FSM クルー
fsm-a04-06Master DataSAP FSM 欠勤
fsm-a04-07Master DataSAP FSM スキル要件
fsm-a05-02Master DataSAP FSM 汎用ツール
fsm-a05-03Master DataSAP FSM シリアルツール
fsm-a05-04Master DataSAP FSM 倉庫
fsm-a05-05Master DataSAP FSM バンストック
fsm-a06-01Master DataSAP FSM パートナー招待
fsm-a06-02Master DataSAP FSM パートナー登録
fsm-a06-03Master DataSAP FSM クラウドパートナー
fsm-a06-04Master DataSAP FSM パートナーテクニシャン

L2-B) Transaction

IDCategoryTitle
fsm-b01OverviewSAP FSM トランザクション:プロセスフロー、階層、および関係