One work model may not fit every asset

This piece continues from the work order is not the maintenance system. If the work order is one transaction inside a larger model, the next question is whether a single work model can serve every kind of asset.

Maintenance systems need common structures.

Assets need identities. Work needs to be raised. People need to be assigned. Materials need to be issued. Costs need to be captured. History needs to be retained.

That commonality is valuable.

But it can also create a design trap.

If the system begins with a generic work-order and scheduling model, there is a temptation to make every asset class fit that model.

A haul truck, road network, bridge, processing plant and building can all be represented as assets.

They can all generate work.

But the way they deteriorate, the way work is identified, the way resources are deployed, the way performance is measured, and the way future work is forecast can be very different.

That raises a useful question:

Should every asset class be forced through the same operating workflow simply because the underlying system can represent them all as assets and work orders?

Probably not.

Common data does not necessarily imply common workflow

At a high level, most maintenance activities can be reduced to something like:

Asset
  ↓
Requirement
  ↓
Work
  ↓
Resources
  ↓
Execution
  ↓
Completion

That abstraction is useful.

It gives the organisation common reporting, common costing and common governance.

But it is also very broad.

Once we look at the work operationally, the differences become substantial.

A truck is usually maintained as a discrete machine.

A road is maintained as a network of sections.

A bridge is often managed through component condition and engineering assessment.

A processing plant may be maintained around functional systems and shutdown windows.

A building may be managed through service requests, statutory obligations, tenancy and facility systems.

The common work transaction can remain.

The operating model around it may need to change.

Mobile plant is naturally equipment-centred

Mobile plant fits the traditional CMMS model relatively well.

A haul truck, excavator, grader or loader is a discrete maintainable asset.

Its maintenance demand may arise from:

• operating hours;
• kilometres;
• tonnes moved;
• defects;
• scheduled services;
• component life;
• condition monitoring;
• breakdowns.

A simplified model might be:

Asset
  ↓
Usage / Condition
  ↓
Maintenance Requirement
  ↓
Work Order
  ↓
Workshop
  ↓
Labour + Parts
  ↓
Return to Service

The work often centres on the equipment.

Resources are commonly:

• fitters;
• auto electricians;
• workshop bays;
• service trucks;
• cranes;
• parts;
• replacement components.

The scheduler asks questions such as:

Which machines are due for service?

Which components are approaching intervention?

Which jobs can the workshop handle this week?

Which machines can be released without affecting production?

This is recognisably a work-order-centred maintenance environment.

Roads are different

Road maintenance is much less naturally organised around discrete equipment records.

The asset may be:

Road Network
  ↓
Road
  ↓
Segment
  ↓
Location / Chainage

Maintenance demand may come from:

• condition surveys;
• potholes;
• rutting;
• cracking;
• drainage defects;
• shoulder deterioration;
• traffic loading;
• weather events.

The natural workflow may therefore look more like:

Network
  ↓
Condition / Defects
  ↓
Treatment Candidates
  ↓
Prioritisation
  ↓
Geographic Work Program
  ↓
Crew + Plant + Materials
  ↓
Completed Quantity

The operational question is not merely:

Which work order should we schedule next?

It may be:

Which defects should be grouped into one geographic program while the grader, roller and water cart are already mobilised to the area?

That is a different optimisation problem.

Geography matters.

Quantities matter.

Mobilisation matters.

Weather matters.

The work package may be more important than the individual work order.

Earthworks and civil works introduce production-style thinking

Earthworks sit somewhere between maintenance and production.

The key variables may include:

• quantities moved;
• haul distances;
• material type;
• equipment balance;
• productivity;
• weather;
• access;
• sequencing.

A work model may therefore look like:

Work Area
  ↓
Quantity
  ↓
Method / Sequence
  ↓
Plant Combination
  ↓
Production Rate
  ↓
Completed Quantity

The resources are not just labour and parts.

They may include:

• excavators;
• trucks;
• graders;
• rollers;
• water carts;
• survey;
• traffic control.

The planning problem is closer to:

How do we configure and sequence the fleet to complete the required quantity efficiently?

rather than:

Which technician is available for this work order?

Again, the generic work object may survive underneath.

The scheduling logic is quite different.

Structures often begin with inspection and risk

Bridges, culverts, retaining structures and similar assets often have another pattern.

The starting point may be an inspection.

Structure
  ↓
Component
  ↓
Inspection
  ↓
Defect
  ↓
Condition Rating
  ↓
Engineering Assessment
  ↓
Intervention

The work order comes comparatively late.

Before work is approved, the organisation may need to determine:

• severity;
• structural significance;
• consequence of failure;
• load restrictions;
• urgency;
• repair options;
• monitoring requirements.

A defect may result in:

Monitor
Repair
Strengthen
Restrict Use
Replace

The maintenance decision is therefore partly an engineering and risk decision.

A generic work-order screen cannot replace that reasoning.

Fixed plant introduces functional dependencies

Fixed plant may look more familiar to a CMMS, but the asset relationships matter more.

A pump may be a discrete item.

Operationally, however, it may sit inside:

Pump
  ↓
Pumping System
  ↓
Process Circuit
  ↓
Production Plant

Its availability may affect the entire system.

Maintenance planning therefore needs to understand:

• redundant equipment;
• process dependencies;
• isolation boundaries;
• operating windows;
• production constraints;
• standby capacity.

A job that takes four hours on one pump may have almost no production consequence if another pump is available.

The same four-hour job on a single bottleneck asset may stop the plant.

The work is similar.

The operational meaning is different.

Processing plants make shutdowns more important than individual work orders

Processing plants expose the limits of work-order-centred thinking particularly clearly.

Major maintenance is often coordinated through shutdowns.

The relevant model becomes:

Production Window
  ↓
Shutdown
  ↓
Scope
  ↓
Work Packages
  ↓
Dependencies
  ↓
Isolation
  ↓
Resources
  ↓
Execution
  ↓
Commissioning

Hundreds or thousands of work orders may sit underneath.

But planners are also concerned with:

• scope freeze;
• critical path;
• material readiness;
• contractor mobilisation;
• crane access;
• scaffolding;
• permits;
• isolation boundaries;
• break-in work;
• commissioning;
• return to production.

The shutdown is an operating event.

Treating it as merely a collection of work orders loses important context.

Buildings and facilities have another work pattern

Buildings can contain maintainable assets such as:

• HVAC systems;
• fire systems;
• lifts;
• electrical distribution;
• pumps;
• security systems.

But facilities work may also arise from:

• tenant requests;
• cleaning;
• access issues;
• compliance inspections;
• room condition;
• service levels;
• contractor visits.

A useful model may therefore include:

Request
  ↓
Service Requirement
  ↓
Priority / Compliance
  ↓
Work
  ↓
Service Outcome

The underlying asset may sometimes be secondary.

For example:

Air-conditioning complaint in Meeting Room 3

may begin with a service request rather than an equipment defect.

The system needs to connect the request to the relevant equipment later.

Even scheduling means different things

The differences become particularly obvious when we look at scheduling.

For mobile plant, scheduling may be driven by:

SMU
Component life
Workshop capacity
Machine availability

For roads:

Geography
Condition
Weather
Crew productivity
Plant mobilisation

For structures:

Risk
Inspection findings
Specialist access
Engineering resources

For process plant:

Shutdown window
Dependencies
Isolation
Critical path
Production constraints

For facilities:

Service priority
Occupancy
Compliance date
Contractor availability

Calling all of these simply scheduling is technically correct.

Operationally, they are very different problems.

Resources also need domain context

A generic resource model might contain:

Person
Plant
Tool
Material
Contractor

That is useful.

But different domains combine those resources differently.

Mobile plant

Fitter
Auto electrician
Workshop bay
Crane
Parts

Road maintenance

Crew
Grader
Roller
Water cart
Gravel
Traffic control

Structures

Inspector
Engineer
Access equipment
Specialist contractor
Traffic management

Shutdown

Trades
Contractors
Cranes
Scaffolding
Tools
Materials
Isolation personnel
Commissioning resources

A common resource register can remain.

The planning logic around resource combinations should not necessarily be common.

This matters for lifecycle management

The differences are not limited to work execution.

Assets also consume life differently.

A truck may consume component life through:

hours
tonnes
distance
payload
duty cycle

A road may consume life through:

traffic
axle loading
weather
water ingress

A processing plant may consume life through:

throughput
material hardness
temperature
pressure
starts and stops

A structure may deteriorate through:

corrosion
fatigue
water exposure
loading
age

So future maintenance demand needs domain-specific lifecycle models.

That means different work models are not just an interface issue.

They affect forecasting.

Production and service outcomes also differ

The value produced by an asset is different across domains.

A haul truck contributes:

tonnes moved

A processing plant contributes:

throughput
recovery
product output

A road provides:

access
capacity
service level

A bridge provides:

safe load-bearing connectivity

A building provides:

usable space
service availability
compliance

So the consequence of maintenance also needs context.

The same eight-hour intervention can have radically different operational effects.

Budgeting follows the same pattern

A common budget system can still aggregate:

Labour
Materials
Contractors
Plant
Capital

But the forecast behind those numbers may be domain-specific.

For mobile plant:

Production Forecast
  ↓
Operating Hours
  ↓
Component Consumption
  ↓
Maintenance Demand
  ↓
Budget

For roads:

Condition Forecast
  ↓
Treatment Program
  ↓
Quantities
  ↓
Plant + Materials
  ↓
Budget

For structures:

Condition / Risk
  ↓
Interventions
  ↓
Engineering + Construction
  ↓
Budget

For shutdowns:

Scope
  ↓
Resources + Materials
  ↓
Duration
  ↓
Production Loss
  ↓
Budget

The financial result may be common.

The operational path to that result is not.

The risk of one universal work model

A universal model is attractive because it simplifies software.

Everything becomes:

Asset
  ↓
Work Order
  ↓
Schedule
  ↓
Complete

But operational complexity does not disappear because the software hides it.

Instead, organisations often compensate with:

• spreadsheets;
• separate planning tools;
• custom fields;
• free-text notes;
• external schedules;
• manual coordination;
• undocumented business rules.

The system remains technically central.

The operating model becomes distributed around it.

That can create an illusion of integration without actually integrating the decision process.

A better approach may be common kernel, specialised workflows

There is still strong value in commonality.

The organisation may want common:

Asset
Location
Organisation
Person
Contractor
Cost
Document
Work
Inspection
Risk
Material

Those can form a common operational kernel.

Above that kernel, domain models can vary.

For example:

                  Common Kernel
                       │
          ┌────────────┼────────────┐
          ↓            ↓            ↓
     Mobile Plant     Roads      Process Plant
          │            │            │
         SMU        Geography    Shutdowns
     Components     Treatments   Dependencies
      Workshop      Quantities    Isolation

The common kernel supports:

• enterprise reporting;
• integration;
• governance;
• common identity;
• cost aggregation.

The domain layer preserves operational meaning.

Work patterns may be more useful than one work module

For CPM and DSLCore, this suggests a potentially useful architecture.

Instead of one universal work-order process, define a small number of reusable work patterns.

For example:

Equipment work

Asset
→ Requirement
→ Work Order
→ Repair / Service

Inspection-driven work

Inspection
→ Finding
→ Assessment
→ Intervention

Program work

Condition
→ Candidate Work
→ Program
→ Geographic / Repetitive Execution

Project work

Scope
→ Package
→ Dependencies
→ Execution

Shutdown work

Shutdown
→ Scope
→ Work Packages
→ Readiness
→ Execution
→ Commissioning

Service work

Request
→ Service Requirement
→ Work
→ Service Outcome

Different applications can combine these patterns.

A mine site might use nearly all of them.

A council road system might use mainly inspection-driven and program work.

A facilities system might rely heavily on service work.

DSLCore could make the difference explicit

This is where a metadata-driven architecture becomes particularly useful.

The platform does not need completely separate software products for every domain.

The DSL can describe:

• what entities matter;
• what events trigger work;
• what lifecycle model applies;
• what resources are required;
• what relationships matter;
• what workflow should be followed.

So the common engine remains.

The domain model changes.

That is different from merely hiding or renaming fields in one generic work-order form.

This could also improve integration with enterprise systems

The same architecture can coexist with SAP, Maximo, MEX or another CMMS.

A specialised CPM workflow could determine:

What should be done
Why
When
Priority
Resources
Operational consequence

and then issue the execution transaction into the enterprise system:

CPM Domain Model
        ↓
Maintenance Requirement
        ↓
SAP / Maximo / MEX Work Order

The enterprise CMMS remains the system of record for execution.

CPM provides the domain context.

That may be more realistic than trying to replace large installed systems.

A working hypothesis

The proposition is not that common maintenance systems are wrong.

Common structures are necessary.

The question is whether common structures have sometimes been allowed to become common workflows where the underlying work is not actually common.

A useful principle may be:

Standardise what needs to be shared. Specialise what needs to reflect the way the asset is actually operated and maintained.

The asset register can be common.

Work transactions can be common.

People, costs and materials can be common.

But the operating models that determine when, why and how work occurs may need to remain different.

Questions worth testing

Where should the common enterprise maintenance model stop and the asset-specific model begin?

Which parts of work management genuinely need to be universal?

Should roads, structures and processing plants use the same scheduling metaphor as mobile plant?

Should work packages and programs sometimes sit above individual work orders?

Can a common resource model support very different domain-specific optimisation methods?

How much complexity is created when organisations force specialised work into generic CMMS workflows?

And perhaps the broader question:

Are we simplifying the software by assuming that all maintenance work is fundamentally the same, while transferring the real complexity back to the people operating the assets?

If so, the opportunity may not be to build a more configurable work-order screen.

It may be to recognise that different assets genuinely require different operating models.