Skip to Content

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.

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. Shai Sinai

    I didn’t catch the difference between Custom (with a capital ‘C’) code and custom (with a lowercase ‘c’) code, nor the technical/business difference between them…

    (0) 
  2. Michelle Crapo

    Very nice blog…  Totally agree.  I have yet to work with a company that does not have custom code.  It is what makes them better, more profitable, and ease of use.

    Custom code is not bad.  Bad custom code is bad.  Third party software usually requires custom code.  I think that is your point above too.

    (0) 
  3. Patrick Van Nierop

    Thanks for this blog! The timing is perfect as well (with the new mission statement of ‘keeping the core clean’ and all).

    I’d just add that besides enabling new functionalities and the automation of standard processes, it is necessary to extend standard processes as well. And in my book extending does not need to mean changing those processes.

    (0) 

Leave a Reply