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.
If you fall for a temptingly simplistic story that’s mainly or only about “loading” data 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.
If you’re an SAP Retail functional person, it helps to be familiar with relevant IDocs. And if you’re a Master Data Aficionado, it’s kind of expected. This article explains the most common mistake made when attempting to create Generic/Variant Articles in data migration. It’s all about understanding the functional use of ARTMAS IDoc segments.
Data Migration doesn’t fit well into project tracking schemes. Unsurprisingly, the frustration of stakeholders eventually becomes palpable on every project.
The universal question I hear is: “When will the data migration deliverables be “done?”
If you ask me — the functional master data guy — when data migration will be “done” then the honest answer is clear: “The day before go-live.” When will the data migration functional specification be done? Same answer. Go ahead and ask the technical team when the data load program will be finished. “That depends on the functional specification. Oh, and you’re not going to change anything over time, are you?” For some reason, replies like these reliably produce eye rolls.
I am not “all-in” on SAP S/4HANA Migration Cockpit.
Analysts warn that 83% of all data migration projects either fail or significantly exceed budgets. Like a poker table full of serious faces in a swanky casino, the stakes in data migration are sky high. Before going all-in on a single bet of such consequence, you’d better consider the big picture.
Yes, I understand that it’s the recommended tool for loading data into SAP S/4HANA, and has been for 5 years. And — for as many years — it’s been touted as the successor to Legacy System Migration Workbench (LSMW), which is no longer considered strategic. It’s not that SAP S/4HANA Migration Cockpit isn’t usable. After five years of steady revision, it’s achieved that mark, albeit with constraints. And it introduces important innovation, such as Direct Transfer, to transfer data directly from an SAP system. That’s all super-good news, but it’s insufficient information.
It would be fair to say that I still dislike eCATT. But the best SAP Functional folks are the best, in part, because they’re aware of every tool in their kit. And sometimes eCATT is the right tool for the job. In rare cases, it’s the only tool for the job.
You should know a bit about eCATT, even if you plan to avoid it, as I do.
Creating master data (and customizing, without customizing requests!) is a serious matter. Your data migration process better be executed properly and accurately. For one thing, it’s a tedious mess to clean up (archive) if things goes awry. Of course, as a Master Data Aficionado reading this article, you now have a plan for success.
Let’s begin by recognizing that your Site Master business process design dictates where and when you’ll be executing Site Master data migration.