On Consultants and Employees and Change Management

From Consultant M's Blog
(http://blogs.ittoolbox.com/erp/implementations/archives/001245.asp)

ON CONSULTANTS AND EMPLOYEES AND CHANGE MANAGEMENT

A good mix of employees and external consultants is, in my view, essential for a good implementations. This project has a good balance between consultants and those knowledgeable in the business. We have a strong communication and participation with the actual user community who will be using the system once we let it loose on them. The users need to approve each step before the implementation team can proceed. This started with gapping, and continued with initial design, detailed design, etc. This will assure that nobody can come back during roll-out and say “we have never seen this” or “I have never approved this”. It is as much a safeguard for the users to ensure that they know what they are to receive in the end, but also for the implementation team and for management. Both can verify that the design had been approved by a broad user community.

The ideal balance between In-house experts and consultants depends heavily on management’s goal to re-engineer business processes, employees’ knowledge of the software system and the unique requirements of the business. By nature, each business operates differently. Most have distinctive business process that developed out of unique circumstances; many also have certain business processes that provide distinctive business advantages over its competitors. These are processes that a company should not change and where intricate knowledge is required that only in-house employees can provide. Neither of these processes will be provided by a standard software package – not even I2 or SAP.

On the other hand one needs to be open enough to allow changes in business processes to perhaps save millions in custom development. Over-development of custom processes can create a system that cannot be supported by the original software manufacturer and where software upgrades take as many resources as the original implementation. One must look at the individual software packages and examine how perhaps smaller changes in the business process could provide a compromise between the processes and the mechanism of the software and lead to major savings in time and cost of development. This is an area where general management as well as consultants can provide good inputs. Employees will always try to duplicate their old methods and procedures and, if they get the chance, will even duplicate the old Cobol or C++ screens.

Most importantly, one also needs to look at parts of the business process that are inefficient and could gain from process improvement. This may be difficult if the current employees, who also have to be convinced that the new software implementation is going to offer advantages, have to change their old ways and habits. This leads to a difficult subject of CHANGE MANAGEMENT. I have often seen a business following a methodology that was developed 20 or 30 years ago and is reluctant to adopt to the new ways. External viewpoints and experience are needed for this part of the implementation as well. (For example, a previous client was adamant about maintaining their procurement method because they knew of no other process and did not trust their consultants. This resulted in lead times twice as long as the industry average and in high inventory levels and lack of control thereof.)

Although I had said at the beginning that this project has a good mix between employees and consultants, the major issue I see is with the last point. The company is at times using business practices that seem to have carried over from pre-industrial times. The user community is not willing to look at today’s best practices approach and work towards a more streamlined and effective business management. The culprit is, I believe, the lack of a strong management leadership on the user community. It is impossible to have a good implementation and achieve long-term gains and improvements for the company as long as management is not convinced of the need for the new software and is not open to changing today’s business processes. And so, the implementation team is developing a software that is tweaked in each and every respect to match the current legacy system.

I have seen implementations where almost each and every transaction was customized or a new one created. In the end, the original software was unrecognizable. System upgrades or fixpacks that are offered by the software manufacturer can no longer be applied.

Unfortunately, this project sees a lot of “old methods”. One in particular causes me a lot of head-aches and I will spend the next blog talking about it – so watch for the next blog that will be deal with the topic “Managing suppliers”.

It is, in my view, essential to find a good balance between good or necessary practices of the “Old World” while using the chance to improve those processes that do not meet the ‘best practices’ approach. What I mean with that is that there are many parts of the business where the software needs to adapt to the business – either because of unique or cutting edge processes, because of an already efficient and effective way of doing business, or because of unique industry requirements. But there are often many other parts where the business is too lazy to change its methodologies to adapt to a more efficient (doing the right things) or effective (doing things right) method. This change, however, can only be done if you have the support of upper management driving the change internally and if you staff the implementation team with employees willing and open to change. It is much more than a simple system change, it may require changes in how the company is working with suppliers or customers.


M