Posted by

SAP Architect Matthew Montano kicks off his series on the Vortex Consulting blog:

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.