When mine production targets move without anyone noticing

Situation

The site is a gold operation. Two surface pits and two underground operations feed a single processing facility. Side-tipper rehandle from local ROMs at each surface pit to the crusher ROM is part of the daily picture, on top of the underground feed.

One open pit ran a Tier 1 Fleet Management System that fed data into a spreadsheet. Two underground mines ran on spreadsheets. The processing plant had a spreadsheet at the centre of its reporting. All of it consolidated into a single spreadsheet at the top. Schedules and forecasts were entered into the spreadsheets by the respective departments.

The reporting state could be summarised as: multiple sources of truth, limited data drill-down, poor data quality, a low level of automation, no effective way to report and analyse reconciled numbers, no means of rapidly consolidating and reporting data.

A new pit was being brought online. The site needed a way to record production and time data for it from day one. That requirement became the install path for an integrated reporting platform across the whole site.

Failure mode

The mechanics behind the spreadsheet stack were straightforward. There was no held forecast, no held budget, no held monthly schedule, no held weekly plan anywhere on site. Plans existed in whichever spreadsheet someone had open. Numbers could move without leaving a trace.

The daily reporting cadence had its own problem, separate from the weekly review. Each department sent its own report. A consolidated picture didn’t exist until every input was in, which was usually around lunchtime. Engineers spent the first half of every day reconstructing yesterday when they should have been planning today. Most mines find this pattern familiar; it is the default state of any site running consolidated reporting through email distribution and spreadsheet pulls.

The cost stack:

• MTD movements, grades, and equipment metrics not visible to the GM in any form he could trust
• End-of-month survey adjustments running blind, with no trending of corrections over time
• Site lacked accurate production numbers and accurate targets simultaneously, so both ends of the variance were rubbery
• Engineering time consumed on retrospective compilation rather than design and scheduling
• Corporate-level visibility into daily site performance: nil

Intervention

The headline scope was two surface installs, two weeks each. Underground and processing came in around them.

The new pit went first, installed and operational within two weeks. Shortly after, the established pit’s FMS feed was integrated into the platform. From there it was a case of executing against the vision that had been set at the start of the engagement.

The end-state scope:

• Surface FMS pit feeding the platform directly
• Two underground operations on manual entry, treated identically to automated feeds by the data warehouse
• Side-tipper rehandle from local ROMs to the crusher ROM
• Processing data joined via the metallurgical accounting spreadsheet
• Geology Module covering stockpile weight and grade
• Product Tracking Module covering material movement and grade tracking from genesis to crusher, with stockpile makeup known at all times
• End-of-month survey adjustment workflow

The rest came in methodically around the surface installs. There was a vision at the start, and the delivery worked toward the end state per the plan.

Once both surface pits and both underground operations were feeding the platform, the approved Forecast, Budget, Monthly Schedule, and Weekly Plan were loaded as the single held versions. To change actual production numbers, the change had to be made at source. To change any forecast, budget, schedule, or plan, the change had to come through a defined and visible pathway.

The platform shipped with a library of pre-built reports. Very few of them were used. Vendor canned-report libraries fall into the same trap at every site: they look impressive in the demo, and they don’t answer the question the engineer actually has at 7am. Either the report doesn’t tell you exactly what you want, or you need to run ten of them to get a picture of what you need.

What replaced the canned library was a set of targeted reports built to answer specific operational questions, compare actual to plan, and track material and grade from genesis through to the crusher. Two examples of custom reports were:

The Sitewide Daily report was automatically emailed at 8am daily, covering day plus MTD plus budget variance:

• Tonnes crushed and milled
• Mill feed grade
• Recovery
• Ounces recovered
• Expit/hoisted tonnes by material type
• Mined grade
• Availability and U of A by area

The Sitewide Daily was supported by department-specific reports issued earlier the same morning, shortly after the production day closed.

The Forecast parameter signoff used the platform data to inform the quarter’s parameters. Pre-platform, the quarterly mining parameters review took the planning team one to two weeks to compile manually: dig rates, productivity, op hours, availability, utilisation, capacity, and timing parameters by digger and truck class. Post-platform, the engineer selected start and end dates, ran a suite of targeted reports, and pasted the output into the signoff document. The cleanest before-and-after on the site: one to two weeks of manual compilation collapsed to a date-range selection.

Outcome

Single source of truth for production data across the site: tonnes, BCM, grades, stockpiles. Surface and underground reporting through one platform. Processing data joined via the metallurgical accounting spreadsheet. The whole site had accurate production numbers and accurate targets simultaneously for the first time.

The site had held versions of forecast, budget, schedule, and plan for the first time. Changes to any of them were visible and traceable. Variance against held numbers became something the site could see and act on.

End-of-month survey adjustments became trendable. The running numbers were close enough to truth that survey corrections were a meaningful signal rather than noise. Trending was visible by cutback, equipment fleet, and oxidation, exposing where adjustments were systematically running long or short. Survey adjustment became a managed process rather than an end-of-month surprise.

Variance visibility at shift, crew, and operator level became available to Planning, Supervision, and Training. What supervisors did with that data was their call.

The geology and metallurgical teams gained insight into grades and recovery robbing that fed into forecasting and blend recipe management.

The Sitewide Daily report landed on the GM’s desk every morning, within hours of the production day’s completion. Distribution went to the GM, all managers, superintendents, engineers, processing, and the corporate COO. Corporate-level visibility into daily site performance went from nil to a single-page report on the COO’s desk every morning. By 8am, the picture was settled across the site and engineers could start the day on today’s work.

Transferable lesson

The actionable points:

• If your site has rubbery production numbers in the weekly production review, the cause is not the reporting platform’s report library. The cause is that business logic lives in spreadsheets and no system holds the approved targets.
• Buying a reporting platform without relocating business logic out of spreadsheets and locking targets inside it is buying an empty filing cabinet.
• Use the canned report library to discover what the dataset and platform can deliver. Then build targeted reports against the held targets to answer the questions your engineers actually have.
• The daily cadence is the second-order win. If the Sitewide Daily lands within hours of the production day closing instead of by lunchtime, engineers get half a shift back per day.

The reporting platform’s real job isn’t generating reports. It’s holding the version of truth that didn’t exist before.

The deliverable is the change. Held targets, business logic out of spreadsheets and into a database, and data access through a single platform rather than through a network of siloed inputs. Before: numbers in spreadsheets that could move without leaving a trace. After: an approved forecast, an approved budget, an approved schedule, an approved plan, all sitting somewhere defensible with changes visible to anyone who needs to see them.

The common mistake is buying a reporting platform for its report library. The canned reports look like the value in the demo. They are not the value. Look at the canned reports to identify what the dataset and platform can deliver, not as the deliverable itself. The value is the held targets, the relocation of business logic from spreadsheets to a database, and the data access that comes from having both. Targeted reports get built on top once those foundations are in place.