Failure-Mode Mappings

Failure-mode mappings are an optional curation layer that narrows the cause picker the technician sees when diagnosing a breakdown. They are useful when you have reliability data on a particular asset class (CNC mills, hydraulic presses, refrigeration units, …) and want the floor to pick from a realistic shortlist rather than the full cause-code vocabulary.

You do not need a mapping for every asset class. Classes without mappings simply fall back to the broader “causes that apply to this asset class” list — the cause picker is never blocked.

When you should add a mapping

You have a mapping case as soon as your team can say “on a CNC mill, when the operator reports excessive vibration, the cause is almost always one of: bearing worn, installation error, operator error”. Encoding that knowledge as three mapping rows turns the technician’s cause picker — which would otherwise show every cause that applies to machine tools — into a curated shortlist. New hires diagnose faster, the Pareto buckets get cleaner, and your reliability KPIs stop being polluted by guesses.

Curate the mappings only for asset classes where you actually have reliability data. Leaving the table empty for the rest is the right choice; the broad picker handles those classes already.

How the picker behaves

The cause picker on a work order works in two steps:

Mapped causes. If at least one active mapping exists for the (asset class, problem code) pair, the picker shows only the mapped causes. This is the curated shortlist.
Fallback. If no mapping exists for that pair, the picker shows the broader list — every active cause whose “applicable asset classes” either includes this class or is empty (the “any class” convention).

Both lists are sorted by code so the same shortlist appears in the same order every time. While someone submits or triages a work request, a Likely causes preview appears showing exactly what the technician’s cause picker will offer. The preview is labelled Mapped causes when a curated mapping narrowed the list, or Causes for this asset class when the broader fallback list is being used — so you can see at a glance whether the org has reliability data on this asset class yet.

What lives on a mapping

Field	What it means
Asset class	Taxonomy node the mapping applies to (CNC mill, hydraulic press, HVAC unit, …). A mapping fires only on assets that belong to this class.
Problem code	The observed-failure code the operator picks at work-request time (excessive vibration, oil leak, won’t start, …).
Cause code	The root-cause code the technician selects after diagnosis (bearing worn, installation error, operator error, …). Add one mapping row per plausible cause — three causes for a pair means three rows.
Notes	Free-form hint shown to the technician when the cause is offered. Use it to nudge less-experienced techs (“listen for a knock during start-up”, “check spindle alignment first”, “likely consumes part X”).
Seed origin	Provenance tag. `CUSTOM` is a mapping your team authored. `IMPORT` came in via an FMEA spreadsheet import. Blank means a legacy or unset row. Beelocity’s shipped catalog seeds problem, cause, and remedy codes but no mappings, so every mapping you see is one your team created or imported — none is overwritten by Beelocity.
Active	Soft-disable flag. Inactive mappings stay on historical work orders but disappear from the cause picker. Use it to retire curated rows without losing the audit trail.

Worked example

You run a small machine shop. The work-order history on your two CNC mills shows that “excessive vibration” almost always comes down to three causes — bearings, installation, or operator error. Adding three mappings:

Asset class	Problem code	Cause code
`CNC_MILL`	`EXCESSIVE_VIBRATION`	`BEARING_WORN`
`CNC_MILL`	`EXCESSIVE_VIBRATION`	`INSTALLATION_ERROR`
`CNC_MILL`	`EXCESSIVE_VIBRATION`	`OPERATOR_ERROR`

Next time an operator submits “excessive vibration” on a CNC mill — a request paying overtime at 2 500 DA/hour to triage — the technician opens the work order and the cause picker offers exactly those three options. The other ten causes that technically apply to “machine tools” stay hidden. Diagnosis is faster, the cause column on the Pareto report is cleaner, and your spare-parts demand forecast for spindle bearings gets the signal it needs.

If you later acquire a third mill and start seeing a different failure pattern — say, lubrication issues — you add a fourth mapping row. The catalog is yours; Beelocity never rewrites your CUSTOM rows.

Curation tips

Start with your top problems. Open the Top problems by asset class report. Pick the three problems that account for most of your breakdown work orders, then list the causes you actually see on closed orders. Encode those.
Keep the shortlist short. Three to five causes per (class, problem) pair is the sweet spot. A 10-row shortlist is barely a shortlist.
Leave classes alone if you have no data. The fallback list is fine. Empty mappings beat speculative ones.
Use Notes generously. The cause picker shows the notes inline; one sentence on the diagnostic step that confirms the cause pays back the first time a junior tech needs it.
Deactivate, do not delete. Once an order has been closed against a mapping, deleting that row removes the audit context. Toggle Active off instead.