3 Major Mistakes You're Making When Planning Your SAP S4 Interface Implementation

Kenn Wu on August 21, 2020

You’ve landed an SAP S4 implementation, and the client is looking for estimates and project plans to review. Peers and colleagues remind you that that the interfaces will be the most complex technical customization on the project. You have a lot on your plate, so let’s make sure you navigate the pitfalls of planning and scheduling these interfaces successfully.

While they’re not wrong, it’s essential to know what ‘interface complexity’ really means. Knowing what and where the complexity is will help you plan for a smooth implementation.

Does ‘complexity’ mean interfaces are the most sophisticated software engineering problems that need to be solved? No, not really.

Most software and service vendors at the enterprise level know that functioning, well-documented API are table stakes. While the implementation team may run into some problems coaxing two or more systems into ‘talking’ to each other, by and large, this is not the complexity that project managers and engagement partners need to consider.

The problem is the people. Or more accurately, not considering the right people when formulating your plan.

Non-SAP Resources Don’t Show Up in the Plan

When an organization tackles a transformation project, chances are that doing any significant ERP work (like migrating to SAP S4) will be the most notable and most expensive activity. Of course an SAP-led and SAP-focused integration team is what you want!

But, an SAP-led planning effort often doesn’t account for the changes that need to occur on the other, non-SAP, side of the interface. Whether it’s integrating a new software service or an ancient legacy app, every interface needs expertise and effort on the SAP and non-SAP sides.

Here’s what you can do:

1. Define which resources will be providing non-SAP expertise and effort. In the ‘statement of work’ is best. In a RACI matrix (or their many equivalents) is good. But if those ships have sailed, the best time to get it defined and communicated is now.
2. Assign plan deliverables to the non-SAP application resource. This resource may be a customer’s employee, a customer’s managed service provider, or it could just be a team member from your consulting firm. On an SAP project, most stakeholders plan only for the SAP functional specification and allocate time to test the SAP application. Ensure that the non-SAP resources are planning and executing their corresponding work by getting their deliverables on the project plan.
3. Check your project plan for resource constraints. If the expert for legacy app A happens to be the expert for apps B, C, and D (which is common), your plan must account for that. Make stakeholders aware that the delivery of interfaces with apps A, B, C, D will be extended because of a resource bottleneck.

External Partners Aren’t in the Loop

On some smaller implementations and most large ones, there will be many interfaces with external vendors. For example, on a human capital management project, you’ll likely see touchpoints with banking, payroll, print services, pension, and insurance providers, to name a few.

Most project managers underestimate the coordination it takes to work with a client’s external partners. These partners may have pre-existing rules of engagement that make it difficult and slow to get them on board with your plans. They may have internal projects that tie up resources (that your project needs!) and impose black-out dates on changes that you need on their system. The result is a significant risk that coordinating changes and testing efforts with these external partners will delay meeting your project milestones.

Here’s the one key thing you can do to mitigate these problems:

1. Assign a dedicated resource whose primary activity is the on-boarding and coordination of external partners. That means communicating project milestones and dates, confirming participation details (i.e., dates and people), collecting status, and orchestrating larger meetings as needed. This person will need to have a client counterpart to ensure that existing relationships with that partner are respected. Can the integration lead take this on? Yes. Will they be burned out? Also, maybe yes.

Missing Dependencies on Infrastructure Teams

In most cases, the system integrator will round up a development team to deliver the custom interfaces between SAP S4 and partner systems. Lower down the technology stack, the client (or their service provider) is typically responsible for providing the technology infrastructure.

When the development team needs help setting up a new environment, applying licenses, setting up VPN tunnels through the firewall, signing up for TLS certificates, applying configuration changes, or planning for disaster recovery, the infrastructure team needs to be there.

How can you make sure this vital team is engaged and aware of their importance?

1. Allocate a full-time infrastructure resource to support the integration team when scheduling environment setup or major code promotion activities (including the start of an end-to-end test cycle, or releases to production). Ideally, that resource should be the integration teams’ primary point of contact with the network, server, and operating systems teams.
2. Engage your integration architect early in the process - they should be there during project discovery and hopefully a member of the pre-sales team. Ask your integration architect to identify technology components that will likely be needed that aren’t part of the integration platform. Will the integration team need a set of databases in each environment? Do they need logging and monitoring services? How about separate messaging queues? These components constitute additional licensing considerations and require infrastructure support resources. Get these components named and in front of the infrastructure team ASAP to ensure they are budgeted.

Summary

Make sure to consider non-SAP developers, coordinate with external interface partners, and include the customer’s infrastructure teams. Once you’re familiar with these common gaps in planning and scheduling ‘complex interface’ work, you’ll find it easier to get ahead of those risks and on the path to a successful implementation.