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.
S/4HANA Business Partner master data design requires a structured approach to track the many moving parts.
In this 7-minute video, I share my template for doing just that. It’s a small insight into the process of crafting a master data design for Business Partner.
I also share how I quickly analyze Business Partner configuration in any SAP system-client. That’s super valuable. For this task, MDA Workbench is the secret enabler.
The output (analysis) looks just like the input (requirements). That’s because these are two sides of the same coin.
Over time, I’ve got to build up functional requirements and express them in a way that properly enables accurate configuration. And then I need to be able to quickly evaluate the Business Partner configuration in any system-client … on demand, and repeatedly. With a few minutes of effort, not hours!
What you’re going to see fits this specific use case, but the concept is totally generic — I use this approach for all kinds of configuration and master data analysis. And now so can you.
If you want to understand S/4HANA Business Partner, then you need to stop thinking 𝙞𝙣 𝙩𝙚𝙧𝙢𝙨 𝙤𝙛 Customers and Vendors, but continually think 𝙖𝙗𝙤𝙪𝙩 Customers and Vendors.
If you know about Customers and Vendors in ECC 6.0 then this requires a dramatic shift in thinking!
I’ll confess, even experts need an occasional reminder of exactly how Business Partner is astonishingly complex, massively duplicative, simplification. All at once. But simplification accrues to users and the enterprise. You and I — responsible to implement Business Partner — get to wrestle with complexity and duplicative data.
I can tell you this much with certainty: Continuing to think 𝙞𝙣 𝙩𝙚𝙧𝙢𝙨 𝙤𝙛 Customers and Vendors is a path to misery.
SAP S/4HANA Business Partners, extended to a Customer or Supplier role, bring the possibility of a special class of errors. Are you prepared for these in your Production environment?
Let’s frame the key decision: What is Postprocessing Office and should it be active for Business Partner in Production?
A bevy of related SAP Notes seemingly offer contradictory advice — or no advice — about whether Postprocessing Office (PPO) should be active for Business Partner (BP) synchronization in an S/4HANA production environment. SAP Note 1573189, specifically recommends that PPO “should be deactivated in production system …”
Maybe, and maybe not. I agree with experts who say that this “recommendation” should be understood as one option, with tradeoffs to be carefully weighed. Further, we agree that — with eyes wide open — activating PPO in Production may be your best alternative.
Listing in SAP Retail and Fashion is a pain point. After coming to grips with the art and effort of assortment management, you’ll find that execution of Listing is performance intensive. Maybe problematically performance intensive. Sooner or later, it begs the question: Is all of this really necessary?
Of course, the simplistic answer is: Yes, you have to. But this answer isn’t only unsatisfying. In some cases, it’s simply wrong.
If you’ve been given an explanation of Listing that more-or-less begins and ends with “it’s mandatory,” then press on. I’d begin with: What business purpose does this serve in SAP ERP? Here’s a tip: Reject any generic or technical answer. You need to ask, very specifically: What business purpose does this serve for me, right now, in the context of my particular business processes? Why? Why? Why?
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.
What was true about Generic Article and Variants in SAP ECC 6.0 has changed from top-to-bottom.
With SAP S/4HANA, in keeping with SAP’s movement of Industry to Core, the implementation of the SAP Retail concept of Generic Article and Variants dramatically changed to align with concepts found in standard Variant Configuration (LO-VC). The result is significant technical change, but also significant business process change, as one would reasonably expect when master data concepts are rearranged.