SAP Data Extraction Made Easy

SAP Data Extraction:

Companies using SAP Data Extraction are focused on how to derive value from their investment in the solution, while supporting constantly changing business requirements. This manifests itself in many forms, from seeking to reduce the costs of supporting the landscape, through upgrading for new functionality, to extending the usage of SAP throughout the business. Pressure on SAP development and support resources is relentless, and this often leads to key activities being squeezed in terms of time, resources and expertise.

Business needs drive implementation timescales. Most companies find that Meskimen's Law applies to them: "There's never time to do it right, but always time to do it over." In the delivery lifecycle, this means the emphasis is on quickly building and deploying functionality, with limited time available for testing and training. The effect is to defer, but increase costs as issues are discovered and corrected post-implementation.

A strong quality assurance (QA) cycle, from initial requirements through to support is essential. A key part of the QA process is ensuring that the business requirements have been met.

Testers face many challenges within a limited timescale and SAP data extraction. They need clear requirements to test against and representative data with which to test. The obvious solution to providing test data is to periodically make a copy of the production system to create a QA environment. This sounds easy, however SAP testers face a tremendous challenge when attempting to reuse representative high-quality production data to support development, testing and training activities.

Why? The key issue is the size of the production database. It is not uncommon to find terabyte-sized databases supporting many of today's worldwide SAP systems.

The volume of data leads to the following problems:

- Replicating the database requires production level hardware in development, testing and training. This can be cost prohibitive for many companies.

- Existing data copying technologies require the production system to be taken offline, sometimes for several days. This is unacceptable to most businesses.

For larger companies, sap data extraction and the hardware costs for replicating the production system will normally be in the range of $600,000 - $965,000 and companies with smaller SAP systems can expect the cost to be in the hundreds of thousands of dollars range.

For those companies that use sap data extraction and test automation tools, experience has shown that it is impossible to develop repeatable automated tests without a known, stable dataset. Ask any tester what they spend most of their time on, and the answer will be creating test data. Even where manual testing is undertaken, 75% of the time spent testing is taken up with creating the data, and only 25% of the time is spent on the actual test itself. Test automation can only bring value when suitable data is available to run the test, and accelerates the time spent running the test. Only the combination of test data availability and test automation enables the use of repeatable tests.

Repeated client copies are time and resource consuming and the alternative of manually migrating data is fraught with difficulty (the R/3 data model is complex) and risk (inaccuracies in the migrated data lead to deterioration in the quality of the test and development systems). In addition, taking the production system offline, even for a short period of time, may not be an option.

Problems include:

- Data extraction dependencies: Data items such as Sales Orders do not live in isolation inside the

SAP data extraction database. There exist many relationships between data and to maintain integrity, the dependencies must be transported with the primary data item.

- Data structure customization: The definition of data items is different between releases of R/3.

Industry Solutions of R/3 also include modifications to the data structures. Customers can also enhance their SAP systems by customizing the data structures.

For a solution to be useful at solving these data management issues it must:

- Enable representative data to be transported from production to development, testing and training systems

- Operate without causing the production system to be taken offline - Manage data dependencies - Handle data structure customization - Be easy to use and modify