Lighten the cargo when RISEing with SAP

Considerations before check-in

If you haven’t flown internationally since the pandemic, prepare yourself for a potential shock when you do it again. The experience is a lot more variable than it used to be. I had a terminal pretty much all to myself when transferring through Heathrow – it was surreally quiet at what I considered a busy time; and then a few weeks later, I had an hour-long queue just to drop bags off when I was already checked in for a short European flight. And more recently, the dreaded ‘flight cancelled’ – only announced at 11pm.

What’s the relevance to RISE with SAP® and test data management (along with our Data Sync Manager™ solution)? My experiences with both tell me that it's all about the planning, otherwise there can be unnecessary dramas and unwanted extra costs.

Space and time

You’re always predicting the space increases of your SAP production environment, to ensure there is enough capacity as the business stores ever more data. And you may well include the impact of that on test systems in your planning, in line with the refresh strategy and timings.

Before you go to RISE, this is something that can be done almost reactively when a problem occurs. But what you’re essentially signing up for when you switch to a cost model like RISE is pre-agreeing what your system volumes will look like over the course of the contract. We’ve seen organisations purchase the Data Sync Manager (DSM) suite later on to reduce the size of non-production systems, but they don’t get the full cost savings – compared to the RISE contract being signed with the test system a quarter of the size of production.

HANA multiplier

You may be taking your existing system to RISE without an immediate S/4HANA upgrade, but most organisations are planning to move to S/4HANA as part of their RISE with SAP strategy. The cost of an oversized test system may not be too eye-watering on traditional database systems, but when you move to the HANA database, the in-memory technology required comes at a much higher cost (typically more than three times the cost in our experience), and the ability to scale in small increments disappears. When a system breaches the space limit, the next size up is typically double, with the corresponding cost impact (less some economies of scale, you would hope).

Stop the meter!

The beauty of using Client Sync, part of the DSM suite, to refresh your test systems isn’t just that it means your test system(s) can go on a smaller HANA appliance or hyperscaler sizing bracket. It’s that your test systems can be frozen at that size, even if the production grows quite dramatically. The reason for this is that you typically use Client Sync to make a test system with 3, 6 or 12 months of transactional history. So when you come to refresh it in a year’s time, the size will only be larger if:

1. the business is transacting significantly more now than before

2. there is a lot more master data being created.

And even if one of those is true, you can bend the sizing a little by altering the slice date or limiting the test system to specific company codes only. Even if that is just a short-term measure until the next contract cycle.

Take DSM along for the RISE

Along with two other certifications, DSM is now ‘works with RISE with SAP’ certified. So whether you implement DSM before you go to RISE, or even as part of the project to move to RISE, don’t get tied into a RISE agreement with more space than you really need to be leveraging for non-production systems.