Creating an Asset Management Framework For Successful EAM Configuration

With the goal of understanding and building a data set around lifecycle costs, Veolia formed a core team of internal experts to evaluate the industry best practices in maintenance strategies. The team identified the ideals of Physical Asset Management (PAM), also commonly referred to as simply “asset management” or “infrastructure asset management,” as representing these best practices and selected the International Infrastructure Management Manual (IIMM), developed and made available by the NAMS Group in New Zealand, as a guiding document on PAM.

In addition to the IIMM, the team also began to add specific industry tools with proven benefit, including Reliability Centered Maintenance (RCM), Predictive Maintenance Strategies, Root- Cause Failure Analysis, and Criticality/Risk Based Prioritization. The guiding strategy and specific tools were combined into an overall implementation framework model. The primary architect of this model for Veolia and co-author of this paper, Terry Nelson of Inspiraworks, is now a consultant specializing in applying and adapting this implementation framework, now known as the Nexus Approach to Physical Asset Management TM (Nexus Approach).

With a framework envisioned, the Veolia PAM team moved on to address the core objective of selection and implementation of an Enterprise Asset Management System (EAM) capable of accommodating any or all of the 300 plus water and wastewater systems and future undefined growth. The first step was to write a Request for Quotation (RFQ) based on the desired functionality, which resulted in a short-list of EAM providers who demonstrated their products ability to address over 500 specific functions. Oracle Work and Asset Management (OWAM), at the time known as Synergen, was selected. The next step was implementation of a small set of representative systems which would demonstrate the range of anticipated configurations necessary to meet the PAM objectives. Finally, an internal company process was developed to continuously extend the EAM to additional client systems.

Looking back at the process, the Veolia team recognizes that the goal of understanding the life of assets and the selecting a framework of concepts and tools was critically beneficial during the selection, implementation, and configuration of the OWAM EAM. To others, who are considering an EAM implementation or upgrade, Veolia would highly recommend starting with a clear definition of your objectives, develop a specific and documented approach, and clearly convey the objectives through the selection and implementation process to achieve success.

BENEFITS OF SELECTING A FRAMEWORK:

The EAM selection process and preparation for implementation clearly revealed that Veolia faced a complicated effort to lay the proper foundation within the EAM to support the larger PAM strategy. In essence, Veolia had to work with and find compromises between:

• Inherent EAM capability, functions and limitations;
• Configuration and customization of the EAM to adapt it to the strategy;
• Adapting of company work flows and business practices to conform to EAM functions.

These challenges are common among EAM implementers and users. Navigating the process and achieving an effective and valuable EAM implementation is often not successful. This is supported by the survey results discussed in the August/September 2008 issue of Uptime Magazine. In an article (Surveying The Field, pages 22 – 25), Terrence O’Hanlon includes a number of charts. The first shows that 57% of survey respondents reported that they did not achieve anticipated return-on-investment for their CMMS/EAM: over one half of the respondents felt like they “didn’t make it” to their objectives for their CMMS/EAM. Other charts show that 61% of respondents changed their work processes to accommodate the CMMS/EAM, and 64% customized their CMMS/EAM. Even with the selection of a properly fitting CMMS/EAM, customization of the EAM to improve the fit, and adaptation of business practices to better utilize the EAM, over half of the respondents did not feel they achieve their objectives.

This is distressing news. Organizations often take the approach of starting their path of improvement by upgrading to a new CMMS/EAM system, hoping to catalyze or initiate a process of ongoing improvement by doing so. Often this process starts without a well-formed strategy in place and so the EAM implementation begins by incorporating the existing organizational functions, which often include organizational dysfunctions. As the Uptime Magazine survey article states, “If you automate a dysfunctional process, you simply create more efficient dysfunction.” In order for a CMMS/EAM to actually result in improvements, improved processes need to be developed and implemented through the CMMS/EAM implementation. They will not merely happen as a result of implementing an EAM system. A high percentage of EAM implementations fail and are abandoned or later re-implemented using lessons learned from the failed implementation. First-attempt success rates for some EAM systems can be astonishingly low and this is a possible explanation for the high dissatisfaction percentages for return on investment on EAM systems.

DEVELOPING THE GUIDING STRATEGY:

According to the IIMM, the objective of PAM is to “provide the agreed level of service in the most cost effective manner for present and future customers”. IIMM further breaks down the overall scope into a three-tiered organizational hierarchy. The highest tier is the strategic organizational perspective, which includes developing the vision, mission, objectives, policies, risk, etc. The product of a strategic PAM effort is a clear set of targets to be achieved within a defined concept of the organizations service.

Once the strategic tier is established, the tactical tier can be addressed where an asset management policy and approach is developed. This tier includes organization, funding, business prioritization, plans, and functional framework such as methods or processes.

The tactical plan then feeds into an operational tier where a suite of asset management solutions are developed, implemented, and operated to carry out the strategy and tactical plan. For Veolia, the set of asset management solutions including RCM, PM Optimization, Root-Cause Failure Analysis, and others were laid out in a cohesive functional diagram and later enhanced into a comprehensive PAM methodology, which is now available from Inspiraworks as the Nexus Approach to Physical Asset Management.

Once Veolia developed their strategic and tactical objectives, the block diagram was used to select and emphasize blocks as appropriate to translate the strategy into an operational plan. Each of the blocks represents functions or activities that depend on data from other blocks. The connecting lines represent a data channel for communication between the operational components. Veolia found that identifying and defining these data channels and how they would exchange data between the components of the operational tier was the key to success. Since data communication is common in the approach regardless of EAM selected or the elements of the operational approach, the focus of the remainder of this paper will be on examples of how Veolia defined these communication channels and implemented them in the EAM to provided connection between all elements of the operational tier.

COMMON LANGUAGE:

The Nexus Approach overall diagram (please email marc@wllcamg.com subject: DIAGRAM, if you don’t have this diagram available) shows the blocks connected into groups color coded by area or process. These processes are then connected together into the whole PAM approach. In order for the processes to connect and for information to flow, a common or universal language within the larger system is necessary, represented by the thicker blue arrows connecting the major diagram elements. The blue arrows represent the “tracks” along which the communication “train” runs, to connect the larger diagram into a functional whole. These train cars are the blue blocks on the left side of the diagram. Another diagram further exemplifies the fundamental nature of the common language showing four bars representing form, function, focus, and importance intersecting at a nexus.

Veolia incorporated these common language elements in the OWAM EAM using the prioritized methods below. These examples, will demonstrate how a guiding strategy is used to guide implementation efforts and decisions.

INTEGRATION METHODS:

The PAM approach and the EAM were fit together using several prioritized methods including:

• Configuration – Using built in options and capabilities of the EAM through setting of standard switches and parameters to align the EAM to the desired functions and flows.
• Modification – Using capabilities of the EAM (regardless of the uses intended by the vendor), to carry out functions and flows as desired within the EAM through special configuration.
• Procedural – Using capabilities of the EAM in limiting or specialized ways through procedural means such as documented procedures (not “hard” configured).
• Customization – Adding or altering the EAM to add or change capabilities and functions not inherent to the EAM as delivered.
• Cultural – Changing work processes and procedures to conform to EAM requirements, functions, and information flows.

The following examples demonstrate how the EAM implementation used the prioritized methods above to accommodate the common language elements noted above: function, focus, form, and importance.

EXAMPLE – FUNCTION: Function is what an asset does within the larger context of the systems it belongs to. Veolia developed a functional hierarchy format within which all client system assets, functional systems, and processes fit, including a coding structure. Assets are automatically grouped by the hierarchy into increasingly broader functional systems.

The hierarchy system reaches in detail to the “system” level: meaning that individual assets do not have unique hierarchy codes. Groups of about five to about 20 assets (all those forming a single functional system) share identical hierarchy codes. Because of this, the asset identification field of the EAM could not be used to store the hierarchy code to and allow sorting and filtering of assets by hierarchy code, as this type of field is often used in EAM implementations. OWAM provides fields for this use: the Department and Area fields. These fields would be appropriate; however, their field lengths are inadequate to hold the elements of the hierarchy coding structure.

The solution was to designate and configure two custom fields to store the functional hierarchy codes. Two fields were used instead of a single one in order to use cascading dependency so that the number of value options on each list could be limited to shorter lists for user friendliness. The hierarchy code was broken into two parts: a facility code identifying the physical facility of interest; and, a system code identifying the functional process and system of interest within the selected facility. Custom SQL code was used to populate and connect lookup values to the fields. The ability to use the functional hierarchy was effectively added to the EAM and has become a cultural foundation for EAM users tying them to the larger PAM program.

EXAMPLE – FOCUS: Focus represents what constitutes a unit asset within the EAM. For example, a pump set may be considered a single asset, or the motor and other components of the pump set may be considered assets. In order for the information within an EAM system and a larger PAM process to be useful in the aggregate, there must be consistency in focus: a pump must always mean the same thing. There is no particular right or wrong focus: it must simply be a consistent focus throughout the systems.

By default, the OWAM asset module allows stacking of assets into hierarchies to any depth desired, complicating or eliminating a fixed focus. To address this, the asset hierarchy functions had to be disabled, allowing only a single “level” of assets within the EAM. However, within many customer systems, a finer level of focus than the company wide asset focus is often necessary in addition to the company focus. The component module of OWAM allows management of units that are subsets of assets, which provides the necessary finer focus while allowing assets to be held at a single level.

Training, implementation guidelines, and user documentation all specify both a well-defined set of asset focus guidelines and require the parent asset fields of OWAM asset records to be blank (providing a flat asset hierarchy). Because they are to be blank, quality assurance querys can be run periodically to detect and provide for corrective action if not blank.

EXAMPLE – FORM Form represents the type that an asset takes and provides for grouping of similar assets. For example, pumps with pumps, compressors with compressors, etc. Because maintenance related information tends to have statistical or probability based aspects, population management is essential to effectiveness in most maintenance approaches including PAM.

OWAM provides an asset type field that is almost ideally suited for form. Only a single field is provided; a disadvantage because the list of company specified asset types is long due to the range and variety of facilities and asset types involved. Another limitation is that the list of values for the asset type field can by default be altered by users logged in at the local level; conflicting with managing the list at the company level.

Customization was used to create a “super administrator” user level allowing control of the list of values for the asset type field to be moved out of local control and into the super administrator.

EXAMPLE – IMPORTANCE Importance is more commonly known as risk or criticality. It represents the significance or impacts of loss of assets and importance of work items.

OWAM provides asset criticality and work order priority fields; both allowing numeric entry from 1 to 9. OWAM calculates overall work priority values by multiplying asset criticality by work order priority. Overall work priority has a scale from 1 to 99, the simple product of the ranges of input values. Higher work priority values mean higher importance.

It was not desired to give equal weight to asset criticality and work order priority in calculating overall work priority. For example, painting a highly critical asset should not have higher overall work priority when compared to repair of a functionally impaired less critical asset.

OWAM provides for restricting or specifying allowable values for fields. By experimenting with various values and combinations, asset criticality option values and assigned descriptions were developed as follows:

• 5 – Safety
• 3 – Environmental impact
• 2 – Economic Loss
• 1 – Low Impact

Work order priority options were limited and defined as followings:

• 9 – Emergency
• 7 – Urgent
• 6 – High
• 5 – Normal
• 4 – Low

By using the lower end of the 1-9 scale for asset criticality and the upper end of the scale for work order priority, work priority tends to override asset criticality, solving the critical asset painting priority issue. By skipping selected values (4 for asset criticality, 8 for work order priority), the desired order of multiplication products was established. For example, safety related mid-priority work is “boosted” above other non-safety work.

Conclusions and Recommendations

1. Figure out your Asset Management program objectives (CMMS is the foundation AM is built on).
2. Design specific implementation or workflow strategies to meet your Asset Management Program Objectives
3. Work closely with your implementer to use the tools and configuration options to achieve your goals.

 Dowload the companion Power Point presentation (PDF) below from the Reliability 2.0 Conference