Making ERP work for you

Guest Column

The past decade saw several boards facing the question of whether to go in for an enterprise resource planning (ERP) or not.

It was considered an expensive, tedious solution meant only for large organisations that need to manage their logistics. However, as time passed it became clear that small and medium enterprises (SMEs) cannot escape it.

The recent consolidation moves and developments in this industry are making lesser room for the best of the breed.

When Larry Ellison (CEO, Oracle) announced, "Best of breed is dead except in dog shows," the deduction is that an ERP will come branded, expensive and involving the risk of a single vendor. Can this risk and pain of implementation be mitigated?

An ERP solution, among other things, is a very expensive option. According to a survey, the average Fortune 500 companies have invested between $40 million to $240 million in the past decade for a typical ERP project.

The effort involved is of epic proportion and the vital return on investment (RoI) is, well, at best obscure. With the big implementations now almost over, vendors are hounding SMEs with offerings more suited to their taste and budget.

The financial investment required for SMEs may be lesser, but the effort, time involved and disruption in the normal working would be similar to that of the large organisations.

Most of the projects in the late 1990s in India and abroad were sold to the chief information officers (CIOs) and the boards, relying on the marketing expertise of the consultants capturing their imagination, promising the moon.

They were eventually implemented by the "school bus" of novice junior consultants with incomplete functional and ERP knowledge.

The projects became never-ending and most consultants and the client team members left midway for greener pastures, causing serious damage to the project.

The result was anybody's guess "" time and cost overruns; failed implementations; and lack of target set out to achieve.

Savour a few facts from the decade gone by:

Eight out of 10 ERP implementations worldwide overran cost and time targets by over anything between 40 per cent and 85 per cent (Forrester Research).

The story is not too different in India. A Gartner survey on Indian implementations pegged average cost overrun at 178 per cent; average schedule overrun at 230 per cent, and a decline in functional expectations.

Fifty-five per cent of ERP implementation overran on every sphere; 35 per cent were cancelled midway.

If the past holds a key to the future and if statistics do not lie, then ERP should have been long dead. Who would want to implement something as unsuccessful? And more so, why an SME that has lesser resources to spare, and maybe even lesser talent in terms of personnel? It should have been obituary time for ERP.

But it isn't. Even one success can spur a gold rush.

So, how does a CIO make his ERP a success?

Given the above facts, it is indeed a daunting task for a CIO and his in-house IT team (sans any ERP knowledge in most cases) to present a business case convincing enough for the CFO to take it on whole hog.

One approach could be to break the ERP cookie into "bytes" his team can chew and the organisation can digest "" a trend that has witnessed some success.

Divide the ERP as a project into manageable phases with deliverables that are outlined with more clarity. The financial and costing aspect of the project requires a closer look. And lastly, the so-called soft issues of change management and employee training come to the fore.

Give the methodology and approach its due. Though it is the first lesson in basic project management, it has been the most blatantly ignored one.

All major ERP vendors offer a roadmap. SAP calls its methodology ASAP; People soft has SPEED and so on. These are methodologies offering step by step process and project management.

It may come as a surprise, but most projects I have been involved with as a consultant allocated the least time to the blue print stage, thus resulting in a lack of clarity of objective and scope not only for the client but also for the consultant.

Requirements, functionality and reporting tools keep changing during the course of implementation. What was envisaged as a three-month job grows on to be a year-long project, much to the exasperation of both sides.

It is imperative to recognise the fact that even the best fit ERP has to be tailored and customised. The tailoring may be less or more, depending on the vendor chosen, the processes of the organisation and the intellect of the consultant.

Keep a tab on this additional tailoring.

Distinguish between the "nice to have" frills and the "need to have" seams.

Remember: frills are expensive to create and possess. Make sure you put a cap on the frills demanded by the line managers.

Have clarity of the deliverables down to the last "t". Rather than a vague process time-improvement objective, develop a case that outlines a before and after ERP scenario more clearly.

It is imperative, not only to understand your own process, but also the technology it would be mirrored on.

Have the best resources from both sides during the initial stages of the blueprint. If the deliverables are outlined lucidly with active involvement of the line staff, chances of a good implementation increase.

For example, in a payroll implementation, the printing of the remuneration slips in a particular fashion, along with the company logo and the location may be required to be taken up with the consultants initially rather than after the time and money estimates have been done.

Have a project manager distinct from the process owner, someone who has some hands-on experience on that package. He may be hired from outside the organisation.

Being familiar with the package saves the client from being at the mercy of the intellect of the consultant. This person is responsible for the eventual piecing together of the jigsaw that was broken up in the first place for convenience and clarity.

The pricing models of what used to be the Big Five had a major role to play in the failures of the projects and high levels of frustration among the clients.

While the ERP turned out a huge money spinner for the consultant, the client had little choice but to pay on an hourly basis for the goals of the project that were ill-defined and increasing.

With the time- and-material model of an ERP pricing becoming archaic, the trend is to pick up several stages of the project and link the delivery at each stage to the pricing. It is a good idea to mix and match between fixed costs and the variable ones.

Outline major deliverables and have a fixed fee at various stages of development. Don't let the implementation become as one happening in your neighbour's compound. Take active control over it.

Specify the roles and responsibilities of all consultants and employees, and link this with the terms of the contract.

Have a look at the employment profile of the consultants before they come to work for you.

And as the project draws to a close, there's training. This happens when the project is about to get over and thus, with little attention. The people who are going to work on the system participate in quashed versions of rapid action trainings only to spend the bulk of the time learning: A list of what the icons on the screen do? How to log off in three different ways?

Conduct end-user training in-house by an employee in command of the process and with knowledge of the product. Relating the two in the minds of the end-users is important.

Focus on the entire process rather than familiarity with screens and software alone. ERP is a different way of working, not just a new software.

The concept of "Train the trainer" works brilliantly. Prepare an in-house team before commencement of the project to deliver the training at various client locations. A threat with this approach could be that the earlier trained team leaves mid-way for greener pastures. However, this is a little cost to pay for successful implementation.

To conclude, the moral of the story, in the words of Sumner Redstone (CEO of Viacom): Unless it' s a win-win, you both lose.

The author is an ERP consultant with Siemens Information Systems Ltd. The views expressed are personal