Mirror of Oracle documentation
Converted for search and offline reading. Authoritative source: Oracle. Diagrams and some complex tables are simplified — check the PDF when in doubt.
-
Increase gross margin and revenue.
-
Reduce shipping and handling costs.
-
Improve stock rates and reduce overstocks.
Functional Overview
The solution includes the following key areas:
-
Setting Up Pre Pack Configuration Runs provides a way for users to select product/ location areas and optionally specify business constraints.
-
Submitted runs get queued for optimization. Progress of these runs can be reviewed in the Run Queue.
-
Queued Runs get optimized.
-
Users can review and approve resulting Pre-Packs.
Optimization Process Overview
The optimizer estimates the cost impact of different packs for analysis. It evaluates various pack configurations that meet the specified constraints and iteratively performs mock allocations to calculate the store over and under allocation units. The units are multiplied by cost factors that can be overridden during Create Runs (comes with default values). In addition, a cost factor is applied to every pack (based on the Distribution cost factor). The optimizer finds the pack configurations that minimize the total Objective Cost.
The total objective cost for each store is for each combination of pack configurations being evaluated:
-
Total Objective Cost = # of under allocated units at the store * under allocation cost factor + # of over allocated units at the store * over allocation cost factor + # of packs needed of each pack type * distribution cost factor.
-
The total Objective Cost is aggregated up to the optimization level for each pack combination being evaluated. Note that there are two levels of optimization going on here: Picking the optimal pack configuration combinations and optimally allocating those pack configurations to each store to minimize overall objective cost. The resulting output is the optimal set of pack configurations as well as the resulting store allocations. In the case where fixed pre-packs are specified, the pack configuration optimization part is skipped and only the optimal mock allocation part is performed.
Application Workflow
This section describes the application workflow.
Setting Up Pre-Pack Configuration Runs
Pre-pack configurations are expected to be run based on user-initiated runs using the Pack Configuration Create Run task.
Pack Definition Rules
These rules represent business constraints that need to be honored around how packs are recommended. These constraints could be due to constraints from the vendor or supply chain constraints around the ability to handle certain sizes of packs.
Minimum total units per pack: This is to be set based on vendor and supply chain constraints.
Maximum total units per pack: This is to be set based on vendor and supply chain constraints.
Valid Pack Sizes ladder: This allows you to enter a list of acceptable values such as 4,6,8,10,13,14.
Enable Eaches: If this is set, the optimization will fill the remaining demand outstanding after allocating packs with Eaches.
Max number of Pack Configurations: This value is set to indicate to the system not to try more pack configurations than this during optimization. This is helpful to ensure the optimization runs within acceptable and realistic search space and therefore does not unnecessarily process unrealistic scenarios. Within this, the optimizer will recommend the optimal number of Pack Configurations.
Holdback
This allows you to simulate situations where it is best practice to holdback a % of the demand at the Warehouse to replenish in eaches to stores, based on in-season sales. It is possible for you to simulate different holdback scenarios to see the difference in recommended pack configurations.
Holdback% : A % value of demand to be used as held back demand. For example, if this value is set to 30%, then 70% of the total demand (from the user selections of time period for the optimization level) are used for Pack Optimization. The remaining demand is assumed to be fulfilled in Eaches.
Holdback Eaches Handling Costs Factor Type: This currently defaults to Constant.
Holdback Eaches Handling Cost Factor (Constant): Specifies the factor by which every single holdback item gets multiplied by, for computing the handling cost associated with Holdback for the scenario. It should be noted that Holdback costs are not considered as part of the optimization, but are included in the results for reporting purposes.
Costs
These are cost factors that the optimizer considers when balancing tradeoffs.
Under Allocated Costs Factor Type: This currently defaults to Constant.
Under Allocated Costs Factor (Constant): Specifies the factor by which every under allocated unit gets multiplied by, when the optimizer computes the over allocation cost for any scenario it evaluates. Recall that the optimizer tries to minimize the net objective cost and it is computed as the sum of Over Allocation Cost, Under Allocation Cost, and Handling Cost.
Over Allocated Costs Factor Type: This currently defaults to Constant.
Over Allocated Costs Factor (Constant): Specifies the factor by which every over allocated unit gets multiplied by, when the optimizer computes the over allocation cost for any scenario it evaluates. Recall that the optimizer tries to minimize the net objective cost and it is computed as the sum of Over Allocation Cost, Under Allocation Cost, and Handling Cost.
It may be considered that the cost of over allocating is different from cost (increased markdowns) of under allocating (lost revenue). Hence this level of flexibility is provided.
Handling Costs Factor Type: This currently defaults to Constant.
Handling Costs Factor (Constant): Specifies the factor by which every pre pack gets multiplied by, when the optimizer computes the handling cost for any scenario it evaluates. Recall that the optimizer tries to minimize the net objective cost and it is computed as the sum of Over Allocation Cost, Under Allocation Cost, and Handling Cost.
Eaches Handling Costs Factor Type: This currently defaults to Constant.
Eaches Handling Cost Factor (Constant): Specifies the factor by which every single item (also called Eaches) gets multiplied by, when the optimizer computes the handling cost for any scenario it evaluates. It is possible that it may be less or more laborious to handle eaches compared to handling pre-packs, hence this level of flexibility is provided. Recall that the optimizer tries to minimize the net objective cost and it is computed as the sum of Over Allocation Cost, Under Allocation Cost, and Handling Cost.
Allocation Constraints
These allow you to impose constraints for the mock allocation to ensure presentation minimums are met and style colors and stores do not get allocated below or above an acceptable threshold even if it may be sub-optimal to do so at an aggregate level.
Presentation Minimums Type: This can be chosen among Constant, Size and no value (see Presentation Minimums Value for details).
Presentation Minimums Value: If it is required that a minimum quantity of each SKU is sent to each store, this value can be set. For example, this would be useful to maintain presentation standards at the launch of an assortment at the beginning of the season. Note that this parameter can be overridden at the Size level if the Presentation Minimums Type field is set to Size, and this enables the corresponding Presentation Minimums by Size table in the Pack Configuration Set and Size Level Overrides tab (see below). In this way, for example, it is possible to specify presentation minimums for only some core sizes rather than all SKUs. If any changes are made in this screen tab, any size level overrides will be overridden.
Max Under Allocation % (of Demand): This parameter value imposes a maximum acceptable threshold on the percent of underallocation computed as the total underallocation across all stores aggregated up relative to the total demand. This can be used as a guard rail to ensure overall underallocation stays within a threshold even when it may be more efficient to underallocate demand rather than incur additional distribution costs.
Max Under Allocation % by Style Color: When the system performs the mock allocation, it computes the misallocation at each SKU and Store level. Misallocation is percent of demand that was either over or under allocated relative to the SKU/Store demand. This misallocation% is recomputed at the Style Color level by computing the total misallocation across all SKU/ Stores in the Style Color and comparing it to the demand at the Style Color. This parameter value imposes a maximum acceptable threshold on this. This can be used a guard rail to ensure no Style Colors are excessively used.
Max Over Allocation % (of Demand): This parameter value imposes a maximum acceptable threshold on the percent of overallocation computed as the total overallocation across all stores aggregated up relative to the total demand. This can be used as a guard rail to ensure overall overallocation stays within a threshold even when it may be more efficient to overallocate demand rather than incur in lost sales costs.
Advanced Parameters
These are advanced optimization parameters that are only available to Administrator users and allow deeper control on the optimization internals.
Enable Heuristic Mode: This enables the initial phase of the optimization algorithm (packs search) based on heuristics. Enabled by default.
Enable Full Optimization Mode: This enables the initial phase of the optimization algorithm (packs search) based on a linear cost model. Disabled by default.
Only one among Heuristic and Full Optimization modes can be enabled at one time.
Enable Demand Clustering: In the initial optimization phase, it reduces the demand matrix size by clustering.
Clustering Max Iterations: The maximum number of iterations of the clustering algorithm.
Max Demand Level Clusters: The maximum number of demand levels resulting from the clustering algorithm.
Max Size Profile Clusters: The maximum number of size profiles resulting from the clustering algorithm.
Number of Random Runs for Optimization Mode: The number of times the Full Optimization algorithm (packs search phase) is executed (with randomized initialization) to find the best solution.
Max Time at Plateau (sec) for Optimization Mode: For the Full Optimization mode (packs search phase), if the solution does not improve for the specified number of seconds, the algorithm will assume to have found a plateau, thus will accept the solution and proceed with the subsequent phases.
Max Total Runtime (sec) for Optimization Mode: For the Full Optimization mode (packs search phase), the maximum number of seconds the algorithm is allowed to run (regardless of plateaus), before accepting the solution and proceeding with the subsequent phases.
Convergence % Threshold for Optimization Mode: The percentage convergence threshold for the Full Optimization mode.
Max Total Runtime (sec) for Eaches Optimization: To obtain a measure of the misallocation induced by the integer rounding of the demand matrix, and at the same time obtaining a baseline measure of the costs incurred if only eaches (and no packs) were utilized, the optimization starts by simulating an allocation via eaches only; this parameter controls the maximum total runtime of this phase.
Number of Random Runs for Optimal Allocation Mode: The number of times the final allocation phase of the optimization is executed to find the best solution, regardless whether Heuristic or Full Optimization modes were enabled in the initial packs search phase.
Max Total Runtime (sec) for Optimal Allocation Mode: For the final allocation phase of the optimization, the maximum number of seconds the algorithm is allowed to run before accepting the solution.
Convergence % Threshold for Optimal Allocation Mode: The percentage convergence threshold for the final allocation phase.
Enable Verbose Logging: This enables additional logging for the optimization algorithm, which is only available to Oracle Support.
Saving overrides at the run level: Once you click Apply, this spreads the override values to all scenarios. Note that any previous scenario level overrides will then get overridden. Hence it is important that you set parameters at the Run level first and then perform any scenario specific overrides.
| Column Label | Detailed Description |
|---|---|
| Pack Configuration Set Label | Pack Configuration Set Label (User provided or system auto generated). |
| Size Range | Size Range Name |
| Vendor | Vendor |
| Status | Scenario Status |
| Scenario # | Scenario number |
| Rec Pack Configuration | Recommended Optimal Pack Configurations |
| Rec # of Pack Configurations | Recommended Optimal Number of Pack Configurations |
| Net Objective Cost diff Baseline | Net Objective Cost Difference to baseline pack configurations. This metric helps quantify the benefits from systems recommended pack configurations compared to the baseline pack configurations. Typically either last approved packs or scenarios with fixed pre packs are selected as baseline scenarios when runs are submitted. |
| Rec # of Eaches | # of eaches needed to meet total demand based on system recommended packs, as simulated by the system. If “Enable Eaches” is set to False when creating the run, this value will be 0. Includes heldback need if “fill heldback need with eaches” is Y. |
| Rec # of Allocated Packs | # of packs needed to meet total demand based on system recommended pack configurations, as simulated by the system. |
| Total Demand Sourced | This is the Total Demand that was used to determine the optimal pre-pack configurations. SKU/Store level demand is used to determine the optimal pack configurations, based on the Demand Source and weeks specified. The number presented here is an aggregation of this demand at the optimization level. Includes heldback need if “fill heldback need with eaches” is Y. |
| Over Allocated Unit % | Units Over Allocated/Total Demand Units as simulated by the system. The over allocated units are computed at the store level and aggregated up. |
| Under Allocated Unit % | Units Under Allocated/Total Demand Units as simulated by the system. The under allocated units are computed at the store level and aggregated up. |
| Incremental Mis Allocated Unit % | Increment in misallocation units, compared to only distributing Eaches. Misallocations from Eaches arises from fractional need at the size level and cannot be avoided. Hence this metric represents the additional misallocations from the packs. |
| Over Allocated Unit Cost | Simulated Under Allocation costs divided by Total Demand Sourced. Under Allocation cost is computed as Total Units Under Allocated * under allocation cost factor. |
| Under Allocated Unit Cost | Over Allocation costs divided by Total Demand Sourced. Over Allocation cost is computed as Total Units Over Allocated * over allocation cost factor. |
| Mis Allocated Unit Cost | Misallocation Cost (Over + Under Allocation costs) divided by Total Demand Sourced |
| Net Objective Unit Cost | Total cost (Misallocation + Distribution Cost) minimized by the Optimizer divided by Total Demand Sourced. When comparing scenarios, a lower Net Objective cost per Unit is better. |
| Column Label | Detailed Description |
|---|---|
| Baseline Rec # of Pack Configurations | # of Pack Configurations simulated as baseline. When runs are submitted, any one scenario can (optionally) be specified as a baseline. The results from this scenario are used as a basis for comparing all other scenarios. Typical expected usage is that either last approved packs or scenarios with fixed pre packs are selected as baseline scenarios. If no scenario is selected as Baseline, then all Baseline metrics will be empty. |
| Baseline Rec # of Eaches | # of eaches needed to meet total demand based on baseline pack configurations, as simulated by the system. If “Enable Eaches” is set to False when creating the run, this value will be 0. |
| Baseline Rec # of Allocated Packs | # of packs needed to meet total demand based on baseline pack configurations, as simulated by the system. |
| Baseline Over Allocated Unit % | Units Over Allocated/Baseline Total Demand Units as simulated by the system for baseline pack configurations. The over allocated units are computed at the store level and aggregated up. |
| Baseline Under Allocated Unit % | Units Under Allocated/Total Demand Sourced Units as simulated by the system for baseline pack configurations. The under allocated units are computed at the store level and aggregated up. |
| Baseline Incremental Mis Allocated Unit % | Increment in misallocation units when distributing baseline pack configurations, compared to only distributing Eaches. Misallocations from Eaches arises from fractional need at the size level and cannot be avoided. Hence this metric represents the additional misallocations from the baseline packs. |
| Baseline Over Allocated Unit Cost | Under Allocation costs with baseline pack configurations divided by Total Demand Sourced. Under Allocation cost is computed as Units Under Allocated * under allocation cost factor. |
| Baseline Under Allocated Unit Cost | Over Allocation costs with baseline pack configurations divided by Total Demand Sourced. Over Allocation cost is computed as Units Over Allocated * under allocation cost factor. |
| Baseline Mis Allocated Unit Cost | Misallocation Cost (Baseline Over + Baseline Under Allocation costs) with baseline pack configuration sets divided by Total Demand Sourced. |
| Baseline Net Objective Unit Cost | Total Baseline cost (Baseline Misallocation + Baseline Distribution Cost) divided by Total Demand Sourced. When comparing scenarios, a lower Net Objective cost per Unit is better. |
| Rec # of Eaches Ratio to Baseline | # of simulated Eaches distributed with system recommended pack configurations / # of simulated Eaches distributed with baseline pack configurations. |
| Simulated # of Packs Allocated Ratio to Baseline | # of simulated Packs distributed with system recommended pack configurations / # of simulated Packs distributed with baseline pack configurations.. |
| Over Allocated Unit var Baseline % | % Units Over Allocated/% Units Over Allocated with Baseline Pack Configurations. |
| Under Allocated Unit var Baseline % | % Units Under Allocated/% Units Under Allocated with Baseline Pack Configurations. |
| Mis Allocated Unit var Baseline % | % Units Mis Allocated/% Units Mis Allocated with Baseline Pack Configurations. |
| Over Allocated Unit Cost / Baseline ratio | Over Allocated Cost per unit/Over Allocated Cost per Unit with Baseline Pack Configurations. |
| Under Allocated Unit Cost / Baseline ratio | Under Allocated Cost Per Unit / Under Allocated Cost per Unit with Baseline Pack Configurations. |
| Mis Allocated Unit Cost / Baseline ratio | Mis Allocated Cost Per Unit / Mis Allocated Cost per Unit with Baseline Pack Configurations. |
Once the user approves a scenario, the scenario status gets updated as Approved. The Approval date and Approved by fields also get populated or updated. Any additional scenario statuses change to Overridden.
In this guide
- Guide: AI Foundation User Guide
- Previous: 14 Portfolio Optimization
- Next: 16 Glossary