Having overseen over 35 ERP implementations some things stand out as to what can make or break an ERP implementation. I've listed out the top 5 below that I've seen work based on my experience. If you'd like to discuss these or get more tips about what can be done better - please don't hesitate to email or call me.
Top 5 recommendations to ensure your ERP implementation is successful
Document your requirements and existing pain points but focus primarily on the important requirements: I know this may sound like a 101 of ERP implementations but we get so many ERP implementation requests without a document stating what the key business requirements are. In these situations, our approach is to go in and first document the pain points and requirements. If you just go into an ERP implementation without a clear definition of what you are trying to achieve you are going to fail. It is important you setup a baseline for what you want to achieve. However, ensure you don't go overboard with your requirements. Don't use this as an opportunity to ask for everything you've ever wanted. You'd just be shooting yourself in your foot. Keep your requirements focused to what will solve the pain and then as they come up list up your nice to haves but ensure the nice to haves are clearly marked. Ensure your requirements list meets a) Key pain points you have today and b) Core functionality you have today that you want to ensure you retain. While many teams do their requirements they only focus on pain points and what they need to change but often forget to document what works.
Robust Solution Design: Install, configure, and go! Unfortunately that almost never works unless you are a really small organization (less than 10 people) that needs a single user system. To make your ERP implementation successful you need a robust solution design done upfront. Seems obvious - but it is surprising how many ERP disasters we walk into that have no or very little design documentation. We often get questions about how much documentation. The answer is simple - 80% of your key scenarios. You don't need to document every scenario because you can improve your implementation as you go - however, you need to document your key scenarios especially those that you consider key to your business. Every business is a little different and you need to ensure you cover those nuances in your design. For example, when we implemented Dynamics AX for Ignify we wanted to ensure our cash receipts process for customer payments via check was a two step process (apply payment to customer but impacted asset GL is Undeposited funds as opposed to cash and on deposit of check credit Undeposited funds and debit appropriate bank account) while cash receipts for ACH and wire payments was a single step process (apply payment to customer and impacted GL is the appropriate bank account). Other businesses may do this differently and to ensure our implementation is successful we documented both scenarios as use cases with an appropriate solution to each use case. Validate the documented solution design back with your requirements. You need to verify that you addressed your key pain points well and with a solution that is significantly better than what you have today.
Strong Internal Project Management organization: Most customers spent a lot of time evaluating a variety of ERP solutions and picking up the right solution. Sometimes this period is over 6-9 months. In over 20 years of consulting - I've never seen a bad solution make a project go wrong. Most ERP systems out there as long as you pick a mature one that has been around for over 10 years provide fairly robust functionality. However, not putting the right internal people on the project can make a project or break it. Key to this is the project management you put around the project. The project management team needs to have teeth to be able to manage scope. Scope has a direct tie to budget, project timeline and risk. You increase scope and budget, project timeline and risk increase. Often stakeholders will increase scope without increasing budget or timeline which means the increase their risk of failure exponentially. If the project management team doesn't have the teeth and ability to manage scope and change then you will end up with a project that never ends and an ERP that is over-customized irrespective of the solution you choose. It is important that you manage scope well and be able to clearly mark out what needs to go in a first phase versus what can go in later phases and are nice to haves.
Test, Test and Test: Begin testing early and test often. Like flossing you must test every day once your system starts getting even close to final shape. And test with your best users. Don't put in sideline folks to test. You need to put your best users there and set expectations with them that they will find holes, gaps, and since you are in 'lab mode' - they will not find a perfect system. In fact set expectations that they should expect to find an imperfect system and it is their goal to work with your implementation partner to get it ready in time for go-live. Make your users key owners of the system and not just passive bystanders.
Train and then re-train: The best approach to training is to do it several times. Once is not enough. Three recommend points of training which Ignify follows are:
a. On Design: When you have a high level design complete in the form of a conference room pilot
b. Before test: Before detailed user testing so that users are familiar with the system and can test for scenarios specific to your business
c. Post go-live: After you have been live for 2-3 weeks go back and re-train. You will find the most questions at this stage and update your training documents to answer questions that come up that were not addressed in the training documentation. Then repeat this every 6 months.
How much training is enough? Ensure you have at least 4 hours of class room/trainer lead training + 4 hours of hands-on testing by the user and 4 hours of post go live training per user per module. That means a total of 12 hours per user per module in various formats. Ensure your internal team gets self-reliant to the point that they can own training documents and become a first level support within your organization. Ideally you want your post go-live support to be done by internal team members and if possible also your broader before test training also done at least in part by internal team members. Training others will be the best way your users will learn the system.