Case study ยท Power BI and analytics

Inventory, forecast accuracy and OEE reporting for a two-plant food manufacturer.

Golding Farms and Foods runs procurement, sales and operations on a set of Power BI reports we build and maintain. Each change is scoped with the business owner, built in the model, and validated cell by cell before it is published.

Golding Farms and FoodsFood manufacturingPower BIDAXSQL Server
4report areas: inventory, sales, forecast accuracy, operations KPIs
203 / 203OEE cells matched to the plant's own workbook on delivery
80zero-stock items surfaced that inventory reporting used to hide

The work

  • Inventory and days on hand. Procurement needed to see items with zero inventory that still had a six-month forecast or open orders. We extended the model with source-layer placeholder rows and an item-source flag so those items appear on the days-on-hand, purchase analysis and purchase forecast pages without changing any existing total.
  • Forecast accuracy by salesperson. The salesperson slicer sat on a dimension with no direct relationship to the forecast tables. We bridged it through master customer using a count comparison and TREATAS, added the variance measures and a detail page, and validated against the sales team's own numbers.
  • Weekly core KPIs and OEE. A new operations page with weekly KPIs by line, then OEE and efficiency built from machine-level Vorne data with ideal time backfilled model-side. Delivered as matrices by date and line for each plant and matched exactly to the plant's spreadsheet over a 30-day window.
  • Consolidated sales and open orders. Aligned the target ship date logic across both sites and validated every open-order row after the change.
  • Component filters that stay honest. When a broader product filter started pulling in shared components, we reverted to the narrow bill-of-materials definition procurement expected and logged the remaining edge cases as a follow-up.

How we work with them

Requests come from the operations and procurement leads with a spreadsheet of what "right" looks like. We check the live model first, propose the change, build it with formatted DAX and documented measures, and publish only after the numbers reconcile. Every change is recorded in the report's master documentation with a change log, so the client always knows what changed and why.