As SAP is extended and expanded, it spawns a network of transactions, potentially written in different languages, and some inconsistencies in data models. An SAP implementation is not just SAP, it’s JEE, JSP, HTML as well as custom ABAP. Analyzing the characteristics of these applications by hand requires a set of experts in each language, and tends to be expensive. There are excellent tools for analyzing the individual technology, but in a complex and expansive environment like SAP, what is required is a tool that can analyze across technology environments.
The ability to look at processes horizontally (between layers) and vertically (within the environment) give developers and auditors visibility into how the transaction is executed, where the holes might be and how to bring the transaction into compliance. Like many distributed systems, the code triggers activities in all three layers, so not only was it necessary to analyze the custom code, it was also essential to map how that code integrated with SAP. As the graphic shows, the analysis engine was able to identify several areas where there may be performance or maintenance issues.
Interfaces are almost always a neglected part of the code. But when the overall system performance is examined, enhanced interfaces are a surprising performance boost.
Few SAP implementations avoid custom code. While the intent is always to reap the benefits of reuse inherent in the SAP business model, staying just within the SAP standard code is simply not possible. SAP transport and control process work well within the ERP’s environment but it is not ideal for managing multiple environments. Many SAP implementations forget the size of the non-SAP base.
Successful implementations invest in a set of processes much like DevOps where the tools are used consistently across environments. Using one of the external tools that allow more robust “versioning” and packaging will make the release process much more predictable and stable.
Is your SAP environment improving? A simple question with a surprisingly complex answer. Most companies really don’t know factually. Perhaps ticket counts are measured, possibly support costs, but real, concrete data is hard to find. When you consider the effort in logging a ticket, most users simply live with it. If the environment is outsourced, the rumblings tend to be toward the vendor but without concrete data, very little improvement is apparent.
The problem grows more complex with transactions outside SAP. The quality of the add-ons and the extensions is rarely obvious. Analytics need to be put in place to manage add-ons, or else the risks of the add-ons will become the risks of the whole system.
In a recent product demonstration, CAST showed us that their curated assessment model provides risk evaluation of identified defects and cumulative effect on business value. This was great news to us, as it now becomes possible to measure supplier effectiveness. All of this happens before the issues can migrate into production and create a problem for the users.
The management of a supplier is much easier when there are facts and clear expectations. Having the data improves the relationship, and drives better value.
Purchasing an off the shelf application does not eliminate custom code. The issues faced by SAP implementations are made worse by the need to integrate across environments. Quality cannot be outsourced to the SAP package.
This is Part 2 of a two-part series on SAP custom programming. In Part 1, we focused on Performance Tuning of your SAP Deployment.
About the Authors
Scott Beckman is an independent consultant specializing in process improvement and the technology to support them. Formerly a Partner with PwC in the SAP and BPO practices, Scott has used his broad range of experience multiple Fortune 50 clients, driving enterprise value.
Bill Dickenson is a former IBM executive with extensive experience in SAP dating from R/2 and the early days of R/3. He writes on a variety of application development and maintenance topics focused on getting value for the software investment.
To learn more about Scott and Bill's venture, visit Strategyontheweb.com
Erik Oltmans, an Associate Partner from EY, Netherlands, spoke at the Software Intelligence Forum on how the consulting behemoth uses Software Intelligence in its Transaction Advisory services.
Erik describes the changing landscape of M & A. Besides the financial and commercial aspects, PE firms now equally value technical assessments, especially for targets with significant software assets. He goes on to detail how CAST Highlight makes these assessments possible with limited access to the targetâ€™s systems, customized quality metrics, and liability implications of open source components - all three that are critical for an M&A due diligence.