It is incontrovertible that companies should do, themselves, as much as is possible of the work involved in their ERP or digital transformation (hereafter called DT in the interests of brevity) projects, for several reasons, including:
However, equally undeniable is that it is almost impossible for companies to have all the necessary skills required for a successful conclusion to the project. These skills may include:
Many organizations, especially the larger ones, will have some of these skills but none will have all, so a look at each of these areas will help to identify where external assistance is likely to be necessary.
Some companies are actually not interested in understanding ERP and digital transformation and what they can and, just as importantly, can't do. They just want a modernized version of their old system but, if we chose cars that way, we would still be driving Model T Fords. Implementing a new system is the best chance that an organization will have in years to review what it does, why it does it, and how it does it.
Organizations need to look forward; not backward. They need to consider doing new things, and doing old things in new ways and, in order to do that, they need to understand what ERP and DT can offer so that they can explore new possibilities. At the same time, they need to be realistic about what it can achieve and, although there are good books out there, most organizations benefit from input from people who have extensive and varied experience.
It may be that new employees can bring these fresh perspectives with them but just a few days of genuinely independent advice can help identify both opportunities and potential pitfalls for a fraction of a percent of the project budget.
The second area is a written specification of what the new system is required to do is essential. Firstly, it allows competing systems to be objectively compared and measured against actual requirements. Secondly, it sets the scope of the project and by doing so, limits 'mission creep', as anything that is not in the requirements spec is not in the project unless proper change management procedures authorize it to be there. Lastly, if using external consultants or system integrators to implement the software, it tells them (if properly written) clearly and unambiguously what they are required to deliver.
The keywords here are in the phrase 'properly written' because ERP salespeople are predisposed to answering 'yes' to questions about their software's capabilities and, even though the clever ones will not actually lie, they can often 'misinterpret questions advantageously'!
As an aside, some companies are tempted to amend and recycle previously used requirements specs but they should beware: many of these documents are badly written and totally unsuitable for the purpose, so copying a bad one is not a good idea.
When considering what the new system has to do, it can be difficult for some companies to change, especially the larger ones. Where even minor changes to processes and procedures can mean retraining very large numbers of people or operational disruption. But, nothing can change if everything stays the same, and new systems bring new opportunities so it is no bad thing to challenge the status quo.
Technology will have moved on since you last implemented a new system, some things that were impossible 7-10 years are commonplace today, and clumsy and inefficient workarounds may have gone from essential to totally unnecessary. We are all, to a greater or lesser degree, constrained by our experiences and so, if we haven't seen something done, it can be hard to imagine it being done.
Hopefully, new employees bring with them an up-to-date 'knowledge of the possible' but a review of possibilities at the very beginning of the project can be a small, but very rewarding, investment.
Many companies already have good project management teams in place and may not need much help in this area, but even they will benefit from a day or two with experienced external consultants. One major job of project managers is to estimate the amount of time that tasks will take and then build in contingencies to cope with unidentified tasks and for when things go wrong. Things will go wrong and, when trying to identify what is likely to go wrong, there is no substitute for having walked the path before – several times.
System providers and system integrators should be able to help but can be drawn to being over-optimistic to ensure that they get, and retain the contract. System integrators will make a case for providing project management, but it is rarely a good idea for external contractors to manage themselves.
For many years change management consultancy was, as best, a 'nice to have': something to put in the plan to bump up the budget but always the first thing to be pulled when costs had to be reined in. The main reason was that it was easy for companies to convince themselves that all that was changing was the screens that users were looking at: buyers would continue to buy, order entry clerks would continue to enter orders and accountants would continue to account.
All that was required, they felt sure, was some training and perhaps some work to make the new system look and feel like the old one. But they were wrong. No system is a carbon copy of the old one (and, if it was, there would be little point in changing it), so there will be different options, different routines and different ways of doing things. When change is under-estimated, some people can feel overwhelmed.
Experienced hands will have gone from perceived experts in the old system to complete novices in the new. Many will find that difficult; as can their less-experienced colleagues who have relied on them for advice and assistance in the past. On the other hand; allowing them to think that the change may be greater than they can cope with can make them decide to move on to less-threatening environments, with the result that the organization loses good people at the very time that it needs them most.
Good communication, clearly explaining what is going to happen and why, undoubtedly helps but, as with many aspects of ERP, talking in advance with someone who has trodden the path before helps to ensure that there are no nasty surprises.
All of the roles thus far discussed can, to some extent at least, be satisfied (or at least supported) by in-house resources but, for a successful implementation, detailed and extensive knowledge of the particular software being implemented is absolutely essential. The implementation consultants must know what the software can do, what it can't do, and what it doesn't do very well. Building up that knowledge takes a lot of time, as does developing workarounds to deal with gaps and with areas of the system that, although working, can be unnecessarily complex for some users.
This implementation consultancy can come from two places: Tier 1 systems are generally implemented by teams of consultants from one or other of the large management consultancies; whilst, with Tier 2 and Tier 3 systems, companies are usually restricted to choosing from amongst the ERP author's value-added resellers (VARs) or dealers.
For all companies, picking a good implementation partner is actually as important as, perhaps even more than, picking a good system. But not all consultants are as knowledgeable and as experienced in the software that they are implementing as the customer has the right to expect. Every implementation consultancy, from the biggest to the smallest, has consultants who are either new to the job or new to the software package that they are working with.
When a large team of consultants is working on a Tier 1 project, the weak and inexperienced consultants can be shielded by giving them tasks out of the client's gaze, where they can be coached and monitored whist, they build up their knowledge (albeit at the client's expense).
Things are more difficult with Tier 2 systems, which are typically implemented by small teams of consultants (perhaps one per business area), and even more so with Tier 3 systems, where frequently just one 'all-rounder' consultant will be assigned to cover all aspects. In Tier 2 and Tier 3, inexperienced consultants inevitably come into direct customer contact and so the risk of the client being given inadequate, or down-right bad, advice is very much greater.
Ironically, though, the problem can be easier to fix at these levels because companies generally have a greater choice of implementation partner and can interview competing partners, and even individual consultants, to ensure that the skill sets of those consultants match the tasks that they will be asked to perform: something that is impractical on a large project where dozens, or even hundreds, of consultants, will be involved.
There is another tactic that all companies can employ and that is to retain independent consultants to augment the team in areas where they feel that the skills of the primary implementation partners are insufficient. True; some implementation partners do not like this, but it's not their project and they are not the ones who have to live with the consequences of a bad or failed implementation.
In summary; there are a number of skills that are required for a successful ERP implementation or digital transformation and, although companies may well have suitable people on board to handle many of the tasks they will face, they may not have enough or may need a temporary injection of specific expertise in some areas.
Some will rely on just one consulting organization to provide everything from change management through to software-specific end-user training but history shows this to be a risky strategy because it puts the client in the hands of those consultants in an environment where the odds are stacked heavily in the consultant's favor.
The most obvious risk occurs when the same consultants are involved in both system selection and in system implementation. All of the big consultancies have very close relationships with one or other of the big ERP suppliers and consequently have built up very large teams of consultants, trained in implementing their partner's system. It is unrealistic to expect them to recommend a competitor's system, knowing that in doing so they will automatically rule themselves out of providing implementation consultancy: the big prize.
In the end, what is equally risky is having the implementation partner, or system integrator, provide both project management and implementation services because then they will be monitoring and managing themselves. It is in the customer's best interests that there are at least two sets of consultants involved, so that all-important decisions can be properly debated and, where necessary, challenged.
All good consultants should be able to work properly and effectively within a larger team, one that will include some of the client's own people as well as other consultants. If they can't, or if they don't want to, then they are not the right people for the job.
Before the contract is signed, all consultancies will be putting their best people in front of the client. But clients frequently find that, for all sorts of reasons, some of the most impressive consultants become 'unavailable' for subsequent phases, and their replacements are less impressive: a situation not improved by having to re-educate these new consultants about the company, its culture, and its needs.
Companies should always remember that they have the right to choose which consultants will be working on their projects: if the contracts they sign preclude them from doing so, they have signed a bad contract. Companies don't sign very expensive contracts without first having them checked by lawyers who have specialist knowledge of ERP and DT projects. Or do they?
If you want to talk more about The Role of Consultants in an ERP or Digital Transformation project, don’t hesitate to reach out. We are happy to be a sounding board along your digital transformation journey.
