When business owners and decision makers make the decision to replace their ERP software, they have made an important and tough decision. Regardless of the amount of talking and demoing and talking they have done with the various vars, they have taken a leap of faith that the next ERP solution checks all the boxes and will help their business get to the next level.
This leap of faith is based on the expectation that the software’s var has done their homework, asked the right questions and has presented a use case that shows a success path where the business will gain from such a purchase. But, mixed in with the hope and expectation that the new software will take your business to the next level, is the doubt concerning what if it doesn’t satisfy all the checkboxes. What do I do if the software doesn’t fulfill all my companies needs.
In this case, the stakeholders have to review the need and make the hard decision to modify the software or modify the business. In many situations, the requirement might be minor and based on need and the costs required to modify the software, the decision is to do without the required function. This is to modify the business to do without and come up with some other way outside the software.
In other cases, the need is so major, that the business will need to have the software modified to allow it to function in the manner that the business requires. This modification could be costly in terms of dollars and cents as well as the time required to spec out the change, program it and test it before placing it into production. But maybe, with the brainstorming of the software consultants and the users, there is a creative way to get the desired result using a slightly unorthodox process.
This could be by using a field or a program differently than how it was envisioned. This requires some out of the box thinking that can save the company time and money and could be the best way to handle a ‘missing’ process. Quite often, especially in the early going of using the new software, this is the best solution. The reason is that the users are not fully versed in the use of the new software and might just be falling into the idea that the old system did it this way so the new software should do it the same way. Sometimes, the old way is not the best way and it takes a little time and some creative thinking to determine that the old way is not the best way.
When bringing up a new software package with a customer, I like to recommend a moratorium window as a breaking in period where we don’t change too much of anything from the prototyping and testing period done prior to going live to ensure the changes we are making are the right changes. If after that waiting period, the problem is still there and the required processing is still required, then, a change needs to be made.
I am not saying that a major miss in terms of processing shouldn’t be addressed immediately, it just means that there needs to be a breaking in period that should be allowed to take place before going modification crazy. This way, we don’t let the old way become the new way just because it was the old way. This will result in a better solution as there will be less cost overruns, quicker timeframes to get up and running and people will talk thru the issues they are having to come up with better ways to use the software and will find out, the old way should remain the old way.
