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

I have a distant yet distinct memory from a client in the U.S. Midwest (with a popular restaurant billboard that quipped  “where butter is king”). In it, a heavy duty trolley was pushed around the office every morning, delivering dozens of reports, each with hundreds of pages.

The company was in the middle of migrating to an online reporting tool that was outside of SAP ECC where each user could create their own custom report and–in theory–require absolutely zero IT support. I thought it was a noble and realistic goal. 

But it never happened.

While the printed report and the trolley went away, the SAP custom report that IT had to support didn’t.

Here’s a bar bet that any SAP consultant would make: all SAP implementations end up with a custom report that has become embedded in how business is done.

The genesis of the report was likely to join together information which wasn’t otherwise connected by SAP. Chances are, the since-updated platform no longer provided an obvious out-of-the-box transaction to meet the requirement, prompting cries of “that was the way we used to do it in the legacy system!”

Someone wanted just one extra field… then someone wanted it to be emailed automatically… then someone described extending the existing report off in a different direction because the SAP custom report was in a comfort zone.

The report likely ends up being a performance hog with business logic and assumptions deeply embedded in code. The report likely becomes so intertwined with how business is done that additional changes are technically cumbersome, change management is significant, and the report never gets any faster to run.

And so the SAP custom report becomes the Zombie Report. It won’t die, it won’t go away, and change is expensive. Every year it creates a technical deficit that contributes to an accumulating technical debt.

So, what can you do?

Standard SAP is Standard SAP

SAP has provided an incredible amount of  reports out of the box, with many of them having been added in recent years. Using them is “free” compared to building and sustaining your own.

If you believe standard SAP doesn’t meet your requirements, a good first question is, “Why?” Are you trying to use SAP in a manner disjointed to how it was designed? If you truly believe your organization’s needs are special, you are likely going to be already bumping against using SAP in a non-standard manner. Creating a custom report might be symptomatic of a deeper problem of using SAP in a non-standard manner and could be a catalyst to revisit why you aren’t using SAP as it was intended.

External Reporting Tools

Well beyond the scope of a crabby consultant blog post, there are many tools that place control of the data they report in the hands of the user. While there will be some setup work to ensure that data is interpreted and reported correctly, they can enable you to avoid the hardwiring in SAP ABAP code assumptions and the creation of a single monolithic, inflexible custom Zombie Report.

But why is there really an SAP Custom Report?

But any nightly printed report, or even one pulled from SAP through a Zombie Report, becomes inaccurate the second after the report is run.

The harder, but far more valuable activity is to revisit how the Zombie Report is being used, then go beyond just finding a standard or external report, but rather reengineering the process away from the report mentality. Instead of someone running the Zombie Report, visually looking for conditions that might trigger an action or workflow, you may even be able to turn to a decades-old SAP capability that can systematically find those conditions and trigger an alert. SAP’s Fiori tiles are geared towards an automobile dashboard philosophy where they provide a visual indication of a condition. I’m betting your team will find the convenience of this newer alert system light years ahead of the alternative–dealing with a clunky and challenging Zombie Report. 

If your company is trapped by the technical debt of an SAP custom report and wishes to explore more efficient options, I invite you to reach out to the team at Vortex Consulting to help you get things straightened out. Call us at 1.888.627.3640 today.

About the Author: Matthew Montano is a Vortex Consulting SAP architect with more than 25 years of experience 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.

Check out his previous blog posts here: Why Years of SAP ERP Experience Makes Me Question if You Really Need that Custom Code / Time Zones in SAP: Let’s Dig In / Daedalian ABAP Source Code (aka Throw us Old Folks a Bone) / ZZXREFDETAIL–SAP’s Dreaded Universal Cross Reference Table (…that your favorite SAP functional consultant hates to see) / Listen to Your Elder EDI Integration Consultant’s Advice When it Comes to Planning Your Next S/4HANA Move

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

Back in the late 1990s–decades before S/4HANA made its way onto the scene–my first full SAP implementation took a team of a couple dozen SAP consultants about 9 months. In addition to focusing on the successful incorporation of multiple currencies and languages, my secondary responsibility was the full EDI integration of 30+ EDI transactions across about a half dozen EDI trading partners. With just a part-time technical resource and a Windows NT EDI Server–which has less computing power than the phone in your pocket–we did it all on time and on budget.

So what’s changed since then? Today, the topic of EDI integration as part of their S/4HANA project can strike fear in even the most hardened of CIOs. Fear of exploding budgets, fear of racks of expensive servers and software licenses with fancy names, and the fear of endless consulting bills.

All because we need to exchange several hundred bytes of correctly crafted letters and numbers that represent a Purchase Order or an Invoice?

How did the everyday work of EDI integration become intimidating?

I have some theories and some recommendations on how to think about EDI as part of your next project to keep you from running away scared.

A key question is, “What is EDI?” Although formally known as Electronic Data Interchange, it is better described as Electronic Document Interchange. In its most accepted definition, it is the electronic exchange of relatively standard messages that mirror a paper document such as a Purchase Order, Order Confirmation, or Invoice. Not only is the content of the message often a mirror image to a paper equivalent, but so is the timing and frequency. Most companies use EDI standards from the early 1990s and only exchange them every 10-15 minutes. This is all fine.

There is a separate integration world where none of these norms apply. For example, integrating SAP with an internal Warehouse Management System (WMS) is very different. Sometimes the connections might be synchronous (in which both systems exchange data and there is a confirmation almost instantly). Sometimes there are multiple WMS systems that require significant transformation of the messages.

Solutions such as SAP Integration Suite (as part of SAP BTP), or third-party suites such as Boomi or Mulesoft, are built for non-EDI integration scenarios. In other words, they are made for scenarios like those I’ve just outlined.

But dragging EDI into the same integration world could unnecessarily kill your budget and be intimidating to all involved. Consider these red flags:

If you hear the term “canonical,” be wary. The concept prescribes that messages from different sources are all mapped into a single internal common structure and then mapped on to their destination structure. This might sound like a great way to simplify building and testing. But the EDI standards themselves already represent a canonical standard, one that is already a middle-aged global standard that is proven to accommodate nearly every business scenario. Additionally, when using SAP, you are almost assuredly going to use an IDoc, which is by definition a “canonical” itself.

“Canonical” approaches frequently fail because of the telephone-game problem: too many transformations.

If you hear the phrase “IDocs are dead; APIs are the future,” you might want to hang up the phone. API (Application Programming Interfaces) is the collective term usually used to describe a live connection between two systems. Terms such as RESTful, SOAP, and OData correspond to the various protocols. Need a real-time check of inventory or calculation of a price? Then an API-based integration is the approach to take. But EDI messages are like their real-world equivalent; completely intended to be handled in batch. Connectivity with trading partners is through connections, with names like AS2, sFTP, or X.400–all batch technologies, and many of them still operating on 10- to 15-minute cycles.

There is considerable effort and risk–along with minimal benefit–taking API technology into an EDI world.

Your elder EDI integration consultant will undoubtedly share many stories where an EDI message was implemented that never gets used or doesn’t deliver the benefit that was expected–despite an extensive effort to implement it.

A classic example is the Purchase Order Change (EDI 860) message. In most SAP implementations, once a Sales Order is entered, there are minimal opportunities to automatically change it. A Sales Order has been credit checked, inventory allocated, and items possibly already shipped. Expending the effort to fully integrate a complicated “Purchase Order Change” message, which is already a business exception that has minimal chance to actually update an SAP Sales Order, is likely not a good investment.

There is no shame in saying “no” to integrating some EDI messages and asking the business to just go manual. 

EDI is a very mature technology that does mesh well to SAP S4/HANA but needs to be respected for what it is and what it is not. For further experience, insight, and guidance on integrating EDI with your SAP solution, I invite you to reach out to the experienced EDI integration consultants at Vortex Consulting. Contact us at 1.888.627.3640 today.

About the Author: Matthew Montano is a Vortex Consulting SAP architect with more than 25 years of experience 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.

Check out his previous blog posts here: Why Years of SAP ERP Experience Makes Me Question if You Really Need that Custom Code / Time Zones in SAP: Let’s Dig In / Daedalian ABAP Source Code (aka Throw us Old Folks a Bone) / ZZXREFDETAIL–SAP’s Dreaded Universal Cross Reference Table (…that your favorite SAP functional consultant hates to see)