The word “Leadership” implies change agent(s) regardless of whether Reliability, Lean, Six Sigma, or any other initiative. Change agents aren’t bound to upper management positions but can rise up from any level within the organization. At a recent OpEx conference, Dr. Howard Penrose lamented on how surveys continue to show that 60% of organizations are reactive, a number unchanged for the last 20 years or so. Rather than resting on your laurels and accepting the status quo, what prevents you from initiating change within your span of control?

When we add the word “Reliability”, we add context to imply moving from a potentially reactive to a more proactive reliability centered culture. What does this mean to you and how would you approach it? Would you start with an assessment and then, based on the gaps identified, develop a strategic plan? What about aligning the organization (potentially adding Planners and Schedulers if you have none as an example)? What would you do from an education and training perspective? How would you gain buy-in at the lowest levels to encourage support for the change? What other items would you add?

Cheers,
Jeff

A few days ago, I conducted a webinar on protective devices and hidden failures with ReliabilityWeb.  With webinars of this type, there are often great questions that come up for a response. This webinar was no exception.  I’ll go on to add that I truly appreciate professionals like Terrence O’Hanlon of the ReliabilityWeb organization and Larry Hoing from Wells Dairy for pushing the concepts into real life scenarios and creating conversation outside of the box.  Larry asked if ladder logic and/or controls functions could be hidden potential failures. If so how would you test them? He went on to clarify by asking how we can be proactive and prevent incidents when PLC controls are involved.  Is it in some type of standard for ladder logic writing or is it simply up to the designer of the program?

In the answer, I wanted to frame it with one of the more recent events that was published regarding the use of PLC logic and failures. If you remember, a virus titled “Stuxnet” was specifically designed to attack Siemens PLC and SCADA control systems. It was intentionally designed to infect and destroy Iran’s nuclear program centrifuges. The virus spread from USB drive to USB drive in Asia for months until it infected computers that controlled centrifuges at Natanz, Iran’s main uranium-enrichment facility. The worm stealthily sped up Natanz’s centrifuges to their breaking points, even as it hijacked the facility’s monitoring system to falsely show that the machines were functioning normally. It took the Iranians weeks to figure out what was happening, and the resulting damage supposedly set back the suspected Iranian nuclear-weapons program by years.

In this particular case, the functional failure of the centrifuges was evident to the Operators on its own and not hidden even though some time may have occurred before detecting failure (RCM “question of time”). The protective devices had been maliciously programmed to indicate normal function when in fact, this was not the case. From a RCM2 perspective, with the protective device failures hidden by coding and the resulting functional failure of the centrifuges, we had a “multiple failure”.

To Larry’s question, either inadvertently or maliciously a programmer could create a potential hidden failure using ladder logic or programming techniques. In the example above, the protective devices were programmed to appear to be functioning normally when they were not.  When I was in the role of a Controls Engineer, I have seen a protective device omitted from the logic by accident or deleted in error. This is actually one of the reasons that I used to hard wire safety and environmental protective devices to interrupt the machine function so that I could guard against human error in PLC logic. I would simply use the PLC logic for monitoring the protective device status. This was prior to communication networks like Profibus becoming widespread which changed the approach for many.

As for the remainder of the question, I have become too far removed from the ladder logic and SCADA programming so I’ll put that to you for discussion.  From a programming standard, does the IEC 61131 address the potential for hidden failures? Is there another standard more applicable?  And finally, how would you test to determine the potential for hidden failure from a logic perspective?

Cheers,

Jeff Shiver

I was recently talking with a gentleman regarding his requirements for attending a publicly offered course. During the conversation, the subject of culture change came up and how his organization reacted to change in general. He went on to say that he only had about three feathers in his headdress compared to those in charge who he implied had a higher number of feathers. If we ask them, they may very well disagree but that’s a story for another day.

So, the conversation begs the question of how many feathers are required in the headdress to initiate and sustain culture change. How many do you believe are required? I’ll be the first to agree that true sustained culture change is best lead from the top down by those with lots of feathers in the headdress. However, I’ll go on to say that I also believe that change can start with just one person. You see individuals take those steps every day. Consider the one woman activist who was solely credited with causing the banking giant Bank of America to withdraw the plans for a monthly fee for the use of her debit card. She used the tools she had, the Internet, and a passion to make a difference.

I think that individually we miss many opportunities to influence our peers and others because we believe that we only have a few feathers or are low on the totem pole so to speak. What prevents you from making positive and proactive change within your span of control? What ideas do you have for change that could be implemented within your organization to drive improvement in either Maintenance or Operations activities?

Cheers,
Jeff Shiver

What is the basis for your Preventive and Condition Based Maintenance Tasks?  I recently posted this as a poll question in a webinar and the majority of respondents replied their OEM Equipment Manual.  For years, I have always said the OEM Manual is a great starting point but your operating context may be very different as an example over the averages used by the OEM. Therefore, you should perform a level of analysis depending on the equipment criticality.  The equipment criticality will either lead us to perform a full RCM2 analysis or a simplified Maintenance Task Analysis. This is a much better basis to determine the right maintenance tasks.

After working with different OEM groups across the last several months to include the groups that actually write the manuals and track the warranty information, I’m more convinced than ever about using the OEM Manual as a basic starting point. Here are some facts that may disturb you with regard to reliance on the OEM Manuals.  First off, just like you try to get MTBF information from the OEM, so is the OEM trying to get the same information from their OEMs, often with little success.  Recognize too that the operating context is different from client to client and site to site.  This means there are relatively few samples of component failure within any given operating context for many OEMs. Add to that the clients all have differing levels of Maintenance Best Practices (reactive, emerging proactive, proactive, and world class) as examples.  Depending on the type of equipment, the client user may not track maintenance information in a CMMS or other tool, so no equipment history other than tribal knowledge. Unless it’s a warranty issue, often the OEM gets little or no feedback on failures. Some do track or estimate equipment hours or cycles and send email alerts that a particular time-based service is due.  Very few OEMs install health monitoring on their equipment.  Many have never done an analysis to determine on condition tasks that may be utilized to find components in the act of failure. Therefore, most everything published in the manual as a task is a time-based intrusive overhaul or discard. Intrusive maintenance introduces the opportunity for infant mortality. If you are familiar with how equipment fails, you will recognize this as the most expensive type of maintenance short of “run to failure” or breakdown maintenance.

Cheers,

Jeff Shiver

Ever seen a “defect” tag? I have been familiar with them for years as a product of TPM activities. I was at the SMRP Conference this week and my old friend Doc Palmer shared a self-laminating “defect” tag with me. If not familiar, a “defect” tag is simply a roughly 2.5” x  4” tag with a hole in the top.  A string, tie wrap, or wire is passed through the hole to allow attachment to a piece of equipment.  Generally, the tag has a top sheet and a back sheet with a layer of carbon paper between them.  There is usually a unique number imprinted on the sheets as well. The intent of the tag is to allow an Operations person to identify a defect in the equipment such as a loose air fitting or the location of leaking pipe.  The Operator documents the defect found on the tag, tears off the top sheet which is submitted to Maintenance, and applies the tag as close as possible the identified issue.  In this case, the tag had a self-laminating clear sheet that is used to protect the writing on the tag from water or other damage.

Using this approach allows a process for Operations to identify current or potential issues and report them to Maintenance without actually accessing the CMMS.  Another benefit of the tag concept is that it allows the Maintenance person to quickly identify the location of the trouble since the tag is placed near the defect.

Are you using “defect” tags?  If so, what are your experiences with them?

Cheers, Jeff Shiver

Want to take your organization to the next level? Start with the foundation. Do you have one? I know the answer to this question seems obvious but you would be surprised at how many different groups I keep running into that have never established the proper foundation to build basic metrics from, much less to build a world class organization from.

Get your house in order by establishing the foundation. Items like a solid CMMS built with a functional asset and location hierarchy, failure codes, work types, and so forth. Then, establish and audit the work management system. Next, address the Storeroom and materials management issues. I see some groups where more than 50% of the inventory in the Storeroom is obsolete. Next establish the partnership between Operations and Maintenance. It doesn’t do any good to generate PMs or Condition based Maintenance activities if Operations will not make the equipment available for the inspection or repair. Another item is to get your craft skill levels up. Do you have a training schedule or do toolbox training?

These are just a few of the foundational items that you should be considering? Struggling? Send me an email and I’ll provide a more focused approach for you to concentrate on.

Cheers, Jeff

On occasion, there is value added in looking back in order to move the organization forward from an educational perspective. It seems that many times,we forget the foundational elements that can help us build an effective Maintenance strategy to care for our equipment assets. That said, recognize there are three basic groupings of Maintenance Tasks that you can employ.

They are:

1. Time based Maintenance Tasks
2. On-Condition Tasks
3. Failure finding Tasks

Time based Maintenance tasks are the old standby and one of the more costly forms of maintenance.  These include scheduled discard and scheduled restoration tasks.  Scheduled discard tasks might be changing the oil based on time (where the cost of oil analysis outweighs the benefits) or changing the filters on a duct collector.  These tasks are typically intrusive in nature. The time period can be calculated based on days, hours, cycles, strokes and so on.

On-Condition tasks can be a combination of condition based monitoring using a control system, predictive technologies, or simple visual inspections. Consider a flow meter measuring pump output to show impeller wear or the use of a vibration pen by an operator. These tasks are typically non-intrusive as a rule.

Standby equipment and protective devices require failure finding tasks because the failure is NOT evident to the operator under normal circumstances.  When it comes to protective devices, a large portion of safety devices are never inspected and we don’t know they have failed until it’s too late, hence the need for failure finding tasks. It may surprise you to learn that a tremendous number of “failsafe” devices can fail without your knowledge.

Now, I’ll ask the hard question.  How did you determine which approach to use?

Cheers, Jeff Shiver

I was at a site recently walking down a few jobs with the Maintenance Planners as part of a coaching effort around developing job plans.  Whenever I go out and walk in the site, I generally find something in the act of failing or that has failed.  That trip was no exception.  I looked through a 2″ hole in a guard and found a drive belt that was almost sheared in two.You might ask “Why is it you that finds it, Jeff?” There is a very simple answer.  I’m LOOKING for it.

As a manager, you have to create a preventive failure finding culture.  Teach your people to look up, in guards, and at the equipment for potential failures.  When you stroll through the site, take one or two from your Maintenance staff with you. Point out potential issues to help set the expectation of what they should be looking for.  While it may seem obvious to you, you might be surprised at what you learn when you take a walkabout with them.   How many of you teach your people to inspect on the fly? How many times do you take a walkabout in the plant with them in a month? What are the stumbling blocks?

Cheers, Jeff Shiver

It’s been a great few weeks for me related to Maintenance Planning and Scheduling, not to mention Operational Excellence in general.  In the previous week, I conducted one week of our 4 part series entitled Maintenance and Reliability for Managers.  As part of that course, I covered the A to Z of Maintenance from a benchmarking assessment perspective.  With a number of Operations and Maintenance Managers, it was eye-opening in many areas but especially the Planning and Scheduling side.  The following week, I enjoyed seeing the light bulbs go on in a number of Maintenance Planners as well as Operations and Maintenance Supervisors during an onsite 2 day Maintenance Planning and Scheduling course.  To top it off, I had the opportunity (pleasure is a better word) to follow the 2 day class with a day and a half of actual coaching at the job site. Before we started the class, the organization was like most others with no job plans.  When I left, they had created a number of job plans and had more on the way. I really enjoy when those attending the course share with you how much they learned to drive success within their organization.

I can tell you that education is a powerful tool in building effective partnerships and helping the organization create a positive environment where Planning and Scheduling can succeed, especially with your Operations partners as an example. Courses like these give the different groups an opportunity to gather in a single room, not be distracted by the events in the factory or facility, and focus on what the future can look like together.  Now, that’s powerful.  What prevents you from creating a winning environment in your organization?