Power BI for Operations: Distributor Case Study

Operations teams generate more data than almost any other function in a business, and yet they are often the last to get a decent reporting layer. The ERP has its own screens, the warehouse management system has its own screens, and the courier portal has its own screens. When something goes wrong, three people open three different tabs.

This case study covers a project we delivered for a UK distributor of industrial components, shipping around 1,800 orders a day out of two national distribution centres. The operations director wanted one place to answer three questions: are we shipping on time, is stock healthy, and which customers are quietly costing us money.

The challenge

The business ran Microsoft Dynamics 365 Business Central for orders and inventory, Mintsoft for warehouse management and a blend of DPD and Royal Mail Business Account portals for despatch tracking. Reporting existed in each system, but the joins between them were manual.

On-time-in-full (OTIF) was measured once a month using an export from Business Central and a matching export from the courier portal, reconciled by hand. Stock reports were printed each Monday and marked up with a highlighter. Cost to serve, the number the ops director most wanted to see, did not really exist.

What we built

We connected Business Central, Mintsoft and the courier feeds into Microsoft Fabric, built a clean operations semantic model, and delivered four Power BI dashboards aimed at different audiences.

Daily operations dashboard

Refreshed every fifteen minutes during working hours. Shows orders received, orders picked, orders despatched and orders at risk today, split by warehouse and by carrier. The warehouse managers now start their morning huddle in front of this screen rather than a printed pick summary.

OTIF and service level

Full OTIF calculation done properly for the first time, joining the promised date from the order to the actual despatch scan from the courier. Split by customer, product group and carrier, with drill-through to the individual orders that failed. The monthly customer service review now works from this page instead of a slide deck.

Stock health

Every SKU classified into healthy stock, slow movers, at risk of stockout, and obsolete. Purchasers use it to prioritise their week; the FD uses it to challenge working capital. The same underlying model feeds forecast accuracy reporting for the demand planners.

Cost to serve

The one that needed the most thought. We combined average pick time from the WMS, courier cost per parcel from the despatch feed, and returns cost from Business Central, then allocated back to customer and channel. For the first time the sales team could see which of their largest accounts were actually the least profitable once fulfilment was included.

How we handled the awkward bits

The two hard problems on any operations reporting build are data quality at source and definitional disagreements between teams. Both showed up here.

Data quality first. Pick scans were being skipped for around four percent of orders during busy periods because operatives knew the system would still let the order despatch. That showed up as gaps in the OTIF calculation. Rather than paper over it in the model, we surfaced it as its own dashboard tile — the ops director wanted the missing scans visible, not hidden. Compliance is now over ninety-nine percent.

Definitional disagreements second. Customer service measured OTIF against the promised date at order entry. The warehouse measured it against the internal target ship date, which was usually one day later. Sales measured it against whatever the customer had asked for on the phone. All three are legitimate. The model captures each, and the dashboard lets the user pick which definition they want. Arguments stopped because the numbers were finally on the same page.

The outcome

OTIF improved from around eighty-nine percent to ninety-six percent within six months, largely because problems were visible in hours rather than at the next month end. Stock holding came down by roughly £600k as the purchasing team finally had a proper slow-mover list to work from. The cost to serve view triggered a repricing conversation with two of the largest accounts, both of which agreed to a fairer delivery charge structure.

The less measurable win was cultural. The Monday morning ops meeting used to be a debate about whose spreadsheet was right. It is now a fifteen-minute walk through a live dashboard, followed by an actual discussion about what to do next.

Why Power BI for operations?

Operations data lives in more systems than any other function, which is precisely why a proper analytics layer is so valuable. Power BI, sitting on top of a warehouse that joins the ERP, WMS and courier feeds, replaces a wall of reports with a single view that every team can trust. Our supply chain analytics guide goes into more detail on the metrics that matter.

If your ops team is stitching together reports from three systems every week, our Power BI consultancy and Microsoft Fabric consultancy services are the natural starting point, or get in touch for a chat.

Frequently asked questions