The Maximo Manufacturing User’s Group wrapped up their October meeting last week. I’ve been spending the last couple of days wrapping my head around some of the key discussion topics the group had. The biggest one I’ve been thinking about is the effect reactive maintenance has on a crew’s true availability. The general statement made in the discussion was:

You need to recognize that reactive maintenance takes away from the real availability of your crew.[1]

Statements like this are what I call a BFOTO.[2] Think about. Reactive maintenance, by its own definition, are maintenance activities that are being accomplished in reaction to a set of unplanned/unscheduled events.

Two popular definitions of reactive maintenance and reactive work are:

Reactive Maintenance: Maintenance repair work done as an immediate response to failure events normally without planing, always unscheduled. Synonymous with breakdown and emergency maintenance. [3]

Reactive Work: Maintenance work that breaks into the weekly schedule, including emergency work (to correct safety concerns, immediate hazars, etc.) [3]

Part of the dilema most maintenance organizations get into is what gets defined as emergency work.

Emergency Maintence Task: A maintenance task carried out in order to avert an immediate safety or environmental hazard, or to correct a failure. Also emergency repairs or emergency work. [4]

Here’s a more ‘real world’ definition of emergency work:

Emergency Maintence Task: A maintenance task carried out to keep my boss’s butt out of a sling and prevent me from getting yelled at by the Plant Manager. [5]

Taking these definitions aside, almost anyone in Maintenance wants to do the right thing and keep the plant running. So when new requests come into to address an foreseen issue in the plant, and the organization doesn’t have a solid planning/scheduling process in place, jobs like these get done as soon as Maintenance is notified. The problem is reactive work like this is interrupting the scheduled work that was already in place for the week.

Here’s a few examples of the impact I’m talking about:

• A facility has 400 work orders scheduled for the current work week. During the course of the week 100 new requests are made, but only 20 of those requests were acted upon during the current work week. The crew should be considered 5% reactive.
• A facility has 400 work orders scheduled for the current work week. During the course of the week 100 new requests are made and all 100 requests are acted upon. The crew should be considered 25% reactive. [6]
• A facility has 400 work orders scheduled for the current work week. During the course of the week 100 new requests are made and all 100 requests are acted upon. However, because of the 100 new requests were completed, 75 of the originally scheduled jobs didn’t get done. The crew should now be considered 30% reactive.

So how do we measure “reactive maintneance”? The basic equation I’ve been working with is this:

# of WO's created during work week / # of originally scheduled WO's

The general idea is to look at all the work created and acted upon during the current work week over the work that was originally scheduled to be completed that work week. A basic SQL query could look like this: [7]

select ( 
select count(wonum)*1.0 from workorder where siteid = 'BEDFORD' and istask=0 and reportdate > dateadd( week, datediff( week, 0, getdate() ), -2 ) and workorder.targstartdate  >=  dateadd( week, datediff( week, 0, getdate() ), -2 ) and workorder.targstartdate  <  dateadd( week, datediff( week, 0, getdate() ), +5 ) 
) / ( 
select count(wonum) from workorder where siteid = 'BEDFORD' and istask=0 and reportdate < dateadd( week, datediff( week, 0, getdate() ), -2 ) and workorder.targstartdate  >=  dateadd( week, datediff( week, 0, getdate() ), -2 ) and workorder.targstartdate  < dateadd( week, datediff( week, 0, getdate() ), +5 ) 
) as reactivework from dummy_table

There are several key parts for the query to work:

1. The workorder.targstartdate field, or possibly the workorder.schedstartdate field, needs to be actively used in your work order management process. If we aren’t stating when a job will start, we can’t compare it against any other work.
2. The query uses the code dateadd( week, datediff( week, 0, getdate() ), –2 ) to get the first day of the work week. This allows the query to be re-used and not have a fixed date for the beginning of the work week.
3. The query is based on the assumption that a plant’s work is scheduled one week in advance. In the denominator of the query, the query will omit any work order that was reported during the current work week, regardless of when the work is targeted/scheduled to start.

Several other parameters could be added to futher refine the calculation - e.g. exclude any ‘W’ status work orders since they aren’t actively being worked on.

So when we have 20%–30%–40% of the work we accomplished in last 7 days created within those 7 days, we need to recognize that part of our crew’s work time is no longer truly available to be scheduled for work because one of two things: the work won’t get done (missed) or the work gets deferred (rescheduled).

In either case we didn’t get done what we needed to get done.

Got any questions? Feel free to hit me up on Twitter at @MyGeekDaddy.