The Vortex Consulting Team is excited to be on-site at SAP for Utilities 2025, the premier North American gathering for utility ERP professionals, taking place September 8–10 at the Colorado Convention Center in Denver. We’ll be engaging with cutting-edge sessions on SAP-driven transformation—from Cloud strategies and asset management to AI-powered analytics—helping SAP clients turn complexity into competitive advantage. To learn more about the conference click here – see you there!
Vortex Consulting has been chosen by a leading aerospace and defense manufacturer to provide SAP GTS consulting support as part of full lifecycle implementations for their A&D and Industrial Groups. The consultant will lead and participate in requirements gathering, design, configuration, testing, training, and go-live support, with a focus on customs management, compliance, and risk management. Additional responsibilities include developing functional specifications, maintaining technical documentation, supporting workshops, troubleshooting issues, and providing end-user training. This engagement ensures the client’s SAP GTS system is optimized for regulatory compliance, trade management, and operational efficiency across multiple business units.
Vortex Consulting has been selected by a leading food and beverage company to provide onsite SAP S/4 EWM support. Two Vortex consultants will assist with the Go-Live of the Extended Warehouse Management system. The engagement includes monitoring system performance, addressing issues in real time, and ensuring a smooth transition during the critical launch period. This support helps the client achieve operational readiness and maximize efficiency from day one.
Motivations for SAP upgrades range from cost, compliance, and revenue growth to financial performance, among others. However, nearly all these drivers face hidden barriers. In discussions with customers about data quality and archiving, two recurring themes often emerge and are highly relevant to SAP S/4HANA transformations:
• Misaligned data retention and destruction practices • Limited exposure to enterprise-wide information governance principles within the business
Defining your Ground Zero, where your foundation is solid and where it needs reinforcement, begins with one simple, strategic question:
“How do we handle data retention and destruction?”
The answer to this question reveals more than just policy gaps; it shows how much control you have over cost, timeline, agility, and ultimately, transformation success.
Information Governance is Ground Zero, before Phase Zero even starts.
It’s where you start:
Controlling project scope and cost.
Reducing long-term IT operating costs.
Enabling agility to shift with markets and tech.
Creating a foundation for trustworthy, transparent data.
From Patchwork to Purpose
My first encounter with SAP archiving was 25 years ago. Imagine this: 18 months into a multi-plant rollout, it stalls at “Live” sites due to data volume issues in revenue-critical processes. We fixed it with archiving, but it was a patchwork solution.
Even today, archiving is still often viewed as a technical cleanup, disconnected from broader governance and transformation strategies. That perspective limits its value. The great news in the Ground Zero perspective is that you have a clean slate to innovate governance that can scale with your company’s ever-evolving requirements.
A future post will cover the essentials of Phase Zero. For now, let’s stay focused on the bigger picture.
Why ILG? Why Now?
Information Lifecycle Governance (ILG) is the management of data from creation to destruction. Wrapped around that lifecycle are the Three P’s:
Policy – Is it modern, enforceable, and relevant?
People – What is the RACI for ILG?
Processes – Are they scalable, cost-effective, and structured to service your business?
Many organizations still depend on data retention policies designed for paper records or legacy systems. That’s like trying to increase revenue with a CRM that holds both current and obsolete contacts and preferences—it slows down progress, obscures insights, and risks eroding trust. Why would out-of-date policies still meet today’s goals for growth, compliance, or customer experience?
A VP and a CFO from two separate companies recently discussed similar objectives for their ILG efforts.
Accountability for governance
Ownership roles that drive clarity
Best practices that minimize silos and promote transparency
Reducing data footprints ahead of upgrades or cloud migrations
Sound familiar?
Before You Plan Your SAP S/4HANA Transformation
What could your transformation look like with early visibility into quiet barriers—and a clear path to address them before Phase Zero begins?
Positioning Information Lifecycle Governance (ILG) as Ground Zero sets a foundation for buildable value. It identifies the same decisions, innovations, and ownership models that your S/4 transformation will rely on.
By addressing these barriers early, Phase Zero gains meaningful traction, with a clean core strategy, stronger accountability, and alignment across the business.
Let’s start the conversation…
That’s how transformation builds lasting momentum. And that’s where we bring focus, structure, and value.If you’re ready to explore where your ILG stands today, we’re here to help. Learn more about Vortex Consulting’s SAP Data Volume and Archiving services, or contact us to get started today!
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?
An essential question is this: Why is there a report in the first place? The entire concept of a report was born when computers were expensive, both for CPU performance and the cost (at the time) of an interface, such as a screen and keyboard. The solution was to use lower cost computing cycles–often in the middle of the night–and relatively cheaper paper for a printed report that was delivered via a trolley to your desk the next morning.
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.
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.
SAP Architect Matthew Montano continues his series on the Vortex Consulting blog:
I think the Las Vegas odds are good that your SAP ERP system has a custom table starting with Z and a name like ‘XREF…’.
Why am I so sure that’s a safe bet?
After 25 years, I’ve seen far too many SAP functional consultants and developers stumble across a requirement where the answer is to utilize a cross reference table. The solution inevitably ends up being a custom database Z Table. (Of course, there is always the question as to why custom code was needed in the first place…you can read more about my thoughts on that in my previous blog post on custom SAP ABAP source code.)
More often than you realize, the implementation of a quick custom database Z Table means skipping all of the additional documentation that a custom solution would warrant. Conversely, using SAP in the manner it was intended can minimize or eliminate the need for additional documentation and security controls.
And, of course, quick solutions are almost always shortsighted–focusing on a solution for now and not how it might support the next similar requirement.
A good SAP functional consultant can avoid inadvertently creating a house of cards combination of custom tables and custom code and additional unique dependencies. You definitely want to avoid the “short blanket syndrome” where you leave your feet cold for no reason.
So here’s what the process might look like:
It all starts with a simple “If the Sales Area is X, then set the flag to Y.”
Everyone gets excited that the business requirement has been quickly addressed with the ~magic~ of the Z Table.
Then other custom functionality uses the same Z Table.
Then someone forgets to update the table.
Then someone updates it incorrectly (maybe with something as simple as entering an O versus a 0?).
Then someone forgets to update the documentation that describes how to update the table.
Then someone corrupts the table.
Then the table is not included in the system backup.
Then an auditor asks why a single user has single and solitary control over dozens of core functions of your SAP system.
It never ends well.
In almost all cases, your SAP functional consultant can offer a better solution that respects all key aspects:
Maintains data integrity
Ensures security
Delivers appropriate validation
It often takes a few extra lines of code to retrieve the data, but the benefits of everything that SAP already provides is almost free.
Below are some ideas so you too can avoid the dreaded Z Table.
Do you need a value that is different by customer, vendor, or material? Store it along with the rest of the Business Partner (Customer or Vendor) or Material data. There are numerous existing fields that might already suit your requirement. If not, adding additional characteristics is easy for a well-versed SAP functional consultant.
Do you need to track a value that varies by Sales Area or Purchasing Organization? Why not create a customer or vendor with a fixed partner number and store the data there?
For more complex requirements, SAP has built an entire toolkit named Business Rules Framework plus–or simply BRFplus–that provides an entire infrastructure to securely store and validate cross-reference data. A small learning curve can yield extensive benefits.
There are numerous other SAP-supported capabilities to store data within SAP GTS, SAP CRM, the IDoc/ALE Integration, and more. Use them!
So, the next time someone suggests using a Z Table to store data, stop them. It is absolutely worth the investment for the long-term stability of your solution to ensure that critical data is stored in the right place so it is subject to the correct validation, security, and retention controls.
If you feel your project needs assistance in finding better solutions to meet your business requirements, please do reach out to Vortex. SAP functional consultants are at the center of our ERP solutions offering. Contact us today to get the conversation started.
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.
SAP Architect Matthew Montano continues his series on the Vortex Consulting blog:
In my experience, there are generally two circumstances where we end up reading SAP ABAP source code. The first–we need to improve custom functionality and so have to understand how it was built. The second is when the red siren light is flashing–and we’re on an open-ended, 24-hr. emergency conference call about missing invoices, reviewing code that was copy-and-pasted from an acquisition 15 years ago and trying to understand what broke.
In neither circumstance should ABAP source code read like a new installment of Dan Brown’s The Da Vinci Code.
So why do developers author code that might only make sense to themselves?
SAP ABAP is an optimized language. Consultant hours are expensive. Given that bytes are essentially free and obnoxiously clean code with extensive comments makes no impact on system performance, there is no reason that any code can’t also make some friends.
The vast majority of the ABAP source code that is authored is solving a business problem (that theoretically hasn’t been addressed by SAP already, which I have plenty of thoughts on…but that’s a different post). So if the code is trying to solve a problem, there’s a good possibility that the underlying business requirement (or those nasty assumptions) has changed, so chances are very good that a business user (aka a functional consultant) will need to read it at one point.
Your average SAP consultant probably has some development experience from when they learned BASIC on their Apple II or Commodore 64 in the 1980s. The younger ones might have learned Borland Turbo Pascal on an MS-DOS clone in the mid-90s. Most of us can stumble through nothing more than a complex Excel formula.
But too much ABAP source code I see is missing any narration of what the requirement is and how that requirement is being addressed, especially when using complex ABAP commands.
Whatever your organization’s approach to solution documentation and change management may look like, there shouldn’t be a single line of ABAP code that is written (or changed) without a clear reference to an Object ID, requirement, or change number. I’m a functional consultant–not a crime scene forensic detective. I’m not even adverse to seeing wholesale chunks of the functional specification straight in the ABAP source code.
Does the code use one of those fancy new ABAP constructors such as “dereferencing generic references”? That’s all and well–but could you throw old dudes like me a bone as to what the code is intended to do? (I guarantee any other senior level consultants involved will appreciate the gesture.)
(Using an “if” or “case” statement? Why not tell us what you are IFing or CASEing?)
And I’ll go ahead and offer one more tip while we’re here. This one starts with a question: What is with variable names turning into a game of “trick the parents” by using the fewest number of letters possible? ABAP variable names can be 30 characters long. Go ahead and use a few so everyone involved knows what purpose the variable serves.
Customized ABAP source code is almost assuredly the result of a long and often expensive process of requirements and specification reviews and approvals. That code will be subject to testing and probably changed several times by other teams. Given its placement within SAP, it’s doing something important–if not critical–for the business, and it will likely get changed by developers you’ll never meet. ABAP source code should reflect this very important role in SAP solutions and not be treated like an unfortunate afterthought.
If you need help upgrading your ABAP development standards, consider reaching out to Vortex Consulting. Our consultants have decades of experience developing and implementing SAP solutions that get the job done today and are well aligned for your organization’s future growth and evolution. Email us here or call us directly at 1.888.627.3640.
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 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
SAP Architect Matthew Montano continues his series on the Vortex Consulting blog:
“Can you figure out why all these EDI 214 Transportation Carrier Status messages were failing?” I was asked almost 20 years ago.
The EDI message was failing a validation in SAP because the carrier was indicating they were arriving before they left. But the EDI message contents seemed correct and the carrier was creditable and clearly not trying anything of disrepute.
This was a rabbit hole. And I like rabbit holes.
In the real world there was a delivery to an address which should have taken about 40 minutes of driving time. The truck was known to have left at 9:50 local time and the carrier claimed they arrived at 9:30 local time. What? How can you arrive before you leave? I know my client was hiring very punctual carriers, but that might be too good.
Anyone who lives near a time zone boundary or has experience flying internationally knows exactly how this happens. But, in this particular scenario of a delivery entirely within the U.S. state of Tennessee, SAP’s ECC (and S/4HANA to this day!) did not know how this could happen.
Why the world uses time zones was probably something we all learned in elementary school. Some of us might remember pictures of old, complicated train schedules. Then, for many of us, back when long-distance phone calls were expensive, we learned again the importance of time zones when calling family members so as not to accidentally wake them from a slumber and ensure we were calling after 6pm for the evening discount rates.
As we aged, depending on your vintage, we entered the working world, and scheduling meetings with colleagues around the world may have involved some coordination. But even that has become mostly transparent with Google Calendar or Microsoft Outlook.
Then again–missing a meeting is one thing, not posting a financial document in SAP S/4HANA is another.
Time zones are used extensively, but not consistently, throughout SAP S/4HANA. While the system time zone is the SAP default used for recording date/time stamps, the explicit recording of time zones are found in Business Partner Addresses and carefully recorded in many transactions. As we discovered 20 years ago, care is required when working with time zones in SAP, especially when recording and validating crucial business transactions.
It may be easy to presume that time zones are firmly just in the realm of Logistics, but, in fact, they are very important in the other areas of SAP. In a global company scattered around across the world, how do you handle financial period closes? There is a definitive answer.
So what was happening to those trucks in Tennessee? SAP ECC thought Tennessee was in a single time zone–U.S. Central Time. But as anyone who lives in Tennessee (or Florida or Kentucky) knows, the state is in more than one time zone. So the carrier was reporting their departure and arrival in “local time” and SAP ECC was correctly raising an error. It didn’t know any better!
In diving further down the rabbit hole one could easily assume that SAP has the country of France, with its clear footprint at the center of Western Europe, in one time zone. But in actual fact, SAP does correctly capture that France, given the multiple French dependencies scattered around the world, is actually a part of many different time zones. (France is considered to have more time zones than any other country.)
So today, in 2024, what’s the issue and why are we talking about it? Well, SAP does actually provide the ability to configure that 13 U.S. states (and 4 Canadian provinces) are in multiple time zones. The problem? When it comes out of the box, S/4HANA doesn’t know this.
But there is more! The rabbit hole is actually much deeper. Although designated time zones and their boundaries might not change often, politicians are in control of it all. And then add another layer to the discussion by considering daylight saving time–which countries observe it, which don’t, and which have changing views on the matter. Just look at the currently proposed Sunshine Protection Act and you’ll be reminded that our use of daylight saving time could certainly change in the future. Heck, Mexico ended daylight saving time within the last two years.
SAP is built to handle all of these changes, but once again not necessarily out of the box. Care and discipline is required in ensuring your SAP system doesn’t do crazy things like arbitrarily declaring a carrier as a fraud. This is a core competency of the team at Vortex Consulting. With over 25 years of SAP experience, we’re well versed in the intricacies of optimizing SAP performance and ensuring reporting malfunctions like those around time zones are avoided. 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 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. Keep checking in for his “Musings with Uncle Matthew” series on the Vortex Consulting blog.
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. 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.
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 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. Keep checking in for his “Musings with Uncle Matthew” series on the Vortex Consulting blog.
It’s worth briefly calling out why this is better described as “giving us bitter medicine” as opposed to being an act of bullying.