Implementing ERP? Timescales you need to keep in mind

One of the hardest things to do, when planning an ERP project, is to establish realistic timescales. There is no formula for this because there are so many factors to consider, including the complexity of the system, the complexity of the organization implementing it, and the level of existing ERP knowledge and expertise already in that organization. Although this article looks at the problems likely to be encountered when moving too quickly, moving too slowly can also cause problems because of:

• management turnover. Big Tier 1 systems can take several years to fully implement. During that time, new managers will arrive with different ideas about how they want their departments to run, and differing ideas about what they want from a new system,
• implementation team turnover. If the project goes on too long, some team members will inevitably move on to new jobs, perhaps in new companies and, as with management, new people will have differing ideas,
• new features and new functionality will get introduced into the new systems and it will range from difficult to impossible to prevent the implementation team from reviewing these new options and incorporating them into the proposed ways of working, even though this will often mean rework, and
• inertia becomes a habit. When the projected go-live date is too far in the future, there will always be the temptation to put off doing things when other tasks appear urgent or important. And some people will enjoy working on a project where they only have to demonstrate progress and not results.

But, if taking too much time to implement an ERP system causes problems, rushing them is equally wrong. There are a number of reasons why companies make this mistake. One is that they perceive the demand for a new system to be urgent. Whether that urgency is real or imagined, the truth is that when organizations leave the implementation of a new system until it is urgently required, they usually find that they have left it too late. Even a small company implementing a Tier 3 solution typically needs six months to do the job properly (for clarity; this is for a true ERP system and not an accounting system that is labeled ERP). Potential problems that rushing causes include: not taking sufficient time to source the best advice, choosing the wrong system, going with ‘as-is’ solution.

Bad advice

When implementing ERP, there is a lot to consider. Most companies have at least some staff who have experience of ERP, but experience of ERP is not the same as experience of implementing ERP, so good advice can be game changing. Unfortunately, selecting good consultants to work with is as difficult, and arguably even more important than, selecting the right software and many companies just select a general management consultant that they have worked with previously, or go for one of the ‘big name’ consultancies. History says that doing so doesn’t usually give the best results and, indeed, a Google search of ‘ERP failure’ turns up some very big names indeed. So companies need to interview every consultant who will be assigned to their project and to ask for, and check, their references. That can be an enormous task for a Tier 1 implementation using dozens or hundreds of consultants but the alternative is to have inexperienced or partially trained consultants on the job.

Choosing the wrong system

Other articles on this website give useful advice on how to write an effective ITT (Invitation to Tender) document, how to analyze vendor or SI (System integrator) responses, and how to manage vendor demonstrations, so this article will not get into unnecessary detail on these topics.

However; this process takes time and when companies decide, or feel compelled, to rush, doing things properly can seem unnecessary. First to go is often a comprehensive ITT; to be replaced, at best, by a few pages of high level requirements at little more than bullet point level, such as, “The system should have a CRM module; it should be multi-currency; it should have a reporting facility”, etc.

Frequently, companies bypass even this and just select a handful of vendors to take straight to the demonstration phase (an approach often described in the IT industry as, “holding a beauty parade”). The problem with this is that the people doing the demonstration can be expected to know their systems very well. They will know where their system’s gaps and weaknesses are (all systems have gaps and weaknesses) and they will be expert at concealing them. In these circumstances, some vendors will ‘deliberately misunderstand’ some questions and, in the absence of a detailed response to a detailed ITT, it is practically impossible to prove deliberate misrepresentation when it occurs.

Another problem that occurs is that a quick decision inevitably results in a focus on today’s problems because there is insufficient time to consider where the business is going to be in five or ten years and what will be needed from the system to help get it there. So, even if the chosen system satisfies current needs, in just a few years or even sooner, problems will start to appear and the gap between what the company needs, and what the system can deliver, will widen until eventually the company sees no alternative but to look for a replacement; and the cycle begins again.

So how can a company hurry without rushing?

Some elements of an ERP project cannot and should not be rushed. The importance of a detailed ITT has already been discussed, and cutting back on training is a guarantee of a disappointing and, at best, second rate implementation.

Whilst companies are usually wrong to select the first system they see, it is also wrong to see too many systems before choosing, because seeing too many just causes confusion. But they can quickly come up with a shortlist of options, not by picking ‘big names’ but by talking to their business partners. Most companies have both customers and suppliers of similar size, and most of these will be surprisingly willing to share their experiences. Truly independent consultants are also a good source of information but companies need to understand that all of the big consultancies have symbiotic relationships with one or other of the big ERP supplies and that can lead them to make recommendations that are not necessarily in their customers’ best interests.

One possible area for saving time is to choose a ‘tried and tested’ solution. This most frequently happens when a senior manager or CxO joins the company with experience of a successful previous implementation, and proposes that system for their new company. It certainly helps when a senior manager champions a new system but the company must assure themselves of three things before they commit. One is to check how close to ‘vanilla’ the system was at that manager’s company: if it was heavily modified, are those modifications affordable? Secondly; was it a successful system for all of the company and not just one department? And lastly; is it affordable? Many managers move from large conglomerates to smaller companies and start-ups, and having used a Tier 1 system without knowing its cost, perceive them to be a universal answer. In truth; a Tier 1 can be not only too expensive but too unwieldy and too complex for smaller companies.

Looking at the implementation phase; companies can sometimes compress the time line by bringing in extra consultants so that some activities that would normally happen sequentially can happen in parallel. Particularly with Tier 2 and Tier 3 systems, this can mean running multiple training sessions each day and, if some data has to be manually loaded, bringing in additional keying resource; always remembering that these people are unlikely to understand what they are keying (or the critical importance of getting it right) and that, in consequence, their work needs to be checked very carefully.

One last thought is that, when companies need an urgent solution frequently the need is being driven by just one business area, so the answer can be to introduce an interim ‘point solution’ to cover needs in that one area  until there is proper time to address the needs of the company as a whole. What companies should absolutely not do, though, is to introduce a relevant module, or set of modules from a large ERP system, with the intention of driving all other departments down that path subsequently. If they do that, then inevitably the needs of those other departments will not be properly considered and, although the needs of the initial business area will be satisfied, in the long run the majority of company departments will be running with a system that they feel no ownership for and which does not adequately satisfy their needs.

So, hurry. But don’t rush.