Can You Handle The Truth About Your SAP Software?

BrandPost By Tricentis
Dec 13, 2019
Enterprise Applications

Not understanding the truth about your SAP systems can have serious business consequences.

istock 134723331
Credit: iStock

A recent survey conducted by Tricentis and the Americas’ SAP Users’ Group (ASUG) found that 70% of SAP customers were not fully confident that their company understands the business and technical risks of migrating their existing SAP systems to S/4HANA.1

Given the complexity of most organizations’ SAP landscapes—for example, a company may have years of custom ABAP code deployed extensively across multiple production systems, each connected to numerous 3rd-party applications and all contributing to critical business processes—this uncertainty is easy to understand.

The fact is, many organizations lack the time or tools to fully understand the truth about their SAP systems. This can have devasting business consequences: cost overruns, missed timelines, system downtime, security lapses, lost customers, and PR disasters, to name a few.

These risks often deter organizations from updating their SAP systems in a timely manner. In his keynote speech at this year’s SAP SAPHHIRE NOW conference, SAP co-founder Hasso Plattner speculated that the average SAP customer was 6 years or more behind in their updates. When talking to leaders in these lagging organizations, upgrading or migrating to SAP S/4HANA is not even on their roadmap.

But time, tide, and digital transformation wait for no CIO. When the competition moves forward with innovations that speed time to market and increase efficiency, or when security defects are found in deployed software, standing still is perhaps the riskiest strategy of all.

Fortunately, there is a safe way to accelerate SAP software updates, but that requires facing the cold, hard truth about your SAP systems.

Exposing The Grave Dangers in Your SAP Landscapes

It doesn’t matter if your organization is planning an SAP S/4HANA conversion, applying an ECC service pack, or adding custom code to your current implementation. You need to know the truth about your SAP software and the impacts of the proposed changes before you greenlight any updates. A change impact assessment tailored for SAP software can tell you the risks of an update and whether your implementation’s unique blend of custom and standard code, configurations, settings, and external integrations is really ready for what comes next.

This assessment should be automated, giving you the twin benefits of speed and unbiased accuracy, and it must provide the following “truths” about your current SAP landscape and the technical and business risks associated with a proposed update:

  • How much custom ABAP code you have, how much is actually used, and where do low-quality, redundant, or obsolete customizations threaten the stability of your business processes?
  • Which features are business-critical for your organization and which are not even being used?
  • Who will need to be retrained after an update due to UI or process changes?
  • What are the non-SAP systems that integrate or supply data to your SAP systems, and will any integration break after the update?
  • Do you have security issues in your roles, authorizations, and profiles?
  • Where do applications, data, and processes differ across SAP systems?
  • What custom and standard objects are most at risk from the update and should be the focus of testing?
  • Is your test suite actually capable of testing those objects?

Lies, Damned Lies, and Test Coverage Statistics

Of course, knowing the truth is only half the battle. To ensure a successful update, you must test against the risks identified. The classic approach to testing SAP applications is to “test everything.” In practice, this usually means running all the tests that are documented, which is not only time and resource-consuming but provides no guarantee that the most-at-risk functionality was actually tested. At best, you’ll get a statistic showing the number of tests that were executed and passed. But these statistics doesn’t actually tell you how much risk was covered by these tests.

A Crystal Clear Solution

A much better solution is to use an impact analysis tool that integrates with a continuous testing platform. In this solution, the impact analysis should automatically:

  • Identify the exact objects to test to achieve 100% risk coverage for the update.
  • Generate a test plan that achieves 100% risk coverage using the fewest test cases possible (alerting testers when test cases need to be created to get to 100% risk coverage).
  • Report testing results based on risk coverage, making release decisions easier (and smarter).

Organizations using such a solution see 100% risk coverage for only 15% of their previous testing effort, accelerating the pace of their SAP updates by 40% or more.2

  But to realize these benefits, they must be willing to first face the truth.

Related Resources

[1]Tricentis and ASUG Research, June 2019

[2]LiveCompare customer survey