Over the past few years we have completed several re-implementations of Dynamics GP for our clients while several others are considering the same in favor or moving on to something else. Here are some reasons why they are choosing to re-implement.
1. Enable new revenue streams and growth strategies:
After completing a Dynamics GP implementation for a client in the early 2000s they recently changed their distribution strategy to include direct sale retail stores and have expanded the number of customer service centers. During the initial implementation, neither was part of their strategy or a design consideration. Their Dynamics GP workflow and integration customizations were not designed specifically to handle some of these new requirements.
We are now in the process of planning the re-design and implementation of some of their customizations. With this new design, as they continue to expand their retail and service operations, on boarding these entities will be as simple as populating some setup screens on which their workflow, subledger to general ledger integration, and other system features will rely. Long-term, as they continue their expansion, this will save them consulting services costs and make them more nimble.
2. Automate standardized business processes:
We spent a significant portion of last year re-implementing Dynamics GP for a client that was originally implemented in the early 2000s. Since, they had further evolved and standardized their business processes as business process improvement and SOX compliance projects had been executed. They evaluated their options and considered replacing Dynamics GP with a "Tier 1" system. Through that evaluation they found that Dynamics GP could handle their requirements just as well for a fraction of the cost.
The result was a complete re-implementation of an integrated Dynamics CRM/GP system with a new custom application in between to handle product configuration. The project was completed for considerably less than the estimate to do the same with a common "Tier 1" system with the same or better results. They now operate their business free of disparate Excel spreadsheets, countless hours of redundant and unnecessary data entry, or years worth of hard coding implemented to quickly deliver on new or changing requirements.
3. Hodge Podge Syndrome:
ERP systems are "evolutionary" not "revolutionary". They grow, mature, and evolve over time as existing requirements are refined or more clearly understood and new requirements become known. As this happens new functionality in the form of 3rd Party ISV Products, new modules or integrated technology, and custom developed solutions is implemented. This is a common best practice that most often produces very good results.
Over time, if continuously reacting to an ever changing environment by implementing the first solution that appears to plug a GAP as quickly as possible, at the lowest possible cost you may end up with a variety of heterogeneous systems that don't integrate well or truly fit your requirements. Common results of this approach include business rules hard coded into queries serving reports and a myriad of patches that have turned your off the shelf solution into a custom solution.
Taking the time to carefully and proactively consider new requirements and match them to the best available solution with consideration for how it interacts with the existing environment will prevent this problem. If you don't, you may be sacrificing long-term continuity for short-term results.
4. The "vanilla", "out-of-the-box" approach left you with an incomplete system:
While "vanilla", "out-of-the-box" implementations are less costly and completed more rapidly than full scale deployments they are often incomplete. This is more commonly true for larger organizations. Typically, customers assume that they can simply follow-up Phase I with future phases to layer on additional functionality. This is not only true but is considered a best practice approach. However, if you don't plan for future phases while designing your initial implementation you could be left with many GAPS to fill later.
If those GAPS are not few and far between you might be left with a square peg/round hole scenario in which you are consistently working around design decisions made without consideration of the future functionality required. This is another situation where the software, if designed and configured around all of your business processes and requirements, will likely fit well. If you do take this rapid approach with your implementation make sure to consider any known future requirements in your design to ease the implementation of that functionality later.
5. Your initial implementation just wasn't successful:
There are many reasons why ERP system implementations fail. Inadequate requirements definition, inadequate customer and/or consulting resources, and unrealistic timelines or expectations are among some of the common reasons. Typically, the primary driver of an unsuccessful implementation is not the software itself.
Often, unsuccessful implementations can be salvaged. However, if the foundation is bad then you might be better served starting over. Of course, now you would have the luxury of hindsight to determine why the initial implementation failed and correct that before starting over. I would recommend you start by discussing this with your partner who has obtained the institutional knowledge to best ensure your success. Of course, if they were the problem you might consider a change.
In summary, don't assume that changing ERP systems will solve your problems or get you where you need to go next. You could very well have already purchased, many years ago, the ERP system that is best suited to run your business for many years to come. Whether you are experiencing some sort of pain or simply have a new ERP strategy to implement I recommend you consider all of the factors involved in delivering a world class ERP solution and take the steps necessary to prevent the problems you might have to react to later.
