Rolly, This is a good topic to explore. I'm glad you started the thread. I'm talking with a company that wants to implement RCM at a new plant. My current industry is fairly new to implementing RCM. My impression is that they want a single RCM engineer to build and maintain the entire program from scratch, with some support from inside groups. Management at my current site thought they could implement RCM the same way. It must be a prevalent impression. I think they must see or hear about a consultant coming in, performing a study and leaving a report and RCM is nearly implemented. I don't know what the misconception is. My experience tells me that most consultant driven programs are never actually implemented, and if they are, only partially; especially if the work gets too hard for a non-RCM group to follow through on. Our current implementation has a good story. The RCM Manager couldn't implement the program alone. After many ups and downs in program credibility, he was able to lobby for headcount. He transitioned internal people from each craft who had RCM tendencies and a desire to learn. The core group has consisted of a CMMS data entry expert, mechanical tech, an instrument tech, an electrical tech, a utility operator and a mechanical engineer. What he set up was a group that was self-supporting and could perform FMEAs, well written job plans from direct experience and other RCM functions with a minimum of bother to the crafts. We were not seen as an outsider group. Still, we receive pokes from the techs as being superfluous. I've found the crafts, by nature, don't like supporting RCM. They're a hands-on group. We've been effective at our sites (we support multiple sites with multiple buildings), but we still have a large amount of work on our plates. Many times our focus is interrupted because of projects that we are admittedly the natural group to support, such as major data transitions to upgraded versions of CMMS software. I consider it part of our job to assure the data is in the best state for continuing operations. Point being that RCM isn't just an implementation; it is a living process that must be improved upon as the process determines. It is labor and data intensive. I am very proud of the program we've been able to install here. I'm proud for my manager to be able to install his vision even with the struggles he faced. I could go into my experiences with free entry work plans, generalized work plans designed multiple equipments, transition to specific work plans to produce more predictable and defendable results, etc.; perhaps later. There are times when a systemic failure of an OEM product used in our process will take a month or better to prove the OEM manufacturer that they have a systemic problem, after doing that, I find myself gathering huge amounts of data to support my argument. And at times, pointing out problems with their designs and working with them on redesign. When supporting our process to resolve a failure of a critical component, one person cannot continue the RCM implementation alone. The implementation appears to be stalled as can be seen from the outside. The entire program gets a bad reputation for not making things happen. And so it goes. I think that's all I want to say. We'll see where the thread goes from here. Jeff
One of the key elements in any maintenance program whatever letters you put on it are the technicians! As a manager you MUST be proud of your techs. If you do not take pride in what they accomplish they will not take pride in what they are doing. As managers we often get caught up in all of the "other stuff" we have to do and leave our techs to do what they do, and if we have given them; training, tools, and a vision of how the plant should be maintained, what they know best how to do. Oh we easily think of them when something goes wrong, but it is essential to make time for each individual tech several times a month for some on-on-one feedback of how they are doing, measured by; metrics, vision, and your personal feelings (pride). There are many folks who write about what motivates people, promise of promotion vs fear of termination, but in my experience most of your techs just want to be techs. Our job as managers is to find what motivates each individual tech; is it that cool new tool, ramrodding the replacment of a troublesome machine that doesn't fit into the cost/benefit analysis, lunch for a job well done... All this builds loyalty which makes it easier to get them to take pride in what they do for you/tenant/company. Just a few ramblings from a guy who moved to corp management from facility manager in '92 and retired in '01.
Rennie, Management in the implementation at our site was a talented individual. He was mostly project and new construction oriented though. He was not seasoned in a maintenance environment. He did bring RCM to the plant after all, and that's a good thing. I don't think he understood how labor intensive and on-going the process is. Not his fault, just a mis-conception. Klaus, I agree totally with your statements. I've been lucky enough to be in an industry that promotes trust and respect in its employees. We used to have a good amount of autonomy and authority to make decisions at the tech level that management stood by. Sadly, as the company grew large with executive staff with visions of growing even larger, the autonomy and authority gave way to meetings and bureaucracy. Alas, that's the way most things go these days. We rely on the techs for real time input for problem codes and work plans that need updated or extended. They have an active voice in the RCM process. The nice thing about having a multi-functional RCM team is that much data, desk work and RCFA reports get done without involving the techs in too much work they don't like doing. J-
Could anyone supply me with an example of a realiability policy. I am meeting with a manufacturing company next week to introduce and encourage the company to implement a reliability policy and take steps to initiate a root cause analysis team. Thank you, Frank Abbott, Ph.D.
Dear All, First there are differences between how TPM and RCM is being implemented, kindly check this link for a comparison about the 2 strategies. Although some difficulties can be shared by the two strategies. I still consider TPM to be the larger part while RCM to be just a slice of the pie that can be exactly be fitted in the later part of the Planned Maintenance pillar of TPM, where an algorithm or decision diagram is required. My Warm Regards,
Dear All, For those embarking on a TPM journey, would like to share my experiences on implementing TPM and its key factors that must not be overlooked.
How to measure performance of TPM? Any KPIs for TPM?
Josh, Different pillars of TPM have different KPI's used example in Planned Maintenance we use MTBF, MTTR, Breakdown Occurence. However, the primary measure for TPM is OEE or Overall Equipment Effectiveness. My Warm Regards,