Few at SAP are better qualified to speak to the evolution of the company’s cloud ERP portfolio than Jan Gilg, President and Chief Product Officer of Cloud ERP.
A 17-year SAP veteran, Gilg has held multiple roles at the company, including Global Head of Enterprise Architecture, Global Head of IT Business Services, and SVP & Head of SAP S/4HANA. That last position, which Gilg started at the beginning of 2019, expanded a year later to encompass SAP’s digital supply chain portfolio, leading to his current role, where he’s responsible for digital supply chain and SAP’s cloud ERP.
Whether he’s spending time with customers (at least one a day), communicating with the SAP partner ecosystem, or handling internal responsibilities (driving product strategy, identifying future areas of investment, and learning how to improve delivery, technology, and integration efforts in support of the entire SAP ecosystem), Gilg keeps busy.
“We can come together much more closely, which requires internal alignments and covering end-to-end processes for customers. My days are packed, excitingly so. There’s so much going on in this space.”
-Jan Gilg, President and Chief Product Officer, Cloud ERP, SAP
Below, in the first half of our wide-ranging conversation, Gilg discusses his views on the importance of digital transformation, shifting away from customizations, and the role that AI can play in helping customers navigate cloud ERP.
This interview has been edited and condensed.
Question: What are you hearing from SAP S/4HANA customers about the business and technology challenges they’re facing?
Answer: When we launched S/4HANA in 2015, the narrative in the market was that SAP was forcing a new ERP solution on customers. At that time, we also announced the end of maintenance for SAP ERP Central Component (SAP ECC). S/4HANA is not an upgrade, we said: it’s a new product, because we wanted to do things very differently. ECC was an evolution, by and large, of the SAP R/3 system—and it did evolve, certainly. But to do things differently on a fundamental level, you have to be more disruptive.
We decided to leverage the HANA database, which was hugely innovative at the time, and optimize the software for this database. This gave us the ability to rethink certain processes, specifically around finance but also in logistics and supply chain, and to do more in real time, by automating different steps. Over the last couple of years, in my view, the discussion has shifted from “SAP wants us to move to this new ERP, so let’s do it as quickly as possible” to companies understanding that this is an opportunity, amid ongoing marketplace disruption, to rethink business processes and drive those projects from a business perspective.
In The Matrix, Neo gets offered a red pill and a blue pill. The red pill leads to Wonderland, and the blue pill leads to stagnation. That’s the choice customers have at the moment: “Do I embrace digital transformation and get myself ready for the next decade? Or do I stay where I am?” Very few want to stagnate, so this has completely changed the narrative. Companies have realized the importance of those processes that ERP and supply chain cover. Supply chain disruption, after the last couple of years, is top of mind for customers. They need flexibility, visibility, and the ability to de-risk their supply chains. That's not possible on the IT infrastructure and systems they’re running today.
For us, S/4HANA has never been about end of maintenance for ECC. We just believe ECC had its day, and now it's time to think differently. That's why I believe S/4 is the right step for our customers. I believe, by and large, the majority now sees it the same way.
Q: So, you’d say one of the shifts you've seen from customers is away from the question, "Do we pursue cloud ERP?" to "When do we pursue cloud ERP, and in what form?"
A: Yes, exactly: when and how. There’s this whole discussion of greenfield, brownfield, and anything in between. It's become less brownfield over the last couple of years, and more customers do greenfield. Some even decide to go as far as SAP S/4HANA Cloud, public edition, which is a different animal. Most do something in between.
Customers now look into their processes and ask what’s differentiating for them. Perhaps they carry over customizations in those processes that are unique to them; but, for other processes, they go back to standard, taking whatever is in the software and getting rid of all the bells and whistles they put in because they thought they needed to run processes for accounts payable (AP) or accounts receivable (AR) in a certain way. They standardize and leverage the synergies that come with that. That discussion’s happening everywhere with all of our customers.
Q: In encouraging a fit-to-standard approach, you’re also advising a narrower scope for at least that initial implementation, then engaging with customers over an extended period of time to determine what else they need. Often, the result is less customized than you would have seen in an on-premises application.
A: That’s always the elephant in the room. On the one hand, customizations made SAP software very sticky, especially ERP, although they helped customers at the time. But the pendulum swings back and forth. There was a time where customers built IT capability and hired very knowledgeable people, and the open platform allowed pretty much everybody to extend it. Later, they obviously paid the price because they realized it became extremely difficult to upgrade the system, and the test cycles became extremely long. Customers shied away from doing this, and they started to get stuck.
With ECC, we had enhancement packs. But at some point, customers wondered why they couldn't consume even innovations that SAP shipped, which they’d paid for. There was innovation in those enhancement packs that would have been really helpful for the customers, which was unfortunate. We believe the R&D spend we put into our products will help customers manage their challenges, so we want customers to be on the latest releases. I believe this is behind a shift in the market toward the software-as-a-service (SaaS) model.
We see this demand increasingly in ERP for our installed base, in the very large instances and with those that have a lot of customizations. For them, transformation is a huge step, because it involves greenfield implementation with a very high degree of standardization and change management. That's why we needed a vehicle to help those customers and launched the RISE with SAP offering, with S/4 Cloud at the core: to help customers in that journey, not only with their target states but also with how to get there. How customers can arrive at a clean core and manage active custom code is a critical question. We’re continuing to invest in tooling to help customers achieve that.
The objective of running cloud ERP is to help you standardize, to be on a model that is much more scalable and elastic, so you can be more flexible. And flexibility is something that has not traditionally been associated with ERP, but I believe it’s the future. That's why SAP is changing from an architecture perspective. We’re becoming much more modular, offering more deployment flexibility and different hybrid approaches, all to make it easier for customers to adopt.
Adoption is the key. I don't even look at bookings or revenue numbers, typically. I look at adoption numbers, because I want customers to implement and use the software, which is a huge stack. In the on-premises world, frankly, my organization has been decoupled from customers. We sell it, and then you get support tickets, requests, and sometimes feedback, but we can’t look into the system and understand what customers are actually doing—what are they using, how often, what’s appreciated, what’s not used at all. But with cloud ERP, that’s more possible, which is why this approach helps us build technology more relevant for our customers.
Q: Integration between SAP and non-SAP systems is a major topic of interest for our members. How will SAP address the complexity of hybrid environments and move to meet these customers where they are?
A: I believe it’s absolutely critical to stay open in the cloud. We cannot afford to be a closed shop. That’s why we're heavily investing in providing APIs in our solutions. Of course, there's a distinction between that and integrating SAP to SAP, which has to have a different quality than integrating third-party products. We also have strategic partnerships with companies like Siemens, in the product lifecycle management (PLM) space, where we have SAP Teamcenter by Siemens and integrate that almost like an SAP product. Of course, every customer also has competitive products. No question. We have to be open, but we don’t actively build adapters to integrate to those solutions. We offer APIs, and the customer can connect those systems into an SAP backend or landscape.
I believe, still, one of our key differentiators is that SAP to SAP should always work the best. It should be the most seamless for the customer, while staying open to connect any other solution. But there has to be a difference in quality. We don’t provide mappings into competitive solutions, we wouldn't work with a competitor to align data models, and so on. We only do that internally and with our strategic partners.
If you think about how this evolves in the cloud, we see more customers looking to only pay for what they use, so to speak. They always ask us to be more transparent and more modular. If you think that through, theoretically, customers could almost assemble software themselves, out of a catalog of cloud services. With core finance, customers could configure it in an end-to-end process, and we would only deploy those kinds of solutions to them, as well as the services needed to assemble a solution that covers such a process.
For that to work, those solutions need to be harmonized, technically; they have to seamlessly integrate. They have to have the same provisioning mechanisms, the same operating and support models underneath.
That’s why we're harmonizing our portfolio to offer that technical flexibility, which will also offer us commercial flexibility. This is critical in the SaaS world, where we have full control of cloud services, and why we're expending a lot of R&D on integration topics. At SAP, when we develop new capabilities, we’re developing a lot of them on the SAP Business Technology Platform, in a way that's an integral part of the S/4HANA Cloud package. We see benefits to being cloud-native. And we'll be able to offer that flexibility to the customer.
For procurement in S/4HANA Cloud, public edition, we’re building the buying 360 capability, a shopping cart for purchase requisitions. This will come pre-integrated, as part of S/4HANA Cloud, public edition, and it feels like part of the overall solution. But it can also be bought by a customer who only buys SAP Ariba Buying. This helps clean out the portfolio and get rid of redundancies. Those redundancies always caused questions for our customers.
Now, a customer can start by implementing a procurement solution and, later, if they want to implement a S/4HANA Cloud solution, the procurement module would be identical. There’s no need to re-implement. It will just fit into the broader ERP story. This is the vision we're working toward, in all areas.
Q: Technology is facing talent shortages, and our members tell us that mastering technical migrations, such as those required in the move from ECC to S/4HANA, is a top priority. How does SAP provide customers with the expertise they need to navigate cloud ERP?
A: There are multiple angles to that. Firstly, we help with what we call product lead growth, especially in the public cloud. We’re building capability into the product that prompts customers and end users toward tools they can use. In addition, we monitor the usage behavior to see what the customer is using versus what they are entitled to use, and we can actively notify them about what they’ve subscribed to that would add value. Additionally, we should discuss leveraging artificial intelligence. Now, with hype around generative AI, we are obviously looking into digital assistant tools that will revolutionize the user experience.
At the end of the day, AI could help to accomplish the vision we’ve been talking about for years: that customers can talk in business language about technology problems they need to solve—creating purchase orders, for example—and the intelligent digital assistant will then take over. All the customers would have to do is add any additional missing data. The customer wouldn’t need to understand the plumbing.
The complexity of the process hasn't changed; the plumbing is still there. That’s always been a strength of ours, that we can actually support this complexity. But we need to shield it from the end user. I believe generative AI will play a huge role here. There’s a big push around AI and generative AI at SAP, on how can we help customers more easily accomplish what they need to accomplish—to help them leverage the full power of the system.
Q: Outside of making support within S/4HANA more responsive, what other use cases do you envision for AI within S/4HANA?
A: The most obvious use cases are those that help customers automate processes, get additional insights, improve the user experience, and so on. Other aspects that we're actively looking into are ways to improve implementation time. At the end of the day, a configuration in the system is nothing but answering business questions, right? It should be possible to use AI to help automate configuration, which could bring implementation costs down.
From an operational perspective, if you think about monitoring systems, site reliability, and preventative ways to avoid outages, AI can be tremendously helpful. Internally, we are also looking into how we can leverage tooling that helps us develop software, and some of this tooling could be made available to customers and partners, because extensibility is always going to be a major component of ERP.
In addition to no-code, low-code will get another boost through generative AI, letting customers produce protocols and extend solutions without being programming experts. That may be little further out, but these are all things we’re looking into from a development perspective, and we have started proof of concepts (POCs) for.
For more from Jan Gilg, read the second half of our interview here.