Ampla Delay Accounting: A Practical Guide
The Reports Still Run. Nobody Believes Them.
Somewhere in most Australian processing plants there is a weekly downtime Pareto that nobody argues about any more, because nobody uses it. It comes out of Ampla on schedule, it lands in the shift review pack, and the people in the room discuss what actually stopped the plant using their own notes. The report is not wrong in any way you could point at. It describes a plant that no longer exists.
Ampla, sold since the 2020 release as AVEVA Production Management, is the system of record for delay and downtime on a large number of Australian mine sites, mineral processing plants, sugar mills and continuous manufacturing operations. Looked after properly, its delay accounting gives you the cleanest answer available to the question of where the hours went last month. Left alone, it produces numbers that are precise, auditable and disconnected from the plant floor.
This is a guide to the second situation, because it is the common one. It covers what delay accounting does inside Ampla, the specific ways the model drifts away from reality over a few years, four diagnostics you can run on your own data this week without a consultant, and how to rebuild a reason code tree so that operators will actually use it. Across 18 years of industrial data and OT work, including plant, production and reporting systems projects delivered for BHP, Rio Tinto and Senex Energy while employed by other consulting and engineering firms, the failure pattern has been consistent enough to be worth writing down.
What Delay Accounting Actually Does in Ampla
Strip away the module names and delay accounting answers one question: for every hour in the calendar, what was each piece of equipment doing, and if it was not producing, why not.
Ampla builds that answer from four things working together.
The equipment hierarchy is the spine. Every delay record hangs off a location in the model, which mirrors the physical plant down to whatever level the site decided to track: circuit, crusher, mill, screen, conveyor, packing line. Rollups follow that hierarchy, so a stoppage recorded against a single screen propagates up into circuit availability and site utilisation.
Equipment state comes in automatically. An interface, usually OPC or a direct historian connection off Citect SCADA or the plant PLCs, drives a running or stopped signal. When the state changes, Ampla opens a downtime record with a start time and closes it when the equipment runs again. The duration is machine-measured, and this half of the system is usually reliable.
The reason code tree is the part humans supply. Ampla structures cause information hierarchically, typically as cause location, then cause, then a finer reason code, with the AVEVA Production Management datasheet describing a four level Time Usage Model along with event splitting, an approval workflow and configurable context fields. An operator or supervisor picks a path through that tree to classify the event. Everything downstream, every Pareto, every availability figure, every loss attribution, is built from that pick.
Shift and crew calendars sit underneath it all. They define what counts as scheduled time, which shift and crew owns an event, and where the boundaries fall for the rollups. Get these wrong and delay hours will never reconcile against production hours, no matter how good the coding is.
How a delay event becomes a number in a report
Notice where the weak link is. Five of those six steps are machine work and they rarely fail. The third step depends on a person, under time pressure, choosing correctly from a list that somebody designed years ago, and the quality of that one choice sets a ceiling on everything downstream of it.
How These Models Drift
Nobody breaks a delay accounting model. It decays, in four ways that compound.
The reason code tree is built once and never revisited
The tree gets designed during commissioning, usually in a workshop, usually by people who were thinking hard about the plant as it was about to be built. It is a good tree on day one. Then the plant changes. A circuit gets debottlenecked. A crusher is replaced with a different type that fails differently. A new product grade is introduced that brings its own stoppage modes. Feed source changes and suddenly ore hardness variability is a real loss category that has no code.
The tree does not change with any of it, because changing it requires someone with Ampla configuration access, an understanding of the rollups, and the authority to tell the site that next month's numbers will not compare cleanly to last month's. Nobody has all three, so the tree stays. After four or five years the codes describe a plant from a previous era, and operators are forced to map real events onto approximations.
Operators code to habit, and to the top of the list
Give a person a hierarchical picker with sixty leaf nodes and thirty seconds between tasks, and they will develop a fast path. Usually that fast path is whatever sits at the top of the alphabetical list, or the code they used last time, or the one broad category that is never wrong enough to be questioned. Mechanical, Other, Process Upset. These codes become gravity wells. They absorb events that had specific, addressable causes, and once absorbed, those causes are invisible to every report the site runs.
Blaming operators for this misses where it comes from, which is the design of the picker. If coding an event correctly takes four clicks and coding it approximately takes one, the model is asking for the approximation.
Unaccounted time creeps up
Every Ampla site has a bucket for downtime where the equipment state says stopped but no cause was assigned. At commissioning it is small, because everyone is watching. It grows. It grows fastest during busy periods, on night shift, and after any change that made coding harder.
Unaccounted time is the most honest metric in a delay accounting system, because it is the one number that cannot be gamed by picking a vague code. It tells you exactly what fraction of your downtime nobody is explaining. Most sites do not report on it, which is a shame, because it is the single best leading indicator that the rest of the numbers are degrading.
Deferred coding means events are classified by people who were not there
When coding is not done during or immediately after the shift, it gets done later. Later means a supervisor or a production clerk on a Monday, working through a backlog of events from the weekend, deciding what caused a 42 minute stoppage at 3am on Saturday based on a logsheet comment that says "belt issue".
The delay record will be completed. It will have a cause, a duration and a crew attached. It will look exactly like a well-coded event in every report. And it will be a guess, made three days after the fact, by someone who was asleep when it happened. Once a meaningful share of your events are coded this way, the Pareto is measuring the memory and assumptions of the person doing the backlog, not the plant.
The end state of all four is the same. Delay hours stop reconciling against production hours. Somebody notices, raises it once, gets no traction, and stops raising it. The reports keep running. The operational conversation moves to spreadsheets and personal notes, and the site keeps paying for a system it has stopped trusting.
Four Diagnostics You Can Run This Week
You do not need an engagement to find out whether this has happened to you. Four queries against the Ampla database, or four reports if you have the reporting layer for it, will tell you most of what you need.
1. Measure unaccounted time as a share of total downtime
Take the last three months. Sum downtime hours with no cause assigned, divide by total downtime hours, then plot the same ratio by month for the last two years. The absolute number matters less than the trend. A ratio that is climbing tells you the coding discipline is losing ground, and the inflection point usually lines up with something specific: a roster change, a system upgrade, a supervisor leaving.
2. Look at the distribution of reason code usage
Count events per leaf node over six months and sort descending. A working model produces a long tail with a real shape to it. If a handful of codes carry most of your events, you have gravity wells. If you have leaf nodes with zero usage across six months, the tree is describing equipment or failure modes that no longer exist, and every dead code is making the picker slower for the ones that are still live.
3. Check whether delay hours reconcile to production hours
For one piece of equipment, over one month, take scheduled time and subtract every category in your Time Usage Model. Does it close? If the arithmetic leaves a residual that nobody can explain, then the calendar configuration, the state signal and the coding are disagreeing with each other somewhere, and every availability figure built on top of them inherits the error.
4. Measure the lag between event end and coding
Ampla records when a downtime record was last modified and, in more recent versions, who modified it. Plot the distribution of the gap between event end and final coding. If a large share of your events are being classified more than 12 hours after they finished, you are measuring recollection rather than the plant.
Working thresholds for a delay model health check
These are working thresholds drawn from practice rather than a published standard, so treat them as prompts to look harder rather than as pass or fail lines. A site with 4% unaccounted time and a flat trend is in reasonable shape. A site at 3% and climbing steadily for eighteen months has a problem that has not surfaced yet.
Reading what your delay data is telling you
Rebuilding a Reason Code Tree Properly
The instinct when a tree has drifted is to add codes. Resist it. Almost every drifted tree is already too big, and adding to it makes the fast path problem worse. A rebuild goes the other way.
Start from the losses the site actually manages by
Not from the equipment list, and not from what the previous tree had. Sit with the people who run the weekly production meeting and ask what decisions they make and what would change those decisions. If nobody has ever taken an action off the back of distinguishing between two codes, those two codes should be one code. The tree should mirror the site's loss model, the way it already thinks about where production goes, and for surface mining operations that loss model should line up with the GMG standardised time classification framework, published in 2020 by the Global Mining Guidelines Group, which sets out operational definitions, a Time Usage Model and KPI definitions for availability and utilisation. Aligning to a published framework is also what makes your availability figures comparable to anyone else's.
Keep it shallow enough to code in one or two clicks
This is the constraint that most rebuilds violate. If an operator has to traverse four levels to record a chute blockage, the chute blockage will be recorded as Process Other. Design for the 80% of events that are routine and give them a one click path. Reserve the deeper structure for the events that are rare and genuinely need detail. It is better to have twelve codes that are used accurately than sixty that are used approximately.
Map it to the CMMS
This is the step that gets skipped, and skipping it guarantees an argument later. If Ampla calls something an unplanned mechanical delay and SAP, Pronto or Ellipse classifies the same stoppage against a different failure taxonomy, then production and maintenance will produce two different pictures of the same month and spend the meeting reconciling them instead of acting. The mapping does not have to be one to one, but it does have to be written down and agreed by both functions before the tree goes live.
Plan the discontinuity
Changing a tree breaks year on year comparison. Decide in advance how you will handle it: whether you will map history onto the new structure, whether you will run a parallel period, and what you will tell the board when the Pareto looks different. This is a communication problem more than a technical one, and it is the reason most sites never change the tree at all.
A drifted tree against a rebuilt one
| Metric | Drifted | Rebuilt | Improvement |
|---|---|---|---|
| Tree structure | Grown by accretion, four or five levels deep | Designed around the site loss model, shallow at the top | Clicks to code |
| Code count | 50 to 100 leaf nodes, many unused | Fewer nodes, all in active use | Usage per code |
| Coding time | Coded on Monday from weekend backlog | Coded within the shift that owned the event | Lag distribution |
| Unaccounted time | Climbing, unreported | Reported weekly as a managed metric | Trend direction |
| CMMS alignment | Different taxonomies, reconciled by argument | Documented mapping agreed by both functions | Meeting time |
| Report credibility | Produced, ignored, worked around | Used in the weekly production meeting | Actions taken |
Where Ampla Sits, and Why the Codes Have to Agree
Ampla is a middle layer, and most of its hard problems come from that position rather than from the product itself.
Below it sit SCADA and the historian. Citect on the control side, AVEVA Historian or OSIsoft PI holding the time series, feeding equipment state and production tags upward. Above it sit the ERP and the CMMS: SAP, Pronto, Ellipse, holding work orders, financial periods and the maintenance failure taxonomy. Ampla's job is to turn continuous plant signals into discrete, classified, reportable events that both layers can agree on.
The single most common source of arguments about production numbers is that the classification used in the middle layer does not match the classification used above and below it. Maintenance codes a stoppage one way in the CMMS. Production codes it another way in Ampla. The historian has the raw state change and no opinion at all. Three systems, three versions of the same shift, and the monthly meeting turns into a reconciliation exercise. We have written about the same problem in its production tonnage form in why SCADA and your ERP disagree on tonnes, and the resolution is the same: the taxonomy has to be agreed once, across systems, and maintained as a shared asset rather than owned separately by each function.
This is also where the modelling discipline upstream pays off. A well-built asset model in the historian, with templated equipment and consistent tag context, makes the Ampla equipment hierarchy far easier to keep aligned with the physical plant. If you are working on the historian side of this, PI Asset Framework template design covers the same structural thinking one layer down. Getting the reporting layer right on top of it is covered in getting historian data into Power BI.
Most of the work in bringing these layers into agreement is integration work rather than Ampla configuration, which is why it tends to stall when it is treated as a plant systems task with no system integration capability behind it.
Sequencing a Reason Code Rebuild
A tree rebuild on a single plant area is a matter of weeks, not months, provided the discovery is done honestly and the site is willing to make decisions.
Reason code rebuild, single plant area
The last row is the one that gets cut when budget is tight, and cutting it is what produces the next drifted tree. The configuration work is finished by week six. The coding habit takes another six weeks to set, and if nobody is watching unaccounted time and coding lag during that window, it does not set at all.
Somebody Has to Own the Model After Go-Live
Every drifted tree started as a good tree that nobody owned. The plant kept changing, the model did not, and there was no standing arrangement under which a change to the plant triggered a change to the delay model.
This is the part a project cannot solve, because it is not a project. A crusher is replaced in March, a new product grade is introduced in July, a circuit is rerouted in November, and each of those should produce a small, deliberate amount of work on the reason code tree, the equipment hierarchy and the reports built on both. On most sites that work is nobody's job. The site engineer who understood the model has moved on, the vendor relationship is break and fix, and the model falls another year behind the plant.
A retained arrangement exists to cover exactly this: someone whose standing job includes keeping the delay model aligned with the physical plant, watching the health metrics above, and making the small changes before they compound. That is the shape of our managed AI and OT support service, and it is worth reading what an Ampla support arrangement should actually cover before you renew whatever support contract you are currently on, because most sites are paying for incident response and receiving no maintenance of the model itself.
Where to Start
If your unaccounted time is climbing, or five reason codes are carrying most of your events, or coding is happening on Mondays for events that occurred on Saturday, that is worth an hour of someone's attention this week. Run the four diagnostics against your own Ampla database first. They cost nothing, they need no vendor involvement, and they will tell you whether you have a configuration problem, a process problem or an integration problem before anyone proposes a solution.
Solve8 works with Australian plant and production teams on delay accounting, historian and MES systems, drawing on 18 years of hands-on OT and industrial data work. Our operational technology and manufacturing capability covers Ampla and AVEVA Production Management, Citect SCADA, PI and AVEVA Historian, and the integration layers between them, and we work with resources and industrial operators out of Brisbane across Queensland and nationally. If your delay numbers have stopped being believed, start a scoping conversation and we will look at your model and your diagnostics before proposing anything.