From Forecasting to Decision Optimization

From Forecasting to Decision Optimization

Building an end-to-end retail data science system: business KPIs, demand forecasting, mathematical optimization, supplier selection, decision policies and production deployment, told as one story.

A practical, illustrated guide · about 40 minutes of reading · all figures in the examples are illustrative

A forecast is only a sentence about the future. A business needs a verb. This guide follows one retailer, and one data scientist, from the first vague complaint (“we keep running out of things, and also throwing things away”) to a deployed system that predicts, decides, executes, measures and improves.

What we will cover

1. Business understanding
2. KPI design
3. Data acquisition and preparation
4. Demand forecasting
5. Designing a decision policy
6. Inventory optimization
7. Supplier selection
8. Optimization algorithms
9. How the pieces fit together
10. Validating the policy
11. Deployment on Google Cloud
12. SAP and enterprise systems
13. Continuous improvement
14. The three feedback loops
15. A complete worked example
16. What to build first
17. Lessons and glossary

Introduction: beyond predictive modeling

Meet Leila

Leila is a data scientist at FreshMart, a supermarket chain with 150 stores and about 20,000 products. On her first Monday she is handed a one-line brief: “Improve inventory management.” Over the next sixteen sections we will follow her as she turns that sentence into a working system.

Every day FreshMart must decide how much milk, bottled water, fruit and meat to buy, where to store it and how to distribute it. These decisions are tangled together. Too much milk and it expires. Too little bottled water during a heatwave and customers walk out empty-handed. The cheapest supplier is no bargain if the truck arrives three days late. A full warehouse keeps shelves stocked, but it also ties up cash.

A production data science system should not stop at predicting what will happen. It should use those predictions to decide what to do, evaluate whether those decisions improve the business, and keep adapting when conditions change.

No single discipline can solve this alone. Leila will need six, and the real skill is making them work as one system:

• Business analytics to understand the objectives and measure performance.
• Data engineering to collect, transform and integrate the data.
• Machine learning and forecasting to predict demand and quantify uncertainty.
• Operations research to find good decisions under constraints.
• Simulation and experimentation to test whether decisions are likely to work.
• Data and ML engineering to deploy, integrate and monitor everything.

Figure 1. The lifecycle of a retail decision system. In practice some stages run in parallel, and an optimizer may reveal that the forecast does not carry enough information for a reliable purchasing decision, which sends us back upstream.

1. Business understanding: what are we actually trying to optimize?

Before choosing a forecasting model or an optimization algorithm, we have to understand the business problem. Leila sits down with the category managers and hears three recurring complaints:

1. Some products are frequently unavailable.
2. Others stay in storage too long and expire.
3. Procurement costs keep rising.

Management’s request sounds like a forecasting problem: surely a more accurate demand forecast would reduce both stockouts and excess inventory. But even if Leila knew future demand perfectly, she would still have to decide how much to order, when to order, which supplier to use, how much buffer to keep, how to respect the budget, and how to balance availability against waste and storage cost. Forecasting is necessary and not sufficient.

1.1 Prediction versus decision

Take bottled water. The forecasting model says a store will sell 500 bottles over the next seven days. That is a prediction. The decision is whether to order 200, 400 or 600 more bottles, and from whom. That decision also depends on current stock, incoming deliveries, lead times, storage capacity, supplier prices and the consequences of running out.

Figure 2. A forecast estimates what may happen. A decision combines that estimate with state, costs and constraints to choose what to do.

Question	Discipline	Output
How much demand should we expect?	Forecasting	Predicted demand
How uncertain is that prediction?	Statistical modeling	Forecast distribution or prediction intervals
How much should we order?	Inventory management and optimization	Recommended order quantity
Which supplier should we use?	Procurement optimization	Supplier allocation
Did the new approach improve performance?	Evaluation and experimentation	Measured business impact

1.2 Identify the actual business objective

The first question is not “how do we minimize inventory?” It is “what does the company want to achieve?” Candidate objectives include minimizing total operating cost, reducing stockouts, increasing availability, reducing waste, improving gross margin, freeing capital tied up in stock, or holding a target service level at minimum cost.

These objectives pull against each other. Less inventory lowers holding cost but risks stockouts. More inventory improves availability but raises storage cost and waste. A useful formulation therefore reads:

Intuition

Minimize total relevant cost while maintaining an acceptable level of product availability. One objective, one constraint. That is more honest than pretending every KPI can improve independently.

2. KPI design: turning business goals into measurable quantities

Once the problem is understood, Leila defines the Key Performance Indicators that will steer the project. This is more than copying metrics from a dashboard. For each KPI we need to know what it measures, how it is calculated, which data it needs and which decisions it will influence.

2.1 Forecasting KPIs

These measure how well the model predicts future demand. Let D_t be actual demand and D̂_t the forecast.

Mean Absolute Error (MAE)

MAE = 1n ∑_t=1ⁿ | D_t − D̂_t |

Suppose actual demand over three days is [100, 120, 80] and the model predicts [110, 110, 90]. Each absolute error is 10, so MAE = (10 + 10 + 10) / 3 = 10 units per day. MAE is easy to read because it uses the unit of the target. But 10 units is a big miss for a product selling 15 a day and a rounding error for one selling 1,000.

Weighted Absolute Percentage Error (WAPE)

WAPE = ∑_t | D_t − D̂_t |∑_t D_t × 100

On the same example: 30 / 300 × 100 = 10%. WAPE expresses total error relative to total demand, which makes portfolios with very different volumes comparable. Its weakness is the mirror image of its strength: high-volume products dominate, so low-volume items can look better than they deserve.

Forecast bias

Bias = ∑_t ( D̂_t − D_t )∑_t D_t × 100

With this sign convention, positive bias means systematic over-forecasting (a recipe for excess stock) and negative bias means systematic under-forecasting (a recipe for stockouts).

Why MAE alone can mislead

Two models can have the same MAE. One misses randomly in both directions. The other always under-forecasts by 10. The first is noisy; the second is quietly manufacturing stockouts. Always read absolute error together with bias.

2.2 Inventory and operational KPIs

Forecast accuracy is only half the story. The retailer also needs to measure what its purchasing and replenishment decisions cause.

KPI	What it measures	Why it matters
Stockout rate	Frequency or proportion of situations where stock is unavailable	Product-availability problems
Service level	A defined measure of how successfully demand is fulfilled	Customer-service performance
Average inventory	Average quantity or value of stock held	Stock levels and capital needs
Holding cost	Cost of storing and financing inventory	The price of excess stock
Waste rate	Share of product lost to expiry, damage or other causes	Critical for perishables
Supplier lead time	Time from order to receipt	Determines how early orders must be placed
Gross margin	Revenue minus cost of goods sold	Profitability before other operating costs
Purchasing spend	Procurement spend over a period	Budget control
Inventory turnover	How often inventory is sold relative to the inventory measure used	Inventory efficiency

Average inventory

A simple approximation uses the start and end of the period:

AverageInventory = Beginning + Ending2

If stock is worth €100,000 at the start of the month and €140,000 at the end, the average is €120,000. This can mislead when stock swings within the month. With daily data, use the mean of the daily values instead: (1/T) ∑ Inventory_t. And always say whether you mean units or euros. They are different KPIs.

Service level versus stockout rate

Related, not interchangeable. One retailer may define service level as the share of order lines fulfilled completely; another as the share of customer demand met immediately from stock. Stockout rate might be the share of product-store-days with zero stock. The organization must fix the definition before anyone compares policies.

2.3 Financial KPIs

GrossMargin = Revenue − CostOfGoodsSold     GrossMargin% = Revenue − COGSRevenue × 100

A product sells for €3.00 and costs €1.80 to buy, so the unit margin is €1.20 and 10,000 units earn €12,000. But if the retailer over-orders and 1,000 units expire, it forfeits the expected margin on those units and pays disposal costs. That is why a forecast should never be judged apart from the decisions it supports.

2.4 Not every KPI should be optimized directly

Suppose the business requires: minimize total relevant cost, keep service level at or above 98%, and never exceed a €50,000 purchasing budget. These play different roles.

Figure 3. Different KPIs play different roles. Only the objective is minimized and the constraints are respected; the others are monitored to explain what is happening.

Why not minimize everything at once? Because some goals conflict, and an optimizer needs an explicit trade-off. One option is to minimize cost subject to a service-level floor. Another is a weighted objective, though the weights must reflect real business priorities and the units must be handled with care.

Deliverable of this phase

A measurable definition of success, plus a recorded baseline, before any model is built. Without a baseline, no improvement can ever be demonstrated.

3. Data acquisition and preparation: building the information foundation

With KPIs defined, Leila asks whether the data to compute them actually exists, and whether it tells the truth. At FreshMart the information is scattered across systems.

3.1 Typical data sources

Source	Information	Typical use
Point-of-sale (POS)	Sales, quantities, timestamps	Demand estimation
ERP	Purchase orders, invoices, costs, suppliers	Procurement and financial analysis
Inventory system	Stock, movements, reserved quantities	Replenishment decisions
Promotion system	Discounts, campaigns, planned periods	Promotional demand
Product information	Categories, brands, shelf life, packaging	Features and constraints
Supplier system	Lead times, capacities, prices, minimum order quantities	Supplier selection
Warehouse system	Space, receiving capacity, storage conditions	Operational constraints
External providers	Weather, holidays, local events	Extra demand predictors

The challenge is not loading all of this into one database. It is agreeing on definitions and joining data at the right level: sales arrive as transaction lines, inventory as product-store snapshots with their own timestamps.

3.2 Define the forecasting granularity

Suppose FreshMart forecasts daily demand by product and store. One observation is identified by (ProductID, StoreID, Date). The target is quantity sold or, ideally, an estimate of unconstrained demand. A sample (illustrative) extract:

Date	Store	Product	Units sold	Price	Promo	Stock available
01/06	A	Water	100	€1.20	No	300
02/06	A	Water	110	€1.20	No	250
03/06	A	Water	180	€0.99	Yes	220
04/06	A	Water	150	€0.99	Yes	40

Look at the last row: 150 units sold, but only 40 in stock. If the stock figure covers the whole period, that is impossible. Perhaps the snapshot was taken before a delivery, or the two systems use different timestamps. Leila flags it for investigation, because data quality is not a side issue. It feeds directly into forecasting and optimization.

3.3 Sales are not always demand

A store has 100 bottles and sells all 100 before closing. Recorded sales: 100. Actual demand: perhaps 120, but the 20 missing sales are invisible. This is censored demand: observed sales are capped by available inventory.

Figure 4. On Thursday and Friday the shelf was empty before customers stopped coming. A model that treats those flat bars as “low demand” learns the wrong lesson.

Possible responses: flag stockout periods, estimate lost sales, use inventory availability during data preparation, apply statistical methods built for censored observations, or exclude observations that cannot reliably represent demand. The right choice depends on the data and the business context.

3.4 Avoid data leakage

If the features used to forecast next Monday include the actual sales recorded on that Monday, the model has seen the future. Offline results will look wonderful and production results will not. Every feature must be checked against the moment the forecast is generated.

Feature	Available at forecast time?	Consideration
Yesterday’s sales	Yes, if reporting is complete	Useful history
Price planned for next Monday	Yes, if the promotion calendar is final	Future-known feature
Actual weather next Monday	No	Use the weather forecast available at prediction time
Actual sales next Monday	No	That is the target, not a feature
Supplier delivery confirmed before the forecast	Potentially	Useful for replenishment decisions

3.5 Data architecture

Figure 5. A typical analytical pipeline. In a cloud setting, a warehouse such as BigQuery hosts the analytical datasets, with scheduled pipelines or streaming services feeding it.

The key principle is to separate historical analytical data (for training and evaluation) from the operational data needed to make today’s decision (current stock, open orders, today’s prices).

4. Demand forecasting: predicting the future

The data are ready, so Leila can finally build a forecasting model.

4.1 Define the forecasting problem

Let D_i,s,t be demand for product i in store s on day t. We want to estimate demand h days ahead:

D̂_i,s,t+h = f ( X_i,s,t , h )

X holds everything known when the forecast is produced: historical sales, day of week, season, prices, planned promotions, holidays, weather forecasts, product and store characteristics, recent trends. The function f can be a statistical model, a machine-learning model or a deep network.

4.2 What forecasting horizon should we use?

No horizon fits every problem. It must match the decision the forecast supports.

Business problem	Illustrative horizon	Typical granularity
Immediate store replenishment	Next 1–14 days	Daily
Distribution-center planning	Next 1–8 weeks	Daily or weekly
Seasonal purchasing	Next 3–12 months	Weekly or monthly
Financial planning	Next 6–24 months	Monthly or quarterly

These are illustrative ranges, not industry standards. The right choice depends on supplier lead times, ordering frequency, shelf life, seasonality and how fast the business can react.

The lead-time rule of thumb

If a supplier needs 10 days to deliver bottled water, tomorrow’s forecast is useless for today’s purchase. The retailer needs to understand demand over the window during which it cannot replenish. The relevant horizon is at least lead time plus review period.

4.3 Training window, forecasting horizon, forecast frequency

Three ideas that are constantly confused:

• Training window: the history used to fit the model.
• Forecasting horizon: how far ahead the model predicts.
• Forecast frequency: how often new forecasts are generated.

FreshMart might train on three years of sales, forecast the next 14 days, refresh the forecast every morning, and retrain weekly. Four separate design choices. A model can produce fresh predictions daily without being retrained daily.

4.4 A rolling forecasting example

Today is Monday and the system needs 14-day forecasts. Tuesday, yesterday’s sales join the dataset, new inventory arrives, and the same model forecasts again from a one-day-later origin.

Figure 6. A rolling forecasting process: the forecast is refreshed as new information arrives.

4.5 Which forecasting algorithms should we consider?

Family	Examples	Good for
Baselines	Naive, seasonal naive, moving average	The bar to beat. Seasonal naive predicts next Monday with last Monday.
Statistical	Exponential smoothing, ARIMA/SARIMA, regression, state-space	Trend, seasonality, autocorrelation, interpretability
Machine learning	Random Forest, XGBoost, LightGBM, CatBoost	Nonlinear effects of price, promotion, store and calendar across many series
Deep learning	RNNs, temporal convolutions, Transformer-based forecasters	Very large datasets with complex temporal dependencies

Complexity does not guarantee better business performance. A well-engineered gradient-boosting model can beat a fancier architecture on a given retail dataset. Establish the answer empirically, and remember that a sophisticated model earns its place only by beating the simple baseline meaningfully.

4.6 Forecasting uncertainty

A point forecast of 500 does not mean demand will be exactly 500. The model may instead provide a distribution or a prediction interval, for instance: expected demand 500, lower bound 420, upper bound 610. How to read the interval depends on how it was built and its intended coverage.

Figure 7. The point forecast is the line; the band is the plausible range. The band widens with the horizon, and the amber zone shows the period during which an order already placed cannot be changed.

This matters because the cost of under-forecasting rarely equals the cost of over-forecasting. Forecast uncertainty becomes an input to the decision, not just an evaluation statistic.

4.7 Validate the forecasting model correctly

Randomly splitting a time series into train and test sets leaks the future into the past. The usual remedy is rolling-origin backtesting: train on everything up to a date, test on what follows, then move the origin forward and repeat.

Figure 8. Rolling-origin backtesting evaluates the model over several periods instead of one arbitrary test set.

Also evaluate each forecast horizon on its own (tomorrow may be accurate while two weeks out is not), and evaluate by product group and store. Strong aggregate metrics can hide poor results for individual products.

Deliverable

A forecasting system that produces reliable demand estimates at the granularity and horizon the business actually needs.

5. From predictions to actions: designing a decision policy

Leila now has forecasts. What should FreshMart do with them? This is the move from predictive analytics to decision-making.

5.1 What is a decision policy?

A policy maps the current state of a system to an action:

a_t = π ( s_t )

In replenishment, the state s_t may include current inventory, forecast demand, incoming orders, lead times, budget and storage capacity. The action a_t is the order quantity, the supplier, or the timing. A policy is the logic that turns information into decisions.

5.2 Example: a simple replenishment policy

A store has forecast demand of 500 over the relevant period, 150 units in stock, 50 on order and a target buffer of 100.

Q = max ( 0 , D + B − I − O ) = max ( 0 , 500 + 100 − 150 − 50 ) = 400

(D forecast demand, B buffer, I inventory on hand, O incoming orders.) A fine starting point, but it silently assumes all quantities refer to compatible periods and that the buffer is appropriate. It ignores order costs, supplier constraints, perishability and delivery timing.

5.3 Static rules versus dynamic policies

A static rule says: “When stock drops below 100, order 300.” Simple, cheap, sometimes perfectly good. A dynamic policy also looks at forecast demand over the lead time, demand uncertainty, incoming orders, shelf life and supplier availability, so it can recommend different quantities on different days. Static rules are not necessarily bad; the question is whether they adequately represent the business problem.

5.4 The reorder point

ReorderPoint = ExpectedDemandDuringLeadTime + SafetyStock

With expected demand of 50 units per day, a 4-day lead time and 40 units of safety stock: 50 × 4 + 40 = 240 units. When the inventory position reaches 240, an order is triggered.

Figure 9. The classic inventory sawtooth. An order is placed when stock reaches the reorder point; during the lead time, demand keeps eating stock; the safety buffer absorbs surprises so the delivery lands before the shelf runs dry.

Go deeper: where does the safety stock come from?

Under a simple normal-demand assumption, safety stock is SS = z · σ_L, where z is the standard-normal value for the target service probability and σ_L is the standard deviation of demand over the lead time. For a 98% target, z ≈ 2.05. If daily demand has a standard deviation of 12 units and the lead time is 4 days, σ_L = 12 × √4 = 24, so SS ≈ 49 units and the reorder point becomes about 249. The 40 used above is a given round number. In practice, σ_L should come from forecast errors, which is another reason to keep forecast uncertainty as a first-class output.

Note that inventory position is not always the same as physical stock on hand: depending on the policy, it includes incoming orders and subtracts quantities already committed. The definition must match the company’s actual replenishment process. And remember: the reorder point is a decision rule, not a forecasting model.

6. Inventory optimization: choosing the best order quantity

A reorder rule is useful, but it does not necessarily minimize total cost. To do better, Leila formulates an optimization problem.

6.1 Why optimize?

Order too little and customers find empty shelves. Order too much and storage costs and waste climb, while budget disappears that other products needed. With Q as the order quantity, a simplified objective is:

min_Q [ C_purchase(Q) + C_holding(Q) + C_stockout(Q) + C_waste(Q) ]

The exact expression of each term depends on the business. Purchase cost depends on quantity and supplier price; holding cost on inventory carried over time; stockout cost on unmet demand; waste cost on product expiring unsold.

Figure 10. A schematic of the central trade-off. Ordering more cuts stockout cost and raises holding and waste cost; the optimizer looks for the bottom of the U.

6.2 Linear Programming

Linear Programming (LP) applies when the objective and constraints are linear in continuous decision variables. Say FreshMart buys a product from two suppliers. Let x₁ and x₂ be the units from each. Supplier 1 charges €2.00 and can supply at most 600; supplier 2 charges €2.20 and can supply at most 500; the store needs at least 900 units.

min 2x₁ + 2.2x₂    s.t.   x₁ + x₂ ≥ 900,   0 ≤ x₁ ≤ 600,   0 ≤ x₂ ≤ 500

The cheapest solution is x₁ = 600 and x₂ = 300, for a cost of 600(2) + 300(2.2) = €1,860. The same problem in code takes a few lines with Google OR-Tools:

from ortools.linear_solver import pywraplp

solver = pywraplp.Solver.CreateSolver("GLOP")      # an LP solver
x1 = solver.NumVar(0, 600, "x1")                   # supplier 1, capacity 600
x2 = solver.NumVar(0, 500, "x2")                   # supplier 2, capacity 500

solver.Add(x1 + x2 >= 900)                         # demand constraint
solver.Minimize(2.0 * x1 + 2.2 * x2)               # purchasing cost

status = solver.Solve()
if status == pywraplp.Solver.OPTIMAL:
    print(x1.solution_value(), x2.solution_value(), solver.Objective().Value())
    # 600.0 300.0 1860.0

Notice the structure: variables, objective, constraints, solve, check the status. Every optimization service in the rest of this guide is a bigger version of these ten lines.

6.3 Mixed-Integer Linear Programming

Real purchasing involves yes/no choices. A supplier may demand a minimum order if selected at all. Introduce a binary variable y_j (1 if supplier j is used, 0 otherwise) and link it to the quantity with a minimum m_j and capacity M_j:

m_j y_j ≤ x_j ≤ M_j y_j     min ∑_j ( c_j x_j + f_j y_j )

If y_j = 0, the quantity is forced to zero. If y_j = 1, it must lie between the minimum and the capacity. Here c_j is the unit cost and f_j an optional fixed activation cost. Integer variables make this a Mixed-Integer Linear Program (MILP), widely used in purchasing, supplier selection, facility planning, production scheduling and distribution.

6.4 The objective function must represent real business costs

The hardest modeling question is what belongs in the objective. A comprehensive version might include purchase, transport, holding, stockout, waste and ordering costs. But beware of double-counting, and of arbitrary penalties that match no real consequence. If stockouts are simply unacceptable, a service-level constraint is more honest than an invented price per missing unit. If stockouts have a measurable financial impact, an explicit penalty is appropriate.

6.5 Hard constraints versus soft penalties

A hard constraint must hold: spend ≤ €50,000. A soft constraint is a preference that can be violated at a price: “we prefer the 3-day supplier, but a slower one is acceptable if necessary.” Soft constraints are modeled with penalties; hard ones require you to handle the case where no feasible solution exists. A mathematically optimal solution is only useful if the model represents the business requirements accurately.

7. Supplier selection: choosing whom to buy from

Inventory optimization decides quantities and timing. Procurement optimization decides who supplies them. FreshMart needs 10,000 units of a product and has three candidate suppliers (illustrative figures):

Supplier	Unit price	Max capacity	Lead time	Minimum order
Supplier A	€2.00	6,000	3 days	1,000
Supplier B	€1.85	5,000	7 days	2,000
Supplier C	€2.10	8,000	2 days	500

By unit price alone, B wins. But B is slow, and if the product is needed soon, delay becomes stockout risk. C is dearer and fast. A sits in between. The right answer depends on requirements, so let us see how the optimizer answers two different questions.

Figure 11. The same suppliers, two business requirements, two different optimal plans.

7.1 Supplier scoring versus supplier optimization

Supplier scoring ranks suppliers on price, delivery history, quality, reliability, location, sustainability and contract terms, for example:

Score_j = w₁ PriceScore_j + w₂ QualityScore_j + w₃ ReliabilityScore_j

The weights express relative importance. Useful, but the best-scoring supplier is not necessarily part of the best allocation for the whole purchasing problem. Supplier optimization decides how much to buy from each supplier, considering all decisions at once:

min ∑_j c_j x_j    s.t.   ∑_j x_j ≥ D,   x_j ≤ Capacity_j

with further constraints for minimum orders, delivery requirements, budgets and supplier eligibility. A ranking sorts suppliers; an allocation model solves a global problem. In practice the two combine well: scores for qualities that are hard to price (reliability, sustainability) can feed the optimizer as eligibility rules or penalties.

7.2 Does supplier cost belong in the formula?

Yes, but unit price alone is rarely enough. Total relevant cost may include purchase, transport, inventory, quality, delay and ordering costs. Not every component belongs in every model: a quality penalty only makes sense if quality differences can be measured, and a delay penalty should reflect the real consequence of late delivery rather than an arbitrary number.

7.3 How do we account for lead time?

If we need product tomorrow and Supplier A takes three days, neither supplier helps. If we are planning for next week, B becomes viable. An optimizer may need to model when the order is placed, when it arrives, whether it arrives before demand occurs, current stock and incoming orders, expedited-delivery options and delay risk. With uncertain delivery times, scenarios or safety buffers come in. A crucial point: delivery time cannot always be handled as a simple cost penalty. If the delivery must arrive before a deadline, timing becomes an explicit feasibility constraint, exactly as Case 2 above treated it.

7.4 What if the cheapest supplier cannot provide enough?

Supplier A may be cheapest but offer only 6,000 of the 10,000 units. The optimizer fills the rest from the next eligible supplier. With a pure cost objective it takes as much as possible from the cheapest source, then the next. Real procurement adds delivery deadlines, contracts, quality requirements, concentration limits and uncertainty.

7.5 Single sourcing versus multiple sourcing

One supplier simplifies logistics; several reduce dependency. Both are policy choices, and a model can encode either with a cap on the number of suppliers, fixed activation costs, minimum or maximum allocation shares, eligibility constraints, or risk penalties when they can be meaningfully quantified. A rule such as “no supplier may account for more than 70% of a category” reshapes the feasible region, and the optimizer cannot simply pick the cheapest source if that violates it.

8. Optimization algorithms: how does the computer find a solution?

Once the problem is formulated, we need an algorithm or solver. No single one suits every problem; the choice depends on the structure of the objective and constraints, the problem size and the time available.

8.1 Mathematical programming

Family	Use it when	Retail example
Linear Programming (LP)	Linear objective and constraints, continuous variables	Splitting a purchase across suppliers
Mixed-Integer LP (MILP)	Discrete choices are part of the decision	Use a supplier or not; open a warehouse; number of vehicles
Nonlinear Programming	Nonlinear objective or constraints	Demand that responds nonlinearly to price
Quadratic Programming	Quadratic objective, linear constraints	Risk-aware allocation
Constraint Programming	Complex logic and scheduling	Delivery schedules with time windows and precedence
Stochastic / Robust optimization	Uncertain demand, capacity or delivery	Orders that hold up across scenarios

8.2 What do solvers actually do?

For LP, common methods are the simplex and interior-point methods. For mixed-integer problems, solvers use branch-and-bound, branch-and-cut, cutting planes and presolve techniques. These are different tools for different parts of the problem, not synonyms. In practice, data scientists and OR specialists formulate the model and hand it to a solver rather than implementing these algorithms from scratch.

8.3 Heuristics and metaheuristics

For very large problems, complicated constraints or strict time limits, heuristics may be the practical choice.

• Genetic algorithms evolve a population of candidate solutions by selection, crossover and mutation.
• Simulated annealing explores alternatives and sometimes accepts worse ones to escape local optima.
• Tabu search uses memory to avoid cycling through solutions already explored.
• Large Neighborhood Search repeatedly destroys and rebuilds parts of a candidate solution.

They can find high-quality solutions, but generally give no guarantee of global optimality. And do not assume a heuristic beats an exact solver on a big problem: modern solvers handle many substantial models very well. Test it.

8.4 Stochastic optimization and the newsvendor

Demand, supplier availability and delivery times are rarely certain. Stochastic optimization represents uncertainty explicitly, often through scenarios and probabilities. Suppose demand for one period has three scenarios:

Scenario	Demand	Probability	Cumulative
Low	350	20%	20%
Normal	500	50%	70%
High	700	30%	100%

E[D] = 0.2(350) + 0.5(500) + 0.3(700) = 525

Yet ordering exactly 525 is not necessarily optimal. The best quantity depends on the relative cost of having too much versus too little. The classic newsvendor model captures this with a critical ratio:

CR = C_uC_u + C_o   →   order the smallest Q with   P(D ≤ Q) ≥ CR

C_u is the cost of one unit too few (lost margin), C_o the cost of one unit too many (what you paid and cannot recover). Consider two products using the scenarios above:

• Fresh milk: margin lost per missing unit €0.60, loss per expired unit €1.00. CR = 0.60 / 1.60 = 0.375. The cumulative probability first exceeds 37.5% at 500, so order 500, below the 525 expectation.
• Bottled water in a heatwave: a missing unit costs €2.00 (margin plus lost customer goodwill), a leftover unit only €0.30 because it keeps. CR = 2.00 / 2.30 ≈ 0.87. The cumulative probability reaches 87% at 700, so order 700.

Figure 12. Same demand distribution, two products, two optimal orders. The costs of being wrong, not the average demand, set the quantity.

A retailer with expensive perishable stock leans conservative; one selling essentials accepts more inventory to protect availability. Related techniques include stochastic programming and chance-constrained optimization.

8.5 Robust optimization

Where stochastic optimization models uncertainty with probabilities or scenarios, robust optimization seeks decisions that stay acceptable across a specified set of conditions: demand above the central forecast, a supplier capacity cut. A robust plan is typically more conservative and more expensive than one tuned for expected conditions; the price buys protection against bad outcomes.

8.6 Machine-learning-based decision methods

ML can estimate future demand, stockout probability, supplier reliability, substitution effects or price response, and these estimates become inputs to a mathematical optimizer. Two further approaches deserve a mention.

Contextual bandits pick an action given the current context and learn from the observed reward. FreshMart might test approved promotion strategies in different contexts (category, stock level, season, customer segment) and learn which tends to produce better incremental profit under business constraints. Bandits suit repeated decisions with feedback, though they do not automatically capture long-term consequences.

Reinforcement Learning (RL) addresses sequential decisions, where today’s order changes tomorrow’s state:

s_t → a_t → r_t → s_t+1

The agent learns a policy that maximizes cumulative reward. But RL brings real challenges: learning safely without disrupting operations, building a trustworthy simulator, delayed rewards, enforcing business constraints, and checking that gains generalize beyond the training environment. When objectives and constraints are explicit, plain mathematical optimization is often simpler, more transparent and easier to validate.

8.7 Simulation-based optimization

When real operations are too complex for a closed formula, simulation lets us compare policies safely. FreshMart can simulate (1) fixed reorder thresholds, (2) forecast-based replenishment and (3) forecast-based replenishment with optimization under varied demand, supplier delays and stockout scenarios, then read off total cost, average inventory, stockout rate, waste and service level. A search algorithm can tune policy parameters. The caveat: the simulator must reflect real operations, or it will confidently mislead.

9. How the different algorithms work together

It is tempting to think a retail optimization system uses one algorithm. In reality it combines several, each solving one part of the problem. Back at FreshMart, Leila’s architecture looks like a relay race: every stage hands a better-informed baton to the next.

Figure 13. Each stage has a different job and a different technique. The architecture is conceptual: a real organization may merge stages or use capabilities already present in its ERP and supply-chain software.

Component	Main question	Possible technique
Demand forecasting	How much will customers buy?	Statistical models or ML
Uncertainty estimation	How variable might demand be?	Probabilistic forecasting
Inventory management	How much buffer stock is appropriate?	Inventory theory, stochastic optimization
Supplier allocation	How should quantities be split?	LP or MILP
Complex scheduling	How to schedule under constraints?	Constraint Programming, heuristics
Policy evaluation	What would happen under alternatives?	Backtesting and simulation
Sequential adaptation	How should decisions evolve?	Dynamic optimization, or RL where justified

Rule of thumb

A mature solution does not need every technique in this table. It needs the simplest combination that adequately solves the business problem.

10. Validating the decision policy: does it actually improve the business?

This may be the most important stage of the lifecycle. A forecasting model can be statistically accurate and still support poor decisions. Conversely, a model with slightly worse average accuracy can support better decisions if it handles uncertainty or business cost better. So we validate the forecast and the policy separately.

10.1 Forecast validation

Evaluate predictions with MAE, WAPE, bias, performance by horizon and performance across categories and stores. The question is whether the forecasts are reliable enough for the intended application.

10.2 Policy validation

Next, evaluate the decisions made from those forecasts. FreshMart’s current policy costs the figures below each year (illustrative). A historical simulation of Leila’s proposed policy gives:

Figure 14. A historical simulation of the two policies under the same conditions. The numbers are illustrative; the lesson is how to read them.

500 + 250 + 100 = €850,000  →  430 + 210 + 75 = €715,000  →  850,000 − 715,000850,000 × 100 ≈ 15.9%

It looks promising, but a good analyst asks hard questions first:

• Were both policies evaluated under the same demand conditions?
• Were lead times and stock constraints represented accurately?
• Were all relevant costs included, including the cost of implementing the new system?
• Does the simulation reproduce the real business process?
• Is the result driven by a few unusual periods?

Historical simulation provides evidence, not certainty.

10.3 Backtesting a policy

A policy backtest must reconstruct what the business knew at each decision point:

1. Load the information available at that time.
2. Forecast using only that information.
3. Apply the proposed policy.
4. Simulate or reconstruct the resulting purchasing and inventory.
5. Compare with the existing policy.
6. Repeat across many periods.

This prevents look-ahead bias. If the backtest uses next week’s observed weather to decide this week’s order, it overstates what the business could have known. Use the weather forecast that was available then.

10.4 Pilot deployment and controlled evaluation

Even a good backtest may miss real-world behavior. FreshMart can pilot the policy in selected stores, compare them with similar stores on the old policy, monitor the agreed KPIs, collect operational exceptions and user feedback, and expand if the results justify it. Where possible, controlled experiments give the strongest evidence, with a design that accounts for differences among stores, products and periods. The decision to scale should weigh measured benefits against implementation costs.

11. Deployment: turning a model into a working business system

A model is not a production solution just because it is accurate in a notebook. A production solution must obtain reliable data, run the calculations on schedule, deliver recommendations to the right business system and make results observable.

11.1 A reference architecture on Google Cloud

Figure 15. One possible Google Cloud design. It is a reference, not a requirement: a smaller retailer may need only scheduled SQL and simple pipelines, and a custom Python service may be enough where managed ML workflows would be overkill. Choose by workload, cost, operational requirements and existing infrastructure.

11.2 What happens inside the forecasting service?

1. Retrieve the latest validated input data.
2. Load the appropriate trained model.
3. Predict for the required horizon.
4. Produce uncertainty estimates, if the model supports them.
5. Check the outputs are valid.
6. Publish forecasts to the next stage.

It should also record the model version, prediction timestamp and relevant inputs so every decision can be traced and evaluated later.

11.3 What happens inside the optimization service?

It receives forecasts plus current inventory, existing purchase orders, supplier capacities, prices, lead times, budgets, warehouse constraints and business rules. It builds or updates the optimization problem, calls the solver and checks the result: does the solution satisfy the modeled constraints, are quantities valid, were all required products considered, is the solver status acceptable, and are infeasible or unresolved cases flagged? A solver’s output should never be treated as a valid business recommendation without checking the result and the assumptions behind it.

11.4 How do we expose the results?

Through an API, a dashboard, an ERP integration, a procurement workflow or a batch file for an existing planning system. Some retailers create purchase requisitions automatically; others require a buyer to approve each recommendation. The right degree of automation depends on risk, business rules and the demonstrated reliability of the solution.

12. SAP and enterprise systems: do we need to build everything ourselves?

Often, important parts of the workflow already live inside the ERP and supply-chain planning systems. SAP, for instance, offers products covering procurement, inventory management, demand planning and supply-chain planning, but the precise functionality depends on the products, versions, configuration and licenses a given organization has. A data scientist should investigate before proposing something parallel.

12.1 ERP versus advanced planning

An ERP system manages core processes and operational records: purchasing, stock movements, suppliers, financial transactions. Advanced planning systems add forecasting and optimization. A supplier quota arrangement, for example, distributes procurement by predefined rules, which is not necessarily the same as an optimizer evaluating every feasible allocation against a global cost function. Likewise, a demand forecast does not automatically yield an optimal purchasing plan. Actual capability depends on the specific planning component.

12.2 Where can data science add value?

Before building anything custom, Leila asks four questions, in this order:

1. Is the capability already available? Forecasting, inventory planning or optimization may already exist.
2. Is it configured correctly? Poor results often come from missing cost parameters, wrong lead times, unsuitable constraints or incomplete master data.
3. Is the data adequate? No optimizer can compensate for unreliable supplier capacities or inaccurate inventory records.
4. Is there a genuine modeling limitation? A specialized demand pattern, a custom objective or an unusual constraint the existing system cannot express.

Only then does the team decide whether to build a separate component. The best solution may be to improve the existing system rather than replace it.

13. Continuous improvement: what changes every day, and what should be retrained?

After deployment the system enters an operating cycle, and three things that sound alike must be kept apart.

13.1 Three separate processes

Process	What happens	Typical trigger
Forecast generation	A trained model produces new predictions	New data become available
Optimization	The decision problem is solved again	A new purchasing or replenishment decision is required
Model retraining	The model’s learned parameters are updated	A schedule, a drift signal or an evaluation criterion

Figure 16. Over four weeks: a fresh forecast every day from the same model, an optimization run for every decision (plus extra re-runs when the world changes), and retraining only on schedule or when drift is detected.

13.2 Daily forecasting does not imply daily retraining

On Monday the model predicts the next 14 days. On Tuesday it uses the latest information to predict again. It may be exactly the same model, with identical learned parameters; only inputs and outputs changed. Retraining could be weekly, monthly or otherwise, depending on how stable demand is and how much new data adds. Establish the frequency empirically rather than picking it arbitrarily.

13.3 Optimization is often rerun more frequently

Even with an unchanged forecasting model, the optimizer may need to run again because stock changed, orders arrived, supplier availability or prices moved, the latest forecast differs from the last, or a purchasing deadline approaches. The objective function and constraints may stay the same while the input data change. That is not a change to the algorithm; it is a new solution to the current decision problem.

13.4 Model drift and retraining

Demand patterns move. A product becomes popular, a competitor opens nearby, a promotion shifts behavior, seasons slide, pricing strategy changes. Monitoring should track forecast error and bias, performance by product and store, input-distribution shifts, data quality and the business outcomes tied to the forecasts. If performance deteriorates persistently, find the cause before reaching for the retrain button: if a sales feed stopped reporting transactions, retraining on incomplete data makes things worse. Fix the pipeline first.

13.5 Policy drift and business changes

The decision policy needs monitoring too. If the forecasts stay accurate but a supplier raises prices, the old purchasing policy may no longer minimize cost. A new budget cap or service-level target may require updating the optimization problem. That is a different kind of change from forecasting drift. A useful monitoring framework separates five kinds of problem, each with its own response:

Figure 17. When a KPI slips, work through the possible causes in order. The cheapest and most upstream explanation comes first, and retraining is rarely step one.

14. The complete feedback loop: connecting KPIs, forecasting and optimization

KPIs are not just defined at the start of a project. They are also how the deployed system is evaluated and improved. Three interconnected loops run at different speeds.

Figure 18. Three loops at three speeds. Together they let the team localize a problem: is it the data, the forecast, the optimization or the business itself?

For example, if service level falls below target despite good forecast accuracy, the problem may be supplier constraints, the safety-stock policy or the optimization formulation rather than the forecasting model. Conversely, if the policy is sound but forecasts systematically underestimate demand, the forecasting component needs work. The loops tell you which part of the system deserves attention.

15. A complete worked example: optimizing bottled-water replenishment

Let us follow one hypothetical product through the whole lifecycle. FreshMart wants to improve replenishment of one bottled-water product across its stores: reduce total inventory-related cost while holding a 98% service level. All figures are illustrative.

Step	What Leila does
1. Business objectives	Three priorities: enough stock to serve customers, less excess inventory, controlled purchasing spend. The primary objective is minimizing modeled inventory and procurement cost, with a service-level constraint and a purchasing budget.
2. KPIs	Forecast WAPE and bias, service level, stockout rate, average inventory value, holding cost, waste cost, purchasing spend. Baseline performance is recorded before anything changes.
3. Data	Combines sales, inventory, incoming orders, prices, promotions, supplier lead times and capacities, warehouse constraints. Checks missing values, duplicates, timestamp inconsistencies, stockouts and future-known features. Result: daily product-store observations.
4. Forecast	Compares seasonal naive, a statistical model and gradient boosting by rolling-origin backtesting. Picks the one with suitable accuracy and operational characteristics, not the fanciest. Produces 14-day forecasts plus uncertainty where the decision needs it.
5. Baseline policy	Q = max(0, 500 + 100 − 150 − 50) = 400 units: simple, explainable, and a benchmark.
6. Optimization	Variables xj (and binaries if minimums or activation costs exist). Objective: purchase, transport, holding, stockout and waste costs where they can be modeled. Constraints: demand and inventory, capacities, minimum orders, delivery timing, budget, service level, warehouse space.
7. Validation	Backtests against the existing policy on cost, service level, stockouts, inventory, waste and spend; checks robustness across stores, products and demand regimes; then a limited pilot.
8. Deployment	Each morning: load data, forecast, optimize, check against business rules, send approved recommendations into procurement, record outcomes.
9. Monitoring	Tracks model metrics and business outcomes. If accuracy holds but stockouts rise, look at inventory and procurement decisions before retraining. If hot weather is systematically under-forecast, improve features or uncertainty handling. If a supplier’s lead time changes, update the optimizer inputs.
10. Improvement	Retrain when justified, recalibrate safety stock, update supplier costs, refine the formulation, adjust service targets, improve data checks, and strengthen deployment and monitoring.

The essential lifecycle of a decision system

Predict, decide, execute, measure, improve. Then do it again.

16. Practical implementation: what should a data scientist build first?

For anyone building these skills, I recommend growing the solution step by step rather than attempting an autonomous supply-chain platform on day one. Each stage below produces something you can show, and each prepares the next.

Stage	Build	What you learn
1. Forecasting baseline	Data validation, exploration, seasonal naive plus one statistical or ML model, rolling-origin backtests, MAE/WAPE/bias	How to produce forecasts you can evaluate reliably
2. Basic inventory policy	Current stock, incoming orders, lead times, a reorder point and safety stock; test on history	How forecast outputs influence decisions
3. Mathematical optimization	A small LP with a few products and suppliers in OR-Tools or Pyomo; add integer variables only when decisions demand them	How an optimization model differs from hand-written rules
4. Compare policies	Existing vs forecast-based vs optimization-based policy, same history, comparable costs	Whether sophistication actually pays
5. Uncertainty and simulation	Demand scenarios, supplier delays, stockout costs, perishability, budget limits	Robustness instead of single-scenario thinking
6. Production architecture	Reproducible pipeline, forecasting and optimization services, results warehouse, KPI dashboard, logging, monitoring, model and policy versioning (on GCP: BigQuery, scheduled pipelines or Dataflow, Cloud Run, suitable ML and monitoring services)	Connecting analytics into a reliable decision workflow

17. The most important lessons

1. Start with the business decision, not the algorithm. Understand what the company wants before choosing a forecasting model or optimization technique.
2. Define KPIs carefully. Separate objectives, constraints, forecasting metrics and diagnostics, and establish a baseline before claiming improvement.
3. Forecasting and optimization solve different problems. One estimates demand; the other chooses decisions from forecasts, costs, constraints and requirements.
4. A decision policy is not necessarily an optimization algorithm. It may be a simple rule, an optimization-based process or a learned strategy. Use the simplest approach that adequately solves the problem.
5. Optimization is not one algorithm family. LP, MILP, stochastic optimization, heuristics, simulation and RL address different problems.
6. Supplier selection is a decision problem, not just a ranking. Price, capacity, lead time, minimums and reliability may need a global allocation model.
7. Validate decisions, not just predictions. Lower forecast error does not automatically mean lower cost or fewer stockouts.
8. Production systems have multiple feedback loops. Forecast daily, optimize whenever a decision is due, retrain when justified, and let objectives and constraints evolve.
9. Integration is part of the solution. A model that never reaches the operational system cannot improve purchasing. Data quality, APIs, ERP integration, monitoring and workflows matter.
10. Evaluate existing enterprise software before building replacements. If the retailer has SAP or another planning system, understand its capabilities, configuration, data and limits first.

Conclusion

A mature retail data science system is much more than a forecasting model. It starts from business objectives and measurable KPIs, uses historical and operational data to estimate future demand, turns predictions into decision policies and applies suitable optimization techniques to allocate resources under real constraints. Its recommendations flow into operational systems and are judged against business outcomes. New information, changing conditions and observed performance then drive the next round of forecasting, optimization and improvement.

Understand the business → measure performance → prepare data → predict demand → design decisions → optimize actions → validate outcomes → deploy → monitor → improve.

The goal is not the most sophisticated model or the most advanced algorithm. It is a reliable system that helps the business make better decisions. That connection between data science, operations research and production engineering is exactly why understanding the whole lifecycle is so valuable for an industry-facing data scientist.

Glossary: quick definitions

Censored demand: demand that was never observed because stock ran out. Data leakage: using information at training or evaluation time that would not have been available when the forecast was made. Inventory position: stock on hand plus incoming orders minus committed quantities. Lead time: time between ordering and receiving. Newsvendor model: single-period ordering under uncertain demand, balancing the cost of too much against too little. LP / MILP: linear programming with continuous variables, or with some integer variables. Policy (π): a rule that maps the current state to an action. Rolling-origin backtest: repeated train-then-test evaluation with a moving cut-off date. Safety stock: buffer held to absorb demand and delivery variability. Service level: a defined measure of how well demand is fulfilled; always state the definition. WAPE: total absolute forecast error divided by total actual demand.