Mean Time to Repair

Mean Time to Repair

Goal of the analysis:

Measure and reduce the average time required to restore an asset to a functional state after a failure. Mean Time to Repair (MTTR) quantifies how long the full repair cycle takes—from failure occurrence to return-to-service—not just “wrench time.” It is a primary lever, together with MTBF, for improving Availability and throughput. Executives use MTTR analysis to recover capacity without capex, stabilize lead times and OTIF, reduce overtime and premium freight, optimize technician staffing and spares holdings, and drive design-for-maintainability and diagnostic improvements.

Data required:

  • Event and state telemetry (MES/SCADA/OEE):
    • Time-stamped states: Running, Breakdown/Repair, Fault/Safety stop, PM, Setup; event start/stop times, operator Andon calls.
    • Alarm logs and codes around failure onset; micro-stop threshold policy.
  • Maintenance work history (CMMS/EAM):
    • Corrective work orders with failure start, response arrival, repair start, repair finish, test/commissioning complete; failure/asset/component codes.
    • Labor time (clocked and wrench), number of techs, shift/crew, priority, parts used, deferrals, and rework (repeat failure within X hours).
  • Spares and materials (Storeroom/ERP):
    • Parts reservations/issuance timestamps, stockouts, kit completeness, lead times, critical spares min/max.
  • Asset and operating context:
    • Asset hierarchy and criticality (A/B/C), bottleneck designation, nameplate/demonstrated rates, duty cycle/load, changeover matrix.
  • Labor and coverage (LMS/HR):
    • Technician rosters, certifications, callout/response SLAs, overtime, contractor usage.
  • Documentation and diagnostics:
    • Standard job plans/SOPs, troubleshooting trees, wiring/pneumatic diagrams, past RCAs, condition-monitoring results (vibration, thermography, oil).
  • Normalization and policy:
    • Definition of “repair complete” (ready for production vs first good), inclusion/exclusion of waiting-for-operations or QA sign-off, time zone/shift calendars.

Detailed step-by-step instruction on how to conduct the analysis:

  1. Define the metric and time boundaries.
    • Event start (failure) = transition to Breakdown/Fault state that halts production.
    • Event end (repair complete) = asset restored to function and released to production (include test/commissioning if required by policy).
    • MTTR = Σ (repair durations) ÷ number of repair events. Also compute P50/P75/P90 to understand tails.
    • Break repair duration into sub-states: detection/notification, response travel, diagnosis, parts retrieval, repair execution (wrench), test/commissioning, handover/waiting for ops.
  2. Extract and align data.
    • Pull 8–12 weeks of MES/SCADA state logs and CMMS corrective work orders; map each failure event to a work order and align timestamps.
    • Join to storeroom issues (parts timestamps), technician rosters, and alarm logs; standardize reason codes and asset IDs.
  3. Clean and reconcile.
    • Merge contiguous repair states; remove duplicate work orders; correct obvious misclassifications (starved/blocked ≠ breakdown).
    • Enforce a consistent “repair complete” time (e.g., end of commissioning or first good); document exceptions.
  4. Compute MTTR and sub-time profiles.
    • For each asset and failure mode: calculate MTTR (mean/median/P90) and the share of time in detection, response, diagnosis, parts wait, wrench, test, and handover.
    • Compute Repeat Within X Hours (%) to capture ineffective repairs.
  5. Segment and compare.
    • By asset/line, component/subsystem, failure code, shift/crew, day vs night/weekend, product family/changeover pair, and criticality (A/B/C).
    • Contrast bottleneck vs non-constraint assets; evaluate technician skill/certification effects.
  6. Pareto and bottleneck identification in the repair process.
    • Pareto MTTR minutes by failure mode and by sub-time category (e.g., parts wait, diagnosis) to find primary delays.
    • Build a repair value stream map to visualize queues and non–value-added waits.
  7. Link to availability and business impact.
    • Availability = MTBF ÷ (MTBF + MTTR); quantify ΔAvailability if MTTR improves by Y% on constraint assets.
    • Translate recovered hours to units (× demonstrated rate × FPY) and $ contribution; include overtime/premium freight avoidance.
  8. Root-cause and effectiveness checks.
    • Review RCAs for top repeat failures; ensure corrective actions exist and are verified.
    • Compare planned job plans vs actual elapsed times to identify gaps in SOPs, tooling, and access.
  9. Scenario and what-if modeling.
    • Quantify impact of spares kitting (−parts wait), technician coverage changes (−response), standardized diagnostics (−diagnosis), modular design (−wrench), and remote resets (−detection/response) on MTTR and throughput.
  10. Integrity checks.
    • Ensure events sum to Scheduled Time; align CMMS labor to MES event windows; audit a sample against operator logs; keep “unknown/other” <10% of minutes.

Format of the output of analysis:

  • Executive scorecard: MTTR (mean/median/P90) by asset/line, Availability %, MTBF, repeat-within-X-hours %, capacity and $ impact, trend vs target.
  • Pareto charts: MTTR minutes by failure mode and by repair sub-time category (parts wait, diagnosis, response, wrench, test).
  • Repair timeline visuals: event Gantts and stacked bars showing sub-time distribution per repair; before/after comparisons.
  • Heatmaps: MTTR by asset × shift/crew and by component/subsystem.
  • Scenario/ROI sheet: expected MTTR reduction and units/$ recovered from kitting, staffing, diagnostics, modularization, and remote support.

How to interpret results:

  • High MTTR with low failure frequency: Serviceability/process issue—focus on parts availability, access/ergonomics, SOPs, and technician response rather than reliability.
  • Large “parts wait” share: Storeroom planning/kitting gap; set critical spares min/max, pre-kit PM/correctives, and improve BOM accuracy.
  • Long detection/response times: Weak Andon/alarms or thin coverage; add auto-notification, escalate SLAs, and cross-train operators for safe resets.
  • Diagnosis time dominant and variable: Lack of standard troubleshooting; deploy fault trees, quick-reference guides, and onboard diagnostics.
  • Extended test/commissioning/handover: Centerline or QA sign-off friction; standardize centerlines, automate recipe verification, and streamline sign-off.
  • Shift-to-shift MTTR gaps: Skill/capability variance; re-balance staffing, certify techs, and mentor night/weekend crews.

Steps a company can take to improve on this measure:

  • Spares and kitting:
    • Create critical-spares kits and mobile crash carts; reserve parts at plan time; maintain min/max based on failure history and lead time.
  • Diagnostics and standard work:
    • Publish troubleshooting trees and job plans with photos/videos; embed digital work instructions; add onboard/edge diagnostics and remote support (AR/telemetry).
  • Coverage and response:
    • Establish callout SLAs; stagger shifts or add on-call coverage at peaks; Andon alerts to tech mobiles; empower operators with safe reset procedures.
  • Design for maintainability:
    • Modularize components for quick-swap; improve access/ergonomics; add quick-disconnects and alignment guides; standardize fasteners.
  • Process and handover:
    • Pre-authorize test recipes and centerlines; define clear “ready for service” gates; co-locate QA/operations sign-off to shorten commissioning waits.
  • Governance and skills:
    • Weekly reliability huddles on MTTR/MTBF with action closures; certify technicians on top failure modes; track “repeat within 24h” and enforce RCAs.
  • Example scenarios:
    • If MTTR median is 78 minutes with 28 minutes in parts wait, implement kitting and critical-spares min/max; target median ≤45 minutes and +3–5 pts Availability on the constraint.
    • If diagnosis averages 30 minutes with high variance on control faults, deploy fault trees and PLC alarm rationalization; expect diagnosis −40–60% and MTTR −25%.
    • If night-shift MTTR is 2× day-shift, add on-call senior tech coverage and certify crews; close the gap by half within two cycles.

Benchmark comparisons:

General benchmarks:

  • Discrete/high-mix assembly: MTTR commonly 20–60 minutes on critical stations; world-class 20–45 minutes with strong kitting and SOPs.
  • Process/continuous industries: MTTR on critical assets typically <60 minutes, though complex overhauls run longer; focus on rapid diagnosis and access.
  • Response SLAs: technician response (to asset) ≤10–15 minutes in staffed plants; parts wait should be ≤15–20% of total repair time for A-assets.
  • Availability targets: mature operations 90–95%+; Availability = MTBF ÷ (MTBF + MTTR) underscores MTTR leverage when failures are unavoidable.

Constructing internal benchmarks:

  • Track MTTR weekly by asset/shift and failure mode; publish quartiles and set redlines (e.g., P90 MTTR >90 minutes on A-assets triggers RCA).
  • Set sub-time targets: response ≤15m, diagnosis ≤20m, parts wait ≤15m, wrench ≤30–45m for the top 10 failure modes.
  • Pair MTTR with MTBF, Unplanned Downtime Hours, and Availability; prioritize assets where MTTR reduction yields the largest capacity gain.
  • Rebaseline after kitting, staffing, diagnostic, or design changes; codify best-cell practices (kits, SOPs, sign-off flow) as standards.

How to get started

1

arrow-down-blue

Tell us about your project

2

arrow-down-blue

Interview candidates

(We’ll provide bios within 48 hours on average)

3

Select your consultant and start work

Find a Consultant

or email us at: [email protected]