All Member Open Forum

Hi Ahmed, thank you for sharing the diagram.

Beyond the visual representation, the key point is the purpose of MTTR and the system property being evaluated.

The diagram explicitly separates the "Get maintenance technician on site" phase from diagnosis and repair activities. If the intention were to include response or travel time within MTTR, the logical starting point would have been something like "call to maintenance." This separation clearly suggests that organizational response time is distinguished from technical repair time.

From a maintainability and inherent availability (Ai) perspective, MTTR starts when the technician arrives on site and ends when the asset is restored, in line with SMRP Best Practices and the classical maintainability approach.

For this reason, it is clearer to:

• Define MTTR from technician arrival to restoration,

• Measure travel and response times as separate indicators, and

• Use complementary metrics when the objective is to represent total downtime or service performance.

Looking forward to other perspectives.

Hi Luis,

I think I got your point, and I am sharing same concern with you.

MTTR must reflect just repair activities (starts from arriving to the equipment to end of repair), as other time (like travel time) is already included in MDT (mean down time), so traveling could be traced in another KPI.

and current MTTR is also includes time to travel to stores to get any required spares (which not typically an inherent maintainability factor).

I reviewed Ramesh Gulati's maintenance and reliability best practices book, and found that he only takes actual repair time into consideration

"MTTR is the average time to repair assets. It is pure repair time (called by some wrench time)." Maintenance and Reliability Best Practices

So, I think we have three distinct terms that need more clarification from SMRP

Wrench time (I think no confusion with it - only actual work is considered).

MTTR (what to include in the metric and what to exclude).

MDT (I think no confusion with it - All downtimes are considered).

Thanks Luis for escalating this point, I think we need some clarification about it.

Best Regards

Ahmed

Hi Ahmed, thank you for sharing the diagram.

Beyond the visual representation, the key point is the purpose of MTTR and the system property being evaluated.

The diagram explicitly separates the "Get maintenance technician on site" phase from diagnosis and repair activities. If the intention were to include response or travel time within MTTR, the logical starting point would have been something like "call to maintenance." This separation clearly suggests that organizational response time is distinguished from technical repair time.

From a maintainability and inherent availability (Ai) perspective, MTTR starts when the technician arrives on site and ends when the asset is restored, in line with SMRP Best Practices and the classical maintainability approach.

For this reason, it is clearer to:

• Define MTTR from technician arrival to restoration,

• Measure travel and response times as separate indicators, and

• Use complementary metrics when the objective is to represent total downtime or service performance.

Looking forward to other perspectives.

Hi Luis,

I think I got your point, and I am sharing same concern with you.

MTTR must reflect just repair activities (starts from arriving to the equipment to end of repair), as other time (like travel time) is already included in MDT (mean down time), so traveling could be traced in another KPI.

and current MTTR is also includes time to travel to stores to get any required spares (which not typically an inherent maintainability factor).

I reviewed Ramesh Gulati's maintenance and reliability best practices book, and found that he only takes actual repair time into consideration

"MTTR is the average time to repair assets. It is pure repair time (called by some wrench time)." Maintenance and Reliability Best Practices

So, I think we have three distinct terms that need more clarification from SMRP

Wrench time (I think no confusion with it - only actual work is considered).

MTTR (what to include in the metric and what to exclude).

MDT (I think no confusion with it - All downtimes are considered).

Thanks Luis for escalating this point, I think we need some clarification about it.

Best Regards

Ahmed

Hi Ahmed, thank you for sharing the diagram.

Beyond the visual representation, the key point is the purpose of MTTR and the system property being evaluated.

The diagram explicitly separates the "Get maintenance technician on site" phase from diagnosis and repair activities. If the intention were to include response or travel time within MTTR, the logical starting point would have been something like "call to maintenance." This separation clearly suggests that organizational response time is distinguished from technical repair time.

From a maintainability and inherent availability (Ai) perspective, MTTR starts when the technician arrives on site and ends when the asset is restored, in line with SMRP Best Practices and the classical maintainability approach.

For this reason, it is clearer to:

• Define MTTR from technician arrival to restoration,

• Measure travel and response times as separate indicators, and

• Use complementary metrics when the objective is to represent total downtime or service performance.

Looking forward to other perspectives.

Hi Ahmed and Luis, 

MTTR already include the travel time of the technician based page 83. If this excluded and only consider upon arrival of technician at site, it would be close to tool time or wrench time. 

Any this is any interesting discussion to establish our fundamentals for the MDT, MTTR, and Tool Time. Any comments?

Hi Luis,

I think I got your point, and I am sharing same concern with you.

MTTR must reflect just repair activities (starts from arriving to the equipment to end of repair), as other time (like travel time) is already included in MDT (mean down time), so traveling could be traced in another KPI.

and current MTTR is also includes time to travel to stores to get any required spares (which not typically an inherent maintainability factor).

I reviewed Ramesh Gulati's maintenance and reliability best practices book, and found that he only takes actual repair time into consideration

"MTTR is the average time to repair assets. It is pure repair time (called by some wrench time)." Maintenance and Reliability Best Practices

So, I think we have three distinct terms that need more clarification from SMRP

Wrench time (I think no confusion with it - only actual work is considered).

MTTR (what to include in the metric and what to exclude).

MDT (I think no confusion with it - All downtimes are considered).

Thanks Luis for escalating this point, I think we need some clarification about it.

Best Regards

Ahmed

Hi Ahmed, thank you for sharing the diagram.

Beyond the visual representation, the key point is the purpose of MTTR and the system property being evaluated.

The diagram explicitly separates the "Get maintenance technician on site" phase from diagnosis and repair activities. If the intention were to include response or travel time within MTTR, the logical starting point would have been something like "call to maintenance." This separation clearly suggests that organizational response time is distinguished from technical repair time.

From a maintainability and inherent availability (Ai) perspective, MTTR starts when the technician arrives on site and ends when the asset is restored, in line with SMRP Best Practices and the classical maintainability approach.

For this reason, it is clearer to:

• Define MTTR from technician arrival to restoration,

• Measure travel and response times as separate indicators, and

• Use complementary metrics when the objective is to represent total downtime or service performance.

Looking forward to other perspectives.

Hello Sir,

As the MTTR is a indicator, we need to consider the whole time, because we need to improve it where it's take more time, elimine the bottlenecks or reduce it. Also from time to time the professional can e requested while being in different parts of the industry, so the time travel will be different.

Also the production will consider the whole time, so you'll have two numbers.
Our role here is to analyze and improve, so we need to  open up the number and understand why the MTTR is high, for example:

A MTTR of 10 hours:

10% of travel;
40% of maintenance;
10% of filling out the report e
40% waiting the parts in the storage.

Hello Allisson,

I think you have highlighted a good point and it is indeed the core of our job to analyze and get insights. However, having a solid definition is crucial in my opinion, so you have the same standard across industry and professionals which will enable benchmarking in more consistent way.

imagine I am talking about MTTR as a wrench time, and you are talking it as MDT, it think it will cause a little bit confusion. I think also, a world acknowledged institution like SMRP must has a sharp definitions.

Best regards

Ahmed

Hello Sir,

As the MTTR is a indicator, we need to consider the whole time, because we need to improve it where it's take more time, elimine the bottlenecks or reduce it. Also from time to time the professional can e requested while being in different parts of the industry, so the time travel will be different.

Also the production will consider the whole time, so you'll have two numbers.
Our role here is to analyze and improve, so we need to  open up the number and understand why the MTTR is high, for example:

A MTTR of 10 hours:

10% of travel;
40% of maintenance;
10% of filling out the report e
40% waiting the parts in the storage.

Sir Mohamed,

Indeed! To define MTTR we'll consider the wrench time, but the downtime need to be considered the amount of time, because we can identify the bottlenecks and improve it.

Once I had a problem with a ECU module that we didn't have it in stock, because of that we ordered the module from the OEM and took (more or less) 15 days to be in our hands. After that, the module was replaced in less than one hour. After this event, we started a study to define the minimum of the ECU module to cover all 30 harvesters that we had, based in reliability, time to restocking, and cost.

Hello Allisson,

I think you have highlighted a good point and it is indeed the core of our job to analyze and get insights. However, having a solid definition is crucial in my opinion, so you have the same standard across industry and professionals which will enable benchmarking in more consistent way.

imagine I am talking about MTTR as a wrench time, and you are talking it as MDT, it think it will cause a little bit confusion. I think also, a world acknowledged institution like SMRP must has a sharp definitions.

Best regards

Ahmed

Hello Sir,

As the MTTR is a indicator, we need to consider the whole time, because we need to improve it where it's take more time, elimine the bottlenecks or reduce it. Also from time to time the professional can e requested while being in different parts of the industry, so the time travel will be different.

Also the production will consider the whole time, so you'll have two numbers.
Our role here is to analyze and improve, so we need to  open up the number and understand why the MTTR is high, for example:

A MTTR of 10 hours:

10% of travel;
40% of maintenance;
10% of filling out the report e
40% waiting the parts in the storage.