Jim MacLennan; Executive Director of IT, Pactiv Corp.

You classify your custom code using three basic categories.  Can you describe what they are?

The first is code that nobody is using any more, but we never got around to removing it from the code database. It may be reports people asked for in the past or custom screens that were used and delivered business value for a time – but we went to a different process or introduced new functionality, and didn’t bother to take the old code out.  Or there are things we built and nobody used them because the underlying processes changed.

Next is custom code for which standard code now exists. When we implemented SAP 12+ years ago, there were a lot of things that didn’t exist in standard product, or maybe we just didn’t like the standard functionality. The biggest cluster of customizations came in the EDI area – the content of standard SAP iDocs has improved since we created our custom iDocs, and we have begun replacing custom with standard. This customization is good to target, because changes should not impact end user interfaces or business processes at all.

The last group is code that is specific to certain user groups and how they do things. This is the classic type of customization.  One area that everybody customizes is order entry, for example. We’re aware that there could be standard functionality available now, but it’s going to be a big change management issue because the business doesn’t necessarily see the point of changing. What we have works, it’s in place, what’s the problem?  You always have to balance IT concepts like “total cost of ownership” and “easier to maintain, easier to upgrade” with the business perspective; “I’m getting a lot of business value out of this customization.  If it costs IT some time and effort to manage it, they’re going to have to deal with that.”  If it’s serving a good business purpose, of course you’re going to leave it in.

How do you find and get rid of that first class of custom, the code that isn’t being used?

In the past, we looked at usage statistics using the SAP ST03 Workload Monitor, which gives you a log of aggregated system activity and workload statistics, and compared that to usage statistics from a third-party product that performs similar activity logging. We can generate a list of all the customizations in the system, then compare that to the logs and find customizations that are never used. But that’s a manual, time-consuming process and it’s not entirely foolproof.  We’re evaluating third party products from companies like Panaya. These tools automate the process that we’ve been doing manually. There’s value in the automation because it streamlines the process and makes it more best-practices driven.

To what extent have you tested these products?

We spent time over the last 6 months to a year going through trials, having them look at our code base and giving us a decent idea of how big our code base is compared to what we thought it was.  They have helped us identify how much customization we have in use and not in use, so we know what we’ll need to “touch” to go to ECC 6.  We estimate the tools would cut the time it takes to identify custom code by about 30% vs. our manual process – a non-trivial chunk of savings.

What about the second class – how do you find the customizations for which standards are now available that weren’t previously?

We review our customizations and group them according to functional areas, such as EDI, SD [Order Management], LE [Warehouse Management], and then review current standard product to see if similar functionality is available. Again, it’s a manual process.

Regarding the third class, how do you find these instances?

For large-scale customizations, we know what they are; there are only a handful of them.  Like order exceptions or certain warehouse transactions, we know we’ve customized them extensively. Every time the business process changes such that we require different functionality, we re-evaluate to determine whether standard functionality is sufficient or not.

How much custom code have you eliminated thus far?

Since we began this effort about two years ago, we have eliminated about 500 customizations. Most fell into the category of “obsolete” – no longer in use.

That’s kind of an odd number because some were simplistic escapes and others were relatively large programs; each could be one customization.

What benefit have you received from the effort?  Can you quantify an ROI?

To date, we have not quantified the benefit, but we have upgraded one of our SAP instances after eliminating a large chunk of customizations. The technical leads involved in that upgrade feel the process was improved – it was speedier, with fewer complications.  We didn’t need a better ROI than that because it was all done with internal labor.  However, since we are discussing bringing in third party tools, we will have to “dollarize” the productivity gains, to come up with a clear ROI.

What advice do you have for other customers who want to reduce the amount of custom code in their SAP environments?

Definitely look into the tools that are on the market. When you can clearly identify code that is simply never used, and automate the tedium of syntax and basic functionality checks, you should be able to take a significant amount of effort and risk out of the upgrade question.

Also, develop an appreciation for total cost of ownership of a customization. Understand that when you customize the heck out of a system, it becomes your system; it’s not as generic, it’s hard to find resources, it’s hard to be agile and change the business because you have to undo your customizations. So when you absolutely must have a customization from a business perspective, try to quantify the actual business benefit vs. “Well, that’s the way we’ve always done it.” Anything you can get to help quantify things, to get the conversation away from, “I really feel I need this customization,” to “This is what it costs and this is what the benefit is,” are always helpful.

ERP Executive is published by Panaya.