Archive | April, 2004


2:53 am
April 2, 2004
Print Friendly

Enhancing an Enterprise Asset Management Project

Capitalize on opportunities for improving maintenance and reliability and prevent missteps during an EAM implementation.

Since winning a Strategic Asset Management (SAM) Best Practices Award from MRO Software, Bedford, MA, at the MRO World Conference in July 2003, Air Liquide America, L.P. (ALA) has been asked by many companies to explain what made the implementation so successful. Lacking an innovative format to describe the elements, we resorted to the “Top 10 Reasons” approach (see accompanying section “Top Ten Enhancements”).

ALA, part of the Air Liquide Group headquartered in Paris, France, is the world’s largest supplier of industrial gases. Its products include air gases such as nitrogen, oxygen, argon, hydrogen, and CO2, as well as electricity and steam. In the United States, it has more than 125 production facilities and 700 customer installations to maintain.

Originally, facility maintenance was a decentralized function handled at the local or regional level. This arrangement served the company well for many years. However, in 1999, ALA wanted to upgrade and implement several management systems to better compete in national and global markets. One of these areas of focus was improved maintenance and reliability. It is well known that a fully functional enterprise asset management system (EAM) is a fundamental building block for improving maintenance and reliability. After extensive research in 2000, ALA selected MAXIMO as its EAM choice, and in January 2001 the project was commissioned.

We had been part of multiple EAM implementations with previous employers, but the other projects were replacing aged mainframe systems—legacy systems with existing processes and data to convert. Because ALA was decentralized, there were few common systems, data, or work processes. This made the project more daunting because so much data had to be collected or created. However, the upside was that we were able to start with a clean canvas.

ALA executives provided the project with excellent support and funding, and the implementation team developed a realistic project plan prior to approval. Without these elements, projects are either doomed to fail or will experience very difficult implementation with less than optimal results.

Set realistic expectations
Almost everyone in the company had desired a functional EAM for many years. Most viewed the implementation of an EAM more as the solution to improving maintenance and reliability and less as a fundamental part of a larger program. As a result, many people in the company thought the EAM would solve all of the maintenance and reliability problems. This led to numerous unrealistic expectations. When issues arose in meetings, it was common for someone to say, “Just wait until we get the EAM software and that problem will be solved.”

It took a considerable and sustained effort to constantly explain that the EAM was merely a tool to facilitate a process that was executed by well-trained people. When a maintenance or reliability issue was discussed, we tried diligently to categorize the issue as tool, process, or people. This did two things: it helped people understand that many of the issues were larger than the EAM and the EAM team did not get sidetracked with solving global problems. Some teams were given the process issues (prioritization, planning, scheduling, approval, etc.) to resolve and define. Other teams were given the people issues (reorganization, roles, responsibilities, training, etc.).

Because the maintenance function had been decentralized for decades, many in the company had built their own tools and processes to facilitate it. These were difficult to sustain on an individual basis and over time lacked coordination. Everyone wanted to migrate from these ad hoc processes, but they wanted the new tool to provide the same functionality that they were accustomed to.

Lacking any communication to the contrary, the field users expected or assumed that the new tool would do what they had always done, only better and faster. Again, it took considerable effort to explain that many of these were not really tool/EAM issues, but were process issues.

Then there are the database-savvy employees—the people who can make any database do just about whatever they want. They are invaluable resources within any department, but may also come with a set of unrealistic expectations.

Frequently, they believed that the software should be able to do everything they wanted it to do. When they experienced limitations with what the EAM software could do, their first impulse was to redesign and reconfigure software. We had to set the expectations with these people that the software, while limited, was more than adequate for the early stages of our maintenance and reliability evolution.

In the end, users began to realize that like everything else in life, the EAM had its limitations. The software would not do everything exactly as was done before and it could not do everything people thought it should, but in the end it performed well enough to gain the desired benefits at this stage of the journey. Furthermore, most of the changes needed fell outside the realm of the EAM. The EAM team needed to make sure the tool could support the new processes and the emerging organization.

Use the opportunity to reengineer
How many times do you get the chance to fundamentally change something as large as the way a company does maintenance and reliability? For most of us, the answer was not too often. Needless to say, we were excited about the opportunity to reengineer but were wary of the size and complexity of the issues involved.

Prior to commissioning the EAM project, ALA completed a Maintenance and Reliability Benchmarking Project with consultant Edwin K. Jones, P.E. The report indicated there were many pockets of excellence in the company, as well as opportunities to improve. The Benchmark Team evolved into a Strategy Development Team and their task was to migrate the pockets of excellence across the company and fill gaps where practices were lacking.

Starting with a clean canvas, we set out to create maintenance and reliability work flows that incorporated our own best practices and filled gaps where needed. As engineers, we charted flows for everything. However, as we built and refined, we made the common mistake of trying to perfect them. The flows became complicated and unwieldy. Pilot testing confirmed what we thought: no matter how perfect the flow charts were in theory, simplification was needed to assure success. After all, what is better: having perfect flows people in the field could not use, or functional flows that yielded 80 percent of the benefits that everyone could use?

We felt all along that our reengineering strategy of incorporating ALA’s pockets of excellence was a good one. Yet again, we also realized that if we were not careful, it could cause us to become too internally focused on solutions for gaps. Where should we look for best practice solutions to our gaps? There were plenty of books and magazines on the subject, which most of us read. There were successful past experiences from similar projects that would help. But in the end, we decided the first place we would look was to the software.

We hoped that by looking to the software for clues to process gaps, we would accomplish two things. One was to migrate best practices from the software. But second and equally important was that it would eliminate the need to change the base configuration of the software. This required an open mind from all of us.

The first time we tried an unfamiliar software function to complete a task, it seemed awkward and our initial impulse was to reject it. However, as we learned the software and kept an open mind, we found that we were adopting more and more of the software out of the box and building our processes around it. Taken to the extreme, this had the potential to break another cardinal rule—do not become a slave to your software. However, by simply trying the software solution first and adopting it where possible, the project benefited by increasing the quality of the project while at the same time lessening the workload on the project team.

Get stakeholder agreements early
A cross functional team from the different business units and other stakeholders was assembled early in the process to review the functionality of the EAM system as well as to identify and define the processes, gaps, and solutions. The project charter required that we operate with a single database and a single configuration managed centrally at our corporate offices. Therefore, flexibility was a must among all business units and was emphasized repeatedly.

Many configuration decisions were made during this time, some of which were compromises between the different business units. However, the flexibility of the software allowed us to meet the needs of all the business units, sacrificing little functionality.

Regardless of how the user requirements are collected, the most important thing is to collect them early in the project to define the project scope. The initial focus should be on defining the process and functionality necessary for the implementation. This is also the time to reach agreements and compromises within the group on the functionality to be implemented.

Once the requirements and corresponding solutions are fully defined, then the system configuration can begin. Care should be taken not to start the configuration too soon as this will likely result in duplicated efforts if the configuration does not meet requirements. Take the time up front to define the requirements. This time will be made up easily in the configuration phase if the requirements are well defined and agreed to by all involved.

The implementation plan should be developed during this time. This is not necessarily a detailed project plan but is instead a definition of how this new software will be introduced to users. In our case, we chose to divide the project into smaller, manageable pieces that could be implemented in succession.

We deployed the work order, preventive maintenance, and asset data systems initially with later implementations of interfaces to our financial system and inventory. Dividing the overall implementation into three smaller initiatives simplified the training requirements, reduced the configuration and documentation requirements, and allowed the users to learn one aspect of the system at a time.

Keep the team small and focus on quality
Steve Busick, an ALA maintenance manager, is fond of saying “better, faster, cheaper…pick any two.” It is a good way of describing that all projects have three basic elements: quality, schedule, and budget and that all three cannot be realistically guaranteed. One needs to be picked as a lever to assure the other two. This must be determined early in the project.

We chose to assure budget and quality by compromising schedule. We used a small but efficient implementation team which allowed us to solve problems quickly, concentrate on the quality of each phase, and better control scope creep.

If the speed of the implementation is the driving force of the project, the decision may be made to implement all of the functionality simultaneously. This is a daunting task and requires a very large project team. However, by dividing the project into smaller phases of implementation and using a smaller team, the timeline may lengthen, but the team will work more efficiently and be better able to meet the project quality and budget targets.

Adding people to the team will not necessarily reduce the implementation time. More people on a team may introduce inefficiencies, as well as reduce the team’s overall effectiveness. To assure better quality and maintain cost control, it is better to use a small group of strong contributors and implement at a slightly slower pace. By doing so, the team will have better focus and will learn the functionality of the entire system.

Smaller and slower paced, the project team members will become experts on the system once the project is completed. Large teams have a tendency to develop into silos of responsibility with each member concentrating on smaller parts of the system, resulting in individuals having only partial knowledge of the system.

Exploit software functionality
As we learned the software and began to use it as the basis for filling work process gaps, we discovered that the software had far more functions and features than we dreamed. As our confidence in the software increased, we explored capabilities outside our initial design. As we explored these features, we would match them with requests for functionality we had previously rejected.

Some of the things people requested started to make more sense. In many cases, the software was able to handle the requests. This was another discovery that had multiple benefits. It built broader support by incorporating more requests, and it came virtually free of effort. Additionally, it increased the effectiveness of the software and the processes it supported.

The natural tendency of good engineering project managers is to stay very focused on the scope of the project. They are not inclined to look outside what they are tasked to do for fear that they be tempted to add scope and ultimately cost and time to the project.

However, the effects of exploring all possible functionality had just the opposite effect on our project. It allowed the project to move faster at virtually no additional cost and provided a more comprehensive solution. We did not incorporate every feature we explored, but we did have an open mind to discover hidden opportunities that the software provided.

You may think you do not have time to explore all the features of the software and in the end you really need only 10 percent of the features. EAM software is not like that. Users may just use a few screens or perform only one or two functions required for the job.

But keep in mind that people are assigned different functions throughout the maintenance and reliability process. In effect, each person is using a different 10 percent. Among the approvers, planners, schedulers, warehousemen, purchasing agents, field foremen, craftsmen, and engineers, virtually all features can be exploited to some benefit. Remember, you paid for all of this functionality; you might as well try to use it.

Interface with EAM
One of the keys to a successful implementation of an EAM program is to interface it with the company’s financial system. Dual data entry will be eliminated and the data necessary to manage the maintenance business in your company will be available.

There are a variety of methods for interfacing systems. We would strongly recommend either an interface offered by your software manufacturer or a third party software interface. Many of these systems are robust and will significantly reduce interface development time compared with programming the interface yourself.

Do not assume that an interface provided by the software manufacturer will be an out-of-the-box solution. Much of the interface development will depend on how the financial system is configured. If significant customizations were made during the installation of the financial system, the interface effort may be more difficult. Interfaces offered by the software manufacturer will likely meet at least 70-80 percent of the interface needs, allowing you to focus project resources on the development of the remaining portion.

Additionally, there are third party interface providers who offer many benefits as well. Since these systems can interface many different computer systems simultaneously, they may be able to do additional future integrations to further enhance your project. These systems are often referred to as enterprise application integration (EAI) or middleware systems. Instead of programming an interface, the EAI will offer the foundation to build the interface through a graphical user interface in which tables from one system are linked to the tables of another.

An EAI solution will greatly reduce the effort required to build an interface and is an excellent alternative if the software manufacturer does not offer an interface that meets your needs. There are many user-friendly EAI products to choose from. Usually, little programming knowledge is necessary to use these systems and someone with good database skills can easily learn to configure the EAI.

The other benefit of an EAI is that it lends itself to changes and upgrades in the future. Custom interface development with programming code is time consuming and will be difficult to maintain as your business needs change.

At Air Liquide, we explored several EAI options, but in the end we chose MRO Software’s standard interface offered to our Oracle Financials system. This standard interface met most of our needs and required some custom interface development to meet the remaining needs.

Avoid smart numbers
Smart number methodology, where each digit has a specific meaning, is a holdover from older computer systems and is no longer necessary with current database software. Convincing people who are accustomed to working with smart numbers that the method is no longer necessary can be a difficult task and is often met with resistance. However, it has been our experience that once these users learn the new software, they will agree that the smart numbers are no longer needed.

Smart numbers are difficult to create, maintain, and teach to casual users of the system. Also, smart numbering of records in the system will increase initial development time and result in difficulties down the road as the need arises to change the numbers. Instead of placing intelligent information in the number or name of a record, place that information in a field on the record. This will greatly enhance searching and reporting capabilities.

Forbid code modifications
Configuration and customization both refer to changes in the software. Customization is the modification of the programming code and improves the desired functionality that the initial software does not provide. Configuration refers to the initial set up of the software: setting options, setting security levels, creating validated lists, etc. With some training, employees can usually configure the software; however, the amount of training will vary depending on the program.

Customization of the software that requires code modifications is the most costly and time consuming aspect of an implementation and should be avoided. It is imperative that the team selects a software platform that meets the needs and is easily configured to avoid code modifications.

Software programmers will gladly modify the code for you in order to meet your specific needs. However, you must be mindful of the project scope, budget, and the future. Code modifications can quickly grow, causing scope creep and budget overruns. Once the door to code modification is open, it will be difficult to close it. Others will attempt to modify the software for reasons they believe are important.

In addition, every modification made to the software code will have to be repeated every time the software is upgraded. This can become expensive considering that most software manufacturers release a new version every 6-12 months.

Modifications to software code usually require the hiring of the software supplier. Otherwise, warranties for the software will be considered void. You will then be committed to hire the supplier each time you wish to upgrade the software.

Furthermore, if you have a modified version of the software, it will be difficult to get help from the manufacturer when there is a problem. The person answering the manufacturer’s free help line is trained on the basic software and cannot help if there have been extensive modifications. That will require bringing a manufacturer’s representative on site at a significant cost to help with the problem.

It is easy for users to justify the need for software changes and then demand that the functionality is put in place. All requests for software code modification or customization must be carefully scrutinized. Customizing the software code usually provides only small incremental benefits and is not as critical to your business as some may believe.

Our suggestion would be to perform a cost benefit analysis on each individual change that is being requested. Be sure to use life cycle costs in this analysis because the future costs to maintain the modifications are often much larger than the initial costs. In most cases, modification of the software code is not justified because even simple modifications can be quite expensive. But if modifications are made, do not be surprised if the budget and maintenance fees for the project are negatively impacted.

Instead of modifying the software to fit your needs, consider modifying business practices to fit the software. You will find that although you may prefer to do business another way, the method forced upon you by the software is not that bad and often better. This will save both time and money in your initial implementation as well as in future upgrades.

Use a single database configuration
At Air Liquide, we implemented the system across more than 800 sites and three different business units with a single database. If you choose to interface the EAM with a financial system, a single database may be mandatory. There is always a temptation for each business unit to have its own database with its own configuration to fit its own unique business needs. It is your job to champion the benefits that a common database will bring.

Operating on a single database will greatly simplify the long-term maintenance of the system as well as the initial implementation. A common database means that each time there is an upgrade, a configuration or interface change is made, data is loaded, security is set, or the system is tested, it will have to be performed only once. It is difficult enough to maintain documentation of the system configuration on a single database system, but one of the most time-consuming parts of an EAM project is final testing and documentation of the configuration. The number of databases will multiply the amount of effort here also.

At Air Liquide, we implemented the entire United States on a single database with plans to incorporate our Canadian counterparts in the future. This required some compromises on system functionality among business units, but in the long run it enabled quicker testing and implementation and will enable us to maintain the system with a small number of employees.

Manage your consultants
We have saved perhaps the most difficult and most critical recommendations for last. The size and effectiveness of the consultant team is often the determining factor in the success of your project. It takes only one or two ineffective or misguided consultants to sidetrack or seriously harm an EAM project. On the other hand, getting the right consultants on the team can make all the difference.

So how do you go about selecting the number needed, assuring the quality of their work, and aligning them with your objectives? There are no hard and fast rules for these critical decisions, but these few guidelines should help get the most value for your investment in a consultant workforce.

How many consultants to hire? We have already mentioned one guideline: “Better, faster, cheaper…pick any two.” Know which two levers are the most critical for your project.

If it is faster and better (schedule and quality), you will need a large team of well-qualified consultants. This would be the most expensive route and most difficult to manage. Every member you add has the potential to hurt the effectiveness of the other members of the team. If it is faster and cheaper (schedule and costs), you may be able to use more consultants that cost less to employ, but you have to be careful about the quality. Good consultants are usually more expensive for a reason.

As mentioned previously, our needs were better and cheaper (quality and costs). We were able to use a small team of high-quality consultants. This may have taken more time, but in the end we were on budget with a very high-quality EAM system.

Another guideline is that it all comes down to people. You cannot totally depend on the reputation of the consultant company. Employee turnover at consultant firms is by nature higher than it is for a standard operating company. Even a highly regarded consultant firm can occasionally hire a bad consultant. Comparatively, a little-known company can have some really talented consultants. Keep in mind that a misaligned or ineffective consultant can kill your project.

In hiring the first consultant, we cheated a little. We hired a person we used on two other EAM projects. His work ethic, attention to detail, knowledge of maintenance processes, and ability to promote teamwork were outstanding. Even though he had never worked with this software, he knew exactly what we wanted. We concluded that with some training, he was smart enough to learn how to configure the software exactly as needed and there would be no “alignment” issues.

We knew that we needed someone with MAXIMO experience for our second consultant position, preferably someone familiar with accounting and inventory interfaces with financial systems. This was not as easy. We went through at least four consultants before we found the right one.

The key to hiring the right second consultant was to test-drive potential consultants on a trial basis and closely scrutinize their performance, work habits, and alignment with our goals. Some came in with their own agendas, not ours. It may be difficult, but it is best to quickly dismiss an ineffective or misaligned consultant and find another. Do not try to coach or mold an ineffective consultant into the team member you want.

The last guideline is to manage your consultants or they will manage you. If the project manager does not desire or know how to manage consultants, the consultants will usually work in a direction they assume best helps the project. This is misaligned with what the project actually needs.

Set short- and mid-term targets aligned with the project plan. Review the consultants’ work often and check progress against agreed-upon targets. Investigate teamwork and alignment issues as soon as they occur. Measure actual hours worked against the hours billed and do not pay for time at work spent on issues unrelated to the project. In short, set expectations and stay engaged.

What we would do differently
Develop the maintenance management process earlier in the project. We waited too long to fully develop the maintenance planning, scheduling, and reporting processes. This resulted in some reconfigurations.

We would advise that the maintenance process be fully and completely defined and flow-charted before the first configuration change is made and that all related reports and measures are identified. This is difficult because people usually tend to jump in and start working/configuring the software, especially if they have done a project like this before.

Put the configuration on hold and take the time up front to fully define the maintenance process. It is time well spent and will minimize the amount of rework needed after implementation. The software is only the tool to help perform your maintenance processes. Without a well-defined process, the software will be ineffective.

Limit the amount of initial asset data required for start-up. We spent a tremendous amount of time collecting and defining asset information. In hindsight, we have concluded that much of the data we thought we wanted to capture was not that useful and was time consuming to capture.

Typically, capturing the manufacturer, model, serial number, and a couple of other attributes was all that was needed. Do not spend too much time on the detailed data (pressure, flow, temperature, and other design data). The more data put into the system, the more data has to be maintained. Start with what is needed initially and add more data later as the need arises.

Reduce the levels of asset location hierarchy. The location hierarchy should allow users to find an asset without using smart numbers. The hierarchy format of drilling down to the asset is an excellent method for organizing data in the system.

However, be careful not to get too detailed with the hierarchy. In retrospect, we have too many levels in our hierarchy and would like to simplify it, but it would be difficult to modify something so fundamental to the configuration.

Better define user and system requirements. In retrospect, we should have spent considerably more time in the initial phase of the project and on development of user requirements for the system. We discovered later in the project that we had not fully defined these requirements.

This caused considerable rework of much of the configuration, documentation, training information, and testing information. We were too anxious to start configuring the software and could have saved much time by having better defined requirements.

Use fewer large workshops and more small focus groups. Although good information came from the large workshops, they were not the most efficient method for gaining the needed information. Too often, some participants had to endure topics for which they had little interest or involvement.

We believe conducting smaller focus group discussions and demonstrations on specific portions of the functionality rather than attacking the entire system at once in a workshop atmosphere better serves a project. The project team could then assemble the users’ requirements from these individual sessions, create recommendations for the configuration, and present those findings to the group in a single, larger session for approval.

Lessons learned
As is the case with many recommendations, we learned most of these the hard way. Whether installing a new EAM or replacing an old one, the success of the project will play a critical role in the future of your company.

It is important that the project be seen as an opportunity to improve maintenance and reliability processes and not an obligatory exercise to maintain the status quo. Be bold enough to incorporate best practices that may be different than current ones, but also be practical enough to compromise when needed to assure success. MT

Justin P. Bednarz is currently the manager of the Mississippi River Reliability Center located in Geismar, LA. Mark E. Lawrence, PE, CMRP, is the director of maintenance and reliability at Air Liquide America in Houston, TX.

Top Ten Enhancements
1. Set realistic expectations.
2. Use the opportunity to reengineer.
3. Get stakeholder agreements early.
4. Keep the team small and focus on quality.
5. Exploit software functionality.
6. Interface your EAM.
7. Avoid smart numbers.
8. Forbid code modifications.
9. Use a single database configuration.
10. Manage your consultants.>

back to article

Maintenance Management Processes Flow Chart


The basic flow chart shows how maintenance work orders flow through the process.

EAM/Financials Integration


Interfacing the two systems provides a way to manage the maintenance business.

Continue Reading →


1:16 am
April 2, 2004
Print Friendly

Updating Shaft Alignment Knowledge

Defining permissible misalignment tolerances determines a reliability-focused approach.

In the majority of industrial facilities, worker and technician resources are probably stretched to the limit. They might be looking for ways to simplify some traditional work processes and procedures. Or the facilities may have had an experience that reinforces the contention that high-tech tools are not always the answer, and that back-to-basics thinking has considerable merit.

While no reasonable and experienced reliability professional will take issue with these statements, industry must be cautioned against drawing the wrong conclusions. A recent example of wrong conclusions involves claims that rotating equipment alignment is sufficiently accurate as long as the shaft centerlines in their cold, standstill condition are within 0.002 in. (0.05 mm) of each other. Those who believe this and blindly follow this questionable advice may soon find themselves among the repair-focused dinosaurs who are struggling to survive.

On the other hand, those who update their knowledge of shaft alignment and alignment tolerances are on the way to becoming reliability focused. Indications are that only the reliability-focused facilities will be around in a few years.

Expressing tolerances
The only correct way to express shaft alignment tolerances is in terms of alignment conditions at the coupling. This article will describe several ways to do this. It is incorrect to describe alignment tolerances in terms of correction values at the machine feet, and this will be examined also.

When two machines are directly coupled with a flexible coupling, any misalignment between their centerlines of rotation can result in vibration which, depending on its severity, can produce premature wear or catastrophic failure of bearings, seals, the coupling itself, and other rotating components. Misalignment of the centerlines of rotation has long been recognized as one of the leading causes of machinery damage.

Decades of well-documented observations attest that misalignment is responsible for huge economic losses. The more misalignment, the greater the rate of wear, likelihood of premature failure, and loss of efficiency of the machine. Misaligned machines absorb more energy and thus consume more power.

However, even excellent alignment of the shaft centers of rotation does not guarantee absence of vibration because there is still the possibility of imbalance of rotating components. Structural resonance, fluid flow turbulence and cavitation, or vibration from nearby running machines that is transmitted to adjacent machines through either foundation or piping could also exist.

Foot alignment does not work
Absolute perfection in the alignment of shafts is not realistically attainable, nor is it needed. The issue is quantification of alignment quality and allowable deviation—the alignment tolerance.

Misalignment is defined by visualizing the shaft centerlines of rotation as two straight lines in space. The trick is to get them to coincide to form one straight line. If they do not, then there must exist either offset misalignment or angular misalignment (Fig. 1), or a combination of both.

Since the shafts exist in three-dimensional space, these misalignments can exist in any direction. Dividing this space into two planes, the vertical and the horizontal, and describing the specific amount of offset and angularity that exists in each of these planes simultaneously helps define the four specific conditions of misalignment—vertical offset (VO), vertical angularity (VA), horizontal offset (HO), and horizontal angularity (HA). These conditions are described at the location of the coupling because that is where harmful machinery vibration is created whenever misalignment exists.

The magnitude of an alignment tolerance (the description of desired alignment quality) must be expressed in terms of these offsets and angularities, or the sliding velocities resulting from them. Attempts to describe misalignment in terms of foot corrections alone do not take into account the size, geometry, or operating temperature of a given machine. Accepting the simple foot corrections approach can seriously compromise equipment life and has no place in a reliability-focused facility. An illustration of the fallacy of the foot correction approach will be given later.

How much vibration and efficiency loss will result from the misalignment of shaft centers depends on shaft speed and coupling type. Acceptable alignment tolerances are functions of shaft speed and coupling geometry. High-quality flexible couplings are designed to tolerate more misalignment than what is good for the machines involved. Bearing load increases with misalignment, and bearing life decreases as the cube of the load increase, i.e., doubling the load will shorten bearing life by a factor of eight.

Why would high-quality flexible couplings be generally able to accommodate greater misalignment than what is good for the connected machines? A large percentage of machines must be deliberately misaligned—sometimes significantly—in the cold and stopped condition. As they reach operating speeds and temperatures, thermal growth is anticipated to bring the two shafts into alignment.

Alignment case history
A refinery has a small foot-mounted steam turbine enveloped in insulating blankets. The operating temperature of the steel casing is 455 F, and the distance from centerline to the bottom of the feet is 18 in. The turbine drives an ANSI pump with a casing temperature of 85 F; its centerline-to-bottom-of-feet distance is also 18 in. Both initially started up at the same ambient temperature. The differential in their growth is (0.0000065 in/in/deg F) × 18 in. × (455 – 85) deg F = 0.043 in.

If these two machines had their shafts aligned center to center, this amount of offset would cast the equipment train into the frequent failure category. Using the 80/20 rule, it would be safe to assume that 20 percent of the machinery population accounts for 80 percent of the maintenance money. This pump train would be in the 20 percent group.

As mentioned earlier, aligning center to center without paying attention to thermal growth is one of the factors that keeps practitioners in the repair-focused category.

Permissible tolerances
There are a number of acceptable ways to describe misalignment at the coupling and to define permissible misalignment tolerances. While many of these are of equal merit, describing alignment tolerances in terms of foot corrections is not acceptable in a reliability-focused environment.

Offset and angularity at the coupling (for short couplings) is one of the most common ways of correctly defining alignment tolerances. The offset tolerance simply describes the maximum separation that can exist between two machine shafts at a specific location along their shaft axes, usually the coupling center. The angularity describes the rate at which the offset between the shaft centerlines may change as they travel along the axes of the shafts.

The angularity may be described either directly, as an angle in terms of mils/in. (or milliradians), or as a gap difference at a particular coupling diameter. The latter method is popular because it relates directly to what the mechanic can detect with his feeler gages between the coupling faces. A modern laser shaft alignment system measures the angle between shaft centerlines; such a system can also be set to describe this angle as a gap difference at any desired diameter.

This approach can have two different interpretations, however. If the permissible offset between the driver and driven shafts is X, does this mean X in any direction, or X individually in both the horizontal and vertical planes? These two alternatives are not the same. The first example, vector tolerance, is more conservative. The second approach, standard tolerance, is the more common approach. If it is not desired to have more than X of offset to exist between the shafts in any direction, then standard tolerances should not be used. Doing so would, in some circumstances, lead to greater-than-intended offsets. Figure 2 illustrates this point.

Figure 2 (left) illustrates a case where applying standard tolerances results in an offset of 2.5 mils horizontally and 2.7 mils vertically that is deemed acceptable because the permissible limit for either of these offsets individually is 3.0 mils. However, the actual offset between the shafts is 3.7 mils, which is unacceptable if your absolute limit is 3.0 mils. This result can be seen as a vector tolerance (Fig. 2 right).

A good laser shaft alignment system will allow the user to make this distinction and to specify exactly which type of tolerance is desired.

Table 1 shows the values most widely accepted as the standard industry norm for short couplings.

Spacer coupling tolerances are generally expressed as limits to the angle that may exist between each machine shaft and the spacer piece between them. Since the spacer piece (or spool piece) connects to each of the machine shafts at either end, there should be no offset between the spacer and each of the machine shafts. Only the maximum angle allowed between the spacer shaft and each of the connected machine shafts needs to be specified. This angle may be specified directly in mils/in. (or milliradians) or in terms of the offset that each individual angle between spacer and machine shaft projects to the opposite end of the spacer. The first way is called the angle-angle method (sometimes called the alpha-beta method), and the second way is called the offset-offset (or offset A-offset B) method (see Fig. 3).

Since most flexible couplings have two flex planes (or points of articulation), the spacer coupling tolerances may safely be used, even with flex couplings. The best criterion to make the distinction is the relation between the diameter of the flex planes and the distance between them. Whenever the distance between flex planes (span) is greater than the diameter, it is called a spacer coupling. This will make achieving tolerances easier when performing alignment corrections in the field. Table 2 presents the values most widely accepted as the standard industry norm for spacer couplings.

Sliding velocity tolerance is the permissible limit of the velocity that the moving elements in a flexible coupling may attain during operation. This can be related to the maximum permissible offset and angularity through the formula:

Maximum allowable component sliding velocity = 2 X d X r X a X π

d = coupling diameter
r = revolutions/time
a = angle in radians

When offset and angularity exist, the flexible or moving coupling element must travel by double the amount of the offset and angularity every half rotation. Because the speed of rotation is defined, so must be the velocity that is achieved by the moving element in accommodating the misalignment as the shaft turns. When the permissible sliding velocity is limited, the offset and angularity (in any combination) that can exist between the coupled shafts as these turn is also limited by definition.

For 1800 rpm, this limit is about 1.13 in./sec for excellent alignment, and 1.89 in./sec for acceptable alignment. A good laser alignment system will let reliability-focused users apply this approach as well.

Tolerances expressed as corrections at the machine feet are not acceptable. It is impossible to define the quality of the alignment between rotating shaft centerlines in terms of correction values at the feet alone, unless the exact dimensions related to these specific correction values are specified each time. This approach is too cumbersome and error-prone, since two machines will rarely share the same dimensions between the coupling and the feet, and between the feet themselves.

A tolerance that describes only a maximum permissible correction value at the feet without references to the operative dimensions involved makes no sense because the same correction values can yield vastly different alignment conditions between the machine shafts with different dimensions. Such a tolerance ignores the effects of rise over run, which is essentially what shaft alignment is all about. Such a tolerance does not take into account the type of coupling or the rotating speed of the machines.

These alignment tolerances specified generically in terms of foot corrections can have two equally bad consequences: the values may be met at the feet yet allow poor alignment to exist between the shafts, or these values may be greatly exceeded, while representing excellent alignment between the shafts. In the first scenario, the aligner may stop correcting his alignment before the machines are properly aligned. In the second case, the aligner may be misled into continuing to move machines long after they have already arrived in tolerance.

A couple of examples illustrate the fallacy of the generic foot correction approach. Assume that the specified alignment tolerance for an 1800 rpm machine is defined as a maximum correction value for the machine feet, ±2 mils.

A machine is found to require a correction of –2 mils at the front feet and +2 mils at the back feet—in tolerance by this method. If the distance between the feet is 8 in., this would imply an existing angular misalignment of 0.5 mil/in. If the distance from the front bearing to the coupling center is 10 in., the offset between the machine shafts at the coupling would be +7.0 mils.

This offset is considerably in excess of the ±3 mils of offset (either standard or vector) that is considered the maximum acceptable for an 1800 rpm machine at the coupling. Yet, with the improperly specified foot correction tolerances, this alignment would be in tolerance. This is a classic example of where small correction values at the feet do not necessarily reflect good alignment at the coupling (Fig. 4).

In addition, the opposite scenario is just as likely to occur. Assume a large machine (such as a diesel engine) is running at 1200 rpm with distance between the feet of 80 in. The distance from front feet to the coupling is 30 in. The machine has misalignment requiring foot corrections of –8 mils at the front feet and –26 mils at the back feet. The misalignment at the coupling is only 1.25 mils of offset and only 0.225 mil/in. of angularity. In reference to the coupling, both of these alignment conditions are already much better than required by the standard industry norms for 1200 rpm. However, using the improperly specified tolerance values of ±2 mils at the feet, the aligner would be misled into working much harder and longer than necessary to bring the machines to these values (Fig. 5).

Note: Figures 2, 4, and 5 were created with the assistance of Alignment Explorer software by Prüftechnik, Ismaning, Germany, and input from Ludeca, Miami, FL. MT

Heinz P. Bloch, P.E. is a consulting engineer with over 40 years of experience in chemical process plants and oil refineries. He may be reached at 5459 Ponderosa Dr., West Des Moines, IA 50266; (515) 225-0668; e-mail



Fig. 1. Misalignment can be offset (left), angular (right, or a combination of both.

back to article



Fig. 2. Depending on circumstances, using the standard tolerance (left) instead of vector tolerance (right) can lead to greater than intended offsets.

back to article



Fig. 3. Specifying the maximum angle allowed between the space shaft and each of the connected machine shafts sets the spacer coupling tolerances.

back to article



Fig. 4. Small correction values at the feet do not necessarily reflect good alignment at the coupling.


Fig. 5. Improperly specified tolerance values may show misalignment where none exists.

back to article

Table 1. Shaft Alignment Tolerances (Short Couplings)











































back to article

Table 2. Shaft Alignment Tolerances (Spacer Couplings)

Angularity (Angles α and β) or Projected Offset (Offset A, Offset B)(mils/in.)






















back to article

Continue Reading →


5:57 pm
April 1, 2004
Print Friendly

The Tale of an Old Clock. . .And Reliability


Robert M. Williamson, Strategic Work Systems, Inc.

A broken clock is exactly right twice each day. But did you ever think about what “right” really means?

An old man walked to work each day, checking his watch as he walked through town. On his way he detoured to the town’s only jewelry store. He would stop there every day and set his watch by the old clock in front of the store. This went on for years. The shopkeeper would watch this routine with curiosity and respect for the old man’s consistency. Rain or shine, the old man’s daily ritual never changed.

Finally one day the jewelry shop owner stepped out of his doorway and asked the old man why he was setting his watch every day. This surprised the old man, but he was kind enough to answer what seemed to be an obvious question.

He explained, “I stop by here each day on my way to work to set my watch. You see, this old watch may not keep the best time in the world but it’s the only one I have. And my job is the timekeeper at that old mill up there on the hill—I have to make sure the clocks up there are accurate. Then, every day at four o’clock I have to sound the whistle signaling shift change time. So, each day I have to reset my watch to make sure I sound the whistle at the right time.”

The shopkeeper looked puzzled by this reply. He told the old man, “As you can imagine, this old clock has served us well for many years. And it really doesn’t keep time that well any more. So each day at four o’clock I reset it when I hear the mill whistle.” Both men paused, then laughed. Together, they had created their own erroneous time zone in that small mill town for years.

This story should remind us that each day we do simple things that require thought and care—in many cases our jobs and our company’s success depend on what we do. What is our standard for doing the right things to take care of our plant and facility equipment? How do we make sure we are doing the right things at the right times, the right way? These questions bring me to a second story, one of close personal experience.

One of the machines we were working on recently was an old one, built in 1939 and refurbished in 1970. It was in remarkably good shape considering its age. It ran as part of a processing line 24 hours a day for 5-6 days each week. This machine was picked as a total productive maintenance (TPM) target since most of the product quality losses from the processing line could be traced to it. The data was accurate and reliable. But rarely was this quality data used to address maintenance problems the way we did with the pillars of TPM.

Underneath a 6-ft long solid steel guard were two flat belts. It takes two people to lift the guard off the machine. One of these belts was used to drive the intake drum, the other to drive a takeoff drum. Upon inspection of these belts they were worn beyond any usefulness. They showed signs of severe slipping. But, according to plant standards, they were not to be replaced unless they were broken; “If they aren’t broke we don’t replace them.” The preventive maintenance (PM) instructions said to “check the belts.” So, they checked them.

Upon looking at part of the machine drive system we noticed a very heavy buildup of fibers. The plant’s PM instructions went on to say “clean all gears and chains. Oil the chain and sprockets, grease the gears.” That would seem normal. But that was the OPPOSITE of what the equipment manual recommended.

On a single page describing lubrication there was a warning note: “Do not grease or oil the gears and chains. There is extra clearance designed into these components to prevent a buildup of fibers. Grease and oil will attract fibers and cause the parts to bind and jam and the belts to slip.”

So, what about belt slippage? It was the single largest cause of product defects. What is the root cause of belt slippage? Not checking the right source for proper maintenance—the equipment manual; not using the right information to perform the right maintenance at the right time on a critical piece of equipment; assuming that a “common sense approach to basic maintenance” applies across the board. Pick one.

“Right” means doing what the equipment requires. “Right” means consulting accurate and reliable sources to determine the right things to do. “Right” means “right” without a doubt—facts not opinions. Equipment reliability depends on all of us doing the right things the right way. MT
Continue Reading →


5:50 pm
April 1, 2004
Print Friendly

Thinking Inside the Box


Robert C. Baldwin, CMRP, Editor

The other small book I unearthed a couple months ago with “The Team Memory Jogger” is the delightful “Think Outside the Box: The Most Trite, Generic, Hokey, Overused, Clichéd or Unmotivating Motivational Slogans” put together several years ago by consultant Jim Tompkins. Its content was fed by a contest to see who could come up with the worst slogan. It drew 1100 entries.

The book is available from the Tompkins Associates Web site at, and draws attention to that portion of today’s corporate culture that often looks for quick fixes or creative slogans to solve problems or re-energize organizations. What typically happens is the opposite—such slogans often backfire.

As one contributor put it: “The currently popular phrase ‘outside the box’ fits the contest criteria perfectly. It pre-supposes in the most denigrating way that employees are unimaginative, uncreative, and stupid. The only clue to the faintest possibility of it being true is that the person works for someone who uses such a phrase.”

In all too many cases, the think-outside-the-box message needs to be sent back up the chain of command where it might do some good.

Many people with leadership titles might as well be working inside an empty box. They seem ill informed about or do not understand the workings of the organizations they have been tapped to lead.

Perhaps they are asking people to think outside the box because they have little knowledge or appreciation for what is going on inside the box.

It would seem prudent to leverage what is of value inside the box, regardless of which way you are looking.

There is plenty of value inside the maintenance, reliability, and operations (MRO) box and most companies are using only a fraction of what’s there.

More companies are beginning to realize that some of their best chances for boosting performance reside in the MRO sector and there are a number of suppliers of technology products and services gearing up to serve the growing MRO market.

One place to find out more about what the MRO box has to offer and how you can make it an even more effective contributor to enterprise performance is the Maintenance & Reliability Techology Summit (MARTS) scheduled for May 24-27, 2004 in Rosemont, IL.

I hope we will see you there, regardless of whether you hang out inside or outside of the MRO box. MT


Continue Reading →


2:37 pm
April 1, 2004
Print Friendly

Ultrasonic Leak Detection Improves Heat Rate

In the competitive electric power generation market, attention must be given to improving condenser operating efficiency. Steam turbines cannot attain their specified performance without an efficient condenser. Tube leaks that affect condenser performance are critical. Most condenser tubes are designed to last at least 30 years. Unfortunately, normal plant operation, changes in water chemistry, and other circumstances often create a shorter life for tubes. Most condensers are overbuilt to allow for a certain percentage of tubes to be plugged when a leak is detected.

In the past, Seminole Electric, headquartered in Tampa, FL, like other utilities, used methods including pasting wet newspapers against tube sheets, spraying thick foam, or using saran wrap to locate condenser tube leaks. These methods were slow, required multiple experienced operators at inconveniencing hours (plants can typically be brought to a partial load only during the midnight shift), and worse, were often ineffective.

By using a ruggedized portable ultrasonic leak detector, Brian Thorp, predictive maintenance (PdM) technician for Seminole Electric, has been able to provide quick leak detection and repair on an aging steam condenser, allowing the utility to provide maximum power during high demand periods.

Ultrasonic technology
Ultrasonic leak detectors work like simple microphones that are sensitive to high-frequency sounds ranging from 20-100 kHz. In comparison, most humans can hear at most 17-19 kHz.

Using a sensitive piezoelectric crystal element as a sensor, minute high-frequency sound waves excite or “flex” the crystal, creating an electrical pulse that is amplified and then heterodyned, or translated, into an audible frequency that the technician can hear through a pair of noise reduction headphones.

As a leak passes from a high pressure to a low pressure, it creates turbulence. The turbulence generates a high- frequency sound component, which is detected by the piezoelectric element, allowing the technician to guide the instrument to the loudest point in order to pinpoint the leak.

Several ultrasonic detectors use parabolic or elliptical reflectors to enhance and concentrate the leak signal, which can be useful when detecting small leaks or scanning at a great distance.

Effects of tube leaks
The condenser is the largest heat exchanger in the condensate/feedwater network. It is located under the steam turbine generator. When the steam exits the turbine, it is passed over cool pipes (cooled by river water) that condense it to liquid water. The purified water is pumped back to the boiler to be heated to steam again. The same purified water is boiled and condensed over and over.

Keeping the condenser tubes from leaking the river water into the steam or clean side of the condenser is a key to achieving optimum performance. Fresh water leaking into the purified system can wreak havoc by causing corrosion throughout the system and can significantly reduce operating life if not rapidly addressed.

Leak detection in condensers
The Seminole Electric plant condensers contain 44,000 one-in. tubes per unit and feature a split design, with eight water boxes or two loops. This allows the plant to isolate one loop or four water boxes while running at a partial load. Isolating a section of the condenser allows Thorp to drain the cooling water and enter the water boxes while the plant is still operating. Because the turbine is still operating, a vacuum is present on the steam side of the condenser tube. This vacuum creates a pressure differential that sucks air into the tube leak site. As the air enters the leak site, it creates a minute turbulence, which generates a high-frequency signal. The ultrasonic leak detector quickly detects and pinpoints leaking tubes, allowing them to be plugged.

Operations know when a leak is severe enough to warrant attention by sensitive sodium parts per billion (ppb) counters in the condensate pump discharge system. The sodium counter display is checked by operators on their rounds.

Ultrasonic leak detection
Seminole originally tried an older airborne ultrasound detector. The unit tested was not designed for the high humidity environment that is present in steam condensers. It soon ceased to function as moisture built up in the circuit but not before what was thought to be a tube leak was heard. Unable to complete the ultrasonic test at that time, the usual time-consuming methods were used to solve the immediate problem; however, the PdM department was convinced it should learn more about high-frequency ultrasonic detectors that were designed for harsh environments.

Thorp’s research led him to SDT North America, Cobourg, ON, where he found the company’s 170M, an instrument that is sealed to IP65 (ensuring it will function in wet environments) and includes a flexible extension wand to extend the reach of the leak detection sensor.

Thorp soon discovered that online steam condensers offer abundant ultrasonic signals to compete with the leak signal. To solve this problem, he holds the instrument a few feet from the tube sheet and scans the entire area. If a noisy area is found it is noted. He then switches to an extended flexible sensor and scans tube to tube. If the sound signal on the digital dBVU meter or sound in the headset does not change from tube to tube, a leak is unlikely. This is particularly true of tubes located on the outer edges of the tube sheet, as these tubes are more likely to have noisy steam flowing over their o.d. surfaces.

If a significant signal change occurs, a leak is suspected. If the leak is in the tube, the difference will be heard at the tube opening. If the noise level is heard on the tube sheet, the area is blocked to eliminate reflected noise. A concentrator cone with an opening of 1/8 in. is placed on the flexible extended sensor and is held almost on the tube sheet surface. It is then moved around the tube to tube sheet fit or the plug previously installed in the tube. During this process the small area of the 1 in. tube that is leaking can be pinpointed and repaired.

After using the ultrasonic detector for a while, Thorp attended a 21/2 day Level 1 training course. He returned from that training confident that he would expand the use of the ultrasonic detector to detecting problems with coal conveyors, bearings, compressed air leaks, and other problems that commonly occur in a power generating station.

Seminole Electric realized several intangible savings from improvements in water cleanliness and reliability related to the ultrasonic leak detection project. Reduced water chemical cleanings mean reduced costs and a reduction in tube leakage also means less corrosion.

Also, working in water boxes at operating power plants can be unpleasant, with an ambient temperature of 100-105 F and a 99.99 percent relative humidity. Using ultrasonic leak detectors has allowed Seminole’s maintenance personnel to get into the water box, find the leak, and get out quickly.

Thorp reports a quick return on investment for the ultrasonic detector and has attracted the attention and support of top company management based on the results to date.

His advice to others considering ultrasound is to use as many technologies as are available to solve problems, as no one technology can supply all the answers. He is confident that ultrasound will remain an important inspection tool for Seminole Electric. MT

Seminole Electric

Seminole Electric is a generation and transmission cooperative headquartered in Tampa, FL. It provides bulk supplies of electricity and wholesale energy services to 10 cooperatives located throughout peninsular Florida. More than 1.5 million individuals and businesses in 45 counties rely on Seminole and its members for electric service. Seminole’s primary generating facility is located on the St. Johns River in Putnam County, FL, about 50 miles south of Jacksonville. This 1300 MW station has two 650 MW generating units. The plant’s water hyperbolic cooling towers (450 ft tall and 400 ft across) and 675 ft stack are visible from miles away. This plant generates electric energy from coal. Its output is distributed across transmission lines to Seminole’s member distribution systems that, in turn, deliver electricity to individuals and businesses—about 10 percent of Florida’s population.

back to article

Continue Reading →