Over the last 22 years of working at EPI-USE Labs, I’ve realised that a constant and continuous client requirement is to have secure test data more regularly in non-production systems, with less system footprint.
An effective test data strategy needs to be both proactive and reactive to address certain business requirements. There are always business, technology and legal changes to contend with. The ability to have ‘Production-like’ data for testing at your fingertips fosters better levels of quality and service to your organisation. Your SAP® implementation is only as good as the data you feed it, and the SAP lifecycle is particularly thirsty.
In this blog, I look at some examples of changes that impact the data you have in the SAP systems, and how you need to cater for them. This doesn’t necessarily mean they will cross your implementation in this order; and they can be cyclical. To give you an overview, we have plotted them in a path to run through the various elements and explore how these will impact your test data strategy.
The SAP lifecycle is data thirsty
Privacy laws have progressed leaps and bounds since the introduction of GDPR (the General Data Protection Regulation in the EU), with many countries adopting their own privacy regulations. The concept of ‘privacy by design’ should be adhered to from the start of any project, and therefore should be part of your strategy even before go-live in your SAP implementation. You will undoubtedly have real and potentially sensitive data in your non-production systems. Key data pertaining to the Employee, Vendor, Customer, Addresses and Business Partner objects in SAP will need to be analysed and obfuscated. You may have other sensitive fields that are pertinent to your business that all need to be scrambled; for example, recipe information if you are a food manufacturer.
Authorisations in test systems can be laxer, and you may also be partnering with a System Integrator who could also have access to the sensitive data. This means the non-production environments could be a much easier target.
Data privacy is an important element that needs to be addressed throughout your lifecycle. With heavy penalties attached to lack of compliance with data privacy regulations, it simply cannot be ignored.
The moment you go live, the data in the systems should be of the best quality. Production and Quality systems are typically in sync and all is well, but then life happens! Transactions and interfaces hit your Production system, and it can grow rapidly. In my experience, the system growth can vary between industries, and is amplified within businesses which manufacture goods, as well as B2C industries such as Utilities. Your non-production systems are quickly left behind in terms of data correlation and relevance. Ultimately, this will make testing going forward less reliable as time goes by.
A key requirement for SAP test data across your business is to resolve issues in Production. These can typically be caused by configuration issues, but in order to resolve the problem, you cannot have users fumbling around in your Production system to recreate and test the issue. Basis teams cannot authorise an SAP Client Copy or System Copy to entertain such granular activities because of its invasiveness (and the data would also be unscrambled).
Dealing with Production support requires secure, swiftly-produced, current data into a test system to help resolve issues quickly. Users may also need to clone data to test multiple scenarios. Once an issue is resolved, a configuration fix can then be transported securely to your Production system, safe in the knowledge it has been effectively tested.
SAP Support Packages and upgrades are fundamental to getting the latest enhancements from SAP into your system. They are typically fuelled by configuration updates or legal change requirements. The latter is a challenge, especially for companies running SAP HCM and Payroll. Before organisations apply support packages, they need to be robustly regression-tested first. Having real-life data in your test system enables proper, realistic testing to be undertaken to ensure ‘gremlins’ do not sneak through to your Production system.
A very important requirement is training your people on how to use SAP. Over the years, we have seen clients simply use a full system copy to create a training environment. This can be a sledge hammer to crack a nut. How much of the data is the training going to consume? Probably very little. It may be very hard to undertake a system copy because of the Production system size and the downtime of the target system to undertake this. Also, the training system then has sensitive information which will need to be scrambled.
Typically, the development system is small and does not have much data. The usual approach is to transport the development straight into QA where there is data in order to test. To get the development correct could take many iterations, meaning there are many previous transports in trying to get the config right that will never make it to Production, or be moved there one after the other, depending on your change management policy. Either option still leaves some room for manual error, and is time-consuming.
For multiple and global projects, companies typically set-up a parallel ‘project-track’ SAP landscape. This typically consists of a Development and Quality Assurance system. For successful projects, quality data will be needed in this landscape to ensure proper regression testing, before the new configuration is transported into Production. In addition, companies often outsource such projects to System Integrators, where components of their businesses are off-shored, hence there is also a key data compliance/privacy angle which must be adhered to before giving access to potentially sensitive data. The data must be scrambled before access is given.
Since the recent pandemic, the increase of Mergers and Acquisitions rose significantly. Amazing to think that even in the worst economic topography ever experienced, companies continued to buy others. A technical carve-out or merger can be the answer. This system landscape optimisation (SLO) project requires technical and functional understanding to be performed accurately and cost-effectively. Sunsetting some of the data could be an option where systems are no longer in use.
Moving to the cloud often makes sense, but only if your SAP landscape is optimised. Having full copies of Production in non-production systems is cumbersome and expensive as you will be charged typically by GB. We have even seen some clients with multiple copies of Production. Naturally, clients have reached out to EPI-USE Labs to help reduce their SAP system footprint, but it’s essential to do this before the contract with the cloud provider is signed, if the non-production system sizes are locked in.
RISE with SAP drives innovation in key business processes with SAP S/4HANA®, and its uptake continues to grow. Getting there also requires data optimisation. S/4HANA Appliance costs can prove quite costly, and full copies of your Production system in non-production systems does not foster a positive business case. Getting your house in order before you move to RISE is advisable. Once you’re there, the non-production systems do not need to grow as the Production one does. A time-slice of the system will only be bigger than previous copy backs if the volume of transactions has increased in the slice period, or the master data is growing dramatically.
Moving to the cloud, system divestitures and RISE with SAP or migrating to a different ERP vendor all have significant legacy system implications. Such business and technological transformations give organisations the opportunity to optimise their new systems in terms of data. There can be legacy data that serves little value in your new systems, but needs to comply with internal company rules, statutory tax laws, and also global data privacy legislation and regulations. Such data needs to be continuously online and available for clients to reference. We have seen many clients who have divested parts of their business years ago still have the old data on their Production system.
The SAP data copy challenge
The SAP lifecycle is thirsty. The cost of having poor-quality data in your test systems is immeasurable. A well-known oil company stated that the cost of having their Production systems down, when it is unplanned, was in the region of $ 1 million per hour. SAP offers standard data copy methods such as Client Copies and System Copies. Both have their merits, but they are all-or-nothing approaches that can be data-invasive. EPI-USE Labs’ clients have often said that Client Copies are just not feasible because of the time required to refresh test systems as a result of the system size. Also, with both of these approaches, the data being transferred to the target system is not scrambled.
For a while, SAP entertained Test Data Migration Server (TDMS) as a solution for its customers. This essentially was born from its System Landscape Optimization business, and ‘shoe-horned’ into test data creation. The announcement that TDMS is not compatible with SAP S/4HANA shows it is nearing its end of life.
Given the data-intensive SAP lifecycle, our clients highlighted an intrinsic requirement to have ‘Production-like’ data more regularly in non-production systems, on demand, with less system footprint, and scrambled.
Solve test data management challenges with Data Sync Manager
EPI-USE Labs developed our Data Sync Manager™ (DSM) suite to solve test data management challenges. It has four main components and enables:
- Creation or alignment of system shells.
- Copying of data objects for data on-demand.
- Copying of clients where you would like to reduce the footprint. You can use a time slice or an enterprise slice or both.
- Scrambling of data for data privacy compliance.
Why choose EPI-USE Labs’ Data Sync Manager (DSM) suite?
- In the market place for 25 years
- Designed specifically to address SAP lifecycle challenges
- Delivered via ABAP transport
- Integrated with your current authorisations model (also shipped with additional solution-related authorisations)
- All in a dedicated /USE namespace which cannot interfere with SAP or client existing developments
- Created with a simple user interface
- Caters for both business and IT SAP test data requirements
Leave a Comment: