Abstract: The blog analyzes why “RISE with SAP” projects often fail when “SAP Activate” is used without project-specific customization – especially in the private cloud. It shows how individual contract models, strong customer leadership and a partnership-based approach can ensure project success.
Insights from the epilogue in BLOG34
Can “SAP Activate” be used in all S/4HANA Cloud projects?
In recent years, I have taken on several customer mandates in which I was asked to rescue “RISE with SAP” projects that had got into extreme difficulties. The projects were all commissioned on the basis of the “SAP Activate” method/framework and were to be implemented in accordance with it. Unfortunately, this was not successful in any case. You will have understood the system-inherent reason for this by the end of this article.
All of these projects were ultimately cancelled and cost the CIOs and other managers their jobs. Incidentally, I have not experienced a single “RISE with SAP” in this context where the implementation partner consistently used the corresponding “SAP Activate” framework, even though the project was commissioned accordingly; on the other hand, in my experience and assessment to date, this is not even possible in “RISE with SAP” projects as actually intended. The reasons for this will hopefully be clearer by the end of the article.
There is another way – the solution makes the difference.
For almost a year now, I have been the overall project manager commissioned directly by the customer for a “GROW with SAP” (i.e. Public Cloud) project, which was also commissioned on the basis of “SAP Activate” and is being handled using the “SAP Activate” framework in accordance with this method. And I am confident that this project will be completed successfully. It is essential that the tasks assigned to the customer according to “SAP Activate” and largely carried out independently by the customer are consistently managed. This can certainly be achieved in a public cloud project of this kind, as the tasks assigned by SAP in the “SAP Activate” framework can be used without restriction in a public cloud project. In addition, my customer fortunately did not make the mistake of commissioning the implementation from the implementation partner in a fixed-price contract (see below) – so that the tasks involved can be managed in partnership with the best possible effectiveness.
What is the problem?
In my “BLOG34 – https://sapxp.ch/erfolgreiche-s-4hana-projekte/ “, I have already written in detail about the obvious incompatibility of RISE with SAP (private cloud) and the use of the “SAP Activate” method/framework. Now that I have also gained a detailed insight into the “GROW with SAP” (public cloud) solution and the use of the “SAP Activate” method/framework in this environment, it has become all the clearer to me why its use in “RISE with SAP” (private cloud) projects is doomed to failure:
- With “SAP Activate”, the so-called “self-enabling” of key users is a basic requirement. This means that the key users are no longer taken by the hand by the consultants as with “AcceleratedSAP” and are shown and explained everything in detail. Instead, they must acquire the necessary knowledge and understanding of the future processes in the so-called starter system (comparable to the former IDES) using the documentation provided by SAP (essentially process diagrams and test scripts).
- This can also function relatively smoothly in the public cloud, as the processes found in the starter system also correspond to those in the documentation provided, as no real process-changing adjustments are permitted in the public cloud.
- And it is precisely for this reason that this approach is doomed to failure in the private cloud, as the decision has usually been made to make appropriate adjustments, i.e. the validity of the existing documents is overridden.This is sometimes taken to extremes by the additional implementation of add-on-based special solutions from third-party providers, especially if these interfere with integrated processes and functions. Key users are left stranded in the moment it comes to self-enablement.
- With “SAP Activate”, the critical task of data migration in every SAP project is transferred almost entirely to the customer. The only support provided by the implementation partner is an introduction to using the SAP Data Migration Cockpit. Collaborative mapping of the data and the definition of necessary and sensible conversion rules – supported and perhaps even guided by the implementation partner’s consultants – is not provided
- As the data structures/table fields are generally used unchanged in the public cloud, the available migration templates are valid and the field usages also correspond to the functionality provided and documented in the standard. This means that the customer can acquire the knowledge they need to identify existing sources and define conversion rules – albeit laboriously.
- It should also be clear for this task that the approach outlined in the private cloud, in which the use of additional fields in the master data objects (supplemented by extensions in the tables) cannot work. This is the standard, especially in connection with the implementation of add-on-based special solutions from third-party providers – and thus often leads to never-ending error corrections in the mock load cycles.
- In contrast to the previous “AcceleratedSAP” method, “SAP Activate” no longer requires ALL processes and functions to be run through and tested completely and jointly by key users and consultants as part of the integration test. Instead, it is planned that the consultants (without the intervention of the key users) only test and validate the correctness and successful “integration” of additional developments, the so-called WRIFEF, as part of the integration test. The adjustments to the configuration of the standard processes are not part of the planned integration test scope.
“SAP Activate” is designed so that the key users can fully test the processes and functions for the first time as part of the acceptance test and “accept” the solution independently – without defined support from the consultants – ideally right away- The assumption that the processes and functions delivered in the SAP standard do not have to be subjected to an integration test, but that this is only relevant for additional developments, in particular form customisations and interfaces, may be understandable for the public cloud, as no significant changes to the standard processes are possible in the public cloud. Nevertheless, it is generally highly questionable whether it makes sense to restrict this test. Experience has shown that it is so important for deepening key users’ understanding of the future solution. However, as they are completely excluded from this integration test anyway according to SAP Activate, it is irrelevant against this background.
GROW with SAP projects should therefore also ensure that the standard agreement is adapted so that EVERYTHING IS TESTED TOGETHER in the integration test. - The approach of restricting the integration test in the private cloud to the additional developments only and ignoring the adjustments to the configuration, which are often significant and frequently affected by the developments to extend or change the functions, can be described as downright criminal.It is also completely incomprehensible that the key users are denied the opportunity to develop the overall functionality in a joint integration test in the interplay of newly developed functionality and customised configuration under the guidance of the consultants.This must inevitably lead to great frustration among the key users and process owners, as they are supposed to accept the overall solution in the subsequent acceptance test without preparation by a joint and complete integration test.
In addition, it is probably also an imposition that the process owners are more or less forced to accept everything in the subsequent acceptance test, as the acceptance test naturally takes place as the last test very shortly before the planned go-live and any deficits identified in the test can no longer be rectified without immediately jeopardizing the go-live date.This constellation often leads to the RISE project being stopped, at best put on hold and restarted or, at worst, cancelled altogether, which at this stage of the project means that both the usually very high investments made up to that point have to be written off completely and the relationship with the implementation partner is in most cases completely shattered.
- The assumption that the processes and functions delivered in the SAP standard do not have to be subjected to an integration test, but that this is only relevant for additional developments, in particular form customisations and interfaces, may be understandable for the public cloud, as no significant changes to the standard processes are possible in the public cloud. Nevertheless, it is generally highly questionable whether it makes sense to restrict this test. Experience has shown that it is so important for deepening key users’ understanding of the future solution. However, as they are completely excluded from this integration test anyway according to SAP Activate, it is irrelevant against this background.
The mutual flagellation in the contract completes the dilemma.
The above-mentioned tasks are known to be the most critical tasks for the overall success of an SAP project (development of expertise within the company (OCM) and data migration) and are entirely the responsibility of the customer with “SAP Activate” / “RISE with SAP”, although they cannot be solved in this way.
However, these effects are massively amplified by the fact that the two contractual partners, i.e. the customer and the implementation partner, agree on the procedure within the framework of the contract, which is usually based on RACI with the division of labour according to “SAP Activate”, which the customers insist on because they are so strongly propagated by SAP and cannot know any better.
In addition, the potential customer is usually of the opinion that he is best off with a fixed-price contract, although it should be known that this rarely works satisfactorily.
The two together are a truly unspeakable mixture, as customers generally attach the greatest importance to the total costs offered and therefore often opt for one of the most favourable providers. This provider, in turn, can only offer such favourable prices because it relies uncompromisingly on the division of tasks required by the customer in accordance with the SAP Activate method and the associated RACI matrix as well as the contract templates provided for this purpose.
In case it transpires in the course of “SAP Activate”/”RISE with SAP” that this does not really work, both companies can generally no longer move towards each other as partners because they have tied themselves into this contractual fixed price corset.
As a customer, realize that it does not make sense to insist on the strict application of SAP Activate in a “RISE with SAP” project. In case you have to prepare a tender, specifically request concrete and quantified proposals for a plausible partnership-based solution to the above-mentioned challenges.
Don’t be afraid to refer back to the previous “Accelerated SAP” method, in which collaboration was much more sensibly organised. Be very specific about what is expected of you and make sure you have the resources to achieve all of this. And make sure that you plan enough additional reserves for contingencies if this is not guaranteed.
Once you have decided on an implementation partner, talk openly with them about which form of contract is best suited to a partnership-based collaboration and a quick joint response to unforeseeable situations (see also BLOG5 – https://sapxp.ch/partnering-modelle/ ).
Comprehensive project management on the customer side can make the difference with both “RISE with SAP” and “GROW with SAP”.
Both for customers who opt for “RISE with SAP” (private cloud) and for those who choose the “GROW with SAP” (public cloud) route: Be aware that your own project manager in an SAP Activate project must have a proven track record, especially in the following project-critical areas:
- Data migration (including procedures, methods and tools) (see also BLOG22 – https://sapxp.ch/datenbereinigung/ )
- Organisational Change Management (OCM) including train-the-trainer concepts and the creation of targeted and sustainable process and application documentation (see also https://sapxp.ch/anwenderdokumentation/ )
- Test management including preparation by creating a BPML with e2e scenarios and deriving the business cases to be tested in all relevant process areas with reference to the scope items to be implemented (formerly S4HANA Best-Practise ID) and, of course, planning and controlling the tests to be carried out under customer responsibility (see also BLOG11 – https://sapxp.ch/mapping-best-practice-bpml/ & BLOG19 – https://sapxp.ch/anwenderdokumentation/ & BLOG24 – https://sapxp.ch/integrationstests/ ).