Aggregation Can Change the Decision

Aggregation is one of the easiest ways to make a supply chain model smaller.

It is also one of the easiest ways to make the model solve the wrong problem faster.

Suppose you have 50,000 item-location combinations. Someone proposes grouping similar products into families, solving at the family level, and allocating the answer back down afterward. The runtime drops from 20 minutes to 40 seconds. Everyone is happy.

Then the system starts making strange decisions.

One SKU is consistently overbought. Another is starved. A vendor minimum is satisfied in the aggregate but impossible to execute with real case packs. A capacity constraint looks loose in the model even though the warehouse keeps hitting it. The forecast looks smoother and more accurate at the family level, but realized economics get worse.

None of this is surprising.

Aggregation does not merely remove rows from a table. It can remove distinctions that matter to the decision.

Start with what must actually be decided

The first question is not, “What can we aggregate?”

The first question is, “At what level does the business take an action?”

If the business orders SKU (i) from vendor (v) in period (t), a basic decision variable is

[ x_{i,v,t} = \text{units of SKU } i \text{ ordered from vendor } v \text{ in period } t. ]

If orders must respect case packs, minimum order quantities, supplier capacity, item-specific lead times, costs, and inventory positions, those details live at or below the level of the executable action.

Now imagine replacing all SKUs in product family (g) with one aggregate variable:

[ X_{g,v,t} = \sum_{i \in g} x_{i,v,t}. ]

Mathematically, that looks harmless. Operationally, it may be a completely different decision.

The aggregate model knows how much to buy for the family. It does not necessarily know which SKU should receive those units. If the disaggregation step is economically important, then part of the optimization problem has simply been pushed downstream.

That is fine if you acknowledge it. It is dangerous if you pretend it disappeared.

The test for safe aggregation

Two things are safe to aggregate only when the distinctions between them cannot materially change the action you care about.

That is a much stronger requirement than “they look similar.”

Before combining products, locations, periods, or scenarios, ask:

• Do they have the same feasible actions?
• Do they face the same constraints?
• Do they have similar marginal economics?
• Do they respond similarly to uncertainty?
• Can the aggregate answer be converted back into executable decisions without another hard optimization problem?
• If I swap one unit between the members of the group, does the business value remain approximately unchanged?

If the answer to those questions is no, aggregation is not just compression. It is an approximation.

Approximations can be excellent. They just need to be treated like approximations.

A simple example

Consider two products, A and B.

Both sell 100 units per week on average. At first glance they look like obvious candidates for aggregation.

But A has a gross margin of $40, a case pack of 10, a two-week lead time, and stable demand. B has a gross margin of $8, a case pack of 60, an eight-week lead time, and highly intermittent demand.

If you combine them into a 200-unit-per-week family, you have created a clean forecast and a smaller model.

You have also erased most of the information that determines how much of each item should be purchased.

The aggregate demand may be predictable precisely because errors cancel. That does not mean the executable SKU-level decisions are predictable.

This distinction matters constantly in supply chain work. Forecastability at one level does not imply decisionability at that level.

Aggregating demand changes uncertainty

Aggregation often improves forecast metrics. That is real, but it can be misleading.

If item-level forecast errors are imperfectly correlated, positive errors on one item can offset negative errors on another. The variance of aggregate demand is

[ \operatorname{Var}\left(\sum_i D_i\right) = \sum_i \operatorname{Var}(D_i)

• 2\sum_{i<j}\operatorname{Cov}(D_i,D_j). ]

When correlations are low, relative uncertainty can shrink substantially after aggregation.

That is useful if inventory is genuinely pooled.

If inventory is not pooled, the benefit may be fake.

Ten units of excess inventory for a black shoe in size 8 do not necessarily cover a shortage of ten units in size 11. A family-level forecast can look fantastic while the item-level system still stocks out.

The physical substitutability of inventory matters more than the statistical convenience of the aggregate forecast.

This is why I would never choose a forecasting hierarchy independently from the decision hierarchy. The question is not simply where the forecast is most accurate. The question is where uncertainty must be represented to make the action correctly.

Time aggregation has the same problem

The same issue appears when weekly periods become monthly periods.

Monthly aggregation can reduce a 104-week MILP to 24 periods. Great.

But suppose supplier capacity is 1,000 units per week. A monthly constraint of 4,000 units does not preserve the weekly constraint if production cannot actually be shifted freely across weeks.

The monthly model may schedule 3,500 units in a month and call the plan feasible even though 2,000 of those units are required in the first week.

Lead times can also become distorted. A three-week lead time is not naturally a one-month lead time. Promotions, holidays, outages, transportation cutoffs, and expiration dates can disappear inside a bucket.

A useful compromise is mixed resolution: model near-term periods weekly or daily, then aggregate farther into the future where exact timing has less influence on today’s decision.

Again, resolution should follow decision sensitivity, not calendar aesthetics.

Constraints are where aggregation usually breaks

Objective functions get most of the attention, but constraints are often the bigger problem.

Suppose a vendor has a $25,000 minimum purchase requirement. At the vendor level, aggregation may be perfect because the constraint itself is vendor-level.

But suppose each SKU also has a different MOQ:

[ x_i \in {0, q_i, 2q_i, 3q_i, \ldots}. ]

An aggregate recommendation of 1,300 units may have no feasible SKU-level decomposition once the (q_i) values are applied.

The same issue appears with pallet quantities, truck loading, shelf capacity, item-specific storage requirements, production setups, expiration, supplier calendars, and substitution rules.

If the aggregate solution cannot always be mapped to a feasible detailed solution, then the aggregate feasible region is a relaxation of the real one.

That can still be useful. In fact, it can be very useful for bounds, decomposition, screening, or generating a starting point. But you should know what role it is playing.

Do not hide the disaggregation problem

A common architecture is:

1. Forecast and optimize at an aggregate level.
2. Allocate the aggregate decision to detailed items using a simple rule.
3. Send the detailed result downstream.

The dangerous part is step two.

If step two says “allocate proportional to forecast,” you have embedded a policy whether you intended to or not.

If it says “allocate proportional to historical sales,” same thing.

If it says “give every SKU the same weeks of supply,” same thing.

Those rules can dominate the economics of the final decision.

If detailed allocation is constrained and economically meaningful, model it explicitly or treat it as a second optimization stage. For example, an aggregate model might determine vendor-level spend or capacity envelopes, while a detailed model allocates those envelopes across SKUs using item-level marginal value.

That is a legitimate decomposition. Pretending the second stage is clerical is not.

Aggregation can be part of a good decomposition

None of this means every production model should operate at maximum granularity.

That would be a terrible rule.

Large systems often need hierarchy. The trick is to preserve the structure that matters.

One practical pattern is to use an aggregate model for scarce shared resources and a detailed model for local decisions.

For example, let

[ C_v = \text{capacity assigned to vendor or category } v. ]

A top-level model can allocate scarce budget, storage, or production capacity across groups. Then detailed subproblems decide item-level quantities subject to those envelopes.

This works best when cross-group interactions are limited and the subproblem can return useful information about the marginal value of more capacity.

You can even iterate: solve the master allocation, solve detailed subproblems, update marginal values or cuts, and solve again. That is the basic intuition behind several decomposition methods, although you do not need a textbook decomposition algorithm to benefit from the architecture.

The important point is that aggregation is deliberate and the detailed economics are allowed to push information back upward.

What about MILP runtime?

Aggregation is often proposed because the detailed MILP is too slow.

Before aggregating away business structure, profile what is actually making the model hard.

A model with ten million continuous inventory-balance variables may solve more easily than a much smaller model with weak binary logic, symmetry, loose big-M values, and nested activation decisions.

Count variables and constraints, but also inspect:

• binary and general integer variables;
• root relaxation quality;
• coefficient ranges;
• presolve reduction;
• node count and incumbent progress;
• repeated structures that create symmetry;
• model-building time versus solver time;
• data structures that are expensive before the solver even starts.

Sometimes aggregation is the right answer. Sometimes the model is slow because the formulation is weak. Sometimes the optimizer is fine and 70% of runtime is spent constructing a giant business-rule tree in application code.

Do not compress the decision space until you know which problem you are fixing.

Evaluate decisions, not just runtime

If you introduce aggregation, benchmark it as a policy approximation.

Take historical decision dates or simulated states. At each date, build both the detailed and aggregate information sets using only information available at that time. Generate the decisions, execute them in the same simulated future, and compare realized outcomes.

Track at least:

• realized profit or total economic cost;
• stockouts or lost sales;
• holding and disposal cost;
• expedites;
• capacity and constraint violations after disaggregation;
• decision stability;
• runtime and memory;
• the frequency with which the detailed decision materially differs from the aggregate one.

The last metric is especially useful.

If aggregation reduces runtime by 95% and changes economically meaningful decisions in 0.2% of states, you may have a fantastic approximation.

If it changes 30% of purchase decisions near MOQ, capacity, or inventory boundaries, the speedup is probably buying you the wrong thing.

Failure modes I see repeatedly

The first is aggregating because the forecast is better at the aggregate level. A smoother forecast is not enough. Inventory, constraints, and actions also need to support that aggregation.

The second is solving at the family level and treating disaggregation as a reporting step. If the detailed allocation changes economics, it is part of the policy.

The third is preserving average parameters. The average lead time, average margin, average MOQ, or average holding cost may describe no real item in the group.

The fourth is aggregating constraints incorrectly. Capacity that is interchangeable across a month can be summed. Capacity tied to specific weeks often cannot.

The fifth is evaluating only solver runtime and objective value. The aggregate objective is not directly comparable if it represents a different feasible region or different economics.

The sixth is assuming the most detailed model is automatically best. Detail that cannot affect the executable action can create cost without value. Granularity is not a virtue by itself.

What I would do in practice

I would start with the executable decision and draw the hierarchy around it.

For each candidate aggregation dimension—item, location, vendor, period, scenario, customer, lane—I would document what information disappears when the grouping happens.

Then I would classify that lost information into three buckets.

The first bucket is irrelevant detail: information that cannot materially alter feasibility or economics. Aggregate it aggressively.

The second bucket is detail that matters only far from the current decision. Use coarser resolution where appropriate, especially in long planning horizons.

The third bucket is decision-critical detail: MOQs, packs, margins, substitutability, lead times, binding capacities, or uncertainty that can flip the action. Preserve it, or build a decomposition that brings its economic effect back into the higher-level decision.

Finally, test the approximation end to end. Do not stop at “the model solves faster.” Replay the resulting policy through realistic uncertainty and measure what the business would have experienced.

The practical rule

Aggregate where distinctions do not matter to the decision.

Keep detail where they do.

That sounds obvious, but it is a much better design principle than aggregating wherever the data happens to have a convenient hierarchy.

A smaller optimization model is valuable only if it preserves the economics of the action you actually need to take.