One of the hardest things to do during ERP implementation project planning 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:
But, if taking too much time to implement a 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 even a small company implementing a Tier 3 solution typically needs six months to do the job properly (a Tier 1 can take several years). Potential problems that rushing causes include:
This video provides some advice on how to define a reasonable ERP implementation timeline:
When implementing ERP, there is a lot to consider. Most companies have at least some staff who have experience of ERP, but the experience of ERP is not the same as experience of implementing ERP. Implementing it once is not the same as implementing it 100 times, so good advice can be game-changing.
Unfortunately, selecting good ERP consultants to work with is as difficult as, and arguably even more important than, selecting the right software and many companies and 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 failures’ 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.
Other articles on this website give useful advice on how to write an effective ERP request for proposal (RFP) or 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; the ERP software selection 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 the top ERP systems 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 experts at concealing them. In these circumstances, some vendors will deliberately 'misinterpret’ 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.
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 ERP 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 suppliers, which 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, can those modifications be replicated? 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 also too unwieldy and too complex for smaller companies.
Looking at the implementation phase; companies can sometime compress the time line by bringing in extra consultants so that some activities that would normally happen sequentially can happen in parallel. This can mean running multiple training session 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 best of breed ERP ‘point solution’ to cover needs in that one area until there is a 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 inevitable 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.