Observations on what to avoid when implementing new business (ERP) software.
Having successfully installed many cieTrade business software solutions over the years I’m often asked by new clients what they can do to help ensure a smooth transition from their old system and minimize potential problems. While the answer partly depends on their particular circumstances and specific business requirements, we’ve also repeatedly encountered a few common problems that can lead to frustration and delays, potentially impacting the success of your business software project. Here are a few situations you should look to avoid.
1. Weak support from management.
Your stakeholders might have given the nod for new business software, but without a real commitment or lukewarm support, it’s nearly impossible to have a successful transition, especially in the absence of any motivation or incentive from operations or accounting. Before starting any software project, your management team needs to effectively communicate a mandate for change and take ownership of both the decision and the chosen solution.
2. Not having a strong project lead.
Every software project involves numerous tasks and decisions that will need to be coordinated between different parties, many of which can have a profound effect on your business. Choosing someone that understands your operation and that can work effectively with the vendor not only makes it easier to gain everyone’s cooperation, but also serves to streamline the entire implementation process. Otherwise, no one thinks it’s their responsibility to prioritize project tasks and the leadership role often falls back on the vendor. Having a strong internal project coordinator (or what we often like to call a “hammer”) is the single most important thing you can do to help ensure the success of your project.
3. Forcing the new software to work like the old one.
No one’s comfortable with change. So it’s no wonder there’s a tendency to cling to established procedures and operating silos and then force them upon the new software system. The problem is that by doing so you also sacrifice the advantages of the new solution and, in many cases, actually end up creating workarounds or redundancies simply to mirror how things were done before. While it may require some new thinking or changes in workflow, it’s important to understand and embrace the new solution and not simply recreate your old system.
4. Not being engaged with the training & implementation.
Without designating someone internally to drive the implementation project, it’s unlikely that anyone else will take the initiative to learn the system or identify business requirements (especially with documentation). Your vendor may arrange training days and encourage people to “practice” with the software but in the absence of any accountability, it’s doubtful that it will be a priority. As the start-up date approaches there’s typically a “mad scramble” to quickly learn the system and address any missing requirements. Although the resulting problems can usually be overcome, it will come at the added cost of stress and pressure on your operation that will serve as a wake-up call for what should have been done much earlier. If nothing else, you can always push the start date back.
5. Not understanding your business needs.
Clients usually have a clear idea why they need to introduce business management software. Less common is a having a good grasp of the specific requirements that the software needs to meet or even a consensus on what those requirements should be. Most software vendors understand this and are usually prepared to help mediate solutions. However, starting the process without any consideration of your specific business needs will put a lot more pressure on the vendor and can easily extend the implementation timeline by weeks or even months while it’s sorted out.
6. Running in parallel.
We try to discourage clients from running their existing program in parallel with the new software because it’s an unproductive exercise since your working with established software products that don’t need to be “tested”. By working in both systems, your operation is asked to do double the work while knowing that you aren’t really invested in the new system yet. If they’re too busy or encounter problems that need time or training to resolve, it’s easy to sacrifice the test and fall back on the old system. As a result, most parallel tests accomplish very little except to delay your implementation and make the switch-over much more difficult on your team.
7. Starting with bad data.
Admittedly there’s some work involved with updating and checking the data from your old system before its loaded into the new one. But taking shortcuts or using outdated or incorrect data can impact the usability of the new software now and well into the future. Investing the time to properly cleanup your master data and verify the accuracy of financials, such as inventory data, will not only help make the new software easy to work with from the start but will also pay dividends by avoiding the headaches of trying to fix these data problems down the road.