Flagship product
Stannar — the reliability system of record
The why behind your maintenance plan lives in three overlapping spreadsheets and a few people's heads, and walks out the door when they do. Stannar makes it one defensible record that sits beside your CMMS, not inside it.
Your CMMS records what was done; it cannot tell an auditor why PMP-1234 is High criticality. Stannar can. Author one FMECA study, scope it across the fleet, and every covered asset gets a criticality derived from it — traceable to the study, the engineer, and the date, and never changed without sign-off.
Pump class — 40 assets
1 study authoredPMP-1234 — PM justification
Criticality due for review
2 awaiting adoptionThe problem it exists to solve
A criticality assessment is a real piece of engineering. Someone sits down with the process flow, the consequence categories and the failure history, and makes a defensible call about what happens when this asset stops. Then the whole thing gets compressed into a single letter, typed into a field in the CMMS. Everything that justified it stays in the workshop spreadsheet.
Eighteen months later the duty changes, or a new asset joins the fleet, or an auditor asks why a task is on the plan. The letter is still sitting in the field. The reasoning is in a file three people have edited independently and none of the copies says which one is current. You have all of it and none of it.
Everyone treats this as a discipline problem. It is not, and no amount of template governance has ever fixed it. The analysis has nowhere durable to live, so it decays. Stannar is somewhere to put it.
How it works
Coverage at speed
Author one FMECA study for an asset class and scope it across the assets that share its operating context. Forty pumps do not need forty studies. They need one study and an explicit statement of which assets it covers. Doing this for one pump is an afternoon. Doing it for four hundred, and keeping it current as duties change, is where the afternoon turns into a job nobody has time for.
Defensible by construction
Every adopted rating carries its provenance: the study it came from, the engineer who signed it off, and the date. So when someone asks why this asset is A-critical, you can answer without ringing anyone.
Human-authored, not inferred
Nothing is guessed from CMMS master data. An agent can propose; a person ratifies. You can absolutely derive a criticality by pattern-matching equipment descriptions, and it will look convincing right up until someone asks a second question about it.
Stale, not silently overwritten
When fresh analysis changes a rating, the asset is flagged stale and waits for sign-off. Nothing changes underneath you while you are not looking. That is most of what "record" is doing in the name.
A loop, not a filing cabinet
Recorded failures feed back into the FMECA, so the maintenance plan sharpens with every event instead of ageing away from reality.
Where it sits
The asset master and the work orders stay where they are. SAP PM, Maximo and Ellipse hold the transactions, the hierarchy and the cost history, and Stannar does not replace them or try to. It holds the layer those systems were never built to hold: failure modes, criticality, task justification, and the provenance of each.
We say that out loud because the bigger claim is available and we are not making it. Tell a buyer you are the system of record for everything and the first thing they will say is that you are a downstream copy of SAP. They would be right. We hold the reasoning, which SAP has never claimed to hold and does not want.
See it against your own assets
There is no signup form. A walkthrough runs on your asset classes and your consequence categories rather than a demo dataset, which is more useful to both of us and stops the demo from being a magic trick. If you would rather start with the analysis than the software, we do that too: see FMECA facilitation and maintenance strategy review and criticality frameworks and ISO 55001 readiness.
Book a walkthrough