You’ve made the decision to upgrade your ERP solution (see “Why Should You Upgrade Your ERP Solution?”) You have prepared yourself and your organization for some level of disruption (see “What Should You Expect During Your ERP Upgrade?”) and you are now ready to engage on the project. You have one final decision to make, regarding your deeper involvement in the project. The first installment of this upgrade series addressed “justification,” the second installment addressed general “expectation,” and here we will address “participation.”
Upgrade vs. Re-Implementation
The two ends of the upgrade project spectrum are often labeled as “upgrade” versus “re-implement.” In fairness, even the most aggressive “re-implementation” is still an upgrade at some level, and most projects fall somewhere in the middle. Even with that distinction in mind, it might be better to consider the following choice:
1. Treat the project as a pure upgrade.
Ask your partner to carry forward any and all customizations as they were originally written and introduce no new changes outside of what is available in the newer version. Aside from the changes introduced by the software publisher, the application, configuration and your workflows will be unchanged.
2. Use the project as an opportunity to make additional changes that will help the business.
Engage users, promoting more thorough solution ownership throughout the company. Engage with various department and process “owners” within your organization to understand:
a) What new pain-points have arisen since you initially implemented?
b) Do newer business processes call for different approaches within your ERP solution than you are using today?
c) Are there any gaps that were not addressed in the original implementation now demand more attention?
d) What customizations and unique application configurations (and reports) can now be discarded?
The first option, a pure upgrade, allows your team to mostly remain outside of the project until the testing phase. This approach works well if the application is lightly customized, internal constraints prohibit active user involvement in the project, or if the current solution does most of what you need – less some features that are already included in the newer version. It also tends to be much cheaper, provided the newer version of the software works more or less the same as today.
The second option requires a more formal project approach and significant involvement from your team. This approach works better if many current customizations could be left behind (i.e. clean up the database), if new functionality or workflows are justified, or if users don’t already “love” the current version of the solution as implemented. Analysis is often needed, either formally as a distinct project phase, or through ongoing dialogue as functional areas or customizations are considered for inclusion. This option feels more like an implementation, but with a little less deer-in-the-headlight response from your team. They already understand the solution, have a good feel for processes and are often better prepared to participate in the dialogue to promote change. Likewise, an upgrade is generally less threatening than an implementation as no one necessarily feels that their job or role is being threatened through ROI pressures.
Review the Software Itself
One final factor that may dictate this decision for you is the software itself. If the software publisher has reinvented the solution, partially or completely, it almost always makes sense to take the second approach. If you happened to read the previous entries in this series, you are familiar with the building-a-house analogy. If you ask a service technician into your home to upgrade an appliance, you probably don’t need to participate much beyond the initial purchase. The new appliance should do exactly what the old appliance did, but possibly with a few extra buttons. If the software publisher simply added some new bells and whistles to the solution but hasn’t materially reinvented existing processes or interfaces, then this would be very much like swapping out an appliance. You can sit back and relax as someone else makes the routine swap.
On the other hand, you probably wouldn’t ask a contractor to remodel an entire room in your home without some deeper discussion of the various options now available or without your continued participation in the project as it progresses. When the software publisher rewrites part of the ERP solution, your old workflows, configuration decisions and customizations will likely not apply the same way or produce the exact same results as today. Further, there may be significant, wholly new areas of the application not previously available. You will want to be involved to ensure that you aren’t carrying forward antiquated or invalid workflows and that you are taking advantage of any possibilities afforded by the newer version.
Regarding the second approach, strongly consider how much you should be involved and plan accordingly. Also, include other areas of the application that may be available today, but haven’t been put to use in the solution. Because everyone will be re-focused on the software, the project can also be used to shore up some training and revisit individual workflows for lost efficiencies. Discuss your thoughts with your partner and go deep into the dialogue. You should both walk away from that discussion with a clear understanding of immediate goals and concerns, impact of the publisher’s changes, cost of carrying forward any previous customizations, resource availability, and longer-term potential changes in business.
Your partner will always know more about the software, but less about your business. Your involvement, where justified, will help ensure the two are again in harmony when the project is complete.
Let us know if you have questions about which is the right approach for your ERP Upgrade.