Since then, RCM has been introduced to a broad spectrum of plants and facilities across the U.S., and via the 80/20 rule continues to be recognized today as the best available process for defining applicable and effective PM tasks to control/decrease corrective maintenance and downtime in complex "bad actor" systems.
RCM Team Analysis at Greater Cincinnati Metropolitan Sewer District (MSD)
Anyone who has successfully used RCM to define their PM tasks knows two things: 1) It takes some effort to do it (no free lunch!), and 2) It works. At AMS, we exclusively use Classical RCM (i.e. like the original 747-100 process) for our client's 80/20 systems, and it continues to be the basis for our success over the past 30 years.
With that said, every so often someone proffers a so-called magic bullet to easily establish a plant maintenance program without taxing company resources. Who wouldn't want that? Deep down we know this doesn't exist, but that doesn't stop us from flirting with the notion. One such idea that is floated now and then is PM templating. The basic premise behind PM templating is that systems are all comprised of common equipment, just in different combinations and uses, so why not borrow a standardized library of PM tasks common to that equipment and skip the analytical process? It sure is tempting.
Unfortunately, such simplistic notions fail in real world application. While a portion of template tasks may work for some assets (even a broken clock is accurate twice a day), a significant portion of the PMs will be far removed from the actual operating conditions of a plant. More importantly, however, a significant number of tailored PM tasks, those that are specific only to the unique interplay of components within the assembled system, will be missed, with possibly drastic results.
The practitioners of PM templating promote their process as a better substitute for the well-known Reliability Centered Maintenance (RCM)
process. The RCM process is a proven methodology used worldwide with a successful track record for over 40 years in a variety of industrial applications (see Reference 1, Chapter 12, for seven such examples). It is the recognized standard for world class maintenance plans for any asset. PM templating practitioners state that RCM is too labor intensive for practical purposes, and that PM templating frequently consumes only 15% of the time traditionally employed for RCM. Over the years, we have seen these "quick fix" claims (such as Streamlined RCM; see Reference 1, pp. 171 to 174) and have observed how they quickly fall out of favor with those who try them. So just what is wrong with PM templating?
Criticality
A tolerable failure for one component in a system (for example, internal leakage of a valve) may be entirely intolerable for an identical valve in a different application. Hence, the maintenance strategy for those identical valves should be different as well. The proper maintenance for an asset can only be prescribed once its criticality within the system is understood; in other words, its ability to degrade system or plant performance. Equipment failures that do not harm the system or plant (due to redundancies, excess capacity, etc.) should not be the focus of your maintenance resources. You simply cannot ascertain a component's criticality without a sound cause-and-effect analysis between the asset, its failure modes, and the higher-level business requirements. If you do not thoroughly document the functions and possible functional failures of the system, and associate a component's failure modes with those functional failures within the discussion of an effects and consequences analysis at three levels (local, system, and plant), you will misdiagnose the criticality of the asset. Moreover, if you do not engage the actual process participants, those who live with the results of failure on a daily basis, you will misdiagnose the criticality. That has been proven repeatedly in practice, and intuitively we all know that.
System Monitoring Conditions
A comprehensive world-class preventive maintenance program is far more than a compilation of generic PM tasks. There are always system and/or plant design parameters that must be monitored and controlled to ensure the correct operating conditions. These parameters are not found in a PM template catalog or library that contains only component-level data. They are unique to your system! For instance, If one didn't specifically document that their air dryer system requires an output dew point of -28 °F to avoid moisture buildup with potential for freezing and then plant shutdown, one is unlikely to recommend a PM task to develop a dew point trend report to capture dew point data that will be visible on screen in real time to operators. One also would be unlikely to impress upon a newly hired equipment operator the necessity and value of this recommended task. This is a real-life example that did in fact occur, resulting in lost product opportunitin the multi-hundred thousand dollar range. MESSAGE: You can not neglect to account for system or plant interactions in specifying the correct component PM tasks.
Equipment Operating Environment
The environmental conditions imposed upon a component exert a considerable influence on the maintenance strategy. Even within like industries, the stresses encountered by one asset may be entirely different from the stresses encountered by an identical component in another application. Duty cycles, wear-out rates, and dominant modes of failure will all differ. Selection of PM task frequency will likewise differ. Some process industries require their assets to operate non-stop for years at a time, while others may operate only periodically. Such differences affect the types and frequencies of PM tasks one should prescribe among like equipment. For example, would you prescribe the same PM tasks on a valve that is used every day, versus an emergency isolation valve that is generally never operated? What if that valve is 5000 feet below the ocean's surface? Questions like these get to the heart of the HIDDEN FAILURE issue and how unrealistic it is to consider the ability to identify hidden plant failures from component template data.
Organizational Culture
The preventive maintenance that works at one organization is not always the best fit for another organization. Every company and every facility has its own unique culture, with established routines and protocol for maintaining equipment, based on years of experience and refinement. Those practices may be entirely situational and not suitable for exportation to others. Should one prescribe sophisticated PdM technology or the use of handheld mobile recorders for data capture? Companies may not be ready to embrace such technologies, or the ROI may not be justified. Each company has maintenance and operational personnel with various strengths and weaknesses. RCM involves those personnel, gives them a voice, and seeks to leverage their strengths. PM templating may not take this into account because it basically bypasses the team concept in the PM decision process.
Maintenance Plan Ownership
As facilitators for over 100 RCM projects, we have reports documenting thousands of equipment failure modes and PM tasks, and we bring this experience to each RCM team that we serve. From this experience, we could also painstakingly compile a library of tasks from our archives to apply to generic components, but we don't, and we won't. The reason is this: if you are looking for magic, that magic does not exist in a library of generic data (aka templates); it exists only when you gather a team of the equipment stakeholders in a room and develop a reliability strategy together in a structured format.
The team method isn't unique to RCM. This is the same concept used in Lean, Kaizan, TPM, Process Re-engineering, and so on. You must engage the process participants (the maintenance crafts people, the equipment operators, and the process and reliability engineers) for the cross-pollination of information, -and only in that manner will you achieve BUY-IN and obtain superior results. We believe that a Ptemplate approach will only discourage and disengage a team. It won't be theirs, and they will tune out. Worse yet, the template data will invariably miss very critical information that will lead to incorrect decision making. At the end of the day, a team-derived RCM plan has BUY-IN at all necessary levels for implementation.
Training, Education, and Corporate Knowledge
The dividends of an RCM project far exceed the development of a maintenance plan. As is often the case, those who conduct RCM are encouraging a cultural change to move from a reactive to a proactive culture. This can only be done in the context of training and education. That is one purpose of establishing an RCM Team and RCM Champion. Moreover, as one records and rationalizes the business case for establishing a preventive maintenance task, one is in fact capturing valuable corporate knowledge that will be preserved for future training, education, and decision making. As one of our client RCM teammates said at the end-of-project brief to upper management: "It would take a person 3 years or more to learn and become proficient in understanding the possible failures and effects associated with the system that the team documented."
Analysis Level of Effort
RCM was introduced to the nuclear power industry in the early 1980s by Tom Matteson (retired VP of United Airlines and creator of RCM) and Mac Smith, and rapidly moved into fossil plants, large manufacturing plants, and government test facilities in the late 1980s and 1990s. To date, AMS has supported/facilitated some 100 Classical RCM projects with over 75 Fortune 500 companies. In the beginning, a typical project would take 5 to 6 weeks to complete and was recorded by hand without the assistance of software. When it was obvious that there was no RCM software worth its salt on the market, in the late 1980s AMS initiated the development of the Classical RCM WorkSaver software in a collaborative effort with JMS Software. Today, that software has supported over 50 RCM projects and has been purchased/used by over 100 clients.
The point to this story is that the conduct of Classical RCM projects has matured to the point that AMS now conducts a standard RCM project in 3 to 4 weeks, including a 3-day up-front team training and a 1-day end-of-project briefing to client management and staff personnel. Our experience for the past 20 years has been that clients consistently find that the ROI from these projects on 80/20 systems is well worth the short span of effort required. These projects have taken place in several product areas (e.g., waste water treatment, refineries, airplane production, aerospace test facilities, postal automation, diesel engine assembly, etc.). Some sample statistics are shown below for 5 recent projects, all of which involved 80/20 "bad actor" systems, an RCM team for the complete analysis process, documented results, and, finally, implementation. Each project involved a unique plant with different functions and would have, in our opinion, been a complete failure using PM templates as the basis for the PM results.
Notice that each project varied in the number of components involved and failure modes analyzed. This suggests that system complexity is unique from plant to plant. Also note the large number of hidden failure modes and critical failure modes that were specifically identified. This is just a sampling of the AMS experience; Reference 1, Chapter 12 presents seven case studies that can be reviewed for more details.
A survey by Reliabilityweb.com found that 50% of all RCM projects are not implemented for one reason or another. That figure should not be surprising. 50% of all business startups fail. 50% of all marriages fail. However, our experience with Classical RCM has been that implementation is in the 70% range. Those who are truly serious about obtaining reliability results make it work.
Conclusion
When we talk about how to focus resources, which are usually rather scarce these days, we need to first decide what is really important to us. That just makes common sense and should not be a controversial topic. As indicated in the above paragraphs, AMS has successfully employed the 80/20 rule for three decades to answer that question. Now if you know which systems (20%) are eating your lunch (80% of your grief), then does it not also make sense to do the best possible job in deciding how to eliminate that grief. We have presented seven arguments above to help you to understand that PM templates are NOT the way to address these important 80/20 systems.
Only the Classical RCM methodology has the ability to take a top-down, zero-based approach to maintenance analysis, which starts at defining the necessary performance attributes that an organization requires from its assets (functions) and drills down through a decision methodology to ensure there are technically feasible and worthwhile maintenance tasks in place to prevent interruption of those vital requirements. To date, AMS Associates has supported/facilitated some 100 Classical RCM projects with over 75 Fortune 500 companies. Each project was a unique plant with different functions, and would have, in our opinion, been a complete failure using PM templates as the decision process to address such an important issue.
Reference 1: "RCM - Gateway to World Class Maintenance," Anthony M. Smith and Glenn R. Hinchcliffe, Elsevier 2004.
Anthony "Mac" Smith has over 50 years of engineering experience, including 24 years with General Electric in aerospace, jet engines, and nuclear power. Mac is internationally recognized for his pioneering efforts in introducing RCM to U.S. industry in the early 1980s. Since then, he has worked with some 75 Fortune 500 companies, the USPS, NASA, and the USAF, among others. He has personally facilitated over 75 RCM studies and has authored/co-authored two books on RCM that have become the standard references for Classical RCM. www.jmssoft.com
Tim Allen joined Mac in 2005 after a 20-year career with the US Navy's Submarine Maintenance Engineering Planning and Procurement Activity (SUBMEPP). During his tenure, Tim was one of the principals in developing the submarine group's RCM process and rose to the level of RCM Program Manager. His efforts helped lead the Navy away from expensive time-based overhauls of equipment to more surgical condition-based strategies. www.jmssoft.com
