Why Years of SAP ERP Experience Makes Me Question if You Really Need That Custom Code

There is a joke that those of us with a few years of SAP ERP experience tell:

“If you believe you need to create custom SAP ABAP code to meet the business requirement, chances are you don’t understand the business requirement. And if, after further consideration, you still think you need custom SAP ABAP code to meet your requirement, you still don’t understand the requirement.”

Now that might sound harsh, but the reality is that if, after 30+ years, the number one ERP software provider doesn’t have embedded in their current S/4HANA solution the ability to meet a requirement without custom code, that’s a sign to reconsider what’s really needed. On one hand, maybe you don’t have a complete understanding of what SAP S/4HANA is capable of. On the other hand, maybe your business requirement needs a good revisit by a seasoned pro with some major SAP ERP experience.

With SAP’s GROW and RISE initiatives, which prescribe the installation of the S/4HANA ERP system outside of your own data center, there is minimal opportunity (if any at all) to just “cut code.”

Some have implied that SAP’s attempts to limit code cutting is a mean act. Image shows computer code It’s worth briefly calling out why this is better described as “giving us bitter medicine” as opposed to being an act of bullying.

S/4HANA and its predecessors are business applications mostly written in SAP’s development language ABAP. ABAP was initially described and truly was, similar to COBOL (Common Business Oriented Language) in that it was intended to be used for authoring business applications with minimal development experience. Given that SAP themselves were enhancing their ERP application and supporting new technologies (e.g. web browsers), the ABAP language evolved from its roots, with enhancements supporting object orientation constructs and much more.

Simultaneously, SAP was very unique among software vendors where the source code of their business applications were not just readable by their customers, but permitted them to not only build new reports and transactions but also author ABAP code to run within SAP’s own developed applications. This allowed SAP, along with their implementation partners and clients, to enhance SAP to meet essentially all possible business requirements. This access to nearly limitless customization undoubtedly contributed to the rapid adoption of SAP and the emergence of an ERP implementation industry where everyone could get what they wanted.

But then, two things happened.

First, SAP kept building. Through acquisitions and internal development, SAP has built extensive capabilities into their core ERP solution as well as applications such as SAP TMS, eWM, etc. SAP has also developed the ability to build applications outside of core S/4 ERP solutions through environments such as SAP BTP, or through very robust APIs (Application Programming Interfaces). The sheer list of capabilities is exhausting to review.

Second–and this one might be hard for some SAP experts to admit–integrators got lazy. Through implementation after implementation, many integrators with SAP ERP experience simply ”threw code” at requirements. In many scenarios, those requirements would have been completely satisfied by standard functionality if there was awareness. The remainder of the scenarios would have been addressed by changing how the business requirement is addressed.

A lot of that custom code stemming from so-called “‘lazy” implementations has stranded many existing SAP ERP systems in the past. The custom code often doesn’t work with the latest enhancement packs or S/4HANA, and justification to unwind custom code can be hard to make. The ironic part is that the custom code might not have been required in the first place if the business requirement was properly addressed with out-of-the-box functionality from SAP.

Sentence on how SAP ERP experts recommend meeting business requirements

An SAP project should have never been, but now is no longer reliant on an army of ABAP developers. Its success depends on having knowledgeable resources who deeply understand the S/4HANA module and other available SAP and non-SAP solutions and who are extremely comfortable in working with business requirements.

Reviewing and redesigning business processes to align them to standard SAP S/4 functionality is a core competency of the Vortex Consulting team. With over 25 years of SAP ERP experience under our belt, we’ve monitored passing trends and strengthened our approach to long-lasting ERP performance that is made to evolve and adapt as our clients’ needs change, too. Send us a message to learn more about how we can support your business.


About the Author: Matthew Montano is a Vortex Consulting SAP architect with more than 25 years of experienceSAP Architect Matthew Montano in Electronic Data Interchange, Supply Chain Integration, and Third-Party Logistics. His passion for good documentation and streamlined work process has yielded measurable results for clients in the consumer packaged goods, life sciences, manufacturing, and transportation industries across both the United States and Canada. Keep checking in for his “Musings with Uncle Matthew” series on the Vortex Consulting blog.

SAP Global Template Demystified: Process Design

We’ve talked about the fact that an SAP Global Template is so much more than process design. At the same time, you can say that it is nothing without a solid and sound process design at its core! This is where consulting expertise, business knowledge, and SAP software product experience intersect, where these different components must merge to form a beautiful piece of art. (For a refresher on this topic, please refer back to our earlier blog post, “Why Experience Matters on Your Road to S/4HANA.”)

Advice on SAP Global Template Process Design

When it comes to process design in the context of an SAP Global Template, I want to talk about some of the main concepts that come to mind:

  • Organizational Model – It is imperative to not only align the organizational model with the available structures in SAP (company codes, profit centers, etc.) but, also, to shape it in a way that creates templates. These structures need to be at the core of the building blocks to describe what an operating company vs. a holding company looks like, to distinguish the difference between a complex operation vs. a site business. They allow you to categorize the elements of your business fleet to identify the right starting point once the next acquisition or greenfield operation comes along.
  • Business Functionality – SAP has an extremely large portfolio of business functionalities. You need to be able to identify what is important for your company! Once you’ve established the core components of your business design, group them around the building blocks of your organizational model to establish the go-to pieces of your Lego puzzle! That allows you to start from a pre-built structure instead of starting from a single brick. As I’ve frequently said in previous blog posts, you need to avoid reinventing the wheel!
  • Level of Standardization – Part of the concept of the SAP Global Template is moving from having continued design discussions (“Business Blueprint”) to focusing on rolling out a pre-designed solution that needs to be adopted (“Fit-Gap”). It represents the shift from rehashing the basics to simply stating the obvious–if you are a business in the fleet, you need to comply with the direction that the overall enterprise takes. This will be the biggest factor for saving money in your SAP deployments, and, with it, the best guard against the useless over-customization of your SAP system that to this day plagues many companies out there.
  • Solid Documentation – We need to talk about the complexity of business design in relation to the short span of the human memory. If you do not document what you agreed upon, you have already lost the battle! Coming to conclusions in those endless blueprint sessions is a thing that you do not want to jeopardize afterwards! Simply write down what you agree on, put it in swim lane diagrams, freeze if in business design templates, lock it into configuration documents. In other words, put it in writing to save yourself from the hassle of doubting your memory as time passes! I agree, this is not the most enticing topic, but–by far–it is one of the most important, as many executives have had to learn the hard way! 

Allow me to come back to the question of standardization of the business design in your SAP Global Template. You need to talk about and agree on the rigidity of that design when it comes to systems configuration. Which parts would you allow to be changed by a given local business and where would you draw the line to defend the given corporate design? I find it very helpful to partition your functionality and master data into different categories that are aligned with said level of rigidity:

  • Mandatory, not changeable – These settings and functions are not up for debate. All parts of your business fleet have to adopt them as they are laid out, without any changes. You need to defend these elements with tooth and nail, as they are the pillars of the overall SAP design. Examples are foreign currency handling, supply chain handling, or production process elements that must follow a corporate design.
  • Mandatory, but expandable – You may allow the local business to extend certain pieces of your design in a way in which the result still fits within the corporate vision. Think, for example, about an organizational model where the local business wants to establish a more granular cost center structure than the one given by the template. Adding another marketing cost center or a more detailed work center structure in the production does, in its nature, not deviate from the overall design. It still complies with the spirit of the business design. I would caution you to still look out for Trojan design horses. When appropriate, be lenient in granting these requests.
  • Local – You will never be able to standardize everything. There will be local tax requirements, cultural “need to have’s” related to doing business in a certain country, the one-off odd (but hugely profitable) business in the portfolio–all legitimate reasons why design may need to deviate in a region, country, or line of business. Where advisable, don’t fight it, rather support it. Just make sure that the local deviation stays as the exception, not as the mainstream practice!

This brings us to the conclusion of today’s post about Business Process Design. In our next chapter of the Global Template series, we will talk about technical SAP Systems Environments. As always, thanks for your valuable time today! If you have questions about Global Template that you’d like to see addressed in future posts, we invite you to reach out via Twitter.