10 Data Mistakes to Avoid in your...

No Defined Responsibility – Data moves like an orphan in a transformation project. Most consulting companies will provide resources but not take responsibility for the data quality. Ensure you engage a specialist provider for data who works with your business and not with the implementation partner.
Data Preparation Starts Late – We all start with a Project Plan from the design or blueprint of your system. The Mock Conversions are meant to pass the SIT and not to ensure quality data. The core problem is most architects and consultants will not talk about data during design and specification phases (as they know it will scare you off). The simple assumption is that it will magically happen. This exercise must start a considerable time before you officially kick off the design. Once the design is complete, there will be tweaks but you will be way ahead with most data objects.
Business Readiness and Availability – The assumption that business employees will be available to help you with data when you need it, is a completely false expectation. They already have a daily work load, especially the people who know the data, are usually the people who are wanted most in the business. It becomes a 3-fold pressure; they need to help in the verification and testing of the system, do their regular work and meetings, and if they have time help with data. This is the starting point of the failure. Having this exercise done early can spread their work load.
ETL Tools will solve the Problem – ETL tools and teams work in isolation and are designed to Extract, Transform and Load, regardless of what the data is. For Example, if you have the value “NA” in a mandatory text field, it will load it. Data Migration in a transformation project is a very collaborative process, there needs to be strong governance around data collection, mapping and verification of data.
Verification and Reconciliation – Verification and Reconciliation of data is often taken very lightly, mainly due to time pressure. It doesn’t matter how long a project is planned for, the business often doesn’t get enough time to verify or reconcile its data. This can be addressed by having a strong collaboration tool for verification of data and clear definition for both verification and reconciliation.
Identifying Redundant Data – This step can be done before you start the transformation project. Identification of Data is something that takes time and deliberation, it requires multiple collaboration and agreements. This cannot be done at an expected speed during the project. As we are moving to environments such as in-memory and cloud, it becomes more important to identify data that does not need to be in the new environment.
Ownership of Data – The definition of ownership must be clear. The business units who own the information should ideally be part of the User Acceptance of the system. This should be well defined before the project starts.
Data is not part of System Design – The Dependency of Data in System Design should have its own step in the project. You can create an excellent design and a process but need to know the source of that information. Systems such as S/4 Hana need a lot of data to get you the best business outcomes. It is often late in the process that you realise the data is in someone’s draw or secret excel files which only a few people know about. It becomes more complex when multiple business areas have to provide a common way of delivering data to make your new system work.
Data Quality is not in Scope – There are valid reasons why Data Quality cannot be in the scope of a Transformation Project. The main ones being time and cost. These projects are always aggressive and are already urgent before they start. No one wants to uncover the dirt of 10 years within the given project timeframe so they’re skipped. Data Quality exercises should start before the project begins and continue running in parallel. Poor data migrated to a new system will be hard or impossible to support when you are in execution. Data Quality problems will show up in matter of weeks when you go live.
No Defined Data Governance Strategy – Not having a Data Governance Strategy defined, including ownership of information, will become an issue as you start using your new system. Too often we see companies in “fix-it mode” as incorrect and misleading data with no ownership erodes their new environment and starves them from transformation benefits. This needs to be defined and implemented as part of your project, not after the damage is done.