Recently comes the headline: SAP users struggling with data management for S/4HANA migration.
And the metrics: “According to a survey of 116 SAP user organizations, 61 percent said that data management challenges have slowed or will slow the automation of their business processes. Meanwhile, two-thirds (66 percent) state that data management is a challenge when moving from SAP ECC 6.0 to SAP S/4HANA, the study by the UK and Ireland SAP User Group (UKISUG) found.”
Is it really surprising that two-thirds of folks seem surprised by the effort required to bring data into a new system? Or that they struggle to manage data after the fact?
On reading this news, my first reaction was: There’s nothing new here! Implementing SAP ERP has always been about the data. In particular, it’s all about the master data, because SAP ERP is a master-data-driven system. Data migration has always been — and will always be — the highest-risk workstream. If your SAP master data isn’t right and governed, then woe is you!
But there’s definitely more going on with the move from SAP ECC 6.0 to SAP S/4HANA. Much more. For example:
- The shift to cloud, preconfigured content, and a fit-to-standard mindset all reduce implementation time, but these also combine to significantly exacerbate data migration risk. You have to perform data migration and data quality remediation tasks in … much, much less time? Shortening the runway for data migration increases risk exponentially.
- Many companies have a low data maturity score, with little or no data governance in place. Or worse, “data governance” is led by IT, which is an illusion of data governance. Data migration tools and partners can’t compensate for what your people and organization must quickly bring to the party.
- Finally, having plenty of experience with SAP ERP 6.0 tends to inspire overconfidence, especially when you’re told that SAP S/4HANA Migration Cockpit provides “.. a comprehensive migration solution with no programming required by the customer.”
That last bullet should prompt healthy skepticism. I’ll offer two small examples of why:
- The adoption of SAP S/4HANA Business Partner to replace ERP Vendors and Customers requires rethinking and often restructuring master data. It’s a business problem more than a technical problem, usually requiring compromises. Because SAP ECC 6.0 experience is insufficient for formulating the new master data design, it’s typical to underestimate the complexity of this task.
- When it comes to loading data, the much-touted Migrate Your Data – Migration Cockpit replaces Legacy System Migration Workbench (LSMW). Again, your ECC 6.0 experience isn’t very informative; this is a new tool and a new skillset, which might present a challenge all on its own. But the most common mistake is to focus on this tool (it’s not a solution) rather than an end-to-end process and consistent stakeholder experience. Data migration involves far more than the “Load” step, and believing otherwise inevitably leads to missed expectations.
Excellence in Execution
The risks posed by data migration to SAP S/4HANA and subsequent data management processes are real and widespread, as recent headlines attest.
What do the successful one-third know that confounds the majority? Mainly, principles that apply to companies of all sizes!
For this topic, the cliché that “people, process, and technology” combine to produce excellence in execution has the added benefit of being absolutely true. In my experience, when data migration success happens, it’s as much about people and culture as it is about tools and content.
There are success stories — principles, if you will, or at least common habits — that stand against the many well-publicized tales of woe. You can observe these to minimize risk and promote success. That’s today’s story.
People
Who are the resources you’re looking for? Can you spot them in the wild?
Can you identify the unicorns that you need?
At the onset, seek out a few unicorns. You’ll eventually settle for mere mortals, but it’s important to know key roles, and the desirable characteristics of the folks who will fill them.
For standard ERP implementations, master data responsibilities may be allocated amongst various business process functional leads. But if your implementation is SAP Retail or Fashion, then you’ll definitely need a dedicated SAP Retail Master Data lead, because Master Data makes SAP Retail special.
In any case, the mission of the Master Data Lead is orchestrating master data, cross-functionally, for the enterprise. Central orchestration is required because, for example, SAP S/4HANA Business Partner as one master data represents Suppliers and Customers across financial, purchasing, logistics, and sales business processes. Material Master (Article Master) is likewise important cross-functionally. It’s dangerous to split responsibility for a master data business object.
The dynamic duo: your Master Data Lead (blue) and a Master Data Expert (orange).
While project size and scope dictate head count in master data and data migration workstreams, you should begin hunting early for key master data and migration resources that are required for all SAP ERP implementation projects.
As a starting point, assume a conventional two-in-the-box pairing of your own Master Data Lead and a Master Data Expert (e.g. consultant). The two-in-the-box approach pairs functional knowledge of legacy and future state. Together, they uniquely create a bridge, then a foundation of master data, for every business process. That’s not hyperbole, but essential truth for taming the highest-risk workstream.
When scouting your organization for a unicorn Master Data Lead, you’re looking for signs of experience, relationships, and especially an ability to blend into scenery.
This person knows — at least at a business object and systems level — how data flows in the enterprise. All the better if that person participated in making it so. While the role is typically staffed from the ranks of IT, the unicorn has solid relationships with business counterparts, including those who are — or are likely to be — named as data owners. Telltale signs of a trophy can be observed in meetings with both Business and Technology folks in the room. Your unicorn is the person cheerfully moving the conversation forward by deftly translating between business and technology stakeholders, who may be talking past each other. There’s a distinct scent of “how may I serve you?” as this one moves and interacts.
Every bit of that description is about people and culture. And every bit is far more valuable than specific SAP knowledge.
Key SAP S/4HANA Data Management roles.
The same is essentially true for your Data Migration Lead, but with a more technical bent, of course. This one knows your systems, data sources, and has hands-on experience using your favorite tools for extracting and moving data (more on that later).
Experience teaches that a weaker Data Migration Lead can usually be sufficiently compensated for by a strong Master Data Lead. But I’ve never observed the reverse in the wild. Choose carefully.
Eventually, the broader data team is realized, and among best-run companies — or those striving to be — this includes data governance. Introducing data governance warrants full-length treatment, beyond the scope of this missive. If you’ve already staffed these business roles (not IT roles) then, “bravo!” If not, then digital transformation either isn’t on your radar or it’s past time to get started with crawl, walk, run.
Additional Reading:
Process
How and how early should key data folks work together? Have you arranged it properly, and can you spot trouble?
So far I’ve mainly described your dynamic duo — your Master Data Lead and an SAP expert counterpart — who are functionally responsible for to-be master data definition and master data processes. It’s no accident that this pairing uniquely provides a once-in-a-lifetime opportunity for knowledge transfer as a side-effect of workaday activities.
Now let’s have a look at how you expect these folks work, together, and with data migration leads, to produce timely success.
I’ll begin by describing the setup for calamity, so that you’ll smartly avoid it. Just imagine an arrangement that has functional leads writing data migration functional specification documents as an output of project Explore phase, and then tossing them over a wall to technical resources for execution during project Realize phase. As if these activities naturally occur sequentially to produce an output, or can be handed off from one team silo to the next on a timeline.
We’ve all seen project plans laid out on this basis. In fact, it’s the norm, because it’s the timing and sequence prescribed by methodology. But your success depends on deliberately coloring outside of those lines!
Here’s a guiding principle: Plan for and organize an intensely-collaborative, iterative process that intentionally minimizes complexity by playing to the strengths of each role. Oh, and plan to start early!
Competencies and collaboration result in successful data migration.
Start Early
The SAP Activate Methodology for Transition to SAP S/4HANA prescribes the Data Migration Design steps that should occur during Explore phase.
- Conduct a Data Migration Assessment
- Run a data audit in the legacy source systems
- Finalize the data migration approach and strategy document
- Define specifications for data migration
- Set up and configure data migration tools
- Perform Data Cleansing Activities
You should diligently work that list. But for some objects, do more, and sooner.
Practical Examples Mitigate or Confirm Risks
As data migration business objects are identified during Data Migration Assessment, your Master Data Expert and Data Migration Expert should flag those that present risks or unknowns for loading data into SAP S/4HANA. For some or all of these, create simple prototypes.
- In a sandbox or development data migration client, load a few rows of manually created sample data.
- This can be accomplished far in advance of known requirements.
- Success demonstrates prototype load functionality for a business object.
- Simple result informally validated by functional resource who will own the conversion functional specification document for the business object.
This exercise may seem simplistic, but the value of early-insight can’t be overstated whenever there’s any unfamiliarity with some aspect of a business object, or with the tool required for loading data for a business object.
Early Engagement
One all-to-common pitfall involves the rather important Data Migration Approach and Strategy Document, which is carefully crafted and then read by … almost nobody. Then it’s set aside. Too often this document is a bit long on the technical and a bit short on strategy, or practical application.
Consider the essential data migration process steps:
- Analysis
- Extract
- Transform
- Validate
- Load
- Reconcile
From the start, it’s important that everyone who participates in data migration — from business data owners on down — understand the essential process steps and their role.
Perhaps one level deeper, I rarely see data Validation and Reconciliation steps treated sufficiently and effectively communicated. It’s a gap that’s both easy to spot and guaranteed to cause consternation later on.
Business data owners own the data. They’ll be asked to “accept” the results of data migration. Engage them early on, and coach them on what the data migration “Validate” and “Reconcile” steps looks like in practice, and especially their role. What the process “looks like in practice” isn’t a figure of speech. Show them an example of reporting or a transaction code that they — or their representative — will use as the basis for “accepting” data migration results.
This exercise will surprise you as questions are asked and expectations are clarified. Early engagement and agreement with data owners — those who will sign off on data migration results — is the way to avoid guaranteed upset and correction-under-pressure at a later date.
Intensely-collaborative, iterative process that intentionally minimizes complexity.
As already suggested by the early collaboration of your Master Data Expert and Data Migration Expert, silos and handoffs are verboten by design. When detected, relentlessly tear down those walls, or suffer the consequences.
The structure of collaboration may change depending on choice of tools, but required competencies and collaboration remain constant.
| Knowledge / Task | Master Data Lead | Master Data Expert | Migration Lead | Migration Expert |
|---|---|---|---|---|
| Legacy Data Knowledge | XX | X | ||
| Formulate To-Be Master Data Design | X | XX | ||
| Formulate To-Be Master Data Processes | X | XX | ||
| Data Load Method, Define Structures | X | XX | ||
| Define Simplified Target for Data Staging | X | XX | ||
| Legacy Systems and Data Tools Knowledge | X | XX | ||
| Fill Simplified Target | XX | |||
| Data Migration Step: Validate | X | X | X | XX |
| Data Migration Step: Load | X | XX | ||
| Data Migration Step: Reconcile | X | X | X | XX |
In practice, the people in these roles must visibly operate as a tightly-knit team.
The concept of “Minimizes complexity by playing to the strengths of each role” comes to life by “defining a simplified target for data staging.” What does this mean and how do you recognize it in action?
The master data structures in SAP S/4HANA are complex and likely unfamiliar to your Master Data and Migration leads (at least initially). For example, SAP Business Partner and Material Master are comprised of dozens of tables and thousands of fields. Most of these tables and fields will be irrelevant for your particular SAP S/4HANA implementation. Considering them in entirety would be a distracting waste of time and would only add complexity and confusion.
For this reason, your Data Migration Expert and Master Data Expert closely collaborate to present relevant (simplified) structures in a data staging area. Mapping from legacy data to SAP S/4HANA becomes simplified as mapping from legacy data to relevant (simplified) structures in a data staging area.
The people who understand legacy data are more sharply focused on the objective and shielded from unnecessary complexity. They focus on moving data from legacy systems to a data staging area. The people who understand how to load data into SAP S/4HANA are focused on loading data from the data staging area into SAP S/4HANA.
This is a highly-productive division of labor, by competence, with end-to-end speed and accuracy — in particular, iteration speed and accuracy — augmented by constant collaboration. If this level of collaboration and speed isn’t readily observable, then you’ve probably got silos to tear down with high priority.
Process (Progress)
Are you asking the right questions? How certain are you that data migration is on track?
Here’s a guiding principle: Understand — and embrace — that data migration is an iterative process..
The universal question that I hear asked is: “When will the data migration deliverables be done?”
Project managers diligently — almost comically, but tragically — struggle to answer this question on nearly every project. For data migration and data management workstreams, toss out the Gannt charts! They’re worse than misleading because they impossibly pretend to inform. To the point, it’s pointless to talk about “done.” It’s the wrong question.
Just say no when you see this presented for data migration.
The data migration workstream must accommodate change over time. That means — by design — an expectation of and readiness to accommodate significant change in the beginning, and carefully-considered (prudent) change later on.
It then follows that data migration doesn’t fit neatly into a project plan or make for a pretty Gannt chart. And hammering data migration deliverables into typical “check the box” reporting with an end date doesn’t provide critically-needed transparency to project stakeholders.
The insight-producing question is: “Are we on track for success with data migration deliverables?”
To produce an informative answer, insist on milestone-based status reporting, for each data object. That provides essential Data Migration Transparency. It’s not one check-box or a timeline, but an at-a-glance, experience-based indication of progression that builds confidence and identifies risks as early as possible.
At the highest level, at least this level of detail is required by business object:
- Object Definition / Prototype
- Unit Test
- Functional Test
- Full Load (or … almost)
The data-migration mantra of “Load Early, Load Often” is shorthand for two important insights. First, it affirms the notion that data migration is an iterative process. Second, it declares that the only reliable indicators of progress are demonstrated and repeatable results. Show me the data, in SAP S/4HANA!
Additional Reading:
Tools
Are you focused on an end-to-end process and consistent stakeholder experience?
Or have you been told a temptingly simplistic data migration story that’s mainly — or only about — “loading” data? If so, then you’ll wildly underestimate the effort of data migration. It happens every day. Getting it right begins with understanding the touchpoints of repeatable process.
Again, because it’s worth repeating, the essential data migration process steps are:
- Analysis
- Extract
- Transform
- Validate
- Load
- Reconcile
Any data migration “solution” must address all six data migration steps to warrant the name. If you’re responsible for the outcome then you dare not do less.
Covering the scope of data migration steps requires looking beyond Migrate Your Data – Migration Cockpit — looking beyond the Load step — for all but the simplest projects. What’s more, even in SAP S/4HANA 2020, consider that no single tool will enable the Load step for all data migration objects!
For example, LSMW (more precisely, IDocs or BAPI) remains essential for SAP Retail. For confirmation of necessity, see SAP Note 2538170 – Migration of Retail Objects to SAP S/4HANA on-premise. Even outside of SAP Retail, your S/4HANA data migration architecture not only has to cover the six steps, but has to enable multiple options for the Load step, with a decision to be taken by data migration object.
Load step options include these tools, and you will need more than one:
- SAP Data Services
- Migrate Your Data – Migration Cockpit
- Legacy System Migration Workbench (LSMW)
- Extended Computer Aided Test Tool (eCATT)
- Custom Development Object / Load Program
Finally, the scope of every enterprise-grade data migration project includes writing some code, no matter what the brochure says. Migrate Your Data – Migration Cockpit is no assurance of avoiding that reality.
SAP S/4HANA Data Migration Architecture
You expect the infrastructure and process conveyed by the above image, because it’s preferable to have a single flow (or fewest) that accommodates all business objects. That desire encompasses functional as well as technical steps, and should work similarly regardless of the technical method chosen for the Load step.
That’s why I believe SAP Data Services (or an equivalent world-class tool) is essential for all but the simplest data migration projects. It’s uniquely capable to cover all six data migration steps, and any of the data migration load options fits into the process.
With that said, here’s a guiding principle: Right-size your tools and resources.
SAP Data Services requires specialized resources and dedicated infrastructure. If that fits — or can be made to fit — your landscape and staff, then that’s sweet. It’s good because we know that it will produce good results. But if you have other world-class data tools, and experienced staff to use the tools, those can work as well.
For medium-size companies with modest data quality concerns, experience teaches that you could get by with much less, with eyes wide open to risks.
I’ve participated in several ERP implementations where the data staging environment consisted of a database server and a couple database experts (extract / transform). We got along just fine, because we covered the six essential data migration process steps, and acted out many of the habits described above.
Experience substantiates the claim that when data migration success happens, it’s as much about people and culture as it is about tools and content.
Master Data Governance
Here’s a guiding principle: When it comes to data governance, people and process aren’t only more important than tools, but success demands that they arrive before tools.
With that said, your migration from ECC 6.0 to S/4HANA represents a rare data management opportunity to restore order. There are tools to support people and process to this end, and it’s noteworthy that they’re useful for upfront data preparation, not only for governance afterward.
If SAP Master Data Governance (MDG) is already existing in — or planned for — your business process landscape, then it too requires coordination of people, process, and technology (e.g. customizing, data migration targets). MDG sequencing and capabilities can play a role in supporting data migration with a mix of master data consolidation, central governance, and data quality management.
Data governance — considered holistically, as people, process, and tools — should be an integral part your journey to SAP S/4HANA.
Altogether, this is what transforms your data from a showstopper into a business accelerator. And that’s the essence of what folks recognize as true digital transformation.
Additional Reading:
- Migration Cockpit is a tool, not a solution.
- All-in on SAP S/4HANA Migration Cockpit?
- SAP Community – Master Data Governance Page
- SAP Community – Master Data Governance How-To Page
Notes and Asides
- In this document, I use the term SAP Retail as shorthand to mean both SAP S/4HANA Retail for Merchandise Management and SAP S/4HANA for Fashion and Vertical Business.
- SAP Managed Tags:
4 Comments
