Supply chain analyst, nearly four years of it, and this account is where I work out the questions the job raises but never has an afternoon to settle.

The first stretch was at Mahindra Logistics in India, on third party logistics. Replenishment and demand analysis across five thousand SKUs, safety stock and reorder points, supplier lead times and purchase order variance, and the inventory, stockout and aging dashboards planners opened first thing. Third party logistics is a useful place to learn in, because the person being served is somebody else's operation and the cost of a bad number is their line stopping rather than your report looking wrong.

Then a master's in Analytics and Systems at the University of Bridgeport, and since the start of 2025 I have been at Cargill in the US, on agribusiness. Demand and shipment patterns across regions and seasons, forecasting in Python, inventory and replenishment risk, forecast variance and scenario work going into S&OP, and transportation analytics on lane performance, carrier utilisation, transit times and delivery exceptions.

Those two settings look similar on a resume and behave differently in practice. A case either arrived or it did not. A commodity is weighed at one end and weighed again at the other, and the two numbers can disagree without anyone having taken anything, so the question becomes which formula you reconcile them with. Working on both is most of why I started writing these.

It is almost never a model that is wrong. It is a number that is answering a different question from the one it gets read as.

A safety stock formula solves for the share of replenishment cycles that survive, and the review deck reports the share of units served. A carrier scorecard starts counting at ship confirm, so a delay that happened before it is not measured imprecisely, it is not measured at all. A forecast backtested on sales history is graded against your own availability on every day the shelf was empty, so the forecaster that ignores the problem wins the backtest.

None of those are precision problems that more data fixes. The estimate is fine. It is an estimate of a different quantity from the one the decision needs, and that gap does not show up as an error bar, which is why it survives review after review.

It is also an awkward thing to raise in a meeting, because "that number is answering a different question" sounds like an opinion right up until somebody shows you how big the difference is. So I started measuring them.