S/4HANAネイティブ受注履行の設計と実践
2026年6月
「受注した商品が、いつ、何個、どこから出荷できるか」——この問いに対して、即座かつ正確に答えられる企業が、顧客から選ばれ続ける時代が到来しています。ECサイトやEDIを通じて瞬時に注文が届く現代において、「納期は後日回答します」という対応は、顧客の離反を招くリスクと直結します。
SAP Advanced Available-to-Promise（以下、aATP）は、この「注文約束（Order Promising）」の課題に対してSAP S/4HANAが提供する回答です。従来のATP（利用可能在庫チェック）が単純な在庫照合に留まっていたのに対し、aATPは在庫・生産能力・輸送制約・顧客優先度・代替品在庫までを統合的に考慮した上で、リアルタイムで最適な注文確認を生成します。
本稿では、aATPを構成する各機能モジュールを「なぜ必要か」「何を解決するか」「どう設定し操作するか」という三つの軸から解説します。IBPが「計画」の領域を担うのに対し、aATPは「約束」の領域を担うという位置づけを理解することが、本稿を読み進める上での最初の出発点となります。
SAP Advanced Available-to-Promise（aATP）とは、SAP S/4HANA上でネイティブに動作する、受注履行（Order Fulfillment）のための高度な在庫確認・注文約束機能です。受注時に「どの品目を、何個、いつ、どこから供給できるか」をリアルタイムで計算し、顧客に対して実現可能な確認日付と数量（Confirmation）を即座に提示します。
従来のSAP ERPおよびSAP APOが提供してきたATP機能（いわゆる「基本ATP」や「gATP」）と比較したとき、aATPの最大の差別化要因は「何を考慮した上で確認を生成するか」の幅の広さにあります。基本ATPが「現在の在庫と将来の入庫予定に基づく単純な在庫引当」に留まっていたのに対し、aATPは製品配賦（Product Allocation）・供給保護（Supply Protection）・代替拠点・代替製品・製造能力・輸送スケジューリングまでを統合的に考慮した確認を生成します。
SAP公式資料の言葉を借りれば、aATPは「関連するすべてのサプライチェーン制約を考慮しながら、ビジネス優先度と収益性目標を守りつつ、正確で信頼性の高い注文約束日を提供する」ソリューションです。これは、単なるシステム機能の強化ではなく、企業の「約束する能力（Promise-Making Capability）」そのものを競争優位の源泉へと変えるための経営的転換を意味します。
ATPの進化を歴史的に辿ると、SAP ERP時代の「基本ATP（Digital Core ATP）」→ SAP APO時代の「gATP（Global ATP）」→ SAP S/4HANA時代の「aATP」という系譜をたどります。
基本ATPは、需要と供給の時系列データ（ATP時系列）に基づいて在庫引当を行うシンプルなメカニズムです。一方APO gATPは、製品配賦・部品表（BOM）展開に基づく多段階ATP・ルールベース代替検索などの高度な機能を持ちましたが、S/4HANAとは別システムで稼働するためデータ同期と遅延が課題でした。aATPはこれらの機能をS/4HANA内にネイティブに実装し直したものです。APO gATPからaATPへの機能移行（Migration）は提供されておらず、企業は新たに設計・実装することになります。
S/4HANAのデジタルコアATPとaATPの違いも重要です。デジタルコアATPは製品有効在庫チェック（PAC）とバックオーダー処理（BOP）のみを提供するのに対し、aATPはこれに加えて製品配賦・代替ベース確認・供給保護・供給割当・輸送スケジューリングなどの高度な機能を備えます。「SAP S/4HANAを導入したからaATPが自動的に使える」ではなく、aATPは追加の設計・設定・ライセンスが必要な機能群であることを認識しておく必要があります。
SAP供給チェーンソリューション全体の中でIBPとaATPがどのような役割分担を担うかを理解することは、両ソリューションを正しく評価する上で不可欠です。
IBPは「計画（Plan）」の領域を担います。数ヶ月から数年先の需要・供給・在庫を統合的に計画し、リソースをどこにどれだけ配置するかという中長期の意思決定を支援します。一方aATPは「約束（Promise）」の領域を担います。実際に受注が入った瞬間に、計画された在庫と供給能力に基づいて、「この注文を、いつ、いくつ、どこから届けられるか」をリアルタイムで顧客に約束します。
IBPで計画された製品配賦データ（販売チャネル別・顧客別の割当数量）をaATPの製品配賦機能に取り込む連携が実現しており、計画と約束が一貫した数値体系で結びついている点が重要です。「IBPで決めた配賦計画をaATPが実際の受注に適用する」という連携が、サプライチェーン全体のコントロールタワーとしての機能を可能にします。
注文約束（Order Promising）の現場が直面している課題は、大きく四つに整理できます。
リアルタイム確認への要請：ECサイトやEDI経由で受注が届く現代、顧客はほぼ即時の納期回答を期待しています。「翌営業日に回答」という対応では、顧客の購買決定機会を失います。
ビジネス優先度と収益性に基づく配分：在庫が限られている局面では「どの顧客の注文を優先するか」という判断が経営課題となります。しかし従来のATPは「先着順（First Come, First Served）」が基本であり、戦略的な顧客優先管理をシステムで実現することが困難でした。
複雑なサプライネットワークへの対応：単一工場・単一倉庫という構造は少数派となり、複数拠点・複数代替品・複数輸送ルートが絡み合う複雑なネットワークから最適な供給源を瞬時に特定することが求められています。
計画と約束の乖離：IBP等で策定した販売計画や製品配賦計画が、実際の受注対応で守られずに形骸化する問題が多くの企業で発生しています。計画で「A顧客向けに100個確保する」と決めても、受注処理の現場でその配賦が守られなければ、計画そのものの意味が失われます。
SAP ERP標準の基本ATPが構造的に解決できない問題として、以下の三点が挙げられます。
第一は「先着順の罠」です。基本ATPは在庫を時系列で先着順に引き当てます。その結果、戦略的に重要度の低い顧客の注文が先に処理されることで重要顧客分の在庫が枯渇し、後から来た大口・重要顧客の注文を確認できないという「逆転現象」が日常的に発生します。在庫が逼迫しているときほど、この問題は深刻です。
第二は「単一拠点の限界」です。基本ATPは原則として1拠点の在庫に対してチェックを実行します。「A工場に在庫がなければB工場を見る」「C製品がなければ代替のD製品を提案する」という柔軟な代替確認が、設定なしには実現できません。顧客が受注した製品・数量・日付の組み合わせで在庫がなければ、単純に「確認不可」という結果しか返せないのです。
第三は「計画との断絶」です。基本ATPは個々の受注処理の場での在庫引当ツールであり、販売計画・配賦計画との動的な連携がありません。IBPで策定した製品配賦計画を受注対応に強制的に反映させる仕組みがなければ、計画は「参照情報」に留まり、現場の受注処理はそれを無視した「早い者勝ち」のままとなります。
aATPはこれらの三つの問題に対して、製品配賦（PAL）・代替ベース確認（ABC）・バックオーダー処理（BOP）・供給保護（Supply Protection）という機能群で体系的に答えを提供します。
aATPは単一の機能ではなく、複数の機能モジュールから構成されるソリューションです。各モジュールは独立して機能しますが、組み合わせることで相乗効果を発揮します。主要モジュールは以下のとおりです。
製品有効在庫チェック（Product Availability Check：PAC）：全機能の基盤となるリアルタイム在庫確認モジュール。受注時に在庫と将来入庫予定を照合し、確認可能な数量・日付を算出します。
バックオーダー処理（Backorder Processing：BOP）：需給状況が変化したタイミングで、過去確認済みの注文を優先度ルールに従って一括再確認するバッチ処理機能です。
製品配賦（Product Allocation：PAL）：販売チャネル・顧客セグメント別に在庫を事前配分し、その枠に対して受注を照合する「割当管理」機能です。
代替ベース確認（Alternative-Based Confirmation：ABC）：要求品目・拠点で在庫が確保できない場合に、代替製品・代替拠点・代替保管場所を自動的に探索し最適な確認を生成する機能です。
供給保護（Supply Protection：SUP）：特定の顧客グループや販売チャネルに対して優先供給枠を設定し、優先顧客への供給を保護する機能です。
供給割当（Supply Assignment：ARun）：需給状況を一括分析し、最も重要な需要に対して物理的な在庫・入庫を割り当てることで、出荷まで確実に供給を確保する機能です。
ATPスケジューリング（ATP Scheduling）：輸送計画日・積み込み日・ピッキング時間・輸送リードタイムなどを考慮した上で、実現可能な納品日を計算する機能です。
受注が入った瞬間から納品確認が完了するまでの流れの中で、aATPの各モジュールはどのように連携するのかを整理しておく必要があります。
受注入力と同時にPACが起動し、要求品目・数量・希望日に対する在庫確認を実行します。その際、PALによる製品配賦の制約が適用され、顧客・販売チャネルの属性に基づいて利用可能な割当枠の中でしか確認が行われません。在庫が要求を満たせない場合、ABCが代替品・代替拠点を探索し、最適な代替確認を提案します。ATPスケジューリングは在庫が確保できる日付から逆算して実際の納品日を計算します。
一方BOPは定期的なバッチ処理として稼働し、キャンセル・入庫変更・新規大口受注などで需給バランスが変化したときに、既存の確認を優先度ルールに従って再計算し直します。そして供給割当（ARun）は出荷直前のフェーズで在庫と注文の物理的な紐付けを確定し、「確認済み」から「確保済み」への最終確定を行います。
この一連のフローの全体が、S/4HANAのHANAインメモリデータベース上でリアルタイムに実行されます。
製品有効在庫チェック（Product Availability Check：PAC）は、aATPの全機能の基盤となるモジュールです。顧客が「品目Aを、100個、X日に欲しい」という受注を入れた瞬間に、そのリクエストに対して「いつ、何個が確認可能か」をリアルタイムで計算し、確認（Confirmation）を生成します。
PACの計算ロジックの核心は「時間軸上の在庫可用量（Cumulated Available Quantity）の追跡」です。現時点の手持在庫を起点として、将来の入庫予定（製造指図・購買発注・輸送入庫）を加算し、既存の需要（確認済み受注・出荷指示）を減算した「累積利用可能在庫」を時間軸上で計算します。希望納期の時点でこの累積利用可能在庫が要求数量以上であれば「オンタイム確認」となり、不足する場合は要求が充足できる最初の日付を探索します。
この計算において考慮する在庫・供給・需要の範囲（スコープ）は設定で制御できます。たとえば「安全在庫は確認に使用しない」「品質管理中在庫は除外する」「発注残は参入する」といった設定が、Customizingの「有効在庫チェックのスコープ（Scope of Availability Check）」で定義されます。
PACにおけるスケジューリングは、受注の希望納品日から逆算する「バックワードスケジューリング」と、今日を起点に順算する「フォワードスケジューリング」の二段構えで機能します。
バックワードスケジューリングでは、顧客の希望納品日（Requested Delivery Date）から輸送リードタイム・梱包時間・ピッキング時間などを逆算して「材料有効在庫日（Material Availability Date）」を算出します。この日付の時点で必要数量の在庫があれば、オンタイム確認が成立します。
材料有効在庫日に在庫が確保できない場合、システムはフォワードスケジューリングに切り替えます。今日を起点に、入庫予定が累積して必要数量を超える最初の日付を特定し、そこからフォワードに納品日を再計算します。「今日以降の最短で、いつ届けられるか」を自動的に提案するのです。
一部確認（Partial Confirmation）も可能です。たとえば希望日に40個しか在庫がなく、残り60個が2週間後に入庫する場合、「希望日に40個、2週間後に60個」という複数日付にわたる分割確認が生成されます。これを顧客が受け入れるか否かを判断できる「納品提案（Delivery Proposal）」として提示するUIが、aATPのSAP Fioriアプリに実装されています。
受注処理において見落とされがちな重要な概念が「仮数量割当（Temporary Quantity Assignment：TQA）」です。受注担当者が受注画面でATPチェックを実行した瞬間から、その受注が保存（Save）される前の段階でも、TQAという仕組みで在庫が仮押さえされます。
なぜこれが重要か。オンライン受注処理では、複数のオペレーターが同時に同じ品目の在庫を確認しているケースが常時発生します。TQAなしでは、Aオペレーターが在庫チェックをしてから保存するまでの数分間に、Bオペレーターが同じ在庫を確認・保存してしまうという「二重確認」が起こります。TQAはこの問題を防ぐために、ATPチェックが実行された瞬間に在庫を仮押さえし、他の確認からその数量を除外します。
TQAの有効期間は標準で8時間です。受注が保存されればTQAは実確認に置き換えられ、受注がキャンセルまたは破棄されればTQAも自動削除されます。ただしシステム障害等で処理が異常終了した場合、TQAが残留して在庫を不正に占有し続けるリスクがあります。このためaATPにはTQAの残留チェック・クリアのためのレポート（ATP_TQA_PAC_DEL_DISPLAY）が用意されており、管理者権限で定期的な保全作業を行うことが推奨されています。
PACを機能させるために、Customizingで設定する主要パラメーターを示す。
チェックグループ（Checking Group）：品目マスタに設定する。「在庫確認を行うかどうか」「どのATPチェックを適用するか」を品目単位で制御する属性値。aATPの高度な機能（製品配賦・代替確認等）を適用する品目には専用のチェックグループを設定する必要がある。
チェッキングルール（Checking Rule）：販売伝票タイプ（例：通常受注=OR、急送受注=RU）ごとに、どのスコープで在庫確認を行うかを定義する。急送受注では安全在庫も確認対象に含める、または過去の受領も考慮するといった差別化が可能。
チェックホライゾン（Check Horizon）：何日先までの入庫予定を確認対象として考慮するかを定義する。たとえばホライゾン=60日とすると、60日を超えた将来の入庫予定は確認計算に使用されない。これにより「実現可能性の低い遠い将来の入庫」に基づく過大な確認を防止する。
数量配分（Quantity Distribution）：製造指図・計画オーダーの入庫数量を、製造期間全体に日割り配分して在庫確認に使用する機能。これをオンにすることで、製造期間の途中からでも部分的に在庫が利用可能な状態として扱えるため、確認精度と供給柔軟性が向上する。
【チェッキングルール設定例】販売伝票タイプ「OR（通常受注）」と「RU（緊急受注）」で異なるチェッキングルールを割り当てた設計例を示します。ORではチェックホライゾン60日・安全在庫除外・品質検査中在庫除外・前月以前の在庫除外という厳格なスコープを適用します。RUでは同品目に対してホライゾン=無制限・安全在庫を50%まで確認対象に含める・品質検査中在庫を30%まで仮利用可能として扱うというより広いスコープを適用します。この設計により、緊急顧客への優先対応を「受注担当者が手動で在庫を探す作業」ではなく「販売伝票タイプの選択」という標準業務フローで自動実現できます。RU伝票タイプへのアクセスは担当者の職位・権限（Authorization Object）で制限することで、緊急扱いの乱用を防止します。
バックオーダー処理（Backorder Processing：BOP）は、需給状況が変化したタイミングで、過去に生成された受注確認をバッチ処理で一括再評価するaATPの機能です。オンラインのPACが「新規受注が入った瞬間」のリアルタイム確認であるのに対し、BOPは「需給バランスが崩れた後」に「確認全体の最適再配分」を行う定期的なリセット処理です。
BOPが必要になる典型的なシナリオには以下のものがあります。重要顧客からの大口受注が入ったが、既存の低優先度顧客の確認がすでに在庫を占有していて確認できない。ある受注がキャンセルされ在庫が解放されたため、以前に確認できなかった受注に再配分できる。入庫予定が遅延し、既存確認が実現不可能になった。これらのケースでは、個々の受注を手作業で修正するのではなく、BOPによって優先度ルールに従ったシステマティックな再確認が行われます。
BOPが各需要に対してどのような確認結果を生成するかは「確認戦略（Confirmation Strategy）」で定義されます。aATPが提供する標準的な確認戦略のカテゴリを示します。
Win（優先確認維持）：優先度の高い需要が現在持っている確認を維持します。すでに良い確認を持っている重要顧客の注文を「勝ち組」として守ります。
Gain（新規確認獲得）：現在は未確認または不十分な確認しか持っていない需要が、解放された在庫から新たな確認を獲得することを目指します。
Redistribute（確認の再配分）：低優先度の需要から確認を取り消し、高優先度の需要に再配分します。これが「先着順を覆す」BOPの最も本質的な機能です。
Fill（残余在庫の充填）：上記のWin・Gain・Redistributeの処理後に残った在庫（余剰在庫）を、まだ確認が不足している需要に割り当てます。
これらの確認戦略とBOPセグメント（品目グループ・得意先グループ等での絞り込み）・BOP変数（実行タイミング・パラメーター）を組み合わせて「BOPバリアント（BOP Variant）」として設定し、スケジュール実行します。たとえば「毎日深夜2時に全品目を対象としたBOPを実行し、前日夜間に変化した需給状況を翌朝の業務開始前に再確認済みの状態にする」という運用が典型的なパターンです。
BOPの設定と実行はSAP Fioriアプリ「Configure BOP Variant（BOP変数の設定）」と「Schedule BOP Run（BOP実行のスケジュール）」を通じて行います。
BOPセグメントの定義：品目・拠点・得意先・販売組織などの属性でフィルタリングし、どの需要・供給をBOPの対象とするかを定義します。たとえば「販売組織1000の全受注を対象」「特定品目グループのみ」という絞り込みが可能です。
確認戦略の割当：セグメントに対して確認戦略（Win/Gain/Redistribute/Fill）のどれを適用するかを割り当てます。重要顧客グループにはWinを優先し、一般顧客グループにはFillを適用するという差別化が一般的です。
優先度属性の設定：需要の並び替えに使用する属性を定義します。得意先の優先度クラス（Priority Class 1=最重要、5=標準）・注文の確認リードタイム余裕・製品の利益率など、複数の属性を順位付けして組み合わせることができます。
シミュレーション実行：本番更新の前に「シミュレーションモード」でBOPを実行し、確認がどのように変化するかをプレビューできます。「Monitor BOP Run（BOP実行の監視）」アプリで結果を品目・得意先別に確認し、意図した通りの再配分が行われることを確認した上で本番更新に移行します。
BOPの実行ログ分析は「Monitor BOP Run」アプリを起点とし、以下のフィールドで品目・得意先別に精査します。
再確認タイプ（Rescheduling Category）：BOPが各受注明細に行ったアクションを分類します。「新規確認獲得（Gained）」「確認改善（Improved）」「確認悪化（Worsened）」「変更なし（Unchanged）」「完全取消（Cancelled）」の5カテゴリが表示されます。意図に反して重要顧客の確認が悪化していないか、不要な取消が発生していないかをこのフィールドで即座にフィルタリングできます。
確認数量の変化（Before / After Confirmed Quantity）：BOP実行前後の確認数量が明細単位で並列表示されます。差分がマイナスの行は「確認が削減された受注」であり、優先度設計が意図通りに機能したかどうかの検証に使用します。特にRedistribute戦略適用後にこのフィールドを確認し、高優先度顧客の数量が増加・低優先度顧客の数量が減少していることを確認します。
未処理需要（Unprocessed Demand）：在庫不足等でBOPが確認を生成できなかった需要の一覧です。未処理需要の量が多い場合、それは優先度設計の問題ではなく「供給量そのものが計画を下回っている」シグナルです。このデータを週次SCM会議に持ち込むことで、調達・生産計画との意思決定の根拠として機能します。
BOP処理時間（Processing Duration）：BOPが対象セグメントの処理を完了するまでに要した時間です。処理対象需要件数の増加に伴い処理時間が増大します。BOPのセグメント分割（品目グループ単位での並列実行）を設計する際のパフォーマンス設計の基準値として使用します。標準的な運用では1セグメントあたり数分〜十数分での完了を目安とし、深夜バッチウィンドウに収まる設計にします。
製品配賦（Product Allocation：PAL）は、販売チャネル・顧客セグメント・地域などの属性別に在庫の割当枠（Allocation Quantity）を事前設定し、受注時の在庫確認をその枠内に収める「枠管理」機能です。
PALが解決する問題は明確です。希少な在庫を持つ人気製品で、特定の大口顧客が大量発注することで他の顧客分の在庫がなくなる「買い占め問題」と、季節需要や需給逼迫時に「誰にどれだけ売るか」を企業が能動的にコントロールできない問題です。PALは、配賦計画という「販売の枠組み」を受注処理に強制的に適用することで、これらを解消します。
IBPの供給計画で生成された製品配賦計画をAPIでaATPのPALに取り込む連携機能が提供されており、計画と実行の一貫性を保つことができます。「IBPが立てた配賦計画をaATPが実行する」というループが、サプライチェーン全体のコントロールを可能にします。
PALを設計・運用する上で理解すべき基本概念を以下に整理します。
特性値組み合わせ（Characteristic Value Combination：CVC）：配賦量を定義する単位です。「販売組織=0001、販売チャネル=01、得意先=顧客A」という複数の特性の組み合わせでCVCが特定され、そのCVCに対して時期別の配賦数量（時系列）が設定されます。
配賦オブジェクト（Product Allocation Object）：特性の組み合わせと時間軸を定義するマスターデータです。「配賦量の単位はEA（個）、期間タイプは月次、チェック日時は希望納品日を使用」といった配賦の基本設定を持ちます。
配賦シーケンス（Product Allocation Sequence）：複数の配賦オブジェクトを「代替候補（Sequence Group）」として組み合わせたものです。たとえば「まず直接顧客配賦から在庫を消費し、足りなければ販売チャネル全体配賦から補完する」という階層的な消費戦略を定義できます。
後方・前方消費（Backward / Forward Consumption）：配賦量の消費を、要求日が含まれる期間の前後何期間まで遡って（後方消費）あるいは先行して（前方消費）探索するかを定義します。たとえば「後方1期間・前方4期間」と設定すると、直前月の余剰配賦と翌4ヵ月の配賦をまとめて消費の対象とします。
【数値例】月次管理の製品XでCVC「顧客A向け」に配賦量が10月=100個・11月=120個と設定されており、後方消費=1期間・前方消費=2期間と設定した場合を考えます。顧客Aが10月15日付けで150個の受注を入れた場合、システムは10月枠（100個）に加えて前方消費で11月枠から50個を先行消費し、計150個の確認を生成します。このとき11月の残配賦量は70個になり、翌月の顧客A向け受注は70個しか許可されません。前方消費期間が長すぎると将来の配賦枠を食い潰すリスクがあるため、業種・製品ライフサイクルに応じた慎重な設計が求められます。季節性の強い製品では前方消費=0（当月枠のみ）に設定し、年末商戦前に配賦を集中管理するアプローチも一般的です。
PALを実際に設定・運用する際の操作フローを示す。設定はSAP Fioriアプリ群（Configure Product Allocation / Manage Product Allocation Sequences / Manage Product Allocation Planning Data）を通じて行います。
STEP 1 — 配賦オブジェクトの作成（Configure Product Allocation）：まず配賦オブジェクトを作成します。「このオブジェクトでは販売組織・流通チャネル・得意先番号という3つの特性を使って配賦量を管理する」という定義を行い、各特性の並び順（上位から照合する順序）を設定します。
STEP 2 — 計画データの入力（Manage Product Allocation Planning Data）：作成した配賦オブジェクトに対して、CVC別・期間別の配賦数量を入力します。たとえば「販売組織0001・流通チャネル01・顧客A → 10月:100EA、11月:80EA、12月:120EA」という時系列データを設定します。データ量が多い場合はExcelテンプレートのアップロード機能を活用します。
STEP 3 — 配賦シーケンスの設定（Manage Product Allocation Sequences）：配賦オブジェクトをどの順序・条件で消費するかの「シーケンス」を定義します。後方消費期間=1、前方消費期間=4などのパラメーターを設定します。
STEP 4 — 品目への割当（Assign Product to Product Allocation）：品目・プラントと配賦シーケンスを紐付けます。これにより、その品目への受注があった際にPALチェックが自動的に実行されるようになります。
受注入力時のPALチェック結果は「確認（Confirmations）」と「消費（Consumptions）」の二画面で確認できます。どのCVC・どの期間の配賦枠からいくつ消費されたかがリアルタイムで追跡できるため、配賦の残量管理と顧客別の充足状況把握が可能となります。
代替ベース確認（Alternative-Based Confirmation：ABC）は、要求された品目・拠点で在庫が確保できない場合に、代替製品・代替拠点・代替保管場所を自動的に探索し、最も適切な代替確認を生成するaATPの機能です。
ABCが解決する問題は「0回答（ゼロコンファメーション）の排除」です。倉庫Aに在庫がなくても、倉庫Bには在庫がある。製品Aが欠品でも、後継機種の製品Bは在庫がある。こういった場合に、単純に「確認不可」と返すのではなく、代替オプションを自動探索して顧客に最善の選択肢を提案できることが、ABCの本質的な価値です。
ABCによる代替探索は固定的な順序ではなく、「評価属性（Rating Attributes）」と「ハード制約（Hard Constraints）」の組み合わせで定義された「最適化目標」に従って動的に実行されます。この点が、単なる「優先順位リストに従った代替探索」との決定的な違いです。
aATPのABCが対応する代替の種類は以下の三種類です。
製品代替（Product Substitution）：要求品目が欠品の場合に、代替品目のマスタデータ（代替品グラフ）に基づいて代替品を探索します。製品の後継機種（Supercession）への代替や、同等スペックの別SKUへの代替が含まれます。たとえば「製品A_V1が在庫切れ → 代替マスタに従い後継品A_V2を探索 → A_V2が在庫あり → A_V2で確認を生成」という流れです。
拠点代替（Plant Substitution）：要求拠点で在庫が確保できない場合に、代替拠点を探索します。「全プラント検索モード」（システムが在庫を持つ全プラントを候補とする）と「代替マスタモード」（事前設定した代替拠点リストを参照する）の二つが選択可能です。拠点代替の結果は、メイン注文明細の「サブアイテム（Subitem）」として受注に取り込まれます。
保管場所代替（Storage Location Substitution）：同一プラント内の複数保管場所を代替候補として探索します。特定保管場所が入荷検査中の場合に他の保管場所から出荷するといったユースケースに対応します。
ABCの最大の特徴は、代替候補の優先順位が「評価属性（Rating Attributes）」によって動的に決まる点です。主要な評価属性を示します。
最大確認率（Maximum Confirmation Ratio）：できる限り高い確認率（要求数量に対する確認数量の割合）を達成することを目指します。
最小遅延（Minimum Delay）：できる限り早い確認日付を優先します。
最小代替数（Minimum Number of Substitutes）：できる限り少ない代替品・代替拠点の組み合わせで確認を生成することを目指します（シンプルな出荷作業のため）。
最小シーケンス番号（Minimum Sequence Number）：代替マスタで設定した優先順位の低い代替品よりも、優先順位の高い代替品を優先します。
「ハード制約（Hard Constraints）」は、それを満たさない確認は生成しないというルールです。たとえば「最大遅延60日（Maximum Delay 60 days）」というハード制約を設定すると、60日を超えて遅延する確認は代替候補に含まれません。「最小確認率50%（Minimum Confirmation Ratio 50%）」であれば、要求数量の50%未満しか確認できない場合は確認自体を生成しません（0確認）。
評価属性とハード制約の組み合わせを「代替決定（Alternative Determination）」として定義し、得意先属性や販売チャネルなどの特性値との組み合わせ（「代替制御：Alternative Control」）で特定の受注に適用するABCロジックを決定します。重要顧客向けには「納期遅延ゼロ・確認率最大」を目指すABC設定を、一般顧客向けには「在庫効率優先」の設定を使い分けるというアプローチが実務では広く採用されます。
ABCは「代替決定（Alternative Determination）」という設定オブジェクトを中心に構成されます。SAP Fioriアプリ「Configure Alternative-Based Confirmation」で設定します。
代替制御（Alternative Control）の定義：どの特性値の組み合わせにどのABC動作を適用するかを設定します。たとえば「販売組織=1000かつ得意先優先度クラス=1（VIP顧客）」に対して「最大確認率・最小遅延優先、ハード制約：最大遅延30日」を設定し、一般顧客には「在庫効率優先・最大遅延60日」を割り当てるといった差別化設定が可能です。
評価プロファイル（Rating Profile）の設定：評価属性（最大確認率・最小遅延・最小代替数・最小シーケンス番号）の重みを数値で定義します。たとえば「最大確認率：ウェイト80、最小遅延：ウェイト20」と設定すると、多少遅延しても高確認率の代替を優先する動作になります。数値は0〜100の範囲で設定し、合計100になるよう設定するのが基本です。
製品代替グラフ（Product Substitution Graph）の設定：品目マスタのカスタム設定で「後継品マスタ（Successor Material）」を定義します。代替品グラフはツリー構造で設定でき、第一代替→第二代替→第三代替という順で探索されます。シーケンス番号（Sequence Number）が小さいものほど優先的に探索されます。
拠点代替リスト（Plant Substitution）の設定：品目・拠点の組み合わせに対して代替拠点を優先順序付きで登録します。全プラント検索モードを使用する場合はこの設定は不要ですが、物流コスト・輸送日数の考慮から特定拠点セットに限定した探索を行う場合は代替拠点リストの設定が必要です。
受注入力時にABCが動作するとき、SAP Fioriの「受注確認レビュー（Review Availability Check Result）」画面に代替確認の結果が表示されます。得意先希望の品目・拠点での確認結果と、ABCが生成した代替候補が並べて表示され、担当者は代替案を選択するか、元の製品・拠点への確認不可として処理するかを判断できます。この「提案→担当者の確認判断」というUXが、ABCの自動化と担当者の裁量を適切に組み合わせる設計思想を反映しています。
供給保護（Supply Protection：SUP）は、特定の顧客グループ・販売チャネル・地域に対して優先供給枠を設定し、その枠を他の需要からシステムが自動的に守る機能です。在庫が逼迫している局面でも、保護対象の顧客には最低限の供給が保証されます。
供給保護が解決する問題は「暗黙の約束の制度化」です。多くの企業では「A顧客は最優先」「特定チャネルは在庫を確保」という方針を持ちながらも、それがシステムで強制されておらず、現場の受注処理担当者の判断・経験に依存していました。供給保護はこの「暗黙の優先管理」を、明示的な設定値としてシステムに落とし込み、担当者の経験に依存することなく一貫して実行します。
供給保護には「コア保護（Core Protection）」と「優先度付き保護（Prioritized Protection）」の二つの方式があります。
コア保護（水平保護）は厳格な方式です。設定した保護量を、それ以外のすべての需要から平等に保護します。どの需要も、保護された数量を侵食することはできません。たとえば「プラント0001の製品Xについて、直販チャネル向けに100個を常時保護する」と設定すると、その100個は卸売チャネルの受注がいくら入っても使われません。
優先度付き保護（垂直保護）はより柔軟な方式です。複数の保護サブグループを優先度付きで定義し、「優先度1のグループが保護量を消費した後に優先度2のグループが残量を消費できる」という階層的な保護構造を作ります。たとえば「優先度1：直販A顧客（50個保護）」→「優先度2：直販B顧客（追加30個まで保護）」という設定が可能です。コア保護より柔軟に供給を配分しながら、高優先度顧客への供給は確実に守るという設計です。
供給保護はSAP Fioriアプリ「Manage Supply Protection」で設定・管理します。主要な設定項目を示す。
供給保護オブジェクト（Supply Protection Object）：品目・プラントの組み合わせごとに作成します。各オブジェクトには「計画期間（Planning Horizon）」と「特性（得意先、販売組織、流通チャネル等）」が設定され、どの顧客属性の組み合わせに対して保護を適用するかが定義されます。
タイムバケット（Time Buckets）：保護数量を時期別に管理するための時間単位を設定します。標準は週次または月次ですが、特定イベント（季節需要ピーク・年末商戦等）に対しては任意の期間幅でバケットを定義することも可能です。保護オブジェクトの計画終了日を過ぎると、在庫確認への影響がなくなります。
保護数量の入力：各タイムバケット・各CVCに対して保護数量を設定します。たとえば「10月第1週：優先顧客A向け50個、10月第2週：60個」というような時系列での設定が可能です。供給保護データはCSV/Excelファイルのアップロードで一括入力もできます。
供給保護とBOPの連携：BOPの実行時、供給保護は「高優先度」として扱われます。BOP実行中にWin/Gain/Redistributeなどの確認戦略が適用される際も、保護された数量は常に優先的に保護対象顧客向けに確保されます。
在庫が確保できる日付が決まったとしても、その在庫を顧客に届けるまでには「ピッキング・梱包・輸送計画・輸送」という複数の時間が必要です。ATPスケジューリングは、これらのリードタイムを考慮した上で、顧客に提示する「実現可能な納品日（Confirmed Delivery Date）」を計算する機能です。
スケジューリングで考慮されるリードタイムの要素には、輸送計画日（Transportation Planning Date）・積み込み日（Loading Date）・ピッキング・梱包時間（Pick/Pack Time）・輸送日数（Transit Time）が含まれます。これらの時間は、配送ルート・輸送手段・得意先の地域などのマスタデータから自動的に参照されます。
バックワードスケジューリングで計算した材料有効在庫日が過去になってしまう（在庫は今あるが今日出荷しても間に合わない）場合、システムはフォワードスケジューリングに切り替え、本日から出荷準備を開始した場合の最短納品日を計算します。「確認可能だが希望日には届かない」ケースで、現実的な代替納品日を自動計算して提示できることが、ATPスケジューリングの実務的な価値です。
供給割当（Supply Assignment：ARun）は、確認済みの需要（受注）に対して、具体的な在庫・入庫を物理的に紐付ける機能です。PACやBOPで生成された「確認」は、どの在庫や入庫からの供給かが確定していない「軟確認（Soft Confirmation）」の状態にあります。供給割当はこの軟確認を「どの製造指図・どの購買発注・どの在庫バッチからの供給か」を明示的に紐付けた「硬確認（Hard Assignment）」に変換します。
供給割当が重要になるのは、在庫が逼迫している局面で「誰の注文に、この入荷を使うか」を能動的に決定する必要があるときです。BOPが「優先度に従って確認を再配分する」ソフト的な調整であるのに対し、供給割当は「この受注にはこのバッチ在庫を充てる」という物理的な確定です。一度割り当てられた供給は他の需要に使用されることがなくなるため、重要顧客向けの供給を出荷直前まで確実に確保することができます。
供給割当はSAP Fioriアプリ「Analyze Supply and Demand（需要と供給の分析）」と「Execute Supply Assignment（供給割当の実行）」を通じて運用します。
ソート基準（Sort Criteria）：需要をどの優先度で並べるかを定義します。得意先優先度クラス・製品の利益率・確認リードタイム余裕日数など、複数の属性を重みづけして指定できます。
供給ソート基準：どの在庫・入庫を優先して需要に割り当てるかを定義します。有効期限の早い在庫（FEFO：First Expired First Out）を優先する、特定のバッチを特定の顧客向けに優先するといった設定が可能です。
割当ホライゾン（Assignment Horizon）：何日先までの需要・供給を割当の対象とするかを定義します。通常は出荷予定日から7〜14日先を対象とし、出荷直前の確実な供給確保に焦点を当てます。
シミュレーションモード：BOPと同様に、実際にデータを更新する前にシミュレーション実行が可能です。「この条件で割当を実行したとき、誰に何を割り当てられるか」を事前確認した上で本番更新を判断します。
aATPが旧世代のgATP（APO）と本質的に異なる技術的特長は「S/4HANAへのネイティブ実装」にあります。APO gATPはS/4HANAとは独立したシステムで稼働しており、S/4HANAとの間でリアルタイムデータ同期（CIF：Core Interface）が必要でした。この同期の遅延は、在庫情報の「鮮度」に直接影響し、在庫の実態と異なる古い情報に基づく確認を生成するリスクを常に抱えていました。
aATPはS/4HANAのデータモデルをそのまま参照します。受注・在庫・製造指図・購買発注のデータはS/4HANAのデータベースに一元格納されており、aATPはそれをHANAインメモリ計算で直接処理します。「計算のためにデータをコピーする」工程がないため、常に最新のトランザクションデータに基づくATPチェックが実行されます。これが「リアルタイム確認」の技術的な根拠です。
aATPの操作は、SAP Fioriベースのアプリ群を通じて行います。受注担当者・受注管理者（Order Fulfillment Manager）がaATPのコア業務で使用する主要アプリを以下に示します。
「配賦の確認結果のレビュー（Review Availability Check Result）」：PACの実行結果を確認・調整するためのUIです。確認提案・代替提案が一覧表示され、担当者が手動で選択・調整できます。
「納品のリリース（Release for Delivery）」：出荷前の最終確認調整を行うFioriアプリです。緊急顧客からのエスカレーションに対応して在庫の手動再配分を行う際に使用します。変更の影響が即座にシミュレーションで確認でき、過剰確認を防止する機能を持ちます。
「製品配賦概要（Product Allocation Overview）」：配賦の消費状況を概要レベルで確認するダッシュボードアプリです。どの期間のどのCVCが「余裕あり」「ひっ迫」「超過」の状態にあるかを色分けで把握できます。
「BOP実行の監視（Monitor BOP Run）」：BOPの実行結果を品目・得意先・確認戦略別に確認するモニタリングアプリです。BOP前後での確認状況の変化を追跡し、想定外の確認変更がないかを確認できます。
aATPのPAL・ABC・供給保護・BOPは、いずれも「得意先・販売組織・品目属性」などの特性（Characteristic）に基づいてルールを定義します。これらの機能が参照する特性の定義を管理するのが「特性カタログ（Characteristic Catalog）」です。
特性カタログはaATPの設計基盤です。「PALでは販売組織・流通チャネル・得意先番号を特性として使用する」「BOPでは得意先優先度クラスを使用する」という特性の選択をカタログとして管理します。このカタログを変更することで、各機能が参照する特性を柔軟に追加・変更できます。aATPの導入プロジェクトにおいて、特性カタログの設計は最初に固める重要な設計判断のひとつです。なぜなら、一度稼働した後に特性カタログを変更することは、配賦データや供給保護オブジェクト等の既存設定への影響が大きく、変更コストが高くなるからです。
aATPの設定はSAP S/4HANAのCustomizing（SPRO）で管理されます。主要機能のSPROパスを把握しておくことは、導入・保守における設定変更の効率を大きく左右します。
ATPチェック全般（PAC設定）：「SD → 基本機能 → 有効在庫チェックおよび所要量転送（Availability Check and Transfer of Requirements）」配下。チェッキングルール・チェッキンググループ・確認スコープの定義はすべてここで行います。品目ごとのチェッキンググループ割当は品目マスタMRP 3ビューの「ATPチェック」フィールドで設定します。
aATP全般：「SD → Advanced Available-to-Promise」配下に各機能のサブフォルダが格納されています。新規S/4HANA環境ではこの配下の設定が空の状態から始まり、導入チームが各機能ごとに設定を積み上げる形になります。
BOPバリアントの定義：「... → Backorder Processing → Define BOP Variant」。BOPセグメント（対象品目・拠点の絞り込み）・確認戦略（Win/Gain/Redistribute/Fill）・優先度属性の重みを一つのバリアントとして登録します。実行スケジュールはSAP FioriのジョブスケジューラまたはトランザクションSM36（バックグラウンドジョブ定義）から設定し、BOPプログラム「/SAPATP/BOP」をジョブとして登録します。
製品配賦オブジェクトの定義：「... → Product Allocation → Define Product Allocation Objects」。使用する特性の組み合わせ・チェック日付タイプ（受注日 / 要求納品日 / 材料有効在庫日のいずれかを指定）・配賦数量の単位を設定します。チェック日付タイプの選択は業種ごとに重要な設計判断です。受注日ベースは「今月受注した分だけを今月枠から消費する」挙動となり、納品日ベースは「今月に納品が必要な受注を今月枠から消費する」挙動になります。
ATPスケジューリングリードタイム：「... → Scheduling → Define Scheduling Types」。ピック梱包時間（Pick/Pack Time）・積込時間（Loading Time）・輸送リードタイムのデフォルト値はここで定義します。品目・出荷ポイント・輸送ルートの組み合わせごとにオーバーライドが可能であり、多拠点・多チャネル企業では出荷ルート別の詳細設定が精度向上に直結します。
aATPは標準機能の範囲を超えた業務要件に対して、BAdI（Business Add-In）拡張ポイントとRESTful APIを提供しています。ただし拡張の使用はFit to Standard原則の逸脱を意味するため、プロジェクトの設計フェーズで「なぜ標準機能では対応できないか」を十分に検討した上で採用を決定すべきです。
BAdI「ATP Check Customization」：PACの有効在庫計算に対してカスタムロジックを挿入する拡張ポイントです。「バッチ属性（賞味期限・品質グレード）に基づく特定受注への確認制限」「特殊な顧客契約条件に基づくスコープの動的変更」などのユースケースに使用します。実装はSE19（BAdI Explorer）でアクセスし、ABAPクラスとして実装します。
BAdI「BOP Priority Calculation」：BOPの優先度計算に自社独自のスコアリングロジックを組み込む拡張ポイントです。標準の優先度属性（得意先優先度クラス・利益率など）では表現できない「複合スコアリング（顧客戦略的重要度 × 注文利益率 × 契約上のリスク）」を実装する際に使用します。
製品配賦データAPI（OData）：IBPや外部計画ツールからaATPのPAL配賦データをプログラム的に更新・参照するためのOData V4サービスです。IBP連携ではこのAPIを通じて計画配賦数量が自動転送されます。S/4HANA Cloud版ではCommunication Scenario「SAP_COM_0132」が該当し、OAuth 2.0クライアント認証情報フローで認証します。
受注ATP照会API：外部のOrder Management System（OMS）やEC基盤から直接aATPのPACを呼び出し、受注確定前に在庫確認結果を取得するためのAPIです。SAPが提供する「Business Document Processing」のOData APIを通じてオンラインATPチェックを同期呼び出しできます。応答時間は通常サブ秒（＜1秒）での返却が期待されますが、製品配賦・ABC・供給保護を含む複雑なチェックでは若干の増加があります。
「どのBAdIを使わないか」の判断もaATP設計の重要な成果物です。BAdI拡張は実装コスト・テスト工数・将来のSAPアップグレード時の改修リスクを伴います。標準機能のCustomizingパラメーターで80〜90%の要件に対応し、残余の要件のみBAdI拡張で対応するという設計原則が、長期的な保守性を確保する上で不可欠です。
aATPの機能モジュールは多岐にわたりますが、最初からすべてを導入することを目指すべきではありません。IBP同様「ビジネスの最重要課題を起点にスモールスタートで価値を実証する」という原則が、aATP展開においても不可欠です。
最も多くの企業が最初に手がけるのはPACとBOPの組み合わせです。リアルタイムの在庫確認と、需給変化に対応する定期的な優先度再配分という基本機能を確立することが、他の高度な機能（PAL・ABC・SUP）を有効に機能させるための前提となります。PACとBOPが安定稼働した後に、次の課題に合わせてPAL・ABC・供給保護を段階的に追加していくアプローチが現実的です。
現在APO gATPを稼働させている企業がaATPへ移行する際、技術的な自動移行（Migration）ツールは提供されていません。gATPで設定していたルール・配賦・グローバルATP設定を、aATpの設計思想に基づいて再設計・再設定する必要があります。
この「技術移行なし」という現実は、単なる不便ではなく再設計の好機でもあります。gATP時代に蓄積した複雑な設定・例外処理・レガシーなルールを踏襲するのではなく、aATPの標準機能（Fit to Standard）を最大限に活用した、よりシンプルで保守性の高いATPプロセスを設計し直すことができます。「技術移行できないからこそ、業務プロセスを見直せる」という視点で移行プロジェクトに臨むことが、長期的な運用コスト削減につながります。
aATpの展開において、IBPとの連携設計は重要な戦略的選択です。IBPで策定した製品配賦計画（どの販売チャネル・顧客に何個割り当てるか）をaATpのPALに取り込むAPIが提供されており、これを活用することで「計画で決めたことが受注処理で確実に守られる」仕組みが実現します。
しかしこの連携を有効に機能させるためには、IBPの配賦計画の粒度（品目・販売組織・得意先の単位）とaATPの特性カタログの設計が整合していることが前提条件となります。IBP導入とaATP導入を別々のプロジェクトで進める場合、後から連携しようとした時に特性の定義が不整合で再設計が必要になるというケースが実際に多く発生しています。IBPとaATPを同時期に導入する場合は、設計フェーズの最初から両者のデータモデルの整合性を確保することが、プロジェクト成功の重要な要件に他なりません。
aATPが正しく機能したとき、組織に生じる最も直接的な変化は「約束した納期が守られる率（On-Time Delivery：OTD）」の改善です。従来の基本ATPでは「確認した日付に出荷できなかった」「確認数量より少ない数しか出荷できなかった」という乖離が日常的に発生していました。aATPのリアルタイム在庫確認・優先度に基づく配分・物流時間を考慮したスケジューリングが組み合わさることで、確認と実出荷の乖離は大幅に縮小します。
OTDの改善は顧客満足度の向上に直結し、長期的には顧客ロイヤルティの向上・解約率の低下・単価交渉力の強化という形で経営成果に結びつきます。「約束を守る会社」という評価が、競争優位の根幹となる時代においては、aATPのような注文約束基盤への投資は、単なるシステム投資ではなく経営戦略上の不可欠なインフラ整備です。
aATPのPAL・BOP・供給保護が連携することで、在庫の配分が「先着順」から「ビジネス戦略に基づく配分」へと変わります。この変化が経営にもたらす含意は大きいです。
希少な在庫を利益貢献度の高い顧客・製品・チャネルに優先的に配分することで、同じ在庫水準でもより高い売上・利益を実現できます。また「重要顧客に供給できなかった」という経営上の最悪のシナリオ──大口顧客からのクレーム・違約金・取引解消リスク──を、システムの設定で予防できることは、リスク管理の観点からも重要な価値です。
本稿を通じて解説してきたaATPの本質を、最後に一言で総括します。aATPとは、受注が入った瞬間に「誰に、何を、いつ、どこから届けるか」を最適化し、その約束を確実に実行するための経営の仕組みです。
PAC・BOP・PAL・ABC・供給保護・供給割当という各モジュールは、それぞれ独立した機能に見えますが、すべてが「注文約束の精度と公正さを高め、在庫という経営資源を最大限に有効活用する」という一つの目的のために連携しています。その連携が正しく機能するとき、aATPは単なるシステム機能を超えて、企業の「約束する力」を競争優位の源泉へと変える経営インフラとなります。
そしてIBPとaATPが正しく連携したとき──計画（IBP）が立てた在庫配分の意図を、実行（aATP）が受注処理において忠実に反映する連携が実現したとき──企業はサプライチェーン全体を一つの統合されたビジネス運営の仕組みとして機能させることができます。その可能性を最大限に引き出すために、本稿が一助となれば幸いです。
本章では、aATPの各機能モジュールを実際に活用した企業事例を紹介します。各事例は公表されている複数の情報源（SAP PRESS、業界専門誌等）をもとに構成したものです。企業名は匿名としていますが、いずれも実在する企業において記録された導入効果に基づいています。
グローバル半導体メーカーA社は、世界的なチップ供給不足（2020年代の半導体ショートウェーブ）のさなか、深刻な受注管理課題に直面していました。OEMの自動車メーカーへの供給継続は契約上も戦略上も最優先事項でしたが、従来のATPの先着順処理では汎用品を取り扱うディストリビューターの注文が先に処理され、OEM向け在庫が枯渇するケースが頻発していました。現場のオペレーターが手作業でOEM向けに在庫を「手押さえ」していたものの、属人的・非効率であり、ミスも発生していました。
A社はSAP S/4HANA移行に合わせてaATPの製品配賦（PAL）を導入しました。「得意先グループ（Customer Group）」を特性カタログの主軸特性として設定し、OEM顧客グループ・Tier1ディストリビューター・一般流通の三階層を特性値として定義。各チップ品番の週次生産予定に対して、CVC別の配賦数量を製品配賦データとして毎週更新する運用を確立しました。IBP for Response & Supplyと連携させ、IBPで算定した需給調整結果をPALデータとして自動取り込みする連携も実装しています。
PAL稼働後、OEM向け確認率は大幅に改善しました。「先着順」によるOEM在庫枯渇がシステムレベルで防止され、OEM顧客からの納期クレームが激減しました。在庫の手動調整に費やしていた受注管理スタッフの作業時間が削減され、その工数をより付加価値の高いサプライヤー協議・需給シミュレーションへ振り向けられるようになりました。「在庫配賦の根拠が可視化・ルール化されたことで、顧客への説明が格段にやりやすくなった」という定性的な評価もあります。
産業用電子機器メーカーB社は、民間向け製品と政府・防衛省関連契約の両方を抱えていました。生産能力の逼迫時には「政府契約を最優先」という社内方針があったものの、これを受注システムに反映する仕組みがなく、民間顧客の受注が先に処理されて生産枠を占有するケースが継続していました。政府契約違反は違約金・契約解除のリスクがあり、経営上の最優先事項でしたが、ITシステムがそれを保証できていませんでした。
B社はaATpのバックオーダー処理（BOP）を導入しました。「得意先分類（Customer Classification）」特性に「政府契約=GVT / 防衛省=DEF / 民間優良=PREM / 一般=STD」という値を設定。BOPバリアントでは「Redistribute（再配分）」戦略を採用し、実行時に低優先度顧客（STD/PREM）の確認を必要に応じてキャンセルして政府・防衛契約顧客（GVT/DEF）に再配分するロジックを設定しました。BOPは毎夜23時にスケジュール実行し、翌朝の業務開始前に優先度に基づく再確認を完了させる運用にしました。
BOP稼働後、政府契約の納期遵守率が大幅に向上しました。担当者の手動介入なしに、生産能力が逼迫しても政府契約が常に優先的に確認される状態が実現しました。一般顧客への確認変更（一部キャンセル・遅延）は増えましたが、事前通知の仕組みとセットで運用することで顧客への丁寧な対応が可能となりました。「政府契約リスクがシステムで管理されるようになり、経営層が安心できるようになった」という評価が寄せられています。
消費者向け電子機器の多チャネル小売業者C社は、国内4か所の配送センター（DC）と2か所の直販倉庫を保有していました。従来のATPは各倉庫を個別にチェックするのみで、「主力DCの在庫が切れた場合に他DCを自動的に代替として提案する」仕組みがありませんでした。EC注文ピーク時（年末商戦・セール期間等）に主力DCの在庫が枯渇すると、大量の受注が「確認不可」として処理され、機会損失が発生していました。他DCには在庫があるにも関わらず、それを活用できていなかったのです。
C社はABCの拠点代替（Plant Substitution）機能を導入しました。各主力DCに対して代替DC・直販倉庫をシーケンス番号（輸送コスト・顧客住所との距離を考慮した優先順位）付きで登録。評価プロファイルでは「最大確認率（ウェイト70）・最小遅延（ウェイト30）」を採用し、多少輸送コストがかかっても確認率を最優先する方針を反映しました。ハード制約として「最大遅延3日（通常配送サービスレベル）」を設定し、3日以上遅延する代替確認は提案しないよう制御しました。
ABC稼働後、ピーク期間中の受注確認率が大幅に向上しました。主力DCの在庫切れによる「確認不可」がほぼ解消され、代替DCからの出荷で顧客の納期要求を満たせるようになりました。「システムが自動的に最適倉庫を選んでくれるようになり、受注担当者が手動で倉庫在庫を確認して転送依頼を出す作業がなくなった」という運用改善も実現しています。物流コストの若干の増加はあったものの、機会損失の削減・顧客満足度向上の効果がそれを大幅に上回りました。
別の半導体メーカーD社（アナログ半導体・センサー製品領域）も、OEM顧客へのコミットメントと一般ディストリビューターへの供給の間でバランスを取ることに苦慮していました。A社との違いは、D社が製品ラインごとに「OEM向けに最低X個は必ず確保」という明示的な契約上のコミットメントを顧客と締結していた点です。この数値コミットメントをシステムで強制する必要がありましたが、従来のATPにはその仕組みがありませんでした。
D社はaATPの供給保護（Supply Protection）コア保護方式を導入しました。契約上のOEMコミットメント数量を品目・プラント・OEM顧客グループの組み合わせで「保護数量」として設定。特性カタログには「得意先グループ（OEM_PRIO / DIST_A / DIST_B）」を設定し、コア保護オブジェクトはOEM_PRIOのCVCに対してのみ設定することで、保護枠への確認は自動的にOEM顧客からの受注のみに制限されました。タイムバケットは月次で設定し、月ごとに更新される生産計画に連動して保護数量を見直す運用を確立しました。
供給保護稼働後、OEM向けの契約コミットメント数量が常時確保される状態が実現しました。ディストリビューターからの大口注文が殺到しても、保護された枠はOEM以外の需要には絶対に割り当てられないため、OEM顧客との契約違反リスクがほぼゼロになりました。「月次の保護数量設定という定型業務はありますが、それ以外の在庫管理の手間が大幅に減った。むしろ数値が可視化されたことで、どのOEMとの関係が在庫を最も圧迫しているかの経営議論ができるようになった」という評価があります。
以上の4事例は、aATPの機能が「設定値」という形で経営方針をシステムに組み込み、現場の判断・手作業・属人化に依存せずにその方針を実行し続けるという、aATPの本質的な価値を示しています。どの事例においても共通しているのは「在庫配賦のルールを明文化し、それをシステムが自動的かつ一貫して実行することで、経営リスクが管理可能になった」という点です。
以上