by Rajesh Gopalan

There are many factors contributing to a successful enterprise asset management (EAM) implementation, not the least of which is the strategic relation between IT and the business during an implementation or product development lifecycle. While synergy between IT and business strategies is essential, another core element is the EAM user’s participation in the implementation and product development process. In fact, it’s one of the most critical elements to a successful EAM system.

The EAM user community is unique compared to their counterparts, such as finance and supply chain management. They’re not people who can be spotted behind a computer screen all the time, or those busy on their phones doing some price negotiations. Rather, they are out in the field most of their day. They are not computer savvy and very proud about this fact! Yet, they are the actual users of an EAM system, so it seems ironic that sometimes they get completely left out of the real action. They, to a greater extent, are detached from the IT stuff as opposed to their counterparts who occupy the top slots for any IT implementation decision-making process. When it comes to designing an EAM system of choice, the voice to put forth their ideas is the least.

As a real-life example, during a requirements gathering workshop for a business optimization program, Bob, a person in his mid-40s, turned up with a scribbled sheet of paper. He mentioned his manager insisted that he show up with the process map for the fleet maintenance department. At the time, the workshop was concluding, the clarifications and changes were all done, and sign off on the document was to be secured in the later part of the day. Bob’s attendance was surprising, not because the document was in the form of a scribbled piece of paper, but because of all the sessions he had missed already. When asked about the absence of representatives from the fleet division, Bob’s response was, “We guys work!” It was pun intended! For many in the EAM user community, most of their days are spent at far off sites, let alone participating in IT meets. Meeting with the boss often takes place on the weekend, when team meetings would plan work schedules for the coming week. IT didn’t work on weekends!

When an EAM software provider conducted a utilities amplifier solution, an application that leverages the inherent capabilities of the software and combines utilities best practices, the solution was well received by the likes of vendor teams, analysts and the business community. The functionalities, especially around efficient usability across multiple EAM roles, were very much appreciated during the demos and presentation. But the critical success factor of the solution was an “end user-input” element. So how did this happen? While being encouraged to critically evaluate core functionalities that would comprise the solution, each attendee was also encouraged to be very particular about having “a free mind” and donning that “user’s hat,” thinking through important aspects of a day in the life of various maintenance roles and the problems they face, and identifying solutions to optimally address them. The team working on the solution had this free mind when conceptualizing the functionalities and developed a working model out of it. This is something that normally does not happen in a regular EAM implementation or a product development process.

It was a good thing that Bob turned up that day. The surprise was a pleasant one because the process maps made a lot of sense and aligned well with the organization’s process optimization goals. While upgrades, enhancements, industry add-ons, etc., are emphatically discussed, what really matters is a system designed for a purpose. There needs to be a provision for the actual users to squeeze the system well so their functionality needs are addressed. This can only happen through effective user participation.

We need someone to corroborate jargons like reliability centered maintenance, key performance indicators, etc., with some quantifiable actions. If not, then EAM implementations would just get entangled into mystics of strategies. These users are tactical experts, people who breathe EAM functions day in and day out and who can give life to strategies. Let’s give them a chance to participate and let’s give them the feeling they are part of the system. Right now, EAM providers are actually missing them in the action and this needs to change!