How Does the Level of Repair Analysis (LORA) Work?

Level of Repair Analysis (LORA) is a structured decision process for failed parts. It works out whether a failed component should be repaired on-site, sent to a higher repair level, or scrapped and replaced. The method compares the cost, downtime, and logistics of each option. It then assigns each part to whichever option costs the least over its full lifecycle, without hurting equipment uptime. Most industrial and defense teams turn this into a repeatable check instead of a one-off judgment call.

Key Takeaways

• LORA looks at total lifecycle cost, not just the repair bill: It weighs repair cost, downtime, logistics, and spare-parts supply together.
• Four maintenance levels get evaluated: Organizational, intermediate, depot/OEM, and replace-or-discard each have a different cost and turnaround.
• The process follows a set workflow: Identify the failure, gather data, compare costs, then pick, apply, and monitor the decision.
• A CMMS supports LORA but doesn't replace it: It centralizes the asset, cost, and inventory data the analysis needs.

What Is Level of Repair Analysis (LORA)?

Level of Repair Analysis (LORA) is a process that decides whether to repair, replace, or escalate a failed part. The method started in defense and aerospace logistics. Planners used it to decide where in the supply chain each part should be fixed. Manufacturing and facilities teams now use the same logic for industrial gear. It turns a decision that used to depend on whoever was on shift into a fixed standard.

A Computerized Maintenance Management System (CMMS) supports this goal in a simple way: cut total lifecycle cost while keeping equipment running. LORA does this by scoring each repair option on cost, downtime, and reliability. It does not default to "always repair" or "always replace." The logic sits close to reliability-centered maintenance (RCM). Many teams run both side by side. RCM decides which failures matter most. LORA decides where each resulting repair should happen. According to the Wikipedia overview of level of repair analysis, the method is widely used across defense logistics planning to set support strategy before equipment even enters service.

What Data Goes Into a Level of Repair Analysis?

A LORA is only as good as the data behind it. Weak or missing data is the top reason a level-of-repair call looks right on paper but fails in the field.

• Asset criticality: How much risk does downtime on this asset create?
• Failure modes and history: What has failed before, how often, and why?
• MTBF and MTTR: How often does the part fail, and how long does a repair take?
• Repair cost vs. replacement cost: What does each option cost in parts and labor?
• Logistics and transport: What does it cost to move the part to a repair site?
• Technician skills and tooling: Can the current site even repair this part?
• Spare-parts supply, warranty, and rules: Is a spare in stock, and is the part still under warranty?

Most of this data already sits somewhere in a maintenance operation. The problem is that it is scattered across spreadsheets and memory. Centralizing asset records and asset tracking data in one system is what makes a LORA repeatable.

The Four Maintenance Levels in a Level of Repair Analysis

Organizational-level maintenance is on-site repair by the equipment operator's own team. A LORA checks this option against three others, each with its own cost and turnaround.

Placing each part on the right row — rather than defaulting every job to one level — is the main output of a LORA.

Use the mean maintenance cost calculator to weigh an asset's running repair cost against its replacement value before you pick a level.

How the LORA Process Works: Step-by-Step

A Level of Repair Analysis follows a set order. Each step feeds the next. Skip one, and the final call often ignores a real cost.

The LORA Decision Process:

• Identify the failure: Confirm what failed, on which asset, and under what conditions.
• Collect maintenance and cost data: Pull failure history and cost records for this part and similar past events.
• Evaluate repair options: List every level that can perform the repair, from organizational up to OEM.
• Compare lifecycle costs: Line up total cost — repair, downtime, logistics, and risk — for each option.
• Choose the maintenance level: Pick the lowest-cost option that still meets your uptime target.
• Implement the strategy: Route the repair to the chosen level and log it in the work order management record.
• Monitor performance: Track whether the level keeps delivering the expected cost and speed, and revisit if it doesn't.

This order turns a one-time judgment call into a decision the whole team can repeat for the next failure of the same type.

Key Decision Criteria in a LORA

Lifecycle cost is the full cost of an asset from purchase to disposal. A LORA weighs several factors together to reach that number for each repair level.

• Repair cost vs. replacement cost: The direct dollar comparison, but rarely the deciding factor alone.
• Downtime impact: How much output is lost while the part is out for repair. Downtime tracking data makes this real instead of guessed.
• Labor and tooling: Do the right skills and tools exist at this level?
• Transport and logistics: How much time and money does moving the part cost?
• Reliability gain: Does the repair also raise MTBF, or just restore the part to its old state?

Most maintenance teams find that downtime and logistics cost — not the repair invoice — are what actually separate a good level-of-repair call from a poor one.

Benefits of a Structured LORA Process

A formal LORA swaps out inconsistent, technician-by-technician calls for one standard the whole team can follow.

• Lower lifecycle cost: Every repair call gets checked against total cost, not just the repair invoice.
• Better spare-parts stock: Knowing which level handles which repair lets teams stock spare parts inventory where it is actually needed.
• Less downtime: Faster, clearer routing cuts the time parts spend waiting on a decision.
• Standard repair calls: New technicians and new sites use the same rule instead of guessing.
• Better reliability and budgets: Cost visibility by level feeds sharper maintenance budgets.

Common LORA Challenges

A LORA is only as strong as the data behind it. Most LORA programs run into the same few problems.

• Data quality gaps: Thin failure history or missing cost records make a call look sharp but rest on guesswork.
• Changing conditions: A level picked under one duty cycle can turn wrong once conditions shift.
• Hidden logistics costs: Transport and handling costs often get underrated, tilting the call toward off-site repair.
• Skill gaps and OEM lock-in: A level can look cheap on paper but fail if the skill or OEM slot isn't actually free when needed.

How a CMMS Supports LORA Decisions

A CMMS does not run a Level of Repair Analysis by itself. The calls on cost, risk, and reliability still belong to maintenance engineers and reliability leads. What a CMMS does is pull together the asset, work order, and inventory data a LORA needs, so the call rests on full records instead of scattered notes.

Asset and failure history give the analysis its raw material. Work order data shows real repair time and cost by level. Inventory records confirm spare-parts supply before a repair route gets picked. Reporting and BI dashboards then surface the cost and downtime pattern that backs up — or challenges — a level assignment already in place. Maintenance teams using Cryotos have reported up to 30% less unplanned downtime and 25% faster repair turnaround once routing calls run on real data instead of memory. This lines up with guidance from the ISO 55000 asset management standard, which frames good asset decisions as a balance of cost, risk, and performance across an asset's full life.

Most facilities that run LORA well treat the CMMS as the evidence base, not the decision-maker. The call stays a human judgment, backed by data the system keeps current. The Society for Maintenance and Reliability Professionals (SMRP) lists this kind of data-backed repair routing among the best practices that separate mature reliability programs from reactive ones.

Frequently Asked Questions

What is the difference between Level of Repair Analysis and a simple repair-versus-replace decision?

A repair-versus-replace call is a two-option comparison for one asset. A Level of Repair Analysis is broader. It checks every maintenance level, from on-site repair through OEM depot work and disposal, and applies that check the same way across a whole fleet of similar parts, not just one asset at a time.

How many maintenance levels does a Level of Repair Analysis typically evaluate?

Most LORA setups check four levels: organizational (on-site), intermediate (regional workshop), depot or OEM (manufacturer facility), and replace or discard. Some teams merge intermediate and depot into one "off-site" group, depending on their support network.

Can a CMMS run a Level of Repair Analysis automatically?

No. A CMMS pulls together the asset, cost, and inventory data a LORA needs, but comparing repair options on cost and risk stays a call made by maintenance engineers or reliability leads, using that data as their base.

How often should a company revisit its Level of Repair Analysis decisions?

Revisit a level assignment any time operating conditions, failure rates, or repair costs shift by a meaningful amount. Most teams do this as part of an annual maintenance strategy review, or right after a part's failure pattern changes. A level picked under one duty cycle can quietly turn wrong as usage or logistics costs move.

A Level of Repair Analysis turns scattered repair calls into one standard every technician and site can follow. Schedule a free demo to see how Cryotos centralizes the asset, cost, and inventory data your team needs to run LORA decisions with confidence.