- SAP Managed Tags:
Introduction
This blog discusses the common pitfalls of implementing SAP Cloud Projects especially when most of the partner and customer teams come from implementing SAP in an on-premise landscape using the waterfall model.
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 colleague dav_keytree & Manish Bhalla for contributing into this blog.
Common Pitfalls
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 pre-configured MVP's designed for the purpose of meeting MVP time frames .
Define and Communicate the Objectives & 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 as the cloud transformation project is just percieved as an IT system upgrade as the business objectives and quality gates aren't defined and communicated clearly across the organisation.
The projects followed fragile methodology due to the complexity of the customization and it neither had milestones and quality gates that you generally have in waterfall methodology and nor the stage gates/show & tell or score cards or story point estimates or well defined user acceptance criteria that you generally use in Agile projects.
Achieving an ROI and measuring success of this project 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.
SAP Activate provides a good starting point with 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 support you through that process.
The following table can be used as a guideline to set the right expectations on the project governance and define the right measures of success based on the methodology you had chosen.
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. The general reason behind that is due to the time that it takes to understand the existing interfaces and legacy data models due to poor documentation or probably due to the fact that it is outsourced to niche SI Partners or third party vendors .
The other compelling reason to not to include data and integration build in sprints 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 to finalize To-Be data models and then sign a waterfall contract model late in the day for Data/Integration delivery.
Recommendation: I always recommend clients to include migration/interface build into sprint increments but 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 worst case if you think project scope is shifting on the sand constantly and it is complex to work out a Agile Contract commercial model with third party vendors then establish the change control process to plan and communicate the release dependencies between SAP Cloud To-Be Data Model and Configuration Sprints and Data Migration/Integration waterfall commercial model. Ex: Sprint Backlog has to be baselined with an estimate on when the data model and configurations are available for Data Migration/Integration build to complete i.e JIRA Sprint release plan should be aligned with phased waterfall plan for Data/Migration Deliverables.
While many people use MS project/excel plans to track data migration/integration build and Jira velocity reports for building other components of SAP Cloud Projects, I would always recommend to use one tool i.e JIRA as waterfall plans generally will quickly be out of date when you follow a Agile Model for rest of the project.
In Jira, I will probably do this :
- Create Migration and Integration work streams as epics
- Create a user story for each data/integration interface
- Add the user story that is responsible for configuring SAP Cloud To-Be DATA model and Configuration as a pre-requisite.
- Add Tasks/Sub Tasks into a user story
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 to onboard customers on how cloud project are expected to be delivered for maximising ROI and help customers to plug the knowledge gap inside the organization.
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 i.e baselining & prioritizing the backlog and how important is user acceptance criteria for a user story at the beginning of the project as it helps you to set right expectations.
I also tell customer upfront in the beginning of the project "what & how much customisation we can do with SAP Cloud Products" and "what dependencies we may have on SAP Incident Management teams" and "what type of incident management that clients needs to do with the help of SAP Customer Engagement Manager" 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.
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 mixed bag of Waterfall and Agile i.e '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 and dependencies between scrum teams aren't communicated properly.
Recommendation:The projects that used following 5 principles worked well :
- "Solution Architect Scrum Team" with product owners for each workstream reporting into them. SA Scrum team has the responsibility of communicating the dependencies between scrums and prioritizing the backlog items between multiple scrums and resolving the conflicts.
- Add strategy/architecture type of user stories as well into the backlog and reference a one page confluence type of documentation which clearly defines the RACI model and the strategy(Environment/Migration/Integration) .
- Add a separate user story for every GAP with type "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.
- Add a task/sub task with a link to SAP Incident Number assigned to SAP Engagement Manager if the custom requirement requires support from the SAP incident or product team.
- 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 for better visibility of the overall status.
The below diagrams provides a sample reference Org Scrum structure for medium size cloud projects and is essential that you have solution architects acting as "Scrum of Scrum teams" to align different work streams.
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.
5.Infrastructure Strategy
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 graphic shows the factors that you may need to consider to evaluate and choose the right deployment model for a S/4 HANA or C/4 HANA or SuccessFactors transformation.
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-nee... and note that you need to follow similar approach for other SAP Cloud products.
Zero down on the right tier for SAP Cloud Tenants
Problem: SAP provides 2 tenants by default for the test and production landscape.It will work for small to medium size clients who doesn't need to do lot of customization of the SAP Cloud product and who have a small set of integration/migration interfaces.
We need to license additional tenants and hence many clients generally stick to 2 tenants without evaluating whether the tenant landscape is right.
On the other extreeme, I also saw large clients procuring lot of additional tenants matching their on-premise landscape irrespective of whether it is really needed.
Recommendation: I recommend a minimum of 3 tier (Development where you test bespoke development, Test & Production Client) architecture for clients who has medium to high complex customisation requirements.
Additionally I would recommend to have a temporary stand alone Migration/Performance Test client that is replica of production tenant size. You can do migration and performance tests during the project life cycle esepcially if you need to migrate millions of records and have more than 45 interfaces to integrate. If you are pressed on the money then do your high volume migration and performance tests in the production environment but please have a strategy to take a SAP Cloud restore point before you commence the tests via SAP incident management if you need to erase the data after you have done your stress tests.
However, you also need to check other factors to decide whether the tenant landscape is right according to SAP Best Practice Gudelines below.
- SAP C/4 Guidelines for Tenant Landscape
- Side by Side Extension - Multi-Tenancy Development on SCP Cloud Foundry
- Side by Side Extension - Multi-Tenancy Development on SCP Neo
- Multi Tenancy Architecture Guidelines on SCP
- SAP CPI Tenant Landscape Guidelines
- SAP Cloud Platform Account Model
- SAP S/4 Guidelines for Tenant Landscape
Golden Principles
SAP introduced these five golden rules for Implementing SAP S/4HANA with Cloud Mindset few years ago mostly focusing on customers deploying private cloud version of SAP S/4HANA Cloud. While they were aimed at that audience, I believe these rules represent the optimal way to deploy the SAP S/4HANA software and enable continuous innovation through the lifetime of the system. Let’s look at these rules as they are embedded into the SAP Activate methodology and are enabled through pre-configuration that SAP and SAP partners deliver. Check Updated rules here.
4 Comments
