Public Cloud Solutions (aka SaaS) at Operation – Why adoption is crucial?
This article is about Public cloud services (also known as software as a service) and not covering platform or infrastructure as a service. All core principles are valid for the SAP Cloud product family and all public cloud vendor offerings.
Cloud operations help companies operate, adopt and develop software applications. In this article, we explain why cloud operation should include adoption, how the teams should work together and what needs to be delivered to the business.
Why is adoption crucial for your cloud solution?
Characteristics of on-premise solutions
I am trying to simplify a bit here to provide the core message. Let’s talk about on-premise solutions first. Let’s assume, you have an SAP HCM solution, and a project team helped to deploy the solution. At GoLive, you cover all the business requirements. However, after some years, the business requirements increased. To cope with the new requirements, a costly upgrade project was conducted so that capabilities meet requirements. Such upgrade projects are typically every two to three years.
Per definition, it is about “need coverage” and software solutions trying to cover the business blueprint.
(For the sake of simplicity, as mentioned, I am discarding the EHP activation and providing changes around legal requirements).
Characteristics of on-cloud solutions
Here it gets more complex to understand. The baseline when the solution went live is the blue line shown above. Even if customers do not conduct projects or adoption activities, thanks to ongoing global release changes, better and more compliant solutions are available over time (the gray line).
The cloud solutions’ ground-breaking innovation capability could be seen in the blue line. Third-party solution extensions, other easy-to-integrate cloud solutions, and new optional capabilities introduced by the vendors make the solution capability much better than business requirements.
Here the core mindset is not trying to cover the business blueprint but provide the best meaningful cover via fit-gap analysis where customers can discover new and valuable capabilities that the new solution offers; therefore, it has a “want generation.” nature. Solution capabilities are much higher than business requirements. The delta between the solution capabilities and available solutions without adoption could be considered an adoption gap.
Ideal operation of cloud solutions
Ideal operation of cloud solutions
For the sake of clarity, I am simplifying here again. At the high-level, adoption should not be a one-time activity like on-premise but a continuous effort for long-term value realization. As you can see in the blue line, solution capabilities are improved over time between release cycles. SAP Successfactors offers a new release and off-cycle mobile releases every six months and several innovations via its ecosystem.
Here the cloud solution provides capabilities (blue line) that are more comprehensive than the business requirement (red line). The solution covers not only the blueprint requirement but also new capabilities for business. For example, the digital signature was not in the scope, but it is available and straightforward to integrate. Therefore we could enrich the initial scope. Or mobile native reporting via tables was not part of the initial blueprint but became available out of the box. Therefore again, we could enhance the initial scope. These scope enhancements (innovations) are the area between red and blue lines. Per definition, such enhancements are not readily available at the on-premise option.
To deliver the ongoing change(adoption), a cultural and structural shift must occur within an organization to support successful business innovation via cloud technologies. This foundational change is often referred as cloud mindset.
How to govern the cloud solution for Change & Success?
Let’s be specific and take SAP SuccessFactors and HR as example solutions. As explained in “Why is adoption crucial for your cloud solution?” section, a cloud solution without ongoing adoption is a waste of investment and missed opportunity.
Here are some key areas you need to address for your cloud journey.
- It would be best if you shifted away from a one-time launch to an ongoing time and resource investment.
- SAP partnership becomes continuous and essential to understand the roadmap and capabilities coming from SAP and the whole SAP ecosystem.
- It would help if you planned the teams for continuous support innovation via your cloud investment. That typically involves several teams’ collaboration to evolve to execute the change and maximize outcomes.
Let’s talk about the key players for SuccessFactors solution adoption (SAP point of view).
- SAP Solution Extensions and supporting apps, several cloud solutions could be integrated into SuccessFactors like digital signature, candidate background check, AI-powered candidate filtering, or LMS content. The SAP SuccessFactors ecosystem offers hundreds of additional capabilities.
- SAP Product Management, it provides release changes and new capabilities twice a year and the product roadmap for the next two to three years. Moreover, they also announce sunsetting features.
- SAP Cloud Product Support and Engineering teams, they are supporting customers in explaining and deploying these capabilities.
- SAP Cloud Operation team, They work closely with other parties to keep the landscape technically competitive, including hardware changes, security updates, and application patches. Customers have to follow their guidance. (e.g. update SSL certificates, aware of system maintenance times)
Let’s talk about the key players for SuccessFactors solution adoption (Customer point of view).
Teams and structures at customers
The chart above is a streamlined view of the customer team. Depending on the size of the customer, some teams and functions are done by a super user or an IT admin. Some parts could be fully or partially outsourced. Similarly, different countries or solutions could add further complexity and need additional support units.
An approach, how to run the change management at SuccessFactors?
A model proposal for an ongoing adoption
Let’s talk about the model,
Listen to the voices of change; employees, business and system capability, what could be better or different today, drive business needs, strategy & change imperatives.
(e.g. Can we introduce digital signature and avoid paper? Can we merge 2 or 3 screens to avoid several mouse clicks and waiting time? Which new mobile scenarios could be deployed? Where else can we use AI in our process?)
Understand the SAP SF roadmap, available capabilities, and out-of-the-box offers from its ecosystem.
(e.g. Review and deploy SAP key features and release changes regularly. Understand the scope of the coming releases to avoid obsolete custom developments. Discover solution extensions or other apps that could be integrated and add value)
Change Management, Collaborate with HR, IT, and SAP to deliver changes via the operation process. For major change requests, manage the possible to the actual via a governance process that approves where investment should be made & budgeted every year.
(e.g. Cloud operation is a culture fostering collaboration amongst all participants involved in the development and maintenance. Change request management and impact analysis are quite important. The intention is not to activate each and every feature but to activate only impactful and relevant ones.)
Govern the changes to the system and process and data that support the planning the right way; A Global process and data owner/architect to understand what happens in the change.
(e.g. which data is kept where and why? When should these data be purged? Is the change a legal complaint? Where is the data kept?)
Plan and deliver IT owns the final steps in this process (incl. testing, documenting, and training); the rest comes from the business owners and how they operate better now.
(e.g. Executing change management and tracking the usage. Document the process and update training materials and regression test scenarios if required. Train the users )
We observe customers experiencing diminishing returns after SuccessFactors golive. I want to share some of the typical reasons to learn from these,
- HR team, from time to time, raises a change request via RFP (against shared blueprint) and asks the IT team to facilitate. It typically leads to custom development and increases support complexity and cost of ownership. Most of these could be covered via standard or partner offerings.
- Customer satisfaction fades after two to three years post-live, and the adoption initiatives stopped after the project handover to the operation team; the critical people left; the initial business value is now a new baseline; hence perceived solution value for the key stakeholders, like IT and HR leadership, is limited.
- No or minimal adoption since go-live leads to a growing gap between what the system can do (the art of the possible) and what is implemented/used. The solution is two to three years old, outdated, and not competitive with the alternative solution in the market anymore.
- IT Team or its subcontractor, operation partner, has limited time and competence to evaluate and defacto blocking any adoption request from business and also not capable to evaluate new features from SAP SuccessFactors, vendor.
Further reading, references.
- to be updated
Hopefully, this blog helps you better understand the necessity for the ongoing adoption need SAP SuccessFactors like any other public cloud solution.
I look forward to getting questions from you, our customers, to enrich the blog further and aim to explain more about your best practices and experiences.
An informative article and so important for customers to understand that the job isn't over when the solution has gone live. Thanks Orkun
Great article, Orkun, thanks!
Thanks Orkun, great approach and helps to clarify why? How? What? When? ....well done!