KPI Logic for MTTR and MTBF

[former_member675056]

Hello Gurus,

Below are the KPIs of MTTR and MTBF. The columns are as follows: Formula given by my business, Input, Custom Table, Logic given by PM consultant (Me). I just want to know whether the logic is correct or not. Also the unit of measure they want to get is in "DAYS". My technical person is still confusing after I gave the logic also. Please help me out. You can enter the given table also for reference. He wants that how he can get Available time, breakdown time and no. of breakdowns.

Thank you.

MTBF (Available time - Breakdown Time ) / No of breakdown Shift Date ZTPM_DETENTION Custom 1. Pass Shift date (SHIFT_DATE) in ZTPM_DETENTION where DCODE=007* & DETENTION_MIN <> 0.
2. For any PLANT (Plant) & ZSEC (Section) combination, calculate time elapse between two consecutive entries and get arithmetic mean value of all entries in given period (START_DATE: START_TIME of second entry) - (END_DATE: END_TIME of First entry). MTTR Breakdown mints / no. of breakdown Shift Date ZTPM_DETENTION Custom Access table ZTPM_DETENTION.
1. Pass Shift date (SHIFT_DATE) in ZTPM_DETENTION and pick detention code- DCODE=007* & DETENTION_MIN <> 0.
2. Get DETENTION_MIN for each Section- ZSEC for all SHIFT. Display Sum of all Detention_min as MTTR for that section for that day.
3. Detention codes under 007* category are 007A, 007B, 007C.

[peter_atkin]

Useful info: https://blogs.sap.com/2014/07/21/equipment-availability-vs-reliability/

.

PeteA

[pardhreddyc]

Hi,

I have not got clarity about your custom tables that you specified, as I do not see the fields of those tables.

Before you get into logic, you have to understand the length of the downtime that your client would input at the Notification level when we talk about MTTR/MTBF and MTTF.

As you said, your client wants to have the UOM as "Day", you may use custom logic to convert the hours in "Day". Are you considering total stoppage time or only the actual stoppage of the technical object excluding isolation/restoration time etc...?

I can say, it will vary from business to business to capture the length of the B/D at the notification level...if your client is very effective in dealing with RCM concept, you have to understand the length of the breakdown time that is being captured. The reason why I am emphasizing is, when the main equipment is stopped due to sub equipment malfunction, we can not consider that as a malfunction for the main equipment. However, we can record the stoppage as a delay for production also we can use system availability information...If we have standby sub equipment, we might change over to stand by equipment during the failure of the sub equipment. In these situations, we can not update break downtime as total stoppage time...

We have to consider the below information too, to attain your requirement.

This information will provide the availability of your technical object before and after a malfunction.

I would suggest you use a custom screen at notification level so that you can update your own logic in custom fields whenever user input the values in "Malfunction data"/ "System Availability" you can convert the parameters as per your business requirement during the closure of the Notification and can be populated in your custom fields...this way it helps your client to track the notification lead to downtime and also could help them to understand the availability of system before and after B/D...

If you go with your own custom table data as per the current set up... I request you to consider below key points to calculate your MTTR/MTBF/MTTF...

• First/last start of malfunction that month
• Number of breakdowns recorded
• Time Between Repair
• Number of actual breakdowns
• Mean Time Between Repair
• Total downtime that month
• Mean Time To Repair that month

Note: Kindly ensure the startup date of the technical object, as we may dismantle and re-install in required F/L... we have to be careful when we put custom logic to consider actual operational time (hours/days) of the equipment in specific F/L. Because standby equipment may have different operational times...This will help to evaluate the technical object malfunction with respect to each position/location, etc...

If you get the time and help from your technical team, you can go through the information structure S070 for better clarity.

you may also refer below information for your logic :

MTTR: Total Maintenance Time/Total Number of Repairs

MTBF: Total Operational Time/Total Number of failures

Note:

You may have to understand the maintenance strategy on operational time for the standby equipment as it may be running once in a while.

MTTF: Total Hours of Operation/Total Number of Units.

Note: MTTF is a basic measure of reliability and it mainly emphasizes the length of the time that an object expected to last in operation until it fails...This mainly concentrates on similar kinds of technical objects "Mean Time to Failure".

Regards,

Pardha Reddy.C

[AB]

Good morning,

I'm assuming MTBF denotes mean time between failures. The word failure often creates some confusion - MTBF is commonly measures "uptime" - periods between failures.

To calculate mean time between failures, you need to track timepoints when failures were resolved and when failures started. The time distance between the resolution and commencement of a failure is the period of time between failure events - uptime.

The sum of all the periods of time between failure events divided by the number of failure events will provide you a mean time between failures in the period of time you are considering for evaluation.

                          
 UP  ------>|            |--------------->|          |------------->|
           failed        up             failed      up             failed
 DOWN       |===========>|                |=========>|              |===>

 Time =>    0 --------- 10 ------------- 20 -------- 25 ---------- 50 ---- 

In the above example we have two complete periods of operation, 10 units from 10 to 20 and 25 units from 25 to 50. So here we have 35 units of uptime (between failures) and two failure cycles leading to 35 / 2 => 17.5 units to time between failure.

To make life more complicated, some organisations need to consider not just the binary state of downtime versus uptime - but also consider when the component or system needed to be operational. If a component or system failure is resolved, but uptime doesn't start, then end sum of downtime durations <> sum of uptimes.

As for your calculations, since I don't have any knowledge of your customer specific Z table design, I cannot definitively confirm your pseudo-code. I trust you can use the explanation above with your knowledge of your Z table design to reach a level of confidence.