External Dependencies in SAP Projects – The Ultimate Survival Guide

External Dependencies in SAP Projects – Here’s your survival guide!

If you’re running or planning an important SAP Project such as SAP S/4HANA conversion, you might have heard about the topic of External Dependencies (3rd party systems and EDI partners).. And especially if you are a Project or Program Manager, you definitely know how important it is to take every dependency into consideration – especially if you don’t have full control over it.

The following article is based on the conversation between Michał Krawczyk and Korneliusz Kordus in the Navigating SAP API Testing cycle. Find the full conversation below:

Having said that, if you want to mitigate the risks posed by External Dependencies, this text is for you!

What are the External Dependencies in SAP Projects?

The bigger the SAP project is, the higher is the likelihood that it’s not done in a vacuum. The system that is the focus of the project usually needs other, external systems in order to do its job properly.

External Dependency is reliance on system and/or staff outside of the scope of the project. This can mean both:

• the external system outside of your organization or EDI partners,
• in-house systems (3rd party, non-SAP systems) that are not subject to the given change. 

 
Although these systems and their resources are not in the scope, success of your project is dependent on your ability to work with them and continue smooth business operations.

Even though these systems usually do not change in the span of the project, they are a critical piece of the puzzle. Overall, if your ability to conduct your critically important business processes is dependent on them, you need to make sure that they are working after performing any changes to the systems that work with them.

And since the project outcome is dependent on those, they shouldn’t be ignored under any circumstances.

What are the examples of External Dependencies?

For enterprise companies in segments such as retail, FMCG, pharmaceutical, automotive or food & beverages it’s not unusual to work with hundreds or thousands of External Connections. The systems can be (but are not limited to):

• EDI providers,
• systems for collecting orders from e-commerce solutions,
• third party logistics providers,
• 3rd party warehouse management systems,
• other mandatory systems such as banking or governmental reporting systems,
• other systems specific to your industry.

 
So what’s the common denominator? These are in essence external systems that allow you to smoothly conduct daily activities. Regardless of the technology.

Why do we call these Dependencies “External”?

Predominantly – because they are outside of the control of the SAP programs. You don’t have full access to them and they usually require additional, external resources to help you with quality control.

Of course, you can try to secure a sense of control, for example by setting up arrangements with those 3rd party systems and their staff. But especially when we’re talking about big and complex SAP Projects such as SAP S/4HANA Conversions, the amount of these external systems, the cost and effort required to coordinate these 3rd party systems, makes this a hardly relevant solution.

And the time and resources needed to set-up an extra environment (of which you also don’t have full control) for every one of those systems can also be a considerable investment.

What is there to worry about?

As mentioned before, these systems are outside of the project scope. This means that they will usually not change and, at least for a period of time, will remain the same. So the only role you expect from them is that they will conduct their business as usual after YOU conduct the changes. So what do you need to consider?

Why do you need to be mindful about the SAP External Dependencies as an SAP Project or Program Manager?

At the end of the day, Project or Program Manager’s goal is straightforward: to allow the project team to conduct the expected activities on time, in budget and in acceptable quality. And External Dependencies pose a risk in regards to reaching this goal.

As a PM, you need to be concerned about any risk factor. Because the Project Management Team primarily needs to create an environment and context in which the project team can secure the success of the project.

With External Dependencies, you are usually not in control. For example, your ability to influence external staff’s response time or range of support is limited. 

Whose work is affected by External Dependencies?

Looking at the project structure “by the book”, we can identify few groups whose work and goals might be affected by External Dependencies:

• Developers that do enhancements on the newly setup systems
• Functional Consultants that set up the business in the newly established way and customize systems
• Project Management Team that create the environment which allows successful delivery of the project,
• Steering Committee that takes accountability for success of the project
• Leadership perspective (e.g. CIO/CTO) that may not be directly involved in the project, but has on outlook on how much value this project generates.

 
There is no specific role that gets impacted the most, because this depends on the perspective from which you’re looking at the project.

If there’s a day-long power outage in the clothing shop it affects every involved employee – just in a different way. The cashiers cannot scan and sell the articles. The merchandiser cannot find the needed items. The assistants cannot iron the clothing. The magazine workers cannot pack and ship packages. Store managers can’t make progress towards their sales targets. And the chain itself will be less profitable at the end of the day.

Similarly in SAP Project or Program, there’s no specific role that’s getting most heavily impacted. Eventually everybody is impacted by these External Dependencies – depending on how you look at the risk.

Developers or Functional Consultants might have trouble with testing the third party systems in the early stages of the project, pushing the potential issues or defects further into the project, where fixing them will be more difficult and costly.

Project or Program Management Team might have to face consequences of that in form of potential project delays.

Project’s Steering Committee might not have enough confidence in the systems in order to go live, because some defects in regards to cooperation with third party systems might prevent the business from conducting its critical processes such as selling, buying or shipping.

The ultimate goal of the project is to create something that will be meaningful for the organization. And External Dependencies are a risk factor to that goal – so you have to address it on every level of the project.

So what we can control is the SAP environment. There is something big that we cannot control. 

Are you creating effective solutions or “perfect excuses”?

External Dependencies are frequently generating project delays. The bigger the amount of the External Dependencies, the bigger the delays can get.

If you do not mitigate this risk of External Dependencies, the Developers or Functional Consultants usually cannot deliver their work on time, in budget and in acceptable quality. This poses a risk as there can come up these “perfect excuses” regarding the External Dependencies such as:

“The external team is not willing to help us”

“They are not working with me”

“I cannot contact or connect with them”

“They didn’t help us”

“They are not responsive”

“I couldn’t reach them – I tried to ping them three times already to no answer”

But these statements won’t change the facts – that the project might not get completed in time, within budget or in acceptable quality. The point being – you have to create workable solutions, and not space excuses. Because the opportunity for such excuses should not be available. 

Who should raise awareness regarding External Dependencies as a project risk in order to mitigate it?

In an ideal world every team member would be aware about the risks generated by External Dependencies. But in reality, raising such awareness will usually be an important part of mitigating this challenge.

Whose responsibility is it to create a proper context for those excuses not even to appear?

Korneliusz Kordus perceives that identifying, raising awareness and ultimately mitigating the risk of External Dependencies is a Project or Program Manager’s responsibility. 

But you have to remember that the PM works within constraints of budget, time and quality. So if the situation calls for that, for example if there’s no budget, the PM might have to escalate this issue to SteerCo in order to get proper funding for mitigation.

Project and Program managers are bombarded with risks and challenges. Should they prioritize managing External Dependencies?

We realize that the Project/Program Manager always gets the bad news. This is almost a part of the job description. 

But the later you’re going to postpone handling External Dependencies, the worse this news might get. So the best time to start organizing the solution for that risk is before the project even starts. In this way:

• You can properly prepare,
• You can do your research and look at solution that the market offers for such challenges (such as Int4 Suite),
• You can create and implement solutions in terms of skills, procedures, ways of working and tools.

 

Look beyond the project!

Although the project is heavily exposed to dealing with External Dependencies (because they can disrupt the success of the project), these Dependencies are an issue for the organization as a whole. The bigger your organization is gonna become, the more it becomes a problem for the whole organization.

The project is almost a complete world in itself. But for the organization, the project is just a part of the bigger journey. Because the changes in the IT landscape, whether they are driven by the needs of the market, strategy or vision of the organization, technically driven or business driven – they will never stop.

Don’t let the External Dependencies slow down your innovation

The challenges that companies face when dealing with External Dependencies can make the organization see changes as a negative thing. Because when the companies struggle with SAP Programs or Projects, they tend to get more and more cautious with future initiatives that could drive the business into the future. 

So if your organization doesn’t have the understanding of External Dependencies, you will innovate slower. Because innovation will be seen as too complex, problematic and time-consuming.

You’re not the only big organization that has challenges regarding External Dependencies in SAP.

During this time where many organizations are undergoing major SAP changes, many Project or Program Managers are facing this exact issue of dealing with hundreds or thousands of External Dependencies.

Int4 Suite is an SAP API Testing and Service Virtualization platform that helps with mitigating this risk by removing the External Dependencies.

With its Service Virtualization capabilities, you can simulate the 3rd party systems by reusing your existing communication, in order to make sure that the system is working after making any change.

SAP Project Teams leading some of the biggest SAP S/4HANA conversion projects in the world are using Int4 Suite with great results – such as 500x increase in time needed to test a complete process in their SAP S/4HANA Greenfield. And by the way – that’s not an exaggeration.

If you want to learn about how the Int4 Suite can help you mitigate the risks tied to External Dependencies, you can schedule a free discovery session with our Experts HERE. 

And if before doing so you’d like to evaluate the tool on your own, below you’ll find a link to a Crash Course that explains the basic concepts and capabilities of Int4 Suite.