Quartania

Reliability engineering

We facilitate the analysis maintenance plans are supposed to be built on — FMECA, RCM, PM optimisation, failure investigation — for reliability teams in mining, utilities, heavy industry and infrastructure. Perth-based, working across WA and nationally.

From what we have seen, most sites do not have a reliability problem. The plan is broadly sensible and the people running it know what they are doing. Pick any single task on it and ask why that task, at that interval, and watch what happens.

FMEA and FMECA facilitation

An FMECA is only as good as the room it was run in. We facilitate the workshop — maintainers, operators, the reliability engineer, and whoever actually remembers what happened last time — and hold it to one consequence framework, so the output from the pump class can be compared with the output from the conveyors.

You get a study: each failure mode with its detection method, its consequence assessment, and the task that addresses it — or a written decision to run it to failure, which is a legitimate answer nobody ever writes down. Where an existing study just needs review, we review it. Re-running analysis that was fine burns the workshop time that should have gone to the gaps.

Scoping matters more than people expect. Forty pumps sharing an operating context need one study and an explicit statement of which assets it covers. Forty near-identical documents will have diverged by this time next year and nobody will know which one is right.

RCM and PM optimisation

Full RCM gets proposed far more often than it is the right tool. It is expensive in the scarcest resource on any site, which is the attention of the people who actually know the plant. On an existing plan with reasonable coverage, a PM optimisation gets you to a defensible answer faster and for less of everyone's week.

We will tell you which one your situation warrants, including when the answer is neither. PM optimisation usually sorts the plan into three piles: tasks that stay and now have their justification written down, tasks whose interval moves with a stated basis, and tasks that come off entirely. The third pile is where the money is. It is also the one nobody will sign without a written rationale, which is the whole reason the work exists.

Maintenance strategy review and PM justification

Finance challenging the PM budget and an auditor asking why a task exists are the same question wearing different clothes: what is the engineering basis for this? We rebuild that basis task by task — failure mode, consequence, interval, evidence — in language a manager and a finance business partner will actually accept.

Tasks accumulate. An OEM recommendation goes in at commissioning. A supervisor adds an inspection after a bad failure. A temporary check quietly becomes permanent because nobody ever came back to remove it. Nothing on that list is unreasonable. What almost never happens is anyone asking whether each one still has a basis. It is unglamorous work and it is usually the highest-value thing on the list.

Failure investigation

After a significant failure the useful output is a change to the plan that stops the recurrence, plus a record of why the change was made. Skip the second part and someone without the history quietly reverses it in two years. We have seen that happen to a task that existed for an extremely good reason.

Doing this at fleet scale

Running the analysis once is a project with an end date. Keeping it current as duties change, assets get added and people move on is the part that quietly defeats everyone, and a bigger spreadsheet has never once solved it.

That is what we built Stannar — the reliability system of record that sits beside SAP, Maximo and Ellipse — to hold. One authored study scopes across the assets that share its context; every adopted criticality carries the study, the engineer and the date; a rating changed by fresh analysis is flagged stale and waits for sign-off. The asset master and the work orders stay in your EAM. Engaging us for the analysis does not commit you to the software.

Start with the deadline

A review date, an audit finding, a budget challenge — that is enough to scope from. If the governance layer is the actual gap rather than the analysis, see asset management, criticality frameworks and ISO 55001 readiness.

Talk to us