What can AI actually do for a mining stores team?
It does the line by line work nobody has time for. It checks every stock line against real usage, flags the ones out of line, and explains why, so your team spends time on decisions, not spreadsheets.
In practice that means four jobs:
- Stock levels. Recalculate min and max for every line from usage, lead time and criticality.
- Dead and slow stock. List lines that haven't moved, or that hold years of cover, with the value tied up in each.
- Cross-site matching. Find the same part held under different numbers at different sites, so stock can be transferred instead of bought again.
- Questions in plain English. Ask "why did this line reorder?" in Microsoft Teams and get an answer that links back to the transactions behind it.
None of it replaces the people who run the warehouse. It gives them a full list to work from instead of a sample.
Why are so many min/max levels out of line?
Because they're usually set once and rarely reviewed. Usage changes, lead times change, equipment gets retired, and the min/max values stay where they were.
The common causes are the same on most sites:
- Levels copied from OEM recommendations at commissioning and never updated.
- Returns counted as usage, which makes demand look higher than it is.
- Lead times in the system that don't match how long suppliers actually take.
- Levels raised after a stockout and never brought back down.
- The same part held at several sites, each with its own buffer.
A good inventory superintendent knows which lines are wrong. The problem is there are thousands of them, and reviewing each one by hand takes longer than the levels stay right.
How should min and max levels be calculated?
Min is the reorder point: average daily usage times lead time in days, plus safety stock. Max is the min plus the order quantity. The engine uses plain, checkable maths for this. The AI only explains it.
Min (reorder point) = average daily usage x lead time in days + safety stock
Max = min + order quantity
Example with made-up figures:
| Input | Value |
|---|---|
| Usage over 12 months (net of returns) | 72 units, so 6 a month |
| Average daily usage (6 / 30) | 0.2 units |
| Lead time | 45 days |
| Usage over the lead time (0.2 x 45) | 9 units |
| Safety stock | 4 units |
| Min (9 + 4) | 13 units |
| Order quantity | 10 units |
| Max (13 + 10) | 23 units |
Critical and rotable spares need different treatment, because the cost of a stockout is a stopped machine, not a late delivery. The guide on how to set min max levels covers the formulas in full, and critical and rotable spares covers the exceptions.
Why do returns matter so much to stock levels?
Because a part issued and then returned unused isn't usage. Counting it inflates demand, and inflated demand pushes min and max up on exactly the lines that don't need it.
Example with made-up figures: a line shows 20 issues in a year, but 8 came back to the store unused. Real usage is 12, or 1 a month. Using the gross figure overstates demand by two thirds, and every level built on it is too high.
This was the biggest single fix in the work for an international tier 1 mining operator. One rule change, netting returns off usage, took agreement with the site's own figures on disputed items from 73% to 98.4%. Overall, the stock level engine matched the site inventory expert's own spreadsheet 99.8% of the time. Read the full min/max inventory engine case study.
How do you find dead and slow stock without a month of spreadsheets?
You classify every line by its movement and cover, then sort by value. That gives a ranked list of where working capital is tied up.
| Class | Typical test (set with your team) | Usual action |
|---|---|---|
| Dead | No issues in 24 months | Check criticality, then sell, return or transfer |
| Slow | On hand covers more than 24 months of usage | Lower max, stop reordering |
| Over max | On hand above the recalculated max | Let it run down |
| Under min | On hand below the recalculated min | Review for reorder |
Example with made-up figures: a site holds 8,000 stock lines worth $20,000,000. 640 lines, or 8%, haven't moved in 24 months and hold $1,600,000. If half of that value is sold, returned to suppliers or moved to another site, that's $800,000 of released working capital. It's cash freed from the shelf, not instant profit.
Insurance and critical spares are flagged separately so nothing essential gets cleared by mistake. More on this in the dead stock and obsolete spares guide.
Can stock be shared between sites instead of re-bought?
Yes, if you can prove two part records are the same part. The hard bit is being sure, so the matching sorts every pair into evidence tiers instead of guessing.
- Strong evidence. Same manufacturer part number and matching description. Safe to treat as one part.
- Partial evidence. Some details match, some are missing. Goes to a person to confirm.
- Weak evidence. Similar descriptions only. Shown, but never treated as a match.
This approach refuses to be confidently wrong. A stores team would rather see a short list of proven matches than a long list of maybes. See the cross-site parts matching case study.
Who decides what changes in the warehouse?
Your team does. The system recommends and explains. A person approves every change to a min/max level, every disposal and every transfer.
It's built inside your own data platform, such as Azure, Databricks or Snowflake, with read-only access to source data. Every number links back to the transactions it came from. When a recommendation looks wrong, you can see exactly why it was made, and if a user catches a mistake, it becomes a permanent test.
Where does a stores team start?
With a free 15 minute call with Tristan, or a quick enquiry. No obligation, no pitch. From there, an engagement runs like this:
- 15 minute call. Free, no obligation, no pitch. Tristan asks what you run and what is costing you, and tells you straight whether there is something worth fixing and roughly what it would cost.
- A look at a sample export. Only if it's useful, and read-only.
- A clear scope and price. What gets built, how many days it takes and what it costs, in writing before any work starts.
- Build inside your systems. In your own Azure, Databricks or Snowflake, with read-only access to source data.
- Run, check and support. Monthly re-runs, new sites and fixes. A person approves every change.
Work is charged at a consulting day rate. The price depends on your sites, systems and data, so we talk first, then Tristan sets out what he'd build, how many days it takes and what it costs. More detail is on the mining spares optimisation page.
