It can be a steep learning curve for many existing SAP consultants who started their SAP Journey in an on-premise landscape. I would like to share my experience and lesson’s that I have learnt on Do’s and Dont’s of implementing SAP Cloud Projects in this blog and would love to hear your experiences from across the world.
I would also like to thank my colleagueDavinder Sandhu for contributing into this blog.
1.Project Methodology and Implementation
Get Your Strategy and Approach to Cloud Projects Right
Problem : In most projects, you probably bought the cloud products from different vendors based on sales pitches and a high level business case. An organisation will then usually trigger the procurement teams to identify and select system implementation partners or consulting partners to implement the solution. Following the conclusion of a successful bid process by SI partners, a client may be tempted to sign up to a ‘big bang implementation’ approach to move an on-premise or legacy system solution to SAP Cloud across multiple markets and decommission existing systems without checking whether the presales pitch and reality on the ground match.
Recommendation: I would rather recommend that clients work with their SI partners to plan a phased approach to their implementation, using an MVP model as shown below or Global Template Model.
Organisations can leverage the knowledge and experience of initially moving into the cloud for a single market and performing a ‘deep dive’ on whether the cloud solution is right for them without locking themselves into expensive long term contracts.
It will also help an organisation to decide whether moving to the cloud is the solid solution, by evaluating the customisation that was done on the SAAS product for the first market and estimate the customisation that you need to do for the other markets. If it is a high degree of bespoke customisation that needs to be done, then it helps you to re-evaluate if SAAS products are right for your organisation before committing significant investment.
Before you start the project, It is useful to run the following SAP Activate Accelerators:
to understand the maturity level of the organisation. It will help to set the right expectations and educate a business about “how cloud projects work” during the project kick off.
Get Your Software Development Methodology Right
Problem: If clients approach SAP Cloud projects using a ‘big bang’ instead of an MVP approach or when SI partners/Customers build highly bespoke custom cloud solutions (often to replicate on-premise or legacy designs), the methodology will become a mixed bag of Waterfall and Agile i.e Fragile. Invariably, what set out as an attempt to leverage the ‘best of both’, ends up with customers and partners in conflict about what to use when can result in neither being applied correctly. This is a dangerous RED Sign for me that you aren’t approaching this cloud implementation correctly! It doesn’t matter whether you follow an agile or waterfall model but you need to get the model, milestones and quality gates on the project right.
Recommendation: SAP provides a frame work called SAP Activate. This contains best practices and accelerators to avoid this DANGER situation and hence I recommend you all to go through the development methodology, predefined best practices and workshop templates for S/4 HANA or C/4 HANA or Success Factors based on the industry solution that you are trying to implement during the project or programme kick off phase.
To learn more about how SAP has configured their own Minimal Viable Product’s (MVP) for organisations kick-starting their digital transformations, review the SAP’s Model Company Service Offerings . They are preconfigured MVP’s designed for the purpose of meeting MVP time frames .
Define and Communicate the Measures of Success and Quality Gates for Each Phase of Your Project
Problem: I have been on few projects where the customers customised the cloud solution to match their on-premise system solution. It was very hard to convince them that cloud projects don’t work in the same way because they believed the project objective was to ‘Lift and Shift’ all existing system functionality. Achieving an ROI on this type of project becomes increasingly difficult because the inherent benefits of a cloud solution (automatic upgrades, minimised regression impacts of upgrades , reducing operational costs, capex to opex costs etc) can be nullified by complex customisation of a system.
Recommendation: It may sound bureaucratic, but I always recommend that we should clearly define and communicate the business vision and objectives of the programme to the entire team during the project kick off to ensure that they understand what the IT programme should deliver to fulfil the business objectives. You can use SAP Activate accelerators like QGateChecklist Concept SAP Activate (Public) and Business Definition Templates and Examples (Public) and Phase Sign-Off Template (SAP Customer) and Business Case Template (SAP Customer) to achieve that.
Don’t exclude Data & Integration Teams! They are the heart beat of your cloud sprints!
Problem: 50% of SAP Cloud projects see Data and Integration teams as “Outsiders” and will not include them in sprints due to the risk that sprints will not finish usually in 2 weeks.It takes long time to do data discovery and understand how existing legacy systems integrations work as most of the clients don’t have detailed documentation on these systems or probably outsourced to SI Partners or third party vendors .
The other compelling reason on why Data & Integration teams are left out is due to the complexity of negotiating and signing commercial contracts with third party and legacy system vendors when projects are following agile methodology i.e moving scope. Hence, many clients prefer to wait till the last minute and like to follow a waterfall model for Data/Integration delivery.
Recommendation: I always recommend clients to include Data Migration/Integration Data Model and ETL/Integration build in sprint increments and to negotiate a Agile Contract commercial model with SI partners or vendors that works for agile project. You can then define and prioritise separate sprint data migration load cycles to support your UAT/SIT and functionality of the product you are releasing.
On the other hand if you think project scope is shifting on the sand constantly and it is complex to work out a commercial model with third party vendors or SI partners then establish the change control process to communicate the dependencies between Data Migration/Integration Data Model SAP Cloud Product configuration sprint cycles and their impact on the Data Migration/Integration Waterfall plan.
In Jira, I will probably simply create Data and Integration work streams as epics and create a user story for each data/integration interface and tag the user story that is responsible for configuring DATA model in the SAP Cloud Product as a prerequisite. Integration Scenario and API List.xlsx (Public) ,Data Model Considerations for Data Protection.pdf (Public) can be used to
Data / Integration is the heart beat of a process user story that acts as a catalyst to improve the process efficiency and build real time intelligent connected enterprises. Don’t Lift and Shift existing Data and Process interfaces instead ask the business “Can I decomission the existing interface by using standard best practices or pre-packaged content or use intelligent process automation to improve the process efficiency?What minimum volume and type of data I need to migrate to SAP cloud systems to support my operational MVP Business Process Model”?Do I derive optimum business value in replicating real-time data or API enabling this interface to build connected processes and improve customer experience?
2. Change Champions
Set the Right Expectations to Senior Stake Holders & Onboard a Customer Cloud Champion
Problem: As I said before,the expectation of the business teams that “What works on on-premise should work on on-cloud” is enough to de-rail the entire project and cost an organisation lot of money as it results in delivering a highly bespoke custom SAAS solution diminishing the reason why the organisation has decided to move the solution into the cloud in first place”. This is often the case when organisations implement SAP Cloud Projects with a mindset of “Lift and Shift” approach or when the SI partners and customers approach the cloud projects from an on-premise implementation mindset.
Recommendation: It is very important that we set right expectations to senior stake holders from the beginning of the project with the help of SAP Customer Engagement Success Manager on how cloud project are expected to be delivered for maximising ROI. Additionally,I would also recommend to work with steering board to identify customer cloud evangelist champions who will work with SI Partners to drive the “cloud mindset” across the customer’s business and IT operational teams. They can work with SI Partners in crafting “Design Thinking Demo Evaluation Worshop Templates” and help to educate business teams on how they can evaluate existing business processes using SAP Activate best practices and shift to“Fit to Best Practice Standard” instead of “Fit to Gap” approach.
Define & Tweak your Waterfall or Agile Change Control Processes to work for SAP Cloud Project
Problem: In most of the cloud projects especially when they follow agile model, customers think they can change requirements or drop more use stories during UAT phase or some times even a day before go-live and expect that we can still deliver the project to plan as long as we have appropriate change control. It might have worked in good olden days of on-premise systems where you can do heavy bespoke customisation and ability to deliver the changes using either your internal team or SI partner team.
Recommendation: I found it useful to educate and help customer and product owners on how change control process will work on SAP Cloud Projects up-front at the beginning of the project as it helps you to set right expectations on “what & how much customisation we can do with SAP Cloud Products” and “what dependencies we may have on SAP Incident Management teams” to deliver new requirements and any other external factors that needs to be considered if we need to deliver new requirements for the go-live for both Waterfall or Agile methodologies to ensure that they understand the lead time to deliver the new requirements or user stories. Please use SAP Activate accelerator How to Approach Change Impact Analysis – Cloud.pptx (Public) to educate customers on how to do a Change Impact Analysis that captures all implications needed for an efficient and effective stakeholder engagement, communication and organisation transition to enhance solution adoption.
Set up the Right Organisation Structure & RACI Models that works for SAP Cloud Projects
Problem: This is the fundamental issue of many cloud projects that sometimes won’t be addressed till we go into the build and testing phase and is often the case when you approach SAP Cloud Projects using a ‘Fragile’ Methodology. While organisation structure and RACI Matrix is always clearly defined in SAP waterfall projects, it is not that clearly defined in agile methodology and scrum team model as most of the requirements are documented as user-stories which may not have detailed information like a functional specification or don’t have clearly defined user acceptance criteria. In addition, a complex SAP Cloud Project may have several scrum teams who may or may not have clearly defined role definitions and may be capturing the user stories and leading sprints in a different format that may blur the lines on the RACI model on who owns what.
Recommendation: I always found it very useful to add strategy/architecture type of user stories as well into backlog and add a one page confluence type of documentation which clearly defines the RACI model and the end to end strategy/architecture i.e data migration/integration architecture or environments etc.
Additionally, I also like to have a separate user story for every GAP i.e Custom Extension and link a one page confluence documentation to the user story to ensure that there is no-conflict between the expectation of the customer business teams and SI partner solution teams on requirements.
I would generally recommend to add and assign the tasks/sub tasks of the user story for any dependencies to the right teams and raise JIRA tickets of type “Risk/Dependency/Issue” and link it to user stories or tasks to ensure the lines on the RACI model aren’t blurred and misunderstood by scrum teams.
The below diagrams provides a sample reference Org Scrum structure for medium size cloud projects and is essential that you have solution architectsacting as “Scrum of Scrum teams” to align different work streams. You also need to have a release planning and prioritisation of backlog in JIRA across scrums to ensure that dependencies between various scrum teams are communicated across the programme.
Please refer to SAP Activate Agile Methodology accelerators Agile Release Planning (SAP Customer) and Agile Project Team Roles and Responsibilities (SAP Customer) and Availability and Dependencies of Scope Items.xlsx (Public)for further information.
3.Cloud Customisation & Integration & Data Migration Strategy
Get your Cloud Integration and Migration Tools right (Hybrid Integration Strategy SAP ISA-M Model)
Problem: The ability to transfer and translate data seamlessly and quickly in real-time is crucial to business success, but integrating, transforming and and on-premise critical business applications with digital cloud applications that can be hosted anywhere in the world is proving to be a complex challenge for organisations across the globe and eats 50% of your cloud budgets. The problem is a direct result of the organisations executing cloud projects across the enterprise without a proper data and integration strategy and procuring multi-vendor SAAS products where each vendor offers their own data and integration tools.
Recommendation: “It is not Cloud first or API first but Strategy first!” especially in multi-cloud environments!I would recommend organisations to spin and communicate an enterprise wide Data & Integration and API First strategy that should be used across the cloud projects in the organisation in the journey of becoming “Intelligent Connecting Enterprise”. The strategy should go in tandem with your cloud transformation vision of the organisation. SAP Delivers an ISA-M framework that can be used and applied to the complex data and process integration pattern in your organization which is clearly explained in SAP CIO Guide.
Get your Cloud Extension Strategy right
Problem: As much as we want to stick to “Fit to Standard” dream, we have seen ground reality is always different.There are so many times where we need to customise SAAS products to meet business requirements. SAP provides various mechanisms to customise SAAS products which makes it more complicated if we don’t use the right mechanism to extend SAP Cloud Products. I have seen that some cloud extension projects took more than 6 months and some of them took less than 2 months in C/4 HANA based on the approach they took.
Recommendation: SAP provides two mechanisms ” Side by Side” or “In App”extension to extend SAP Cloud products. I recommend to use “Side by Side” when you need to orchestrate complex business logic spanning 1 or more systems and “In App” extension when the customisation is simple. SAP also provided some best practice recommendations on when to use what methodology for S/4 HANA which you can refer here and C/4 HANA here and Successfactors here. The same principles apply to other SAP cloud products but don’t ask me why SAP didn’t provide one extensibility explorer for all SAP SAAS products..!
4.Cloud Testing Strategy
Don’t cut corners on Testing ! Run Performance, Penetration and Vulnerability Testing!
Problem:“Agile and cloud testing is adhoc as it trades speed for Quality and there isn’t a well defined testing strategy or specific role for testing to do stringent quality check as requirements aren’t detailed enough” is general perception of many project teams. This is merely a myth if the projects are set up correctly but it is a ground and harsh reality when projects follow “Fragile” Methodology and when customers and SI partners don’t negotiate a right commercial model for Agile projects.
There is also a misconception that we don’t need to vulnerability or performance or penetration testing as cloud systems scale automatically to demand and are secured.
Recommendation: I always recommend to configure “Data Migration Testing,SIT, UAT, Performance, Penetration, Vulnerability” as additional sprint cycles with clearly defined entry and exit criteria for each sprint testing cycle in JIRA and clearly define what volume and type of data you need in SAP Cloud systems for each testing phase.
It is important to note that “Cloud is as secure as you configure” and there are some aspects of the cloud that are secured by the cloud providers and some aspects of security has to be configured and secured by the customers.
Though cloud systems automatically scale to the demand based on the sizing and license model that you have chosen, there may be some SAP components that can’t scaled automatically due to “bad design of custom components” or “sizing is not aptly calculated due to the missing requirements ” etc and hence it is required to test the cloud environments.
You can use following templates to accelerate your SAP cloud testing Test Your Processes User Guide.pdf (Public) and Automated Test Scripts Index.xlsx (Public) and Test Automation Tool for SAP S4HANA Cloud.pptx (Public) and Test Strategy Template S4HANA Cloud.pptx (SAP Customer). Please note that you can use SAP Cloud Industry Solution Product specific SAP Activate test templates based on which product you are implementing.
Get the Deployment of SAP Cloud Tenants Right
Problem: There are various ways to deploy SAP Cloud tenants i.e on single cloud private tenant, multi-tenant, in HEC environment hosted by SAP or on-premise hosted in your data center, hosting company or hyperscalers of your choice. It is often confusing to decide which is the right deployment option for you and it may cost dearly if you don’t get this right.
Recommendation: The following image is taken from a great blog by Virendar Kaushal and shows the factors that you may need to consider to evaluate and choose the right deployment model for a S/4 HANA transformation. You can follow the below evaluation model for other SAP Cloud SAAS products (Ex:C/4 HANA, SuccessFactors etc) if the deployment model is available for the product.
Ex: A client who has tighter GDPR security laws and specific performance requirements and who want to enjoy a highly dedicated cloud infrastructure, may choose a private cloud deployment model (SAP Cloud For Customer Single Private Tenant). In contrast, a small or medium size company with limited budgets and rigid timescales may go for multi-tenant architecture.
Factor in the Quarterly SAP Cloud Upgrades dates into your plan
Problem: SAP Cloud projects generally run for more than 3 months for medium to large size clients even though we limit the customisation. The upgrades may have an impact on the functionality you are building and they also can impact your plans .
Recommendation : Watch out on quarterly upgrade dates and factor them into your plans from early stages and also ensure that project and testing teams are included into SAP Cloud Maintenance and Downtime e-mails. You also need to have a set of test regression packs to test after ever upgrade to ensure nothing is broken due to a upgrade. Please check out https://blogs.sap.com/2019/02/15/sap-s4hana-cloud-upgrade-is-regression-testing-needed-what-do-i-need-to-test-and-how/ and note that you need to follow similar approach for other SAP Cloud products.