How to get an ERP implemention right

Enterprise Resource Planning (ERP) software forms the basis of decision-making processes within a company. B K Khaitan enumerates on safeguards to be adopted at various stages while implementing an ERP package

In my previous article published in Express Computer, dated May 5, 2003, I talked about ‘How to evaluate and select ERP’ with more emphasis on my company’s experience in the evaluation process. Correct evaluation of ERP is only one step in the right direction in implementing ERP. There are other critical areas which need to be looked into for successful implementation. Let me first analyse why ERP has failed in organisations in the past and what lessons (see table: Lessons learnt) do we learn from the mistakes made by others.

Correct evaluation of ERP products and implementation partners can mitigate some of the risks of failures, but not all. We shall concentrate on those areas which cause failures in spite of selecting the right product and implementation partner.

Inadequate resources deployed for implementation

In most companies where ERP implementation has failed, it has been observed that key users were not deployed for implementation. Even in those cases where they were deployed, they were pulled out of the team as and when required. In some cases, the skillsets of people deployed were not up to the mark, with the result they could not contribute much in the process. In some cases, the responsibility of implementation was left entirely to the IT team and functional specialists did not participate in the implementation. Selection of the implementation team for ERP must be done with extreme care. Since implementation takes anywhere between 6 to 12 months, depending on the scope of implementation, the team members must be available full-time and must adhere to the time schedules of each milestone fixed.

Lack of training among employees is another area which slows down the implementation process. A comprehensive training programme should be organised to educate end users of the functionalities and features of the product and also the discipline required to feed transactions.

Poor change management

ERP brings about a change in the business process with wide ranging implications in job profiles and functional relationship between workers, supervisors and managers. As a result, organisational structures may undergo drastic change. Some employees may have to be relocated, some may be transferred from one department to another, some may be laid off, some may be promoted. This change brings about psychological fear among employees and they resist change and block the implementation process. It is therefore necessary for management to anticipate such issues and be ready with possible solutions during the implementation cycle. It is imperative that the top management assume responsibility and drive change management throughout the implementation cycle. Unfortunately, the top management does not involve itself enough in change management because their perception is that once the ERP package is selected and the investment made in hardware, software and networking, their responsibility is over. Top management has to get involved in the review meetings of the steering committee and resolve any issues escalated by the core team. They need to use a carrot-and-stick policy to discourage employees from resisting change.

Implementation methodology

Team selection

Steering committee
The steering committee should comprise key decision-makers headed by the CEO or the project sponsor. The purpose of the steering committee is to meet periodically, preferably once a month, to discuss the overall status of the project and to resolve any issues relating to scope, timings, resources and cost, that may affect the project from the implementation point of view. The size of the committee should be kept to a bare minimum so as to conduct business in the most efficient manner.

The project sponsor is the most important person who should undertake the ownership of success or failure of the implementation.

Core committee
Core team members should be drawn from locations where the relevant process will be implemented. Members of this team should possess adequate knowledge of business processes and business issues faced by the company. The IT team should be made a part of core team to provide technical support. The size of core team should be typically between 10 to 15 people. Core team members should be taken out of their normal routine work and should be dedicated exclusively for implementation.

The core committee should be headed by a project manager. The project manager should have cross functional knowledge of the business with some exposure to ERP implementation. His responsibility is to make sure that project milestones are achieved as per schedules fixed. He has to assist in resolving cross functional issues, ensure that the network, hardware and infrastructure are provided as required and are maintained as per project standards, and escalate critical issues to the steering committee for suitable action.

The project manager should be a senior business manager from the main line of business. the IT manager should assist the project manager in project deliverables. Under no circumstances should an IT manager be made project manager, or else the project will be looked upon as an IT project and is doomed to fail.

The quality leader, who will be one of the team members, will audit the project during the implementation cycle and provide management with visibility as to whether the project is adhering to established plans, standards and procedures.

Project deliverables

Project planning
It is necessary to prepare the entire roadmap of implementation with milestones fixed and resources identified from the client side and the consultants’ side to achieve milestones agreed on by both the client and the consultant. A contingency plan should be made and kept ready to tackle unforeseen circumstances which may hamper or delay the implementation process. In order to speed up the implementation process, standard tools developed by implementation partners should be used.

Analysis of current business process

The purpose of this exercise is to prepare a detailed business blueprint and then to simplify the business process by identifying and eliminating non-value-added activities wherever possible.

Develop target process

The target process is the ‘would be’ process and is an improvement over the existing process.

Key users are the best people to develop this as they have the expertise and know-how of the business process and issues of the industry in which they are working. It is for this reason that key users identified for the implementation team must possess the necessary experience to be able to contribute significantly in developing the ‘would be’ process. The blueprint of the existing business process would be the base for developing the ‘would be’ process.

Gap Analysis

The ‘would be’ process is to be compared with the existing process to be able to find out deficiencies in the existing process and to highlight the improvements in the ‘to be’ process in terms of efficiency and cost reduction.

Configuration and customisation

The ‘would be’ business process needs to be documented, describing each process flow in detail, with business rules such as credit policy, pricing policy and others, which will serve as a guideline for configuring and customising ERP modules. Customisation is time consuming, adds to implementation cost and is difficult to maintain. Therefore, customisation should be kept to a bare minimum.

Data migration

The IT manager plays a very important role in undertaking this activity. He should develop uniform code across the organisation, use it in consolidating data of all units to be able to identify duplicates and redundancy in the databases. Before the legacy data is migrated to the ERP system, additional fields not captured by the legacy system should be identified and plugged-in externally.

Training

Key users who are part of the implementation team should act as process owners and will therefore require classroom training as well as on-the-job training by the consultants. They need to understand fully how the process will be driven by ERP and how it is going to impact other business processes. Key users should then be used to train end-users in their respective areas.

Go live

Before going live, it is recommended that the entire system be tested using pilot test data and results be checked thoroughly to ensure full compliance of desired results. Post-go live support is required from consultants for a period of around three months after going live to be able to rectify teething problems that may surface during the live run.

The author is the CIO, RPG Cables. He can be contacted at bkay@rpgcables.com