Friday, January 23, 2015

5 Thoughts That Can Drive Success with Reliability Centered Maintenance and Equipment Maintenance Plans

1.   You can not do RCM on every asset or all at once. Break it down into manageable chunks of your asset list based on risk to the business. Create a plan. Consider a tiered process for building maintenance strategies based on asset criticality. 
One example might be:
  • Top critical asset use Full blown RCM Analysis
  • Upper mid criticality assets use Failure Modes Effects Analysis (FMEA) or its simplified version SFMEA to identify failure modes based on operating context
  • Middle to lower criticality use failure mode libraries or database tools
2.    Once you understand your common failure modes from RCM or FMEA, focus on mapping the Predictive Maintenance (PdM) technologies currently deployed at your site to the failure modes exhibited. This will reduce the number of Preventive maintenance (PM) task required and the total cost of the asset management plan. PdM normally takes less time, does not induce failures, and allows for the equipment to be running as opposed to invasive PM activities which require equipment shutdowns and can induce infant mortality.

3.    Schedule a standing meeting to tackle one RCM or section of an RCM or FMEA per week per group. It should be on your maintenance schedule and be as sacred to those scheduled to attend as your PM work. Create a project plan based the number of teams, the process you are using and the number of resource hours you have based on the weekly meetings.

4.   In all but your most safety, environmental, and production critical assets, the plans developed don't have to be perfect. Get them close and use continuous improvement techniques to refine the RCM and the asset management plan over time. This will allow you to implementing sooner and generating results faster. It also removes you from the world of analysis paralysis.
5. Stay focused and stay the course. It takes time. Reward your teams success. Support them and remove barriers to their sucess. 
I wish you luck as you tackle RCM and lower your risk and cost!

Thursday, October 30, 2014

Software Got You Stuck? Do Not Let RCA Applications Hold Up Your Root Cause Efforts

Let us be clear, root cause analysis is a way of thinking not a software application yet their are sites that are spending thousands of dollars and hundreds of hours learning software instead of solving problems. Software is not inherently bad but you don't need a sports car to learn to drive.
If you are getting started with your RCA efforts and software is part of your plan then be aware of these potential problems:
Software can limit team involvement: Facilitator is head down in the computer rather than up truly facilitating responses from the team.
Software can slow the flow of ideas especially if it is slow to create or move causes and links: time required to create or edit means other are waiting and forgetting points and causes.
Software can complicate reporting: The simplest and most effective reporting for most sites is the A3 style RCA report which will be the topic of the next blog post.
Computers create barriers between facilitators and the RCA team. If you have to collect the information directly to the software then you should consider a facilitator and a recorder or scribe.
If you can problem solve without the software or by capturing the information after the analysis then here are a few tips and benefits of a software free RCA.
Use sticky notes and a big blank wall or a white board. (3M's Super Sticky PostIt Notes work well)
This allows good group involvement by allowing them to write and share or verbally share and you capture the causes.This gives you two streams of causes in two different communication styles. If two people share the same or similar cause than you stack them and both participants know they were heard. This can be key to good facilitation.
With sticky notes you can start by understanding the sequence of events and include any time stamped data from PLCs, cameras etc. and then once you identify key event, or forcing functions as they are sometimes known, you can transition to fault and logic tree with ease. This will provide a better understanding of the systemic and latent causes of the key event.
With the very hands nature of the sticky method you can move and reorganize causal chains quickly and as you discover new causes they can be added with ease and with out huge disruptions to the flow of ideas. When you are done you simply take a quick picture of the analysis via the ubiquitous cell phone and paste this into your chosen report format.  These can then be shared with others electronically.
The point of today's post is not that software is bad. It is simply that it is not required to get started and make substantial improvements in your facility. Many of our student save hundreds of thousands of dollars for their sites using nothing more than the sticky notes and a sound root cause methodology. Once root cause becomes part of your business culture then you can capture, catalog, and share more effectively with the help of software but don't let it hold you back from the start.

Wednesday, October 15, 2014

Two Things Engineers Consistently Get Wrong

As I think back over the years of site assessments, reliability implementation, and coaching of facilities and engineers globally there are two concepts that consistently show up as weak areas with engineers in manufacturing environments.
The first is true in-depth "root causes" problem solving (this is different than the "engineers jumping to conclusions process" that many employ) and the second is relying on technical solutions rather than culture change to solve problems. They both go hand in hand but are only completed at a precursory level by many.
Let's first look at "root causes" problem solving. (There are more post on this topic here) I have put the quotation marks around it to say that I don't believe that all problems need to be addressed at lowest root causes levels but the problem should be understood to that level so that the engineer truly comprehends the systemic and latent roots or drivers of the problem. These base roots many time rest in the culture of the facility and must be known to truly lower risk of reoccurrence. Secondly there is never just one root cause as there are multiple things that must have existed and instantaneously happen to allow unwanted events to occur hence the "s" on causes. This is why five why and fish bones, which are great for creating a culture of problem solving, are not the tools of serious engineering problem solving. You need to be able to see all of the causal factors that came together to create the event and determine all the possible ways the problem could be addressed to insure a solution is selected that lowers the risk of re-occurrence, creates the best business case, and is sustainable in the long term. Many times engineers go after technical solutions like redesign when the best business case is in changing the culture or behaviors that led to the event.
This brings us to the cultural change piece that is so often ignored as an option. We as engineers are trained to think about technical solutions and therefor many times ignore the people or cultural solutions. Some examples of these technical solutions are replacing a lubricated bearing with a sealed bearing to prevent lubrication based failures or changing adjustable components to fixed designs to prevent operator set up issues. These may be good solutions at the micro level but when the problem is macro and you have 100s of assets and components with these issues and the cost to implement can increase significantly. In these cases educating the work force on lubrication practices and set up requirements, and the included systems and processes can be lower total cost solutions. Behavior change is hard and can take much time and focus but the quantity of defects that can be eliminated or prevented is extensive. So as an example if a bearing failed due to over lubrication and we replace it with a sealed bearing and remove the fitting, a very technical solution, we have eliminated that one failure point but if we tackle lubrication and and the cultural issue of precision maintenance as a whole we can correct lubrication issues more broadly and solve many thousands of over lubrication issues across the facility. We can still bring in technical solutions like UE Systems Grease Caddy to help ease the cultural change process but now we are focusing on causes that lie lower in the casual chain and more greatly reducing risk to the facility as a whole.
So in conclusion, if you are thinking about your personal development plan or that of your engineers you may want to consider developing a strong problem solving methodology that looks both deep into the problem and broadly into the contributing factors. It should have business case thinking weaved through out. It also needs a solid process for execution and follow up. It does not have to be complicated but you will need to provide the training required and ensure that your engineers can execute. And, they must consider the behavior or cultural change solutions with the technical solutions to the problems your facility faces. This will have substantial returns on your effort if you stay the course. Reach out to me if you want to hear the success stories others are having in this area.
shon@reliabilitynow.com

Tuesday, September 16, 2014

Introducing our New Sustaining Skills Video Series: Having fun with education and delivering a return on your training dollar

Having Fun with Education!
 Boring is Not Better!
You can laugh about Reliability!


Click here to learn more about this on demand training offering on the Eruditio website and see the full demo

If you like education that is relevant, innovative, and available when you need it...

Leave behind education that does not fit your culture and get a customized solution for your sites