RSMUS.comThe decision to do an ERP Implementation is daunting for many Clients and once the decision is made to proceed, Clients may not be sure what to do next. While each Service Provider will have their own implementation methodology, there are a number of items to consider regardless of what the methodology calls them. The following list is not meant to be exhaustive, but rather is a list of key points to consider:
- Project Organization – Having a clearly defined project organization and a clearly defined Client Team merged with the Service Provider Team are the foundation for a successful implementation. The Project Organization should have the following components:
- Project Sponsors – Client Executive, Service Provider Executive
- Executive Steering Committee –Client Sponsor, Client Executive Team, Client Project Manager, Service Provider Sponsor, Service Provider Project Manager
- Project Team – Joint ownership between the Client and Service Provider Project Managers with membership consisting of Project Managers and Key Users.
- Sub Teams – typically functionality oriented teams (i.e. Finance, Order to Cash, Production, etc.) with membership made up of Client Key Users and Service Provider functional consultants.
- Client Team – For most implementations, this is often the most difficult to put together because of the normal demands of the Client’s day to day operational needs. For the functionality being implemented, the people selected should be the best people with expertise in the business operations (day to day, month end, year end) related to the functionality to be implemented. Client Team members should be given time by the Executives to work on implementation tasks. While not always doable, the best and most efficient implementations happen where Clients allow Client Team members to work full-time on the implementation project while other Client personnel fill in for them temporarily.
- Expectations of the implemented system when live – Everyone involved with the project (Client and Service Provider) should know exactly what the system is expected to do once live and these expectations should be as detailed as possible. These expectations should be reviewed throughout the implementation so that adjustments can be made as necessary and then after Go Live. Examples of categories to consider:
- Increased Productivity
- Increased Profit
- A better Client Experience for their Customers
- Better Reporting
- More Data Capture
- Implementation Plan – This plan needs to be reasonable based on the availability of Client resources. Times when client personnel will not be available throughout the Implementation time frame should be taken into account (i.e – year end audit and taxes, physical inventory, etc.). Based on the project objectives, the plan should clearly define the timing of the major steps and deliverables for the entire project.
- Project Meetings – Not everyone likes meetings, but they do provide a forum for making sure that everyone has a voice and is on the same page regarding all of the implementation tasks and issues. Project meetings should always have an agenda planned in advance. At a minimum the following meetings should become part of the implementation:
- Steering Committee Meetings – at a minimum, these should be held monthly, but during the major activities of the implementation, should be held bi-weekly in order to stay on top of issues and decisions to be made.
- Project Team Meetings – at a minimum these should be held weekly, but during periods of high project activity, could be held twice per week.
- Sub-Team Meetings – at a minimum these should be held weekly, but during periods of high project activity, could be held twice per week.
- Implementation Room – Often called the “War Room”. Having a room that is dedicated to the implementation throughout the project helps keep people focused by having them away from their work space and their day to day operational responsibilities.
- Training – Training is a critical part of any implementation project. A Navy Seal was known to say “Under pressure you don’t rise to the occasion, you sink to the level of your training. That’s why we train so hard.” In the case of an Implementation project, this would also be applicable to testing.
- Operational “Table of Contents” – The creation of a “Table of Contents” for the major operational tasks for each functional area that will be impacted by the implementation is a way to have users start thinking about the business tasks and functions that they do on a day to day, month to month and year to year basis. The “Table of Contents” is merely a list of those business tasks and functions. This thought process can really be done any time, but should be completed prior to users getting into the system and looking to develop test scenarios. As Users do their day to day work in the current system, they should see if the task they are doing is on the list or not and then update as needed. For example, a “Table of Contents” list for an Accounts Payable person may look something like the following:
- Create Vendors in the system
- Log approved open payables
- Process payments
- Process miscellaneous A/P Transactions such as returned payments, vendor credits, etc.
- Produce periodic reports, dashboards, etc.
- Specific month end processes
- Specific year end processes
- Test, Test, Test – There can never be “too much” testing in preparing to Go Live with a new ERP system. While the Service Provider can test the system, it is critical that the new system be totally tested by members of the Project Team and Sub-Teams. This will help reinforce what was learned in training, but also insure that they are ready for the new system when it goes live. In order to test properly, test scenarios should be developed that cover all possible scenarios that were originally defined in each Functional Area’s “Table of Contents”. At a minimum, testing should occur as follows:
- System Testing – typically done primarily by the Service Provider to be sure that the system has been properly set up and is ready for User Acceptance Testing
- User Acceptance Testing – This testing is done primarily by the Project Team and optionally the Sub-Teams. The Test Scenarios should be used to test and then be tracked for passing or failing.
- Mock Go Live – This testing is done by the Project Team and optionally the Sub-Team and is meant to be a complete test of going live. This would include all data migrations, setup work for Go Live, etc. in order to insure that everything is ready to be live.
Following this methodology will go a long way toward ensuring success in your ERP implementation.
For more information about Microsoft Dynamics ERP and how it can benefit your business, contact our experts at RSM 855-437-7201.
