製造業の納期回答システム導入｜ATP・CTPと回答版の設計

製造業の納期回答システムを導入する目的は、営業担当が画面で「最短日」を押せるようにすることだけではありません。顧客の希望日、引当可能な完成品、材料の入荷見込み、設備と人の能力、出荷・輸送の時間を同じ時点の情報で照合し、誰が、どの数量を、いつ届けると約束したかを残すことです。タイの工場を例に、ATPとCTPの使い分け、回答版の承認、ERP・MES連携、RFPと受入試験までを実務に落とします。

本稿の数値例は設計を説明するための仮定であり、TOMAS TECHの導入実績や各製品の保証値ではありません。個別製品の機能範囲、タイ国内外の輸送日数、顧客との契約条件は導入時点で確認してください。

納期回答が属人化する工場で何が起きるか

受注窓口には「来週金曜日に800個」という希望が届きます。営業は在庫表を見て回答し、計画担当は別のExcelで設備負荷を組み、購買は仕入先からの最新回答をメールで受け取ります。各表の更新時刻が違うと、同じ品番について「可能」と「不可能」が同時に存在します。さらに先約の注文や品質保留品を差し引かなければ、帳簿上の在庫を二重に約束してしまいます。

納期遅延の原因を出荷当日に探しても、約束した当時の根拠が残っていなければ、改善先を特定できません。問題は単なる計算速度ではなく、回答候補と顧客へ送った確約を区別し、その間の承認を記録することです。照会時点では可能だった日が、別注文の確約後に不可能へ変わることもあります。候補を表示しただけで引当を確保したように扱う設計は危険です。

MicrosoftのOrder promising文書は、固定リードタイムだけの回答は在庫、既知の需要、計画供給を見ない一方、ATPは未確約在庫や計画入出庫を使い、CTPは材料に加えて能力も考慮する、と区別しています。OracleのGlobal Order Promisingも、手持ち品、移動中在庫、購買・製造・移送を供給候補として扱う構成を説明しています。これらは特定製品の実装例です。本稿で示す承認や監査の設計は、読者の業務要件として定義するもので、両社の標準機能が同じ形で必ず提供されるという意味ではありません。

ATPとCTPは何を答えるのか

ATP（Available to Promise）は、指定日までに確約に使える数量を検討する考え方です。現物在庫だけでなく、既存受注への割当、予定入庫、引当不可の品質保留、出庫・輸送余裕をどこまで含めるかをルール化します。CTP（Capable to Promise）は、完成品がない場合に、材料と生産能力から作れる日を検討します。生産予定を再計算するので、設備カレンダー、段取り、歩留まり、外注工程、材料入荷の信頼度が結果に影響します。

重要なのは「CTPを使えば常に正しい」ではない点です。MicrosoftはCTPの機能範囲が計画エンジンによって異なると明記しています。Oracleも供給元やルールを設定して初めて結果が決まると説明しています。実際の選定では、製品名ではなく自社の受注パターンをテストデータで流し、どの制約が計算に入ったかを確認します。頻繁に変更される材料納期や能力を取得できないなら、まずATPと承認運用から始める方が現実的な場合もあります。

「出荷日」と「顧客着日」は分ける

工場が10月20日に完成しても、検査、梱包、倉庫出庫、通関、輸送を経て顧客に届く日とは違います。見積画面には少なくとも完成可能日、最短出荷日、到着見込み日、顧客希望日、確約日を別フィールドで持たせます。Microsoft Business Centralの公式説明も、利用可能日から倉庫処理時間と輸送時間を加えて計画着日を計算する例を示しています。「納期」という一語だけをAPIやCSVに渡すと、営業と製造で意味がずれます。

タイ国内配送でも工場・倉庫の締切時刻、週末、顧客の受入時間帯を考慮します。輸出なら契約条件と輸送区間を明示し、会社が約束する地点を決めます。出荷後の運送事業者による変動まで工場が保証するかどうかは、契約で定めるべき領域です。記事中の「着日」は、あくまで合意した引渡地点と時刻帯に対する業務上の回答として扱います。

回答を作る前に「正本」と更新時刻を決める

納期回答は複数システムの状態を一枚の画面へ集めます。そこで最初に、どのデータをどこが責任を持って更新するかを決めます。受注行、希望日、優先順位の正本はERP。完成品在庫と品質保留はWMSまたは在庫モジュール。工程進捗と実績はMES。設備能力と休日・保全停止は生産計画。発注残と仕入先回答は購買。運送リードタイムと出荷締切は物流部門、という分担が一例です。企業によって正本は異なりますが、同じ項目を複数部署が独立に上書きする設計は避けます。

各回答候補には、計算時刻、入力データの版、計算ルールの版を記録します。たとえば「在庫は03:00更新、材料入荷は昨日16:00回答、設備負荷は現在時刻」という状態なら、画面に鮮度を表示します。古い情報を新しい確約に見せないためです。重要なデータが更新期限を超えたら、自動確約ではなく「確認待ち」に落とす条件を設定します。その期限を何分・何時間にするかは、製品、工場の運用、インターフェース頻度から決めます。

同じ品番でも顧客別の検査仕様、梱包、ラベル、輸出書類が異なれば、利用可能な在庫集合は変わります。品番だけで可否を判断せず、注文属性から対象ロットや工程条件を絞ります。代替品、分納、別工場生産を許す場合も、顧客契約と品質承認の範囲を確認します。Oracleの資料は、代替品や分割出荷を構成に応じた選択肢として説明していますが、自社で顧客承認なしに自動適用してよいという意味ではありません。

内示と確定注文は同じ需要ではない

内示を全量「確約済み」とみなすと在庫を過大に確保し、逆に無視すれば材料手配が遅れます。内示の版、確定注文との差異、どの時間帯を凍結するかを定義したうえで、納期回答へ反映します。詳しくは内示管理システムの版管理とMRP反映を参照してください。本稿では、確定注文に対する顧客向け回答版を最終責任の単位とします。

受注行から確約までの状態遷移を設計する

納期回答を単一の「予定日」欄で運用すると、途中の仮回答を後から上書きし、誰がいつ顧客に何を伝えたかが失われます。最低限、REQUESTED（顧客希望）、CALCULATED（内部候補）、REVIEW（承認待ち）、APPROVED（社内承認）、SENT（顧客送信）、ACKNOWLEDGED（顧客受領確認）、REVISED（改訂）の区別を置きます。これは本稿が提案する状態例であり、業界共通の必須コードではありません。

回答候補を計算しただけでは確約ではありません。特急割込、通常能力を超える残業、材料の未確定納入、顧客別割当変更、分納や代替品は、決裁権限を持つ人が確認します。承認後も顧客へ送っていなければ社内確定であり、送信した時刻とチャネルを記録して初めて外部への約束になります。顧客がEDIで受領した場合とメールで返信した場合も区別できるようにします。

一つの受注行が二回変更されたら、v1、v2、v3のように回答版を増やします。変更前の希望日、回答日、数量、理由、根拠データ版、承認者、顧客通知時刻を残し、古い版を消しません。v2で納期を遅らせても、顧客がまだ承諾していない間は、契約上どちらが有効かを営業・法務の手順で扱います。システムの画面表示だけで契約上の合意を置き換えないことが大切です。

変更イベントの順番と競合を扱う

受注数量変更と購買納期変更が同時に起こることがあります。すべての受注を毎分再計算して自動メールを送ると、回答が揺れます。イベントを受けたら影響を受ける注文を特定し、計算候補を更新し、確約済み行だけを変更審査キューへ入れます。顧客への通知は承認後に一回送る、という境界を設けます。注文IDと行ID、回答版を冪等キーにして、API再送で同じ版が二度発行されないようにします。

在庫を二人が同時に照会した場合の競合も重要です。画面表示時の数量が、確約時にも残っているとは限りません。確約操作では最新の引当可能量を再確認し、必要なら原子的な予約または排他的な確保処理を実行します。予約と顧客通知のどちらが失敗した場合にどう戻すかも、業務フローで決めます。SAPのaATP資料は在庫と将来入庫、同時の需要を考慮して確約候補を出すと説明しています。実装では、採用するERPのトランザクション境界をRFPと実機試験で確かめてください。

具体例：800個の希望にどう回答するか

以下はすべて説明用の仮定例です。顧客は品番Aを800個、10月30日着で希望しました。今日の完成品在庫は500個ですが、そのうち200個は別顧客へ確約済み、50個は品質保留です。したがって単純な利用可能量は500−200−50＝250個です。来週に予定入庫300個がありますが、仕入先の回答が仮の段階なら、全量を確実な供給として顧客へ約束するかどうかは別のルールで決めます。

残り550個を作るための主要材料は10月24日着見込み、ボトルネック工程は10月25日から毎日200個を処理できると仮定します。ただし段取り半日、品質検査一日、出荷・輸送二日が必要です。「200個/日×3日＝600個」とだけ計算して10月28日着と答えると、段取りと後工程を落とします。工程カレンダーに休日や保全停止があればさらに変わります。CTP候補は、材料入荷の確度、実際の能力枠、既存の負荷を含めて算出します。

顧客との交渉可能性を見せるため、単一の日付ではなく選択肢を出します。たとえば「250個を先行、残り550個を後送」「800個を一括で後日に」「同等品への代替を顧客承認後に適用」の三案です。それぞれ工場出荷日と顧客着日、追加費用、品質承認要否を分けます。分納禁止の契約なら最初の案は表示しても確約対象にしません。承認者は営業だけでなく、生産計画、品質、購買、物流の確認が必要な条件を事前に定義します。

この例で自動化できるのは、可用在庫の差引、工程枠の確認、候補日の算出、根拠データの記録までです。例外時の顧客対応や契約条件の判断は人が持ちます。システムは人の承認を省くためではなく、承認者が同じ事実を見て判断し、その判断を追跡できるようにするために使います。

ERP・MES・購買・物流をどうつなぐか

最小構成は、ERPの受注行を起点に、在庫・購買・製造計画のデータを取得し、回答サービスが候補を返し、承認後にERPの確約フィールドと顧客通知へ反映する形です。MESには確約を直接書き込むより、計画変更または指図変更の承認結果を渡す方が責任境界を明確にできます。工場の仕組みによってERPが計画も担う場合は別構成になりますが、データの正本と変更権限は明示します。

インターフェースでは、受注行ID、品目改訂、工場・倉庫、数量単位、タイムゾーン、回答版、イベント時刻を必須にします。日時だけでは日付と時刻の意味が曖昧なので、工場現地時刻とUTC保存、顧客の受入タイムゾーンを分けて扱います。タイ工場から海外顧客へ回答する場合、10月30日「着」がどの現地日付なのかを確認します。数量も個、箱、パレットを変換する際に梱包単位や端数を考慮します。

夜間の自動連携が止まった時に、営業画面が古い在庫のまま緑色の「確約可能」を表示してはいけません。最終取得時刻と異常を表示し、保留・手動照会へ落とします。復旧後に受注行を再計算し、顧客への送信済み版との差異だけを変更キューに入れます。メッセージの順序が入れ替わっても、古いイベントで新しい確約を上書きしないよう、版番号と発生時刻を照合します。

生産計画の凍結期間と連動させる

今日の設備枠を奪って特急注文に約束すれば、先約が遅れることがあります。生産計画の凍結期間と変更承認で示すように、凍結期間内の計画変更には例外条件と承認が必要です。納期回答システムは、空き能力に見える枠が本当に移動可能かを計画ルールから受け取ります。凍結期間を無視してCTP候補を確約すると、営業には約束可能に見えても製造が実行できません。

またMOQや発注倍数がある部材は、必要量だけ買えるとは限りません。製造業のMOQ管理とMRP提案のように、材料手配の制約は供給日と費用に影響します。ただしMOQによる追加在庫の判断と、今回の顧客向け納期確約は別の承認として扱います。

RFPには何を書き、何を比較するか

RFPで「ATP・CTP対応」と一行だけ書いても比較できません。少なくとも①在庫・予約・品質保留をどう差し引くか、②材料と工程能力をどの粒度で見るか、③分納・代替・別工場をどこまで許すか、④日付をどの地点で定義するか、⑤回答候補と確約版をどう保存するか、⑥承認権限と顧客通知をどう連携するか、⑦障害時にどう保留するか、をシナリオ付きで質問します。

デモ用の美しい画面だけでなく、自社の過去受注を匿名化して投入します。通常品、受注生産品、品質保留、材料遅延、特急割込、分納禁止、計画凍結、輸出便締切の八種類を含めると、製品ごとの制約と追加開発範囲が見えます。ベンダーには「標準設定で可能」「追加設定が必要」「開発が必要」「対応しない」を分けて回答させます。画面の候補日だけでなく、どのデータとルールから候補が出たかの説明可能性を採点します。

費用はライセンスだけで比較しません。ERPとMESの接続、マスタ整備、履歴移行、タイ語・英語画面、承認ワークフロー、顧客EDIやメール、監視・障害対応、教育、保守を見積項目にします。特にCTPは能力マスタの準備が大きな作業です。能力表がない工場に高機能エンジンだけ導入しても、導入効果は出ません。価格相場を根拠なく提示するより、自社の対象受注行数、工場数、接続先、例外件数で同じ条件の見積を取ります。

FAT・SATで確認する失敗シナリオ

FATはベンダー環境でルールと連携を検査し、SATは実際の工場データ、端末、ネットワーク、担当者で運用を検査します。合格条件は「画面に日付が出る」では足りません。たとえば二人が同時に残り100個をそれぞれ80個確約しようとしたとき、一方は再計算・保留され、合計160個を約束しないことを確認します。品質保留50個を利用可能に算入しないこと、仕入先納期が延びた時に影響注文を変更キューへ入れることも検査します。

回答版の試験では、v1を顧客に送信後、受注数量を変更し、v2が承認されるまで自動送信されないことを確かめます。送信に失敗したら承認済みと送信済みを混同せず、再送で二通の矛盾したメールを作らないことも必要です。時刻試験にはタイの週末・工場休業日・顧客の別タイムゾーン・出荷締切直後を含めます。計画凍結期間内の割込は、承認なしで既存確約を後ろ倒しにしないことを検証します。

性能試験の秒数は自社の業務要件として決めます。たとえば大量見積と正式受注で許される待ち時間は異なります。さらに計算の速さだけでなく、入力データの更新遅延、承認待ち時間、顧客への送信遅延を別に計測します。これらを一つの「納期回答時間」に混ぜると、改善すべき場所が見えません。

指標は顧客との約束を基準に定義する

導入前後で見る指標は、希望日回答率、回答リードタイム、確約納期遵守率、確約改訂率、改訂理由別件数、無承認例外件数、データ鮮度違反、同時確約競合、顧客からの再問い合わせ件数です。「納期遵守率」の分母を全出荷行にするか、顧客へ送った確約行にするかを決めます。分納時は注文単位と行単位の両方を見ます。遅延を隠すために回答日を後ろへ動かせば数字が良くなる、という設計を避けるため、初回確約日と改訂後確約日を別に保存します。

仮の試算として、一日100行の回答に担当者が平均12分かかり、導入後の通常70行が平均4分、残り30行の例外審査が15分なら、従来は100×12＝1,200分、導入後は70×4＋30×15＝730分、差は470分です。これは業務工数の説明例であり、実際の削減率ではありません。マスタ維持や障害対応を含め、導入前後に同じ測定方法で実測します。納期遵守率の改善も、需要変動や生産能力の変化を分けて評価してください。

段階導入はどの順で進めるか

第一段階では、対象を一工場・一製品群・一つの受注窓口に絞り、受注行と在庫・予約のデータを整えます。候補日と顧客確約を別に保存し、手動承認で回答版を作ります。この段階で「在庫があるのに出せない理由」と「候補日が変わる理由」が可視化されます。複雑なCTPより先に、データの鮮度と約束の履歴を検証します。

第二段階で材料の予定入庫と工程能力を追加し、受注生産のCTP候補を試します。まず自動確約はしません。担当者の従来判断とシステム候補を並走比較し、差異を「在庫誤差」「材料日付」「能力負荷」「輸送条件」「契約条件」に分類します。差異が説明できない案件はルールやマスタを直してから対象を広げます。第三段階で顧客EDI、分納提案、別工場、優先順位変更を追加しますが、承認と再確約の規則は維持します。

プロジェクトの責任者は営業だけでは不足します。営業が顧客への約束を持ち、生産計画が能力枠、購買が材料日付、品質が利用可能ロット、物流が着日計算、ITが連携と監視を持ちます。例外の最終承認者と代行者を決め、夜勤・休日の対応も用意します。システム導入前に、この業務上の責任分担を合意することがもっとも重要な準備です。

初期導入で作るべき運用文書

画面仕様だけでは、現場の判断が揃いません。最初に、受注受付から確約、改訂、出荷までの業務フロー図を作り、各状態に入る条件、承認者、顧客への連絡方法を一枚にします。次に、品目ごとの回答方式を定義します。在庫販売品はATP、受注生産品はCTP候補と計画担当承認、試作品や設計変更中の品目は手動審査、といった分類です。分類を品目マスタへ埋め込むだけでなく、例外と見直し担当も記します。

データ辞書には「利用可能在庫」「確定入荷」「着日」「予約」の定義を書きます。品質保留、輸送中、サンプル用、他顧客専用の在庫を含めるかは会社ごとに違います。名称が同じでもERPとWMSで意味が違えば、接続時に誤った数を足します。変更履歴には、何を修正したかだけでなく、その修正がどの確約済み受注へ影響したかを追えるキーを残します。顧客との合意書やEDI仕様も、回答版と紐付けて保管します。

障害時の手順には、連携停止を検知する人、回答を一時停止する閾値、顧客へ「確認中」と伝える文言、復旧後の再照合、二重送信防止の確認を書きます。システムが使えない間に電話で答えた場合も、後から手動回答版として登録し、根拠と承認者を残します。そうしないと、復旧後の画面が古い候補を再度顧客へ送ってしまいます。

定着後に見直すルール

初期設定の安全余裕や入荷確度を永久に固定する必要はありません。月次で、回答できなかった案件、過度に保守的だった案件、確約後に改訂された案件を抽出し、原因ごとにルールを見直します。ただし納期遵守率を上げるために単純に余裕日数を増やせば、販売機会を失う可能性があります。希望日に応じられた率と、確約を守れた率を並べて判断します。顧客や製品群別の傾向を見る際は、優先順位ルールが特定顧客に不公平な結果を出していないかも確認します。

材料供給の信頼度は、仕入先の回答履歴や実入荷日で更新します。ただし「この仕入先は平均して二日遅れる」といった統計を、すべての品目へ機械的に適用するのは避けます。輸入材、長納期品、現地調達品では変動の性質が違います。供給リスクが高い品目は、日付を確約せず条件付き回答へ落とす規則も必要です。顧客には条件を明示し、条件が満たされたときに確約版へ昇格させます。

導入後に製品構成や製造拠点が変われば、CTPモデルの工程と能力も更新します。新設備の能力を登録した直後に全品目の納期が短くなるような結果が出たら、対象品目、治具、作業者資格、品質承認、前後工程が欠けていないか点検します。候補日が早くなる変更ほど、先行する顧客約束を守れるか慎重に確認してください。

顧客への回答文を、計算結果から直接作らない

納期回答画面が正しい日付を出しても、顧客に届く文章が曖昧なら約束の意味は揃いません。「十月末頃に出荷できそうです」と「十月三十日までに貴社倉庫へ納入します」は、日付も責任範囲も違います。回答文の雛形には、注文番号と行番号、品番と改訂、数量、分納の有無、出荷予定日、合意した引渡地点での到着予定日、回答の有効期限、条件付き回答ならその条件を含めます。確約前の候補である場合は、顧客が正式な約束と受け取らない表現と表示を使います。

営業担当が顧客の希望に近づけようとして、画面の日付を手入力で早める機能を置くなら、元の計算候補を残したまま、変更理由と承認者を必須にします。入力欄を自由にするだけでは、納期回答システムが単なる新しい表計算になります。反対に、顧客と相談して納入場所や数量を変更できる業務なのに、画面で一切修正できないと、担当者はシステム外のメールや電話へ戻ります。調整できる項目と、再計算・再承認が必要な項目を分けることが実務的です。

顧客から「早い案と安い案を両方示してほしい」と言われる場合もあります。特急輸送で二日前倒しできるとしても、追加費用、物流の確保状況、品質検査を短縮していないことを同じ画面で示します。候補は複数提示できても、実際に確約する案は一つに固定するか、分納行ごとに明確に分けます。古い提案書を参照した顧客が別の日付を主張したときに、どの版のどの案が承認・送信されたかを説明できる状態が必要です。

多言語の回答で項目を揃える

タイ工場では、工場内の確認がタイ語、日系顧客への回答が日本語、海外顧客への回答が英語やベトナム語になることがあります。自由文を毎回訳すのではなく、数量、単位、地点、日付、時刻帯、条件、承認状態を構造化し、その同じ値から各言語の回答を生成します。翻訳するのは定型文と理由コードであり、数値と日付の原データは共有します。これにより、言語ごとに異なる数量を通知する事故を減らせます。

ただし自動翻訳だけに任せてはいけない表現があります。「出荷予定」「納入確約」「到着見込み」「顧客受領」は異なる状態です。各言語の文面を営業・物流・契約担当が確認し、どの語が契約上の約束を表すかを統一します。日付表記も月日が入れ替わり得る形式は避け、月名または国際的に誤読されにくい表記を採用します。時刻を示すなら、工場と顧客のどちらの現地時刻かを明記します。

回答の信頼度をどう表示するか

納期回答には「確実」か「不可能」かだけでは扱いきれない案件があります。材料は発注済みでも仕入先の確約が未着、設備は空いていても保全停止が未確定、輸送便は通常時刻が分かっていても予約は未了、といった状態です。これらを一つの確率に変換して顧客へ提示する前に、どの条件が未確定なのかを内部で明示します。供給条件が一つでも未確認なら、日付を自動確約せず、担当者が確認すべき項目を列挙する方が運用しやすい場合があります。

たとえば「材料入荷確認待ち」「品質解放待ち」「能力枠の承認待ち」「便予約待ち」という理由コードを持たせます。それぞれに責任部署、次の確認予定時刻、顧客への仮回答可否を設定します。保留が長引く場合は顧客へ「いつまでに正式回答するか」を伝え、その回答期限も履歴化します。未確定の日付を確約日に入れてしまうと、計画変更時に黙って日付が動くため、担当者も顧客も異常に気付きにくくなります。

回答の信頼度を色で表示する場合は、色だけに依存せず、理由と次の行動を文章でも表示します。緑色でも供給データの更新時刻が古ければ、表示の根拠は弱くなります。赤色でも、顧客が分納を許し、別工場の能力を使えるなら、提案可能な選択肢が残ることがあります。色を判断の代わりにせず、担当者が必要な確認先と影響範囲をすぐ分かるようにします。

影響調査を一件の遅延から始める

ある材料が三日遅れると分かった場合、購買担当から営業へ一斉メールするだけでは、どの顧客へ何を伝えるべきか決まりません。材料ロットから紐付く製造指図と受注行をたどり、その中で確約済みの行、まだ候補段階の行、代替材料を承認できる行に分けます。確約済み行には旧版と新候補の差を示し、担当営業へ変更審査を割り当てます。顧客通知の優先順位は契約条件と影響の大きさに基づきます。

この影響調査にも過大な自動化を避けます。材料の入荷日が延びても、完成品在庫や別供給が十分なら顧客の確約日は変わらないことがあります。逆に小さな部材一つでも、その部材が特定工程に不可欠なら複数注文へ影響します。システムは関係する注文を広く抽出し、再計算で実際の影響を絞り、最後に人が顧客への説明を承認する流れにします。影響を受けない顧客へ不要な遅延通知を送ることも、影響のある顧客へ連絡しないことも避けられます。

よくある質問

納期回答システムと生産スケジューラーの違いは？

生産スケジューラーは、工程・設備・人員の作業順序と能力枠を計画する道具です。納期回答システムは、その計画と在庫・材料・輸送情報から顧客への約束候補を作り、承認と送信の版を管理します。製品によって両機能が一体の場合も、業務上は「内部計画」と「顧客確約」を別の状態として扱います。

ATPだけで受注生産の納期を確約できますか？

完成品や予定入庫だけを見れば、これから作る品目の工程能力を見落とす可能性があります。材料と能力が重要ならCTPまたは計画担当の審査を組み合わせます。ただしCTPの計算結果も、マスタの精度と、各製品で有効な制約の範囲に依存します。自社の制約を受入試験で確認してください。

納期回答を自動化したら営業承認は不要ですか？

標準品で予約可能量と輸送条件が明確な案件は、決めた範囲で自動承認を検討できます。特急、分納、代替品、契約外条件、既存顧客への影響がある案件は、権限者の確認を残す方が適切です。自動化の範囲は顧客契約とリスク区分で決めます。

遅延が判明したら確約日を上書きしてよいですか？

過去の確約版は消さず、新しい候補と理由、承認、顧客通知を次の版として記録します。顧客の同意が必要か、旧約束がいつまで有効かは契約と業務手順で扱います。上書きだけでは、遅延の原因と顧客に伝えた内容を後で確認できません。

まとめ

製造業の納期回答システムは、ATP・CTPの計算エンジンだけで完成しません。受注行に対して材料・能力・物流の情報の鮮度を揃え、候補日と顧客への確約を分け、変更を版と承認で追跡して初めて実用になります。導入時は、一工場の実データで二重引当、品質保留、材料遅延、計画凍結、顧客通知の失敗を試し、どの制約が製品標準で扱えるかを確認してください。

TOMAS TECHでは、タイ工場のERP・MES・購買・物流データを使った納期回答の業務設計からご相談いただけます。製品選定前のRFPや、一製品群だけでの試行段階でも、お問い合わせから現状の回答フローをお知らせください。

参考資料

• Microsoft Learn: Order promising — 固定リードタイム、ATP、CTPの区別。
• Microsoft Learn: Calculate order promising dates — 出荷・倉庫処理・輸送日付の考え方。
• Microsoft Learn: Delivery alternatives — 代替供給と輸送選択肢。
• Oracle: Overview of Global Order Promising — 購買・製造・移送からの供給候補。
• Oracle: Specify lead times for assembly operations — 固定・可変の組立リードタイム。
• SAP Help: Advanced Available-to-Promise — 確約数量・日付と同時需要。
• SAP Help: Supply Creation-Based Confirmation — 材料と重要設備能力を含む確約候補。