One of the allures of SAP has been the pre-built business transactions which promise speed to value and the ability to leverage code. With the business processes, transactions, and architecture defined, success must be just around the corner. The reality has not quite kept pace. 54% of organizations experience ERP project budget overages.
When discussing SAP performance, it is important to isolate configuration (changes in SAP tables that change how a process executes) from customization (new code, new programs or add-ons). We refer to the customizations as RICE (Reports, Interfaces, Conversions, Extensions), and they typically occupy about 20-35% of the effort. As SAP begins to move into more cloud based environments, the penalty for inefficient or poorly designed code becomes real.
The usual performance bottleneck in today’s environment is database speed. Not that the DB itself is slow. Today’s database engines have excellent optimizers. Having a predefined business model and a predefined database eliminates considerable effort but it also puts constraints on how data should be accessed.
The performance tuning rules (e.g. coding for index seek instead of scan) are the same for SAP as they are for any database. In many SAP implementations, performance engineering is a “backend” function, to be done once the system is in the final stages of a release. Under the best of circumstances, only about 20% of the performance issues and defects are discovered through manual inspection and even then, the cost of remediating these so late can be 50 times the cost of fixing that same flaw in development.
Instead of trying to figure out which areas are issues, all of the customizations should be scanned and then CISQ (link), IEEE (link), and OMG (link) standards applied to all of the languages supported by SAP. With the complete transparency of language, this makes the flaws quite clear.
For example, if a sluggish transaction was analysed, and we discovered multiple flaws in the SQL processing. We can take a systemic approach which examines all of the possible gates. Optimal performance requires eliminating as many gates as possible. Each language and environment brings it’s own set of complexities to an implementation. Chances are that one or more add-ons have been purchased and the number of SAP customizations and extensions is daunting. CAST has reported that this kind of systematic approach has helped one of their clients reduce the execution time of a problematic transaction from 11 hours to 2 hours.
This does not surprise us. Using a standards-based approach has the advantage of being backed by research and then proven in the field. This is not a theoretical exercise, this is reality.
This is Part 1 of a two-part series on SAP custom programming. In Part 2, we will focus on Analysis and Code Management across multiple languages, and driving continuous improvement in SAP.
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