Should operations have a ledger? — Greg Sier & Associates

This piece follows from maintenance budgets should describe the future, not just the past. If a budget is really a position that keeps moving, the natural question is whether operations needs a ledger to track those movements.

Financial systems use ledgers because they need to answer a simple but important question:

What changed, when did it change, and what is the current position?

Every transaction contributes to a larger financial state.

Operations has a similar problem.

Assets accumulate hours.

Components consume life.

Work creates cost.

Purchase orders create commitments.

Shutdown scope changes.

Production consumes capacity.

Condition findings change risk.

Resources become constrained.

Forecasts move.

Yet these changes are often stored in different systems, tables and reports.

That raises an interesting question:

Should operations have something similar to a ledger — not for statutory accounting, but for maintaining a traceable operational position?

The idea is not to reproduce a general ledger.

It is to create a structured record of operational changes that can explain where an asset, fleet, shutdown, plant or organisation stands now, how it got there, and where it appears to be heading.

Operational systems already contain ledger-like behaviour

Consider a haul truck.

During a month, the operation may record:

+ 420 operating hours
+ 185,000 tonnes hauled
+ $42,000 maintenance cost
+ 1 major component commitment
- 420 hours estimated component life
- 16 hours availability
+ 1 completed inspection
+ 1 condition warning

These are not all financial transactions.

But each one changes the operational position of the asset.

Likewise, a shutdown may accumulate:

+ 12 approved work packages
+ $480,000 committed cost
+ 1,800 labour hours
- 4 hours forecast schedule float
+ 2 readiness blockers
+ 1 scope change

A road program might accumulate:

+ 42 km graded
+ 1,800 tonnes gravel consumed
+ $110,000 actual cost
- 3 high-priority defects
+ 5 new defects identified

These records have something in common.

They are all movements in operational state.

The difference between a transaction and a position

This distinction is useful.

A transaction tells us:

What changed?

A position tells us:

Where are we now?

For example:

Transaction:
Truck 047 operated 10 hours today.

Position:
Truck 047 engine remaining-life estimate is now 2,430 hours.

Or:

Transaction:
Purchase order for engine exchange issued.

Position:
FY27 component budget now has $320,000 committed.

Or:

Transaction:
Shutdown package failed readiness review.

Position:
Shutdown readiness has fallen from 91% to 88%.

The operational ledger records the movement.

The position is derived from the accumulated movements and current state.

That separation can be powerful.

Current-state fields can hide how we got there

Many systems store only the current value.

For example:

remainingLife = 2430

That tells us the current estimate.

It does not necessarily explain why the estimate changed.

A ledger-like history might show:

Original expected life             15,000 h
Usage consumed                    -11,500 h
Duty-cycle adjustment               -350 h
Oil-analysis adjustment             -250 h
Inspection adjustment               -220 h
Recent operating hours              -250 h
--------------------------------------------
Current estimated remaining life   2,430 h

The current position becomes explainable.

That matters whenever forecasts, assumptions or recommendations are challenged.

Budgeting is already close to a ledger problem

Maintenance budgeting illustrates the idea clearly.

A budget report may show:

Budget         $10.0m
Actual          $5.8m
Variance        $4.2m

But the operational position may really be:

Budget                         $10.0m
Actual                          $5.8m
Committed                       $2.6m
Known planned work              $1.3m
Forecast reactive work          $1.1m
-------------------------------------
Expected outturn                $10.8m

The important operational movements include:

budget allocation
purchase commitment
work completion
scope change
forecast adjustment
cancellation

Each movement changes the expected position.

The same structure can apply to more than dollars.

Labour can have a position

Suppose annual fitter capacity is:

Available capacity      32,000 h

The system may record:

Budget demand           28,000 h
Scheduled demand        29,500 h
Committed contractors    3,000 h
Forecast demand         34,000 h

The operational position might therefore be:

Forecast capacity deficit     2,000 h

That is effectively a resource balance.

The movements behind it might be:

new shutdown scope          +900 h
component brought forward   +600 h
cancelled job               -250 h
production increase         +750 h

The system can now explain why labour demand moved.

Production can have a position

Production is normally treated as a separate planning domain.

But the same pattern applies.

For example:

Budget production          10.0 Mt
Current forecast            9.7 Mt
Actual to date              5.1 Mt
Remaining forecast          4.6 Mt

Changes might arise from:

asset downtime
production rate changes
weather
shutdown changes
fleet availability
operating constraints

Each event changes the expected production position.

This creates a common planning language across maintenance and operations.

Asset life can also have a position

Remaining life is particularly suited to this approach.

For a component:

Expected life            12,000 h
Actual consumed           9,000 h
Condition adjustment        -500 h
Forecast remaining        2,500 h

The important point is that the remaining-life estimate is not necessarily static.

It may change because of:

usage;
duty;
inspection findings;
condition monitoring;
repair;
component replacement;
engineering judgement.

Those changes could be retained as explicit adjustments rather than silently overwriting the current estimate.

Not every operational measure should behave like money

This is important.

A financial ledger has strict accounting rules.

Operational measures do not necessarily.

A tonne is not interchangeable with an hour.

A condition score does not behave like cash.

A risk finding cannot always be summed.

So the objective is not to force every operational measure into double-entry accounting.

Instead, the common idea is:

preserve significant movements, their source and their effect on the current operational position.

A generic operational entry might contain:

Entity
Metric
Date / Time
Entry Type
Quantity
Unit
Direction
Source
Scenario
Status
Confidence
Reason

For example:

Entity: Truck 047
Metric: Engine Remaining Life
Entry Type: Condition Adjustment
Quantity: -300
Unit: hours
Source: Oil Analysis OA-1842
Reason: Elevated wear metals

Or:

Entity: Shutdown SD-26-04
Metric: Labour Demand
Entry Type: Scope Change
Quantity: +480
Unit: hours
Source: Scope Change SC-017

The structure remains generic.

The meaning remains domain-specific.

There may be value in standard entry types

A common set of operational entry types could help.

For planning:

Budget
Plan
Forecast
Commitment
Actual
Adjustment
Cancellation

For lifecycle:

Consumption
Reset
Extension
Reduction
Replacement
Reassessment

For resources:

Capacity
Demand
Allocation
Consumption
Release

For risk:

Identification
Escalation
Mitigation
Closure

These would not necessarily use the same calculations.

But the common structure provides consistency.

The ledger should not replace transactional models

This is an important architectural boundary.

The system should still have normal operational entities such as:

WorkOrder
PurchaseOrder
Inspection
ConditionReading
ProductionShift
ComponentChange
Shutdown

Those objects describe what happened.

The operational ledger records the effect of significant events on positions.

For example:

Work Order completed
        ↓
Operational postings
        ↓
Maintenance actual +$4,800
Labour actual +22 h
Asset downtime +6 h
Component life reset

The work order remains authoritative for the work.

The operational ledger provides a common downstream interpretation.

This is closer to event sourcing, but not necessarily event sourcing

There is a resemblance to event-sourced architectures.

Event sourcing preserves changes and derives state from those changes.

That can be powerful.

It can also introduce substantial complexity.

CPM probably does not need to make every database object fully event-sourced.

A more practical architecture may be:

Transactional Models
        +
Operational Events
        ↓
Operational Ledger
        ↓
Position Views
        ↓
Forecasts / Alerts / Analytics

This retains conventional relational data while preserving the significant movements that matter to future decisions.

Operational position could become a common concept

Once the ledger exists, the system can derive an operational position for any significant entity.

For a haul truck:

TRUCK 047

Availability             89%
Current condition        AMBER
Engine remaining life    2,430 h
Maintenance forecast     $410k
Committed work           $285k
Next major intervention  Q2 FY27

For a shutdown:

SHUTDOWN SD-26-04

Scope readiness            91%
Forecast duration          76 h
Baseline duration          72 h
Budget                     $4.2m
Forecast cost              $4.6m
Blocked packages              4
Critical-path exposure     HIGH

For a road network:

ROAD NETWORK

High-priority defects       34
Treatment backlog         182 km
Annual budget             $3.2m
Forecast outturn          $3.5m
Condition trend          DECLINING

The structure changes by domain.

The idea of an operational position remains common.

Positions can roll upward

This is another advantage.

Operational entries may occur at a detailed level:

Component
  ↓
Asset
  ↓
System
  ↓
Plant
  ↓
Site
  ↓
Organisation

A component-life adjustment may affect an asset.

Several asset positions may affect fleet availability.

Fleet availability may affect site production.

Production may affect budget and business performance.

The system can therefore aggregate appropriate positions upward.

For example:

Component condition
        ↓
Asset health
        ↓
Fleet availability
        ↓
Production capacity
        ↓
Site position

That creates traceability from high-level management indicators back to operational evidence.

But aggregation needs care

Not every metric should simply be summed or averaged.

This is particularly important for:

condition;
risk;
critical controls;
readiness;
availability.

For example, ten healthy assets and one critically unsafe asset do not necessarily produce:

Average Health = 91%

and therefore a healthy fleet.

A critical exception may dominate the management decision.

The ledger can provide traceability.

The position rules still need domain-specific logic.

Entity health should probably be multidimensional

An operational ledger naturally leads to the idea of entity health.

That can be useful.

But a single health score may hide too much.

For example:

SITE HEALTH = 82%

does not tell us whether the problem is:

condition;
production;
maintenance backlog;
cost;
workforce;
shutdown readiness;
risk.

A better model may retain dimensions.

For example:

Production          GREEN
Availability        GREEN
Condition           AMBER
Lifecycle           RED
Maintenance Cost    AMBER
Resources           GREEN
Risk                RED

The system may still derive an overall exception state for filtering.

But the underlying dimensions should remain visible.

This could improve forecasting

One of the biggest advantages of a ledger-like model is that forecasts become explainable.

Suppose the maintenance forecast changes from:

$9.8m

to:

$10.6m

Instead of simply storing the new value, the system could explain:

Production increase             +$260k
Engine interventions moved      +$220k
Parts escalation                +$140k
New shutdown scope              +$110k
Deferred work                   -$70k
Other                           +$140k
--------------------------------------
Forecast change                 +$800k

This is useful for management.

It is also important if AI-generated recommendations are introduced.

AI recommendations need explainable positions

Suppose an AI-assisted system recommends:

Bring forward the Truck 047 engine replacement.

That recommendation should be supported by evidence such as:

Current remaining-life estimate
Production forecast
Condition trend
Next shutdown opportunity
Parts availability
Failure consequence
Cost

A ledger-like architecture provides an audit trail for how those inputs changed.

Instead of an opaque recommendation, the user can inspect the operational movements that produced the current position.

That could become important for AI governance.

Scenario planning fits naturally

The ledger model can also support scenarios.

For example:

BASELINE
HIGH_PRODUCTION
DEFER_SHUTDOWN
ADD_WORKSHOP_SHIFT
REPLACE_TRUCK_047

Each scenario can maintain its own forecast movements without changing actual history.

For example:

                    BASELINE    HIGH PROD

Production           10.0 Mt      11.5 Mt
Truck hours            68,000       78,000
Engine rebuilds             6            9
Maintenance cost         $9.8m       $11.2m
Availability               87%          84%

The scenario differences can be traced back to their assumptions.

This is more useful than maintaining isolated spreadsheet models.

Operational and financial ledgers should remain separate

This is a critical boundary.

The operational ledger should not become the official financial ledger.

The ERP or accounting system remains authoritative for:

invoices;
accounts;
tax;
accruals;
financial periods;
statutory reporting.

The operational system can instead record:

estimated cost
committed cost
operational quantity
resource consumption
production effect
life consumption
risk change

Where appropriate, financial actuals can later be reconciled with the ERP.

The purpose is different.

The financial ledger asks:

Where did the money go?

The operational ledger asks:

What changed in the operation, why did it change, and what does that mean for the future?

This may be particularly useful between systems

Many organisations already have multiple systems:

ERP
CMMS
Production system
Condition monitoring
Inventory
Planning tools
Spreadsheets

An operational ledger does not necessarily need to replace them.

It could provide a common interpretation layer.

For example:

CMMS Work Order
      ↓
Maintenance actual

ERP Purchase Order
      ↓
Commitment

Production System
      ↓
Usage actual

Condition System
      ↓
Life adjustment

All contribute to:

Operational Position

That could make CPM useful as an integration and decision layer rather than requiring every transactional system to be replaced.

The ledger could support different asset domains

The common mechanism can remain while the metrics change.

Mobile plant

SMU
Tonnes
Fuel
Component life
Downtime
Maintenance cost

Roads

Kilometres treated
Condition
Defects
Grader hours
Material quantities
Program cost

Structures

Inspection findings
Risk
Intervention status
Condition
Cost

Processing plant

Throughput
Availability
Shutdown scope
Wear
Condition
Production loss

Shutdowns

Scope
Readiness
Labour
Materials
Duration
Cost
Production impact

This reinforces the broader CPM principle:

common infrastructure, specialised operating models.

What this could mean for CPM and DSLCore

The operational ledger may be best treated as a platform capability rather than a maintenance-specific module.

DSLCore might allow domains to define:

Metrics
Units
Entry Types
Position Rules
Roll-up Rules
Thresholds
Forecast Rules

For example:

metric: fitter_hours

budget
planned
committed
actual
forecast

or:

metric: engine_remaining_life

baseline
consumption
condition_adjustment
reset
forecast

or:

metric: shutdown_duration

baseline
forecast
actual
variance

The engine can remain generic.

The semantics come from the domain model.

Four layers may provide a useful architecture

A clean conceptual structure might be:

1. TRANSACTION
   What happened?

   Work order
   Inspection
   Purchase order
   Production shift
   Component replacement


2. OPERATIONAL LEDGER
   What changed?

   + cost
   + hours
   - remaining life
   + commitment
   - availability


3. POSITION
   Where are we now?

   Actual
   Committed
   Forecast
   Remaining capacity
   Remaining life


4. DECISION
   What should we do?

   Maintain
   Purchase
   Reschedule
   Replace
   Defer
   Change production

Each layer answers a different question.

Together they create a much stronger operating model.

A working hypothesis

The proposition is not that operations should copy financial accounting.

The controls, mathematics and governance are different.

But finance has benefited for centuries from preserving movements and deriving positions from them.

There may be a useful lesson in that.

A maintenance or operations system that stores only current values and closed transactions can tell us a great deal about what has happened.

A ledger-like operational model may make it easier to explain:

what changed;

why it changed;

what the current position is;

how the forecast moved;

and what decisions should now be reconsidered.

A useful distinction may be:

Transactions describe operational events.

An operational ledger describes how those events change the position of the organisation.

Questions worth testing

Which operational measures genuinely benefit from ledger-like treatment?

Where should immutable history end and recalculated forecasts begin?

Should budget, commitment, forecast and actual use a common underlying structure?

Can remaining-life adjustments be represented transparently without creating unnecessary complexity?

How should operational positions roll from components to assets, fleets, plants and sites?

Which measures should aggregate, and which should remain exception-driven?

Could an operational ledger provide a useful integration layer between CMMS, ERP, production and condition-monitoring systems?

And perhaps the broader question:

If financial systems can explain how every transaction changed the financial position, should operational systems be able to explain how every significant event changed the operational position?

That may be a useful architectural direction for systems intended to support not just record-keeping, but forecasting, optimisation and decision-making.