Process Archives - Vortex Consulting

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

Jul
09
2024

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

Time Zones in SAP: Let’s Dig In

May
30
2024

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.

Decision-making Rights and Tools: Governance Series, Part IV

Dec
22
2023

Welcome to the final post in our 4-part blog series on program and project governance. In the first and second parts of our series, we discussed the differences between programs and projects, along with some of the key considerations when setting up program and project governance in your organization. In the third part, we reviewed the committees, bodies, and structures that are part of successful governance. Today, we will go over decision-making rights and tools to ensure the success of your IS programs and projects:

Decision-making Rights & Tools
Stakeholder Decision-making Matrix
RACI
RAID Log
Reporting & Status Management

Decision-making Rights and Tools

According to the Deloitte article “Getting Decision Rights Right“, ambiguity surrounding who is responsible for making a decision or decisions is a primary cause of delay in the decision-making process. Confusion about who makes which decisions and how they are made can increase the risk that some decisions will simply fall through the cracks entirely. Research shows that top-performing companies define roles, responsibilities, and process:

Simplify and clarify decision rights across the organization
Are transparent about expectations of accountability for decision makers
Align individuals in decision-making groups that work toward a common mission

Decision-making influences overall company performance, so it is critical for organizations to set clear roles and responsibilities. This clarity leaves little room for confusion, wasted resources, or lack of accountability. As process is established, consider these key objectives: (1) Give all those involved a sense of ownership over their decisions, and (2) Identify where individuals are best suited within the process–who should provide input, who should follow through, and who should ultimately be responsible for making key decisions in defined areas of the organization.

Key considerations for your organization before you start a program or project:

Who are the individuals or groups empowered to make decisions?
What decisions must be made and what is the timeline?
Who is responsible for deciding? Who will execute the work?
Who is accountable for the decision’s outcomes?
Who should be consulted for input, information, and insight?
Who should be informed about the decision and its outcome?
Each decision should have only one decider with single point of accountability.

Stakeholder Decision-making Matrix

A stakeholder decision-making matrix is a tool used to define and communicate who has ownership and who is responsible for the business processes, systems, and data that are part of a program and/or project scope. It can be used to reduce conflict and/or confusion on who should review and approve strategic and tactical decisions.

RACI Chart

A RACI chart is a simple diagram used in project management to map task-level roles and responsibilities.
A RACI chart defines whether the people involved in a project activity will be responsible, accountable, consulted, or informed for the corresponding task, milestone, or decision.

RAID Log

RAID is an acronym that stands for Risks, Actions, Issues and Decisions, and the log tracks all of those items within a project.
Using a RAID log enables project managers and teams to follow a consistent approach to project delivery.
The RAID log records information such as cause, probability, impact, mitigation, owner, etc. for things that could go wrong but have not yet occurred.

And that brings us to reporting & status management. This topic deserves it owns blog series, so watch for our coverage of it in the future.

In conclusion, by investing in your organization’s approach to decision-making rights and tools, you increase the chance of successfully achieving the objectives of your IS programs and projects. We hope you found the information in this blog series to be valuable. Reach out to us with other questions or to talk staffing support for your organization in 2024 and beyond.

Here are links to all other blog posts in this governance series: Part I: Understanding Programs vs. Projects | Part II: Defining Rules, Procedures, and Policies | Part III: Defining Committees, Bodies, and Structures

Defining Committees, Bodies, and Structures: Governance Series, Part III

Dec
14
2023

Welcome to the third in our 4-part blog series on program and project governance. In the first and second part of our series we discussed the differences between programs and projects; introduced the set of rules, procedures, and policies that determine how programs and projects are controlled, managed, and overseen; and discussed some of the key considerations when setting up program and project governance in your organization. In this post, we will discuss the committees, bodies, and structures that are part of successful governance.

Four Types of Committees, Bodies, and Structures:

Executive/Project Steering Committee
Program Governance Office
Project Management Office
Project Organizational Structure

Executive/Project Steering Committee

A form of corporate governance made up of high-level executives, authorities, and/or stakeholders who provide strategic oversight and guidance to one or more programs or projects within an organization.

Program Governance Office

Ensures that the program’s goals and objectives are aligned with those of the overall enterprise.
Standardizes project-related governance processes and facilitates effective communication and the sharing of resources, methodologies, tools, and techniques. It establishes the overall framework for execution of a corporate program, and it develops and implements policies, rules, and procedures to manage the program.
Collects data to monitor, analyze, and report on how well the program conforms with these policies, rules, and procedures; remediates any problems or vulnerabilities within the program.
Ensures standardization for projects across an entire program.

Project Management Office

Established for the duration of a single project or program.
Includes project delivery oversight, administrative support, controlling, reporting, and monitoring functions.
Performs a similar function to the Program Governance Office–only for a single project as opposed to an overall program.

Project Organizational Structure

Defines the reporting hierarchy and authority of people involved in a specific project. The structure defines each team member’s function for the duration of a project and the reporting lines can be viewed in chart form.
There are three types of organizational structures in project management:

1. 1. 1. Functional
    2. Project-based
    3. Matrix

SAP Project Organizational Structures Chart

See Essential Guide to Project Organizational Structure for more information and graphics inspiration.

Successful program and project governance are dependent on establishing and supporting the committees, bodies, and structures that approve and oversee budgets, timelines, project definition and scope, resources, and business outcomes. In the next part of this series, we will discuss the tools used to manage your IS programs and projects:

Decision-making rights & tools
Stakeholder decision-making matrix
RACI
RAID log
Reporting & status management

Reach out via email if you have questions on project governance that we can address on the blog or one-on-one. We conclude this series with our next post, and we’ll continue to answer incoming questions on LinkedIn as well.

——————

Here are links to all 4 blog posts in this governance series: Part I: Understanding Programs vs. Projects | Part II: Defining Rules, Procedures, and Policies | Part III: Defining Committees, Bodies, and Structures | Part IV: Decision-making Rights and Tools

Defining Rules, Procedures, and Policies: Governance Series, Part II

Dec
08
2023

Welcome to the second in our 4-part blog series on program and project governance. In the first post, we discussed the differences between programs and projects. In this post, we highlight the importance of defining rules, procedures, and policies that determine how programs and projects are controlled, managed, and overseen, and discuss some of the key considerations when setting up program and project governance in your organization.

SAP Rules, Procedures, and Policies Graphic

Key Aspects of Program and Project Governance:

A set of structures, committees, teams, rules, procedures, and policies that determine how programs and projects are controlled, managed, and overseen
Enables and promotes good, timely decision-making
Reduces risk

According to this Harvard Business Review article, by Paul Rogers and Marcia Blenko, partners at Bain & Company, “making good decisions and making them happen quickly are the hallmarks of high-performing organizations.” For capital investments especially, but even for operational initiatives, good decisions start with program and project governance. Programs and projects must have proper oversight and accountability, they must align with the corporate strategy and business goals, and the governance must span the program and project lifecycle.

Establishing a governance plan lays the groundwork for order and success. It creates a guide for the decision-making process, and it determines what will happen within the lifecycle of the program and project, when and how it will happen, and who is responsible. There is no one-size-fits-all program or project governance structure that can be used by all companies.

Successful program governance provides the following benefits:

Increases efficiency and reduces risk
Establishes a framework for managing issues, opportunities, risks, and competing priorities
Helps to focus resources across an organization to meet strategic business goals

Key considerations for your organization before you start a program or project:

Is effective project governance in place?
Have governing bodies been defined?
Have the rules, procedures, and policies that determine how projects are controlled, managed, and overseen been defined?
Have decision-making rights been defined and communicated?
Is there alignment as to who and how decisions are made?
Are project-related decisions being made in a timely manner?

When analyzing the answers to big questions like these, don’t hesitate to take action where improvements can be made. If needed, establish, reboot, and/or communicate key components of effective project governance. To increase the likelihood of success, it’s critical to get alignment on these items before starting a program or project:

Steering Committee
Project Management Office (PMO)
Project Organizational Structure
Decision Making Rights
RACI
RAID Log
Reporting & Status Management

In conclusion, program governance is a crucial aspect of project management that ensures the overall success of an organization’s initiatives. It involves a structured framework and set of processes that govern the planning, execution, and monitoring of multiple projects under one program. In the next part of this series, we will dive deeper into the key components of program governance and how they can positively impact project outcomes. More specifically, we will discuss the three pillars of project governance:

Project Structure – should be fit-for-purpose
People – the right people in the right roles
Information – timely reporting and communication

Send us a note if you have questions on project governance that we can address in our ongoing blog series. Look for our next post in the series soon.

——————

Understanding Programs vs. Projects: Governance Series, Part I

Dec
01
2023

Welcome to our 4-part blog series on program and project governance. In today’s fast-paced and ever-changing business landscape, being effective at both is crucial for organizations to successfully implement their strategic initiatives. In this series, we will explore the key components of program governance and project management, highlight their importance in driving successful outcomes, and provide practical tips for implementing them in your organization.

Let’s start with a comparison of an Information System (IS) program and project. An IS program refers to a long-term strategic initiative aimed at achieving specific organizational goals by leveraging information technology, systems, and processes. It involves managing and coordinating multiple projects and resources to achieve a broader outcome, such as rolling out a global SAP S/4HANA template over multiple regions and business units to establish a common ERP platform across your entire organization.

On the other hand, an IS project is a temporary endeavor with a defined scope, timeline, and budget, aimed at delivering a specific outcome or product. It focuses on implementing a specific solution to meet a particular business need or goal within the constraints of time, cost, and resources, such as implementing SAP S/4HANA or to innovate using S/4HANA and SAP technology.

SAP Program and Project Governance Chart

In summary, an IS program focuses on long-term, strategic, often organization-wide objectives, while an IS project is a more tactical approach that delivers specific and often narrower outcomes within a limited timeframe. Now that we have defined and discussed the differences between the two, we’ll shift focus in the next post to outline the key elements that go into successful governance, namely the structured framework and set of processes that govern the planning, execution, and monitoring of multiple projects under one program.

Reach out on LinkedIn or send an email if you have questions you’d like us to address. Our experts would love to help you elevate your program governance and project management to the next level. Stay tuned to our blog for more insights and best practices throughout the month.

——————

SAP Global Template Demystified: Process Design

Sep
14
2020

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.