KPI : Mean Time to Repair (MTTR)

Mean Time to Repair (MTTR)

Average time (e.g. in hours) between the occurrence of an incident and its resolution.

Details

Formula:

Average of time between resolution of incident and start of incident

Unit type: Time

Direction: Minimize

Unit: Hours

Benchmark Results

To access benchmark information, login and contribute, or alternatively take a look at KPI Benchmark, our premium data service that provides insight in KPI popularity, KPI benchmark scores and KPI strategy scores.

This KPI is most used for:

Operational Excellence

Listed in:
Systems, Database, Network, ITIL Incident management, IT Service Levels, Application, Web Hosting, Telephony, Maintenance, Email, Storage, Backup, ASL Incident management, MOF Incident Management, VRM Process Performance, VRM Support, IT Incident & Problem

Comments

1. 
   almost 3 years ago by charles Y.

   how?
2. 
   over 2 years ago by Beto S.

   MTTC + MTTS = MTTR
   Mean time to check + Mean time to Solution = Mean Time to Repair!
3. 
   over 2 years ago by dongyop L.

   do u think that is KPI? MTTR is attribute in the KPI.
   why is that KPI?
4. 
   almost 2 years ago by Muzzammil Ahmad

   yes it is not KPI, but only an attribute in the KPI.
5. 
   over 1 year ago by Eduardo C.

   Hello
   Does anybody can recomend me where can I get a benchmarking report on KPI in the industry. I’m interested in comparing our KPI vs other industries.
6. 
   over 1 year ago by The Librarian

   I would recommend posting this question in the Answer section for more visibility.
7. 
   over 1 year ago by NARAYAN RAO

   I think the MTTR is a composite performance measure which depends on the maintenance management systems which are in place. Thus , if all the systems are in place correctly , the MTTR would be a certain value , say 12 minutes. Where systems are not in place , the MTTR can stretch to hours.

   The first system which should be in place is the incident reporting system. How is a breakdown reported ? To whom is it reported ?

   The next system which should be in place is the breakdown attendance system. Who will take action on the incident ? If it is reported to a technician , is he / she authorised to take action ? Or does he / she , in turn have to report it to a higher authority , supervisor / engineer / manager ? Depending on the correctness of this system , the MTTR can vary significantly.

   Once the troubleshooting has started , more systems are needed. Are there circuit schematics and troubleshooting flowcharts available ? Do the people who are troubleshooting the problem have the right instruments and tools ? Are there spares available ? How much time is needed to look up the part number of a spare , and retrieve it from the plant store.

   Even after the problem is resolved , systems are needed. How is the machine handed back to the production department for production to resume ?

   What is the follow-up to the problem ? How are the used spares replenished ? How is the problem resolution documented ? What kind of reports are made ?

   Generating a reasonably correct value for the MTTR KPI should be based on all the relevant systems being put into place , rather than just giving a value , whether it is 12 minutes or 2 hours.
8. 
   10 months ago by Sherm H.

   If there are multiple systems or support groups involved in resolution, and possibly the incident is passed around from one group to another until ultimately the right groups fixes the incident, you should rightly calculate both the OLA as well as the SLA MTTR, so that if the “right” group gets the incident and resolves it in record time, and the SLA target time has already elapsed when the gotr the assignment, that “right” group is not dinged for the missed SLA. The business or whomever is impacted by the incident may not be happy with the duration of the resolution, but a faulty process for assignment of incidents is the problem, not necessarily the groups that get assigned the incident. Do an accurate, and quicker, job of assigning incidents, and MTTR will improve.
9. 
   10 months ago by Eduardo C.

   Hello all, trying to analize the components of this indicator in addition of what was told in previous comments, I wish to know your opinion about how TI services are clasified, i.e, in my company we have incidents clasified as: fails, problem, question and request this last is related to changes in systems solutions, new developments, etc., Does MTTR KPI includes all kind of incidents or only an specific one, like fails?
10. 
    10 months ago by NARAYAN RAO

    Hi Eduardo ,

    I think you should have a separate KPI for each type of incident , since the kind of diagnostic and corrective actions for each type would be different from one another ; the benchmark measure for resolving a fails incident would be different from the measure for resolving a request incident.

    Whether you should tackle only one type of incident or all of them would depend on the impact each of them has on your process / product. If the frequency of the request type incident is very low , and not time critical , probably a KPI would not really impact your process much.
11. 
    10 months ago by Eduardo C.

    Thank you Narayan. Could anybody of the participants share to me how are they using this KPI. Regards
12. 
    10 months ago by Sherm H.

    In my company we have separate KPIs for Break/Fix incidents, service requests (Catalog Requests, or I want something), Development (Project) tasks, Minor Work Requests, and Implementation tasks. We concentrate on OLAs as the completion metric, because that is the only component that as a group, we have control over. We don’t control tasks that are assigned to other groups before or after we get it. We also don’t concentrate on individual task performance. Too granular. If we have a KPI for Break/Fix that says, Priority 2 incidents are to be resolved within 4 hours, and our metric of performance is we will have 85% compliance with this standard, then if we have 85 of 100 incidents resolved within the 4 hour target, then we have attained the 85% complaince. We may have to raise the bar at some time to, perhaps 88%, but there has to be an acceptance of mitigating factors, such as available resources, tools available, training, documentation accuracy, etc. At some point you have to accept the fact that, “with the resources we have available, the tools we have, or lack, and the training we can provide, all within budget limitations, this is the best we can do at the current time.” There is no point, and no value in raising the bar, except to ensure that no one can attain the new level, ruin morale, and emphasize that, contrary to our original intent, "yes, we are using KPIs as a club!