The Reports Still Run. Nobody Believes Them.
Ampla 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. When the reason code tree is well maintained, it gives the clearest picture available of where production hours go each month. When it drifts, it produces numbers that are precise, auditable and disconnected from the plant floor.
This guide covers the second situation, because it is the common one.
Key takeaways
- Delay accounting quality depends almost entirely on the reason code tree and how operators use it, not on the system itself.
- Four diagnostics (unaccounted time, code distribution, time balance and coding lag) will tell you whether your model has drifted, without a consultant.
- Rebuilding a reason code tree is a matter of weeks on a single plant area, but the coding habit needs another six weeks of active monitoring to set.
- Every drifted tree started as a good tree that nobody owned after go-live.
- The reason code taxonomy must agree across Ampla, the CMMS and the historian, or production and maintenance will argue about the same month forever.
What Delay Accounting Actually Does in Ampla
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. 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.
- State changeSCADA or PLC signal says the equipment stopped
- Event createdAmpla opens a downtime record against the equipment location
- Operator codes itA path is chosen through the cause and reason code tree
- Review and splitSupervisor validates, splits multi-cause events, approves
- RollupTime Usage Model assigns hours to availability and utilisation
- ReportPareto, loss attribution, shift and crew comparison
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.
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. 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 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.
- Unaccounted time, share of total downtimeInvestigate above 5 to 8%
- Unaccounted time trend over 24 monthsAny sustained climb
- Share of events in the top 5 reason codesInvestigate above 60%
- Leaf codes with zero use in 6 monthsRetire them
- Events coded more than 12 hours after the factInvestigate above 20%
- Unexplained residual in the time balanceShould be near zero
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.
Which symptom shows up first in your numbers?
- Unaccounted time climbingCoding workflow problem. Look at shift handover, picker speed and who is accountable.
- A few codes carry most eventsTree design problem. The fast path is wrong and needs redesigning around real losses.
- Delay hours do not reconcileCalendar or state signal problem. Check shift boundaries and the running signal source.
- Coding happens days laterProcess problem. Coding has to belong to the shift that owned the event.
- Maintenance and production disagreeIntegration problem. Reason codes differ between Ampla and the CMMS.
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, and for surface mining operations that loss model should line up with the GMG standardised time classification framework (Global Mining Guidelines Group, 2020), which sets out operational definitions, a Time Usage Model and KPI definitions for availability and utilisation. Aligning to a published framework also 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. 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.
| Drifted | Rebuilt | Impact | |
|---|---|---|---|
| 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 in the Stack
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, the historian 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. 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.
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 is covered in getting historian data into Power BI.
Most of the work in bringing these layers into agreement is system integration work rather than Ampla configuration, which is why it tends to stall when it is treated as a plant systems task alone.
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.
- Week 1DiagnoseRun the four diagnostics, quantify unaccounted time and code distribution
- Week 2Loss model workshopAgree the losses the site manages by, with production and maintenance in the room
- Week 3Design the treeDraft the hierarchy, test the click path, map to the CMMS taxonomy
- Weeks 4-5Configure and validateBuild in Ampla, check rollups and calendars, recode a historical sample
- Week 6Train and cut overTrain operators on the real picker, agree the coding deadline per shift
- Weeks 7-12Watch the metricsTrack unaccounted time and coding lag weekly, adjust the tree while attention is on it
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.
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, and making the small changes before they compound. That is the shape of our managed services offering, 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.
How Solve8 can help
Our team has deep hands-on experience with Ampla, AVEVA Production Management, Citect SCADA, PI and AVEVA Historian, and the integration layers between them, drawing on years of OT and industrial data work across our consultants' careers. We work with mining, resources and manufacturing operators out of Brisbane 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.
