Not a neural network instead of a production manager, but a forecast inside the process

Peruvian bakery María Almenara demonstrates a useful sequence for a mid-sized business: turn operations into reliable data first, connect the forecast to production constraints second, and only then call the solution artificial intelligence.

The OECD case traces the company from a family business started in 2007 to 15 Lima stores and 421 employees at the time of the study. Its retail business opened in 2017. The company's current website reports 24 stores and more than 640 employees. The numbers refer to different dates and demonstrate growth, but they do not prove that AI alone caused that growth.

The foundation was a point-of-sale and online ordering flow connected to ERP. According to OECD, a unified customer platform collected more than 20,000 interactions per month, while the online channel accounted for 40% of sales. Records included purchase time and location, product, channel, and sometimes the occasion. This created the basis for estimating demand by store and product.

The forecast used recurring signals such as weekday, twice-monthly salary dates, holidays, and temperature. In a project with MIT, machine learning was applied not to an abstract prediction score but to sales planning under production and storage constraints. Microsoft previously reported that ERP integration supported daily and weekly estimates by product and location. It also reported an increase in fill rate from a 90% target to 99%. Treat that figure as a vendor-reported outcome from one project, not a universal promise.

A practical architecture for an SME

For a bakery, prepared-food operator, small manufacturer, or regional retailer, a practical design has five layers.

1. **System of record.** POS, website, marketplaces, and manual orders provide sales lines with consistent product, store, and timestamp identifiers.
2. **Master data.** ERP holds recipes, shelf lives, inventory, purchasing lots, production capacity, and price calendars.
3. **Data mart.** A cleaning process handles returns, cancellations, missing values, changed product codes, and outliers. History is retained by day and hour.
4. **Forecast.** A model estimates demand by product and location, exposes an uncertainty range, and is compared with a simple baseline such as sales on the same weekday.
5. **Planner.** A separate algorithm converts the forecast into a production proposal while respecting minimum batches, oven capacity, staffing, shelf life, and ingredients. A shift manager approves or edits the plan.

The separation matters. Forecasting answers “how much will probably sell?” Optimization answers “how much should we make under our constraints?” Combining them carelessly can turn an accurate forecast into an impossible schedule or excess waste.

A large language model is not required for the core calculation. Gradient boosting, statistical models, or a dedicated time-series service may be better. An LLM can assist around the workflow: explain a deviation, collect a manager's note, draft a summary, or answer natural-language questions. The production quantity should remain with a deterministic planner and a responsible person.

Data required before a pilot

A minimum useful history is usually six to twelve months of sales by item and site. Businesses with strong annual seasonality should aim for 18–24 months. Each row should include:

  • actual quantity and net price after discounts;
  • returns and cancellations;
  • inventory and an out-of-stock flag;
  • waste quantity and reason;
  • promotions, holidays, and changed opening hours;
  • shelf life and production batch;
  • external variables only where a testable relationship exists, such as temperature for seasonal products.

Out-of-stock status is critical. Zero sales may mean zero demand, or it may mean an empty shelf. If the system cannot distinguish them, it learns to reduce the forecast for the products that already suffered shortages.

Names, phone numbers, and delivery addresses should not enter the training mart without a specific need. Aggregated transactions are normally sufficient. Role-based access should protect raw data, master-data changes should be logged, and any contractor extract should be de-identified.

Measuring impact without fooling yourself

Model accuracy is not a business result by itself. Management needs four metric groups:

  • availability: the share of demand served without a stockout;
  • loss: expired or discarded goods in units and money;
  • operations: emergency production, transfers, and manual planning hours;
  • forecast quality: WAPE or MAE by item and location, upward and downward bias, and the share within an acceptable range.

Run the pilot on several comparable sites and compare it with the baseline. Do not score only popular products: slow movers often create disproportionate waste. Keep a log of manual overrides because it reveals which operational signals are missing.

For perishable products, errors are asymmetric. Underforecasting creates shortages and lost customers; overforecasting creates waste. The business—not the data scientist—must define their relative costs.

A modeled pilot economy

Consider a hypothetical five-site chain. The monthly cost of fresh goods is RUB 5 million and current waste is 7%, or RUB 350,000. A pilot reduces waste to 5.5% without lowering availability. The saving is RUB 75,000 per month.

Assume managers also release 50 planning hours at a fully loaded RUB 900 per hour, creating a resource effect of RUB 45,000. Data and model support cost RUB 35,000 per month. The modeled net effect is RUB 85,000. With RUB 680,000 in integration and pilot costs, simple payback is eight months.

This is not a María Almenara result; it is a calculation template. Released time becomes financial value only if it reduces overtime, improves throughput, or avoids future hiring. The cost of shortages and waste must come from accounting records, not a supplier presentation.

Limits and risks

Demand changes after a new store opens or products, prices, and delivery channels change. The model requires retraining and drift monitoring. A new product has no history, so it needs analogues and a manual limit.

The system cannot know about a broken oven, an absent employee, or a large special order unless the event reaches the data. The interface therefore needs explainable overrides and a reason log. Automatic posting to ERP can follow a stable shadow period, but the first deployment should publish recommendations only.

The case also highlights integration quality. If POS data arrives once a day, inventory does not reconcile, or product codes change without history, a more sophisticated model will not repair the operating process.

A four-week pilot

Week one: select 20–40 products and two or three sites, consolidate sales, inventory, and waste, and record baseline metrics.

Week two: implement a simple rule and one model. Use a time-based train/test split so future information never leaks into the past.

Week three: run shadow forecasts. Planners see the recommendation but keep the existing process and record reasons for differences.

Week four: apply recommendations to a limited product group with human approval. Compare availability, waste, manual effort, and integration stability.

The managerial lesson is to begin with consistent codes, regular transactions, inventory, and production constraints—not with the “smartest” model. Add a simple forecast and a control group next. AI creates value when its output ends in an accountable operational decision rather than one more chart in a meeting.