Daedalian ABAP Source Code (aka Throw us Old Folks a Bone)

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.

Image shows ABAP source code writing

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.

ABAP Source Code Quote

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 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. 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

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.

Map that shows SAP time zones

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.

SAP S/4HANA time zones quote

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 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.

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

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.

The SAP Talent Gap: Finding the Right Team of Experienced Consultants

The SAP talent gap has come to the forefront in industry conversations around digital transformation and mandatory upgrades forecasted for the next several years. This recent Forbes article shines a spotlight on the growing talent gap in the SAP ecosystem, particularly in relation to the migration of existing ERP systems to the S/4HANA platform. SAP has set a 2027 deadline for migrating legacy ERP systems to S/4HANA–and most of SAP’s 425,000 clients worldwide have not started their migrations yet. 

While SAP S/4HANA can be used both on premise and in the cloud, the benefits of utilizing cloud technology are continually growing, convincing more and more organizations to make its adoption a priority. Organizations that wait too long to make the transition to the cloud may face difficulties due to outdated infrastructure. For an increasing number of organizations, it just makes sense when migrating to S/4HANA to simultaneously manage a move to the cloud. 

With just 3 years remaining until the SAP deadline, it’s clear that there will be a surge in migration projects, leading to an unprecedented demand for qualified talent and a growing concern over the SAP talent gap. Many organizations will face challenges when recruiting top talent for their own teams and in finding partners with experienced consultants who are available.

Working with experienced SAP consultants is crucial for any organization looking to maximize the potential of SAP software and to reduce risk when executing SAP projects. SAP is a complex and constantly evolving platform; working with consultants who bring varied and robust experience to the table is essential to ensure successful implementation and ongoing support of the system. 

Statistics about SAP talent gap concerns for 2027

In the early 2000s, the push to offshore SAP project delivery work exposed challenges when working with less experienced resources. Many projects were delivered behind schedule, incurred cost overruns, and resulted in functional and technical issues post-delivery. It was not unusual to have to invest significant capital to re-implement and clean up the issues. This experience led to the onshoring of many roles and to changes in how companies engage offshore resources. Moreover, it highlighted the importance of finding experienced SAP consultants and employees with SAP skills.

Senior SAP consultants provide the following benefits: in-depth knowledge and expertise, business acumen and familiarity with industry-specific processes, the ability to handle different SAP modules and integrations, an understanding of system upgrades and changes, efficient problem-solving skills, deep industry contacts and network, exposure to different project types and sizes, and an understanding of best practices. Those advanced skills lead to faster deployment and implementation, cost and time savings, and overall lower project risk.

Vortex SAP consultants have 23 years of experience

The number of years of SAP experience is just one part of the equation when it comes to delivering a high-quality solution. At Vortex it is as much about understanding your corporate dynamic as knowing the SAP system. We take pride in forming true partnerships and working with our clients to find the best teams for their needs.     

In summary, it is expected to become more and more difficult to find the right resources given the growing SAP talent gap and the surge in demand to migrate to the cloud. Experienced consultants bring a wealth of knowledge and expertise, helping organizations to streamline processes, increase efficiency, and achieve their business goals with SAP. In this competitive business landscape, partnering with experienced SAP consultants can give businesses a competitive edge and ensure they are making the most of their SAP investment. At Vortex, we are confident that we bring the best teams in the industry to help our clients be successful. Send us an email to get a conversation started with a member of our senior leadership team today. 

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.

SAP Global Template Demystified: Rallying the Troops

Its people are the biggest asset of any company. The same is true when it comes to an SAP Global Template–it is only as good as those who establish and manage the platform. This requires that you keep those key people informed, educated, and involved. Only then can you ensure that they understand the direction, are working toward a common goal, and are ultimately willing to defend the system that has been built.

Quite often the change management impact in an effort as big as rolling out an SAP Global Template is profoundly underestimated. And even if change is generally embraced, that may not be enough to bring people on board. The message has to be clearly spelled out: Change is not the enemy but rather an opportunity, ready to be seized!

SAP Global Template Consultants

Let’s define some meaningful categories of key contributors to get closer to their needs:

People Impacting the Global Template
From executive sponsors who oversee teams implementing the Global Template, to the business people designated to support the implementations, you have to enable them with educated buy-in, access to the right tools, and recognition. And when it comes to recognition, go beyond the handshake! A well-structured incentive program may get your internal resources truly invested in the projects, allowing you to avoid much more expensive external help. In reality, the difference between a lousy and an excellent team meal could be significant motivation to go the extra (hundred) miles!

People Impacted by the Global Template
Try to walk in their shoes instead of telling them how brilliant you are. There is no success without acceptance! Make a distinction between people who accept the new world and the ones who don’t–and treat them all with dignity. Someone may just want to ride the existing state into the sunset, while others are eager to embrace change. You need them all. Don’t alienate them for no good reason! You can accept that someone does not want to go on the SAP trip and may rather choose a different position or retirement. They can still be of great help if you treat them right. Support the willingness to change as much as you can as it will contribute to a smoother, more successful process overall.

People Preserving the Impact of the Global Template
You need to defend what you built, and you cannot leave it to chance. The support team that you install needs to monitor across the board, ensuring the many elements of the Global Template are preserved and truly alive! You need to give them purpose and respect; they are NOT an appendix to the operations, but an essential and critical part of it. It starts with your Center of Excellence, includes the various Business Governance functions, like Master Data Management, and also something that is often forgotten–the harvesting of brilliant ideas to ensure continuous improvement from people in the field who really know what works and what doesn’t within the system.

SAP Global Template Team

When we talk about giving people the tools, it starts with governance of the Global Template project–the do’s and don’ts, and, also, the maybe’s that you need to foster creativity. I have found over the years that it is of utmost importance to define and communicate the boundaries around which people will interact with the Global Template. Consider these categories:

  • Global Must-Have’s – Mandatory and therefore not debatable
  • Global Can-be’s – Extendable, used as add-ons to mandatory settings
  • Local Needs – Elements that are better left to the locals

This ties back to executive messaging reinforcing that these rules are there for a reason. This clarity will help tame the “too-free spirits” in the field and also functions as guardrails, helping people walk by themselves.

In our next chapter we will talk about the Governance tools that should support the effort of creating and deploying your coveted Global Template. 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.

SAP Global Template Demystified

Welcome to the first in a new series on the Vortex Consulting blog. Join us over the next few months as we explore the ins and outs of SAP Global Template.

It isn’t about configuration. It isn’t the business process. Nor is it about documentation. It is about all of that and much more. An SAP Global Template (“GT”) is a blueprint to success, a holistic view of all elements of your SAP journey!

To achieve the promise of cost savings, rapid deployment, efficient support, and a solid return on investment, the breadth of standardization must cross the enterprise as a whole, including people, process, and systems.

The challenge is that many consultants, and firms, attempt to give guidance about SAP Global Templates, but only a few truly understand it. When embarking on the exercise, many people quickly realize the complexity and either give up or go only part way. To avoid this frustration and expenditure, you need to plan a GT like a major project, then embed it into your business strategy and long-term deployment plan(s). Finally, it has to be supported with expertise and experience, either in-house or through external advisors.

Vortex Consulting SAP Global Template Guide

Today’s post is the first in a new blog series we are launching. In the coming weeks, we will explore the underpinnings of an SAP Global Template and touch on the topics that need to be considered for standardization. And yes, it’s all about streamlining and standardizing to avoid reinventing the wheel in endless blueprinting sessions. With the concepts we will explore, your team can develop the software fabric that will allow for rapid, agile deployments. This strategic activity will generate acceptance in the organization with a right-sized overall SAP environment that supports the business vision and strategy.

Elements of an SAP Global Template that we will explore in upcoming blog posts:

SAP Global Template Elements

All these elements need to be considered in the context of already existing enterprise IT and business structures. None of them can be seen as a stand-alone effort. Each is a critical part of the foundation that can support the weight of future SAP deployments. When done right, an SAP Global Template can turn a possible burden into an IT strength, leading to a deep acceptance throughout the organization as it generates a “common language” for the deployments of the SAP package across the entire fleet.

Before we end this post, let me take a moment to drill deeper into the idea of a “common language.” This is not a question of whether English is your worldwide project language. It is one of the single most important success factors of your SAP journey. You need to create a dictionary of SAP Global Template business terms and take the utmost care to teach it, reiterate it, and defend it! Yes, you need to defend it until it becomes ingrained into the business DNA! Why? It is difficult enough to bridge a potential gap of languages, cultures, and countless other variables when rolling out an SAP road map across the enterprise. You should not add the unnecessary complications of debating if you refer to a division as a “group” or a “business line.” Clarity minimizes confusion and could literally save millions in wasted dollars.

It is the clarity of thinking strategically, speaking with the vocabulary of convergence, and the holistic inclusion of all aspects that makes an SAP Global Template successful. And you can be the designer of this thriving system, with the help of your trusted advisors. 

Check back next week for the second post in this series, and be sure to follow us on Twitter to stay up to date on all the latest news from the Vortex Consulting team.