Story time
What if the news and headlines are talking about nothing else but the ever expected – and now becoming reality – the impact of massive asteroids to Earth? How could you overcome this life-threatening challenge? How would you survive?
You would need a sophisticated weapon destroying the large rocks long before hitting the surface. Little pebbles would burn up in the atmosphere, little pieces of rocks reaching the Earth could potentially hurt but not harm mankind. That simple! But do we have such a weapon?
Where is the link to SAP?
When we look into your upcoming S/4HANA transformation challenge, the sheer number of SAP standard changes coming feels like asteroids impacting the Earth and consequences can be dramatic to your business except you had a powerful weapon to understand the impact of change and to mitigate risks accordingly. Not only for the S/4HANA transformation but also with any bigger SAP project this is a valid concern. The following questions need to be answered beforehand:
• What are the user impacts? Which business areas are affected from process- and user interface-changes? People need to get trained in time to avoid productivity dips.
• What custom code will break? In average about a third of business functionality depends on custom code. Does this sound familiar to you?
• What’s the impact on other systems that interface with SAP? The supply chain usually integrates with other data supply systems. Data is integrated into SAP processes but is also sent to other systems.
• What are the security impacts? Your roles, authorizations and profiles will change. So, how to make sure critical data is protected from an unauthorized access?
• How to accurately size and safely reduce your data? What data can be retired with a transformation to S/4HANA?
Why is the essential to understand the impact of change?
Beside a transformation which builds the most complex SAP change, SAP deployments typically consist of
• SAP standard changes like SAP Support- or Enhancements-packs.
• SAP customizations typically known as your Z-Transactions.
• A combination of both at the same time.
In any case, a bunch of objects such as user interfaces, transactions, programs, table structures etc., is changed with any deployment, in the first case probably more than in the second. However, it is about the exact understanding WHICH objects change and HOW do they link to your business processes. Only by deep understanding you can reduce the test effort, hence risk to release. By saying reducing the test effort, this also links to test automation. Not the one with the most 10k+ test cases wins but the one who covers the most risks with the least test cases, i.e., has automated the right stuff!
Take it the other way: usually you might have an idea today which business transactions are touched by the change, but the knowledge about the exact impact and if there are any side effects remains vague. This results in the “test all”-approach. The drawbacks of this knowledge leak are manifold:
• A “test all”- approach in the whole SAP landscape is simply not realistic. Firstly, a lot of functionalities might not be actively used in your environment but where to draw the line for test? Secondly, who would cover all of these efforts? Can you put even more test load on business key users?
• Key users must spend more of their time to test things that might not be impacted at all.
• The number of releases cannot be increased due to massive test efforts. Testing seems to be the bottle neck. In contrast business requires more agility.
• SAP standard releases are procrastinated as they are the most critical ones from the impact perspective. Too many changes, too much uncertainty. Not bringing business advantage at first hand. Better do it later. But doing it later, comes with the next drawback: the batch size becomes larger and larger, risk is increasing. The next disliked transformation project ahead.
Proper impact analysis can overcome these difficulties.
What is your weapon of choice?
Sounds great, you just need to understand the impact of change and you are good. But HOW is this actually working? One thing is clear: the technical complexity of single deployments in most cases is far from easy understanding what to test. So, what can you do to gain insights?
The first option is to task an armada of SAP consultants to identify implications. This is time-consuming and therefore costly. And remember, doing this for one transformation project might be a valid approach but what about all these daily SAP transports, from smaller patches, custom changes to support and enhancement packs? Consultants might be gone, problem stays.
The other answer, you need to have permanent tool-support. You need to address the technical impact first to understand higher level implications on business processes. SAP compared to other platforms has one advantage: its code base is accessible. And this fact allows tools to reveal changes from one deployment to the next. And this helps you to understand test demand.
Conclusion
Today we’ve found out that to understand the impact of change is essential at any time in the SAP lifecycle, during a S/4HANA transformation but also in standard operations mode when support packs or custom code changes will be applied. If you want to reduce test effort for key users but at the same time keep pace with regular SAP releases, a tool for impact analysis gives you the necessary insights.
However, a tool is just a tool and what you make out of it is the key.