The Myth of the Over-Customized SAP Instance or The Custom Code Fallacy

[robphelan]

With our brand-spanking-new SAP implementation, we have an opportunity companies rarely get - a freshly-installed SAP instance. Understandably, we want to make sure we 'Do Things Right', from a coding perspective.

Our direction was to go through pains to eliminate and avoid custom code - To keep the ratio of Standard to Custom to 90% / 10%.

• Custom code makes it difficult to rapidly integrate acquisitions into our business processes.


• Custom code makes our Production environment less stable.


• Custom code requires too much support.

 

Coming from outside of the SAP world, this all sounds sensible. The thing is, none of this is necessarily true.

 

Not all Custom Code is created equally

I like to say there are two types of custom code in SAP: Custom (with a capital 'C') code and custom (with a lowercase 'c') code.

 

custom code

SAP is great at letting a user create a Sales Order or a Purchase Order. What SAP isn't good at is providing the capability for users to create a thousand Sales Orders or a thousand Purchase Orders.

That's where lowercase 'c' custom development comes in.

It's our job, and it's completely appropriate, to create Order maintenance applications that allow users (or interfaces) to create, update, post, and most importantly, error correct transactions.

SAP just doesn't deliver that type of functionality. So, custom code is there to solve those problems.

From small reports to large-scale interactive applications... that's exactly the reason we have a full-featured development environment within SAP.

 

Custom code

The Custom code we really should be examining harder, challenging, and limiting, is the type where we're asked to crack open the standard Sales Order or Purchase Order to insert custom business logic in BADIs or User Exits - these types of enhancements interrupt the standard SAP document creation and business process flows.

 

These types of Customizations can change standard process flow

 

But if done correctly, even the risks that are introduced can be mitigated through smart development practices such as compartmentalization of enhancement code and using table-driven principles to drive code pathways.

I cringe whenever I see a user exit with 300+ lines of code, straight down. This is a prime example of bad Custom coding that introduces instability and is not supportable long term. This is where our focus should lie.

 

Consequences

As a consequence, companies will opt to buy 3rd party applications to replace functionality that really should be contained within SAP itself, not realizing that integration is typically required in order for those applications to run properly.

 

Insanity

 

I've seen apps that require up to 11(!) interfaces in order to integrate with SAP, just to send an FI posting doc back into SAP.

I'll repeat. I've seen 10 outbound interfaces to a cloud-based app which turns around, after user interaction, and sends an FI doc back into SAP.

The worst part is that each of those interfaces are necessarily custom developed, adding to the custom code base they were trying to reduce in the first place!

Insanity.

Lastly, each of those interfaces are potential points of failure. As we introduce more data hand-offs, the complexity rises. As complexity rises, more support personnel are required and time to correct issues increases.

 

Conclusion

In conclusion, custom code really isn't bad. And, there's no magic ratio. Keep it abstracted one step away from the standard SAP processes and you'll be fine.

Use custom code to enable new functionality and to facilitate and automate standard processes, not to change them.

 

And, if you are sending confidential sales and customer data to some cloud-based app in order to facilitate document creation back into SAP just to avoid additional custom code in your instance, you're probably doing something wrong.