
目次
SAP PPはProduction Planning(生産計画)の略です。需要を生産計画に変換し、製造指図をリリースから確認、原価決済まで実行するSAPのモジュールです。
PPは予測と受注を受け取り、在庫、部品表、作業手順、能力と照らし合わせて、何を作り、何を買い、いつ必要かを提案します。SAP S/4HANAでは、在庫/購買管理(MM)、品質管理(QM)、管理会計(CO)と並んで、製造領域に位置します。
このガイドは、工場長、計画担当者、プロジェクトリーダー向けです。私は個別生産、プロセス生産(PP-PI)、繰返生産のすべてでPPを導入してきたので、3つとも取り上げます。PPがどこで壊れるかという問いへの短い答えは、マスタデータです。
以前、週に400件を超える製造指図を抱える包装工場のチームと仕事をしたことがあります。PPがない状態では、スプレッドシートと付箋でやりくりしていました。導入後も完璧にはなりませんでしたが、溺れることはなくなりました。
PPはロジスティクスの連鎖の中心にあります。需要を受け取り、品目、能力、タイミングをさかのぼって、生産提案を作成します。需要が流れていく順に、機能を並べます。
- 販売・事業計画(SOP):予測と市場の見通しに基づく大枠の数量
- 需要管理:その数量を、MRPを動かす計画独立所要量(PIR)に変換します
- 資材所要量計画(MRP):在庫、リードタイム、未決注文を使って、何をいつどれだけ生産または購買するかを算出します
- 能力計画と能力平準化:作業区の過負荷を、現場に届く前に示します
- 製造実行:指図を作成、リリース、スケジュールし、完了と決済まで確認します
S/4HANAでは、従来のSOPは互換性スコープであり、SAPはこの役割にIBPを使うよう顧客に案内しています。どちらも後で詳しく説明します。
PPは工場を運営する唯一の方法ではありません。3つの生産形態に対応しており、どれを選ぶかで、設定する指図タイプ、マスタデータ、原価計算の方法が決まります。複数の形態を併用している工場も多くあります。
SAPが提供する3つの形態を表で比較します。
| 形態 | 代表的な業種 | 実行オブジェクト | 中核となるマスタデータ | 原価計算 |
|---|---|---|---|---|
| 個別生産 | 機械、電子機器、自動車部品、防衛装備 | 製造指図 | 部品表、作業手順、作業区 | 指図別、完了時に決済 |
| プロセス生産(PP-PI) | 食品、飲料、化学品、医薬品 | プロセス指図 | マスタレシピ、リソース、部品表 | 指図別、連産品と副産品を含む |
| 繰返生産 | 包装、消費財、大量生産ライン | ラインスケジュール上の計画手配 | 生産バージョン、生産ライン、レート作業手順または作業手順 | 期間別 |
個別生産
「SAP PP」と言うとき、多くの人が想定しているのが個別生産です。MRPが計画手配を作成し、計画担当者がそれを製造指図に変換します。各指図は、それぞれの構成品目、作業、原価を持ちます。独立したロットで、多くは受注ごとに作られ、指図ごとの追跡が必要な製品に向いています。
プロセス生産(PP-PI)
PP-PI(Production Planning for Process Industries)は、バッチとレシピに基づく生産を扱います。製造指図の代わりにプロセス指図を、作業手順の代わりにマスタレシピを使い、連産品、副産品、バッチトレーサビリティを加えます。医薬品や食品のような規制業種では、このバッチ単位の記録は、あれば便利なものではなく、コンプライアンス上の要件です。
繰返生産
繰返生産は、同じ製品を同じラインで長期間作る場合に向いています。個別の指図の代わりに、ラインスケジュール上で期間単位の計画を実行し、作業者は計画手配に対して直接確認を入力します。SAPの繰返生産に関するドキュメントは、期間ベースの計画と、完成数量の確認時に構成品目の消費を転記するバックフラッシュについて説明しています。
トレードオフは詳細度です。繰返生産では指図処理の負担がなくなり、原価は指図別ではなく期間別に決済されます。ロットごとの原価とトレーサビリティが必要なら、個別生産かPP-PIのほうが適しています。
需要から完了までの流れは5つの段階に分かれます。実際には中断なく進むことはまれですが、PPはこの構造を管理するように作られています。
- SOP予測に基づく数量目標
- 需要管理MRP実行を動かすPIR
- MRP計画手配と購買依頼
- 製造実行指図のリリースと品目の準備
- 確認作業時間、数量、在庫移動の転記
SAPが現場で実際に起きたことを反映する
需要管理はPIRを生成します。PIRは予測です。この製品をこの時期にこの数量必要になる見込みだ、というものです。PIRはMRPの入力であり、ここでの誤りは連鎖します。あるクライアントは、3か月分のPIRを二重にアップロードしてしまいました。生産があらゆるものを過剰に発注し始めるまで、誰も気づきませんでした。
MRPは計画エンジンです。PIRと受注を在庫と未決入庫に対して正味計算し、社内製造品には計画手配を、購入部品には購買依頼を作成します。不正確なマスタデータの上で実行すると、計画担当者が何週間も追いかけるノイズが生まれます。
実行と確認でループが閉じます。指図がリリースされ、品目が準備され、作業区で作業が行われます。その後、作業時間、数量、在庫移動が転記され、システムは現場で起きたことを反映します。ただし、確認が期限内に入力されていればの話です。
ECCから移行するなら、設計とデータに影響する計画面の変更はここです。移行パス全体については、私のECCからS/4HANAへの移行ガイドをご覧ください。
MRP Live
MRP Live(トランザクションMD01N)は、S/4HANAでSAPが推奨する計画実行です。SAP HANAデータベースの中で実行され、1回の実行で1つまたは複数のプラントを計画でき、従来のMRPリストは書き出しません。SAPのMRP Liveの学習モジュールは入門として優れており、MRP Liveの操作に関するSAP Helpのページには設定の詳細があります。
これに伴って、ほかに3つの変更があります。
- 生産バージョンが必須になります。社内製造品目が対象です。生産バージョンがないとMRP Liveは部品表を展開しないため、部品表選択方法に頼っていたECCのお客様は、コンバージョンの中で生産バージョンを作成する必要があります。
- 保管場所MRPはMRPエリアに置き換わります。 ECCで個別に計画していた保管場所には、S/4HANAではMRPエリアが必要です。
- SOP、MRPリスト、予測ベースの計画は互換性スコープです。 利用権には期限があり、契約形態によって異なります。SAPはその日付を何度も変更してきました。これらを前提に設計する前に、SAP Note 2269324をご自身の契約と照らし合わせて確認してください。
組込PP/DS
PP/DS(Production Planning and Detailed Scheduling)は、かつてSAP APOにあった高度計画エンジンです。S/4HANAでは組み込まれているため、別のAPOシステムを運用する必要はありません。有限能力スケジューリング、段取順序、部品表の階層をまたぐペギングを追加します。
MRP LiveとPP/DSは、品目ごとに仕事を分担します。品目マスタで高度計画のフラグが立っている品目はPP/DSに渡り、それ以外はMRP Liveに残ります。SAPのPP/DSの学習コンテンツは、ボトルネックリソース上の重要製品はPP/DSで、重要度の低い消費ベースの品目はMRP Liveで計画することを勧めています。
私は導入プロジェクトで、MRP Liveと組込PP/DSの両方を使ってきました。機能一覧よりも重要な実務上のポイントが2つあります。
- ボトルネックリソースを共有するものは、すべてPP/DSで計画してください。 制約のあるライン上の製品の半分がMRP Liveに残っていると、そのラインの有限能力計画は機能しません。
- PP/DSの品目は、MRP Liveの計画範囲から除外してください。 そうしないと、後のMRP Liveの実行でそれらが再スケジュールされ、詳細スケジューリングの結果が失われます。
MRP Live、PP/DS、IBPがそれぞれ何を計画するかを並べて見るには、私の「MRP Live、PP/DS、IBPの比較」をご覧ください。
PP/DSを前提に設計する前に、ご自身の契約で何がカバーされているかを確認してください。
PPは工場を計画します。何を、どのラインで、どの週に作るかです。SAP Integrated Business Planning(IBP)は、その上位で事業を計画します。販売・事業計画、需要予測、在庫計画、ネットワーク全体の供給計画をカバーするクラウド製品です。
私はクライアントにIBPを勧めたことがありますが、それはケースが求めた場合に限ります。MRP Liveだけでうまく回っている工場もあります。
ボトルネックのラインのためにPP/DSが必要な工場もあります。さらに少数のグループでは、計画の問題がそもそも現場にないため、IBPが必要になります。
私がこの3つの層をどう分けているかを表に示します。
| 計画の問い | ツール | 計画期間 | 上位へ移る典型的なきっかけ |
|---|---|---|---|
| 何を作り、何を買い、いつ必要か | S/4HANAのMRP Live | 数日から数か月 | 制約のあるリソースで計画担当者がMRPを上書きしている |
| 有限能力で、ラインをどの順序で動かすか | 組込PP/DS | 数時間から数週間 | 数量と製品構成の判断が、複数の工場や地域にまたがっている |
| 事業として、どれだけ販売し、在庫を持ち、供給すべきか | SAP IBP | 数か月から数年 | 複数拠点のネットワーク、合意された需要、シナリオ計画 |
IBPを示すシグナルは次のとおりです。
- 財務部門が参加する月次の販売・事業計画プロセスが必要です。
- 需要が、多数の顧客とチャネルにまたがる統計的な予測から生まれています。
- 供給の判断が、複数の工場と物流センターにまたがっています。
従来のSOPが互換性スコープであることで、この判断には期限が加わります。IBP側については、私のガイド「SAP IBPが重要な理由」で詳しく取り上げています。
工場のためにSAPとほかのERPのどちらにするかまだ検討中なら、私の「製造業向けERPのおすすめ」の比較で、企業規模と業態別に選択肢を整理しています。
SAP PPの導入でマスタデータを急げば、ほかのすべてが回避策になります。部品表の正確さ、作業手順の完全さ、作業区の保守。どれも省けません。
マスタデータはSAP PPの背骨です。決まり文句ではありません。結果を伴う事実です。
品目マスタ(MRPビュー)。 製造するすべての品目で、MRPビューを正しく設定する必要があります。MRPタイプ、ロットサイズ、ストラテジグループ、利用可能在庫確認、スケジュールマージンキーは、それぞれMRPの動きを変えます。私が関わったプロジェクトでは、品目マスタの項目が1つ欠けていただけで、生産が1週間止まりました。たった1つの項目です。
ストラテジグループ。 ストラテジグループは、受注がPIRを消費するかどうかを制御します。これが間違っていると、受注と予測が相殺されずに並行して動き、エラーメッセージもないまま需要シグナルが2倍になります。
部品表(BOM)。 部品表は、完成品に何が入るかを定義します。構成品目、数量、仕損率、場合によっては代替品です。「この1品目に本当に5つも部品表が必要なのか」という問いには、ちゃんとした答えがあります。MRPを実行しながらではなく、導入前に答えを出してください。
作業手順とマスタレシピ。 作業手順は、どのように作るかを定義します。作業、作業区、時間です。プロセス産業では代わりにマスタレシピを使います。これがないと、SAPは生産にかかる時間を計算することも、能力を確認することもできません。
作業区。 作業区には、スケジュールの計算式、原価計算とのつながり、シフトカレンダーが含まれます。本稼働後に最新の状態を保つことは、後回しにされがちな作業です。そうなると能力計画が不正確になり、計画担当者はシステムを信頼しなくなります。
最初のMRP実行前の準備チェックリスト
移行したデータでMRPを動かす前に、この順序で確認してください。括弧内は承認する担当者です。
- 品目マスタのMRPビューが完全であること:計画対象のすべての品目について、ストラテジグループとロットサイズを含む(計画リーダー)
- 部品表が実際の製造内容と照合されていること:エンジニアリング部門が構成品目と仕損を確認(エンジニアリング)
- すべての社内製造品目に作業手順またはマスタレシピがあること:現実的な作業時間で(生産技術)
- 作業区のカレンダーと能力が現在のシフトを反映していること(工場長)
- 社内製造品目ごとに有効な生産バージョンが1つあること:計画期間をカバー(計画リーダー)
- PIRが1回だけロードされていること:最初の実行前に、承認済みの需要計画と照合(需要計画担当者)
- 未決注文と在庫が照合されていること:旧システムとSAPの間で(在庫管理担当者)
- 1つのプラントまたはMRPエリアでのテストMRP実行:本実行の前に計画担当者が例外を確認(計画リーダー)
PPは単独では動きません。MMはPPが必要とするものを調達し、SDの受注は予測を消費し、COは実際原価を標準原価と比較し、QMの検査ロットは指図を止めることがあります。連携ポイントの一つひとつが、失敗のポイントでもあります。
私はこれまでに本物の大失敗をいくつも見てきました。避けるべきパターンは次のとおりです。
- マスタデータ移行を急ぐ。 部品表と作業手順の移行を急いだ自動車部品メーカーのことを覚えています。本稼働後の6か月間、データの問題で失敗し続ける製造指図の修正に追われました。詳しくは「SAPのデータ移行が失敗する理由」をご覧ください。
- 旧来の業務を再現する。 私が最も一貫して目にする設定上の誤りは、標準の計画ロジックを採用せず、旧来の業務とまったく同じように動くようSAPを設定することです。その結果、設定過多で、PPが本来提供するはずの成果を下回るシステムになります。
- 連携のテストが不十分。 モジュールごとに単独でテストするチームは、連携の問題を本番で発見します。私の「SAPテスト」のガイドにあるとおり、PP、MM、SD、CO、QMをまたぐ計画から生産までの一連の流れをテストしてください。
- ユーザーの抵抗。 経験豊富な計画担当者は、これまで手作業と自分の判断で行ってきた仕事をPPが引き継ぐため、PPに抵抗することがよくあります。早い段階で設定作業に参加してもらい、PPによってどこで時間が生まれるかを示してください。
- トレーニングを削る。 導入に数百万ドルを費やしたあと、トレーニングを削って費用を節約する企業を見てきました。システムを理解していないユーザーは回避策を作り、回避策はMRPが依存するデータの正確さを損ないます。
各リスクを、影響と、私なら計画に組み込む軽減策に対応させた表です。
| リスク | 影響 | 軽減策 |
|---|---|---|
| MRPの設定の誤り | 欠品、過剰生産、過剰な調達コスト | MRPタイプ、ストラテジグループ、ロットサイズを業務リーダーと検証する |
| 部品表、作業手順、レシピの不正確さ | 誤った所要量、現場の遅れ | 移行前のレビューにエンジニアリング部門を参加させる |
| 生産バージョンの欠落 | MRPが部品表を展開できず、有効な指図を作成できない | 社内製造品目ごとに有効な生産バージョンを1つ |
| PP/DSとMRP Liveの重複 | 詳細スケジュールが次のMRP実行で上書きされる | PP/DSの品目をMRP Liveの計画範囲から除外する |
| 現場からのリアルタイムのフィードバックがない | ステータスが不正確で、逸脱が見えるのが遅れる | 期限内の確認を徹底し、SAP Digital Manufacturingまたは別のMESと連携する |
| トレーニング不足のユーザー | 誤った確認、バックフラッシュのエラー、未解決の手直し | 実際の生産サイクルに基づく役割別トレーニング |
SAP PPの正式名称は何ですか?
SAP PPはProduction Planning(生産計画)の略です。需要とMRPから、製造指図、確認、原価決済まで、製造の計画と実行を担うSAPのモジュールです。
SAP PPモジュールは何に使われますか?
SAP PPモジュールは、予測と受注からの需要を、MRPを通じて生産能力に結び付けます。部品表、作業手順、作業区、生産バージョンを管理し、製造指図やプロセス指図を作成から決済まで実行します。
SAP PPとSAP PP-PIの違いは何ですか?
狭い意味でのSAP PPは、個別生産と繰返生産をカバーし、部品表と作業手順に基づく製造指図やラインスケジュールを使います。PP-PIは、食品、化学品、医薬品におけるバッチとレシピに基づく生産のためのものです。プロセス指図とマスタレシピを使い、連産品、副産品、バッチトレーサビリティを加えます。
SAP S/4HANAのMRP Liveとは何ですか?
MRP Live(トランザクションMD01N)は、S/4HANAでSAPが推奨するMRP実行です。SAP HANAデータベースの中で実行され、1回の実行で複数のプラントを計画でき、従来のMRPリストは作成しません。高度計画のフラグが立っている品目は、PP/DSに引き渡されます。
SAP PPとPP/DSの違いは何ですか?
MRP Liveを使うPPは、無限能力で計画します。何を作り、何を買い、いつ必要かです。PP/DSは、ボトルネックリソース上の重要品目について、有限能力スケジューリング、段取順序、ペギングを追加します。S/4HANAではPP/DSは組み込まれています。ご自身の契約でどのようにライセンスされているかはSAPに確認してください。
SAP IBPはSAP PPを置き換えますか?
いいえ。IBPは、販売・事業計画、需要、在庫、供給を事業全体で計画し、通常は月次または週次の単位で扱います。工場での生産の計画と実行は、引き続きPPが担います。
IBPは、S/4HANAで互換性スコープとなっている従来のSOPの後継として、SAPが名前を挙げている製品です。
S/4HANAプログラムでPPのスコープを決めるなら、まず3つのことを固めてください。各工場がどの生産形態で動いているか、どの品目にPP/DSが必要か、そして計画の問題がそもそもIBPに属するものかどうかです。その設計についてセカンドオピニオンが必要なら、SAPプログラムについて私にご相談ください。
次のステップ
いまERPプログラムを進めていますか?
この記事が、いま進行中のプログラムに関わる内容だったなら、社内でさらに1週間分析を重ねるよりも、30分の対話のほうが多くの場合ずっと前に進めます。




