Paul has for many years been a remarkable technical force at EPI-USE Labs. As SVP of the ALM Products, his portfolio includes System Landscape Optimization, and his hands-on experience of implementing Data Sync Manager and helping clients to manage data across the breadth of their SAP landscapes is unique. He has specialised knowledge about data security and how GDPR (the General Data Protection Regulation) impacts companies running SAP.
Many of our Data Sync Manager (DSM) clients chose to buy DSM as part of a major project. Often this would be when the project highlighted early on the risk to the project of old test systems with inaccurate data. With many organisations planning to start their S/4 journey, I wanted to share how being a DSM client can help, before, during and after your S/4 migration; possibly the biggest SAP project you have on the horizon.
A lot of organisations have a sprawling SAP non-production landscape. Some systems are old copies of production and some multi-client systems are relics of old projects long since completed. Over the last 20 years, enterprise-grade storage has become cheaper and more manageable. As a result, SAP landscapes have been allowed to use ever more space. Knowing that S/4 is looming, with in-memory database technology being much more expensive than disk, now is the time to lose the excess baggage. And, at the same time, ensure you have good test data for every part of the S/4 project, however you choose to approach it. With DSM you can spin up new system shells, populate them with lean clients containing masked data and use these to replace existing test systems. Alternatively, you can use the Client Sync powerful client deletion capability to remove redundant clients and delete ones you want to reset with good data. Find out how to Uncover invisible SAP test data to recover costs.
There are a number of steps that can be carried out even before your S/4 project begins, such as the Customer Vendor Integration piece. This, and other factors, may begin a data cleansing and clean up project. Having the capability to bring data-on-demand down to the development or sandbox system could make these functional pre-projects much less time consuming and more likely to be successful in showcasing the work to be done on production. Reliable test data when you need it, select and copy only the data you need. See how Object Sync works.
Multiple SIs and niche consultancies may be involved in your S/4 project, and they may need to start looking at your non-production systems to provide recommendations, prepare analysis reports and scope potential projects. These organisations may be connecting from all over the globe and need to see accurate data BUT not real personal data. The number of headline-grabbing data breaches worldwide is growing: don’t risk someone downloading a table of sensitive data from a QA system and selling it to the highest bidder. Data Secure gives you complete control over all sensitive data.
SAP recommends a Sandbox first before your project starts in full. Read more about what happens in that sandbox here. The more accurate the sandbox is the better, but a full copy of production will mean a larger and more costly appliance. Use DSM to build a lean, dedicated sandbox for the project and consider the cloud, given that the duration of the sandbox project is not clear and the business has to be supported in the meantime. Read about how Ballance Agri used DSM in their Sandbox phase of S/4.
For anyone taking the brownfield approach, I would recommend considering how wide the gap is between the configuration, customisation and code in the development system and production. Over the years, that gap has got wider and wider with old Z-code abandoned, configuration taken to QA and then the project cancelled, and even third-party add-ons loaded in development but never uninstalled. Our migration teams use DSM to rebuild a new non-production landscape from the production system, as part of their cloud migration strategy. This could also be part of your S/4 migration approach.
Rebuilding development and QA from production means a cleaner start on the other side, with a smaller gap between development and production, so less chance of defects sneaking through. Some organisations have even done this with full copies as part of their migration then discovered the costs on the other side when it's already too late. Presumably, the reduction in the volume of custom code to be refactored is a strong driver for this. Using DSM to build out smaller new test and development systems can bring the same advantage in closing the gap between development and production, and reducing the amount of Z-code to rework, but at a fraction of the cost, since smaller appliances can be used.
With the ability to mask data on exit, you can also consider keeping a production environment on-premise and moving all your non-production systems to the cloud. Those are the systems that can benefit most from the elasticity of the cloud resources. Power up the systems during key project phases; switch them off when they’re not required. With Object Sync and Client Sync keeping test data up to date, there is no real person or sensitive data leaving your network.
Once your S/4 dreams have been realised, this will not be the end of the journey. The functional teams will want to embrace S/4 as the digital core to the intelligent enterprise. There are likely to be many follow-on projects leveraging the possibilities of AI, machine learning etc as your business looks to find, or keep, the competitive edge. All of those projects will need accurate test data and an agile non-production landscape. The much maligned TDMS solution, which led many of our customers to find DSM in the first place, does not support S/4, and from the changes we’ve made to our architecture over the last four years to handle new technologies used by S/4, it's hard to see how it ever could. DSM is used on S/4, is supported on S/4 and is certified on S/4.
As your SAP system accelerates away at the other side of the S/4 migration, its footprint will undoubtedly grow. Appliances will need to scale up, or scale out, but your non-production landscape may not need to. With careful planning and use of DSM Client Sync, you can keep smaller test appliances up to date with subsets from production, meaning the rate of growth of the test systems is far smaller than that of production.
Our S/4 Assessment Report can give high-level insight into the likely levels of effort of each approach, and early warning for any considerable blocks that may await, including:
SAP Readiness Check items that will be relevant for your system
Number of customers/vendors without BPs linked
Technical blockers such as Non-Unicode system
Areas of SAP used by your system which are no longer supported
Amount of custom code
Visual Interactive Dashboard of the system to frame up internal conversations
Book your free Assessment today. You can also get regular updates by subscribing to this blog thread; simply add your email address below under 'Get Instant Updates.'