Simon Suarez

Data related things that are missed during ERP implementations

I have had the pleasure (and at times misfortune) of working on multiple ERP implementations during my career. There have been many issues along the way, but I have put together a short list of the things I think can mitigate the drama from a data perspective.

Less is not more when it comes to Data Migration

Let’s not migrate all the products and only the ones we need! It always sounds like a good idea, we have a new shiny solution, let’s not fill it with old data.

Data storage is cheap! To build a migration process it will take the same time to build it for 100 items as it does for 100,000 items. As most businesses will attest, inventory accuracy is a constant work in progress. A product long since dead will appear on the next physical inventory audit behind a cupboard in the stock room. The process to continuously add products manually into the system for the following two years will be a hardship for support staff with the preparation of data imports a laborious task. Can anyone find the data from the legacy platform? Does anyone still understand it? This leads us nicely to the next point.

A Data Backup Strategy is a pre-requisite not a nice to have.

As businesses we accumulate massive amounts of data. Not all that data will reside in a data-platform and could prove important in system migrations of the future. With licenses expiring or 3rd party hosted solutions being shut down, an important part of the planning process is to create a data backup strategy.

Important points to consider.

• Data should not be backed up solely in flat-files and excel documents.
• Data should be easily accessible, searchable, and extracted with ease.
• Firstly, data needs to be stored in its source schema or medium, after which it should be converted and harmonised if required to meet the demands of the point above. Never put yourself in a situation where the raw data can be lost, it may not be recoverable!
• Data should be secured appropriately and is still subject to the same compliance regulations that were there when it was captured. As publicised by numerous academic and security services, around 85% of all data breaches are from within the organisation.
• Document the data, do not rely on the incumbent systems’ owner. They may not be around to assist in the future.

Clean your data before importing it.

As the phrase goes, **** in **** out. Take as much data as possible but put in the extra effort to cleanse and map data. An ERP migration is usually an excellent time to revisit the way that taxonomies are defined for your business or to apply standards to ensure that data quality is maintained going forward. Ensure that this mapping process is included in the data migration mechanism and is automated. Remember that this mapping should cover all data in the old system regardless of what is being migrated. This will help in the long run should ad-hoc additions need to be made in the future.

I would advise rather than fixing data during the migration process it is pre-cleansed in a data layer that has been put into place above where the raw data lives.

Do not neglect reporting!

Reporting is often not seen as a priority early in an ERP migration. I have seen multiple examples of data teams playing catchup even a year after the initial implementation.

Start building up the data models in your data platform as soon as the technical data migration begins. Ensure that the BI team is onboard and available within the data discovery sessions and technical workshops for mapping from old to new. It is their opportunity to understand the new systems, decisions made on cleansing and changing categorisation/taxonomies will be well understood by all. The data team will have a lot to do to manage the re-categorisation of data between the old world and new, while still providing the means to access reports with legacy mappings.