How SAP users are achieving retail transformation with Google Cloud

The retail industry is in the midst of a transformation. Online commerce has emerged as a force to reckon with, commanding close to $6 trillion in market opportunity by 2022. With so much at stake, nearly half of all retailers are looking to the cloud to improve customer omnichannel experience and retail store performance. And retailers utilizing SAP solutions are no exception: 75% of retailers surveyed by the Americas’ SAP Users Group (ASUG whitepaper) expressed plans to increase digital investments in the next two years by at least 10% in order to accelerate digital transformation. Of those surveyed, 1 in 4 intend to increase investments significantly, by 50% or more.

Retailers know what they need to offer to evolve today: a customer-focused, data-driven, seamless customer experience. But that journey is filled with technological roadblocks that are leaving even the largest retailers in limbo. For retailers innovating with SAP technologies, these roadblocks can present difficulties while migrating, deploying, and running new software that’s expensive and challenging to scale on legacy, on-premises infrastructure. Central to making the transformation journey a success is leveraging the public cloud and choosing the right public cloud service provider (CSP) — remember that not all clouds are created equal. Here at Google Cloud, we’ve helped SAP customers and retailers achieve transformation success by:

  1. Giving customers a simplified cloud journey with access to our Cloud Acceleration Program (CAP), and our robust partner community

  2. Helping to accelerate innovation with industry-leading advanced analytics and AI/ML tools.

  3. Providing a scalable and elastic infrastructure to rightsize your applications and instances.

  4. Minimizing downtime with automated infrastructure maintenance with our Live Migration offering.

Let’s take a look at how three retailers using SAP on Google Cloud were able to face their technology challenges head-on and bring their visions for digital transformation to life.

Omnichannel: MediaMarktSaturn’s road to customer-centricity

Customers in the digital age expect personalized, seamless omnichannel experiences—from browsing online or via mobile to in-store and checkout. Most retailers are eager to deliver on this expectation, especially with rising technologies like AI, ML, and predictive analytics promising seamless omnichannel experiences. But contrast retail’s future tech landscape with today’s reality: 75% of SAP retail solution customers who participated in our recent ASUG study qualify as digital newcomers that are still in the early stages of transformation. In order to successfully offer personalized, customer-centric omnichannel experiences, retailers must generate customer insights in real time. However, this requires massive compute resources that are beyond the capabilities of most current on-premises infrastructures leveraging SAP.

MediaMarktSaturn Retail Group, one of the world’s leading consumer electronics retailers, recently encountered data pipeline challenges that prevented the company from modernizing its omnichannel and retail strategies. MediaMarktSaturn was looking to unify its large data sets and infrastructure across its SAP solutions to generate accurate and relevant insights for both its business and its customers. However, MediaMarktSaturn’s legacy hardware infrastructure was not only incapable of handling the data volumes required to realize its omnichannel goal, but it was also unable to scale up and then back down again to accommodate varying levels of traffic without disruption. 

To overcome these technical and infrastructural hurdles, MediaMarktSaturn chose Google Cloud to help modernize and migrate its SAP workloads into the cloud. Together with Google Cloud, MediaMarktSaturn decided to leverage Google Kubernetes Engine (GKE), BigQuery, and BigTable to store, mine, cleanse, and analyze data to generate real-time, personalized insights that would better serve customers across all channels. The effort has so far yielded a 30% increase in conversion rates, due to optimizing their search technology and high-performance data handling. Looking to the future and equipped with the tools to modernize its retail strategy, MediaMarktSaturn has started to build analytics tools that explore price elasticity and price prediction based on multiple variables.

Store operations: How Loblaw is delighting customers with seamless experiences

Building on the omnichannel experience, retailers are also rapidly modernizing store operations, outpacing the agility of their on-premise SAP infrastructure. With optimized express checkout, on-shelf and intelligent inventory management, and dynamic assortment planning on the retail tech horizon, it’s becoming increasingly critical that retail businesses have the foundation to build, test, and deploy the emerging technologies that are critical to compete. Retailers that delay infrastructural modernization in favor of layering new swaths of code on top of legacy systems risk creating a highly complex, coupled, and unscalable monolith that’s prone to downtime and data inaccuracies. 

Loblaw, Canada’s food and pharmacy leader and the nation’s largest retailer, recently encountered data pipeline issues similar to those at MMS while leveraging SAP Hybris in traditional on-prem environments. It had the goal of enabling personalized product recommendations on ecommerce platforms, but the technology was missing the mark, as the quality of suggestions and response latency had room for improvement. Loblaw also wanted to enable marketers to run promotions at any time, without requiring conversations with IT to prepare ecommerce systems. 

Loblaw decided to leverage public cloud because achieving its vision on-premises would require expanding its data centers and creating dedicated IT maintenance and operations teams. Rather than investing even more resources to support dated, inflexible technology solutions, Loblaw picked Google Cloud:

“We thought, ‘Why don’t we offload all that effort to someone who’s doing it at scale, making the appropriate investments, and staying ahead in technology so that we can really focus our efforts on driving value to the customer,’ ” says Hesham Fahmy, Vice President of Technology at Loblaw.

The first phase of Loblaw’s migration to the cloud involved its online grocery store, QuickShop, that leverages transaction data from SAP Hybris. Google Cloud offers a certified infrastructure for SAP Hybris, removing the administrative burden required to create an architectural foundation for modernization. Loblaw also uses BigQuery to run real-time analysis of customer data across the buying lifecycle to serve customers with more relevant offers. 

As a result of the partnership between Google Cloud and SAP, Loblaw has experienced a four-fold improvement in QuickShop’s performance, a three-fold increase in site capacity, and a 50% time savings for its Site Reliability Engineers, allowing the company to focus on further innovations in customer experience. 

Logistics, fulfillment, and delivery: MultiPharma’s path to serving customer needs with automated warehouses 

They may not get as much attention, but back-end operations are critical to retail success. Real-time, accurate, automated warehouse management is one of those workloads. From robotics and RFID tagging to on-demand inventory management, warehousing systems require a vast amount of data from all across a retailer’s ecosystem, both online and in-store. Much like the issues that come with developing omnichannel and store operations innovations, modernizing a company’s warehousing can strain legacy, on-prem infrastructure, causing inaccuracies, downtime, and unfulfilled orders. 

For pharmaceutical retailer MultiPharma, a key value proposition is prompt delivery of medication orders to pharmacists, even during periods of high demand. This required heavy investments in warehouse distribution, robotics, and automation—technologies that need scalable, elastic, and extensible infrastructure. MultiPharma originally satisfied this need with a legacy back-end SAP system and its own private cloud. But issues with cost and flexibility prompted the company to leverage SAP HANA and move to the public cloud. 

While the company considered several cloud services providers, MultiPharma selected Google Cloud for its superior VM solutions, flexible sizing, and pricing structures. MultiPharma phased the migration of SAP workloads into Google Cloud, the first of which involved creating a development environment for teams to conduct agile testing before finishing the product environment. Within the first phase, MultiPharma is already reaping benefits, including greater flexibility and increased resources that allow it to concentrate on further business innovations, such as optimizing ecommerce and customer-facing applications. 

As the retail industry continues to transform, retailers that embrace cloud technologies are increasingly positioned to take advantage of emerging opportunities. But in order for increased investments in digital transformations to pay off, retailers leveraging SAP need to ensure their infrastructure and data pipeline are ready for upcoming innovations. Although many enterprises may be tempted to temporarily solve this challenge by layering software in legacy, on-prem architecture, doing so almost certainly guarantees an inflexible, unscalable, inelastic, and costly monolith incapable of continuous modernization. Like MediaMarktSaturn, Loblaw, and MultiPharma, forward-thinking retailers should consider leveraging the cloud’s many offerings and managed services to not only remove the burden of infrastructure and data development and maintenance, but also to enable the best performance from their SAP and technology investments. 

To learn more about Google Cloud’s work with retailers utilizing SAP technologies and get key takeaways, read “Google Cloud Strategy Guide: 5 Learnings for Your SAP Retail Workloads.” You can also learn more about our SAP and retail industry solutions.

Replicate your data from SAP apps to BigQuery with SAP tooling

As enterprise data grows, and the need for new data tools increases, we know that many of our Google Cloud customers have implemented BigQuery as their preferred big data platform. BigQuery is a serverless, highly scalable, cloud-based enterprise data warehouse with an in-memory BI engine and machine learning built in. It is capable of processing petabyte-scale data sets with unmatched price-performance. 

We also know that lots of enterprises today use SAP tools for large systems like finance, HR, operations and more. As you bring your workloads into the cloud, you can still get the best of those on-prem systems along with the new capabilities you get with Google Cloud. By integrating SAP and BigQuery, you can combine your enterprise data from ERP together with data from other sources, such as social media, websites, connected devices (IoT), or an enterprise tool like CRM in one place, process them quickly and unlock new insights.

SAP and Google Data Integration.png

While there are various methods for integrating SAP and Google BigQuery, one of the most commonly requested we hear is for data replication from SAP sources into BigQuery by using the SAP integration tooling that’s already available to users.     

To make it easier to understand how to implement such a solution, we’ve created an integration guide that includes how to set up near real-time replication of data from SAP applications to Google BigQuery using SAP Data Services (data integration and transformation software application) and SAP LT Replication Server (SLT) (real-time replication tool for big data).

We want to make Google Cloud the best place to run SAP. We’re committed to investing in this space. We look forward to hearing your feedback and sharing more integration solutions in the coming months. In the meantime, learn more about SAP solutions on Google Cloud.

Announcing the general availability of 6 and 12 TB VMs for SAP HANA instances on Google Cloud Platform

Many of the world’s largest enterprises run their businesses on SAP. As these companies drive toward digital transformation and plan for the upgrade to S/4HANA, they are increasingly looking to the cloud to support their mission critical workloads. One of the main advantages of the cloud is its flexibility. Whether enterprises are undergoing substantial organic growth, expanding their portfolio, or contemplating a merger, they want the peace of mind that they have the room to grow and expand as needed. 

To help more enterprises scale and grow their SAP HANA workloads, today we’re expanding our support for larger SAP deployments through a new set of large-memory machine types. We’ve added two new machine types to our VM portfolio, enabling customers to deploy workloads that require up to 12 TB of memory in a single node (scale-up) configuration on Google Compute Engine. These VMs, built on the latest Intel Cascade Lake architecture, are certified by SAP for HANA and are generally available to customers starting today.  

“Our 9TB of SAP data is growing about 1TB per year. Moving to a 12TB virtualized environment with the help of Google Cloud is going to provide us with a better platform for growth as we look to optimize and scale. It’s been a great partnership, I can’t stress enough the excitement I have for where we’re going to take this with Google in the future.” —Duy Trinh, SAP Center of Excellence, Cardinal Health

What 6 and 12 TB VMs on Google Cloud mean for SAP HANA customers
Google Cloud’s unique all-VM approach gives SAP customers the true flexibility to scale up and scale down their SAP HANA workload, without financial penalty. It also simplifies the operational/procurement process, increasing IT’s agility as it serves its business teams.  

Here’s more on what Google Cloud’s unique all-VM approach offers:

  • Flexibility—Upfront sizing is notoriously difficult; you either oversize and waste money, or undersize and risk not meeting business needs. Google Clouds certified large VM sizes give you the headroom for future needs.

  • Simplicity—It can take a lot of work to manage scale-out systems for upgrades, patching, performance, manual table placement, and more. With larger systems, you can simplify by consolidating into a single node. 

  • Implementation choice—Not all SAP workloads support scale-out deployments. For example, to avoid complexity, management and performance considerations, many businesses prefer to use larger (and fewer) nodes for analytics workloads. Larger certified VM sizes mean larger scale-up environments. Only Google Cloud offers these fully virtualized, without the constraints of  bare metal.

Google Cloud’s all VM infrastructure is not just about scalability. It also improves uptime of SAP environments through our VM Live Migration. This allows for infrastructure updates and patching on the fly, without painful reboots or other patching events that result in application interruption—capabilities not available on bare metal implementations. Lastly, Google Cloud complements VM infrastructure for SAP customers with lightning speed network performance, sub-millisecond latencies and robust security.  

To learn more about how we’re supporting SAP customers on Google Cloud, visit our SAP solutions page.  You can also join our  Cloud on Air webinar on September 5th and lear how Cardinal Health plans to deploy a 12TB SAP HANA instance on Google Cloud. Register here.

Best practices for SAP app server autoscaling on Google Cloud

In most large SAP environments, there is a predictable and well known daily variation in app server workloads. The timing and rate of workload changes are generally consistent and rarely change, making them great candidates to benefit from the elastic nature of cloud infrastructure. Expanding and contracting VMs to match the workload cycle can speed up task processing during busy times, while saving cost when resources are not needed. 

In this article, we will explore two options for autoscaling SAP app servers, discuss the pros and cons of each, and walk through a sample deployment.   

The two common approaches for scaling an SAP app server on Google Cloud Platform (GCP) are:  

  1. Utilization-based autoscaling: Generic VMs are added to the SAP environment as usage increases (e.g. by measuring CPU utilization).

  2. Schedule-based scaling: Previously configured VMs are started and stopped in tandem with workload cycles. 

Utilization-based autoscaling

GCP offers a robust VM autoscaling platform that scales the VM landscape up and down based on CPU or load balancer usage, Stackdriver metrics, or a combination of these. The core GCP elements needed to establish autoscaling are:

  1. Instance template: An SAP app server baseline VM image that gets stamped into running VMs on a scale up event.

  2. Managed Instance Group (MIG): A collection of definitions on how and when to scale the VM defined by the instance template. It includes the VM shape, zones to launch, autoscale rules, min/max counts, and more. 

In utilization-based autoscaling, each SAP app server function (for example, Dialog, Batch) has its own separate instance template and instance group so it can scale up and down independently. How SAP systems integrate newly created VMs—by performing logon group assignments and monitoring, for example—differs based on how the system is configured, so we won’t discuss it in this article. 

Here are some of the benefits and challenges of utilization-based autoscaling. 

Pros  

  • When done right, this approach provides the most optimal utilization of resources. Scale-up takes place only when new resources are needed, and scale down occurs when they are not. 
  • Each SAP component scales up or down independently. For example, batch workers are scaled at a different rate and size than dialog workers. 
  • Since there is only a single instance template per component, upgrades and patches are easier to execute.

Cons:

  • Instances are not automatically added to the non-default SAP logon group.
  • Instances are not automatically monitored by SAP Solution Manager.

Implementing utilization-based autoscaling

To implement utilization-based autoscaling, first we need a baseline image of each SAP component. 

Starting with a valid app server dialog VM, remove all hostname references from config/profile  files and replace them with a templated variable, like $HOSTNAME—you will need to replace this variable with the actual hostname using a startup script. Next, take a snapshot of all disks. 

In this example, we assume there are three disks: boot, pdssd (which holds /usr/sap folder), and swap.

Once they’re ready, we create an image out of each snapshot.

Once we have an image of each VM, we can create the instance template.

Now, we can create the MIG that contains a healthcheck and autoscaling policy.

Once completed, the MIG runs the first dialog instance and begins measuring the CPU utilization. As you can see from the variable “target-cpu-utilization” on the bottom line, in this example the MIG adds and removes dialog instances when usage crosses above or below 60%.  

Memory-based scaling

SAP app server load can also scale very well based on memory usage. Thanks to the flexibility of GCP autoscaling, we can easily modify our example to use memory usage as the scale trigger. (Note: Memory usage in a VM is not exposed to the hypervisor, so we will need to install the Stackdriver agent before we create our boot disk snapshot). 

In this case, we’ll set the scale trigger to 50% by executing the following gcloud command, which uses the stackdriver memory usage metric “agent.googleapis.com/memory/percent_used”.

To see the progression of your scale events, simply go to the “Monitoring” tab of your instance group in the GCP Console.

gcp autoscaled monitoring.png

Next-level scaling

You can further optimize scaling by using Stackdriver custom metrics to base it on the actual SAP job load rather than CPU load. Using the SAP workload as the indicator for autoscaling gives you a more graceful VM shutdown, and won’t interrupt jobs that might have low CPU usage.   

Schedule-based autoscaling

Schedule-based autoscaling works best when your SAP app server workloads are running on a known and recurring pattern. 

In this example, we will create a fully configured and functioning cluster, sized to service peak workload. Initially, we create and configure the app server cluster for peak usage, with all VMs up and registered with the correct SAP logon groups. VMs will then be stopped, but not terminated, until the next work schedule. Right before the known work is scheduled to start, Cloud Scheduler revives the VMs, bringing the cluster to full capacity. At a set time when work is expected to complete, Cloud Scheduler then stops the VMs again. 

Here are some of the benefits and challenges of schedule-based autoscaling.

Pros

  • It is a simple environment to configure and maintain.

  • It delivers predictable usage and cost.

  • Desired SAP logon groups are preconfigured in cluster VMs.

Cons

  • Scale events are fixed across the cluster, which creates a rigid scale up/down cycle.  

  • Any change in workload start or end time requires schedule modifications.

  • All VMs come up and turn down at the same time regardless of usage, which can lead to suboptimal resource usage.

  • Stopped or suspended VMs still incur storage cost.

  • Maintenance and upgrades are required for each VM.

Implementing schedule-based autoscaling

The first step in our schedule-based autoscaling example is to build and configure the app server cluster using GCP SAP NetWeaver deployment guides. The resulting environment contains a HANA instance, a primary application server instance, and three dialog instances.

gcp Implementing schedule-based autoscaling.png

If we issue the RZ12 transaction code in the SAP UI we can observe the VMs joining the cluster.

RZ12 transaction code.png

The next step is to label the dialog VMs to include them in the scaling events. In our example, we add the label “nwscale” to all of the instances that will be scheduled to scale up and down.

Following along with the Cloud Scheduler for VM walkthrough, we clone the git repo and deploy the cloud functions that start and stop VMs, and create a Pub/Sub topic for scale up and scale down events.

Now we can test to see if our function can stop one of our dialog instances. 

Based on the tag we created earlier, we base64-encode the message that contains the zone and resource we are operating on.

Then we use the payload to call the cloud function and stop dialog VMs in the us-east4-a zone that’s labeled with “nwscale=true”.

As we can see, the labeled dialog instance in east4-a stops.

east4-a.png

The results of the SAP RZ12 transaction code also show us that the instance is marked in SAP UI as unavailable, but still is a part of the SAP logon group for when it starts up again later.

SAP RZ12 transaction code.png

Now that the initial setup is complete, we can create a Cloud Scheduler cron job to start and stop the instances. For our example, we’ll scale up all labeled instances every weekday at 9AM ET.

We can confirm the schedule has been created through the Cloud Scheduler console.

Cloud Scheduler console.png

To complete the system, just use the same process to create start/stop schedules for all remaining zones. 

The next level: SAP event-based scaling

Since the SAP platform is capable of directly managing infrastructure, we can further improve  our schedule-based autoscaling implementation by using SAP event-based scaling and allowing the SAP admin to define and control the VM landscape. An SAP External Command (SM69) executes the gcloud command and publishes scale messages to Pub/Sub. This can then be referenced in either a custom ABAP or by calling a function module like SXPG_COMMAND_EXECUTE.

Other considerations

When implementing autoscaling in your environment, there are a couple other things to keep in mind. 

Remove application instances gracefully

Scale down does not necessarily drain app server instances before shutting them down, so using the SAP web-based UI instead of rich clients (SAPGUI/NWBC) can limit user disruption.

Monitoring autoscaled instances

SAP Solution Manager requires instances to be added in advance for monitoring purposes. Schedule-based instances can be added as part of their initial configuration, and make debugging easier since they persist after work is done. 

Conclusion

There are many benefits of autoscaling in an SAP app server environment. Depending on the particulars of your environment, utilization-based or schedule-based autoscaling can expand your VMs when you need them, and contract them when you don’t, providing cost and resource savings along the way. In this article, we looked at  some of the pros and cons of each approach and walked through the deployment steps for each method. We look forward to hearing how it works for you. 

To learn more about SAP solutions on Google Cloud, visit our website.

Helping OpenText customers move Enterprise Information Management workloads to Google Cloud

Now more than ever, enterprises are looking to the cloud not just for security, scalability, and access to new technologies, but to drive real business value. For many businesses, the key to this transformation is prioritizing workloads in a few important areas, like ERP and databases. To help, Google Cloud has expanded its partnerships in these areas, developing new ways for customers to run them on the Google Cloud Platform (GCP).

Increasingly, enterprise information management (EIM) solutions are joining this category of “priority workloads,” as businesses try to derive value from their structured and unstructured information. And that’s why today we’re excited to announce expansions to our partnership with OpenText to help more customers migrate their EIM workloads to Google Cloud.

We began partnering with OpenText, a preferred partner for EIM, in 2018, and now our extended partnership spans multiple product and solutions areas, including Anthos for multi-cloud and hybrid deployments, disaster recovery services on GCP, G Suite, and AI and machine learning. In each of these areas, our shared goal is to help OpenText customers leverage the technology, scale and security of Google Cloud.

Specifically, we are rolling out the following new integrations:

  • OpenText has planned containerized versions of several EIM applications on GCP, including Content Server/xECM, Documentum, InfoArchive, and Archive Center. These will all leverage Anthos, our multi-cloud and hybrid offering, to deploy and manage containerized EIM application workloads in a multi-cloud environment.

  • OpenText intends to use Google Cloud to enable multi-layered global disaster recovery services for customers with business-critical EIM workloads running in the cloud, on-premises, and in hybrid cloud architectures.

  • OpenText plans to begin integrating its EIM solutions with G Suite to allow seamless collaboration across the two platforms.

  • We’re working with OpenText to create purpose-built solutions for specific industries, including financial services, healthcare and media and communications, leveraging Google Cloud’s AI and ML services.

Partnering with OpenText is particularly beneficial to customers who are moving SAP applications to the cloud as many run OpenText archiving and other integrated EIM applications to extend the value of their SAP solutions. Our collaboration and OpenText’s investment in managed services in the cloud means these customers can now migrate SAP systems, including their supporting OpenText EIM workloads, to GCP as fully validated and supported applications.

These integrations announced today are just the beginning of our strategic partnership with OpenText. Many customers are increasingly interested in moving critical EIM workloads to Google Cloud and leveraging our reliable and performant infrastructure, AI and ML capabilities, expertise in containerization and our hybrid and multi-cloud solution, Anthos, so we are delighted that OpenText has named Google Cloud as its preferred cloud provider for the enterprise..

We’re excited to bring these integrations to market jointly with OpenText, and we’re excited for a strong future of innovation together—all to the benefit of our mutual customers.

Innovating for SAP customers with Google Cloud

The world’s largest businesses run SAP applications, and increasingly, they’re doing it on Google Cloud. Since announcing our partnership with SAP two years ago, we’ve been expanding our support for SAP customers, from providing global virtualized compute infrastructure with 6 and 12 TB instances for SAP HANA workloads to partnerships with solutions providers such as Accenture, Deloitte, Atos, and Hitachi/Oxya that deliver services for application management, migrations and innovation.

Today, we’re sharing the latest updates on our partnership and how we’re ensuring Google Cloud is the best place to run SAP workloads

Empowering more SAP customers
More and more customers are running mission-critical SAP applications on Google Cloud, including ATB Financial, Carrefour and MediaMarktSaturn Retail Group, and we are continuing to see growth with long-time customers including Tory Burch and The Home Depot, who is now running SAP CAR, EWM and BW in production on Google Cloud. At the recent Google Cloud Next ‘19 in San Francisco, McKesson and Metro AG shared insights into why they chose Google Cloud for their SAP landscapes.

We also continue to expand our ecosystem in support of SAP customers’ journey to S/4 HANA, by working with partners such as Gekkobrain who help automate custom code migration and SNP Group who help automate data migration.  In addition, we have built joint centers of excellence with strategic partners like Accenture, Deloitte, Atos, and Hitachi/Oxya. Together, these partnerships simplify migrations and upgrades for Google Cloud customers.

Introducing SAP HANA Enterprise Cloud as a fully managed service on GCP
We’re also delighted that SAP will bring its HANA Enterprise Cloud (HEC) to GCP, allowing HEC customers to take advantage of Google Cloud’s secure, modern and reliable global infrastructure and capabilities in AI, ML, and analytics. HEC will be offered as a fully managed service on GCP, delivering a flexible operating model to help customers reduce operational complexity.

For customers that require specific compliance certifications and a specialized set of security practices, we’ve also partnered with SAP NS2 Cloud to deliver Secure HANA Cloud on Google Cloud.

Google Cloud at SAPPHIRE NOW 2019
If you’re attending SAPPHIRE NOW 2019, May 7-9 in Orlando, Florida, we’d love to say hello. Stop by the Google Cloud booth #1152 and check out our demos covering innovations in analytics, hybrid cloud, retail, healthcare and more. Come meet the SAP on Google Cloud experts in our booth to learn how the cloud can drive agility, risk avoidance, cost reduction and innovation for your SAP environment. Or join us at our sessions to learn all about SAP on Google Cloud. Here are some highlights:

Why Google Cloud for SAP — a customer perspective
Tuesday, May 7th, 11:30 AM–12:10 PM
Google Cloud with ATB Financial
Session ID: 86665

SAP on Google Cloud — build a reliable, agile and innovative enterprise
Tuesday, May 7th, 2:30 PM–2:50 PM
Session ID: 86676

Big Data for SAP — capture, consolidate and create with Google Cloud
Tuesday, May 7th, 1:30 PM–1:50 PM
Session ID: 86671

Reinventing retail with SAP on Google Cloud
Wednesday, May 8th, 1:30 PM–1:50 PM
Google Cloud with Metro AG
Session ID: 86681

You can find a complete guide to our participation at SAP SAPPHIRE here, and to learn more about SAP on Google Cloud, visit our website.