Today, ERP systems are used by all businesses regardless of scale. Due to the high investment in ERP projects, businesses fear that they will fail. One of the ways to eliminate this fear is to create an accurate ERP project team.
All manner and size of organizations are implementing ERP today; from the very large conglomerates who are drawn to Tier 1 ERP systems through to, at the other end of the spectrum, small companies that are moving up from accounting systems and spreadsheets to their first ‘real’ system in Tier 3. In the middle are the many mid-size companies that make up the bulk of the Tier 2 market. They look at the veritable armies of consultants that are used to implement Tier 1 systems with envy, at at the single all-rounder consultants usually tasked with implementing Tier 3s with incredulity.
Project failure, though, is common to all three, even though only the big failures hit the headlines. But for every Lidl debacle, there are a dozen Tier 2 debacles and, for every National Grid disaster, a gross of Tier 3 disasters. So, regardless of the size of the company, regardless of the size of the investment, regardless of ERP system choice, all organizations share something: the need for an internal selection and implementation project team. The role of this team subtly differs across the spectrum but all have responsibilities in common, including:
- Specifying what the new system has to do.
- Assisting in the selection of a system.
- Performing a gap analysis on the chosen system to see where modifications to software or to procedures and processes are required.
- Being the prime contact for communication with and within their functional area.
- Managing the system integrators (SIs) and external consultants during the implementation phase.
System specification
Regardless of the size of the organization, the key to a successful project is a clear specification of what the new system has to do. Some organizations have processes and procedures which, whether for regulatory reasons or because they find change to be either daunting or downright frightening, they consider to be set in stone. Others positively thrive on change and, rightly, look at an ERP implementation as being the perfect time to re-evaluate both what they are doing and how they are doing it. Either way, it is much easier for the implementation team (especially the external consultants) to hit the target when that target has been clearly and unambiguously defined. The system specification actually has multiple functions, including:
- Telling potential suppliers what the system is required to do so that they can formally reply (and so that their responses can be written into the contract: see our ERP RFP guide for more on this).
- Allowing competing systems to be objectively evaluated.
- Allowing the project team to carry out a gap analysis.
- Limiting ‘mission creep’ once the project begins.
Smaller companies frequently neglect to write this specification but inevitably that decision comes back to haunt them when they later have arguments with their system provider or integrator about delivered functionality; or when the project runs late or goes over budget because the scope of the project drifts.
Large organizations, using teams of consultants, can be tempted to leave the specification to them. They do this for two main reasons: one is that they believe that ‘the consultants must know best’ and the second is that they lack confidence in their ability to create it. There is no doubt that good consultants can bring new ideas and can challenge perceived wisdom but, however good their advice, are they really the people who should be deciding how your organization should be operating for the next 7-10 years or more? Consultants should be advisors, not decision makers, and senior management should not abdicate their responsibilities. Even when consultants are used to map how the company operates, what is important to it, and to identify what opportunities there are for improvement; their work should be monitored, scrutinized and evaluated by the in-house project team.
Moving to whether or not the organization is capable of writing a good specification; it is perfectly valid for them to use consultants to advise how this can and should be done, but not to actually do it.
Selection of a system
The best way to select a system is to compare competing systems against the requirements specification. It might seem that the large organizations have the easier task because they only have a small number of Tier 1 systems to choose from but it’s not that simple. There are important differences between all systems and a large Tier 1 system is a very big beast to evaluate properly. Tier 2 and 3 systems, on the other hand, may have functionality gaps; some of which cannot reasonably be filled by modifications or workarounds.
Companies looking at Tier 1 systems can use selection consultants to analyze their needs and to make recommendations but they need to be very careful because all of the large management consultancies (as opposed to specialist selection consultancies) have very close ties to one or other of the Tier 1 providers. They have literally hundreds of expensive consultants trained in their partner’s software so, when asked to recommend a system, it is clearly unrealistic to expect them to be truly impartial: their first responsibility is to their shareholders so they are obliged to recommend the system that is best for them; especially when their implementation teams are short of work.
Smaller outfits, looking at Tier 2 and Tier 3 systems, face a different challenge because they have potentially hundreds of different options and they can’t realistically look at more than a small percentage of them. Especially if their knowledge of ERP is limited, they can be drawn towards taking advice on which system to choose from local management consultants whom they have worked on other things in the past. But doing so is not without risk, because many of these supposedly independent consultants have symbiotic relationships with local ERP system VARs and dealers: the dealer recommends the consultant and the consultant recommends the dealer.
The in-house team needs to follow-up references for both systems and consultants (not just the companies; but individual consultants as well) to ensure that the system chosen is the right fit for the organization and the best available within the budget.
Gap analysis
Even a Tier 1 system is going to have gaps in its functionality, or things that will not work optimally for all user companies. A major task for the project team is to identify these gaps and to evaluate them. Some weaknesses will need to be addressed but others may require a scale of software modification or development that cannot be justified. The team will then need the help of the software implementation consultants to develop alternative ways of working to alleviate the problem.
Even choosing one of the Tier 1 systems and modifying it extensively (and expensively) does not remove the need for give and take between departments. Finance might want accurate production costs but Production might want to minimize transaction effort by using back-flushing; Sales may want to streamline order entry but Finance might want to impose tight credit checking; Product Development may not want to release bills of materials until design is complete but Purchasing may need to order long lead-time materials up front. These are decisions that consultants can advise on, but they are not decisions that consultants can make; so the in-house implementation team has to be closely involved at every stage.
Communication
Communication in an ERP implementation is multi-directional; from the top to the bottom and up again, among team members, and to and from external consultants (one of the biggest challenges, when implementing Tier 1 systems, is getting accurate and reliable information from the system integrators: hence the need for an internal team that works with them closely). Some implementation team members may believe (and be encouraged to believe) that, when dealing with the rank and file users, it is sufficient for them to closet themselves away in the project room until it is time to unveil the completed solution, but the team needs to be continually communicating with everyone who will be using, or will be affected by, the new system because, if they are not regularly sharing information, they can be sure that the rumor mill will kick in to fill the vacuum. They also need to understand that, whilst it is both nice and necessary to communicate successes, news updates should also include information on problems encountered (with a clear message that they will be overcome!). This is particularly important when the gap analysis has shown up areas where new ways of working will have to be introduced.
Team selection
Particularly in smaller companies, senior management can be tempted to be their own department’s representative on the team. Sometimes this is possible and, in fact, necessary in very small companies, but usually, ERP takes more time to implement than senior managers should have so when senior management in mid-size and large companies involve themselves at anything more than at a steering committee level, something has to suffer. What usually happens then is that they delegate project work to one of their staff and attempt to micromanage that person. So the overall team meets to decide a course of action and the manager expects a right of veto if they subsequently disagree. If the CEO allows this to happen, the other members of the team soon realize that having meetings and making decisions is a waste of time. Progress then grinds to a halt very quickly indeed as the team fragments.
So managers need to select members of staff who can dedicate sufficient time to the project to ensure its success. In a very small company, implementing a Tier 3 system, that might be a part-time job for several months but, in a large company implementing a Tier 1, it will be a full-time role for several years. And that is a problem because the best candidates for the job will be the ones that managers least want to release. They want their best planners planning, their best buyers buying and their best accountants accounting. But the project team will be determining how the company operates for the next 7-10 years or more, and that really does mean that it should be composed of the best of the best. Build a second rate implementation team and expect a second rate system.
But now there is a problem; because it is rare for all the skills needed within team to already exist within a company. Yes; the knowledge of how the company works will be there; and the knowledge of what the company is trying to achieve can be there also. These are essential, but a manufacturing company will primarily have its skills in manufacturing, a construction company will primarily have its skills in construction, and an educational establishment will primarily have its skills in education. True; they may have some people who have previously been through an ERP implementation (possibly even a couple) but does that make those people experts? It is simply not realistic to expect them to be.
There are, of course, good, informative and valuable books out there (and buying them for the team will be a very cheap investment) but books and courses can only go so far. So a major responsibility for the Project Sponsor is to work with the Project Manager to identify weaknesses in the team (i.e. knowledge gaps) that need to be addressed. As a major role for the team will be managing the SIs and implementation consultants, taking their advice on how they should be managed is not an optimal approach; especially as this assistance will be required before a system is even chosen.
So a better approach is to engage an independent ERP consultant (not a general management consultant) who has extensive and demonstrable experience of consulting on ERP implementations. This consultant’s role will vary according to the size of the project and the skills that already exist within the company (for example; large companies may well already have project managers on the payroll whilst smaller companies frequently will not) but will include advising on the writing of a requirements specification, advising on system selection, and, very importantly, on how to manage the SIs and implementation consultants to ensure that they are always working in the best interests of the client. In smaller companies, this may be a part-time role that finishes with the selection of a system but, in larger organizations, it may be much more and might indeed cover the whole lifetime of the project.
One last thing to consider is that, at intelligent companies, the team is not totally disbanded at the end of the project. By that stage, good people have learned a lot about the system and about how the organization works. They make a terrific ad hoc ‘task force’ to look at emerging problems and opportunities that the organization will undoubtedly encounter. Properly used, they can continue to make a big difference long after the project has been put to bed.
