Written by Nishiyama — Paddy & Water Inc. / Supply Chain

(aATP) Explained

Designing and Implementing S/4HANA-Native Order Fulfillment

June 2026

Introduction: Why Understanding aATP Matters Now

We have entered an era in which companies that can answer the question “When, how many units, and from where can the ordered goods be shipped?” immediately and accurately are the ones customers continue to choose. In today’s world, where orders arrive instantly via e-commerce sites and EDI, a response of “We will get back to you on the delivery date later” is directly linked to the risk of losing customers.

SAP Advanced Available-to-Promise (hereafter, aATP) is SAP S/4HANA’s answer to this challenge of “Order Promising.” Whereas conventional ATP (Available-to-Promise stock checking) was limited to simple inventory matching, aATP generates the optimal order confirmation in real time by comprehensively considering inventory, production capacity, transportation constraints, customer priority, and even substitute product stock.

This article explains each functional module that makes up aATP from three perspectives: “why it is needed,” “what it solves,” and “how to configure and operate it.” Understanding that IBP is responsible for the domain of “planning” while aATP is responsible for the domain of “promising” is the first starting point for reading this article.

1. What Is aATP: The “Order Promising” Revolution

Definition of Advanced ATP: An “Optimal Confirmation” Engine Beyond Stock Checking

SAP Advanced Available-to-Promise (aATP) is an advanced stock-availability-checking and order-promising function for order fulfillment that runs natively on SAP S/4HANA. At the moment an order is placed, it calculates in real time “which item, how many units, when, and from where can be supplied,” and immediately presents the customer with a feasible confirmation date and quantity (Confirmation).

Compared with the ATP functionality traditionally offered by SAP ERP and SAP APO (so-called “basic ATP” or “gATP”), aATP’s greatest differentiator lies in the breadth of what it takes into account when generating a confirmation. Whereas basic ATP was limited to “simple stock allocation based on current inventory and planned future receipts,” aATP generates confirmations that comprehensively consider Product Allocation, Supply Protection, alternative plants, alternative products, production capacity, and transportation scheduling.

To borrow the words of SAP’s official materials, aATP is a solution that “delivers accurate and reliable order promising dates while honoring business priorities and profitability targets, taking into account all relevant supply chain constraints.” This is not merely an enhancement of system functionality; it represents a managerial transformation that turns a company’s very “promise-making capability” into a source of competitive advantage.

The Evolution of ATP: From Basic ATP to aATP

Tracing the historical evolution of ATP, we follow a lineage from “basic ATP (Digital Core ATP)” in the SAP ERP era, to “gATP (Global ATP)” in the SAP APO era, to “aATP” in the SAP S/4HANA era.

Basic ATP is a simple mechanism that allocates stock based on time-series data of demand and supply (the ATP time series). APO gATP, on the other hand, had advanced capabilities such as product allocation, multi-level ATP based on bill-of-materials (BOM) explosion, and rule-based alternative search, but because it ran on a system separate from S/4HANA, data synchronization and latency were challenges. aATP is a reimplementation of these functions natively within S/4HANA. No functional migration tool from APO gATP to aATP is provided, so companies must design and implement it anew.

The difference between S/4HANA’s Digital Core ATP and aATP is also important. Digital Core ATP provides only the Product Availability Check (PAC) and Backorder Processing (BOP), whereas aATP additionally provides advanced capabilities such as Product Allocation, Alternative-Based Confirmation, Supply Protection, Supply Assignment, and transportation scheduling. It is not the case that “implementing SAP S/4HANA automatically makes aATP available” — one must recognize that aATP is a set of functions requiring additional design, configuration, and licensing.

The Relationship Between IBP and aATP: Dividing Roles Between “Planning” and “Promising”

Understanding what roles IBP and aATP each play within SAP’s overall supply chain solution landscape is essential to correctly evaluating both solutions.

IBP is responsible for the domain of “Plan.” It plans demand, supply, and inventory in an integrated manner months to years into the future, supporting mid- to long-term decisions about where and how much to allocate resources. aATP, on the other hand, is responsible for the domain of “Promise.” The moment an order actually arrives, based on planned inventory and supply capacity, it promises the customer in real time “when, how many, and from where this order can be delivered.”

An integration exists that brings product allocation data planned in IBP (allocation quantities by sales channel and by customer) into aATP’s Product Allocation function, and it is important that planning and promising are connected through a consistent set of figures. This integration — where “aATP applies the allocation plan decided in IBP to actual orders” — enables the entire supply chain to function as a control tower.

2. Why aATP Is Needed Now: The Limits of Legacy ATP and Market Demands

Challenges Facing Order Promising Today

The challenges facing the front lines of order promising can be organized into four broad categories.

• Demand for real-time confirmation: In an era where orders arrive via e-commerce sites and EDI, customers expect an almost instantaneous delivery-date response. A response of “we will reply the next business day” loses the customer’s purchasing decision opportunity.

• Allocation based on business priority and profitability: When inventory is limited, deciding “which customer’s order to prioritize” becomes a management issue. However, conventional ATP is based fundamentally on “first come, first served,” making it difficult to achieve strategic customer priority management through the system.

• Handling complex supply networks: Single-plant, single-warehouse structures have become the minority, and there is a need to instantly identify the optimal source of supply from a complex network in which multiple locations, multiple substitute products, and multiple transportation routes are intertwined.

• Divergence between planning and promising: Many companies experience the problem that sales plans and product allocation plans formulated in IBP and elsewhere become hollow, unenforced formalities because they are not honored in actual order handling. Even if the plan decides to “reserve 100 units for Customer A,” if that allocation is not honored on the order-processing front line, the plan itself loses its meaning.

Three Problems Basic ATP Cannot Solve

The following three issues are cited as problems that standard SAP ERP basic ATP cannot structurally solve.

The first is the “trap of first-come, first-served.” Basic ATP allocates stock chronologically on a first-come, first-served basis. As a result, orders from strategically less important customers are processed first, depleting the stock meant for important customers, and a “reversal phenomenon” occurs routinely in which large, important customer orders arriving later cannot be confirmed. This problem is more severe the tighter inventory becomes.

The second is the “limitation of a single location.” Basic ATP, in principle, performs its check against the stock of a single location. Flexible alternative confirmation such as “if Plant A has no stock, look at Plant B” or “if product C is unavailable, propose substitute product D” cannot be achieved without configuration. If there is no stock for the combination of product, quantity, and date the customer ordered, the system can only return a simple “cannot confirm” result.

The third is “disconnection from planning.” Basic ATP is a stock-allocation tool used at the point of individual order processing, and it has no dynamic linkage with sales plans or allocation plans. Without a mechanism that forcibly reflects the product allocation plan formulated in IBP into order handling, the plan remains mere “reference information,” and front-line order processing continues to ignore it, remaining a “first-come, first-served” free-for-all.

aATP provides a systematic answer to these three problems through a set of functions: Product Allocation (PAL), Alternative-Based Confirmation (ABC), Backorder Processing (BOP), and Supply Protection.

3. The Big Picture of aATP: Functional Module Structure

Functional Modules That Make Up aATP

aATP is not a single function but a solution composed of multiple functional modules. Each module functions independently, but combining them produces synergistic effects. The main modules are as follows.

• Product Availability Check (PAC): The real-time stock-confirmation module that underlies all functions. At the time of order entry, it matches inventory and planned future receipts to calculate the confirmable quantity and date.

• Backorder Processing (BOP): A batch-processing function that, whenever supply-and-demand conditions change, bulk-re-confirms previously confirmed orders according to priority rules.

• Product Allocation (PAL): An “allocation management” function that pre-allocates stock by sales channel and customer segment, and matches orders against that allotted quota.

• Alternative-Based Confirmation (ABC): A function that, when stock cannot be secured for the requested item or location, automatically searches for substitute products, alternative plants, and alternative storage locations to generate the optimal confirmation.

• Supply Protection (SUP): A function that sets a priority supply quota for specific customer groups or sales channels, protecting supply to priority customers.

• Supply Assignment (ARun): A function that analyzes supply-and-demand conditions in bulk and assigns physical stock and receipts to the most important demand, ensuring that supply is reliably secured through to shipment.

• ATP Scheduling: A function that calculates a feasible delivery date, taking into account the transportation planning date, loading date, picking time, transportation lead time, and other factors.

The Role of Each Module in the Order Processing Flow

It is necessary to clarify how each aATP module works together throughout the flow from the moment an order arrives until delivery confirmation is completed.

The moment an order is entered, PAC is triggered and performs a stock check against the requested item, quantity, and desired date. At that point, the constraints of product allocation from PAL are applied, and confirmation is performed only within the available allocation quota based on customer and sales-channel attributes. If stock cannot meet the request, ABC searches for substitute products and alternative locations and proposes the optimal alternative confirmation. ATP Scheduling calculates the actual delivery date by working backward from the date on which stock can be secured.

BOP, on the other hand, runs as periodic batch processing, and whenever the supply-demand balance shifts due to cancellations, changes in incoming receipts, or new large orders, it recalculates existing confirmations according to priority rules. Supply Assignment (ARun) then, in the phase immediately before shipment, finalizes the physical linkage between stock and orders, making the final determination from “confirmed” to “secured.”

This entire sequence of flows is executed in real time on S/4HANA’s HANA in-memory database.

4. Product Availability Check (PAC): The Basic Mechanism of Real-Time Confirmation

What Is PAC: Viewing Stock Along a “Time Axis”

The Product Availability Check (PAC) is the module that forms the foundation of all aATP functions. The moment a customer places an order for “Item A, 100 units, wanted by date X,” it calculates in real time “when and how many units can be confirmed” in response to that request and generates a Confirmation.

The core of PAC’s calculation logic is “tracking the Cumulated Available Quantity along the time axis.” Starting from current on-hand stock, it adds planned future receipts (production orders, purchase orders, in-transit stock) and subtracts existing demand (confirmed orders, delivery instructions) to calculate the “cumulative available inventory” along the time axis. If this cumulative available inventory at the time of the requested delivery date is equal to or greater than the requested quantity, it becomes an “on-time confirmation”; if it is insufficient, the system searches for the earliest date at which the request can be satisfied.

The scope of inventory, supply, and demand considered in this calculation can be controlled through configuration. Settings such as “do not use safety stock for confirmation,” “exclude stock under quality inspection,” and “include open purchase orders” are defined in the “Scope of Availability Check” within Customizing.

Backward Scheduling and Forward Scheduling

Scheduling in PAC operates in two stages: “backward scheduling,” which works backward from the order’s requested delivery date, and “forward scheduling,” which works forward from today.

In backward scheduling, the system works backward from the customer’s Requested Delivery Date, subtracting transportation lead time, packing time, picking time, and other factors, to calculate the “Material Availability Date.” If the required quantity of stock is available as of this date, an on-time confirmation is established.

If stock cannot be secured on the Material Availability Date, the system switches to forward scheduling. Starting from today, it identifies the earliest date on which cumulative planned receipts exceed the required quantity, and recalculates the delivery date forward from there. It automatically proposes “the earliest possible date the goods can be delivered from today onward.”

Partial Confirmation is also possible. For example, if only 40 units are in stock on the requested date and the remaining 60 units are due to arrive two weeks later, a split confirmation spanning multiple dates is generated: “40 units on the requested date, 60 units two weeks later.” A UI presenting this as a “Delivery Proposal,” which lets the customer decide whether to accept it, is implemented in aATP’s SAP Fiori apps.

Temporary Quantity Assignment (TQA): A Mechanism for “Provisionally Reserving” Stock Before Saving

An important concept easily overlooked in order processing is Temporary Quantity Assignment (TQA). From the moment an order-entry clerk runs an ATP check on the order screen — even before the order is saved — stock is provisionally reserved through the TQA mechanism.

Why does this matter? In online order processing, cases where multiple operators are checking the stock of the same item simultaneously occur constantly. Without TQA, “double confirmation” can occur — in the few minutes between when Operator A checks stock and saves the order, Operator B checks and saves the same stock. To prevent this problem, TQA provisionally reserves stock the moment an ATP check is executed and excludes that quantity from other confirmations.

The standard validity period of a TQA is 8 hours. Once the order is saved, the TQA is replaced by an actual confirmation, and if the order is cancelled or discarded, the TQA is also automatically deleted. However, if processing is abnormally terminated due to a system failure or similar cause, there is a risk that a TQA remains and continues to improperly occupy stock. For this reason, aATP provides a report (ATP_TQA_PAC_DEL_DISPLAY) for checking and clearing residual TQAs, and it is recommended that administrators perform periodic maintenance using this report.

Operational View: Key PAC Configuration Parameters

The main parameters configured in Customizing to make PAC function are shown below.

• Checking Group: Set in the material master. An attribute value that controls, at the item level, “whether to perform a stock check” and “which ATP check to apply.” Items to which aATP’s advanced functions (product allocation, alternative confirmation, etc.) are to be applied must be assigned a dedicated checking group.

• Checking Rule: Defines, for each sales document type (e.g., standard order = OR, rush order = RU), the scope in which the stock check is performed. Differentiation is possible, such as including safety stock in the check for rush orders or also considering past receipts.

• Check Horizon: Defines how many days into the future planned receipts are considered for confirmation. For example, if the horizon is set to 60 days, planned receipts further than 60 days out are not used in the confirmation calculation. This prevents excessive confirmations based on “distant future receipts with low feasibility.”

• Quantity Distribution: A function that prorates the receipt quantity of a production order or planned order across the entire production period on a daily basis for use in the stock check. Turning this on allows stock to be treated as partially available even partway through the production period, improving confirmation accuracy and supply flexibility.

[Example Checking Rule Configuration] Consider a design example that assigns different checking rules to the sales document types “OR (standard order)” and “RU (urgent order).” For OR, a strict scope is applied: a check horizon of 60 days, exclusion of safety stock, exclusion of stock under quality inspection, and exclusion of stock from before the previous month. For RU, a broader scope is applied to the same item: an unlimited horizon, including up to 50% of safety stock in the confirmation, and treating up to 30% of stock under quality inspection as provisionally available. With this design, priority handling for urgent customers can be automatically achieved through the standard business flow of “selecting a sales document type,” rather than through “an order clerk manually searching for stock.” Access to the RU document type is restricted by staff position and authorization (Authorization Object), preventing abuse of urgent handling.

5. Backorder Processing (BOP): Priority Rewrites “Confirmations”

What Is BOP: Batch Reconfirmation in Response to Supply-Demand Changes

Backorder Processing (BOP) is an aATP function that batch-reevaluates previously generated order confirmations in bulk whenever supply-demand conditions change. Whereas online PAC provides real-time confirmation “at the moment a new order arrives,” BOP is a periodic reset process that performs an “optimal reallocation of all confirmations” “after the supply-demand balance has been disrupted.”

Typical scenarios that call for BOP include the following: a large order arrives from an important customer, but the confirmations of existing low-priority customers already occupy the stock, making confirmation impossible; an order is cancelled, releasing stock, which can then be reallocated to a previously unconfirmable order; or a planned receipt is delayed, making an existing confirmation infeasible. In these cases, rather than manually correcting individual orders, BOP performs systematic reconfirmation according to priority rules.

BOP Confirmation Strategies: Win, Gain, Redistribute, Fill

What confirmation result BOP generates for each demand is defined by the “Confirmation Strategy.” The standard confirmation strategy categories provided by aATP are shown below.

• Win (Preserve Priority Confirmation): Preserves the confirmation currently held by high-priority demand. Protects the orders of important customers who already have good confirmations as the “winners.”

• Gain (Acquire New Confirmation): Aims for demand that currently has no confirmation, or only an insufficient confirmation, to acquire a new confirmation from released stock.

• Redistribute (Reallocate Confirmation): Cancels confirmations from low-priority demand and reallocates them to high-priority demand. This is BOP’s most essential function of “overturning first-come, first-served.”

• Fill (Fill With Remaining Stock): Allocates the stock remaining (surplus stock) after the Win, Gain, and Redistribute processing above to demand that still lacks sufficient confirmation.

These confirmation strategies are combined with BOP segments (filtering by item group, customer group, etc.) and BOP variables (execution timing, parameters) and configured as a “BOP Variant,” which is then run on a schedule. A typical operational pattern is, for example, “run BOP for all items every day at 2:00 a.m., so that the supply-demand conditions that changed overnight are reconfirmed before the start of business the next morning.”

Operational View: Configuring and Running a BOP Variant

BOP is configured and run through the SAP Fiori apps “Configure BOP Variant” and “Schedule BOP Run.”

• Defining BOP Segments: Filters by attributes such as item, plant, customer, and sales organization to define which demand and supply are subject to BOP. For example, filtering such as “all orders for sales organization 1000” or “a specific item group only” is possible.

• Assigning Confirmation Strategies: Assigns which confirmation strategy (Win/Gain/Redistribute/Fill) to apply to each segment. It is common to differentiate by prioritizing Win for important customer groups and applying Fill for general customer groups.

• Setting Priority Attributes: Defines the attributes used to sort demand. Multiple attributes — such as customer priority class (Priority Class 1 = most important, 5 = standard), confirmation lead-time margin of an order, and product profit margin — can be ranked and combined.

• Running Simulations: Before a production update, BOP can be run in “simulation mode” to preview how confirmations will change. Results are reviewed by item and customer in the “Monitor BOP Run” app, and after confirming that reallocation is proceeding as intended, the process moves on to a production update.

Analysis of BOP run logs starts from the “Monitor BOP Run” app, and is scrutinized by item and customer using the following fields.

• Rescheduling Category: Classifies the action BOP took on each order line item. Five categories are displayed: “Gained,” “Improved,” “Worsened,” “Unchanged,” and “Cancelled.” This field allows immediate filtering to check whether important customers’ confirmations have unintentionally worsened, or whether unnecessary cancellations have occurred.

• Change in Confirmed Quantity (Before / After Confirmed Quantity): The confirmed quantities before and after the BOP run are displayed side by side at the line-item level. Rows with a negative difference are “orders whose confirmation was reduced,” and this is used to verify whether the priority design functioned as intended. This field is checked especially after applying the Redistribute strategy, to confirm that the quantities for high-priority customers increased and those for low-priority customers decreased.

• Unprocessed Demand: A list of demand for which BOP could not generate a confirmation due to insufficient stock or similar causes. When the volume of unprocessed demand is large, it is a signal not of a problem in priority design but that “the supply volume itself is falling short of the plan.” Bringing this data to weekly SCM meetings serves as a basis for decision-making with procurement and production planning.

• BOP Processing Duration: The time required for BOP to complete processing of the target segment. Processing time increases as the number of demand records processed increases. This is used as a benchmark for performance design when designing BOP segmentation (parallel execution by item group). In standard operation, completion within a few to a little over ten minutes per segment is the target, designed to fit within the overnight batch window.

6. Product Allocation (PAL): Strategic “Quota Management” for Scarce Stock

What Is Product Allocation: Controlling “Who Can Buy How Many”

Product Allocation (PAL) is a “quota management” function that pre-sets an Allocation Quantity of stock by attributes such as sales channel, customer segment, and region, and keeps stock confirmation at order time within that quota.

The problem PAL solves is clear: for popular products with scarce stock, a “hoarding problem” in which stock for other customers disappears because a specific large customer places a bulk order, and the problem that a company cannot actively control “who gets to buy how much” during seasonal demand or supply-demand tightness. PAL resolves these by forcibly applying the “sales framework” of an allocation plan to order processing.

An integration function is provided that brings the product allocation plan generated by IBP’s supply plan into aATP’s PAL via API, allowing consistency between planning and execution to be maintained. The loop of “aATP executes the allocation plan formulated by IBP” enables control across the entire supply chain.

Basic Concepts of Product Allocation: CVC, Allocation Objects, Allocation Sequences

The basic concepts that must be understood in order to design and operate PAL are organized below.

• Characteristic Value Combination (CVC): The unit that defines an allocation quantity. A CVC is identified by a combination of multiple characteristics, such as “sales organization = 0001, sales channel = 01, customer = Customer A,” and allocation quantities by period (a time series) are set against that CVC.

• Product Allocation Object: Master data that defines the combination of characteristics and the time axis. It holds the basic settings for allocation, such as “the unit of allocation quantity is EA (each), the period type is monthly, and the requested delivery date is used as the check date.”

• Product Allocation Sequence: A combination of multiple allocation objects as “alternative candidates (Sequence Group).” For example, it can define a hierarchical consumption strategy such as “first consume stock from the direct-customer allocation, and if that is insufficient, supplement from the overall sales-channel allocation.”

• Backward / Forward Consumption: Defines how many periods before (backward consumption) or after (forward consumption) the period containing the requested date the system searches when consuming the allocation quantity. For example, if set to “backward 1 period, forward 4 periods,” surplus allocation from the immediately preceding month and allocation for the following 4 months are together made subject to consumption.

[Numerical Example] Consider product X, managed monthly, where the allocation quantity for CVC “for Customer A” is set at October = 100 units and November = 120 units, with backward consumption = 1 period and forward consumption = 2 periods. If Customer A places an order for 150 units dated October 15, the system generates a confirmation for a total of 150 units by consuming, in addition to the October quota (100 units), 50 units in advance from the November quota via forward consumption. In this case, the remaining allocation for November becomes 70 units, and only 70 units of orders for Customer A will be permitted the following month. Because too long a forward consumption period risks eating into future allocation quotas, careful design according to industry and product lifecycle is required. For highly seasonal products, an approach of setting forward consumption = 0 (current-month quota only) and centrally managing allocation ahead of the year-end shopping season is also common.

Operational View: Configuring Product Allocation and Applying It to Orders

The operational flow for actually configuring and running PAL is shown below. Configuration is performed through a group of SAP Fiori apps (Configure Product Allocation / Manage Product Allocation Sequences / Manage Product Allocation Planning Data).

• STEP 1 — Create an Allocation Object (Configure Product Allocation): First, create an allocation object. Define, for example, that “this object manages allocation quantities using three characteristics: sales organization, distribution channel, and customer number,” and set the order in which each characteristic is matched (the order from highest priority).

• STEP 2 — Enter Planning Data (Manage Product Allocation Planning Data): Enter allocation quantities by CVC and by period for the created allocation object. For example, set time-series data such as “sales organization 0001, distribution channel 01, Customer A -> October: 100 EA, November: 80 EA, December: 120 EA.” When the volume of data is large, the Excel-template upload feature is used.

• STEP 3 — Configure the Allocation Sequence (Manage Product Allocation Sequences): Define the “sequence” specifying in what order and under what conditions the allocation objects are consumed. Set parameters such as backward consumption period = 1 and forward consumption period = 4.

• STEP 4 — Assign to a Product (Assign Product to Product Allocation): Link the item and plant to the allocation sequence. This causes the PAL check to be automatically executed whenever an order is placed for that item.

The results of the PAL check at order entry can be reviewed on two screens, “Confirmations” and “Consumptions.” Because how much was consumed from which CVC and which period’s allocation quota can be tracked in real time, it becomes possible to manage remaining allocation and grasp the fulfillment status by customer.

7. Alternative-Based Confirmation (ABC): Eliminating “Zero Answers” with Substitute Products and Alternative Plants

What Is ABC: Automatically Generating the Optimal Alternative Confirmation

Alternative-Based Confirmation (ABC) is an aATP function that, when stock cannot be secured for the requested item or plant, automatically searches for substitute products, alternative plants, and alternative storage locations, and generates the most appropriate alternative confirmation.

The problem ABC solves is “the elimination of zero answers (zero confirmations).” Even if Warehouse A has no stock, Warehouse B may have stock. Even if product A is out of stock, its successor product B may be in stock. In such cases, rather than simply returning “cannot confirm,” the essential value of ABC lies in its ability to automatically search for alternative options and propose the best choice to the customer.

The alternative search performed by ABC is not conducted in a fixed order, but is executed dynamically according to an “optimization objective” defined by a combination of “Rating Attributes” and “Hard Constraints.” This is the decisive difference from a simple “alternative search that follows a priority list.”

Types of Alternatives: Product Substitution, Plant Substitution, Storage Location Substitution

The three types of alternatives supported by aATP’s ABC are as follows.

• Product Substitution: When the requested item is out of stock, the system searches for substitute items based on the master data (substitution graph) of substitute items. This includes substitution with a product’s successor (Supercession) or with a different SKU of equivalent specification. For example, the flow is: “Product A_V1 is out of stock -> search for successor A_V2 per the substitution master -> A_V2 is in stock -> generate a confirmation with A_V2.”

• Plant Substitution: When stock cannot be secured at the requested plant, the system searches for an alternative plant. Two modes are selectable: “Search-All-Plants Mode” (in which the system treats all plants holding stock as candidates) and “Substitution Master Mode” (which references a pre-configured list of alternative plants). The result of plant substitution is incorporated into the order as a “Subitem” of the main order line item.

• Storage Location Substitution: Searches multiple storage locations within the same plant as alternative candidates. This addresses use cases such as shipping from another storage location when a specific storage location’s stock is undergoing incoming inspection.

Rating Attributes and Hard Constraints: Defining the Optimal Confirmation

ABC’s greatest characteristic is that the priority of alternative candidates is determined dynamically by “Rating Attributes.” The main rating attributes are shown below.

• Maximum Confirmation Ratio: Aims to achieve as high a confirmation ratio (the ratio of confirmed quantity to requested quantity) as possible.

• Minimum Delay: Prioritizes the earliest possible confirmation date.

• Minimum Number of Substitutes: Aims to generate confirmations using as few combinations of substitute products and alternative plants as possible (for simpler shipping operations).

• Minimum Sequence Number: Prioritizes substitutes with a higher priority, as set in the substitution master, over those with a lower priority.

“Hard Constraints” are rules stating that any confirmation not meeting them will not be generated. For example, setting a Hard Constraint of “Maximum Delay 60 days” excludes from alternative candidates any confirmation delayed by more than 60 days. With a “Minimum Confirmation Ratio of 50%,” if only less than 50% of the requested quantity can be confirmed, no confirmation is generated at all (a zero confirmation).

The combination of rating attributes and hard constraints is defined as an “Alternative Determination,” and the ABC logic applied to a specific order is decided through combinations with characteristic values such as customer attributes and sales channel (“Alternative Control”). An approach widely adopted in practice is to use different settings for different customer segments — an ABC setting aiming for “zero delivery delay, maximum confirmation ratio” for important customers, and a setting prioritizing “inventory efficiency” for general customers.

Operational View: Configuring ABC and How Alternative Confirmation Works

ABC is configured around the setting object called “Alternative Determination.” It is configured in the SAP Fiori app “Configure Alternative-Based Confirmation.”

• Defining Alternative Control: Sets which ABC behavior applies to which combination of characteristic values. For example, differentiated settings are possible, such as setting “prioritize maximum confirmation ratio and minimum delay, with a hard constraint of maximum delay 30 days” for “sales organization = 1000 and customer priority class = 1 (VIP customer),” while assigning “prioritize inventory efficiency, maximum delay 60 days” to general customers.

• Configuring the Rating Profile: Defines numerical weights for the rating attributes (maximum confirmation ratio, minimum delay, minimum number of substitutes, minimum sequence number). For example, setting “maximum confirmation ratio: weight 80, minimum delay: weight 20” produces behavior that prioritizes a high-confirmation-ratio alternative even at the cost of some delay. Values are set in the range of 0 to 100, and it is standard practice to set them so they sum to 100.

• Configuring the Product Substitution Graph: Defines the “Successor Material” in the custom settings of the material master. The substitution graph can be configured as a tree structure and is searched in the order first alternative -> second alternative -> third alternative. Items with a smaller sequence number are searched with higher priority.

• Configuring the Plant Substitution List: Registers alternative plants, with a priority order, for combinations of item and plant. This setting is unnecessary when using the search-all-plants mode, but is required when the search must be limited to a specific set of plants due to logistics-cost or transit-time considerations.

When ABC operates during order entry, the results of the alternative confirmation are displayed on the SAP Fiori “Review Availability Check Result” screen. The confirmation result for the customer’s requested item and plant is displayed side by side with the alternative candidates generated by ABC, and the clerk can decide whether to select an alternative proposal or process it as a non-confirmation for the original product/plant. This UX of “proposal -> the clerk’s confirmation decision” reflects a design philosophy that appropriately combines ABC’s automation with the clerk’s discretion.

8. Supply Protection: Institutionalizing “Supply Assurance” for Priority Customers

What Is Supply Protection: Protecting Supply to Strategic Customers as a “System”

Supply Protection (SUP) is a function that sets a priority supply quota for specific customer groups, sales channels, or regions, and has the system automatically protect that quota from other demand. Even in situations where inventory is tight, a minimum level of supply is guaranteed to protected customers.

The problem Supply Protection solves is “institutionalizing implicit promises.” Many companies hold policies such as “Customer A is top priority” or “a specific channel’s stock must be secured,” yet these were not enforced by the system and instead depended on the judgment and experience of front-line order-processing staff. Supply Protection translates this “implicit priority management” into explicit configuration values within the system, executing it consistently without dependence on staff experience.

Core Protection and Prioritized Protection: Two Protection Methods

Supply Protection has two methods: “Core Protection” and “Prioritized Protection.”

Core Protection (horizontal protection) is a strict method. The configured protection quantity is protected equally from all other demand. No demand can encroach on the protected quantity. For example, if it is set that “for product X at plant 0001, 100 units are always protected for the direct-sales channel,” those 100 units will not be used no matter how many orders come in via the wholesale channel.

Prioritized Protection (vertical protection) is a more flexible method. It defines multiple protection subgroups with priorities, creating a hierarchical protection structure in which “the priority-2 group can consume the remaining quantity after the priority-1 group has consumed the protected quantity.” For example, a setting such as “Priority 1: direct-sales Customer A (50 units protected)” -> “Priority 2: direct-sales Customer B (up to an additional 30 units protected)” is possible. This design allocates supply more flexibly than Core Protection while still reliably protecting supply to high-priority customers.

Operational View: Configuring a Supply Protection Object

Supply Protection is configured and managed in the SAP Fiori app “Manage Supply Protection.” The main configuration items are shown below.

• Supply Protection Object: Created for each combination of item and plant. Each object has a “Planning Horizon” and “characteristics (customer, sales organization, distribution channel, etc.)” configured, defining which combination of customer attributes the protection is applied to.

• Time Buckets: Sets the time unit used to manage the protection quantity by period. The standard is weekly or monthly, but for specific events (seasonal demand peaks, year-end shopping season, etc.), buckets can also be defined with an arbitrary period width. Once the planning end date of the protection object has passed, it no longer affects stock confirmation.

• Entering Protection Quantities: Sets the protection quantity for each time bucket and each CVC. For example, time-series settings such as “first week of October: 50 units for priority Customer A, second week of October: 60 units” are possible. Supply Protection data can also be entered in bulk via a CSV/Excel file upload.

• Integration Between Supply Protection and BOP: When BOP runs, Supply Protection is treated as “high priority.” Even as confirmation strategies such as Win/Gain/Redistribute are applied during a BOP run, protected quantities are always reserved preferentially for the protected customers.

9. ATP Scheduling and Supply Assignment: Raising the “Precision” and “Reliability” of Promises

ATP Scheduling: A “Feasible Delivery Date” That Accounts for Logistics Time

Even once the date on which stock can be secured is determined, delivering that stock to the customer requires several additional stretches of time — picking, packing, transportation planning, and transportation. ATP Scheduling is a function that calculates the “feasible delivery date (Confirmed Delivery Date)” presented to the customer, taking these lead times into account.

The lead-time elements considered in scheduling include the Transportation Planning Date, the Loading Date, Pick/Pack Time, and Transit Time. These durations are automatically referenced from master data such as the delivery route, mode of transportation, and the customer’s region.

If the Material Availability Date calculated through backward scheduling ends up in the past (stock exists now, but shipping today would not make it in time), the system switches to forward scheduling and calculates the earliest possible delivery date if shipment preparation began today. The practical value of ATP Scheduling is its ability to automatically calculate and present a realistic alternative delivery date in cases where “confirmation is possible, but it will not arrive by the requested date.”

Supply Assignment: The Final Step That Turns “Confirmed” Into “Secured”

Supply Assignment (ARun) is a function that physically links specific stock and receipts to confirmed demand (orders). A “confirmation” generated by PAC or BOP is in a state of “Soft Confirmation,” in which it is not yet fixed which stock or receipt the supply will come from. Supply Assignment converts this soft confirmation into a “Hard Assignment” that explicitly links it to “which production order, which purchase order, or which stock batch the supply comes from.”

Supply Assignment becomes important when, in a situation of tight inventory, it is necessary to actively decide “whose order this incoming receipt will be used for.” Whereas BOP is a soft adjustment that “reallocates confirmations according to priority,” Supply Assignment is a physical determination that “this batch of stock will be allocated to this order.” Because supply that has once been assigned will never be used for other demand, supply for important customers can be reliably secured right up until the moment of shipment.

Operational View: Configuration Parameters for Executing ARun (Supply Assignment)

Supply Assignment is operated through the SAP Fiori apps “Analyze Supply and Demand” and “Execute Supply Assignment.”

• Sort Criteria: Defines the priority order in which demand is sorted. Multiple attributes — such as customer priority class, product profit margin, and days of margin in the confirmation lead time — can be weighted and specified.

• Supply Sort Criteria: Defines which stock or receipts are prioritized for assignment to demand. Settings such as prioritizing stock with the earliest expiration date (FEFO: First Expired, First Out), or prioritizing a specific batch for a specific customer, are possible.

• Assignment Horizon: Defines how many days into the future demand and supply are subject to assignment. Typically, the horizon covers 7 to 14 days from the planned shipping date, focusing on reliably securing supply immediately before shipment.

• Simulation Mode: As with BOP, a simulation run is possible before actually updating data. The decision to proceed with a production update is made after confirming in advance “who would be assigned what if the assignment were run under these conditions.”

10. The Technology Foundation Supporting aATP: Integration of S/4HANA and SAP Fiori

The Real-Time Nature Brought by Native S/4HANA Implementation

The technical feature that fundamentally distinguishes aATP from the previous-generation gATP (APO) is its “native implementation in S/4HANA.” APO gATP ran on a system independent of S/4HANA, requiring real-time data synchronization (CIF: Core Interface) between the two. Delays in this synchronization directly affected the “freshness” of inventory information, always carrying the risk of generating confirmations based on outdated information that differed from the actual state of stock.

aATP references S/4HANA’s data model directly. Order, stock, production order, and purchase order data are all stored centrally in the S/4HANA database, and aATP processes it directly through HANA in-memory computation. Because there is no step of “copying data for calculation purposes,” the ATP check is always executed based on the most current transactional data. This is the technical basis for “real-time confirmation.”

SAP Fiori Apps: Modernizing the Order Clerk’s Work UI

aATP is operated through a group of SAP Fiori-based apps. The main apps that order clerks and Order Fulfillment Managers use for aATP’s core operations are shown below.

• “Review Availability Check Result”: A UI for checking and adjusting the results of a PAC execution. Confirmation proposals and alternative proposals are displayed in a list, and the clerk can manually select and adjust them.

• “Release for Delivery”: A Fiori app used to make final confirmation adjustments before shipment. It is used when manually reallocating stock in response to an escalation from an urgent customer. It has a function that lets the impact of a change be immediately checked via simulation, preventing over-confirmation.

• “Product Allocation Overview”: A dashboard app for reviewing the state of allocation consumption at a summary level. It uses color coding to show which period’s which CVC is in a state of “ample,” “tight,” or “exceeded.”

• “Monitor BOP Run”: A monitoring app for reviewing BOP run results by item, customer, and confirmation strategy. It tracks changes in confirmation status before and after a BOP run and allows checking for any unexpected confirmation changes.

Characteristic Catalog: The Common Configuration Foundation of aATP

aATP’s PAL, ABC, Supply Protection, and BOP all define rules based on characteristics such as “customer, sales organization, and item attributes.” The “Characteristic Catalog” manages the definitions of the characteristics referenced by these functions.

The Characteristic Catalog is the design foundation of aATP. It manages, as a catalog, the choice of characteristics such as “PAL uses sales organization, distribution channel, and customer number as characteristics” and “BOP uses customer priority class.” By modifying this catalog, the characteristics referenced by each function can be flexibly added or changed. In an aATP implementation project, the design of the Characteristic Catalog is one of the important design decisions to be settled first. This is because changing the Characteristic Catalog after go-live has a major impact on existing settings such as allocation data and Supply Protection objects, making the cost of change high.

aATP’s Customizing Structure: Key SPRO Navigation Paths

aATP configuration is managed in SAP S/4HANA’s Customizing (SPRO). Being familiar with the SPRO paths for the main functions greatly affects the efficiency of configuration changes during implementation and maintenance.

• ATP Checks in General (PAC Configuration): Located under “SD -> Basic Functions -> Availability Check and Transfer of Requirements.” All definitions of checking rules, checking groups, and the confirmation scope are made here. The checking-group assignment for each item is set in the “Availability Check” field of the MRP 3 view of the material master.

• aATP in General: Subfolders for each function are stored under “SD -> Advanced Available-to-Promise.” In a new S/4HANA environment, the settings under this node start out empty, and the implementation team builds up the configuration function by function.

• Defining the BOP Variant: “… -> Backorder Processing -> Define BOP Variant.” The BOP segment (filtering of target items/plants), confirmation strategy (Win/Gain/Redistribute/Fill), and priority-attribute weights are registered together as a single variant. The execution schedule is set from the SAP Fiori job scheduler or transaction SM36 (Define Background Job), registering the BOP program “/SAPATP/BOP” as a job.

• Defining Product Allocation Objects: “… -> Product Allocation -> Define Product Allocation Objects.” Configures the combination of characteristics used, the check date type (specify one of order date / requested delivery date / material availability date), and the unit of the allocation quantity. The choice of check date type is an important design decision that varies by industry. An order-date basis produces behavior that “consumes only orders placed this month from this month’s quota,” while a delivery-date basis produces behavior that “consumes orders requiring delivery this month from this month’s quota.”

• ATP Scheduling Lead Times: “… -> Scheduling -> Define Scheduling Types.” Default values for Pick/Pack Time, Loading Time, and transportation lead time are defined here. Overrides are possible for each combination of item, shipping point, and transportation route, and for multi-site, multi-channel companies, detailed settings by shipping route are directly linked to improved accuracy.

aATP Extension Points: BAdIs and RESTful APIs

For business requirements that go beyond the scope of standard functionality, aATP provides BAdI (Business Add-In) extension points and RESTful APIs. However, because using an extension means deviating from the Fit-to-Standard principle, the decision to adopt one should be made only after thoroughly examining, during the project’s design phase, “why the standard functionality cannot address the requirement.”

• BAdI “ATP Check Customization”: An extension point for inserting custom logic into PAC’s availability calculation. Used for use cases such as “restricting confirmation for specific orders based on batch attributes (expiration date, quality grade)” or “dynamically changing scope based on special customer contract terms.” It is accessed via SE19 (BAdI Explorer) and implemented as an ABAP class.

• BAdI “BOP Priority Calculation”: An extension point for embedding a company’s own custom scoring logic into BOP’s priority calculation. Used when implementing “composite scoring (customer strategic importance x order profit margin x contractual risk)” that cannot be expressed with the standard priority attributes (customer priority class, profit margin, etc.).

• Product Allocation Data API (OData): An OData V4 service for programmatically updating and referencing aATP’s PAL allocation data from IBP or external planning tools. In IBP integration, planned allocation quantities are automatically transferred via this API. In the S/4HANA Cloud edition, this corresponds to Communication Scenario “SAP_COM_0132,” and authentication uses the OAuth 2.0 client-credentials flow.

• Order ATP Inquiry API: An API for calling aATP’s PAC directly from an external Order Management System (OMS) or e-commerce platform to obtain the stock-confirmation result before finalizing an order. The online ATP check can be invoked synchronously through the OData API of “Business Document Processing” provided by SAP. Response time is typically expected to be sub-second (< 1 second), though complex checks that include Product Allocation, ABC, and Supply Protection will see a slight increase.

The decision of “which BAdIs not to use” is also an important deliverable of aATP design. BAdI extensions carry implementation cost, testing effort, and the risk of rework at future SAP upgrades. A design principle of addressing 80-90% of requirements through the Customizing parameters of standard functionality, and using BAdI extensions only for the remaining requirements, is essential to ensuring long-term maintainability.

11. Deployment Strategy: Where to Start and How to Grow

The Principle of aATP Deployment: Work Backward from Business Challenges

aATP’s functional modules span a wide range, but one should not aim to implement all of them from the outset. As with IBP, the principle of “starting small from the business’s most critical challenge and demonstrating value” is essential in aATP deployment as well.

The combination most companies tackle first is PAC and BOP. Establishing the basic functions of real-time stock confirmation and periodic priority-based reallocation in response to supply-demand changes is a prerequisite for the other advanced functions (PAL, ABC, SUP) to work effectively. A realistic approach is to add PAL, ABC, and Supply Protection in stages, in line with the next challenge, once PAC and BOP are running stably.

Migrating from APO gATP: The Reality of “No Technical Migration”

When a company currently running APO gATP migrates to aATP, no technical automatic migration tool is provided. The rules, allocations, and global ATP settings configured in gATP must be redesigned and reconfigured based on aATP’s design philosophy.

This reality of “no technical migration” is not merely an inconvenience but also an opportunity for redesign. Rather than carrying forward the complex settings, exception handling, and legacy rules accumulated over the gATP era, a company can redesign a simpler, more maintainable ATP process that makes maximum use of aATP’s standard functionality (Fit to Standard). Approaching the migration project from the perspective that “precisely because technical migration is impossible, the business process can be reviewed” leads to long-term reductions in operating costs.

Designing the IBP Integration: Tying “Planning” and “Promising” Together With a Single Thread

In deploying aATP, designing the integration with IBP is an important strategic choice. An API is provided that brings the product allocation plan formulated in IBP (how many units are allocated to which sales channel or customer) into aATP’s PAL, and leveraging this achieves a mechanism whereby “what is decided in planning is reliably honored in order processing.”

However, for this integration to function effectively, it is a precondition that the granularity of IBP’s allocation plan (units of item, sales organization, and customer) and the design of aATP’s Characteristic Catalog be aligned. When IBP and aATP implementations proceed as separate projects, it in fact happens frequently that, when integration is attempted afterward, inconsistencies in characteristic definitions require redesign. When IBP and aATP are implemented at the same time, ensuring consistency between the two data models from the very start of the design phase is nothing less than a critical requirement for project success.

12. The Transformation aATP Brings to Management: Turning the “Power to Promise” Into Competitive Advantage

The Management Benefits Created by Improved Order Promising Accuracy

When aATP functions correctly, the most direct change that occurs within an organization is an improvement in the “On-Time Delivery (OTD)” rate — the rate at which the promised delivery date is honored. Under conventional basic ATP, discrepancies such as “unable to ship on the confirmed date” or “able to ship only fewer units than confirmed” occurred routinely. By combining aATP’s real-time stock confirmation, priority-based allocation, and scheduling that accounts for logistics time, the gap between confirmation and actual shipment is greatly narrowed.

Improved OTD directly leads to higher customer satisfaction, and over the long term ties into business results in the form of higher customer loyalty, lower churn rates, and stronger pricing power. In an era in which the reputation of being “a company that keeps its promises” forms the very foundation of competitive advantage, investment in an order-promising platform like aATP is not merely a system investment but an indispensable piece of infrastructure from a business-strategy standpoint.

Effective Use of Inventory: From “First Come, First Served” to Strategic Allocation

Through the coordinated working of aATP’s PAL, BOP, and Supply Protection, inventory allocation changes from “first come, first served” to “allocation based on business strategy.” The implications this change brings to management are significant.

By preferentially allocating scarce stock to customers, products, and channels with high profit contribution, higher sales and profit can be achieved even at the same inventory level. In addition, being able to prevent, through system configuration, the worst-case management scenario of “being unable to supply an important customer” — the risk of complaints from a large customer, penalty payments, or termination of the business relationship — is also an important value from a risk-management perspective.

Conclusion: aATP Is Not an “Order-Processing Tool” but a “Mechanism for Maximizing Revenue”

To conclude, let us summarize in a single statement the essence of aATP explained throughout this article. aATP is a management mechanism that, the moment an order arrives, optimizes “to whom, what, when, and from where to deliver,” and reliably carries out that promise.

Each module — PAC, BOP, PAL, ABC, Supply Protection, and Supply Assignment — may appear to be an independent function, but all of them work together toward the single purpose of “raising the precision and fairness of order promising, and making maximum effective use of inventory as a management resource.” When that coordination functions correctly, aATP becomes management infrastructure that goes beyond mere system functionality, turning a company’s “power to promise” into a source of competitive advantage.

And when IBP and aATP are correctly integrated — when the integration is achieved whereby execution (aATP) faithfully reflects, in order processing, the inventory-allocation intent set by planning (IBP) — a company can make its entire supply chain function as a single, integrated mechanism for running the business. It is hoped that this article will serve as a help in drawing out that potential to the fullest.

13. Case Studies From Other Companies: The Moment aATP Changed the Front Line

This chapter introduces corporate case studies in which each of aATP’s functional modules was actually put to use. Each case study is compiled from multiple published sources (SAP PRESS, industry trade journals, etc.). Company names have been kept anonymous, but each is based on implementation results recorded at an actual, real-world company.

Case 1: Semiconductor Manufacturer, Company A — Strategic Customer Priority Management Through Product Allocation (PAL)

Background and Challenge

Global semiconductor manufacturer Company A faced a serious order-management challenge amid the worldwide chip shortage (the semiconductor shortage wave of the 2020s). Continued supply to OEM automakers was a top priority both contractually and strategically, but under conventional ATP’s first-come, first-served processing, orders from distributors handling general-purpose products were processed first, frequently depleting stock earmarked for OEMs. Front-line operators had been manually “holding” stock for OEMs by hand, but this was personnel-dependent, inefficient, and prone to error.

aATP Implementation and Configuration Approach

In conjunction with its SAP S/4HANA migration, Company A implemented aATP’s Product Allocation (PAL). It set “Customer Group” as the primary characteristic in the Characteristic Catalog, defining three tiers as characteristic values: OEM customer group, Tier-1 distributors, and general distribution. It established an operation in which, against the weekly production plan for each chip part number, allocation quantities by CVC are updated weekly as product allocation data. It also implemented integration with IBP for Response & Supply, automatically pulling the supply-demand adjustment results calculated by IBP into the PAL data.

Results

After PAL went live, the confirmation rate for OEM orders improved substantially. The depletion of OEM stock caused by “first come, first served” was prevented at the system level, and delivery-date complaints from OEM customers dropped sharply. The working hours order-management staff had spent on manually adjusting stock were reduced, and that effort could be redirected to higher-value-added supplier negotiations and supply-demand simulation. There is also a qualitative assessment that “because the basis for stock allocation became visible and rule-based, explaining it to customers became far easier.”

Case 2: Electronics Manufacturer, Company B — Priority Shipment for Government Contracts Through Backorder Processing (BOP)

Background and Challenge

Industrial electronics manufacturer Company B carried both commercial products and government/defense-ministry-related contracts. It had an internal policy of “government contracts take top priority” whenever production capacity was tight, but there was no mechanism to reflect this in the order-entry system, and cases continued in which commercial customer orders were processed first and occupied production capacity. A government-contract breach carried the risk of penalty payments and contract termination and was a top management priority, but the IT system was unable to guarantee it.

aATP Implementation and Configuration Approach

Company B implemented aATP’s Backorder Processing (BOP). It set values for the “Customer Classification” characteristic: “government contract = GVT / defense ministry = DEF / premium commercial = PREM / general = STD.” In the BOP variant, it adopted the “Redistribute” strategy, configuring logic that, when run, cancels the confirmations of lower-priority customers (STD/PREM) as needed and reallocates them to government/defense-contract customers (GVT/DEF). BOP was scheduled to run every night at 11:00 p.m., completing priority-based reconfirmation before the start of business the next morning.

Results

After BOP went live, the on-time-delivery rate for government contracts improved substantially. Without manual intervention by staff, a state was achieved in which government contracts are always confirmed preferentially even when production capacity is tight. Changes to confirmations for general customers (partial cancellations and delays) increased, but operating this together with an advance-notification mechanism enabled courteous handling of customers. Feedback received includes that “government-contract risk is now managed by the system, which has put management at ease.”

Case 3: Consumer Electronics Retailer, Company C — Multi-Warehouse Shipment Optimization Through Alternative-Based Confirmation (ABC)

Background and Challenge

Multi-channel consumer electronics retailer Company C operated four domestic distribution centers (DCs) and two direct-sales warehouses. Its conventional ATP checked each warehouse individually only, with no mechanism to “automatically propose another DC as a substitute when the main DC’s stock runs out.” When the main DC’s stock was depleted during e-commerce order peaks (year-end shopping season, sale periods, etc.), a large volume of orders were processed as “cannot confirm,” resulting in lost sales opportunities — even though stock existed at other DCs, it was not being leveraged.

aATP Implementation and Configuration Approach

Company C implemented ABC’s Plant Substitution function. For each main DC, it registered alternative DCs and direct-sales warehouses with sequence numbers (priorities factoring in transportation cost and distance from the customer’s address). In the rating profile, it adopted “Maximum Confirmation Ratio (weight 70), Minimum Delay (weight 30),” reflecting a policy of prioritizing confirmation ratio even at some added transportation cost. As a hard constraint, it set “Maximum Delay of 3 days (standard delivery service level),” controlling the system so that alternative confirmations delayed by 3 days or more were not proposed.

Results

After ABC went live, the order confirmation rate during peak periods improved substantially. “Cannot confirm” outcomes caused by main-DC stockouts were almost eliminated, and customer delivery-date requirements could be met through shipment from alternative DCs. An operational improvement was also achieved whereby “the system now automatically selects the optimal warehouse, eliminating the work of order clerks manually checking warehouse stock and issuing transfer requests.” Although logistics costs increased slightly, the effect of reduced lost sales opportunities and improved customer satisfaction far outweighed it.

Case 4: Semiconductor Manufacturer, Company D — Institutionalizing OEM Priority Supply Through Supply Protection

Background and Challenge

Another semiconductor manufacturer, Company D (in the analog semiconductor and sensor product domain), was also struggling to balance commitments to OEM customers with supply to general distributors. The difference from Company A was that Company D had entered into explicit contractual commitments with customers, product line by product line, of the form “at least X units must always be reserved for OEMs.” This numerical commitment needed to be enforced by the system, but conventional ATP had no mechanism for that.

aATP Implementation and Configuration Approach

Company D implemented the Core Protection method of aATP’s Supply Protection. It set the contractual OEM commitment quantity as a “protection quantity” for the combination of item, plant, and OEM customer group. It configured “Customer Group (OEM_PRIO / DIST_A / DIST_B)” in the Characteristic Catalog, and by setting the Core Protection object only for the OEM_PRIO CVC, confirmation against the protected quota was automatically restricted to orders from OEM customers only. Time buckets were set monthly, establishing an operation in which the protection quantity is reviewed in line with the production plan, which is updated each month.

Results

After Supply Protection went live, a state was achieved in which the contractually committed quantity for OEMs is always secured. Even when large orders flood in from distributors, the protected quota is never allocated to non-OEM demand, so the risk of a contract breach with OEM customers has become nearly zero. There is an assessment that “while there is the routine task of setting monthly protection quantities, the effort of inventory management otherwise decreased substantially — and in fact, because the figures became visible, management discussions about which OEM relationship is putting the most strain on inventory have become possible.”

These four cases demonstrate the essential value of aATP: its functions embed management policy into the system in the form of “configuration values,” and continue to execute that policy without depending on front-line judgment, manual work, or personnel-dependent processes. What is common across every case is that “by codifying inventory allocation rules and having the system execute them automatically and consistently, management risk became manageable.”

End