Maintenance Software Information
Please let me introduce myself, most of you know me as Mac Smith, but you may also recognize me as Anthony M. Smith, author of the McGraw Hill book titled Reliability-Centered Maintenance. I've been in the RCM business now for some 16 years, and over that time have had the privilege of working with hundreds of craft personnel and maintenance professionals from a host of Fortune 500 companies, as well as NASA and DOD.
The purpose of this column is to share with you some of my experiences and views on RCM and maintenance issues, and to receive your comments or questions that may be of interest to the maintenance community. In future columns, I intend to comment on topics such as the 80/20 rule, classical vs. streamlined RCM, failure mode and failure cause confusions, hidden vs. evident failure, the difference between failure finding and run-to-failure, selecting PM intervals and other such topics. I'd like to hear from you on topics that should be considered for future columns.
Implementing an RCM Program
When we speak of "implementing" RCM, we generally think of this as three separate activites - all three being necessary to achieve a successful RCM Program:
- Developing the recommended RCM-based Preventive Maintenance (PM) tasks (the 7-Step Systems Analysis process described in Ref. 1).
- Carrying those RCM-based PM tasks to the floor - i.e., doing them (Step 8 in the process).
- Conducting the Living RCM Program to measure results and effectiveness of the Step 8 actions, and to adjust and fine tune as necessary (Step 9 in the process).
This article is devoted to some thoughts about #2 above - sometimes referred to as Task Packaging - and some brief discussions on my actual experiences that span 18 years and some 35 clients who wrestled with a variety of problems in this area.
First, let me say that I found (much to my surprise at first) that successfully initiating and completing #1 above (the 7-Step Systems Analysis process) was done with very little, if any, difficulty. The problems, however, with #2 and #3 above were extremely difficult, and sometimes catastrophic (i.e., nothing was ever down after a successful completion of #1). These problems varied from client to client, but there are a handful of topics that are representative of the main thrust of problems and troubles that I have seen. They include the following:
- Buy In - Nothing new is ever successfully introduced into an operating plant, facility or factory unless the people who are charged with the responsibility to do it are 100% behind it. This is a truism, no matter how good it is - and RCM is no exception. Now we have obviously obtained some degree of acceptance of RCM simply by the successful completion of the Systems Analysis process on a couple of complex plant systems. But this acceptance (buy in) is very narrow, and, as a result, we often move on to Task Packaging without first obtaining a broader degree of ownership and buy in from the plant supervisor and craft personnel. Without that broader acceptance, it is very likely that any attempt to carry the RCM PM tasks to the floor just won’t make it. So, a carefully planned program of indoctrination and education must precede any attempt to actually do the RCM PM tasks, and the broadest possible inclusion of plant personnel in the Systems Analysis process itself should occur in order to systematically develop buy in and ownership with the workforce.
- Equipment-Oriented Mindset - In a typical plant or factory, we commonly find that the "movers and shakers" among the O&M craft and supervision personnel are very skilled and dedicated people who have spent many years of daily hands-on activities with the equipment. In fact, their career is focused on assuring that the equipment is always operating or available to operate if called upon. In other words, we could paraphrase their job focus as equipment preservation. All well and good - except RCM takes a rather different view of what their job focus should be - namely, to assure that the critical plant functions are always available when required. This we paraphrase as function preservation. This shift from equipment to function preservation emphasis frequently becomes a difficult concept to sell, yet it is the basis upon which all of the RCM-based PM tasks depend. Again, the importance of training and a broad base of buy in to the RCM concept is necessary. The plant personnel need to have some grasp of the conceptual logic behind RCM, or they will not be ready and willing to change their old (and comfortable) ways of doing business.
- New Tasks/New Technologies - Human beings resist change. We are comfortable with the status quo. Over the years, in comparing the content of existing PM programs versus a recommended RCM-based PM program, changes in the range of 40% to 80% occur. Clearly, plant staff personnel must have some appreciation of where changes of this magnitude come from and why they are very beneficial to do. That is what the two bullet items above address. But beyond that, other resistance factors enter the picture. The RCM program will always introduce new PM tasks that have never been done previously (note - it will also always delete existing, non-value added tasks). These new PM tasks will require new Work Orders, often complete new procedures and perhaps also new tools and craft skills. In a large number of cases, RCM will introduce predictive maintenance technology, PdM, into the program which always requires some degree of new tools and craft skills. So the shift to the new RCM program is not just a buy in and function-oriented mindset; it is also a commitment to some degree fo time and money to make it happen. Thus, various levels of management approval could be involved. And most certainly, a dedicated attitude among the craft personnel together with efficient resource planning is a must if successful implementation is to occur.
- Computerized Maintenance Management Systems (CMMS) - Today, every plant or factory has some kind of CMMS. (If not, we recommend that you get started). Many of the larger and more complex plants and factories, in fact, have invested heavily in a sophisticated CMMS that has a wide range of useful bells and whistles. The problem here is that, in my experience, virtually no one effectively uses the CMMS capability that is available to them. One particular area of deficiency from an RCM point of view is the absence of any meaningful or useful equipment history file. In my experiences, I have rarely seen an equipment history file that was useful beyond the simplest of data such as date of failure and date of return to service (the "it failed and was fixed" story). If you are going to have a successful RCM program, you must have a credible equipment history file that consistently and accurately gives you access, at a minimum, to two pieces of data:
- for each maintenance event, some reasonable record of what was done and what was the "as found" condition; also for a corrective maintenance event, what was the failure mode, failure cause and specific corrective action taken
- the ability to record, as a function of time, parameters that are being measured (either manually or automatically) for PdM purposes with a capability to automatically provide an alert signal when a preselected parameter threshold is reached. These two data items are necessary in order to make task interval adjustments and to accurately monitor the PdM tasks respectively. Without this very minimum CMMS capability, you will continually struggle to achieve the potential benefit of the RCM program, and most likely will never realize it and end up blaming it on RCM - not your ineffective use of the CMMS.
In closing, let me suggest that the best way to solve the above four problem areas is to recognize their existence, and as a part of your overall commitment and plan to undertake an RCM program, decide upfront how you will address these issues. If you wait until they are upon you, chances are that you may never proceed to place your RCM-based PM tasks on the floor where they belong.