Root Cause Analysis Blog

How important is the SnapCharT(R) in the Equifactor(R) process? The TapRooT(R) system teaches that the first step is developing a good SnapCharT(R), and then gathering more detailed information from there.

But what happens when you develop your SnapCharT(R), analyze your failure, find a lot of information about the failure, but you don’t know where to put it in the SnapCharT(R)? Let me give you an example.

A reciprocating compressor has failed, with a very high vibration in evidence. Your troubleshooting has exhausted the “easy” stuff from your Equifactor(R) analysis (speed incorrect, lubrication system inadequate), and you have now been forced into a teardown of the compressor. Upon inspection, you find:
- heavily fractured piston
- a loose piston rod nut
- metal fragments in the cylinder valves
- water condensed on cylinder surfaces
Now, where do you put these items on the SnapCharT(R)? TapRooT(R) teaches that we normally construct a SnapCharT(R) in the order of occurence; that is, insert the information in the spot in the SnapCharT(R) at the time at which it occurred. However, in this case, when did these new datapoints occur? Did a slug of water enter the cylinder and cause the problems? Did the connecting rod nut become loose due to the failure, or did the loose nut cause the failure? These pieces of data should go in the SnapCharT(R) in the order that they occurred, but in this case, when did these events occur?

A solution to this problem requires several steps.
1. If at all possible, eliminate one of the possible causes by further analysis. In this example, if there is a dehydrator just prior to the inlet, verify it is working properly and is not saturated. If it appears to be working correctly, the water probably did not enter the cylinder here. It may have condensed after opening the cylinder, especially if the cylnder is activley cooled.
2. For what is left (in this case, loose nut or failed piston), you may be forced to just leave these conditions after the incident on the SnapCharT(R). This is not a cardinal sin. In fact, it is much worse to force a condition before the incident by guessing and put it in the wrong place. You now have conclusions being drawn on incorrect information. For example, if you say the nut came loose first and force it before the incident, you have effectively made this the cause of the piston failure when in reality it may not have been.
3. For whatever is left, analyze the most likely causes of these conditions. For example, what could cause the piston to fail, assuming the connecting rod nut was not loose? Is the compressor being operated above its rated capacity? In fact, in this scenario, you would find that the cylinders have been re-bored to increase throughput by 25% above vendor spec. Would we have found this if we had assumed the nut had come loose first?

In general, your SnapCharT(R) should be developed in order of occurence. However, especially with equipment problems, this may be difficult to accomplish. Don’t force your SnapCharT(R) just to be more asthetically correct, if this will introduce errors into your analysis.
This type of problem can also be seen in incidents involving drug testing (when was the drug ingested?) or autopsies.

Recently, there has been some debate as to the priority of conducting a root cause failure analysis of equipment failures, as compared to implementing a Reliability Centered Maintenance program. Which one gives you the most bang for the buck? If you only have money and resources to do one of the two, which one should you choose?

First of all, I don’t believe you can completely separate an RCM system from an RCFA system. One of the cornerstones of the RCM process is determining what PM’s can be modified or disposed of by analyzing what your past equipment performance indicates is required. However, this approach requires that the past failures conform to an analysis which can assume that the equipment is operating as it is designed. Unfortunately, most failures (over 80% by most conservative estimates) are not due to end of life, equipment design criteria, but due to “unknown” or “random” failures. In terms of the RCM process, these definitions may fit, but in reality, they are only unknown or random because we haven’t conducted an effective RCFA to determine what caused the failure.

Opposing this, however, is the need to determine what needs an RCFA conducted. If an asset does not have the right maintenance program (and most maintenance programs do not meet the minimum standard required by RCM), the result is a significant number of failures caused by the wrong or no preventive maintenance. This mass of failures tends to mask those that are real defects or human error. Remember, a significant portion of the failures are a direct result of the preventive maintenance you are performing in the first place.

So what do you do? As an overview:

1. One of the first things to do is quickly rationalize and review your PM program to get rid of most of the “poor maintenance practice” failures. Shoot for getting you PM program up to snuff as quickly as you can.

2. This will now allow you to focus on RCFA when the human-related defects are more visible. Again, these failures can account for a significant number of your failures.
** As a side note, it seems to be assumed by many experts that an RCFA is not used to determine problems or issues with the maintenance process itself. However, this is exactly where the RCFA process can be used to determine what caused the failure, whether it was due to improper machinery operation (human error) or an unnecessary PM (ALSO human error!)**

3. Once this is done, you can again shift back to a reasonable analysis of your PM system and implement a workable RCM strategy that is based on inherent equipment reliability and its relationship to preventive maintenance. Otherwise, your RCM system will end up being based on human-error failures rather than equipment-related design or PM failures.

Give these steps a try if you are trying to figure out where to start your RCM implementation. Remember, defect elimination or RCA work accounts for twice the business benefit of implementing improved maintenance strategies by themselves.

This may be hard to believe, but the 2007 TapRooT(R) Summit planning is almost complete! Mark has put together an awesome program, with 10 tracks guaranteed to appeal to everyone. The Equipment Reliability and Maintenance Best Practices Track in particular is looking better than ever. We’ve got some great topics:

- How “Minor” Mechanical Failures Lead to Major Accidents
- 7-Step Troubleshooting Method for Electronic Troubleshooting
- Developing and Adding Custom Tables to Equifactor(R)
- Equipment Reliability Best Practices
- Lessons From the Crime Scene - Evidence Preservation for Accident Investigation
- Proactive Use of Equifactor(R) to Improve Equipment Reliability

I’d like you take special note of the Equipment Reliability Best Practices topic. I’d like to use your examples of how you have used Equifactor(R) to improve the reliability and operability of your equipment. How much time and effort have you saved using Equifactor(R) to quickly and efficiently troubleshoot your expensive machinery? Let me know if you are interested in presenting your company’s experiences during the Summit. This is a great opportunity to “pat yourself on the back,” while at the same time helping others with their problems.

I recently attended a maintenance reliability conference in Knoxville (MARCON 2006) sponsored by the University of Tennessee’s Maintenance Reliability Center. I was struck by a common theme that came up over and over during the 3 days of the conference. Maintenance managers seem to be at odds with some of their more senior management concerning program implementation. You KNOW that the root cause analysis process you are trying to implement is the right way to go. You KNOW that the proactive analysis techniques you have recently learned will help both your maintenance department and your company. You KNOW that Equifactor(R) will significantly reduce your equipment troubleshooting time and MTTR. Then why is there so much resistance to these changes from your senior management?

In reality, it is usually our fault. We have not been very good at recognizing what our managers are focussed on. Remember, they have an obligation to the shareholders, and in most cases, those obligations revolve around PROFIT. So that is what WE must focus on when presenting our ideas to management. Your presentations should include how your changes will affect the bottom line. Some suggested ways to do this:

1. Calculate your return on investment. For equipment reliability improvements, this has historically been at least a 6:1 benefit ratio.
2. Show them how much production you are losing because of unscheduled equipment down-time. Include overtime calculations, production line start-up time, replacement parts cost, and waste generated during start-up.
3. Show how much more production can result from more efficient equipment operation. This unit per hour calculation addes up quickly.

These techniques must result in an actual dollar amount. This will quickly grab the attention of the manager who is responsible for approving your new ideas for using Equifactor(R) as part of your troubleshooting toolbox.

I’m in Gothenburg, Sweden teaching a 3-Day TapRooT(R)/Equifactor(R) Equipment Troubleshooting and Root Cause Failure Analysis Course that is co-sponsored by SKF. More than half of the students in the course are SKF manufacturing, customer service, and application design engineers - a really smart bunch of people. It’s day 2 of a 3 day course.

It really is humbling teaching root cause analysis to people who know so much about bearings and equipment. But as usual, the TapRooT(R) System helps even experts do better root cause analysis.

The TapRooT(R) System “expands the universe” of potential ideas for correcting serious problems by giving experts additional ideas of potential root causes. And I see this happen in all kinds of industries all around the world.

I think that’s why it is such a good job being a TapRooT(R) Instructor. TapRooT(R) comes through in every case to help experienced and inexperienced investigators find root causes that the previously would have overlooked.

Another strength of the TapRooT(R) System that comes across in this course is the ability to analyze the causes of equipment problems that are causes by human performance of the operators, installers, or maintainers. Often machinery experts know an amazing amount about the engineering of the machine. But they really appreciate the root cause analysis assistance they get analyzing human performance problems.

Tomorrow they get the Equifactor(R) part of the class and I really look forward to the “lightbubs turning on” as they realize how advanced root cause analysis and advanced equipment troubleshooting fit together.

Maybe this is a use of Equifactor(R) that you’ve never thought of before…

You have been assigned to a team that has been tasked with installing a new air compressor that will be used as part of a new manufacturing process. Your specific job is to determine what preventive and predictive maintenance activities you will require for the new compressor. Where do you get this type of information?

You can start with the manufacturer’s recommendations, but we all know this is a pretty coarse set of guidelines. Wouldn’t it be nice if you knew how the compressor could possibly fail before it was installed? You could then design your PM and PdM requirements to look for these failure pathways.

As a TapRooT(R) user, you remember that Equifactor(R) is normally used to troubleshoot specific equipment failures and aid in your root cause analysis. But what if we use Equifactor(R) to list ALL POSSIBLE equipment faults, and then design our monitoring systems to look for these faults? In fact, you decide you can use Equifactor(R) to:
1. Determine what vibration monitoring is required to look for the listed symptoms
2. List what preventive maintenance may be required to prevent the failures from occurring
3. Update the operating procedures to keep the equipment operating conditions away from common failure modes
4. Design an operator training program to teach your people to look for specific incipient failure conditions
5. Include the gear in your company’s lube oil analysis program
6. Conduct an RCM analysis to see what maintenance is really required, based on known Equifactor(R) failure modes

and you are just getting warmed up!

It is tough to set up your CBM system to try to minimize your maintenance workload if you don’t know what maintenance is required in the first place. Take a look at how you would normally set up these types of programs for new equipment, and see how Equifactor(R) can be used as yet one more tool to make your life easier.

Attached (click on the continuation link below) is a report from an aviation failure on a small plane (not a jet).

This is another example of a small mechanical failure (a generator failure) that could have led to a larger failure (loss of the plane and loss of life of the crew and passengers).

What is the lesson I think you should learn?

That equipment reliability is a key part of system performance and SAFETY.

Safety professionals should help maintenance and equipment reliability folks find the root causes of equipment problems by using TapRooT(R). That’s why safety folks (in addition to equipment reliability and maintenance professionals) should attend Equifactor(R) Training.

For general Equifactor(R) information see:

http://www.equifactor.com/

For 3-Day TapRooT(R)/Equifactor Equipment Troubleshooting and Root Cause Failure Analysis Training see:

http://www.taproot.com/courses.php?d=3

(more…)

It’s been a while, but I have published a new addition of our Equifactor(R) newsletter. It is designed for anyone interested in keeping up-to-date on equipment maintenance, machinery reliability, equipment troubleshooting, or root cause analysis issues. This issue covered Equifactor(R) and TapRooT(R) software enhancements, Equifactor(R) course updates, and information from the 2006 TapRooT(R) Summit.
If you did not receive a copy of the newsletter, email me here. I’ll add you to the list.
You can download this issue here.

SKF has joined with System Improvements to sponsor equipment reliability related root cause analysis training in Europe. The second course sponsored by SKF is being held at SKF’s Headquarters in Gothenburg, Sweden.

SKF has many equipment experts (among them the worlds leading experts in bearing failure analysis). So why would they team with System Improvements and TapRooT(R) to offer an advanced root cause analysis course?

Because bearing failures are often caused by causal factors that aren’t equipment related. These failures may be due to human error and sometimes even deeper root causes can be found in management systems. TapRooT(R) helps SKF’s consultants and clients find these root causes and thereby improve equipment reliability and plant performance.

For details of how TapRooT(R) and Equifactor(R) can help you improve equipment reliability, call Ken Reed at 865-539-2139 or e-mail him by using the “Contact Us” button above. Or see the Equifactor(R) Web Site.

And consider attending the course in Gothenburg. For more info see:

http://www.taproot.com/courses.php?d=83&l=1

(Talk about equipment reliability … SKF is one of the sponsors of the Sweden to China & Back trip of the Swedish Ship Gotheborg. For more info on the journey that started in October of 2005 see: http://www.skf.com/portal/skf/home/about?contentId=243438&lang=en )

Ken is out today at the MARTS maintenance conference. He gave a talk yesterday.

Here is a maintenance thought for the day …. does your maintenance crew resemble the picture below?

Things you probably don’t see today:

1) Straw hardhats.

2) Smoking while working on the oil rig.

3) Six guys working a job (they have been downsized to three but to make up for the loss of numbers, they must weigh twice as much).

During the Summit, many users were interested in finding out what custom tables other users have added. As more people discover the power of Equifactor(R), more ideas for custom tables come up. When you develop a custom table for a piece of equipment, let me know! I’d like to share your experiences with other users. In addition, after a careful peer review, these custom tables can be added to our software during the next revision. We can do this for any table that has wide-spread use across multiple industries.

Have you found unique symptoms (and remedies) for some of our already-established tables? Let me know. We can incorporate those experiences, too.

As I told attendees, I will be posting the Summit papers on the blog when the authors pass them along to me.

Here is a paper about Equipment Reliability & Root Cause Analysis by Brian Murray of SKF. (PowerPoint format)

Reliability and Integrity Management 1-1.ppt

Just left Brian’s session after an excellent talk on maintenance management and root cause analysis.

For me, the statistics on failure - especially the “caused” failure by maintenance activities - was an eye opener.

Seems that we would be better off just keeping our hands off stuff.

That is where condition monitoring comes into a maintenance strategy.

For Brian’s slides, click on the attached PowerPoint below.

Reliability and Integrity Management 1.ppt

Next is lunch and then another set of breakouts - I’m attending the Investigations & Corrective Action Program Best Practices session.

More reports later.

Thanks

Mark

We have just activated the Equifactor.com website! Please go on over and take a look. We are still making changes to it, so if you have any ideas please let me know. http://www.equifactor.com

Equifactor(R) has some pretty powerful troubleshooting tables built into the software. It started with the vast petrochemical experience of Heinz Bloch, and has rapidly progressed to new tables targeted at a wide range of industries. But what do you do if there is no table that fits you particular equipment?

Custom Troubleshooting Tables are the answer. These tables allow you to develop new tools in 2 ways. First, you can capture that “tribal knowledge” that has been floating around out there in your maintenance department. Get that expert experience written down before it is lost or forgotten.

Secondly, it is a great way to document troubleshooting efforts of new equipment as you go. When a piece of equipment breaks down, and you finally discover the root cause of that unique failure, put it in a table. You can include the symptoms of the problem, all the possible causes you investigated, and the actual cause of that particular failure. Document how you fixed the issue, including digital pictures of the failed component, allowing future technicians to see what you saw.

It is surprisingly easy to develop a new table. While in the main TapRooT(R) Incident Manager window, select System Configuration at the top, and select Equifactor(R) Maintenance. Then start adding your custom tables. Go ahead and play around with it; you can’t accidentally delete the original Equifactor(R) tables, so add and delete new tables for practice.

We often find that many customers would like to see new troubleshooting tables incorporated into the Equifactor(R) module, but never think to ask. What would YOU like to see? We can usually incorporate new table requests into the next software update. We learned in January from one of our mining customers that they would have a use for Conveyor Belt troubleshooting assistance. I had not thought of that myself, but we have incorporated this new table into our latest TapRooT(R) software revision (v4.0.6).

What do you need? Now’s your chance get your requests in before our next software release!

GoodCatch.pps

Click on the PowerPoint above. It is a good example of a near-miss that was prevented by observant people and luck.

But after reviewing the slides, what else could you learn from this incident?

Is there more to learn than two guys had a good catch?

Give me your ideas below (click on comment) and after the Summit (April 5-8) I’ll add mine.

Many times, we start troubleshooting our broken gear before we really know where to start. This risks losing, altering, or destroying important clues as to why the equipment failed. The @ptitudexchange, an information clearinghouse for SKF, has published a paper I wrote on Evidence Gathering for Equipment Troubleshooting. Check out the paper on their website at the link above (free registration on their website required), or take a look here.

Version 4.0.6 update to the TapRooT(R) software has been released, and registered users can download it here. This update makes a few minor upgrades to the TapRooT(R) software, but it also made some significant changes to the Equifactor(R) module:

1. Added a “conveyor belt” troubleshooting table as requested by our mining industry customers in January.
2. Changed the front page of the Troubleshooting Chart. We have deleted the Failure Classification box, since the
TapRooT(R) Root Cause Tree(R) already takes care of this.
3. All the definitions in the front of the hardcopy Troubleshooting Tables book have been incorporated into the software. All these definitions can now be accessed by simply right-clicking on a term and selecting the Equifactor(R) Reference.
4. Other minor administrative changes have been made to individual tables.

If you have any other suggestions, please don’t hesitate to drop me an email. I’ll be happy to work these into future updates.

Industry today is facing a quandry. As the baby-boomers start to reach retirement age, many companies are facing the very real problem of loss of subject matter experts (SME). How many of you will lose those “salty dogs” at retirement age in the next couple of years? What are you going to do when that one guy who you always call to fix your compressor is no longer available?

I remember we had a specialty set of high-speed reduction gears that required special modifications. There was only one man in the entire country who had ever worked on this particular set of gears, so we had to specially contract him to perform the work. I’m sure THAT was cheap!!

How do you capture that special equipment knowledge from your SME before he goes out the door? For equipment issues, Equifactor(R) can help. Have that expert capture his unique troubleshooting expertise in a Custom Equifactor(R) table. He can make up a list of symptoms he has seen, what the possible causes have been, and how he conducted the repairs. You can attach pictures of your specific equipment to these tables, so you can actually see what a particular failure looks like. Now, when your guru leaves, you have captured his tribal knowledge into troubleshooting tables that your less experienced people can use.

Hi, all. I found a site with an amazing array of data concerning everything you’d ever want to know when it comes to compressors. Check out this site:
Compressor Info4U Everything Compressor, from 12v Air Compressor to Tire Air Compressor.

Recently, some questions have arisen concerning how much maintenance should be expected from equipment operators. One recent comment really raised my eyebrows. It was estimated that nearly 50% of the manufacturing and 60% of the mobile mining maintenance is being performed by the operators, not the maintenance techs! This seemed to be a little hard to believe. After all, we are paying our operators to operate the gear, and we are paying a completely different bunch of folks to repair the equipment. If these figures are true, what gives?

Probably, the reason these figures are so out of the expected range is that the preventive and corrective maintenance plans in place at these particular plants are not up to par. If the operators feel they must be the ones conducting repairs and maintenance, it must be that they believe that there is no one else to do it. It also means that the equipment is probably broken so often that they must assist in the repairs of their gear if they ever expect to operate it. Our operators are now focussing over half of their time on issues not related to equipment operation.

Take a look at how your maintenance programs are divided. If you find that your “operators” are “maintainers”, it might be time to re-evaluate your division of labor, along with the effectiveness of your preventive and corrective maintenance programs.

We’ve had a change of plans on the Equipment Reliability & Maintenance Best Practices Session.

Jeff Hammons from Parsons will not be able to present so we have been lucky to get an excellent talk that will be VERY interesting.

Ken Turnbull, TapRooT(R) Instructor and retired Safety Manager for Texaco, will present a talk on the fire at the Giant Refinery.

Why will this be interesting to those interested in equipment reliability and maintenance?

Because this accident was initiated by an equipment reliability problem.

Ken will show how Hienz Block’s Troubleshooting Tables (part of the TapRooT(R) Software) could have been used PROACTIVELY to prevent this accident.

Link to Case Study by CSB of Giant Refinery Fire:



http://www.csb.gov/metatraffic2/track.asp?mtr=http://www.csb.gov/completed_investigations/docs/Final%20Giant%20Case%20Study.pdf

We’ve been putting a lot of effort into updating our Equifactor(R) course and software to keep up with current events. After several months of work, we have completed the final revision to the course. Updates include:

1. New examples, taken directly from industry reports
2. Techniques to make complex investigations more manageable
3. New troubleshooting tables, as requested by YOU!
4. An update to the Equifactor(R) Troubleshooting Chart, more closely linking the use of Equifactor(R) with the rest of the TapRooT(R) system

In addition, a new software update is about to be released. It adds definitions for the various Failure Modes and Failure Agents directly into the Equifactor(R) Reference, allowing one-click access to the definitions. If you have the software, you no longer need the Tables Book to find these definitions. It also incorporates numerous updates to existing troubleshooting tables, and several completely new tables requested by our mining customers. This software release is imminent, and it is the last planned update before the new web-based interface is released with TapRooT(R) version 5.

Upcoming Equifactor(R) classes are all using the new course format. The next several courses are:

Brussels, Belgium March 15-17 (Sign up NOW to reserve a seat!)
Gatlinburg, TN April 3-4 (Just before the TapRooT(R) Summit)
Calgary, Alberta, Canada April 25-27
Houston, TX May 3-5
Gothenburg, Sweden May 3-5

The Brussels and the Gothenburg courses are being jointly sponsored by System Improvements and our international partner SKF. Their @ptitudeXchange website contains a wealth of information for maintenance and reliability professionals.

One of the biggest factors in worker job satisfaction is work planning. Few things will de-motivate your maintenance techs than having poor job planning. This results in having the wrong tools at the jobsite, multiple trips to the parts crib, and hours of rework for a failed fix.

We often work hard to carefully plan and schedule our preventative maintenance requirements. We prioritize the job, research prior jobs, list the job steps, conduct hazard analyses, and then list parts and tools required. Before we send our techs out, we make sure the proper permissions are obtained and the process can be stopped for the maintenance. All these steps ensure that we are not wasting our people’s time.

Corrective maintenance requirements should be no different. When a conveyor belt stalls, we should to be able to do the same thing. Unfortunately, we are usually in a reactive maintenance environment, with a huge push to get production back on line. What can we do to limit the down-time, yet minimize the re-work and wasted maintenance time?

Let Equifactor(R) give you a hand. When that conveyor belt goes down, conduct a quick Equifactor(R) analysis of the failure. What caused this failure? Before your techs get to the jobsite and modify critical evidence, give them an idea about what they need to be looking for. Should they plan on removing the drive motor? Could the idlers need adjustment? By having these answers in hand prior to arrival, your techs know what tools to bring, what safety hazards may be present, and what parts they are likely to need. This will also prevent their inadvertent modification of important evidence as to the reason for the failure.

Don’t send your maintenance personnel in blind for corrective maintenance. We wouldn’t do it for a preventative maintenance item; why treat this type of job any different?

Question 1: Is this an accident or an “on-purpose”?

Question 2: Will this truck have future equipment reliability problems?

Lesson Learned:

If your root cause analysis tools don’t help you look at equipment problems caused by human performance, you are probably missing a MAJORITY of the root causes.

That is why TapRooT(R) and Equifactor(R) are such a powerful combination.

Equifactor(R) - the best equipment troubleshooting tools from Heinz Bloch.

TapRooT(R) - the best human performance troubleshooting and root cause analysis system from System Improvements.

If you want to find the real root causes of equipment failures, then the 3-Day TapRooT(R)/Equifactor(R) Course is the root cause failure analysis course that you must attend.

Here’s a list of upcoming TapRooT(R)/Equifactor(R) Courses:

2-Day TapRooT(R)/Equifactor(R) Equipment Troubleshooting & Root Cause Analysis Course

April 3-4 Gatlinburg, Tennessee

3-Day TapRooT(R)/Equifactor Equipment Troubleshooting & Root Cause Failure Analysis Course



March 15-17 Brussels, Belgium

May 3-5 Houston, Texas

Often, equipment failures are considered just that - a failure of equipment to perform as expected or designed. When you install a new air compressor, you expect it to perform the maintenance required by the manufacturer, operate it as described in the manual, and conduct overhauls at the required periodicity.

In return, you expect that compressor to perform as designed: it should put out the designed pressure at the required flow rate for a specified number of years. This should not be too much to ask. So what happens when the 4th stage rings blow by after only a few months of operation? Most companies will attribute this to poor workmanship, replace the rings, and continue operating.

After several of these failures, they may decide they need better performance monitoring. They install vibration monitoring gear, and now they can fix the problem before it actually fails. But have they figured out why the rings are failing? Or have they just accepted the substandard performance of this quirky machine?

With Equifactor(R), we can finally get out of this trap. By finding the real root cause of the failure, we can break the cycle of operate-fail-repair-operate. In the majority of cases, we will find that hidden factors (wrong parts ordered? improper installation? wrong lubricant?) are the real causes of the failures. Your gear will only operate as well as you let it. With proper care and feeding, your equipment will operate as designed.

Sign up for an Equifactor(R) course, and see how Equifactor(R) combined with the power of the TapRooT(R) RCA system will solve your equipment reliability headaches.

– Brussels , Belgium March 5 - March 17

– Gatlinburg, TN (pre-Summit) April 3 - April 4

– Calgary, Alberta, Canada April 25 - April 27

– Houston, TX May 3 - May 5

– Gothenburg, Sweden May 3 - May 5

A discussion today with a TapRooT(R) user mentioned that Equifactor(R) would make a great tool for proactive identification of equipment failure modes. The thought went like this:
A new pump is being installed in your facility. An analysis has been performed to make sure all the predictive and preventative maintenance requirements have been delineated. But have we verified all the support and anciliary systems for the new pump are up to the task? One way to find out would be to use Equifactor(R) to determine the possible failure modes anticipated for the new equipment. By analyzing how the pump could fail, we can anticipate these failure modes and correct them before we even install the pump! How’s that for predictive maintenance! My thanks to Bob Novak of Valspar for this great tip.

SKF and System Improvements have teamed up to bring TapRooT® and Equifactor® to SKF’s clients and manufacturing facilities in Europe.

The start of this alliance is a course in Brussels, Belgium, on March 15-17, and a second course in Gothenburg, Sweden, on May 3-5.

If you are in Europe, or if you have facilities in Europe, look at your calendar, decide which course fits your schedule best, and then sign up using this web site!



The course fee of $1890 US Dollars includes the TapRooT® Book, ($195) Heinz Bloch’s book Machinery Failure Analysis and Troubleshooting, ($120) the Root Cause Tree® Dictionary, and a fully functional Single User Edition of the TapRooT® Software ($1495). WOW! What a value.

The Single User Edition of the TapRooT® Software includes a computerized version of Heinz Block’s famous Machinery Troubleshooting Tables.

This course is a must attend for:

- Maintenance Managers,

- Equipment Reliability Engineers,

- Expert Craftsmen, or

- anyone who needs a professional troubleshooting approach.

Even if you think you know everything there is to know about your equipment and all it’s failure modes, we guarantee we can teach you something new about the human performance factors behind most equipment failures.

Click here to learn more about the TapRooT®/Equifactor® Training.

Conducting equipment troubleshooting requires great care to avoid destroying sensitive evidence. Just the act of dis-assembling the equipment for troubleshooting can cause some evidence as to the cause of the failure to be lost, modified, or destroyed. And yet, you need to know what failed in order to start troubleshooting. It’s as if you need to know the cause of the failure before you can even start looking for the cause!

Unless you are omniscient, there are few options available to you. Fortunately, one of those options is the Equifactor(R) Equipment Troubleshooting module of the TapRooT(R) software. By looking at the symptoms of the failure, you can use Heinz Bloch’s wealth of experience to easily narrow down your possible causes for the failure.

With this information in hand, you can now start looking for the right clues as you begin disassembly, allowing you to collect the necessary evidence to eliminate the last few possible cases. Even those expensive repeat failures suddenly become manageable. Omniscience? Well, not quite. But with the data you gain from an Equifactor(R) analysis, it almost feels like you know the answer before you even begin!

Hi! My name is Ken Reed, and I’ll be here periodically keeping you updated on news concerning Equifactor(R). Any questions or comments, don’t hesitate to get in touch with me.

How have you used Equifactor(R) lately? I’m interested in hearing more about how you have used the power of Equifactor(R) to get to the bottom of your equipment failures.

Oscar Barajas, a TapRooT(R) User in Columbia, has a web site with maintenance and equipment reliability tips.

To see it go to http://www.oscarbarajas.com.

Hurricane Rita won’t stop our courses coming up in Lake Charles, Louisiana.

Both courses are scheduled for the Isle of Capri Hotel and Casino - which just reopened today.

The hotel informs us that damage to their facilities is minimal and the course facilities are in great shape.

So if you would like to attend the:

2-Day TapRooT(R) Incident Investigation & Root Cause Analysis Course on February 8-9

OR the

3-Day TapRooT(R)/Equifactor(R) Equipment Troubleshooting & Root Cause Analysis Course on February 8-10

Then now is the time to get signed up because these courses will be held!

I gave a talk at SKF’s Asset Management 2005 Conference (for more info, click here) about the need for advanced root cause analysis to improve equipment reliability. (Click here to see a pdf of the presentation.) The response was very favorable. Several companies and SKF Staff Members were impressed with how helpful TapRooT(R) and Equifactor(R) could be in efficiently solving equipment reliability issues and asked how they could get people trained in this - to them - new technology.

One thing led to another and SKF has decided to help their clients (both internal manufacturing clients and external reliability clients) learn about TapRooT(R) by sponsoring several public 5-Day TapRooT(R) Advanced Root Cause Analysis Team Leader and 3-Day TapRooT(R)/Equifactor Equipment Troubleshooting and Root Cause Analysis Courses at SKF’s sites around the world.

The first course is a 3-Day and it has been scheduled for Brussels, Belgium, on March 15-17, 2006.

You can sign up for these courses on-line just like any other TapRooT(R) Course.

And to get more information about SKF’s reliability services, see their @ptitudeXchange web site.

Lately, several people asked me how to get started when setting up a program for incident investigation, proactive improvement, and root cause analysis. Often this is accompanied by the statement that they have been directed to develop an incident investigation policy.

My answer? Simple. Four ideas:

(more…)

This is an event that you really shouldn’t miss.

Each year I personally select a set of advanced courses for people interested in improving performance. These courses are held on the Monday & Tuesday prior to the TapRooT(R) Summit so that people can attend one of these advanced courses and the Summit. I look at it as a one-two punch for performance improvement. And you save $200 OFF the course fee when you attend both. And you can save an additional $200 if you sign up three or more people at once for a course and the Summit.

Here are the courses scheduled for April 3-4, 2006. Just click on the course title for details about the course and registration information. If you want more information about the Summit, click here.

Coaching Skills

Creative Solutions

Stopping Human Error

How To Interview & Gather Evidence

TapRooT(R) Software Administrator Course

TapRooT(R) Advanced Trending Techniques

Risk Analysis & Management Best Practices

TapRooT(R) Incident Investigation & Root Cause Analysis Training

Special 2-Day TapRooT(R)/Equifactor(R) Equipment Failure Root Cause Analysis

What is a “tin whisker”, what environmental issue has caused them, and why might tin whiskers be negatively impacting the reliability of your electronics?

See these web sites to learn more:

NASA WHISKERS NOTE http://nepp.nasa.gov/whisker/

NRC WHISKERS NOTE http://www.nrc.gov/reading-rm/doc-collections/gen-comm/info-notices/2005/in200525.pdf