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.