Why ERP takes that long to implement?

There is no doubt that ERP integrates all functions and takes care of the most organizational needs. It’s a comprehensive package and is designed to cater to companies of all sizes and  from various industries. Therefore to make this package run in any organization, one has to configure various parameters as per the defined needs. The package being complex it requires people with knowledge and skills to undertake this task.

Most ERP vendors have prescribed clear methodologies which are field tested at various companies across the world. If we follow these diligently we can be sure of success. The methodologies speak of several stages which include as-is process documentation, designing to-be processes, configuring testing, conference room pilot 1, conference room pilot 2, go-live preparation, go-live and post go-live support. It is therefore natural for ERP implementation to take that much time. It also requires considerable effort of people in the form of skilled consultants (from the implementation partner) and internal team members who are competent.

What’s wrong with this?

Times have been changing; companies now face a lot of challenges in the market and expect IT to help their organizations in overcoming them. However talking of six or eight months puts us out of sync with the management. I had to face such embarrassing situations more than once. In one of our management committee meetings, we had discussed and decided on a few strategic steps. The attention then turned to me asking for a solution. Knowing fully well the ERP processes, I asked for a few months. That didn’t go well and I had to face a barrage of questions. Though I explained the situation well, I did feel sheepish and sorry for being a drag in the company’s quest for progress.

I realized that implementation of ERP in its present form was unfit for the world of today. Whether for extension or upgrade when ERP takes months, its efficacy and effectiveness is called to question. My dilemma was for real and I wished that there was a solution which could accelerate this process.

Some solution

It was just last week that I met my friend, director of a well-known IT Services firm who mentioned to me about his plans of bringing in a software tool designed to help expedite ERP implementation and asked for my opinion. When I expressed my thoughts on this subject he was glad and asked me to share my views with the audience at the seminar that he was holding to launch this product.

I attended the seminar and shared my views, which was then followed by an exposition of the product features and demonstration. I liked the product and I felt that there was at last a solution that I was looking for. The tool called Rapid e-Suite; it sits on top of Oracle Business Suite and automates a lot of steps and helps simplify the process by making it possible to work in an off-line mode and then transfer changes to ERP. It has various other features like a knowledge repository, feature mapping for upgrades, the configurator engine, data migration, replication of instances, etc., which help in quick implementation and rollouts. Based on the roll outs in various countries, the company claims to reduce implementation times by over 50%. I am sure there would be other solutions that are available for different environments.

Final view

I strongly suggest that CIOs/ CXOs should look for solutions to implement ERP projects in much shorter time and help IT stay relevant in their organizations. The conventional way of implementing ERP solutions is unsuitable for the current environment in which our businesses operate.

Life of the ordinary

We often get mired in routine tasks and trying to manage day to day operations. We get so consumed with this routine (of keeping the lights on) that we forget the larger purpose that we came in for. Of the little time that we have, we try to add an application here or there and keep ourselves in business. Small successes keep us happy and we try to make big of the small stuff that we accomplish. But when we go out to a seminar and hear someone speaking of big achievements, we feel shy and hide ourselves in the crowd so as to become ordinary and nondescript. That sure doesn’t give us happiness – we wish we had done something good to talk about. Small projects and extensions to the current systems we do often, but it is about doing something significant which brings about a difference to the environment that we are in.

Doing something big

Let me delve on few ingredients of such an effort:

Identification of a requirement – One needs to scan the business environment and seek out a business need that could change the fortunes of the company. This would come through discussions with the business heads or the CEO. Define the requirement and the projected outcome.

Planning – No large project is ever successful without adequate planning. So what is required is to lay down all steps necessary, resources required, possible risks and fall back options. The plan obviously requires concurrence of those involved in the project.

Execution – Adopt formal project management practices and stay committed to its success despite hurdles that we come across. It is our conviction that will lead us through.

Review post implementation – After the initial applause, do pause to take a look at the impact that the move has created and whether the project has actually achieved what it set to achieve. There are many who miss out this step. The management or the end users are the real spokespersons and it is only when they speak out in happiness, we can consider ourselves to be successful.

Of courage and managing risks

However, doing anything big and significant requires courage. We have to break shackles, come out of our comfort zone and get ready to strain ourselves for a big battle. Success however is not guaranteed and therefore the move tests our risk taking ability. Low risk entails small rewards and greater the risks, larger are the gains. We take what is called a calculated risk i.e. be conscious of the pitfalls but prepare well enough to tackle them.

I have at times during my career refused to take the beaten path and embarked on some big ventures against the usual advice of colleagues and vendors. For example, doing a big bang ERP implementation, going ahead with supply chain automation even when there were very few examples of other companies doing so in our industry, attempting digital assets management, etc. The projects carried risks no doubt but when we succeeded all others wanted to be a part of it and claim that they also contributed.

I initiated the discussion citing a few issues that we had faced as CIOs in some of the implementations. People from the CIO assembly agreed that ERP implementation should not be termed an IT project but should have adequate business representation.

Amongst other requisites, the role of the project manager (PM) is one which is critical for a successful run of the project. In most cases, it is the CIO who is one of the main initiators of the move towards ERP, and once approved, he is automatically assumed to be the one to take on the responsibility. The question posed therefore was whether this is the right move for organizations to make when starting an ERP project? Deliberations touched upon various points:

• Should the PM be from one of the business functions, say from finance, sales, operations, etc?

Though the general opinion favored such a move, there were apprehensions expressed about their inadequate exposure to IT and whether they would be able to understand, work out, or guide the team on aspects such as parameter configuration. There were no clear answers. The consensus, however, emerged on the point that selection of a project manager is a challenge since ERP covers more than one function.

• Is a manager from any specific function more suitable for this role than others?

Each of the functions was examined but the larger view veered towards the ‘finance’ function. Participants felt that since the finance plays a controlling role, is in charge of compliance, reports to the Board on results, and since the organization’s performance finally boils down to financial figures, there could be nothing better than a finance manager being on board as the ‘project lead’.

Surprisingly, people did not talk of the organization strategies, the goals of business, the need for transformation and business process improvement, which point towards a business-view of project and the need to go beyond the limited worldview of the finance function. I think we have to grow up to view issues form the management angle.

• Is CIO the best bet?

Well, you bet, the CIOs think so! They say the CIO is the only executive in the company who has an overview of the business processes across the organization since he is involved in automating them. They further say that a CIO is neutral and not function-specific in his approach, and therefore, has an edge over any other functionary. He also has an in-depth knowledge of hardware requirements, software functioning, and networks and therefore can manage the entire project better than any other functional manager. They feel that an IT head with a business understanding is an ideal choice for the Project Manager. A few questions however remain unanswered.

Need for a balance

But is the knowledge of business processes adequate to bring about fundamental changes to those processes and is it equivalent to understanding business? While we may say that the CIO is neutral, his technical orientation could lend a bias which may not be desirable. Knowing IT may not be a qualification essential to be a project manager, as the PM has the overall responsibility of ensuring success of the project.

Again here was a situation where CIOs were keen on holding on to their turf and not willing to let others play this role.

In my opinion, CIOs have to take a broader view and consider the matter from the organization’s perspective. The purpose of the ERP project should be to serve business, and therefore, the project should be led by a person who is most suited to bring about the desired transformation to business using ERP. The community, therefore, would have to move a little higher in terms of thinking and lay focus on business benefits that he can bring about.

Relevance of ERP
As a part of the series, we held an internal meet of CIOs a few days ago for a discussion on ERP implementation and its effectiveness in our respective organizations. About 50 CIOs attended the event. Since the subject was vast, it was important to decide the format of the meeting so that the desired objectives were met. Instead of presentations by a few members, we thought it would be better to place a few salient points for discussion by members.
These points encompassed all elements of the ERP journey, like establishing the need for ERP in the organization, formal definition of project objectives, evaluation/ selection of ERP package and implementation partner, project manager and the team, business transformation, etc. We thought of capturing best practices adopted by the member organizations.
The meet was conducted in a panel discussion format, but at the same time, allowing enough opportunities for all participants to join in the discussion with their views. I was asked to moderate the session.

Establishing the need for ERP
The discussion kick-started with the point – whether the need for ERP was clearly established in the organizations right at the beginning. Answers varied; some expressed their plan of taking ERP as the core application accumulating data from all other legacy systems for consolidation. For someone, it was his company CEO who, having seen it running at some other organization, opted for ERP. Some were clear that their companies needed financial reports and that led to the introduction of ERP. Some said that it was due to peer pressure and also the fact that other companies in their industries had ERP, while some others said that the objective was just to replace their old and creaking legacy systems.
I tried to elicit CIOs’ views on the business value of ERP and the role it can play to further the business of the organization, but didn’t find adequate appreciation from the audience about this being a genuine requirement or an admission that this aspect was left out in their scheme of things.

Laying out project objectives
The second discussion point was about the need for an organization to formally lay down the project objectives or their expectations from the ERP implementation. It was explained that without a clear definition of objectives, it is very difficult to assess the degree of success for any project. There are elements like business drivers, KPIs, or some measures that define goals for the enterprise.
The responses from participants ranged from saying that there was a broad definition to some small and insignificant measures. For example, one CIO stated that the objectives were set based on broad expectations spelt out by the CEO or some functional head during the kick-off meet. Some said that the expectation was to reduce manual entries, or for preparing final accounts from the system. Some said that meeting demands of compliance to IFRS was the need and some said that generating MIS was the need expressed.

Getting IT right
It was only towards the end that one of the CIOs got up to explain that their organization had hired a consultant to lay down KPIs for the CEO and further down to each functional head and that served as the document to drive the design of the ERP system. That was a significant statement and I thought that adequately explained this point and grand finale for the meet.
Discussions during the entire meet were intense and we thought it better to discuss a few issues in depth rather than running through many. To me, the meeting revealed one significant point: there is a need for the CIOs to understand the business value of ERP and IT in general. They need to focus on business outcomes and not limit their focus to operational matters. CIOs still have some distance to travel in spite of their assertions that they have already ‘arrived’.