SAP（特に PP/DS）におけるプライマリリソースとセカンダリリソースについて説明

SAP（特に PP/DS）におけるプライマリリソースとセカンダリリソースについて説明します。

プライマリリソース（Primary Resource）

プライマリリソースは、工程（アクティビティ）を実行するための主たるリソースであり、PP/DS のスケジューリングエンジンが日程計画の基準とするリソースです。

主な特徴：

• PDS/PPM のモード（Mode）において必ず1つ定義される、その工程の「主役」となるリソース
• 有限スケジューリングの対象になる。liveCache はプライマリリソースの能力・カレンダーを見てオーダーの開始日・終了日を決定する
• 能力過負荷の検知、スロット検索、挿入モードなどすべてプライマリリソースに対して実行される
• 代替モード（Alternative Mode）を持てる。つまり、同じ工程に対して「プライマリリソース A で実行するモード1」「プライマリリソース B で実行するモード2」という形で代替リソースを表現する
• 段取時間の最適化（段取マトリクス）もプライマリリソース上で計算される

典型的な例： 加工機械、製造ライン、反応釜、充填機など、その工程の処理能力を律速する設備

セカンダリリソース（Secondary Resource）

セカンダリリソースは、工程の実行に補助的に必要な追加リソースです。プライマリリソースと同時に占有されますが、スケジューリング上の扱いが大きく異なります。

主な特徴：

• 1つのモードに対して複数のセカンダリリソースを割り当てられる
• セカンダリリソースはカレンダーリソースではなく、有限スケジューリングの対象にもならない。liveCache はプライマリリソースのみを見てスケジューリングする SAP Community
• つまり、セカンダリリソースの能力不足や競合があっても、スケジューリング結果には影響しない（過負荷の警告は出せるが、日程は動かない）
• 能力所要量は記録されるため、能力負荷の可視化や事後分析には使える
• プライマリリソースのスケジュール結果に従って、同じ時間帯に能力が消費される

典型的な例： 作業者（人員）、クレーン、共有の検査設備、補助的な治工具など

両者の関係と実務的な使い分け

実務上よくある設計パターン

パターン1：機械（プライマリ）＋作業者（セカンダリ）

最も一般的な構成です。機械を有限計画の対象とし、作業者は能力負荷の可視化に使います。機械は自動化されていて律速要因であり、作業者は比較的融通が利く場合に適しています。

パターン2：機械（プライマリ）＋治具（セカンダリ）

治具の制約が緩い場合はセカンダリで十分です。ただし、治具がボトルネックの場合はセカンダリでは不十分で、先ほどのやりとりでお伝えしたように、治具自体をプライマリリソース化する設計が必要になります。

パターン3：2つのプライマリリソースを並列工程で表現

機械と治具の両方を有限計画したい場合、PDS 上で2つの工程を並列関係（時間制約で同期）として配置し、それぞれにプライマリリソースを割り当てます。作業手順からサブ工程が APO/PP/DS に転送されると、サブ工程は PDS 上で別の工程として表現され、PRT に紐づくリソースが並行して実行されます。 Ovguこれにより両方とも有限スケジューリングの対象にできます。

セカンダリリソースの限界と対処法

セカンダリリソースの最大の制約は「有限スケジューリングされない」点です。そのため、セカンダリリソースが実際にはボトルネックなのに、計画上は無視されて過負荷のまま実行不可能な計画が出来上がるリスクがあります。

この問題への対処としては、以下の方法があります。

• プライマリリソースへの昇格： ボトルネックとなるリソースは並列工程構成でプライマリリソース化する
• PDS BAdI の活用： PDS BAdI を使用して PRT をセカンダリリソースとして PDS に組み込むロジックを実装できます SAP Communityが、有限計画が必要な場合はこれでは不足する
• アラートの活用： セカンダリリソースの過負荷をアラートとして検知し、プランナーが手動で調整する運用を設計する

要点として、スケジューリングの基準にしたいリソースはプライマリ、可視化や参考情報で十分なものはセカンダリ、という判断基準で設計するのが実務上のベストプラクティスです。