SAP PM 保全計画

SAP PM 保全計画
保守計画は、SAP PMの予防保全における最上位のスケジュール計画オブジェクトです。予防保全をいつ実施するか、どの程度の頻度で、どの作業を実行すべきか、どのオブジェクトを保全するかを定義し、適切なタイミングで保全通知または作業指図を自動的に作成します。タスクリストと技術オブジェクトをリンクする保全項目の上位に位置する保守計画は、PM設定フローにおける最終マスタデータオブジェクトです。この記事では、その計画タイプ、スケジュール指標、組織データ階層、およびPMコンサルタントが予防保全スケジュールを本番稼働させるために設定する必要があるすべてのフィールドについて説明します。
第1部:保全計画 — 中核概念(全モジュール共通)
1.1 保全計画とは

保全計画とは、「この設備に対して、この頻度で保全作業を実行する」ことをSAPに指示するスケジュールマスタレコードです。これは、詳細な作業定義(保全項目を介したタスクリスト)と、運用実行オブジェクト(保全通知および保全指図)との間の橋渡しを行います。保全計画がない場合、予防保全は毎回手動で作成する必要がありますが、保全計画はその手動トリガーをシステム駆動のスケジューリングエンジンに置き換えます。
| 側面 | 詳細 | |
|---|---|---|
| 役割 | 予防保全のスケジュールを定義します。頻度、タイミング、起動オブジェクトタイプ、および対象となる保全項目(技術オブジェクト+タスクリスト)を指定します。 | |
| 使用するモジュール | PM(プライマリオーナー — 予防保全および状態基準保全のスケジューリング)、CS(カスタマーサービス — 顧客設備向けサービス計画のスケジューリング) | |
| トランザクション | IP01(単一周期計画作成)/ IP10(ストラテジ計画作成)/ IP02(変更)/ IP03(表示)/ IP30(期限監視バッチジョブ) | |
| 主要テーブル | MPLAN(保全計画ヘッダ)/ MPOS(計画に割り当てられた保全項目)/ MPLA(保全計画スケジューリングデータ) | |
| S/4HANAに関する注意点 | ECCからコアデータモデルは変更なし。Fioriアプリ「保全計画のスケジュール」(F2359)が、監視および手動スケジューリングに利用可能。IP30(期限監視)は、依然として標準のバッチスケジューリングメカニズムです。 |
1.2 計画タイプと日程計画区分

保全計画には、ブループリント段階で決定しなければならない2つの基本的な次元があります。それは、計画タイプ(保全サイクルの数)と日程計画区分(サイクルをトリガーするもの)です。この組み合わせを誤ると、保全イベントの見逃しや、計画が本番稼働した後に修正が困難な誤った日程計画動作が発生します。
計画タイプ
| 計画タイプ | 説明 | ユースケース | 主な動作 | |
|---|---|---|---|---|
| 単一サイクル計画 (IP01) | 1つの保全サイクル — 単一の固定間隔 | 単一頻度の単純な定期タスク(例:月次潤滑、年次点検) | 設定が最も簡単。保全戦略は不要。サイクルは計画に直接定義される。 | |
| 戦略計画 (IP10) | 保全戦略によって駆動される複数の保全サイクル | 階層化された頻度を持つ複雑な予防プログラム(例:同一設備での月次、四半期、年次チェック) | 保全戦略マスタレコードが必要。1つの戦略内の複数のパッケージが、異なるスケジュールで個別のコールオブジェクトを生成する。 | |
| 複合カウンタ計画 | 複数のカウンタ(時間+パフォーマンス)を組み合わせる | いずれかのしきい値に最初に達した時点でトリガーされる保全(例:500運転時間 または 6ヶ月) | 設備に測定ポイント(カウンタ)の設定が必要。測定文書を使用してカウンタ値を更新する。 |
日程計画区分
| 日程計画区分 | コード | トリガー | 代表例 |
|---|---|---|---|
| 時間ベース | T | カレンダー時間 — 日/週/月/年の固定間隔 | 30日ごとの月次点検 |
| 実績ベース(カウンタベース) | L | 測定ポイントのカウンタ値(稼働時間、走行距離、サイクル数) | 500時間ごとのエンジン整備 |
| カレンダーベース | C | 特定のカレンダー日付(ロール間隔ではない) | 政府指定の固定日における年次法定点検 |
設計原則: ほとんどの産業用PMシナリオでは、時間ベースの単一サイクル計画で要件の大部分をカバーできます。同一設備に複数の頻度パッケージが真に必要な場合にのみ、戦略計画を追加してください。戦略による過剰設計は、スケジューリング上のメリットなしにマスタデータのメンテナンスコストを増加させます。
1.3 組織レベルとデータ階層

具体的な例を用いたデータ階層
Maintenance Plan MP-PUMP-001
Type: Single Cycle, Time-based, Monthly
│
└── Maintenance Item 10
Vibration Check — Cooling Water Pumps
── references ──> Equipment 10001234
Centrifugal Pump #3, Plant 1000
── references ──> Task List MAINT-GEN-011.4 他のマスタデータオブジェクトとの統合

保全計画は、PM予防保全チェーンにおける最終マスタデータオブジェクトです。フェーズ1から5で作成されたほぼすべてのマスタと統合されます。
| オブジェクト | 関係性 | 実務上の注意点 | |
|---|---|---|---|
| 保全項目 (MPOS) | 計画には1つ以上の保全項目が含まれる | 保全項目は個別に作成され(IP11)、計画に割り当てられます。タスクリスト参照と技術オブジェクトを保持します。少なくとも1つの保全項目がないと、計画は呼出オブジェクトを生成できません。 | |
| 設備 (IE01) | 保全項目を介して参照される | 設備はプラントレベルの組織範囲を定義します。設備ステータス(AVLB、LOCK)は、計画が有効な保全指図を生成できるかどうかに直接影響します。 | |
| 機能場所 (IL01) | 保全項目を介して参照される(設備の代替) | 計画は特定の設備の代わりに機能場所を参照できます。これは、保全が資産固有ではなく場所ベースである場合に使用されます。 | |
| タスクリスト (IA01) | 保全項目を介して参照される | 作業、作業区、および実行する作業の標準時間を定義します。タスクリストがない計画は、作業のない保全指図を生成します。プランナーは手動でステップを追加する必要があります。 | |
| 測定ポイント/カウンタ (IK01) | 実績ベース(カウンタベース)計画に必須 | 測定ポイントのカウンタは、IP30がサイクルしきい値に対して評価する読み取り値を提供します。測定文書(IK11)で測定ポイントカウンタが定期的に更新されない場合、カウンタベース計画はスケジューリングに失敗します。 | |
| 保全戦略 (IP11領域) | 戦略計画(IP10)に必須 | パッケージ階層(例: M1=月次、M3=四半期、M12=年次)を定義します。計画が有効になった後に保全戦略を変更するには、すべての依存計画を注意深くレビューする必要があります。 | |
| 保全指図 (IW31領域) | 計画の呼出日が到来したときにIP30によって生成される | 計画の呼出オブジェクト設定により、保全指図(PM01/PM02/PM03)または保全通知(M1/M2/M3)のどちらが作成されるかが決まります。ほとんどの予防保全計画は、直接保全指図を作成します。 |
第2部: PM固有のフィールド詳細
2.0 PMオーナーシップの範囲

| データ区分 | PM関与 | 備考 | |
|---|---|---|---|
| 計画ヘッダデータ | ◎ オーナー | 計画タイプ、説明、保全プラント、保全計画グループ | |
| スケジューリングパラメータ | ◎ オーナー | サイクル、開始日、コール予定期間、許容日数、スケジューリング期間 | |
| コールオブジェクト設定 | ◎ オーナー | コールオブジェクトタイプ(指図または通知)、指図タイプ、優先度 | |
| 保全項目割当 | ◎ オーナー | 技術オブジェクト、タスクリスト参照、明細説明 | |
| 完了要件 | ◎ オーナー | 完了要件フラグ、サイクル変更係数 | |
| コスト割当 | ○ COと共有 | 生成される作業指図の決済ルールはPMが設定。COは原価対象(原価センタ、WBS要素)を管理 |
凡例: ◎ = オーナー/重要, ○ = 直接関与
2.1 計画ヘッダデータ

計画ヘッダは、保全計画の識別情報と組織上の帰属を定義します。これらのフィールドは、計画の責任者と、適用されるスケジューリングエンジンのバリアントを決定します。
| フィールド | 説明 | 実務上の使用例 | |
|---|---|---|---|
| 保全計画 (番号) | 計画を一意に識別する番号 | 内部採番(番号範囲)または外部採番が可能。ブループリント時にプラントまたは設備カテゴリごとに一貫した採番ルールを確立すること。アドホックな採番は、大量レポートや計画モニタリングを困難にする。 | |
| 説明 | 自由記述の計画説明文 | 設備、頻度、保全タイプが伝わる命名規則を使用すること。例:「ポンプP-101 月次点検」。適切な説明により、IP30でのモニタリングや監査にかかる時間を大幅に削減できる。 | |
| 計画カテゴリ | 保全計画のカテゴリ | 利用可能なスケジューリングバリアントを制御する。標準PM計画はカテゴリ「PM」を使用。カスタマーサービス計画は「CS」を使用。作成時に設定する必要があり、後から変更不可。 | |
| 計画プラント | この計画を担当するプラント | 作業指図作成時のプラントコンテキストを決定する。保全項目内の設備または機能場所のプラントと一致させる必要がある。不一致があると、スケジューリング時にシステムエラーが発生する。 | |
| 保全計画グループ | 担当計画グループ | 計画担当者またはチームを示す3桁コード。標準PMレポート(例:IP24、IP25)でフィルタリングや責任割り当てに使用される。本稼働前に計画グループを定義すること。これらは主要な組織管理ポイントである。 | |
| 保全ストラテジ | ストラテジキー(ストラテジ計画のみ) | カスタマイジングで定義された保全ストラテジマスタを参照する。IP10ストラテジ計画では必須。単一サイクル計画では空白のままにする。アクティブな計画でストラテジを変更すると、すべてのスケジューリングカウンタがリセットされるため、計画的な保全ウィンドウ内でのみ実施すること。 | |
| サイクル | 保全サイクル(単一サイクル計画のみ) | 保全イベント間の間隔(日、週、月、年)。例:月次点検の場合は30日。パフォーマンスベースの計画の場合、サイクルはカウンタ値(例:500時間)。これは最も重要な単一のスケジューリングパラメータである。 |
2.2 日程計画パラメータ

スケジューリングパラメータは、IP30(期限監視)が期日を計算し、コールオブジェクトを生成するタイミングを決定するために読み取るエンジンです。これらのフィールドのエラーは、実行されているように見えながら、計画イベントを静かに見逃す保全計画の主な原因です。
| フィールド | 説明 | 実務上の使用例 | |
|---|---|---|---|
| 開始日(基本開始日) | 最初のサイクルが開始される日付 | 以降のすべての期日計算の基準点となります。最後に保全を実施した日付、または設備の試運転日を設定します。開始日が誤っていると、将来のすべての期日が同じ誤差だけずれます。計画を有効化する前に確認してください。 | |
| スケジューリング期間 | 将来のコール生成のための期間(日/週/月) | IP30がコールオブジェクトを生成する際の将来の期間を決定します。例:30日の場合、期日の最大30日前までに作業指図が作成されます。期間が短すぎると作業指図の作成が計画に間に合わず、長すぎると将来のオーダーがバックログとなり計画担当者のキューを乱雑にします。 | |
| コール生成期間(%) | コールオブジェクトが作成されるサイクルの割合 | 全サイクルのパーセンテージで表されます。例:30日サイクルの80% = 期日の6日前にコールオブジェクト作成。計画チームのリードタイム要件に合わせて作業指図作成タイミングを調整します。 | |
| 許容範囲(+/-%) | スケジュール日からの許容偏差 | 前回のコール完了がスケジュールを満たし、オフセットをリセットせずに済む範囲を定義します。例:30日サイクルの±10% = ±3日。許容範囲内で作業が完了した場合、次回期日は実際の完了日からではなく、元のスケジュール日から計算されます。これによりスケジュールのずれを防ぎます。 | |
| スケジューリング区分 | 時間 / 実績 / カレンダー | サイクル計算のトリガーを決定します。詳細はセクション1.2を参照。有効になるスケジューリングフィールドに影響します。 | |
| 工場カレンダー | プラント固有の稼働日カレンダー | カレンダーベースのスケジューリングで使用され、期日を実際の稼働日に合わせます。プラントの工場カレンダーID(SCALで定義)を参照します。正しいカレンダーを割り当てないと、期日が週末やプラント休業日に設定される原因となります。 | |
| サイクル修正係数 | サイクルに適用される乗数 | 基本サイクルを変更せずに、一時的にサイクルを圧縮または延長できます。例:係数0.5は高リスク期間中に間隔を半分にします。状況が正常化したら1.0にリセットします。使用は控えめにし、標準以外の係数は計画説明に文書化してください。 |
2.3 コールオブジェクト設定

Call Object(呼出オブジェクト)設定は、IP30が保全イベントの期限到来を判断した際にSAPが何を作成するかを決定します。これは、スケジューリングマスタと運用実行レイヤ間のリンクです。
| フィールド | 説明 | 実務上の使用例 | |
|---|---|---|---|
| コールオブジェクト | 生成されるオブジェクトのタイプ:指図または通知 | ほとんどの予防保全計画は、リソース計画とコスト追跡を最初から有効にするために、通知を経由せずに直接保全指図を作成します。保全イベントにプランナーによるレビューと承認が必要な場合は、コールオブジェクトとして通知を使用します。 | |
| 指図タイプ | 生成される作業指図のPM指図タイプ | 標準PM指図タイプ:PM01(予防保全)、PM02(緊急)、PM03(事後保全)。予防保全計画では、PM01が標準的な選択です。指図タイプは、決済ルールのデフォルト、ステータス管理、レポート分類を決定します。 | |
| 優先度 | 生成される作業指図のデフォルト優先度 | プランナーが作業の順序付けや標準PMレポート(例:IW38、IP24)で使用します。ブループリント時に優先度スキーム(1=クリティカル、2=高、3=標準、4=低)を定義し、一貫して適用します。優先度に一貫性がないと、PMレポートの有用性が損なわれます。 | |
| スケジューリング確認 | 次回サイクル計算前に確認が必要 | 有効な場合、システムは生成された指図が技術的に完了(TECO)するのを待ってから、次回の期限日を計算します。前回のイベントの完了が確認された後にのみ次回サイクルを開始すべき、状態基準またはコンプライアンス主導のメンテナンスに不可欠です。 |
2.4 保全項目割当

保全項目は、保全計画と、何をどこで行う必要があるかを定義する技術オブジェクトおよびタスクリストとの接続ポイントです。計画に割り当てられた各項目は、個別のコールオブジェクトを生成します。
| フィールド | 説明 | 実務上の使用例 | |
|---|---|---|---|
| 保全項目 | 保全項目マスタ(MPOS)への参照 | 保全項目はIP11で個別に作成され、その後IP01/IP10で計画に割り当てられます。1つの計画に複数の項目を保持でき、各項目は計画が呼び出されたときに独自の保全指図を生成します。計画を有効化する前に、すべての項目が「リリース済」ステータスであることを確認してください。 | |
| 項目テキスト | この計画-項目組み合わせの短いテキスト | 保全項目の説明を、計画固有のコンテキストで補足します。例:「2026年の規制要件に基づく年次点検」。IP30のモニタリングおよび生成された保全指図の短いテキストに表示されます。 | |
| 技術オブジェクト | 設備または機能場所 | 保全対象の設備またはロケーション。プラントと計画グループは技術オブジェクトから継承されます。計画が有効化された後に技術オブジェクトを変更すると、新しいスケジューリング履歴エントリが生成されます。オブジェクトが再割り当てされた場合は、PM計画担当チームに通知してください。 | |
| アセンブリ | 設備のサブコンポーネント | 保全タスクの範囲を設備内の特定のアセンブリ(例:ポンプユニット全体ではなくポンプモーター)に絞り込むためのオプションの詳細設定。タスクリストの作業が1つのサブアセンブリに固有である場合に使用します。 | |
| タスクリスト | この項目に割り当てられたPMタスクリスト(IA01) | 保全指図の作業と作業区を定義します。タスクリストが割り当てられていない場合、生成された保全指図には作業がなく、計画担当者が手動で追加する必要があります。予防保全計画項目には、計画有効化前に必ずリリース済(ステータス4)のタスクリストを割り当ててください。 |
2.5 完了要件

完了要件は、実際の保全完了と将来のスケジュール計算との関係を制御します。これは、次回のサイクル開始前に完了の証明が必須となる規制コンプライアンスシナリオにおいて特に重要です。
| フィールド | 説明 | 実務上の使用例 | |
|---|---|---|---|
| 完了要件 | 次サイクル開始前に、先行コールオブジェクトの完了を要求するフラグ | 有効時、IP30は現在の作業指示が技術完了(TECO)に達するまで次の作業指示を生成しません。安全規制や保険要件に準拠した保全活動には必須です。無効時、IP30は現在の作業指示のステータスに関係なく将来の作業指示を生成します。これは、高頻度・低重要度の点検に適しています。 | |
| 日程確定確認 | 確認に基づく日程計画(完了要件の代替) | より緩やかなバリエーション:次サイクルは、計画日ではなく実際の確認日から計算されます。保全チームが遅れて確認しても、後続のサイクルを実際の実行日に基づいて計画したい場合に使用します。 | |
| 遅延完了アクション | コールオブジェクトが期限超過時のシステム応答 | カスタマイジングで設定可能:アクションなし、警告、またはエラー。重要資産の場合は、プランナーに警告が表示されるよう警告に設定します。ブループリント時に、期限超過処理に関するビジネス上の判断を文書化してください。監査チームは規制業界でこの設定を頻繁に確認します。 |
次に読むべきもの
L1) Big Picture
| ID | Category | Title |
|---|---|---|
| pm-001 | Overview | SAP PMとは何ですか? |
L2-A) Master Data
| ID | Category | Title |
|---|---|---|
| pm-a01 | Overview | SAP PM マスタデータ:概要、階層、関係性 |
| pm-a02-01 | Master Data | SAP PM 機能場所 |
| pm-a02-02 | Master Data | SAP PM 設備 |
| pm-a03-01 | Master Data | SAP PM クラス |
| pm-a03-02 | Master Data | SAP PM 特性 |
| pm-a04-01 | Master Data | SAP PM 測定ポイント |
| pm-a05-01 | Master Data | SAP PM 作業区 |
| pm-a06-01 | Master Data | SAP PM 品目マスタ |
| pm-a05-02 | Master Data | SAP PM タスクリスト |
| pm-a05-03 | Master Data | SAP PM 生産資源/治工具 |
| pm-a06-03 | Master Data | SAP PM 保全部品表 |
| pm-a07-01 | Master Data | SAP PM 保全項目 |
| pm-a07-02 | Master Data | SAP PM 保全計画 📍 |
L2-B) Transaction
| ID | Category | Title |
|---|---|---|
| pm-b01 | Overview | SAP PMトランザクション:プロセスフロー、階層、および関係 |