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 階層パターン

すべての導入で同じツリー構造が必要なわけではありません。不必要に深い構造や、人為的に平坦な構造を選択すると、どちらも後工程で実際の問題を引き起こします。前者はレポート作成やディスパッチロジックを肥大化させ、後者はテクニシャンが現場で必要とするサブコンポーネントの詳細を隠してしまいます。
| パターン | 記述子 | ユースケース | 主要な動作 | |
|---|---|---|---|---|
| 単一レベル(フラット) | 親 → 1つの子、それ以上のネストなし | より大きなユニット内の単一の取り外し可能なサブパーツ(例:ACユニット内の交換可能なフィルターカートリッジ) | 最もシンプルで一般的なパターン。最小限のレポートオーバーヘッド。親の下に1つの階層レベルを持つ | |
| マルチレベル(ネスト) | 親 → 子 → 孫、3レベル以上 | 複雑なプラント設備。例:独立してサービス可能なコンプレッサーを持つチラーシステムで、そのコンプレッサー自体にもサービス可能なセンサーサブユニットがある | 各ノードは依然として直接のルート設備参照を持つため、レポート作成時にチェーン全体を辿る必要がない。深いネストは、派遣とスキル要件マッチングの複雑さを増加させる | |
| 論理グループ化 | 親は非物理的な「設置」ノードであり、物理的に関連のない複数の子を持つ | 単一の顧客プロジェクトのために一緒に設置された複数の独立したユニットをグループ化する(例:3つの別々のポンプユニットが1つのジョブとして納入・試運転される) | 物理的な包含関係ではなく、レポート作成とプロジェクトレベルのロールアップに使用される。サービスコールは常に個々の子設備に対して発行され、論理的な親自体に対して発行されることはない |
設計原則: 技術者やプランナーが確認する必要がある、真に物理的または論理的な包含関係を反映する場合にのみ階層レベルをモデル化すること。人為的に深いツリーは、プランニングボードの設備ビューを読みにくくするだけで、読みやすくはなりません。
1.3 組織レベルとデータ階層

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

これらのフィールドは、特定の階層エントリが実際にどの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
| ID | Category | Title |
|---|---|---|
| fsm-001 | Overview | SAP FSMとは何ですか? |
L2-A) Master Data
| ID | Category | Title |
|---|---|---|
| fsm-a01 | Overview | SAP FSM マスタデータ:概要、階層、および関係性 |
| fsm-a02-02 | Master Data | SAP FSM コンタクト |
| fsm-a02-03 | Master Data | SAP FSM アドレス |
| fsm-a03-01 | Master Data | SAP FSM 設備 |
| fsm-a03-02 | Master Data | SAP FSM 設備階層 📍 |
| fsm-a03-03 | Master Data | SAP FSM サービス履歴 |
| fsm-a04-01 | Master Data | SAP FSM スキル |
| fsm-a04-02 | Master Data | SAP FSM 作業時間パターン |
| fsm-a04-03 | Master Data | SAP FSM リージョン |
| fsm-a04-04 | Master Data | SAP FSM テクニシャン |
| fsm-a04-05 | Master Data | SAP FSM クルー |
| fsm-a04-06 | Master Data | SAP FSM 欠勤 |
| fsm-a04-07 | Master Data | SAP FSM スキル要件 |
| fsm-a05-02 | Master Data | SAP FSM 汎用ツール |
| fsm-a05-03 | Master Data | SAP FSM シリアルツール |
| fsm-a05-04 | Master Data | SAP FSM 倉庫 |
| fsm-a05-05 | Master Data | SAP FSM バンストック |
| fsm-a06-01 | Master Data | SAP FSM パートナー招待 |
| fsm-a06-02 | Master Data | SAP FSM パートナー登録 |
| fsm-a06-03 | Master Data | SAP FSM クラウドパートナー |
| fsm-a06-04 | Master Data | SAP FSM パートナーテクニシャン |
L2-B) Transaction
| ID | Category | Title |
|---|---|---|
| fsm-b01 | Overview | SAP FSM トランザクション:プロセスフロー、階層、および関係 |