When SAP brought out it’s in-memory database, SAP HANA in 2010, there was a lot of excitement around how the technology would revolutionise the way organisations use the great untapped resource that is data.
This was initially limited to data warehousing but with S/4HANA now built on this same technology, using large amounts of data directly within an ERP environment is much easier and quicker.
So you don’t need to worry about your historical data anymore, right?
There are a couple of key reasons why proper data management is important when moving to S/4HANA :
SAP S/4HANA Data Size and Immaculate Data Mentality
S/4HANA’s SAP HANA in-memory database is used to store data for processing. In S/4HANA, much of the analytics functionality requires a lot of data.
Memory is much more expensive than disk storage. A decision must be made about how much data you keep in-memory versus the considerable cost.
If you look at public cloud IaaS solutions you can see the cost differential between an SAP HANA instance capable of working with 2 TB of data vs. a Microsoft SQL Server instance of similar capability is significant - think 10 times as much!
- SAP HANA’s data tiering functionality helps but it’s still in its infancy and not easy to get right
- Archiving - how many organisations have a suitable data archiving policy and have implemented it? With R/3 having been around since the early 1990’s it’s entirely possible that there are SAP ECC instances out there with nearly 30 years of data in them. Even if you have archived data, do you still need it? And, if you do, could it be reloaded into S/4HANA?
- Test Data - many organisations utilise at least one full-sized copy of production in their test cycles (I’ve known some keeping as many as 4 or more copies). In the new agile DevOps world, is this really needed? How quickly can you deploy a sandbox system with the right dataset?
The move to S/4HANA, whether greenfield, brownfield or data migration means that you have the ideal opportunity to review your data management processes.
It allows you to put in place processes and tools that will help you store only the data you need to support your business processes and do it online (hence optimising hosting costs).
If you can do this properly you have the basis of a toolset and process for true DevOps that inherently supports agile methodologies.
Keeping Data Secure in SAP S/4HANA
As well as thinking about which data you’re going to move to your shiny new S/4 system and how you’re going to do it, it’s also a vital time to think about how you are going to secure the data in your new system.
Who has access to your data? Do you have sufficient controls in place to prevent fraud or data access by unscrupulous individuals?
If you’re planning a Greenfield implementation, then it’s relatively easy to design a controls framework from scratch as you can implement standards across the new solution.
If you’re planning to go Brownfield via a conversion of your existing ECC system, you need to be sure that your users have access to new transactions and data structures and that you haven’t brought anything from your old ECC system that you don’t need.
- GDPR - There was a mad scramble to achieve GDPR compliance by May 2018. Did you achieve it in the right way? Or, have you unnecessarily affected your business processes and your development process?
- Testing - How many times has a change failed in production because the test data wasn’t appropriate?
Many organisations have a mix of manufactured and copied data in their non-production environments which can give different results.
Again, the move to S/4HANA is an ideal opportunity to review your controls around production data AND set up a test regime that allows your development process access to the right data at the right time.
I’ve not considered aspects such as relevance, accessibility and governance here as these are firmly in the realm of data specialists, UI and Functional consultants. However, these must also be part of your S/4HANA thinking.
Why you should think about relevance, accessibility and governance when it comes ot S/4HANA data.
There’s a reason why data (volume) management is not at the top of people’s lists - once you let it get out of control, it’s time consuming to get it right. In many SAP implementations, data management (usually archiving) is either dropped because of time constraints or configured but never implemented. Thus, there’s the temptation to leave it alone until someone complains or something like GDPR comes along.
So how can you fix historically bad or messy data in preparation for your S/4 move?
“Fixing” data as well as moving to S/4HANA may seem daunting - after all, it’s a significant proportion of your core business data stretching back years - but there’s a few things you can do to help:
- Look at your data before you start your S/4HANA Programme - reducing your dataset sizes across production and non-production before you migrate will reduce your infrastructure costs. And, it will reduce the outage to the business in the cutover event itself.
- Develop a strategy - this is not a one-off event and failing to keep on top of data with an immaculate S/4 data mentality will cost you dearly in the long term.
- Design for security - review your current controls and feed requirements into your S/4HANA design
- Invest in tools - don’t DIY - GSI (Get Someone In!). Whilst SAP does supply some tools as standard, they don’t cover the full range of requirements and don’t have a history of being particularly usable (although this may change).
There are a myriad of companies that can help with data scrambling for GDPR and consistent data reduction to reduce the size of production systems and create smaller, more usable test systems.
Taking a long hard look at your ECC data as part of your S/4HANA preparation activities will help ensure that your data is at its most usable for your business before and after your S/4HANA migration.
If you need help creating a strategy that will keep your data relevant, secure and cost-effective we can help.
Contact us today to get started.