生産計画の凍結期間を設定する方法｜変更承認と受入試験

生産計画の凍結期間を設定したのに、朝の再計算で今日の指示が入れ替わる。逆に、凍結を厳しくしすぎて設備停止や得意先の緊急注文に対応できない。タイ工場でAPSや生産スケジューラーを導入するとき、この両極端を避けるには「何日前から変更不可か」という日数だけでは足りません。工場・ライン・品目・材料の違い、例外の承認、納期回答、ERPとMESへの伝達、そして受入試験まで一つの運用として設計する必要があります。本稿は製品比較そのものではなく、調達仕様書に書ける凍結ルールと検証方法を扱います。

生産計画の凍結期間とは何を固定する設定か

凍結期間は、計画の再計算や人の編集によって直近の製造予定が不用意に動くことを抑える時間帯です。ただし「固定」の対象は一つではありません。製造オーダーの開始時刻、終了時刻、投入順序、ライン、数量、使用材料、確約済み納期のどれを守るかで結果が変わります。まず対象を明記します。例えば「向こう48時間に着手するオーダーのラインと開始時刻を自動変更しない。数量変更と順序変更は例外承認を要する」のように書きます。単に「2日凍結」と書くと、候補ベンダーごとに異なる意味で実装されます。

Microsoft Dynamics 365の公式説明では、マスタープランのfreeze time fence内では既存の計画オーダーが新しいマスタースケジュール実行で変更されず、新規計画オーダーも提案されません。一方、Oracle Fusion Cloudのplanning time fenceの説明には、期間内の再日程と新規計画オーダーを抑える一方、過剰供給と判定したオーダーの後倒しや取消しがあり得ると記されています。SAPの計画時間境界による計画オーダーの確定は、品目のMRPタイプなどの設定に依存します。つまり「凍結」の名称だけで機能を同一視せず、実際に何が変わるかをサンプルデータで確かめるべきです。

計画の凍結と、計画オーダーを実際の製造・購買オーダーへ変換する確定処理も分けます。後者は発注や現場作業に実務上の拘束を生みます。Microsoftの文書でもfirming time fenceは計画オーダーを本オーダーへ自動変換する期間として、freeze time fenceとは別に説明されています。凍結している画面でも購買未手配なら材料は届きません。逆に発注済みでも工程順が自動で動く設定はあり得ます。

「何日」が正解かではなく、変更コストから境界を決める

凍結長を全工場共通の数字として先に決めると、輸入材と現地調達材、連続工程と組立工程を同じルールで縛ってしまいます。境界を決める前に、変更によって発生する実損と調整負荷を工程別に洗い出します。原材料のピッキング開始、金型の予熱、洗浄、作業員の配置、外注先への指示、検査枠の予約、出荷便の予約などです。各作業に「いつから変更すると手戻りになるか」を付け、凍結の候補境界を作ります。日数はその結果です。

例えば同じ工場でも、輸入樹脂を使う成形ラインは材料の到着確認と乾燥準備の前に順序を固め、一般組立ラインは当日朝の人員確認後まで再配置可能にする、といった差が自然です。ボトルネック設備の清掃や段取り替えが高価なら順序の凍結を早め、代替設備が豊富ならラインだけを固定せず出荷日を守る余地を残せます。ここで示す時間は設計の例であり、すべての工場に適用できる標準値ではありません。

凍結単位には少なくとも三層あります。工場レベルでは受注確約と拠点間の負荷移管、ラインレベルでは段取りと人員、材料レベルでは発注・引当・品質判定を扱います。三層が違う境界を持つ場合、もっとも厳しい境界を一律に採用するのではなく「どの変更がどの承認を起動するか」を決めます。材料が凍結済みでも未着なら、ライン計画の見た目を守るより、代替材の承認・納期再回答を先に行うべき場合があります。

凍結期間内に変更が起きたら、例外承認を設計する

「凍結中は絶対に動かせない」運用は現場で迂回されます。設備故障、停電、欠品、不良、顧客の安全上の緊急要求は実際に起きます。必要なのは無制限の手修正ではなく、申請、影響計算、承認、反映、通知、監査記録の短い経路です。申請者は理由コードと証拠を添え、システムは変更前後の予定、遅延する注文、段取り時間、使用材料を表示します。承認者は自分の権限範囲の変更だけを通します。承認後に初めて現場指示を改版します。

例外は緊急度だけでなく、変更の影響で階層化します。表示用の仮シミュレーションは生産管理者が即時に実行できても、確定済み指示を変更する操作は承認を要します。顧客納期を変えず同一ライン内で順序を入れ替える場合と、他顧客の確約日を後ろへ動かす場合では権限を分けます。後者は営業側の納期再回答を含むため、工場長だけの判断にしない設計が妥当です。緊急時の代理承認者と、承認者不在のときの期限も決めます。

システムに求める証跡は「誰が」「いつ」「旧値」「新値」「理由」「承認者」「承認日時」「下流へ送信された版」です。Excelを上書きして旧計画が消える運用では、予定の安定性も例外の適切さも測れません。拒否された申請、取り下げた申請、承認後に配送できなかった指示も記録の対象です。個人の責任追及のためだけでなく、繰り返す例外をマスタデータや凍結長の見直しにつなげるためです。

現場が最初に見る画面には「現在有効な指示の版」と「次に有効になる版」を明確に出します。口頭やチャットの連絡がシステムより先に届くことはありますが、その場合もどの承認済み指示が正式かを確定できる必要があります。夜勤を含むタイ工場では、日付だけでなくタイムゾーンとシフト境界を決めておきます。例えば翌日0時の境界を暦日で処理するのか、07:00のシフト切替で処理するのかによって、同じ「1日凍結」でも守られるオーダーは異なります。

ATP・CTPと凍結期間をつないで納期回答を守る

生産計画の安定だけを最大化すると、得意先への納期回答が遅くなります。反対に、営業が入った注文すべてに最短日を答えると、凍結済みのライン計画を毎日壊すことになります。受注時の納期回答ルールを凍結ポリシーと同時に設計します。

ATP（Available-to-Promise）は、既存在庫や確定・予定供給のうち引当可能な量を基に納期を判断する考え方です。CTP（Capable-to-Promise）は、在庫が足りないときに材料、設備、外注や調達の能力を踏まえて新たに供給できる日を探します。OracleのGlobal Order Promising文書は、既存供給を使うATPと、まだない供給を作る能力をみるCTPを区別しています。ただし、どの供給をATPに含めるか、能力制約をどう扱うかは製品設定次第です。RFPでは用語だけでなく、注文ケースごとの回答とその根拠を出してもらいます。

凍結済みの製造枠を新規注文が奪わないという条件を納期回答側へ渡します。未凍結の能力、代替ライン、引当可能な在庫、納入可能な材料で回答し、どうしても凍結内の変更が必要なら例外承認を経てから得意先へ確約します。仮回答と確約を異なる状態で持ち、承認前の仮日を「確定日」としてERPから送らないことが重要です。複数拠点の在庫を使う場合は輸送日数、通関、検査待ちを含む「使える日」で判定します。発注書の日付をそのまま投入可能日と見なすと、凍結した計画だけが正しく見える失敗につながります。

ATP/CTPの導入要否は、製造形態でも変わります。見込生産で完成品在庫が厚い場合はATPの精度が先決かもしれません。受注生産で材料とボトルネック能力が納期を決めるならCTPの検証が重要です。どちらでも、手動で約束日を上書きした履歴と、変更後の下流影響を追えるようにします。

スケジュール安定性と納期遵守を一緒に測る

凍結期間を評価するとき「変更件数が減った」だけを成功としないでください。変更を禁止した結果、納期遅延や残業、仕掛滞留が増えれば運用は悪化しています。反対に、納期遵守率だけを追うと、現場が毎日計画を組み直して達成している負担を見逃します。指標は両方を並べて見ます。

計画安定率の例は「凍結時点で確定したオーダーのうち、ライン・開始時刻・順序が許容幅を超えて変わらず実行された件数÷対象件数」です。何を変化と数えるかを固定します。開始時刻が5分動いたケースと翌シフトに移ったケースを同じ1件として数えると、改善の手掛かりが消えます。変更幅の分布と、変更理由別の件数も保存します。納期遵守率は、約束日時を基準に、品質検査と出荷準備まで含めて何を「完了」とするか定義します。製造完了だけで計算した数字を顧客納期と混同してはいけません。

導入前後を比べるなら、同じ製品群・同じ期間の注文構成、休日、繁忙期を確認します。試行導入では「今週の値が何％改善した」と言い切るより、同じ事象を旧運用と新運用で再生し、変更履歴と影響注文が取れるかを先に確認します。後述の数値例は受入試験の判定方法を示す仮の条件で、TOMAS TECHの実績値でも業界平均でもありません。

ERP・APS・MES間で何を渡すか

凍結ルールはAPS画面の中だけでは完結しません。ERPは受注、購買、在庫、製造オーダー、確約日を持ち、APSは制約を使った計画案と版を作り、MESは現場の着手、完成、不良、材料使用、停止を返します。製品によって責任範囲は重なりますが、データごとに正本を一つ決めます。ERPが持つ確約日とAPS上の仮納期を混ぜず、MESの実績時刻と予定時刻も別に保持します。

MicrosoftのMES連携文書は、製造オーダーのリリース、開始、良品・不良数量、材料消費、作業時間、完了などのイベントを例示しています。これは特定製品の実装説明ですが、RFPのインターフェース棚卸しに使える観点です。凍結期間の運用では、特に「指示の改版」と「現場が受信した版」の一致が必要です。APSで順序を変えたのにMESには旧順序が残るなら、どの計画が正式か判別できません。

インターフェース表には、発信元、受信先、データ項目、送信契機、更新頻度、タイムゾーン、重複時の処理、失敗時の再送、承認状態、監査ログを記載します。夜勤明けに実績が遅れてERPへ送られたとき、すでに再計算した計画を自動で再変更するのか、差分を保留して人が判断するのかも決めます。通信停止時は「最後に受信できた承認済み指示」を現場へ見せ、復旧後に同じメッセージを二重処理しない設計が要ります。

複数の品目コード、工程コード、設備コードがERPとMESで異なる場合は、導入初期に対応表を作ります。BOM改訂の有効日、代替材、品質保留、ロット指定の意味も合わせます。凍結期間を設定する前にこの基礎が崩れていると、システムは古い材料の到着を前提に計画を守り、現場は別の材料待ちで止まります。

RFPに書くべき凍結期間の要求事項

RFPには画面の有無ではなく、入力・操作・期待結果を記載します。「凍結期間設定可」の一行では、全品目共通の日数だけを設定できる製品と、工場・ライン・品目群ごとに異なる境界と権限を扱える製品を区別できません。最低限、以下を同じ表で各社に回答してもらいます。

1. 凍結の単位と優先順位。工場、ライン、工程、製品群、品目、材料、顧客注文のどこまで設定でき、ルールが重なったときどれが勝つか。
2. 時間境界。暦日、稼働日、時間、シフトのどれで計算し、休日とタイムゾーンをどう扱うか。
3. 自動再計算。凍結内の既存オーダー、新規需要、欠品、設備停止、過剰供給をそれぞれどう処理するか。
4. 手動変更。変更できる権限、必要な理由、申請・承認・代理承認、却下時の動作。
5. 約束日。ATP/CTPがどの供給と能力を見て、仮回答と確約をどう分けるか。
6. 版管理。旧計画との差分、影響注文、承認済み版、MES受信版、ロールバックの可否。
7. 連携。ERP・MESの項目、更新契機、エラー時の再送、部分成功、監査ログ。
8. 運用。設定を変更できる管理者、変更後のテスト、稼働後の保守、現地サポート言語。

回答欄は「標準機能」「設定」「追加開発」「対象外」に分け、該当する画面やAPIの実演を要求します。製品説明にある言葉をそのまま採点しないことが重要です。特定ベンダーを推す前に、現場の実データを匿名化した3〜5件の変更シナリオを配り、各社に同じ条件で実演してもらいます。生産スケジューラー全体の比較項目は生産スケジューラー比較2026に整理しています。本稿の焦点はその中でも変更権限と凍結境界の具体化です。

採点表では、機能の有無と運用時の手間を別の列にします。例えば「例外承認できる」は満たしていても、申請者が変更対象の注文を毎回手で探し、影響する他注文を別の画面で照合するなら、緊急時には使われないかもしれません。同じ試験ケースで、申請から影響確認までの操作数、入力が必要な項目、承認者への通知方法、現場への反映確認を記録します。数値だけで順位を決めず、作業者が迷った箇所をメモします。タイ語の状態名が「仮」「承認待ち」「確定」を区別できるか、英語の管理画面と意味が一致するかも見ます。ベンダーのデモ環境では全員が管理者権限で操作していることがあるため、実際の計画担当、現場責任者、営業担当の権限で同じ操作を試します。これにより、導入後に初めて「現場では承認ボタンが見えない」「営業だけが確約日を直せる」と判明する事態を減らせます。

追加開発が必要な項目は、初期費用だけでなく保守責任とアップグレード時の再試験範囲まで見積もります。凍結ルールは新しい製品や設備が増えるたびに変わるため、一度きりの設定作業ではありません。設定変更を社内で行えるのか、毎回ベンダー作業が必要かを確認し、変更の承認と本番反映の記録を契約上の成果物に含めます。

FATとSATで生産計画の凍結をどう受け入れるか

FATは設定・連携の実装を本番投入前に確認する試験、SATは実際の拠点・端末・シフト・権限で運用できることを確認する試験として設計します。名称や契約上の区分は案件で異なるため、契約書の定義に合わせます。両方で「通常計算が成功した」だけを合格にせず、変更が起きる場面を再現します。

検証データは、二つの工場、三つのライン、ボトルネック設備、材料の入荷遅延、顧客の緊急注文、品質停止、夜勤を含めて小さく作ります。例えば、工場Aのライン1は48時間、ライン2は24時間、輸入材Mは72時間を凍結するという仮条件を置きます。これは試験用の例で、推奨設定値ではありません。月曜09:00に計画を確定し、火曜のライン1オーダーに急ぎ注文が入る。再計算が既存指示を無断で動かさず、影響を受ける注文と代替案を表示することを確認します。材料Mが水曜の入荷予定から木曜へ遅れた場合は、確定済み計画が実行不能と分かる警告を出し、代替材の品質承認または顧客への納期再回答に進めるかを見るべきです。

試験表には初期状態、操作、期待結果、実結果、証跡、合否、再試験日を残します。次の例はそのままRFP付属の受入条件へ転用できます。

SATでは実際の監督者と計画担当者に操作してもらいます。タイ語の状態名、承認通知、エラーメッセージが現場の解釈と一致するかも検証します。実際の停止理由を選べないなら、運用開始後にすべて「その他」へ集まり改善材料を失います。停止から代替案作成、承認、現場受信までの時刻を記録し、ボトルネックが計算なのか判断なのか連絡なのかを分けます。

数値で評価する場合の仮の受入条件

数値目標は各工場の現状値から決めます。以下は試験仕様の書き方を示す架空の例です。効果実績や業界平均ではありません。

• 対象100製造オーダーのうち、凍結内で承認なくライン・開始・順序が変わった件数を0件とする。
• 緊急注文10件を試し、代替納期と影響注文を全件で出力し、根拠データを追跡できるようにする。
• 承認した変更10件で、ERP・APS・MESの有効版がすべて一致することを確認する。
• 通信断と再送を各5回行い、同じ指示の二重作成と未反映が0件であることを確認する。
• 判定の速度は、実データ量とインフラを固定して測定し、契約で合意した上限値を使う。

「納期遵守率95％」のような結果指標だけを短いFATで保証させるのは適切ではありません。顧客注文の偏りや設備故障に左右されるためです。FATでは機能と証跡、SATでは実オペレーション、稼働後は長めの期間で納期と計画安定性を一緒に評価します。現状値がない場合は、まず数週間の版履歴と出荷実績を採り、比較できる土台を作ります。

導入時によく起きる失敗と回避策

第一は「凍結設定を長くすれば現場が安定する」という思い込みです。マスタの能力や材料到着日が正確でなければ、安定して見えるのは画面上だけです。凍結を延ばす前に、実行不能な指示の発生件数を測ります。材料未着や設備停止が頻繁なラインは、凍結期間より先に入力と実績の鮮度を改善すべき場合があります。

第二は、現場が変更できないから、管理者が裏で直接データを書き換えることです。正式な例外ルートが遅く、理由コードが現実に合わないと起こります。権限を緩めるだけでなく、頻出する変更理由を最小操作で申請できるようにし、影響が小さい変更の承認を適切な役割へ委譲します。例外率が高い状態を放置せず、月次でルールとマスタを見直します。

第三は、ATP/CTPとAPSが別々の能力を見ていることです。営業側の納期画面では設備が空いて見えても、現場では段取りや保全で埋まっていることがあります。どの設備、カレンダー、材料を納期回答に使うかを揃え、差がある場合はどちらを正として扱うか決めます。例外承認の前に顧客へ回答する手順も修正します。

第四は、ERPとMESの状態名が一致しないことです。「製造完了」がMESでは最終工程の終了、ERPでは品質検査を経た在庫計上を意味するなら、同じ語でも納期回答可能な数量は違います。状態遷移と時刻の意味をインターフェース仕様に記載し、部分完了と不良を含むケースで試します。有限能力計画そのものの導入順序は有限能力計画の導入ガイドを参照してください。能力制約の正確さと凍結運用は相互に依存しますが、同じ設定ではありません。

第五は、凍結ルールの変更管理が導入プロジェクト終了とともに消えることです。新製品、追加設備、サプライヤー変更、シフト変更で境界を見直す必要があります。変更提案者、承認者、試験担当者、反映日時を決め、設定変更前に過去の代表事例を再生します。製品のアップグレード時にもFATの中核ケースを回せるよう、試験データと期待結果を保存します。

導入前に決めるべき実務チェックリスト

調達会議で最後に確認する項目をまとめます。工場別に凍結対象と境界を説明できるか。ライン別に段取り・人員・保全を含む変更コストを把握したか。材料別に発注日ではなく投入可能日を扱うか。緊急変更の申請と承認者は決まっているか。ATP/CTPが凍結済み能力を勝手に新規注文へ割り当てないか。ERP・APS・MESで版と状態を一致させられるか。夜勤・休日・タイムゾーンの境界を試したか。計画安定率と確約納期遵守率を同時に測れるか。FAT/SATの証跡と不合格時の再試験条件を契約に書いたか。この問いに答えられない部分こそ、製品デモより先に現場で決めるべき仕様です。

特に、いま使っている帳票や口頭連絡をそのまま電子化するだけでは、凍結と例外の境界が曖昧なまま残ります。発注前の会議では、過去に実際に起きた計画変更を一件取り上げ、受注から現場指示の差し替えまでを時系列で追ってください。どの時点で材料の遅れが分かったか、誰が代替案を作ったか、顧客へ再回答したか、現場がどの版を受け取ったかを確認します。その場で説明できない箇所が、導入時に最初に整えるべき業務要件です。

変更ルールを稼働後に育てる方法

稼働開始後の最初の数週間は、凍結内の例外を「想定外だった」で片付けず、理由と発生時刻を週次で見ます。設備故障のような偶発的事象と、材料の入荷日が毎回ずれるような構造的事象を分けるためです。後者を例外承認で毎日処理し続けると、承認者がボトルネックになり、現場は結果的に古い指示で動きます。仕入先の回答日、品質検査の所要時間、入荷から投入可能になるまでの時刻を見直した方が、凍結期間を延ばすより効果的な場合があります。

例外の発生箇所を工程別の時間軸に置き、凍結境界の前後で何が変わるかを確認します。境界の直前に変更が集中するなら、営業の受注締切や購買の確約時刻とずれている可能性があります。境界の直後に実行不能が多いなら、前提となる在庫・設備・人員の情報が古い可能性があります。判断した理由を残せば、凍結を短くするか長くするかという二択から、データ取得時刻や承認経路の見直しへ進めます。

改善会議には生産管理だけでなく、購買、品質、営業、現場、ITを入れます。各部門にとって守りたい時刻が違うからです。月次で変更理由の上位を選び、マスタ修正、連携修正、例外ルールの簡素化のどれで対応するか決めます。設定変更は本番へ直接反映せず、FATで作った代表ケースを再実行します。許容できる変更と禁止したい変更が両方保たれていることを確認してから、変更日と対象ラインを知らせます。こうした運用があって初めて、凍結期間は一度入力した数値ではなく、工場の実態に合うルールになります。

凍結の優先順位を決める三つの衝突例

異なる凍結ルールを重ねたときの結果は、導入前に決めておきます。第一の例は、ラインの順序が凍結済みで、材料の代替だけが認められる場合です。代替材が品質部門で承認され、同じ工程条件で使えるなら、現場指示の材料ロットだけを改版してライン順序を守れるかもしれません。しかし代替材が追加の乾燥や洗浄を要するなら、材料変更は実質的に工程変更です。画面上で「材料だけ変更」と記録しても、段取り時間を再計算しなければ、後続のオーダーが遅れます。材料コードだけでなく工程条件まで影響をたどれることを試験に入れます。

第二の例は、工場間で仕事を移す場合です。工場Ａで材料が不足し、工場Ｂの設備には空きがあります。ただし、工場Ｂへ移すと輸送日数と品質検査場所が変わります。Ａ工場のライン凍結を解除してＢへ割り当てる操作を、単なるライン変更として承認させてはいけません。顧客の確約日、仕掛品の所在、材料引当、輸出入に関係する手続きの確認が必要です。移管前の計画版と移管後の計画版を別々に保存し、注文番号で追跡できるようにします。

第三の例は、顧客の緊急注文が既存顧客の確約と競合する場合です。新規注文だけを画面に表示して「最短で対応可能」とする納期回答は、既存注文の遅延を隠すことがあります。影響を受ける既存注文を一覧に出し、約束日が変わるなら営業責任者の承認を必須にします。顧客への連絡が未完了なのに製造順だけ先に変更される状態を防ぐため、承認を「計画変更の許可」と「顧客回答の完了」に分ける方法もあります。どちらを採用するかは、受注から製造指示までの責任分界に合わせて決めます。

この三例に共通するのは、変更の見た目より影響範囲が大きいことです。RFPでは「ライン変更」「材料変更」という機能名だけで済ませず、変更前後の材料、工程、在庫、納期、他注文への影響を一画面または出力表で見られるかを確認します。特に多拠点運営では、各工場のローカル時刻で表示するだけでなく、システム間に保存する時刻の基準と変換の責任も決めます。夜勤中の承認が翌日の履歴として表示されると、後から判断の順序を再現できません。

移行時は過去の計画を凍結ルールの検証に使う

新しい仕組みを導入するとき、理想化したサンプル注文だけでは例外の抜けを見つけられません。過去に起きた計画変更から、頻度の高い事象と損失の大きかった事象をそれぞれ選びます。少なくとも、納期前倒し、材料遅延、設備故障、品質保留、作業員の欠員、仕掛品の再作業を含めます。個人情報や顧客名を匿名化しても、当時の注文順、材料在庫、設備カレンダー、実際に承認した人、出荷結果は再現できる形で残します。

過去事例を使う目的は、新システムが当時の正解を自動的に当てるかを競うことではありません。変更を知った時点で何が分かり、何がまだ不明だったかを再現し、判断者が必要な情報に到達できるかを検証します。後から確定した材料到着時刻を最初から入力してしまうと、受入試験は不自然に簡単になります。試験データには「受注時点」「計画確定時点」「異常発生時点」の各版を分けて保存します。これによって、システムの再計算結果だけでなく、情報が遅れて届いた場合の例外承認と納期再回答まで確認できます。

移行初期には、旧運用と新運用を一定期間並行して記録し、判断が食い違った注文をレビューします。差が出た理由を、設定、マスタデータ、連携遅延、権限、現場の暗黙ルールに分けます。たとえば新システムだけが同じラインへ二つの作業を重ねていれば能力マスタの問題です。旧運用だけが口頭で順序を変えていたなら承認ルートの問題です。差の種類が分かれば、凍結期間を無闇に動かさずに修正できます。

よくある質問

生産計画の凍結期間は何日が適切ですか？

一律の正解はありません。材料の調達と品質判定、段取り準備、人員と外注の確定、出荷予約の各時点から逆算します。工場、ライン、品目群で境界を分け、試験で変更頻度と実行不能件数を比較して調整します。RFPでは日数だけでなく凍結対象を記載します。

APSの凍結期間とERPの確定オーダーは同じですか？

同じとは限りません。APSの凍結は再計算時に計画の一部を保持する操作で、ERPのオーダー確定は製造・購買の実行手配に関係します。製品ごとの用語と動作を、オーダー作成、再計算、変更、取消しの試験で確認してください。

凍結中に生産スケジューラーの計画変更が必要ならどうしますか？

まず仮の代替案を作り、影響注文・材料・設備・納期を確認します。理由と旧・新版を添えて権限者が承認した後、有効な現場指示を改版し、ERPとMESへ伝達します。承認前の仮案を正式な納期回答に使わないようにします。

受入試験で最優先にすべきケースは何ですか？

確定済み指示がある状態での需要追加、設備停止、材料遅延、承認権限外の変更、通信断からの再送を優先します。通常の初回計画だけがきれいでも、凍結運用の品質は分かりません。各ケースで旧・新版と下流システムの有効版を照合します。

まとめ

生産計画の凍結期間は、計算結果を固定するスイッチではなく、変更コストが高くなる境界を組織の承認とデータ連携へ落とし込む設計です。工場・ライン・材料で守る対象を分け、例外を記録し、ATP/CTPの納期回答と接続します。評価には計画安定性と納期遵守を併用し、RFPとFAT/SATで変更シナリオを試してください。

タイ工場で凍結ルールやERP・MES連携の整理を始める段階なら、現状の計画変更例を持ち寄ってご相談ください。製品を決める前の要求整理から対応できます。

参考情報

• Microsoft Learn, Master plans overview（freezeとfirmingの定義、2026年10月7日参照）
• Microsoft Learn, Firm planned orders（計画オーダー確定、同日参照）
• Oracle Fusion Cloud SCM, Considerations for Configuring Supply Plan Attributes（planning time fenceの製品固有動作、同日参照）
• SAP Help, Firming Planned Orders Using the Planning Time Fence（MRPタイプと品目ごとの確定、同日参照）
• Oracle Fusion Cloud SCM, Overview of Global Order Promising（ATP/CTP、同日参照）
• Microsoft Learn, Integrate with third-party manufacturing execution systems（MES連携イベント、同日参照）
• Oracle, Overview of Time Fence Planning（planning・demand・release各境界の区別、同日参照）