If you’re reading this blog post then you’re probably in the process of working out your path to SAP S/4HANA. You’ve probably also learned that some of the features that you use today come from SAP ERP – and are therefore provided to you as a compatibility pack.
But what are compatibility packs? They were originally introduced as a way to unite multi-year development cycles at SAP with multi-year adoption strategies at our customers. Over time, we want to provide alternatives to the capabilities that are currently provided as part of these compatibility packs. In fact, many alternatives already exist or are already included on our development roadmap.
While SAP recently announced the maintenance extension for SAP Business Suite 7 until the end of 2027, the usage rights of the compatibility packs were not included in this extension and a couple of questions came up about why and how to deal with it.
Compatibility packs not extended beyond 2025: So, what’s next?
In short: We will offer, or have already offered, alternatives. In fact, out of 183 compatibility pack items only 15 are still in clarification for an alternative. We’re currently investing in order to accelerate the development schedule for those alternatives that are still outstanding so that they are available to customers in time for adoption before the usage rights expire. To help with this, SAP will provide timely communication to customers. We are in the process of completing the re-planning of the remaining alternatives and we hope that the complete overview will be available in Q3 2020. Intermediate updates will follow as the planning evolves. The complete overview can always be found in SAP Note 2269324.
We asked our teams to consider the effort to adopt the alternatives and hence build bridges where possible. In addition, we prioritized those with expected larger efforts like HCM or stock room management to start earlier to grant more time to adopt these. Target is for all alternatives to be available by 2023.
We think that customers will be able to plan their adoption scenarios based on this information. We see two scenarios:
- An alternative capability exists for the relevant compatibility scope when you start the project. In this case we recommend that customers adopt the alternative as soon as they move to SAP S/4HANA.
- An alternative is currently only planned for parts of the relevant compatibility scope. In this case it will be adopted as part of an upgrade after the alternative has been provided.
If you bring up a new system, you may as well sequence the deployment of capabilities so that you can only implement certain functionalities once the alternative exists.
Effort remains essentially the same
The good thing is that, in terms of effort, the overall effort to adopt SAP S/4HANA is generally not increased: It is simply split into two phases. Based on this, it’s possible to start now and harvest the innovations that were built over the past five years: In this way, customers can drive the value in their company as there is no need to wait for all the relevant alternatives to be completed first. This even has an advantage of its own as customers who move to SAP S/4HANA after 2025 will no longer be able to split the tasks into two phases. So, there’s no reason to wait to adopt SAP S/4HANA!
Of course, it’s also an option to delay the adoption of existing alternatives to a future upgrade to spread the effort and balance with other company strategies. However, in terms of change management, some changes may be simpler to adopt at the time of moving to SAP S/4HANA. This should be considered as part of the validation process for moving to SAP S/4HANA.
I hope this clarifies the logic and reasoning around compatibility packs at SAP S/4HANA: I believe that this process will make it simpler for our customers to move to SAP S/4HANA within the given timeline.
Further information:
Nenhum comentário:
Postar um comentário