Background

If you have ever analyzed information coming from your company's computer system, you know first-hand the importance of having meaningful and consistent data. Large-scale enterprise business solutions are a fact of life in today's world of manufacturing, business and finance. It's because of this that many have learned the importance of having data entered accurately and predictably in their system. Regardless of your role in your organization, while using your company's computer system, it's likely that you have found the availability of clear and concise pick lists (or selection lists) makes it easier to:

• enter data at key places;
• ensure consistency when performing transactions;
• extract precious information from the mountains of data existing in the enterprise.

In fact, beyond bringing efficiencies to performing work, it is the getting and using of worthwhile information from these systems which makes them valuable for reports and analysis. For reliability practitioners, failure event codes from work history records represent data providing the bridge to effective analysis.

There are 8 basic steps which need to be aligned with the overall implementation process to promote full user adoption of failure and event codes. These steps are sub-sets of other activities and simply need to be included in order to support the objective of user adoption. It begins once initial staffing decisions have been made for the team representing the plant maintenance/reliability functional areas - let's call them the 'reliability stakeholders.'

Step 1 - Education

The reliability stakeholders need to organize and understand their objectives. When it comes to failure and event coding, they should collect information about industry standards and best practices. It is often helpful to use a workshop to condense this timeframe to the minimum. The deliverable of this step is the 'work history and failure event coding overview for system users.' This is a baseline document which will be submitted to other stakeholders for their comments. The other stakeholders would represent the necessary inputs into the development of documentation related to failure event codes and include leadership, IT governance and change management. During the review cycles, this documentation takes shape leading to the final version for end-user training.

Step 2 - Analysis

During this step, the reliability stakeholders learn about and analyze the enterprise asset structure and the work processes to be implemented by the project. They also incorporate the feedback received from leadership, IT governance and change management. Leadership may provide input about the overall objectives and business KPIs for the organization. IT governance will provide information about the data standards to be employed by everyone. Change management will provide direction about the education and training process that will be used. The baseline document will be updated to reflect these valuable inputs. At the same time, the reliability stakeholders will understand what is necessary to effectively design the failure code sets and deliver the message to the organization. The output from this step is the enterprise asset structure and related naming conventions.

Step 3 - Development

Here is where the team of reliability stakeholders use their expertise, shared education and stakeholder input to develop the taxonomy and failure and event code sets. A key aspect is to bring the team together in a workshop specifically targeted at accomplishing this objective. The work should not be done in isolated silos; the effort will be more effective if everyone works together. Additionally, this team needs to continue vetting their work product with other teams. This interaction is valuable to the development of a quality product as well as fueling support for the effort. By now, the group has loosely formed into a 'Reliability Center of Expertise' (RCOE), with everyone taking on roles complementing their individual skill sets which benefit the organization. The output from this step is the enterprise failure event code sets and the complete asset taxonomy.

Step 4 - Implementation

By now, the design is complete, and other stakeholders understand the need and value of failure event codes and the asset taxonomy. This step aligns tightly with project implementation; here the RCOE provides support to others as outlined by the change management. This may take the form of presentations to leaders at all levels, education of end users and other communications. They also act as subject matter experts for others teams needing their input. The output from this step is end user training and, possibly, updates to documentation and work processes based on related discovery.

Step 5 - Adoption

This step is where the RCOE team members actively work within the organization to make sure that failure event codes are being used. They must recognize that, in spite of all the training, not everyone shares their passion and understanding of the need and value for failure codes. They have to coach and promote the usage at all levels of the organization. This begins with reviewing work requests/work orders on a daily basis and looking for opportunities to encourage full system use. Simply confining this activity to status reports which tend to lay blame is counterproductive. They must work one-on-one with others to develop traction and to build momentum until adoption is ingrained in the plant culture. In terms of success stories, there is latency in the process so it will be vital to establish and maintain credibility by properly attributing results to the individual contributors when achievements are realized.

Step 6 - Analysis

This is where the reliability professionals in the organization use the data coded by others on the work requests/work orders as a starting point for reliability analyses. These analyses often result in some level of strategy development or realignment. When things are changed, this should be communicated directly to those affected so that they can understand the benefit of the change and how they contributed by their day-to-day use of failure and event codes.

Step 7- Continuous Improvement

There has been a considerable investment in the overall implementation which has brought visibility to work processes and financial performance. During the implementation, there was any number of cycles to define and adjust. Here, the iterative process continues, but the input should no longer come from the project stakeholders. Rather, it should come from the user community. There should be a process to consider their valuable input and if merited, make the small adjustments and incremental improvements to the taxonomy, failure event codes, documentation or strategies.

Step 8 - Validating Efforts and Results

Another key aspect, which is crucial to on-going user adoption, has to do with giving credit for results. It is vital to publish success stories which are a direct result of individual or team contributions. Reliability professionals are very dependent on the information which comes from the end user, either during the reporting of failures or during the correcting of faults.

Conclusion

With all that the reliability team has invested in the process from the start of the project to after go-live, it may be disappointing if system users don't readily adopt failure and event codes. Don't see this as an obstacle, see it rather as an opportunity to build and strengthen the relationships between the reliability teams and your partners in operations and maintenance. Make sure to give credit to those involved in helping get results. Keep them involved and keep the lines of communication open. Through discipline and diligence, the importance and use of failure codes can become inculcated into your plant culture.

Artcile submitted by: Ralph Hanneman, CMRP, Senior Consultant, Meridium, Inc.

Ralph is a Senior Consultant for Meridium, Inc. who began his career in the Navy where he obtained considerable experience in the maintenance and operation of all facets of shipboard electrical systems, as well as the Navy's preventive maintenance methodology. He has nearly 20 years maintenance management and project engineering experience in pulp & paper, automotive parts manufacturing and heavy construction (tunnel boring).

Ralph has substantial experience in many facets of SAP gained with five years of ERP implementation projects in Plant Maintenance roles. He is experienced in SAP's BI solution, in particular Plant Maintenance reporting. Since joining Meridium in early 2007, Ralph has been involved in pilots and enterprise implementations of Meridium with PEMEX, BMA Coal, Hydro One, Hess, Rio Tinto, Bruce Power, Samarco Mineração and Flint Hills Resources in consulting and project management roles. He has conducted failure code development workshops for clients using SAP and Oracle eAM.