Figure 1 - two projects tracks consolidated to a core/template maintenance track.
With the current pace of SAP S/4HANA transformations it looks like not a lot of companies might make the 2027 deadline. Is there a standard way to speed them up? Yes, you can use project tracks, everyone knows that, right? Why are they not that common then? How can companies run 3-5 rollouts at the same time without disabling the maintenance of the core/template SAP S/4HANA system?
A project and maintenance tier track for SAP implementations is a system for organising and prioritising the various tasks and activities that are required to implement and maintain an SAP system. The main purpose of this system is to ensure that companies can run big complex projects, like multiple SAP S/4HANA rollouts but at the same time be able to work and improve the core/template SAP S/4HANA system. For this purpose you can add a new track (with a second development - DEV1 and integration - INT1) system. In case you need to run more complex projects you may want to consider more project tracts which will later be consolidated to the template track (DEV-QAS-PRD) as shown in Figure 1.
Tier 1 (BAU or maintenance) - Critical projects and activities: These are tasks that are essential for the successful implementation and operation of the main SAP S/4HANA system, such as system configuration and data migration. These tasks are considered high priority and are given the highest level of resources and attention.
Tier 2 - Important projects and activities: These are tasks that are important for the operation of the SAP system, but are not considered critical. Examples include system SAP S/4HANA rollouts, enhancements, complex process improvements. These tasks are assigned a lower level of resources and attention than Tier 1 tasks.
Well this is a good question and there are a few reasons for that:
a) maintenance of such a complex landscape - you need to learn how operate on such a complex landscape - transports must be done in different way, retrofits need to be well thought of as well
b) SAP S/4HANA is not an island... it connects to many other SAP application, much more non-SAP applications and most likely even more B2B/EDI partners. If you want to replicate those in the project tier all of a sudden it becomes a maintenance nightmare. If you don't know how to avoid it.
Figure 2 - SAP S/4HANA systems are connected - how to connect them on project landscapes?
c) costs - two types: costs to maintain the additional tiers and cost to set up all of the non SAP S/4HANA systems (3rd party) - where now with RiseWithSAP it might even be more challenging as customers will not pay for own systems but will use them as a service (more systems = more costs).
We will not go into the technical details on managing the transport layer in this article as most of those topics have been covered several times already. Instead we will concentrate on the connectivity aspect. How to overcome this pain point? Use Service Virtualization - simulation of non-SAP systems and B2B/EDI partners designed specifically for such SAP projects.
Figure 3 - simulate 3rd party systems and EDI/B2B partners in project tracks
Service virtualization can help with SAP S/4HANA projects by allowing teams to simulate the behavior and responses of dependent systems that are not yet available, difficult to access (EDI, B2B partners) or too costly to implement - think of sustainability too. This can enable SAP development and SAP Functional teams to test and develop their S/4HANA implementation in parallel with other systems, reducing the risk of delays and issues arising from dependencies on external systems. Additionally, service virtualization can also help with testing and development of integrations and customizations, and can enable teams to test various scenarios and edge cases that may be difficult to replicate in a live environment.
There's a 3h course on openSAP just on this topic called "Avoid SAP S/4HANA Project Delays with Third-Party Systems Service Virtualization" - In this course we help you understand why SAP-tailored service virtualization is a hidden gem of SAP S/4HANA projects, who can use it and when to use it, and most importantly, how to benefit from it. In addition, you’ll learn how service virtualization can make your projects more sustainable by significantly minimizing their carbon footprint.
Figure 4 - openSAP course on service virtualization
Project tracks are a way to help you run complex SAP S/4HANA projects like multiple rollouts at the same time but they need to the team to be prepared as it's not a standard setup. Service Virtualization is one of the ways to unlock the hidden potential of running SAP project tracks not only effectively but also in a sustainable and cost-effective way
What is a project and maintenance track for SAP S/4HANA projects?
A project and maintenance tier track for SAP implementations is a system for organising and prioritising the various tasks and activities that are required to implement and maintain an SAP system. The main purpose of this system is to ensure that companies can run big complex projects, like multiple SAP S/4HANA rollouts but at the same time be able to work and improve the core/template SAP S/4HANA system. For this purpose you can add a new track (with a second development - DEV1 and integration - INT1) system. In case you need to run more complex projects you may want to consider more project tracts which will later be consolidated to the template track (DEV-QAS-PRD) as shown in Figure 1.
How do you separate those tracks?
Tier 1 (BAU or maintenance) - Critical projects and activities: These are tasks that are essential for the successful implementation and operation of the main SAP S/4HANA system, such as system configuration and data migration. These tasks are considered high priority and are given the highest level of resources and attention.
Tier 2 - Important projects and activities: These are tasks that are important for the operation of the SAP system, but are not considered critical. Examples include system SAP S/4HANA rollouts, enhancements, complex process improvements. These tasks are assigned a lower level of resources and attention than Tier 1 tasks.
Why aren't we using that already at our project?
Well this is a good question and there are a few reasons for that:
a) maintenance of such a complex landscape - you need to learn how operate on such a complex landscape - transports must be done in different way, retrofits need to be well thought of as well
b) SAP S/4HANA is not an island... it connects to many other SAP application, much more non-SAP applications and most likely even more B2B/EDI partners. If you want to replicate those in the project tier all of a sudden it becomes a maintenance nightmare. If you don't know how to avoid it.
Figure 2 - SAP S/4HANA systems are connected - how to connect them on project landscapes?
c) costs - two types: costs to maintain the additional tiers and cost to set up all of the non SAP S/4HANA systems (3rd party) - where now with RiseWithSAP it might even be more challenging as customers will not pay for own systems but will use them as a service (more systems = more costs).
How to run many SAP S/4HANA projects at the same time and solve those issues?
We will not go into the technical details on managing the transport layer in this article as most of those topics have been covered several times already. Instead we will concentrate on the connectivity aspect. How to overcome this pain point? Use Service Virtualization - simulation of non-SAP systems and B2B/EDI partners designed specifically for such SAP projects.
Figure 3 - simulate 3rd party systems and EDI/B2B partners in project tracks
Service virtualization can help with SAP S/4HANA projects by allowing teams to simulate the behavior and responses of dependent systems that are not yet available, difficult to access (EDI, B2B partners) or too costly to implement - think of sustainability too. This can enable SAP development and SAP Functional teams to test and develop their S/4HANA implementation in parallel with other systems, reducing the risk of delays and issues arising from dependencies on external systems. Additionally, service virtualization can also help with testing and development of integrations and customizations, and can enable teams to test various scenarios and edge cases that may be difficult to replicate in a live environment.
Where I can learn more about this topic of Service Virtualization?
There's a 3h course on openSAP just on this topic called "Avoid SAP S/4HANA Project Delays with Third-Party Systems Service Virtualization" - In this course we help you understand why SAP-tailored service virtualization is a hidden gem of SAP S/4HANA projects, who can use it and when to use it, and most importantly, how to benefit from it. In addition, you’ll learn how service virtualization can make your projects more sustainable by significantly minimizing their carbon footprint.
Figure 4 - openSAP course on service virtualization
Conclusion
Project tracks are a way to help you run complex SAP S/4HANA projects like multiple rollouts at the same time but they need to the team to be prepared as it's not a standard setup. Service Virtualization is one of the ways to unlock the hidden potential of running SAP project tracks not only effectively but also in a sustainable and cost-effective way
- SAP Managed Tags:
