7 habits of highly successful ERP implementations
Our prospect list currently ranges from mid-sized multi-site firms to small but rapidly growing businesses. Each has their own unique problems with their current systems, all of which are on-premise. Together, they all share two commonly held fears that can delay or prevent them from adopting the system changes that would solve their issues.
One mid-size firm has an older, outdated system now out of support with few skills in the market to help should a problem occur. They run disparate systems that do not communicate, with poor reporting functions that are open to human error.
Another mid-size business runs a large on-premise ERP system that is costly to maintain, upgrade and support. Though implemented years ago, they only use a small percentage of its functionality. Without the confidence in the system to do what was needed, they developed their own solutions which rather nullified the reason for having the ERP in the first place.
A small to medium size business purchased a new system only a few years ago, but they have quickly outgrown it. Data is duplicated, wasting time and creating errors, and reporting functions are cumbersome.
Lastly, a small but rapidly growing business has outgrown its systems and is finding it difficult and expensive to bring on newly acquired subsidiaries. They run many manual practices that have not been automated.
These issues no doubt are commonplace with many businesses. Yet when contemplating the implementation of solutions or system change needed to solve their problems, two recurring headaches particularly instilled anxiety and doubt among them all: Data Migration and Change Management
We’ll focus on the first, data migration, in this article, the second we’ll explore in our next blog.
Data migration can be a costly affair. Fields and tables will not match, you may not have all or any documentation and if your old system has been heavily customised, it could look entirely alien to any outside consultant. After 17 years of integrating, supporting and maintaining systems, IBT is no stranger to this. So what have we learned and how can we help customers save money and time? How can we help the data migration process go more smoothly?
Be it between on-premise solutions or to the cloud, here are some key factors to consider:
- Decide when is the best time to go live for your business
It is quite often best practice to go live with a new financial year, start afresh and off you go. But year-end is generally a very busy and stressful time, so can you afford to take your best people off their everyday duties so that they can focus on the project? Can you afford not to have your most knowledgeable people on the project? How important is it to have a successful project that meets the needs of the business? Better still, work with your implementation partner and assess the project implementation time. If it is 3, 6 or 12 months, decide when go-live suits you best.
- Decide on who will staff the project
Some companies have chosen to bring in extra staff to help with the project, so that their lead employees are free to focus on their roles. Other companies fill the project team with staff that are available, not the staff that are the most knowledgeable.
However, best practice would be to bring on extra resources to back-fill your best staff everyday duties, so that they can focus on the project. These users know the old system better than most, and can work more effectively with your implementation partner. They build their skills with the new pre-production system, getting trained on it prior to go-live.
Data migration and system implementation is quite repetitive and, if they are anything like me, repetition is often the best way to learn. Once the system goes live, they then become your company’s super-users, subject matter experts, if you will, who essentially help with training the rest of the user base. This saves time, money and a lot of grief.
- Decide on how much historical data you need to bring across
Notice I said need, because nine times out of ten when we pose this question, the answer refers to want. “I want all of it” they say. Then we explain the costs involved with doing this, and they quickly revert to need. So decide what data is critical, whether it would be formulas or date ranges, and go from there.
In Accounts Receivable for instance, it would be critical that you bring across all open items. Customer balances need to match, but could any more detail be kept on the old system for you to refer back to. Let’s face it, how often do you need information from 10 or 15 years ago? Companies that have decided to migrate all of it, eventually realise they didn’t need to, as they hardly, if ever, access it.
- Once you’ve decided what you need, cleanse it as much as you can
Notice I said you. Consultancies can certainly do this for you, but it is time consuming and the expense makes it prohibitive. Look for old redundant records, duplicates and poorly made entries. The business is in a better position to recognise anomalies within data and identify what it should be. Where there are large numbers of data with the same issue a script or program could be generated to assist in cleansing this data.
- Decide on what you are going to do with your old system
Some companies chose to keep their old system running in the background. They continue to pay for user licences and support, whilst also paying for the new system. If your company has a bottomless budget, then fair play to you, but there is a better way.
You could, for instance:
- reduce your systems down to a read-only database, drop all support and unnecessary licences and keep only historical data on it that you can query when necessary.
- opt to move all the data to a data warehouse, and again query it when required.
- or store the historical data on a cloud service, such as Amazon Web Service, and extract data again when you need it.
All three of these options can be far more cost effective than running your old system in the background. As time goes by the maintenance and upkeep of the old system and the knowledge on how to access the information becomes a risk.
- What does your current system interface with and is it well documented
If you have saved money on documentation on past projects this is when the true cost of that saving comes to the fore. The only way you can do it is to take everything across and then run trial-and-error style processes to assess what and where the customisations are.
Interfacing can be tricky, because in many cases you may not have enough documentation on-hand to even know how many interfaces there actually are.
A case in point was a customer we worked with a few years back that wanted to change its HR system. The company had decades of information stored. The sparse documentation that was available was at best outdated and all that was available was what some employees had in their heads. This was fine when all was well, but what happens when or if they leave, as happened in this case?
When the new system was implemented, instead of rewriting the interfaces to and from the new system which is normal practice, they instead updated the old system, which in turn continued to update what it interfaced with. This was deemed less of a risk as they simply did not know how many interfaces existed, they thought it ranged somewhere between 25 to 50. It was too costly to rewrite all the interfaces for the new system, so they re-wrote one and saved the difference. Problem solved? No, not really. Old interfaces are still running, others can and will break in time, connections will be lost and the system will break down.
- Communication is key
IT is still a people business after all. Normal practice would be to perform a handover to the person or persons that are taking over the responsibility for the current business processes, as would usually occur when a person is leaving their current position.
As with the example above, when no hand over and very little documentation is available, we began to figure out how the systems and interfaces were customised by speaking to users and gaining their confidence. We developed stronger ties with the original vendor, who had reached an impasse with the customer and dialogue had broken down. By communicating and taking a less confronting approach, we “scratched each other’s back” and came to a win-win solution.
So in conclusion, you could be forgiven for thinking that the best approach after reading all these points is to do nothing. Why spend the money on an upgrade, a new system or interface re-writes? Doing nothing won’t cost you anything, right? Well maybe, but you are still left with an old or redundant or costly system, and interfaces will always need to be replaced eventually. You will have a system that is restricting your competiveness and your growth. The solution is to implement a flexible system that is scalable and meets your changing business objectives, so doing nothing is not an option. Surviving in today’s marketplace we all need to move forward and keep pace with the changing world economy.
By taking the time to plan your project, choosing the right staff to implement it and deciding what data is the most critical for your business to continue to thrive; it is possible to bring on a new system under budget and within timeframe.
IBT is a NetSuite partner, the world’s leading cloud based ERP; an Attunity partner, a simple and cost effective way to move data; and an Oracle Gold Partner, we upgrade, integrate and maintain PeopleSoft HR and Financials systems.