Business analytics and forecasting automation

Choose a situation to see how the system processes data, makes a decision and produces a result.

The demonstration includes three scenarios: a shortage forecast, anomaly detection and inventory segmentation.

Scenario A / Shortage forecast

The system identifies the risk of a stock shortage in advance.

The warehouse holds 120 units of a spare part, of which 20 are already reserved for existing orders.

Available stock is 100 units.

An ML model forecasts demand of 160 units over the next 14 days. Company rules also require safety stock of 30 units.

With no confirmed incoming deliveries, the calculated replenishment requirement is 90 units.

Pipeline:

1. Receives stock and reservation data from ERP.
2. Loads sales history from PostgreSQL.
3. Builds a demand forecast.
4. Calculates expected stock and safety stock.
5. Detects a forecast shortage.
6. Checks open purchase orders and supplier constraints.
7. Prepares a draft replenishment request.
8. Sends the result to the responsible employee.

Result: a recommendation to purchase 90 units has been prepared, subject to review of lead times, existing orders and purchasing limits.

Scenario B / Intelligent anomaly detection

The system detects deviations from expected business behaviour, rather than simply unusually low sales.

Consider a company selling hundreds of products every day. Demand varies with the day of the week, season, holidays, promotions and other factors.

For one product, normal weekday sales are 20–30 units, while Sunday sales are only 1–4 units.

Monitoring with a fixed threshold below 10 sales would warn every Sunday, even though nothing is wrong.

The ML model uses historical data, seasonality, calendar features and other available factors to calculate an expected sales range for each particular day.

For example, it estimates normal Monday demand at 22–28 units, but only 2 sales are actually recorded.

The system recognises that this value differs significantly from expectations. The same 2 sales on Sunday may be completely normal.

The reverse is also possible: sales of 14 units against an expected 50–65. A fixed threshold of 10 would not trigger, but an analytical model could detect the deviation.

How the automated pipeline works

First, Python-script receives new data from ERP, CRM or PostgreSQL.

Stage one — Data Quality. The system checks loading completeness, data freshness, duplicates, missing records and other technical errors. Incomplete data are marked unreliable and excluded from automated business decisions until the problem is resolved.

Stage two — ML analysis. The model calculates expected sales using the day of the week, seasonality, historical trends and other available features, then compares actual sales with the forecast range.

Stage three — anomaly detection. If the difference is statistically or practically significant under the defined criteria, the pipeline records the deviation, saves its parameters and creates an analytical event.

Stage four — additional checks. The system queries ERP and other sources for signs of stock unavailability, a stopped advertising campaign, order problems or sales recording errors.

These checks narrow the possible causes but do not guarantee identification of the actual cause.

Stage five — automated action. The pipeline prepares a notification with specific data: actual sales, the expected range, the size of the deviation and additional check results. It can also create a task for the responsible employee.

Result

The system detected a significant deviation of actual sales from the expected level, taking the product's historical behaviour into account.

Crossing a fixed threshold alone is not treated as proof of a problem.

The key difference in ML analytics is that it assesses metrics in the context of changing conditions rather than comparing every new value with one unchanging number.

How ML supplements DQ controls

DQ can include technical checks and assessments of whether metrics are plausible. Explicit rules work well for completeness, freshness, formats, duplicates and missing data. Assessing sales, spend or stock often needs context: the day of the week, seasonality, history and related metrics.

An ML model helps refine these controls by calculating expected ranges for different conditions, detecting outdated or overly crude thresholds and suggesting adjustments. It can also take on some DQ functions that require intelligent assessment, such as identifying unusual combinations and deviations that are difficult to describe with fixed rules.

In this scenario, a fixed threshold of sales < 10 is shown for comparison. It would give the same warning for 2 sales on both Sunday and Monday. A contextual ML check gives different conclusions: 2 Sunday sales fall within the expected 1–4, while 2 Monday sales are below the expected 22–28 and require investigation.

The notification in this workflow is based on the contextual check. If an existing system has a mandatory threshold alert, that alert also requires investigation when triggered. ML results help assess the situation and refine the control rules.

A detected deviation calls for checking both data and business conditions. It may reflect a sales recording error or a real drop in demand. The pipeline checks the available sources and gives the responsible person facts and possible explanations, without presenting an assumption as an established cause.

ML supplements technical DQ checks with contextual assessment, making controls more precise: allowing for normal variation and detecting significant deviations even when a fixed threshold is not crossed.

Scenario C / Segmentation and analytical experiment

The system detects excess stock and proposes testing a different purchasing strategy.

There are 480 units available in stock.

Forecast demand over the next 30 days is 90 units. Required safety stock is 25 units.

Analysis of historical sales provisionally places the product in C/Z: a relatively small contribution to sales value and unstable demand.

Available stock exceeds forecast requirements including safety stock by 365 units.

This calls for further analysis rather than automatically treating the whole amount as surplus.

Pipeline:

1. Receives sales, inventory and purchase data.
2. Performs ABC/XYZ product segmentation.
3. Calculates a demand forecast.
4. Identifies products with potentially excessive stock.
5. Checks current purchasing constraints.
6. Proposes adjustments to replenishment policy.
7. Prepares an A/B experiment comparing two approaches.
8. Once results accumulate, evaluates metrics and makes a recommendation.

For example, fixed replenishment rules can be compared with forecast-based rules using comparable groups of products or warehouses.

Results are assessed by stock turnover, storage cost, shortage frequency and order fulfilment. The experiment must account for differences between groups and whether enough data are available to draw conclusions.

Result: a product with potentially excessive stock has been identified, and a proposal to test a new replenishment strategy prepared.