Now, let’s be clear I am not saying that you should not examine your business and document the requirements but let’s treat it differently and think more about higher level organisational goals. You should prepare a succinct document that focuses on things like:
Once you have prepared this you are ready to start looking for systems and implementation partners. Do you research online and shortlist no more than 3 systems? If you have more than 3 on the list it will just be confusing and you will forget what was in each system. There is a huge amount of information on the Internet. Watch demo videos, download datasheets, read up and generally get a feel for a system long before you engage in product demos. Look for systems that have case studies in your industry. If there have been successful projects for similar businesses to yours, the chances of success are significantly higher for you. Especially if you use a partner that really understands your industry.
Once you have selected 3 systems you then need to think about how you would like it to be implemented. Do you want to work with a partner, or go direct to the software author? There are pros and cons to both, but the key thing is to find someone who understands your sector and has references to prove it. Also discuss the project methodology and if they are not using an agile approach then be careful. A good system implemented by a bad partner will be a bad system to live with! The reality is that partners make their money through their services so are inherently motivated to look after you and build long-term relationships with their clients.
The best ERP projects are based on a trusted partnership approach. The devil is in the detail on these projects. You have to accept that you can’t seek confirmation on every requirement right from the start and then hold your supplier to delivering on that scope. These are complex projects which change during the implementation. There has to be a partnership approach and shared goal to get the system up and running to meet the original goals as set out in your requirements document. This happens best when teams work together with flexibility on both sides. An agile project approach, that accepts that changes will happen as the partner learns about your business and you learn about the system, is essential. If you treat your implementer as a supplier and beat them up every step of the way you will end up with a system that does the bare minimum, not one that has been lovingly crafted by people who genuinely care and want to work with you. It works both ways, the implementer must be flexible, understand and deliver when a requirement is essential and outside the normal scope of the system. At the end of the day people buy people and it works both ways. Always take up references from similar businesses and if they can’t supply them ask yourself why not.
You need to be clear how much you are prepared to spend on a new system. This should be based on the ROI you expect to receive over the next 3-5 years. Your budget may change as you learn more about the systems, but do set one, so you have something to work to. You don’t want to waste your time looking at something which is way over budget.
Invite prospective partners in to conduct a discovery meeting. The purpose of this meeting is to start to understand how the partner works and their experience levels, and to get some more detail about the system. This is not a demo of the system or a full requirement gathering workshop, but a chance for the partner to discover in more detail what your requirements are and for you to assess how they go about getting this information from you. The partner can’t effectively demo the solution or give you a budget to work to until they understand your business to some level. There is no point sitting through hours of demos on a generic system which is not tailored to your business. Modern ERP systems are huge and complex and they need to be configured in the right way for you to truly see their capabilities.
Following the discovery meeting invite partners back to demo the solution to you. This should be a tailored demo to your business. Don’t expect to see the system exactly as it will be implemented for you as the partner will not know or understand all your requirements at this stage. However, you should see a system which is able to run your business and help you meet your goals. It may not be polished and refined at this point, but that will come in the project. It is important to understand how the system is built at some level. I’m not suggesting you inspect the source code, but try and understand configuration options and what is possible with further configuration. Don’t be afraid to ask for further and more detailed demos if you are not satisfied with what you have seen and need some further clarification. However, do be realistic about what is achievable before you sign the order.
If anyone tells you data migration is easy they are lying. It is always a tricky process particularly if you are changing things like your chart of accounts. The best advice is to migrate as little as possible and keep it simple. Make sure your data is clean before you start. Forget trying to import part delivered orders with part payments attached for example. Just key them in as part of your training. It is unlikely there will be that many of them anyway. This is the advice you are looking for from your implementation partner, not promises that it will be easy and they will migrate everything for you. It won’t happen!
ERP projects take time to get right so you need to be realistic about go-live dates. There is nothing worse than a project that gets moved back several times. The users start to lose confidence and the pressure builds to go live with something that is not right. The best approach I have seen is to get to a point where you have a system you can use and roll it out. Then build on it and add more advanced functionality one piece at a time. This is where the agile approach comes in as the system will naturally evolve over time and the project team need to understand this. The users will therefore get to use the system more quickly and you get to see ROI.
Like it or not we are all resistant to change at some level. Your users may have a tough time adjusting to the new system so it is important that you consider your approach to change management and include it as part of the project. Your implementation partner should help with this by involving users through the project and working out some quick wins that deliver them a personal benefit. If it makes their lives better they will want to use it!
Once you have been through this process you will be in a strong position to make a decision on the best system and best partner to implement it. This is a long and complex process, and unfortunately there are no real shortcuts if you want to ensure you get your transformation project off to a great start. There are many ways to go about a system selection and many things to look out for. Much of it will be driven by your organisational culture. From my experience, by trusting and truly working with your partner in an agile manner and taking advantage of their experience, you will end up with a system that really works for you and in turn meets those end goals that were set out early on.