The System Predicts Demand, So Purchasing Is Planned Sooner
A purchase request has to be prepared for the next day while customer orders are still coming in and the quantities needed are still changing.
Conceptual illustration. The case is real; company details are disguised.
In a fresh food business that prepares customer orders from stock held at the Depo, planning starts at the Depo, the place where stock is stored and orders are prepared. Waiting for all sales to close meant purchase preparation started later. Meanwhile, a request made earlier still had to follow new orders and the stock that remained. The daily work needed a basis for forecasting as well as a way to update it.
Before, the forecast started in a spreadsheet. On the morning shift, demand history was processed in Excel: data from similar days over a month was selected, the average was calculated, and an estimate was prepared for the next shift. Every day, planning went through the same steps of selecting data and running the same formulas before the result was used to submit a request to the purchasing team.
A mistake in choosing the data or applying the formula could change the quantity requested. A shortage can send additional purchases to the market, while a surplus increases the risk of fresh goods being thrown away. The forecast needs to be available before final demand is known, and then judged together with stock and the nature of the goods. Recalculating history by hand was the part of the work that my team and I moved into the system.
As head of the IT Division, I worked with the team to provide a Purchase Prediction feature that processes demand history automatically every night. The calculation uses a trend-moment prediction formula with the history of the same weekday over nine weeks. For Monday's demand, for example, the system uses the previous nine Mondays. The forecast and the average are available when the admin starts reviewing demand, without having to prepare the history calculation again in a spreadsheet.
On the same screen, the forecast appears together with customer orders already received, stock, purchase requests, supplier orders, and goods receipts. The history detail shows the customers and the quantities they ordered. Orders that exceed the average are flagged so that large, non-routine purchases get attention. The admin reads this information before deciding how much to request.
I kept the final quantity decision at the Depo because what needs to be bought is not always the same as the sales forecast. Goods with a long shelf life can be ordered all at once at the start to become stock, and the purchase quantity also has to meet the supplier's minimum. The admin weighs these points together with stock and the orders already received. For unusual situations, the demand is decided together with the head of the Depo.
The flow passes through three points. First, the initial request is prepared on the night before the goods are needed, using the prediction. Second, demand is adjusted at midday, after the goods left over from the previous preparation are checked. Third, the request is updated after sales close, following the orders that finally came in. With this sequence, purchasing already has a basis to prepare from, while the quantity needed keeps following the operational information as it grows.
Changes are recorded as additions or reductions against the initial request. The history keeps the amount of the change, who made it, and when. Automatic notifications and direct reminders deliver the revision to the purchasing team. The purchasing team knows that the quantity requested has changed, and every change can be traced.
Adjusting supplier orders remains the purchasing team's work. A single request can be fulfilled through several suppliers, so a change in quantity has to be assessed against the orders already placed with each one. The system passes on the change in demand, while the purchasing team decides how to adjust the ordering. In this way, adjusting the orders for a request that several suppliers fulfil stays with the purchasing team.
The benefit felt most comes from daily use. Users say this data has become what they rely on to make requests to the purchasing team. Without it, they would have to go back to calculating demand by hand. The nightly calculation takes over the work of processing history; the admin's attention shifts to stock, incoming orders, and the quantity that needs to be requested that day.
My lesson: a forecast is useful when it enters the daily decisions of the people who use it. The system provides a starting basis routinely, and the people who know the goods update it to match real conditions before the demand is passed on as a purchase.