「MRPを毎晩回しているのに、欠品の連絡が人づてに届く」「前倒し提案を見た購買担当者が発注を変更したが、製造計画は旧日付のままだった」。こうした問題を解くために、製造業のMRP例外メッセージ管理システムを導入するなら、画面の通知件数よりも、提案を誰が判断し、どの確定伝票へ反映し、次回の計算でどう再確認するかを仕様にすべきです。本記事はタイ工場の購買・生産管理・倉庫・IT部門がRFPと受入試験を組み立てるための実務ガイドです。
MRP例外メッセージ管理とは何か
MRP（資材所要量計画）は、需要、在庫、入荷予定、BOM、リードタイムなどを突き合わせ、補充や日付変更の必要性を計算します。その結果として出る例外メッセージは、通常の計画から外れる状況、あるいは既存の供給伝票を変更した方がよい可能性を計画担当者に示すものです。ただし名称、コード、対象伝票、計算範囲は製品ごとに異なります。SAPの再日程計算では確定済み入荷要素に対して前倒し・後ろ倒しの提案が出る場合があり、Microsoft Dynamics 365ではaction messageが前倒し、延期、数量増減の提案として説明されています。どちらも、提案を承認なしで現場へ自動適用すべきという意味ではありません。SAPの再日程計算、Microsoftのaction messagesを製品仕様の一次資料として参照してください。
本記事でいう「例外管理システム」は、MRP計算エンジンそのものの置き換えではありません。既存ERPやAPSが出した提案を、担当者に配り、根拠を示し、処置・保留・却下を記録し、確定伝票との整合を確認する運用層を指します。対象が「材料不足の可視化」だけなら、ERP標準の材料カバレッジ画面で足りる可能性があります。一方、複数工場、仕入先、タイ国内外の調達拠点をまたぎ、メール・Excel・チャットで例外処理が分断されているなら、処置の状態と履歴を一つにする価値が出ます。購買システム全体の選定ではなく、MRP提案の判断と反映の境界に絞るのが導入範囲を保つコツです。
通知と業務上の例外は同じではない
計画結果に表示されたメッセージをすべて「要対応」と扱うと、担当者は重要案件を見落とします。既に仕入先へ催促中の発注、承認待ちの変更、休日カレンダーで見かけ上ずれた予定、安全在庫の設定による警告、実際に生産を止める不足は意味が違います。業務上の例外として扱う条件を「いつ、どの材料が、どの製造指示・顧客注文に影響するか」「現時点で行動可能か」に結び付けます。画面上の色や警告コードではなく、影響先と期限で優先順位を決めるべきです。
提案は確定済み伝票ではない
前倒し提案が出ても、仕入先が納期を受諾したとは限りません。数量増加提案が出ても、MOQ、発注倍数、単価契約、輸送枠、倉庫容量を通過したとは限りません。製造指示の前倒しなら設備能力、治具、人員、材料の可用性も必要です。システムは「提案」「担当者の判断」「相手先との合意」「ERPで確定した値」を別フィールドとして持ち、どこまで進んだかを追跡します。Microsoftの公式説明もaction messageを変更の*提案*と定義し、採用するかは利用者が決めるとしています。Microsoftのaction messages。
導入対象にする四つのメッセージ
初期導入で全コードを一度に扱う必要はありません。まず前倒し、後ろ倒し、数量増、数量減の四群を対象にし、欠品や遅延は別の影響表示として扱うと設計が明確です。Microsoft Dynamics 365のaction messageにも、この四つの提案類型があります。SAPで使うコードを他製品へそのまま移植すると誤解を招くため、RFPでは「業務上の意味」と「伝票に対する操作」を定義し、製品固有コードを対応表にします。
| 類型 | 計画上の問い | 最初に確認する証拠 | 処置の例 |
|---|---|---|---|
| 前倒し | 今の入荷・製造日では需要に間に合うか | 要求日、約束日、仕入先回答、能力 | 催促、代替、計画変更、顧客回答 |
| 後ろ倒し | 早過ぎる入荷が在庫を増やすか | 発注変更条件、保管制約、需要の確度 | 変更依頼、維持、分納 |
| 数量増 | 追加手配が必要か | 正味不足、MOQ、発注倍数、歩留り | 発注増、代替材、需要調整 |
| 数量減 | 過剰手配を減らせるか | 取消可能期限、契約、仕掛進度 | 減数、他用途へ振替、維持 |
この表は実務分類の例です。実際の計算結果やコードは採用製品の設定に従います。影響顧客と材料を持たずに「前倒しだけ」をキューへ入れても、担当者は判断できません。少なくとも計算時刻、計画版、品目、拠点、需要・供給の参照ID、旧日付・提案日付、旧数量・提案数量、発効可否の情報が必要です。
なぜ例外が消えないのか：データと計画版を先に見る
例外処理の効率を語る前に、信頼できる計画入力があるかを確認します。BOMの誤版、購買リードタイムの未更新、入荷実績の登録遅れ、安全在庫の用途不明、代替材の承認漏れが残っていると、同じ警告が毎回再生成されます。警告を「処理済み」にするボタンだけ増やしても、次夜のMRPで再発する理由は残ります。MRPマスタ精度の関連記事で入力の品質を先に整理し、例外管理の案件とマスタ修正案件を区別してください。
計画版も重要です。午前8時に計算結果を取り込んだ後、営業が数量を増やし、午後2時に担当者が朝の前倒し提案を承認する場合、朝の前提は既に古いかもしれません。レコードに「MRP実行ID」「基準時点」「元需要・元供給の版」「再評価期限」を持たせ、承認前に対象伝票が変わっていないかチェックします。旧版の案件を勝手に新しい計画へ上書きするのではなく、旧版を無効化し、再計算で新しい提案との関係を残します。
不足量の数字だけで優先順位を決めない
同じ100個不足でも、明日の組立停止に直結する部品と来月の安全在庫を下回る部品では判断が違います。必要日、次回入荷、代替可能性、顧客優先度、対象製造指示、欠品が実際に起こるまでの時間を組み合わせます。SAPの材料カバレッジ画面では不足定義と不足までの時間を選んで監視できます。これは「不足」の表示がどの定義と時間軸に依存するかを示す良い例です。SAP Monitor Material Coverage。自社導入時も「不足」を一つの絶対値として扱わず、何を含めた見込み在庫かを表示してください。
カレンダーと時間帯を固定する
タイ工場でも調達先が日本や他のASEAN拠点なら、工場稼働日と仕入先営業日が異なります。「3日前倒し」の意味は暦日か営業日かで変わります。ERPの計算に使う工場、倉庫、仕入先、輸送のカレンダーを一覧化し、タイ時間で画面に見える期限とERP内部のタイムゾーンを決めてください。金曜の夜に出た案件を月曜朝のSLA違反として数えるかは、データ処理の問題ではなく運用規則です。RFPには「休日を含むリードタイムの再計算」「跨日・跨月・跨年の境界」「日時の表示変換」の試験を明記します。
処置フローを一枚で決める
良いワークフローは通知を増やすことではなく、担当者が状態を追えることです。標準状態を「新規」「調査中」「仕入先回答待ち」「承認待ち」「確定反映待ち」「完了」「保留・却下」とし、各状態の入出条件を明文化します。たとえば「仕入先回答待ち」から「承認待ち」へ進むには、変更後の納期、数量、回答日時、回答者が必要です。「完了」へ進むにはERP発注書または製造指示の確定値を照合し、次回MRPで不足が解消したか、あるいは別の例外に変わったかを確認します。
業務担当者が現場で判断するのは、提案の採用・不採用だけではありません。供給元へ連絡する前に在庫の引当を確認する、輸送手段を切り替える、承認済み代替品を使う、顧客納期を再交渉するなど複数の手段があります。処置理由コードと自由記述を両方持ち、理由コードで集計しながら文脈も残します。「担当者が気付いたら電話した」という運用を、記録のある例外処理に変えることが目的です。
承認権限は金額だけで決めない
数量増加は購買金額を動かしますが、日付前倒しは特急輸送費を生み、後ろ倒しは契約違反や仕入先との信頼低下につながります。承認マトリクスは変更の種類、金額、顧客影響、代替材の使用、輸送変更、計画凍結期間への侵入を組み合わせます。社内で承認されても、仕入先が受諾するまではERP上の約束納期を更新してはいけないケースがあります。「社内承認」と「外部合意」を分けて記録する設計が必要です。
凍結期間の扱いを明確にする
製造計画の凍結期間内では、通常の再計画と同じ権限で変更できない場合があります。Microsoftのaction messageの生成条件も凍結期間の内外や計画オーダーの承認状態に依存します。製品固有の挙動を把握したうえで、工場のルールとして「提案表示は許すが変更は上長承認」「緊急案件だけ計画責任者が解除」などを定義します。生産計画の凍結期間の関連記事は計画変更側の設計を詳しく扱っています。本記事の役割は、その境界をMRPの例外案件へ接続することです。
ERP・APS・購買システムをどう接続するか
統合には二つの方向があります。ひとつは計算結果を読み出し、判断待ち案件を作る流れ。もうひとつは承認済み処置を確定伝票へ反映し、反映結果を取り込む流れです。片方向だけでは「承認したのに実際には未変更」「変更済みなのに案件は未処理」が起きます。RFPではAPI、ファイル、標準コネクタの名称よりも、どのIDで同一案件を追跡し、再送と重複をどう扱うかを評価します。
例外案件の一意キー
一意キーを品目コードと警告コードだけで作ると、別の需要・別の計画実行が同じ案件に合体します。計画実行ID、拠点、品目、需要ID、供給ID、例外種別、提案日付・数量などを組み合わせ、製品が提供するメッセージIDが安定しているかも確認します。計算のたびにIDが変わる場合は、旧案件との関連付けルールを別途設計します。同じ提案を重複登録しないことと、異なる計画版を潰さないことの両立が必要です。
更新の競合と冪等性
担当者が画面を開いている間に発注書が別部門で更新される可能性があります。反映前にERPの更新日時や版を照合し、違えば再確認へ戻します。送信がタイムアウトしてもERP側で更新済みかもしれないため、盲目的に再送するのは危険です。リクエストID、元版、変更後の期待値を保存し、再試行時はERPの実状態を読んでから処置します。ERPへの書込みを自動化しない初期段階でも、「人がERPで変更し、案件側で伝票IDと新旧値を照合する」手順を標準化できます。
エラー時の戻し方
在庫引当、発注変更、製造指示の変更を一括トランザクションにできない場合があります。一部だけ成功したら、どこまで成功し、次に何を人が直すかを表示します。元伝票の値を無条件に上書きするロールバックは、他の担当者の変更を消す恐れがあります。「自動復元できる範囲」と「再承認が必要な範囲」をRFPで分け、監査証跡を残します。失敗を隠して案件を完了にしないことが最も大切です。
例外キューの優先順位をどう設計するか
表示順を警告コード順にするだけでは業務に役立ちません。優先順位は、顧客・製造指示への影響、着手期限、代替手段、変更の実行可能性を組み合わせます。たとえば「明日停止し、今日仕入先へ回答期限がある不足」は最上位です。「来月安全在庫を下回るが、既に確定した入荷がある」案件は別レーンにします。分類は完全自動にせず、担当者が緊急度を上書きでき、その理由が残るようにします。
案件数が多い場合は、同じ原因で生じた複数の提案を束ねると判断しやすくなります。同一仕入先の輸送遅延が十数品目に波及したケースでは、親の原因案件と子の影響案件を関連付けます。ただし承認・伝票反映は品目と発注単位で追跡し、親案件の完了だけで子案件を閉じない設計にします。似た通知を畳むことと、処置漏れを隠すことは違います。
SLAを見た目の経過時間で測らない
「新規から24時間以内に完了」と決めても、仕入先の回答待ち、上長の承認待ち、ERP連携障害で意味が変わります。初動時間、判断時間、外部回答待ち、ERP反映時間、再計画確認時間を別の時計として持つと、改善箇所が見えます。たとえば初動は速いのに確定反映が遅ければ、通知を増やしても改善しません。業務時間カレンダーと休日の扱いをSLA定義に入れます。
KPIは「警告を消した数」だけにしない
画面の未処理件数を減らすために一律却下する運用が生まれないよう、結果指標を併記します。期限までに処置した案件割合、同一原因の再発件数、計画版変更で失効した案件割合、確定伝票との不一致件数、実際に起きた材料欠品、緊急輸送の件数などです。各指標は母数を明記し、製品や拠点を比較するときは需要量・材料構成の違いを考慮します。数値目標は導入前の自社ベースラインを測ってから決め、他社の効果率を根拠なく転用しないでください。
タイ工場で特に決めたい責任分界
日系本社が計画を作り、タイ工場が発注や生産を実行する構成では、「本社の計画変更提案」と「現地の確定権限」がずれることがあります。案件に計画責任者、購買担当、製造責任者、品質承認者、顧客連絡担当を設定し、誰が単独で日付を変更できるかを明確にします。英語・タイ語・日本語の画面があっても、業務用語の解釈が一致しなければ承認は曖昧です。「約束納期」「希望納期」「計画入荷日」「材料必要日」「回答期限」の対訳を用語集に固定します。
輸入材は国際輸送と通関の時間もあります。MRP上の「入荷予定日」が港着日なのか、工場倉庫で使用可能になる日なのかを区別します。仕入先の回答日付だけ変えても、輸送・受入検査・棚入れを通らなければラインへ投入できません。単純な日付の前倒しより、「いつ、どの工程から実際に使用可能か」を納期回答で合わせます。具体の通関規則や税務判断は貨物・契約ごとに異なるので、業務システム側では必要なステータスと責任者を保持するにとどめます。
多言語運用で翻訳すべきもの
UIのボタンだけを翻訳しても現場は困ります。警告の理由、提案の意味、処置理由、承認コメントのテンプレート、仕入先への依頼文、顧客へ伝える前提を用語集とともに統一します。原文を保存し、翻訳した文面だけで重要な条件を確定しない運用も必要です。たとえば英語のadvanceを「前倒し」と訳しても、発注日を前倒しするのか納入日を前倒しするのかを画面で明示します。言語ごとの説明文と、変わらない伝票ID・日付・数量を並べて表示すると誤認を減らせます。
導入を三段階に分ける
第一段階は、計算結果を読取り専用で取り込み、旧来のExcelやメールと照合することです。メッセージの種類、発生頻度、誤警告、案件の担当者、確定伝票との関係を観察します。必要な項目が欠けていれば、画面づくりより先にERP抽出とマスタを直します。夜間計算、再計算、手動計算が混在する場合は、どの実行を業務上の正本にするかも決めます。
第二段階は、判断・承認・仕入先回答を案件として管理することです。この段階でERP書込みを急ぐ必要はありません。人が確定伝票を変更した後、案件に伝票ID・変更内容を紐付け、再計画後の状態を確認します。ボトルネックがデータ不足なのか、判断待ちなのか、外部回答待ちなのかを明らかにします。
第三段階で、反映が定型化できる操作だけをERPへ連携します。前倒し・数量増などの危険度は一律ではないため、変更の種類、金額、契約条件に応じて自動反映の対象を限定します。例外的な数量や凍結期間内の変更は人の承認を残します。導入範囲を拡大する前に、重複送信、タイムアウト、ERP側の並行更新、差戻しの挙動を試験してください。
RFPに入れる要件とベンダー比較
提案依頼書には機能名の丸印より、実データと判断場面を書きます。「前倒し提案の一覧」だけでなく「発注書の旧納期、希望日、仕入先回答日、工場で使用可能な日、承認者、ERP反映値を並べて表示する」と指定します。候補ベンダーには同じサンプルデータを渡し、同じ例外案件をどこまで処理できるかをデモしてもらいます。権限、接続方式、変更履歴、再送制御、言語対応、サポート体制は本番運用の要件です。
| 評価項目 | RFPで確認すること | デモで見る証拠 |
|---|---|---|
| 取込み | 計画実行IDと元伝票IDを保持できるか | 再計算後の同一・別案件の表示 |
| 判断 | 需要影響と計算根拠を示せるか | 品目から顧客注文までの追跡 |
| 承認 | 権限・代行・差戻しを分けられるか | 金額と凍結期間で経路を変える操作 |
| 反映 | ERP更新の成否を照合できるか | タイムアウト後の再読取と重複防止 |
| 多言語 | 用語と日付の意味を保てるか | JA・EN・TH画面で同一案件を比較 |
| 運用 | 監視、再送、履歴出力ができるか | 障害発生から復旧までの記録 |
価格比較ではライセンス料だけでなく、ERP連携、品目マスタ整備、権限設計、教育、保守、追加拠点展開の費用を同じ条件で見積もります。「標準でできます」という回答は、どの製品版・設定・画面でできるかをデモで確認します。計算エンジンを変更する提案と、例外ワークフローだけを追加する提案は対象範囲が異なるため、同一表で単純な金額比較はできません。RFPの前に自社の必須要件と後続の改善要件を分けるべきです。
FAT/SATで落としてはいけない試験
FAT（出荷前受入試験）では、匿名化した発注・製造・需要データを使い、各例外の生成と案件化を確認します。SAT（現地受入試験）では、タイ工場の実際のカレンダー、権限、夜間計算、ネットワーク、運用手順で確認します。テストは「画面が表示された」だけで合格にせず、正しい伝票への反映、誤った反映の防止、復旧可能性まで見るべきです。次は試験シナリオの例であり、合格値や件数は自社データに合わせて決めます。
- 同じ材料に二つの需要があり、片方だけ必要日が変わる。例外が別の需要へ誤って結び付かないこと。
- 仕入先回答待ち中に受注数量が変わる。旧提案が無効化され、新計画版と旧案件の関係が追えること。
- 確定発注を別担当者が更新した後に承認する。旧版との競合を検知し、上書きを防ぐこと。
- ERP更新成功後にネットワーク応答が失われる。再送で二重変更を起こさず、実状態から復旧すること。
- 凍結期間内の製造指示前倒し。権限がない担当者は確定できず、承認履歴が残ること。
- 仕入先休業日とタイ工場稼働日が異なる。希望日・回答日・使用可能日が正しく表示されること。
- 多言語利用者が同じ案件を開く。日付・数量・伝票IDが一致し、操作の意味がずれないこと。
- 案件を却下した後も、次回計算で同じ不足が残る。再発として見え、処置理由を追えること。
試験結果には入力データ、期待結果、実際の画面とERP伝票、差異、修正・再試験の履歴を残します。ERP側の設定変更を伴う場合は設定版も記録します。PoCでは工場全体の例外を取り込むより、1ラインまたは1購買チームに対象を限定し、実際に処理した案件のサンプルから効果と運用負荷を測る方が判断しやすくなります。
よくある失敗と、その避け方
警告を消すことが目標になる。 処理済み件数だけを評価すると、却下が増え、現場の欠品が残ります。案件の完了条件にERPの確定値と次回計算の確認を入れます。
異なる提案を一つの案件にまとめる。 品目とコードだけで重複排除すると、別需要・別拠点・別計画版を潰します。計画実行IDと伝票参照を用いた一意キーを検証します。
マスタ不良をワークフローで隠す。 未更新のリードタイムや誤BOMは担当者へ毎夜同じ警告を出します。処置理由「マスタ修正」を別案件として追い、修正完了と再計算を結び付けます。
承認と外部合意を混同する。 購買部長が承認しても仕入先が受諾しなければ、納期前倒しは確定しません。仕入先回答とERP確定値の両方を完了条件に入れます。
再送を安全と思い込む。 接続断の後に同じ更新を再送すると、二重変更や別担当者の更新を上書きする恐れがあります。反映前後に版と実値を照合し、失敗時は人の調査へ回せるようにします。
FAQ：MRP例外メッセージ管理の導入判断
MRP例外メッセージ管理システムはERP標準機能だけで足りますか？
単一工場で担当者と伝票が明確、標準画面で根拠と処置結果を追えるなら、標準機能で始める方が合理的です。複数システムと複数拠点をまたいで処置履歴が散らばる、承認や仕入先回答を追えない、変更の反映を照合できない場合に追加の運用層を検討します。まず現行標準機能のデモと実データ検証を行ってください。
MRPの全例外を最初から自動処理すべきですか？
いいえ。提案の種類ごとに契約、金額、能力、品質、顧客への影響が違います。初期段階は読取りと判断履歴を優先し、条件が明確な操作だけを後から自動反映します。数量減少や発注取消は仕入先との合意条件があるため、特に慎重に範囲を決めます。
例外メッセージが多いときは何から減らしますか？
発生件数の多い品目を単純に隠すのではなく、同じ原因で繰り返す案件を抽出します。リードタイム、BOM、在庫実績、計画版、カレンダーを確認し、マスタ修正と実際の供給調整を分けます。警告の非表示は最後の手段で、無視してよい条件と再評価日を記録します。
導入費用はどう比較すればよいですか？
対象拠点・ERP版・計画実行回数・伝票件数・言語・連携方式を揃えて見積依頼します。ライセンス、連携開発、マスタ整備、監視、教育、保守を分けて比較してください。自社条件のない「相場」の数値は意思決定に使いにくいため、本記事では一律の金額を示しません。
まとめ
MRP例外メッセージ管理の要点は、警告を見せる画面ではなく、計画から判断、承認、外部合意、確定伝票、再計画までの一本の証拠線を作ることです。最初に前倒し・後ろ倒し・数量増減の意味、計画版、伝票ID、責任者、完了条件を決め、実データで検証してください。マスタ品質と凍結期間のルールも同時に点検すると、処理件数だけを増やす導入を避けられます。
タイ工場でMRPの例外処理がメールやExcelに分かれている場合は、現在のERP標準機能と一つの代表的な案件をもとに、必要な連携・承認・受入条件を整理する段階からご相談いただけます。TOMAS TECHへお問い合わせください。
