Data migration to SAP S/4 HANA requires well-defined strategy
Moving to SAP S/4 HANA is no easy feat, whether customers have been running an older version of SAP or a non-SAP legacy system, and regardless of which implementation or upgrade method is chosen. This is because the way customers do business has changed. Therefore, people, processes and technology are forced to change as a result.
Business has become digital and not keeping up means that customers can be swallowed whole by hungry competition. Hence, IT Budget is focused on enabling all the good, exciting things that executive committees are after: automation, artificial intelligence, machine learning, digital supply chains and true e-commerce.
This is all well and good, but focusing on the prize without focusing on the foundation and life-blood of the system, ie, its data, can cost a customer dearly.
"I have been called into too many meetings recently where data has been the main issue preventing a successful go-live for a customer that has embarked on a new or Greenfields implementation of the latest ERP from SAP: SAP S/4 HANA," says Malan Barnard, director at GlueData Master Data Solutions.
"The meetings all have a common theme, with complaints such as the following:
* We have not been able to do a successful mock data load yet, and we are already in the UAT (user acceptance testing) phase of the project;
* We thought S/4 HANA came with a toolset to load data and that would be sufficient;
* We never expected data to be our challenge and we started looking at the data too late;
* We did not expect such a big effort for data clean-up as we were doing a system conversion; and
* We made too many assumptions and never executed our test cycles with migrated data. Now that we have, a whole can of worms has been opened, causing massive project delays.
"And the list goes on," says Barnard.
The planning stage of the SAP ERP implementation is the best time to make the data topic a relevant and focused stream; the earlier, the better. A sound strategy is required that, at the very least, outlines the following:
* The data migration approach for ERP and other systems (eg, BI). For example, for a Greenfields implementation, defining the archiving and data resolution approach.
* The reconciliation approach (recon techniques can, for instance, range from field by field comparisons to spot checks). This is where working out what makes business sense for each "data object" (eg, Customer Master) is key.
* The project phases outlining the number of mock cycles lined up to the project plan, together with entry and exit criteria.
* The systems landscape covering the tooling and technical approach (ie, which mock to load into which systems).
* The Data Migration Scope: an inventory of all data to be migrated; the source of the data, target, data owners and what data needs to be migrated, archived or stored in near line storage.
* Roles and responsibilities: defined especially if the implementation team is separate from the data team.
It also does not help to implement SAP S/4 HANA with good quality data without a strategy for keeping the quality standards after go-live. A master data management strategy should therefore also be implemented, and as with the normal business processes, master data processes should also be defined. Data governance capabilities should be established so that there is a framework of policies, rules, processes and roles defined to enable the business to operate successfully post go-live.
Look out for future articles where Barnard will dive into some of the technical elements and options available when performing the data migration.
Contact GlueData to find out more about offerings.