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.
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.
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.
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.