Plant & Equipment Custody: Tracking Assets That Move Every Week
A contractor's plant is capital designed to move — and that mobility is exactly why it goes idle, goes missing, and breaks down unplanned. Custody and movement history are what a register can give you; the service schedule is a discipline you keep beside it.
Plant is where a contractor's balance sheet lives out in the mud: mixers, compactors, generators, pumps, scaffolding, and a long tail of power tools, together representing serious capital. Unlike a factory's machines, this capital is designed to move — between sites, between crews, in and out of the yard — and that mobility is the whole problem. A generator on a finished site while another job hires one in. A compactor nobody can locate on a Monday morning. A register that was accurate the day it was typed and fiction within a month. Controlling plant is the discipline of always knowing three things: where each item is, who holds it, and when it was last serviced. The first two a register does well. The third, as this article is careful to say further down, it does not hold at all.
Custody: an asset is somebody's responsibility
The foundational control is custody. Every significant item of plant has, at any moment, exactly one named person responsible for it — a site agent, a foreman, an operator. When plant moves, custody transfers with it, recorded as a hand-off from one person to another. This does two things at once. It makes "where is the poker vibrator?" a lookup instead of a phone-around, and it changes behaviour: equipment that is always somebody's named responsibility is looked after very differently from equipment that belongs vaguely to "the company." Most tool loss is not theft; it is diffusion of responsibility, and custody is its cure.
Movement history: the register that stays true
A plant register is only useful if it reflects reality, and a register updated by memory never does. The fix is to make location a consequence of recorded movements rather than a field someone is supposed to edit: each transfer of plant between sites is logged the way material transfers are, so current location is always derived from the last movement. The by-product is a full history — this machine has been on four sites this year, and has not moved since the first week of August — which is exactly the data that exposes the second big plant cost: idle capital.
Idle plant: the machine you pay to own and do not use
Owned plant costs money whether it works or not — capital tied up, depreciation, insurance, storage. So idle plant is pure loss, and the most expensive plant mistake is hiring in equipment while an identical machine sits unused on a finished site because nobody knew it was free. Here the movement history earns its keep, though you should know exactly what it gives you: not a utilisation percentage, but a set of dates. A machine whose last movement was five weeks ago is idle, and you can see that by looking. Turning those dates into a utilisation figure per machine is arithmetic you do yourself, on a sheet, and for most contractors the by-eye version is enough to catch the hire-in-while-idle mistake that pays for the whole exercise.
| Plant cost | How it happens | What controls it |
|---|---|---|
| Lost tools | Responsibility diffused across "the company" | Named custodian on every item |
| Cannot locate plant | Register edited by memory | Location derived from logged movements |
| Idle equipment | No view of what is free vs in use | Movement dates read by eye; no utilisation figure |
| Unplanned breakdown | Service by reaction, not schedule | A service schedule you keep outside the register |
Maintenance: scheduled beats stranded
The last discipline is service, and it is the one this system does not help you with. Plant that breaks down mid-job does not just cost the repair — it can stall a pour, idle a crew, and blow a programme, so preventive maintenance on a schedule is far cheaper than reactive repair on a deadline. That is true and worth doing. It is also, here, entirely manual: an asset record holds no service interval, no last-service date and no next-service-due date, and nothing will raise a service when it falls due. Keep the schedule where somebody looks at it — a wall chart in the yard, one row per machine, next service by date and by hours — and treat the register as the answer to where is it and who has it, not when is it due.
Plant is an asset register, not a spreadsheet
The reason plant control fails is that it is usually attempted in a spreadsheet that only one person maintains. Treating plant as proper assets — with custody, movement history and condition recorded on every hand-off — is the same discipline as any fixed asset register, applied to capital that happens to move. Once it moves on recorded transfers, that much of the register maintains itself. The service calendar does not, and stays on your wall chart.
Plant custody is one pillar of the contractor's wider operation, sitting alongside materials control and job costing. Together they answer the question a contractor most needs answered and most often cannot: not just "did this job make money?" but "is this whole business — its materials, its cost, and its capital — actually under control?"
What AWRA OpsHub does today
- Every machine as an asset with serial number, purchase cost and date, status and warranty expiry.
- A named custodian and full movement history — check-out, check-in, transfer between sites and relocation — each carrying condition before and after, who performed it and when.
- GPS capture on movements, which can be made mandatory per movement type.
- Verification, so a site walk-round records that each item was seen, by whom and when.
- Retirement with a reason, a date and an actor.
- Offline-capable capture for site walk-rounds.
More we can add to your workspace
- Utilisation tracking: meter readings, engine hours and idle-versus-working time, which is what makes "live utilisation" a screen rather than movement dates read by eye.
- Service scheduling: a service interval, a last-service and next-service-due date, and a reminder that raises the service for you.
- A maintenance event at all. A repair or service cannot be recorded against a machine. The asset carries a status that can be set to "maintenance" by editing the record, but that overwrites the previous status and leaves no dated trail, so time out of service is not recoverable from the history.
- Work orders, so a repair is not a job with a cost, a completion or a supplier.
- Depreciation, so plant book value is not maintained.
- A hire or charge-out rate, so plant cost cannot be recharged to a job automatically.
The custody chain is genuinely strong and answers the question that matters most on a multi-site contractor — where is it and who has it. Servicing is the honest weak point, and it is a bigger build than it looks: the scheduler needs somewhere to record that a service happened before it can raise the next one. Keep maintenance on a sheet or a wall chart for now, and buy this for custody and location rather than for upkeep.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsControl the fleet you already own
Every machine with a named custodian, full movement history between sites, condition on every hand-off, and a verification trail from your last site walk-round.
Explore construction operationsFrequently asked questions
How do you keep a plant register accurate when equipment moves constantly?
By deriving location from recorded movements rather than a field someone edits. Each transfer of plant between sites is logged, so current location is always the result of the last movement, and a full history builds automatically. A register that depends on someone remembering to update it is wrong within weeks; one that is a by-product of logged transfers stays true.
What is the biggest hidden cost in construction plant?
Idle capital. Owned plant costs money whether it works or not, so equipment sitting unused is pure loss — and the classic mistake is hiring in a machine while an identical one sits idle on a finished site because no one knew it was free. Movement history is what catches it, but be clear on the form it takes: you get dates, not a utilisation percentage. A machine that has not moved in five weeks is visible to anyone reading the history; converting that into a utilisation figure is arithmetic you do on a sheet.
Why assign a named custodian to every item of plant?
Because most tool and equipment loss is not theft but diffused responsibility — things that belong vaguely to "the company" are looked after poorly. When each item is always exactly one named person's responsibility, and custody transfers on hand-off, behaviour changes and "where is it?" becomes a lookup instead of a phone-around.
How should plant maintenance be scheduled?
On a schedule you keep outside this system, because the asset register will not do it for you. The discipline itself is worth the effort — preventive maintenance beats reactive repair on a deadline, and a breakdown mid-job can stall a pour and idle a crew, costing far more than the repair. But an asset record holds no service interval, no last-service date and no next-service-due date, nothing raises a service when it falls due, and there is not even a way to record that a service took place. Run it from a wall chart in the yard, one row per machine, next service by date and by hours, and use the register for custody and location instead.
Can we see how long a machine was out of service for repair?
No, and it is worth knowing why before you plan around it. There is no maintenance event on an asset — a repair cannot be logged as a movement the way a transfer can. The nearest thing is the asset's status, which somebody can edit to "maintenance" and later edit back, but each edit overwrites the last and leaves no dated record. Downtime per machine therefore has to be kept wherever you keep the service schedule.
