Preventive Maintenance Scheduling:
Understanding the Equipment/Task Relationship
By Peter Binkley of
Solid Blue Development
When you find yourself responsible for managing the maintenance tasks for many pieces of equipment spread throughout a building or campus,
the assignment can seem a difficult prospect at first. While it may seem appropriate to simply enter all the equipment into a database and
create a new task for each piece of equipment, you may quickly realize you’ve built a behemoth of a system that requires an increasing number
of hours each week to manage.
In my years of experience designing scheduling software for preventive maintenance and similar processes, I usually find it helpful to rely
on a paradigm I’ve evolved to make ease of managing the system a top priority, yet is flexible enough to handle virtually any task or piece of
“equipment” the system may be asked to handle.
Not only can this system be used for traditionally PM-heavy environments like physical plants at universities, hospitals, and corporate
campuses, but I’ve seen it work in environments where labor is performed for what wouldn’t normally be considered “preventive maintenance.”
It’s been used by pool cleaning services to maintain a schedule for cleaning clients’ pools and spas; a university used it to keep track of
their commitment to shampoo the carpets or strip and wax all the hard-surfaced floors on campus annually, with each floor of each building
treated as a separate piece of “equipment;” it’s even been used by farmers for performing pesticide and weed-killing tasks.
The system requires some effort and thought to set up initially, but the payoff in the long-term is well worth it. The primary prerequisite
is a person – we’ll call him or her the “PM Manager” for the purpose of this series of articles – who is responsible for devoting the necessary
time and thought into setting the system up and really understanding how PM works in their particular organization.
Equipment Classes
To start, we need to understand the concept of equipment classes. Classes of equipment are nothing more than a name we assign to a group of
individual pieces of equipment for which common tasks must be performed regularly. For instance, an air handler would need to be checked for
proper air flow, filter changes, and other things that all of our air handlers must be inspected for. Therefore, “Air Handlers” would make a
good equipment class.
Determining the scope of equipment classes is important, as we’ll see, to be sure they cover all of the basic tasks but don’t include tasks
which might be required for only one or two pieces of equipment. For example, if you’ve got a number of golf carts, mostly electric but a
handful that run on gasoline, the task “Change Fuel Filter” would not apply to the electric carts. Therefore, two classes might be more
appropriate: one for electric carts and one for gas.
Tasks
Note that equipment classes don’t apply to any particular piece of equipment, but rather to an abstract concept of “equipment-ness” for
which common tasks need to be performed. Similarly, “tasks” in this system are best understood as general units of work that might be applied
to several equipment classes or to individual pieces of equipment. For instance, if a task called “Check Power” is created to make sure a unit
has sufficient electric power, that task might be applied to everything from lights to vehicles to air conditioners.
Once tasks are defined they are assigned to equipment classes. When classes are then assigned to individual pieces of equipment, a bundle
of tasks then come with them. At this point, an “instance” of each task/equipment combination is created and stored in a database. The actual
work performed by mechanics thus corresponds no longer with abstract concepts, but to these very real “instances” of work.
Flexibility
At this point you may think we’re developing a system that, far from being flexible, is actually quite rigid and difficult to change.
However, if we look closely, we can see just how many possibilities this system allows for.
Because individual pieces of equipment aren’t tied to a “list of tasks” but rather to individual instances of these tasks, we can fine-tune
the tasks for the oddball pieces of equipment that don’t fit the model. Say you have an aging emergency shower with a leaky O-ring. You know the
ring is broken and you intend to replace the shower head when your budget permits, so you no longer want mechanics waste time checking this shower
for leaks. In a traditional system, you would need to disassociate the shower from the class “Emergency Showers” and create a new, pared-down class
or leave it floating free of any class whatsoever. With the “instance” system, however, all you need to do is suspend the task for that piece of equipment.
Similarly, since there is tremendous flexibility in the way you define classes and tasks, you can get as detailed as you want in defining classes.
In one case, a university had purchased so many air conditioners of different models and from differing manufacturers over the years that they had
over two dozen classes for air conditioners! Most of the classes had the majority of their tasks in common – meaning they all used one generic
abstraction of that task – but each class had one or two tasks that pertained only to air conditioners of that particular model and manufacturer.
They had even assigned detailed instructions for these tasks that were printed out on the list of PM tasks carried by each mechanic as they went
about their week’s duties.
Finally, it should be noted how easy it is to make wide-ranging changes to an existing database in a system like the one I describe. The
university mentioned above experienced a budget shortage that required them to leave vacant mechanic positions as their employees quit or retired.
As a result, some of the tasks that were performed on a regular basis could no longer be performed as frequently, which caused them to fall behind
on their PM.
The solution was very simple. Because the tasks were prioritized, the PM Manager was able to adjust the frequency for less important tasks
to have them performed at a longer interval. For instance, low-priority tasks that had been performed on a three-month basis had their cycle
frequency changed to six months across the board. Even though hundreds of pieces of equipment were affected, the change took only a few minutes
because the system had been designed to allow for a global change. When the cycle was changed on the task “concept,” all of the task “instances”
were changed. The system even flagged instances which already had been assigned a custom frequency, allowing the PM Manager to make decisions on
those pieces of equipment individually.
In future articles, we will look at a number of topics related to this particular task/equipment paradigm and how it has been successfully used
by a variety of organizations.
|