10 Tips for an Optimal ERP Implementation
It can be one of the most solid and effective investments an organization can make - but implementing an ERP system can also be nothing short of a nightmare, as unfortunate and battle-scarred practitioners the world over can testify. Get it wrong, and the consequences for your company (and your own professional standing) could be devastating. On the other hand, get it right and your star could shoot upwards along with your organization’s profits.
In an attempt to assist network members who might be contemplating the prolonged and potentially perilous project that is an ERP implementation, we turned to the experts to find out what advice they could give. And here’s the result: SSON’s Top Ten Tips for an Optimal ERP Implementation. Enjoy.
1. Do it for the business
Implementing an ERP system is a huge task that requires significant resources and a great deal of dedication right from the beginning - so, from the beginning, be totally certain that it’s necessary in the first place. This means making sure the implementation is driven by the needs of the business as a whole and not merely by those of individual departments or functions: sure, what’s good for those departments or functions might well be good for the entire organization - but that’s not an absolute given, and the consequences of pressing ahead with such a major project just to make life easier for certain parts of the business for negligible wholesale benefit could be disastrous.
"Even today I still see that the vast majority of ERP implementations are driven by IT," cautions Philip King, associate partner with Atos Consulting. "Often the objective is to get the system in on time and on budget. This is good, but often the business can be forgotten, and there is minimal bottom-line benefit. In best practice examples the business benefits of the ERP are predicted and measured, both in terms of efficiency and effectiveness, and business stakeholders are leading the governance of the project, supported by IT."
2. Perfect your business case
So you’ve thought about it long and hard, and you’re convinced this project’s good for the business: now you’ve got to demonstrate that to the decision-makers at the top of your organization. Even if you think getting the proposal passed will be a walk in the park, however, don’t skimp on the business case. An uber-compelling business case won’t just help lay executive concerns to rest; the very act of putting it together (and thus exploring fully the scope and potential impact of the implementation) might also throw up a few new ideas in terms of the needs and requirements of the business, as well as shining the spotlight on areas where you might be able to cut costs, or take steps towards further efficiencies in future.
"Especially in current times every investment in ERP will need to have a rigorous business case," says Philip King. "It’s tempting to squeeze project budgets to get an ERP or upgrade approved. A better approach is to look for what business benefits can be achieved by the new system, get stakeholder buy-in and ownership, and track and manage their realization. If senior executives can see the returns, they are more likely to ensure sufficient budget is available and protected."
3. Plan for the future
As those who’ve gone through the process can confirm, putting an ERP system in place isn’t something you want to do on a regular basis: so when preparing for what is after all a protracted and occasionally extremely costly process, it’s crucial to try to be as forward-thinking as possible. This means factoring in (as closely as is feasible, given the information to hand) the future state of the business. Is the company expanding? Are new processes coming on board, or existing ones changing, for whatever reason? While no-one’s expected to be Nostradamus, at the same time it’s going to lead to trouble if a system put in to cope with Organization 1.0 can’t cope with the 2.0 version…
"If required, it is important to plan any changes to the organization and to business processes," agrees David Turner , director at Unit 4 Agresso. "Any changes will need to be factored into the project delivery; the solution will be built with the future structure and business processes in mind."
4. Plan - fully and clearly - who does what, when
As with the initial business case, your project planning should be as comprehensive and as tight as possible (while still leaving the requisite degree of flexibility, of course). If everybody knows what they’re supposed to be doing, and when, getting those things done will be all the easier. And that includes reporting: it’s crucial you outline the conduits of crucial information right from the off, otherwise you run the risk of becoming blind to potentially critical developments in the project simply because nobody’s certain who should be bringing them to your attention.
"Before starting agree a feasible plan detailing, when, what and who," urges David Turner. "Ensure the business case, documented strategies and business process requirements are reflected correctly in the planning and project delivery. Agree a project reporting process that can be used by the project team and business. It must include project status, budget management, risk and issue controls and any change control. Ongoing stakeholder management is very important, especially on longer projects. It is important that you agree any project tolerances with your project manager. This will need to include changes to budget, resource and time-line. If you do not agree project tolerances you will either have all issues escalated or you may only see issues sometime after they have occurred."
5. Allocate the right people - and enough of them
If you know what needs to be done, you should know how many people should be doing it - right? So far, so sensible - but then perhaps the company has a tough quarter, and maybe the budget starts getting squeezed a little, and maybe someone who should know better thinks you might be able to ‘encourage’ a smaller team to do the same job… Be resolute that the job requires sufficient resources in order to be done properly - and highlight the possibly catastrophic consequences of making short cuts here in particular. Furthermore, make sure the people you’ve got on the job are more than mere heads to be counted: you want top-quality staff on what is after all a vital task with very broad and long-term ramifications.
"Have sufficient quality and quantity of project resources," recommends Philip King. "Sounds obvious but it’s often the biggest issue – how to get people away from the day job. And of course you need the ‘A team’ for major ERP implementations. Organizations do use external resources – temps, contractors, consultants - but it’s important that a new system is owned by the organization itself. So consider backfilling your own resource to get them on the project as well as hiring additional supplementary resource for the project itself. And once people are on the project make sure they stay there as long as necessary. New systems projects need to be seen as career-enhancing, so it’s key that people moving off the project are looked after, otherwise no one will volunteer for the next one."
6. Pick the right partners
Your internal resources aren’t going to be the only ones working on this project; the "temps, contractors, consultants" mentioned above are going to play an important role in bringing this project to fruition. Therefore it’s critical that you’re confident you’re working with the right people - and that doesn’t just mean people your team are happy to go out for beers with on Friday evening (although it is obviously important to create comfortable, trusting and mutually respectful relationships - after all, you’ll all be seeing a lot of each other). You need to find partners who can demonstrate the ability to work both with and for you at all stages of the process - while at the same time bringing their expertise to the table at a reasonable cost, of course.
"Ensure you have selected the correct implementation partners," David Turner recommends. "It is important the software vendor is represented correctly on the project. You will need to get the correct balance between vendor and internal resource. This will help with project ownership and on-going support of the solution."
7. Meet regularly - and purposefully
Jeopardizing an ERP implementation - or any project, for that matter - because of a lack of communication with the project team is a sin so heinous there’s a special anteroom in Hades set aside for the guilty. Amazingly, though, it does happen. It’s imperative that meetings are regular - and just as imperative that they’re valuable. There might still be some value in meeting for the sake of meeting (ensuring familiarity between team members, providing a forum for debate even if on that particular day there doesn’t seem much to talk about) but it’s immeasurably more valuable to prepare a worthwhile agenda for each meeting and cover every aspect of the project systematically over a series of get-togethers.
"It is important to meet regularly with the project team. The project team will require ongoing support from the business. This will include managing and delivering any business changes and resolving any issues escalated. Managing the completion of each phase of the project and understanding any risks before the next stage/phase starts is important. If significant issues are not resolved correctly, the outcome could be more costly in terms of overrun," David Turner explains.
8. Remember to allow adequate time for testing
Even during the most favorable of economic climates there’s an understandable pressure on implementation teams to keep timescales as tight as possible. Operating under the current recessionary shadow means that pressure has been turned up to 11 - time is even more money. However, hurrying through an implementation without leaving enough time for testing is effectively mining for fool’s gold, in the sense that the consequences could prove much more costly than the time spent wisely troubleshooting and stress-testing the new system.
"Project management is fixated on the live date; the design and build is behind schedule. What happens? The testing period gets squeezed. It’s important to allow enough time in an ERP implementation for testing – systems, performance, user – in sufficient cycles and with enough time for any rework," Philip King warns.
9. Focus on data quality
The road to hell may be paved with good intentions, but the byway to ERP hell is definitely paved with dodgy data: it’s impossible to overstate the importance of ensuring that the data to be fed into the new system is as clean as possible, otherwise you’ll end up with the equivalent of trying to fly a fighter jet on crude oil (with, possibly, similar consequences for your hitherto-dazzling career)…
"A new ERP system brings a great opportunity to clean up the old data," says Philip King. "And the new system will only be as good as the data in it (garbage in, garbage out?). ERP systems in particular rely on the data being right first time to drive the effectiveness of cross-functional processes. So a good tip is to make sure that sufficient time and effort is put into to data cleansing and migration – it’s dirty work but someone has to do it!"
10. Ensure thorough documentation - and review - at handover
When everything is in place and ready for go-live, you and your team might be tempted - and understandably so - to celebrate a job well done. But all your hard work will be for naught if you don’t give the wider organization the necessary understanding of how to keep the system running once implemented. It’s crucial that you document in as much detail as possible the structure of the new system, and instruct the business in how best to operate and maintain it. For one thing, many of those who worked on the implementation will hopefully be moving on to bigger and better things within the company and won’t be on call forever to help with enquiries that new users - or anyone else, for that matter - will undoubtedly have. This is all the more important when considering future needs: when it comes to expanding or extending the system, in the absence of the original implementation team only thorough documentation will serve to avoid deep, deep trouble down the line. It’s also important, for similar reasons - as well as to assess the overall success of the implementation - to have a thorough review of the entire project before those responsible for it go their separate ways.
"When the project is delivered to the business you must ensure you have delivered through the project team (many via internal resource) sufficient knowledge and documentation for the business to manage the daily running of the solution and understanding what can and cannot be changed... The project team will typically deliver the ‘platform for change’. It is typically the responsibility of the business to ensure any necessary business changes are complete that point to benefits in the business case. A post-project review will allow a formal view of the project success against the business case. This review should also include your software vendor," concludes David Turner.