Q & A: Change Management Supporting New Technology

Following you'll find answers to some questions we get from clients contemplating (and sometimes knee-deep in!) implementing an ERP. But let's first start by giving you some perspective on how we see Change Management (CM) in relation to an ERP…

How we see it…
We are continually amazed by the range of different companies' perceptions of what is included in the scope of CM. The range includes training, communication, marketing, reengineering, organizational behavior and others. The truth is that effective CM includes elements of all of these and much more.

Change Management support helps the organization make the mechanical changes in vision, work processes, and employee performance systems that are necessary to get value from the ERP. Effective CM is not "touchy-feely" stuff, advertising hype, or a bunch of theory. It is a serious commitment of time and resources to get the user organizations ready to use the new technology and to mitigate risks of failure to maximize the return on the big-time serious investment in the technology insertion. Companies either commit the resources and management support to CM and get a return on their investment, or they just talk about it and get only a fraction of the benefits they should have gotten.

The Q & A
Q1: Why is Change Management needed when implementing an ERP (or any other big technical system)?

A1: Change Management helps the organization revise its work processes and employee performance management systems to get maximum benefits from the new tool. It helps the organization internalize the vision of a better way of doing work-what led the company to undertake the massive job of software tool insertion in the first place.

Successful companies would never make major investments in expensive, state of the art, tangible equipment without thinking through how their work should change to get a benefit from the investment. Why, then, should any company undertake the massive investment in intellectual capital represented by an ERP without going through the same steps?

Q2: Who must own Change Management in the implementing organization?

A2: The management of the company must own the Change Management effort because they have to live with the results of it. Just as importantly, the users whose work processes are affected by the technology insertion have to own it because they are the stakeholders who bear the most immediate brunt of the change, good or bad.

Q3: What are some of the bad things you have seen happen when there is inadequate Change Management?

A3: Confusion about how to get work done with resultant deterioration in work performance, outright resistance to the changes, underground resistance to the changes, inappropriate work processes of one work group hampering the performance of other work groups, exceptionally steep and long learning curves, abandonment of projects, severe morale problems. The list is long and depressing!

Q4: How do you get line managers to understand that Change Management is critical for implementation success?

A4: One of the most powerful tools I know for helping this understanding is getting the influence leaders in the line organization involved as subject matter experts very early in the tool development project and keeping them involved. Line managers are usually very pragmatic people. When they understand that the new system will not support old work processes, they look for solutions that will minimize the impact on their work force. Change management techniques can then be presented to the line managers as a tool for making work process changes and improving their performance without causing a performance disaster during the learning curve.

Q5: So an implementing organization is doing a good job of communicating about the upcoming ERP…and the vendor is doing training on the software. Isn't that enough Change Management?

A5: Absolutely NOT, although that is the approach you see many companies take. The activities described will let the users know that something is coming, and they will probably be able to push buttons within their individual silos and make an electronic transaction happen. So what's missing?

• The management and users will not have a common vision about why the implementation is being done and why they must support the vision. Until there is a common vision and all the players (including the worker bees) can articulate what that vision means in their jobs, you will not have a common direction. In fact you may have dissension, sabotage, and other unhappy consequences if this does not exist.

• Work process changes surrounding the transactions in the new system have not been examined for needed changes, revised, and tested. The new system typically does not exactly replicate the old system, so old ways of doing work will probably not fit the new system. Additionally, the new way of doing work in one work group may spill over into another work group's processes and cause havoc there. Until the new system can be described and understood in terms of horizontal work processes instead of transactional silos, there is substantial risk of undesired results.

• The nuts and bolts requirements (Plant, Equipment, Tools) surrounding the new system have not been reviewed and changed. Great communication and good training don't do much for you if the new system has changed the tools you need to do the job and you haven't provided them!

• The old performance management system has not been modified to reflect the new jobs being done by the users of the system. For the new system to be effective, the impact of changed work processes on individual job metrics must be understood and new metrics developed, if needed. The individual users' supervisors must re-contract with the employees to do their new job. New metrics of successful performance must be agreed upon, and we must get a "handshake" acknowledgement from the user that they will do the new work … not the old … and that they will get paid for performing to the new metrics, not the old.

• There must be an action plan to answer the "What do I do on Monday morning?" question. Communication and technical training are necessary steps, but they do not complete the job of visualizing how the work will be done differently under the new system. The work processes and performance metrics around the transactions in the new system must be modified, explained, and understood at the "worker bee" level before successful change can happen.

Q6: Why can't an organization wait until "Go Live" to do Change Management?

A6: Assuming that the project does not totally fail, waiting until Go Live to do Change Management work virtually guarantees the company a longer, deeper drop in productivity than necessary. In the absence of Change Management work prior to going live, necessary work process changes get discovered when employees try to meet work schedules using old work processes that the new system will not support.

Typically, workarounds will then be developed "on the fly" to get the job done with potentially bad consequences from this haphazard approach. Without a proper horizontal view of work processes through the organization, the workaround developed by one group can easily become the next problem for another work group.

In the absence of prior Change Management work, it is unlikely that the management and users will have a shared vision for the project. Support for the new system will be questionable if a common vision has not been developed within the company prior to Go Live. The lack of shared vision creates opportunities for dissension and disillusionment.

In the absence of a clear understanding of and adoption of changed work processes and performance metrics, employees will attempt to continue performing their old jobs to the old standards of performance. This is a normal reaction since the employees have been conditioned to this performance system for years. When the old performance measures are mismatched with the new system, the stage is set for frustration on the part of both the employee and the management. The instinctive reaction is to blame the new system, when the system may be performing exactly as it was designed to do.

The bottom line is that work processes have to get changed if the work is to be done. Changing those work processes after going live greatly increases the chance of a failed project. Assuming that the company dodges that bullet, the consequence for doing Change Management after going live is a much tougher transition for everyone, loss of productivity, and limited upside potential for the improvements the company was seeking when it decided to undertake the project.