AI for Supply Chain Optimization: Manufacturing Case

Summary. AI for supply chain optimization replaced a spreadsheet-driven planning cycle at a mid-market industrial manufacturer serving India and the GCC, rebuilding demand forecasting and inventory policy across roughly 4,000 SKUs and projecting a 30–35% reduction in stockout events on A-class items.

Executive Summary

AI for supply chain optimization replaced a spreadsheet driven planning cycle at a mid market industrial manufacturer serving India and the GCC. Forecasts were produced monthly by hand. Safety stock was set by judgement. The result was simultaneous stockouts on fast movers and a warehouse full of slow moving inventory.

YlogX was engaged to rebuild demand planning and inventory policy across roughly 4,000 active stock keeping units, three plants and four distribution points.

The work started with segmentation rather than modelling. Once demand was grouped by volume, variability and lead time, it became clear that a single forecasting approach could never have worked across the whole catalogue.

A hierarchical forecasting layer was built on the segmented catalogue, feeding an inventory optimisation step that sets reorder points and safety stock per segment and per location.

Projected outcomes include an estimated 30 to 35 percent reduction in stockout events on A class items and an estimated 18 to 22 percent reduction in working capital tied up in C class inventory. Every figure here is modeled, not measured.

Planning next quarter on a spreadsheet that nobody trusts? Talk to us.

Client Overview

The client manufactures industrial pumps, valves and flow control assemblies. It sells through distributors across India and into the GCC, with a growing direct book with engineering procurement contractors.

Three plants feed four distribution points. Roughly 4,000 stock keeping units are active in a given quarter, and the long tail runs well beyond that once discontinued spares are counted.

Demand splits into two very different patterns. Project driven orders arrive in large lumps with long lead times. Spares and replacement demand is small, frequent and hard to predict.

The planning team was five people. They produced a monthly consensus forecast in a spreadsheet, then adjusted it in review meetings with sales. That process took most of a working week every month.

The enterprise resource planning system held reorder points and safety stock values that had been configured during implementation. Nobody could say when they had last been reviewed.

Business Challenges

Everyone in the business knew the plan was wrong. Nobody could say which part of it was wrong, because accuracy was only ever measured at total company level, where the errors cancelled each other out.

Four problems were compounding, and the reporting hid all four of them.

Why did forecast accuracy keep falling?

Because the forecast was built at the wrong level. A single monthly number per product family was disaggregated to stock keeping units using last year proportions, which had stopped being representative.

Project demand and spares demand were forecast together. Those two patterns behave nothing alike, and averaging them produces a number that describes neither.

Accuracy was reported at total company level, where a large over forecast on one family cancelled a large under forecast on another. The headline number looked acceptable every month.

When accuracy was recalculated per segment and per location during the assessment, the picture changed completely. Fast moving spares were the worst performing group by a wide margin.

What was actually causing the stockouts?

Not demand volatility, which is what the team believed. Supplier lead time variability was the larger driver, and it had never been modelled at all.

Reorder points assumed a fixed lead time per supplier. In practice lead times moved considerably between quarters, particularly for imported castings.

Safety stock was set as a flat number of weeks of cover across most items. That over protects steady items and badly under protects erratic ones.

So the same policy produced two failure modes at once. Stockouts on the items customers actually chased, and excess cover on items nobody was asking for.

Why had the ERP reorder points stopped working?

They had been configured once and never revisited. The catalogue had grown, the supplier base had changed and the demand mix had shifted toward spares.

There was no owner for the parameters. Planners could see them but changing them required a change request, so nobody changed them.

The system had no concept of segment. Every item was treated the same way regardless of value, movement or criticality to a customer line.

Reorder points also ignored the open project pipeline entirely, so a known upcoming demand spike had no effect on replenishment until it turned into an order.

What was the spreadsheet process costing the team?

About a working week per month across five planners, before any of the review meetings. That is the visible cost and it is the smaller one.

The hidden cost was that nobody could test an alternative. Rebuilding the spreadsheet to answer a what if question took days, so the question stopped being asked.

Version control was informal. Two planners could be working from different copies, and reconciling them consumed time that should have gone into exception handling.

Most damaging, the process left no record of why a number was overridden. Judgement was being applied constantly and none of it was being captured.

Measuring forecast accuracy only at company level? Read more about our approach at data science and machine learning capability.

Business Objectives

The brief was operational rather than technical. Reduce the stockouts customers were complaining about, release working capital from slow moving stock, and give the planners back most of the week they were losing.

What outcome did the business need first?

Service level on A class items was the first objective, because that was where customer escalations were coming from and where revenue was actually at risk.

Working capital was second. Finance had flagged inventory value as a constraint on the next capacity investment, and slow moving stock was the obvious place to look.

Planner time was third but it mattered more than the leadership team expected. Exception handling was being crowded out by routine number production.

The business also wanted the ability to answer what if questions inside a day. That capability had never existed and was treated as a genuine deliverable.

Why fix forecasting before touching inventory policy?

Because inventory optimisation consumes a forecast. Optimising safety stock against a forecast nobody trusts simply produces confidently wrong parameters.

The sequence was made explicit at the outset so that nobody expected inventory results in the first weeks of the engagement.

It also gave a clean measurement point. Forecast accuracy per segment could be validated before any replenishment parameter was allowed to change.

That ordering protected the programme politically. Planners could see the forecast improve before being asked to trust a system generated reorder point.

What defined success for this engagement?

Forecast accuracy measured per segment and per location, improving against a documented baseline rather than against a headline company number.

Reorder points and safety stock recalculated on a schedule with a named owner, so the parameters could never go stale again.

Planner override rate falling over time, which is the honest signal of whether a planning system is trusted.

And a what if capability the team could actually run themselves, without a data scientist sitting beside them.

Success also meant the client analytics team could retrain and redeploy without us, which was written into the handover criteria rather than assumed.

Want to know which SKUs are actually driving your stockouts? Start a conversation.

Solution Strategy

The approach was segment first, forecast second, optimise third. Most of the value came from the first step, which involved no machine learning at all.

Delivery ran on one of the YlogX solution accelerators, adapted to the client data model rather than rebuilt from nothing.

How was the demand hierarchy rebuilt?

The catalogue was segmented on three axes. Annual value, demand variability measured as coefficient of variation, and supplier lead time variability.

That produced nine working segments rather than one catalogue. Project driven items were separated from spares before anything else happened.

Forecasting then moved to the level where signal actually exists. Stable high volume items forecast well at item and location level. Erratic items forecast better at family level and get disaggregated.

Reconciliation across the hierarchy keeps the numbers consistent, so the total plan still adds up after every level has been forecast the way that level forecasts most accurately.

Which forecasting methods were chosen and why?

No single method was used, which is the point. Stable high volume items were handled with statistical time series methods that are cheap to run and easy to explain.

Intermittent spares demand was modelled with methods built for sparse series, because a standard time series model on mostly zero demand produces confident nonsense.

Gradient boosted models were used where external drivers mattered, taking in open pipeline, promotion calendars and installed base age.

Method selection per segment is automated and reviewed quarterly. Locking a method in permanently is how forecasting systems decay after the consultants leave.

How does AI for supply chain optimization set inventory policy?

Safety stock moved from a flat weeks of cover rule to a calculation driven by forecast error and lead time variability for that specific segment and location.

Target service levels were set differently by segment. Items on a customer production line carry a higher target than items with a ready substitute.

Reorder points now include the open project pipeline, so a known upcoming demand affects replenishment before it becomes an order.

The optimisation runs weekly and proposes parameter changes. It does not write directly to the planning system, which was a deliberate control decision.

How were the planners kept in control?

Every system generated number is a proposal. Planners can override it, and the system requires a reason code when they do.

Those reason codes became the most valuable data in the programme. They showed exactly where the model was missing something real.

Two of the reason codes led directly to model changes, including a customer specific seasonality effect nobody had documented anywhere.

Override rate is tracked as a headline metric. A falling rate means trust is building. A rising rate on one segment is an early warning, not a discipline problem.

Curious what segmentation would reveal in your catalogue? Read more at our AI consulting capability.

Technologies and Tools Used

The stack was chosen for what the client could operate after handover, not for what would look impressive in a slide. Two of the components were already licensed and unused.

What did the data layer look like?

Orders, shipments, returns, supplier receipts and the open project pipeline are ingested daily from the enterprise resource planning system into a cloud data warehouse.

Transformations are version controlled and tested, so a change to a business rule is reviewable rather than discovered later in a broken dashboard.

A feature layer holds the derived series that forecasting needs, including cleaned demand history with returns and intercompany movements removed.

Data quality checks run before every model execution. A failed check stops the run rather than producing a forecast on incomplete history.

Which modelling stack was used?

Python for the modelling work, with established statistical and gradient boosting libraries rather than anything bespoke.

Intermittent demand methods were implemented explicitly, since general purpose forecasting libraries handle sparse series poorly by default.

Model selection per segment runs as a scheduled job that scores candidate methods on a rolling holdout and records why the winner won.

Everything is reproducible from a configuration file. A planner question about why a number changed can be answered from the run record.

Nothing bespoke was written where a maintained library existed. Custom code the client cannot staff for is a liability at handover, not an asset.

How was the optimisation layer built?

Safety stock and reorder point calculations are expressed as an optimisation over forecast error, lead time distribution and target service level per segment.

The solver runs weekly and produces a proposed parameter set with the change from the current value and the reason for it.

Proposals flow to a review screen. Planners accept, adjust or reject, and accepted changes are written back to the planning system through a controlled interface.

Nothing writes to the enterprise resource planning system automatically. That boundary was set by the client and it turned out to help adoption considerably.

What did the operational setup cover?

Scheduled runs, alerting on failed data quality checks, and a weekly accuracy report broken down by segment and location.

Model performance is monitored for drift. A segment whose accuracy degrades for three consecutive cycles raises a flag for review.

Deployment is automated so a model change moves from test to production without manual copying of files.

Documentation was written for the client analytics team rather than for the project file, and handover included two working sessions on retraining. A weekly operations checklist was left with the analytics team, covering what to look at, what a healthy run looks like and who to call when it is not.

Implementation Process

The engagement ran about sixteen weeks from kickoff to handover, with a usable forecast in production well before the end. Nothing was held back for a single large release. Segmentation results were shared in week three and changed the conversation immediately.

How long did the first useful release take?

Roughly seven weeks to a production forecast for the A class segments, running alongside the existing spreadsheet rather than replacing it.

Running both in parallel for two cycles was essential. It gave planners a like for like comparison and removed the argument about whether the new numbers were better.

The inventory optimisation layer followed in week eleven, once forecast accuracy per segment had been validated against the holdout.

Full handover including documentation and retraining sessions closed at week sixteen. The client team ran the following cycle themselves.

How was the accelerator adapted to this client?

The accelerator supplied the pipeline structure, the segmentation logic, the model selection harness and the monitoring scaffolding.

What had to be built was the mapping from the client data model, the treatment of intercompany movements, and the project pipeline join, which was specific to their order process.

Adaptation took about three weeks of the sixteen. Building the same scaffolding from nothing would have consumed most of the engagement.

That is the honest case for accelerators. They do not remove the client specific work, they remove the work that is identical on every engagement.

How was model quality validated before go live?

On a rolling origin holdout rather than a single split, because a single split on demand data flatters whichever method suits that particular period.

Accuracy was reported per segment and per location, and the baseline was the client own historical forecast rather than a naive benchmark.

Segments where the new approach did not beat the existing process were reported as such. Two segments showed no meaningful improvement and were left on the existing method.

Reporting the misses mattered. It was the point at which the planning team started treating the numbers as something other than a vendor claim.

How was planner adoption managed?

Planners were in the room from week one, including during segmentation. They knew the catalogue better than any analysis did.

Training was run on their own data and their own exceptions, not on a demonstration dataset.

The override mechanism was presented as a feature rather than as a fallback, which changed how the team received the system.

One planner became the internal owner of parameter reviews. Naming that person before handover mattered more than any training session.

Progress was reviewed with the planners rather than reported about them, and two of their objections in week four changed the segmentation before it was frozen.

Wondering what sixteen weeks could change in your planning cycle? Talk to us.

Business Results

The figures below are estimated business outcomes, modeled on the engagement scope and on published industry benchmarks for comparable programmes. They are not audited client results, and they are presented as projections. Where a result is directional rather than quantified, it is described in words instead.

What changed on service levels?

• Stockout events on A class items are projected to fall by an estimated 30 to 35 percent once the revised parameters have run for two full replenishment cycles.

• The improvement is concentrated in fast moving spares, which was the worst performing segment before the work and the one customers escalated most often.

• Expedited freight, which the plant used to cover stockouts, is projected to reduce by an estimated 20 to 25 percent as a direct consequence.

• Service level on project driven items changed very little, which was expected. Those orders were never the constraint and the analysis said so early.

What changed on working capital?

• Inventory value held in C class items is projected to fall by an estimated 18 to 22 percent, released mainly by correcting flat weeks of cover on steady low value items.

• Total inventory value is projected to fall by a smaller estimated 8 to 12 percent, because safety stock on erratic critical items increased deliberately.

• That trade is the point of the exercise. Working capital moves from where it was doing nothing to where it protects a customer line.

• Finance was given the segment level breakdown rather than a single number, so the increase on critical items could be defended rather than questioned.

What changed for the planning team?

• The monthly number production cycle is projected to reduce from about a working week to roughly one day across the team, an estimated 75 to 80 percent reduction.

• That time moved to exception handling and supplier conversations, which is where planner judgement is actually worth something.

• What if analysis now runs in minutes. The team tested three demand scenarios during the first quarter after handover, which had never been possible before.

• Override rate on A class segments fell across the parallel run and the first two cycles after go live, which the team treats as the trust indicator.

What changed structurally?

• Replenishment parameters now have a named owner and a review schedule, so the drift that caused the original problem cannot silently repeat.

• Forecast accuracy is reported per segment and per location every week, and the company level number is no longer used to judge anything.

• Reason codes on overrides give the business a documented record of judgement that used to disappear into a spreadsheet.

• The client analytics team retrains models without assistance, which was the actual definition of success at handover.

Want a projection built on your own catalogue rather than a benchmark? Contact us.

Lessons Learned

The technically interesting parts of this engagement mattered least. Segmentation, ownership and parallel running carried the outcome.

What surprised the team most?

That supplier lead time variability, not demand volatility, was the larger cause of stockouts. The business had been certain it was the other way round. That measuring accuracy at company level had been hiding the problem for years—the headline number had looked fine every single month. That two segments showed no improvement at all from the new approach; reporting that honestly did more for credibility than any of the wins. That planners welcomed the system once override authority was explicit—the resistance everyone predicted never materialised.

What worked better than expected?

Segmentation. Nine segments and a per segment method beat every attempt to find one clever model for the whole catalogue. Running in parallel for two cycles cost two months of patience and removed every argument about whether the numbers could be trusted. Reason codes on overrides were added as an afterthought and became the richest source of model improvement in the project. Refusing to write automatically into the planning system—the control boundary that looked like a limitation—turned out to drive adoption.

What would be done differently next time?

Lead time variability would be modelled in week one rather than week six; it was the largest single driver and it was found late. The internal parameter owner would be named at kickoff rather than at handover, so that person is present for the decisions that shape their job. Accuracy baselines would be recalculated per segment before any commitment is discussed, since the company level baseline was misleading. The what if capability would ship earlier—it was the feature the business valued most and it arrived close to the end.

What should other manufacturers check first?

Recalculate forecast accuracy per segment and per location. If it is only reported at company level, the real picture is unknown. Find out when replenishment parameters were last reviewed and who owns them—in most plants the answer is never and nobody. Separate project demand from spares demand before judging any forecasting effort; averaging them describes neither pattern. Ask whether lead time variability is modelled anywhere—in most planning systems it is a fixed number per supplier, and that is rarely true.

Frequently Asked Questions

What does AI for supply chain optimization actually change?

It changes where the planning decision gets made. Instead of a monthly manual forecast and static reorder points, demand is segmented and forecast with a method suited to each pattern, then inventory policy is calculated from forecast error, lead time variability and a target service level per segment. Planners move from producing numbers to handling exceptions.

Why is SKU segmentation more important than the forecasting model?

Because different demand patterns need different methods. Stable high volume items, project driven lumpy demand and intermittent spares behave nothing alike. Applying one approach across a whole catalogue produces a forecast that fits none of them well. In this engagement segmentation delivered more improvement than any change of algorithm did.

How long does an engagement like this take?

This one ran about sixteen weeks from kickoff to handover, with a production forecast for A class segments live around week seven and inventory optimisation around week eleven. Roughly three weeks went on adapting a solution accelerator to the client data model. Timelines depend mostly on data availability, not on modelling complexity.

Should forecasting or inventory policy be fixed first?

Forecasting first, almost always. Inventory optimisation consumes a forecast, so optimising safety stock against numbers nobody trusts produces confidently wrong parameters. Fixing the sequence also protects the programme politically, because planners see forecast accuracy improve before they are asked to trust a system generated reorder point.

How is intermittent spares demand forecast?

With methods built specifically for sparse series, rather than standard time series models. A general purpose model applied to a series that is mostly zeros will produce confident and useless output. Spares are separated during segmentation and handled with intermittent demand methods, with results measured against the client historical forecast rather than a naive benchmark.

Do planners lose control when a system sets reorder points?

They should not. In this engagement every system generated number is a proposal, planners can override it, and the system requires a reason code when they do. Nothing writes automatically into the planning system. Those reason codes turned out to be the most useful data in the programme, because they showed exactly where the model was missing something real.

What data is needed to start?

Order and shipment history at item and location level, returns, supplier receipts with actual rather than planned lead times, and the open order pipeline if project demand exists. Cleaned demand history matters more than volume of history. Intercompany movements and returns usually have to be removed before anything is modelled.

Are the results in this case study real client figures?

No. They are estimated business outcomes, modeled on the engagement scope and on published benchmarks for comparable programmes, and every figure is labelled as projected. Client identity and commercially sensitive details are withheld. Any outcome that could not be responsibly quantified is described directionally in words instead.

What is a solution accelerator and what does it not do?

It is prebuilt scaffolding for work that is substantially the same on every engagement, such as pipeline structure, segmentation logic, a model selection harness and monitoring. It does not remove client specific work. Here about three weeks of a sixteen week engagement went on adapting the accelerator to the client data model and order process.

How do you stop the system decaying after handover?

Name an internal owner for replenishment parameters and give the review a schedule. Automate model selection per segment and review it quarterly rather than locking a method in permanently. Monitor accuracy per segment for drift and flag any segment that degrades for several cycles. The original problem here was caused entirely by parameters that nobody owned.

Conclusion

AI for supply chain optimization worked here because the first move was not a model. It was segmentation, and it revealed that the business had been forecasting project demand and intermittent spares as though they were the same thing. The stockouts everyone blamed on volatile customers turned out to be driven mostly by supplier lead time variability that no system had ever modelled. Reorder points had not been reviewed since the planning system went in.

Once demand was grouped properly and inventory policy was calculated per segment and per location, the projected outcomes followed: an estimated 30 to 35 percent reduction in stockout events on A class items, an estimated 18 to 22 percent release of working capital from slow moving stock, and roughly four fifths of the planning week returned to the team. Those numbers are modeled rather than measured, and they are labelled that way deliberately.

What is not a projection is the structural change. Parameters now have an owner, accuracy is measured where it can be acted on, and the client team retrains the models itself. If your own forecast accuracy is reported only at company level, that single report is where to start looking.

Every figure in this case study is an estimated business outcome, modeled on the engagement scope and on published industry benchmarks — not audited client data. Client identity and commercially sensitive details have been withheld.