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

——————

SAP GT Demystified: SAP Model Company

Sep
04
2020

This may be a strange thing to open with, but stick with me… Laziness–at least a bit of it–can be a good thing. In my view, a healthy dash of laziness coupled with a pinch of procrastination usually leads to the quest of searching for the simplest solution, therefore fostering efficiency. And several great minds have talked about the fact that depicting the solution to difficult problems with simplicity is an expression of deep understanding.

SAP Model Company Business Model To avoid falling for the urge to reinvent the wheel during SAP implementations, isn’t there a way to utilize previous learnings, other people’s experiences? That’s where the SAP Model Company comes into the picture. It can be the seed or foundation for your SAP endeavor based on two flavors:

SAP Model Company by Industry

The focus rests on the industry that the company operates in, be it Chemicals, Pharmaceuticals, Mining, or in another vertical altogether. All of them have best practices that are unique to the specific industry, which set them apart and require years of experience on the part of the SAP implementer. The respective SAP Model Company has that experience already “baked in” and can be a guiding light in the maze of the vast SAP functionality.

SAP Model Company by Line of Business

These model companies are based on a department or part of any generic enterprise, like Finance, Shared Services, or Supply Chain Planning. They help you by putting a baseline into the sand that is rooted in the best practices and the experience collected from thousands of successful SAP implementations.

Photo credit: SAP

I also want to encourage you to watch this helpful 2-minute video from SAP, which lays out a compact and precise vision of the SAP Model Company.

Now, you might be wondering, how does it relate to a Global Template? Well, even a Global Template can benefit itself from a template. As I pointed out earlier, a little laziness could be the secret sauce in your Global Template recipe!

After having covered the basics, let me share my personal view of the SAP Model Company:

Don’t ignore a valid accelerator. (In some regards, your business needs are not as unique as you think!)

Of course you think your business is different than others. The common rules don’t apply, and certainly no one else could dictate how your business is run. Really? What would be wrong in learning from the findings that thousands of successful world class businesses have made? Why not gain from their experience? Don’t be arrogant when it comes to a helping hand–the SAP Model Company deserves a thorough thought!

Use it in a way that is suited for your business.

You may be a smaller company that can use the template as is. A typical example would be a Venture Capital firm that bought an idea and operationalizes it with the help of the world-class SAP software. While not having the appetite to overinvest in IT capabilities, use of the SAP Model Company gives reasonable assurance that you’re on the right track.

Or, you may represent a large-sized company that only uses it as a seed to tailor their own template. Think long and hard about what the right way is, as it will be nearly impossible to turn around for a complete do-over at a later stage!

Even if you think it does not fit, it will still have value.

Should you decide not to use the SAP Model Company for your Global Template or SAP deployments, you can still learn from it. There is so much experience there that it can serve at least as a guiding light! Analyze and understand the pieces and functionality that are utilized in the SAP Model Company that is most relevant to you, your industry, and your line of business. Use that knowledge as an accelerator, as well as a logical boundary for implementing what’s truly needed.

Have your own Global Template in mind!

While the SAP Model Company is a good starting point, never get lazy in your thinking! Have your strategy and road map in mind and assess how it furthers your goals, makes life easier, and helps bring value to the business. Let me state the obvious–while your business is probably not vastly different from some others in the field, a “one size fits all” solution will not be appreciated. Now is the right time to do cherry-picking, to shed the wasteful or flashy “bling” and create a solution that fits like a well-tailored suit!

This brings us to the end of today’s post on SAP Model Company. In our next chapter of the Global Template series, we will talk about Business Process design. 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: Governance

Aug
28
2020

Boring. Dull. Beige. Unnecessary. Overhead. You’ve heard it all when it comes to governance. It’s known to lack excitement in the eyes of many consultants and even IT decision makers. Who wants to deal with budgets and committees when you can focus on the go-live instead? On the surface this is understandable–but it’s also just plain wrong!

Both strategy and execution need governance, and so does the SAP Global Template. A Global Template is about discipline, about creating and preserving a backbone in your ERP endeavor, a solid tree trunk from which you can branch out to create exciting new leaves in your IT portfolio.

Now, you might be wondering, why bring up governance as it relates to Global Template when, in fact, it’s related to all areas of business? And the answer is, quite simply, that GT governance is separate from IT governance. We cannot push down the “handling” of the creation and deployment of a Global Template into a regular SAP ERP project. There is more to it, requiring a separate structure to manage the template. It’s our responsibility to call attention to it as a stand-alone item.

Consider the following elements, which I consider to be requirements for a solid governance strategy:

Governance of the Template Strategy
Aligning with best practices, SAP Model Companies, industry solutions, and other influencing factors has to be at the core of the Executive Governance of the Global Template. It is pivotal to understand the difference between continued evolution and necessary revolution (the structural upheaval from R/3 to S/4HANA) and the impact on the overall IT organization (road map, human resources, capabilities, budgets, etc.).

Governance of the Template Evolution from Idea to Result
You need an intake medium to properly shape the pipeline of future functionality. They handle the selection process, proof of concept, budget and ROI calculations, and the risk assessment to see if an idea will lead to a tangible business benefit. In addition to a strategy management software, it is advisable to have a Global Temple “Guardian” Committee that includes both IT and Business. Further, preselects will be established, with functions that can be deployed at designated time frames. Also, you need to be able to step into the future by configuring and testing Proof-of-Concept deployments in non-production systems as this will enable a healthy pipeline.

Governance of the Template Deployments
While it is certainly part of the regular PMO procedure to handle the roll-out of a Global Template to the organization, there are key differences to stand-alone projects. You need to avoid any aspects of reinventing the wheel (E.g., rerunning blueprint sessions) and focus on the management of deviations (E.g., concept of fit-gap). Also, a harmonization of SAP environments (systems and clients) between deployments, maintenance, and parallel proofs-of-concept is necessary.

Governance Support Software Solutions
SAP has many tools in the portfolio that are embedded in ERP solutions. While there are many, I would like to highlight a select few:

- Strategy and Portfolio Management – Helps to harvest ideas and bring them to fruition in an orderly fashion
- Project Systems – Often underestimated, it can manage projects end-to-end and integrate them with Finance
- Product Lifecycle Management – Managing products (which do not have to be tangible!) in all aspects of their evolution
- Solution Manager – An often disregarded or simply ignored tool that can help you manage and document your SAP landscape and functionality, a fantastic way of governing within the SAP software

Other products not owned by SAP are obviously very helpful, too, though I’ll spare you from a lecture about MS Visio and MS Project.

I do, however, want to steer your attention to two other, relatively new products that deserve to be mentioned:

AMIGO by Platinum PMO: The AMIGO tool focuses on the holistic governance of the digital transformation process and integrates seamlessly with SAP. It can describe and manage the whole lifespan of your Global Template as well as deployment projects. It is described as “governance to ensure your community is playing by the rules and working in perfect harmony.” I could not say it better, and I do buy in to the concept!

Bella Scena: This resource offers a fresh take on meeting governance. Bring purpose to meetings by actively managing them and get out of the mode of asking yourself, “Why do I need to be here?” Bella Scena is very reasonably priced and can be your way out of boring meeting culture–definitely worth giving a try!

This brings us to the close of today’s post on SAP Global Template governance. In our next chapter we will talk about SAP Model Companies as accelerators for your SAP Global Template and its deployment. 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: Executive Message and Buy-in

Jul
29
2020

When it comes to the implementation of an SAP Global Template, you have to be clear. You have to be bold. You have to shout it from the rooftops! Otherwise, you may end up hosting a lame party that people cannot wait to abandon.

Executive Buy-In: You need it to make the hard decisions stick. If not, the local crown prince may just decide to go on a software spending spree, while the king of a tiny ivy tower far, far away thinly veils a tantrum. Don’t get me wrong–it is not about dictating, but rather rallying support from the leaders of your organization.

Executive Message: Make it visible that the Global Template is at the core of your future business strategy. It’s not an “IT thing” that levels somewhere on the nice-to-have layer of your decision process. Achieve this by including C-suite executives in important milestones of the Global Template rollout, like the start of fit-gap sessions, key user acceptance testing dates, and the go-live. Allow the whole enterprise to see that you and key leadership speak with one voice.

SAP Global Template Meeting with Executives

I have experienced many times that the missing buy-in and participation of executive leadership results in local operations running astray. These unnecessary occurrences of leaving the chosen path to Rome never end in happiness. We all want to be recognized as independent thinkers, believing that only our own way is the way to go. In reality, the most successful companies find an acceptable level of standardization without ever abandoning diversity!

Ultimately, it is on you, the program director or Center of Excellence leader, to communicate the need for buy-in and participation to the executives. They are busy without you, even more busy when you come along with your ideas. Don’t throw random or generic sound bites about the necessity of a Global Template and see if it sticks. Make your touch points with executives meaningful so they can relate to the tasks at hand:

Be mindful of their time as their day has only finite hours! Schedule interactions in accordance with their availability. You do not want to compete with board meetings or annual budget sessions. Nurture positive relationships with executive assistants as they are the wonderful magicians that make things happen!

Be precise in what you need from them; prepare a specific executive summary of anything you want to convey. If you cannot summarize it, you may not have fully grasped it yourself–how can you expect them to weed through a hundred pages to figure out how to support you?

Be aligned with the company strategy on all levels. Don’t ask for funds that have not been budgeted except for rare, immediate needs. Understand the business’ direction to avoid asking for help that will not be supported by leadership. If you want to change directions, build alliances, and don’t be surprised if it takes more time than anticipated.

The point is that you need to acquire buy-in to keep things moving! When charged with building a Global Template, it is part of your job description to be the glue between the deciders and the doers. So be that link, the building block that manages up and downward.

In our next installment of the Global Template blog series we will discuss the heart of the operations–the people that make it happen, the stakeholders, and those who are most impacted. If you’re looking for support with an SAP Global Template rollout, contact our team and see how Vortex Consulting can be a critical ally in the process.

Comparing SAP BPC and S/4HANA Implementation Options

Jun
06
2019

There are many variables when it comes to understanding SAP BPC and S/4HANA implementation options. Today’s blog post is from guest author Johannes Le Roux, an SAP HANA Architect at Infogility. Join us as he walks through the basics:

In 2015, SAP launched its latest data management solution, SAP Business Planning and Consolidation (BPC). It was designed to operate seamlessly on SAP’s latest ERP platform, S/4HANA.

Before we delve into the options for SAP BPC and S/4HANA implementation, let’s quickly recap a few of the main benefits to this groundbreaking approach to data management:

Real-time data access
Fast data load time and overall processing
Changes are implemented to core data, ensuring all sourcing comes from a single, centralized data pool

Option 1: New Implementation

Whether your organization is running on SAP or another ERP, implementing a new instance on SAP S/4HANA is an enticing option. Making the move to SAP’s most modern platform allows you the opportunity to realign and optimize existing business processes. If you have highly complex customizations that were built in years past, it’s likely that we can streamline and simplify those setups in a modern platform. Creation of a new SAP environment provides an opportunity to purge outdated data and establish a clean and well-structured data foundation for forward movement and growth. This environment can be developed either on-premise or in the cloud, depending on the unique resources and needs of your business.

Option 2: Landscape Transformation

Landscape transformation is ideal for those organizations with an existing SAP landscape, or even multiple systems–whether distributed regionally or in one central location. Alternatively, it enables large organizations to extract specific entities or business processes from the larger environment and establish them in a standalone SAP S/4HANA setup. Outdated or overly complex business processes benefit from the simplification and development of a “clean slate.”

Option 3: System Conversion / Migration

Some customers seeking an SAP BPC and S/4 HANA implementation simply want to convert an existing SAP ERP system to SAP’s most modern platform. A system conversion, which establishes a new on-premise or cloud-based S/4HANA environment, is the ideal option for organizations in this position. Using SAP’s migration tools, business data and configuration are managed to ensure a seamless transition.

SAP BPC and S/4HANA Implementation Option 3: System conversion or migration from an existing ERP system

Option 4: Migration to New General Ledger (G/L)

Finally, there are businesses operating with a classic General Ledger that are ready to take advantage of the benefits offered by SAP S/4HANA Finance. This process may take place through the use of SAP’s General Ledger Migration Service or through the activation of a parallel ledger and document splitting strategy. A customized approach will ensure data streams and financial management functions remain in order throughout.

Initiating an SAP BPC and S/4HANA Implementation

Choosing to move forward with an SAP BPC and S/4HANA implementation is a strategic decision that will benefit your business. As technology and the business landscape continues to change, your ERP environment will be set up to outperform outdated systems. SAP has been a leader for decades, and with its latest launch of cutting edge ERP solutions, it has once again demonstrated that it will continue to be an industry leader for years to come.