SAP MRP LiveとClassic MRPの違いとは?(vol.83)
- 公開日:
- 最終更新日:

多品種少量生産や複雑な顧客仕様に起因するBOMの複雑化/肥大化 及び それに伴う品目件数の増加など、MRPを実行する上でパフォーマンスの妨げになる要因は日々増えていると思います。
そこで本ブログでは、それらの課題を解決するためにSAP社が提供している高速MRP:「MRP Live」について、その特徴やClassic MRPとの差異、パラメータ値や並列処理設定方法などを解説します。
さらに、「MRP Live」の利用にあたり必要となるパフォーマンステストについて、インフラ環境/データ(マスタ)/使用ツール(機能)やテストの流れなど、ポイントを解説します。
*MRP機能を活用するためのポイントやMRP機能単独では解決できない課題=MRP機能の限界&その解決策については、こちらのブログ記事をご覧ください。
目次
SAP MRP Liveの特徴
「MRP Live」の主な特徴は、次の2点です。
- 処理の高速化
「MRP Live」の最大のポイントである処理の高速化は、HANA DBの内部並列処理化とMRPロジックをHANA DBに実行させる「Code Push Down」により実現されています。これにより従来のClassic MRPよりはるかに高速な計画が出来るようになりました。
※少量の品目のみをMRP実行するのであれば、従来のClassic MRPのほうが高速な場合があります。 - Classic MRPロジックによるMRP実行選択
「MRP Live」では上述の通り、MRPロジックをHANA DBにPush Downさせました。その結果、Classic MRPで実行されていたBadiは、MRP Live では実行されなくなりました。
対応策として、
①MRP Liveで実行される「AMDP Badi」に旧来のBadiと同様のロジックを組み込む
②MRP Liveの中でCalssic-MRPロジックによるMRPを実行させるようにする
の2つが考えられます。
トランザクション「MD_MRP_FORCE_CLASSIC」にて、品目毎にMRP Live/Classic MRPのどちらでMPR実行するかを指定することが可能です。
※多数の品目をClassic MRPで実行させてしまうとパフォーマンス低下につながるので注意が必要です。
SAP MRP LiveとClassic MRPの差異
「MRP live」とClassic MRPでは、主に次の4つの差異があります。
- MRP一覧の消失
MRP高速化の代償として、Classic MRPではMRP処理実行後に作成され、T-CD:MD05/MD06で照会する事ができた「MRP一覧」が作成されなくなりました。その代わり、「MRPコックピット」というFioriアプリ群が提供されるようになり、こちらのアプリでライブデータを分析するというコンセプトに変わりました。
※どうしてもMRPリストの情報が必要な場合はAPI「MD_MDPSX_READ_API」にて情報取得できます。 - 仕入品に対する購買依頼の登録
仕入品に関して、MRP Liveでは計画手配が登録されず、常に購買依頼が登録されます。そのため、「開放期間内の計画手配は購買依頼に変換する」という指定も出来ません。
もし仮に、「仕入品でも計画手配伝票を作成したい」といった場合は、AMDP Badi「PPH_MRP_SOURCING_BADI => SOS_DET_ADJUST」にて、計画されるMRP要素を変更できます。 - MPS計画
MPS計画はMRP Liveに統合され、パラメータによって処理対象をMRP/MPSから選択できるようになりました。 - パフォーマンスログ
MRP Live実行時にログ名を設定できるようになり、パフォーマンスログはトランザクション「MD_MRP_PERFLOG」で確認できるようになりました。このログでは、MRP実行条件や各ローレベル毎の計画件数/処理時間等を確認する事が出来ますが、品目毎の詳細処理時間等は照会できません。
SAP MRP Live (MD01N)のシステム設定
「MRP Live」には、実行画面では表示されない幾つかの設定があります。これは、テーブル「PPHMRPSET」にあり、テーブルを更新するトランザクションも「PPHMRPSET」です。トランザクションが実行できない場合は、SE16Nで上記テーブルの更新を行えます。
「PPHMRPSET」ではいくつかのパラメータ設定が可能であり、これらの値を変更する事でMPR Liveの設定を変更できます。これらパラメータをいくつか解説します。
- パラメータ:HANA計画パッケージのパッケージサイズ
このパラメータにより、計画パッケージ毎に渡される品目数を定義します。MRPではパッケージをこの数よりも小さくしないようにします。 - パラメータ:HANAの並列タスク数
このパラメータにより、並列タスクの最大数を定義します。HANAを最大限に活用してMRP実行中のCPU負荷を減らすために、MRPディスパッチに複数のHANAプロセスを同時に実行するように指示できます。 - パラメータ:ABAPの並列タスク数
このパラメータにより、従来のMRPおよびアドバンスト計画(組込PP/DS)に使用される並列タスクの最大数を定義します。 - パラメータ:ABAP計画パッケージのパッケージサイズ
このパラメータにより、従来のMRPまたはアドバンスト計画(組込PP/DS)の計画タスク毎に渡される品目の最大数を定義します。 - パラメータ:日程計画のパッケージサイズ
このパラメータにより、リードタイム日程計画などを使用して処理される品目の数を指定します。このパラメータはClassic MRP(MD01/MD02/MD03など)によってトリガーされる計画実行には影響しません。 - パラメータ:HANAで計画される品目の最少数
HANAは大量の品目を同時処理するには適していますが、少量のデータボリュームで少数の品目を処理するには時間がかかる事があります。このパラメータにより、HANAではなく、ABAPで少数の品目のみのMRPレベルを計画することができます。 - パラメータ:同時に計画される品目の最大数
このパラメータにより、計画タスクに割り当てる品目の最大数を指定できます。メモリ障害が発生した場合や、処理中にHANAボックスのメモリが不足している場合は、このパラメータを減らすなどしてして調整します。パラメータ2:「HANAの並列タスク数」を多くした場合は、このパラメータを調整することが有効な場合があります。 - パラメータ:購買依頼後処理のパッケージサイズ
新規購買依頼が登録されると、この伝票を拡張するための後処理がバックグランドで実施されます。処理された購買依頼は、「ENQUEUE」によってロックされる必要があります。処理はパッケージ単位で行われます。このパラメータにより、1つのパッケージで処理される購買依頼の数を定義できます。 - パラメータ:後処理に使用される並列タスク数
MRP Liveでは一部の計画が後処理ステップで実行されますが、このパラメータにより、後処理の並列数を指定できます。 - パラメータ:HANAおよびABAPベース計画の並列実行の有効化
通常MRP Liveで殆どの品目が計画されますが、Classic MRPでの計画比率が大きい場合、このパラメータにより、HANAとABAPの計画パッケージを平行して実行できます。 - パラメータ:MRPサーバーグループ
複数のアプリケーションサーバーを立ててMRP Liveを実行する場合、このパラメータにより、サーバーグループ名を指定します。サーバーグループはトランザクション「RZ12」で指定できます。並列化はHANAおよびABAPで計画された品目で参照されますが、設定次第ではABAPで計画された品目のみで参照されます。
ここまで、「MRP Live」の特徴やClassic MRPとの違い、「MRP Live」のパラメータ値や並列処理設定方法などを解説して参りました。
実際に「MRP Live」を利用する際は、インフラ環境やデータモデル、日々の運用サイクルを決める必要があります。そのためには、検討のための情報取得を目的としたパフォーマンステストの実施が必要となります。
そこで次章からは、「MRP Live」のパフォーマンステストで使用するインフラ環境/データ(マスタ)/使用ツール(機能)やテストの流れについて、ポイントを解説します。
SAP MRP Liveパフォーマンステスト用のインフラ環境
パフォーマンス測定は、いくつかの異なるスペックのサーバで実行し、各スペックでのパフォーマンスを比較します。ただし、システム導入の初期段階でパフォーマンス測定用に複数のインフラ環境をオンプレ型で準備することは、費用的スケジュール的にも難しいと思いますので、クラウド型のインフラ環境のご用意をお勧めします。
クラウド型のインフラ環境であれば、インスタンスタイプと呼ばれるメモリ量や搭載CPUスペックの違うサーバタイプをメニューから選択するだけでサーバを準備することができます。また、クラウド型のインフラ環境は、使用時間による従量課金のため、必要最低限の費用に抑えることが可能です。
インメモリデータベースであるSAP HANAのパフォーマンステストにおいては、メモリ量とCPUスペックがパフォーマンスに影響を与えると考えられるため、搭載メモリ量とCPUスペックに着眼した、高/中/低の3種類のインスタンスタイプをご用意することを推奨します。
SAP MRPLive パフォーマンステスト用のデータ(マスタ)
MRP Liveのパフォーマンス測定で必要となる主要なマスタとそのポイントは次の通りです。
*もちろん、ユーザ企業の業種や生産形態(見込生産/受注生産 等)、生産方式(ライン型、セル型 等)、BOM管理方針などによって、必要となるマスタは異なります。
- 品目マスタ(MM01-03)
品目に関する基本情報を登録します。
受注BOMを保持管理する場合でも、品目マスタは受注固有の情報は保持しません。
代表的な設定項目として、【MRPタイプ】【ロットまとめ方式】【ロットサイズ】【特殊調達タイプ】【保管場所】【MRPエリア】などがあります。 - 品目BOM(CS01-03)、受注BOM(CS61-63,CU51)
部品構成を登録します。
受注毎に個別のBOMを保持管理する場合は受注BOMを登録します。
品目BOMから受注BOMをコピーして作成する場合はCU51を使用します。
代表的な設定項目として、【BOM用途】【基本数量】【数量】【出庫保管場所】などがあります。 - 作業区(CR01-03)、作業手順(CA01-03)
作業を行う場所と品目の生産工程、順序を定義します。 - 受注(VA01-03)
MRP計算の所要量情報となる製品の受注を登録します。
代表的な設定項目として、【指定納期】【受注数量】【拒否理由】などがあります。
【拒否理由】を設定することでMRP計算の対象から除外することができるため、MRP計算の対象データの増減コントロールに有効です。 - 計画独立所要量(MD61-63)
MRP計算の需要情報となる製品/半製品の生産計画を登録します。
SAP MRPLive パフォーマンステスト用で使用するツール(機能)
MRP Liveのパフォーマンステストで使用するツール(機能)やトランザクションは次の通りです。
- 汎用バッチインプット(大量データ登録)
パフォーマンス測定に必要な大量のマスタデータ(マスタによっては数千~数十万件)を一件ずつ画面から登録する事は現実的ではありません。大量データ登録時は、SAP画面からのユーザの入力作業を記録し、EXCELシート/テキストファイルで用意した大量データを自動で登録することが出来る汎用バッチインプットツールを使用します。
特別なプログラム開発も不要で、様々なマスタに対応出来るため、パフォーマンス測定データのように手軽に大量データを登録したいときに重宝します。 - MRP Liveの実行:MRP Live(MD01N)
MRP Liveを実行します。長時間処理が見込まる場合やMRPと並行して測定用PCを別の作業で使いたい場合は、バックグラウンドでの実行をお勧めします。また、実行時にパフォーマンスログ名を指定できるので、後で見やすいよう、測定のケースNo.やインプットのデータ数、サーバのスペックが一瞥してわかるように命名すると良いでしょう。 - データ数のカウント:一般テーブル照会(SE16N)
MRPパフォーマンス測定前後の各種マスタや作成された計画手配オーダーの件数カウントやエビデンス取得に使用します。 - バッチジョブの状況確認:バッチジョブの一覧(SM37)
MRP Liveをバックグランドで実行した後、該当ジョブの状況を定期的に監視し、ステータス(開始時間/終了時間、所要時間)を確認します。 - MRP Liveパフォーマンスログ(MD_MRP_PERFLOG)
MRP Live実行時に指定した名称で保存されたパフォーマンスログを分析します。このログでは、MRP実行条件や各ローレベル毎の計算件数/処理時間などを確認できます。 - MRP Liveの動作設定:PPHMRPSETの更新(PPHMRSET)
MRP Live実行時の並列タスク数やパッケージサイズなど、いくつかのパラメータ設定が可能です。 - メモリやCPU利用量分析(DB02)
メモリの使用量やCPUの負荷状況を分析出来ます。ログ情報から後追いで分析可能です。
SAP MRPLive パフォーマンステストの流れと注意点
さて、ここまでMRP Liveのパフォーマンステストで必要となるインフラ環境/データ(マスタ)/ツール(機能)について解説しましたが、パフォーマンステストの流れと注意点についても解説します。
- テストサイクルと順序
パフォーマンス測定では、データ量とインフラスペックという、変動する2つの要素を比較します。クラウド型のインフラ環境を使用する場合は、サーバ停止後、インスタンスタイプを変更して再起動することで簡単にインフラスペックを切り替えられますが、オンプレ型のインフラ環境を使用する場合は、切替に多くの作業時間が必要となります。効率とテストのしやすさ考慮すると、同一インフラスペックでデータ量を変動させてテストを完了し、その後インフラスペックを変更するテストサイクルにするのが理想的です。また、データ量は少量→大量、インフラスペックは高スペック→低スペックの順序でテストを推奨します。逆の順序にした場合、メモリ容量やヒープメモリ設定の問題でMRP Liveがエラー終了し、パフォーマンステストの初期段階で作業が頓挫する可能性があるからです。
負荷の少ないデータ量やインフラスペックで、まずは1サイクルMRP Liveを正常終了させ、初期のデータエラーを抽出したり、ミニマムの処理時間を得ることでその後のテストスケジュールが立てやすくなります。
- パフォーマンス測定で取得する情報
①SE16Nを使用し、実行前に変動させる需要データインプットデータの件数を取得(受注数、計画独立所要量の数)
②SE16Nを使用し、MRP Liveの主要なOUTPUTデータである計画手配(PLAF)と購買依頼(EBAN)の件数をMRP実行前後で取得
③SM37を使用し、開始/終了時間と所要時間を取得
④DB02を使用し、メモリ使用量とCPU使用率の推移を取得
まとめ
本ブログ記事では、前半で「MRP Live」の特徴やClassic MRPとの違い、「MRP Live」のパラメータ値や並列処理設定方法を、後半ではパフォーマンステストで使用するインフラ環境/データ(マスタ)/使用ツール(機能)やテストの流れについてのポイントを解説して参りました。
「MRP Live」はClassic MRPに比べて高速化されていますが、Classic MRPとの併用判断や、MRP-Listがない、ABENDさせないためのメモリ設定値の見極めなど、MRPを運用していく上で難しくなったと感じる部分もあります。
また、実際にパフォーマンステストをやってみると、大量データ登録の処理時間、機能的な成約、登録データの予期せぬ問題、メモリの枯渇によるMRP Liveのエラー終了など、いくつかの課題が発生することがあります。
もし、SAP S/4HANAのMRP運用やパフォーマンスに課題がございましたら、是非、弊社電通総研にお声掛けください。
https://erp.dentsusoken.com/inquiry/
本ブログは、2023年2月1日時点の情報を基に作成しています。製品・サービスに関する詳しいお問い合わせは、電通総研のWebサイトからお問い合わせください。