Asset management

The governance layer around reliability decisions: criticality frameworks, lifecycle planning, failure data structure, and the evidence trail that has to hold up when someone asks. Perth-based, working across WA and nationally.

Reliability engineering works out what to do with an asset. Asset management is how you know that call was sound, consistent with the ones made down the corridor, and still current. Sites fail audits on the second one, almost never the first.

Asset criticality frameworks

Most sites have a criticality rating on every asset and no consistent basis behind any of them. They were set at different times, by different people, against consequence categories that were never quite written down. So an A-critical pump in the concentrator means something different from an A-critical pump two areas over, and everybody has quietly known this for years.

We design the framework: the consequence categories that actually matter to your operation — safety, environment, production, cost, compliance, and whatever else your business genuinely cares about — the scales within each, and the rule that turns a handful of consequence assessments into one rating. Then we apply it, starting with the asset classes where the answer changes what you do on Monday.

Here is the test. Put two competent engineers on the same asset separately. Do they land in the same place, and can either of them explain how they got there to someone who was not in the room? Producing ratings is easy. Anything produces ratings.

ISO 55001 gap analysis and audit readiness

ISO 55000 describes an asset management system — the policy, the objectives, the decision making, and the evidence that it all works the way you say it does. The standard is the easy part. The hard part is that most sites are doing perfectly reasonable engineering and cannot show it, because the showing lives in email threads and somebody's personal drive.

Our gap analysis is deliberately narrow. Where is the evidence, is it current, and would it survive being asked for cold on a Tuesday? You will not get a maturity score out of us — a number between one and five has never once helped anybody. You get a list of the specific things an assessor will ask for that you cannot currently put your hands on, ordered by how long each takes to fix.

For calibration, the usual findings: criticality ratings with no traceable basis, PM tasks with no documented failure mode, studies that exist but cannot be identified as the current one, and a review cycle that is beautifully described in a procedure and evidenced absolutely nowhere.

Lifecycle and renewal planning

Repair, refurbish or replace is a question about total cost over remaining life. It gets answered from the maintenance budget, because that is the number sitting in front of the person who has to decide this week. We build the lifecycle picture — acquisition, maintenance, failure consequence, disposal — so the call is made against the whole cost instead of the visible slice of it, and so the reasoning is still there for whoever inherits the asset.

Failure data that is worth having

Failure history only supports analysis if it is coded consistently. Most CMMS failure coding was configured once during implementation, by someone who has since left, and has been degrading ever since. We work on the taxonomy — ISO 14224 as a starting point, adapted where your equipment population justifies it — and on the question everyone skips: what can a maintainer realistically pick at 3am without getting it wrong. Build a taxonomy nobody can use and you get worse data than having none, plus a report that says coverage is 100%.

Keeping it current

A framework delivered as a document is current for exactly one day. Where you want it to stay live instead, we build it into Stannar — the reliability system of record that sits beside SAP, Maximo and Ellipse: the consequence framework is encoded once, each adopted rating carries the study, the engineer and the date behind it, and a rating superseded by fresh analysis is flagged for sign-off rather than silently overwritten. The asset register itself stays in your EAM.