Few at SAP are bet­ter qual­i­fied to speak to the evo­lu­tion of the company’s cloud ERP port­fo­lio than Jan Gilg, Pres­i­dent and Chief Prod­uct Offi­cer of Cloud ERP.

A 17-year SAP vet­er­an, Gilg has held mul­ti­ple roles at the com­pa­ny, includ­ing Glob­al Head of Enter­prise Archi­tec­ture, Glob­al Head of IT Busi­ness Ser­vices, and SVP & Head of SAP S/4HANA. That last posi­tion, which Gilg start­ed at the begin­ning of 2019, expand­ed a year lat­er to encom­pass SAP’s dig­i­tal sup­ply chain port­fo­lio, lead­ing to his cur­rent role, where he’s respon­si­ble for dig­i­tal sup­ply chain and SAP’s cloud ERP. 

Whether he’s spend­ing time with cus­tomers (at least one a day), com­mu­ni­cat­ing with the SAP part­ner ecosys­tem, or han­dling inter­nal respon­si­bil­i­ties (dri­ving prod­uct strat­e­gy, iden­ti­fy­ing future areas of invest­ment, and learn­ing how to improve deliv­ery, tech­nol­o­gy, and inte­gra­tion efforts in sup­port of the entire SAP ecosys­tem), Gilg keeps busy.

“We can come togeth­er much more close­ly, which requires inter­nal align­ments and cov­er­ing end-to-end process­es for cus­tomers. My days are packed, excit­ing­ly so. There’s so much going on in this space.”

-Jan Gilg, Pres­i­dent and Chief Prod­uct Offi­cer, Cloud ERP, SAP

Below, in the first half of our wide-rang­ing con­ver­sa­tion, Gilg dis­cuss­es his views on the impor­tance of dig­i­tal trans­for­ma­tion, shift­ing away from cus­tomiza­tions, and the role that AI can play in help­ing cus­tomers nav­i­gate cloud ERP. 

This inter­view has been edit­ed and condensed. 

Ques­tion: What are you hear­ing from SAP S/4HANA cus­tomers about the busi­ness and tech­nol­o­gy chal­lenges they’re facing? 

Answer: When we launched S/4HANA in 2015, the nar­ra­tive in the mar­ket was that SAP was forc­ing a new ERP solu­tion on cus­tomers. At that time, we also announced the end of main­te­nance for SAP ERP Cen­tral Com­po­nent (SAP ECC). S/4HANA is not an upgrade, we said: it’s a new prod­uct, because we want­ed to do things very dif­fer­ent­ly. ECC was an evo­lu­tion, by and large, of the SAP R/3 sys­tem — and it did evolve, cer­tain­ly. But to do things dif­fer­ent­ly on a fun­da­men­tal lev­el, you have to be more disruptive.

We decid­ed to lever­age the HANA data­base, which was huge­ly inno­v­a­tive at the time, and opti­mize the soft­ware for this data­base. This gave us the abil­i­ty to rethink cer­tain process­es, specif­i­cal­ly around finance but also in logis­tics and sup­ply chain, and to do more in real time, by automat­ing dif­fer­ent steps. Over the last cou­ple of years, in my view, the dis­cus­sion has shift­ed from ​“SAP wants us to move to this new ERP, so let’s do it as quick­ly as pos­si­ble” to com­pa­nies under­stand­ing that this is an oppor­tu­ni­ty, amid ongo­ing mar­ket­place dis­rup­tion, to rethink busi­ness process­es and dri­ve those projects from a busi­ness perspective.

In The Matrix, Neo gets offered a red pill and a blue pill. The red pill leads to Won­der­land, and the blue pill leads to stag­na­tion. That’s the choice cus­tomers have at the moment: ​“Do I embrace dig­i­tal trans­for­ma­tion and get myself ready for the next decade? Or do I stay where I am?” Very few want to stag­nate, so this has com­plete­ly changed the nar­ra­tive. Com­pa­nies have real­ized the impor­tance of those process­es that ERP and sup­ply chain cov­er. Sup­ply chain dis­rup­tion, after the last cou­ple of years, is top of mind for cus­tomers. They need flex­i­bil­i­ty, vis­i­bil­i­ty, and the abil­i­ty to de-risk their sup­ply chains. That’s not pos­si­ble on the IT infra­struc­ture and sys­tems they’re run­ning today. 

For us, S/4HANA has nev­er been about end of main­te­nance for ECC. We just believe ECC had its day, and now it’s time to think dif­fer­ent­ly. That’s why I believe S/4 is the right step for our cus­tomers. I believe, by and large, the major­i­ty now sees it the same way. 

Q: So, you’d say one of the shifts you’ve seen from cus­tomers is away from the ques­tion, ​“Do we pur­sue cloud ERP?” to ​“When do we pur­sue cloud ERP, and in what form?”

A: Yes, exact­ly: when and how. There’s this whole dis­cus­sion of green­field, brown­field, and any­thing in between. It’s become less brown­field over the last cou­ple of years, and more cus­tomers do green­field. Some even decide to go as far as SAP S/4HANA Cloud, pub­lic edi­tion, which is a dif­fer­ent ani­mal. Most do some­thing in between. 

Cus­tomers now look into their process­es and ask what’s dif­fer­en­ti­at­ing for them. Per­haps they car­ry over cus­tomiza­tions in those process­es that are unique to them; but, for oth­er process­es, they go back to stan­dard, tak­ing what­ev­er is in the soft­ware and get­ting rid of all the bells and whis­tles they put in because they thought they need­ed to run process­es for accounts payable (AP) or accounts receiv­able (AR) in a cer­tain way. They stan­dard­ize and lever­age the syn­er­gies that come with that. That discussion’s hap­pen­ing every­where with all of our customers.

Q: In encour­ag­ing a fit-to-stan­dard approach, you’re also advis­ing a nar­row­er scope for at least that ini­tial imple­men­ta­tion, then engag­ing with cus­tomers over an extend­ed peri­od of time to deter­mine what else they need. Often, the result is less cus­tomized than you would have seen in an on-premis­es application. 

A: That’s always the ele­phant in the room. On the one hand, cus­tomiza­tions made SAP soft­ware very sticky, espe­cial­ly ERP, although they helped cus­tomers at the time. But the pen­du­lum swings back and forth. There was a time where cus­tomers built IT capa­bil­i­ty and hired very knowl­edge­able peo­ple, and the open plat­form allowed pret­ty much every­body to extend it. Lat­er, they obvi­ous­ly paid the price because they real­ized it became extreme­ly dif­fi­cult to upgrade the sys­tem, and the test cycles became extreme­ly long. Cus­tomers shied away from doing this, and they start­ed to get stuck.

With ECC, we had enhance­ment packs. But at some point, cus­tomers won­dered why they could­n’t con­sume even inno­va­tions that SAP shipped, which they’d paid for. There was inno­va­tion in those enhance­ment packs that would have been real­ly help­ful for the cus­tomers, which was unfor­tu­nate. We believe the R&D spend we put into our prod­ucts will help cus­tomers man­age their chal­lenges, so we want cus­tomers to be on the lat­est releas­es. I believe this is behind a shift in the mar­ket toward the soft­ware-as-a-ser­vice (SaaS) model. 

We see this demand increas­ing­ly in ERP for our installed base, in the very large instances and with those that have a lot of cus­tomiza­tions. For them, trans­for­ma­tion is a huge step, because it involves green­field imple­men­ta­tion with a very high degree of stan­dard­iza­tion and change man­age­ment. That’s why we need­ed a vehi­cle to help those cus­tomers and launched the RISE with SAP offer­ing, with S/4 Cloud at the core: to help cus­tomers in that jour­ney, not only with their tar­get states but also with how to get there. How cus­tomers can arrive at a clean core and man­age active cus­tom code is a crit­i­cal ques­tion. We’re con­tin­u­ing to invest in tool­ing to help cus­tomers achieve that.

The objec­tive of run­ning cloud ERP is to help you stan­dard­ize, to be on a mod­el that is much more scal­able and elas­tic, so you can be more flex­i­ble. And flex­i­bil­i­ty is some­thing that has not tra­di­tion­al­ly been asso­ci­at­ed with ERP, but I believe it’s the future. That’s why SAP is chang­ing from an archi­tec­ture per­spec­tive. We’re becom­ing much more mod­u­lar, offer­ing more deploy­ment flex­i­bil­i­ty and dif­fer­ent hybrid approach­es, all to make it eas­i­er for cus­tomers to adopt.

Adop­tion is the key. I don’t even look at book­ings or rev­enue num­bers, typ­i­cal­ly. I look at adop­tion num­bers, because I want cus­tomers to imple­ment and use the soft­ware, which is a huge stack. In the on-premis­es world, frankly, my orga­ni­za­tion has been decou­pled from cus­tomers. We sell it, and then you get sup­port tick­ets, requests, and some­times feed­back, but we can’t look into the sys­tem and under­stand what cus­tomers are actu­al­ly doing — what are they using, how often, what’s appre­ci­at­ed, what’s not used at all. But with cloud ERP, that’s more pos­si­ble, which is why this approach helps us build tech­nol­o­gy more rel­e­vant for our customers.

Q: Inte­gra­tion between SAP and non-SAP sys­tems is a major top­ic of inter­est for our mem­bers. How will SAP address the com­plex­i­ty of hybrid envi­ron­ments and move to meet these cus­tomers where they are?

A: I believe it’s absolute­ly crit­i­cal to stay open in the cloud. We can­not afford to be a closed shop. That’s why we’re heav­i­ly invest­ing in pro­vid­ing APIs in our solu­tions. Of course, there’s a dis­tinc­tion between that and inte­grat­ing SAP to SAP, which has to have a dif­fer­ent qual­i­ty than inte­grat­ing third-par­ty prod­ucts. We also have strate­gic part­ner­ships with com­pa­nies like Siemens, in the prod­uct life­cy­cle man­age­ment (PLM) space, where we have SAP Team­cen­ter by Siemens and inte­grate that almost like an SAP prod­uct. Of course, every cus­tomer also has com­pet­i­tive prod­ucts. No ques­tion. We have to be open, but we don’t active­ly build adapters to inte­grate to those solu­tions. We offer APIs, and the cus­tomer can con­nect those sys­tems into an SAP back­end or landscape. 

I believe, still, one of our key dif­fer­en­tia­tors is that SAP to SAP should always work the best. It should be the most seam­less for the cus­tomer, while stay­ing open to con­nect any oth­er solu­tion. But there has to be a dif­fer­ence in qual­i­ty. We don’t pro­vide map­pings into com­pet­i­tive solu­tions, we would­n’t work with a com­peti­tor to align data mod­els, and so on. We only do that inter­nal­ly and with our strate­gic partners. 

If you think about how this evolves in the cloud, we see more cus­tomers look­ing to only pay for what they use, so to speak. They always ask us to be more trans­par­ent and more mod­u­lar. If you think that through, the­o­ret­i­cal­ly, cus­tomers could almost assem­ble soft­ware them­selves, out of a cat­a­log of cloud ser­vices. With core finance, cus­tomers could con­fig­ure it in an end-to-end process, and we would only deploy those kinds of solu­tions to them, as well as the ser­vices need­ed to assem­ble a solu­tion that cov­ers such a process. 

For that to work, those solu­tions need to be har­mo­nized, tech­ni­cal­ly; they have to seam­less­ly inte­grate. They have to have the same pro­vi­sion­ing mech­a­nisms, the same oper­at­ing and sup­port mod­els underneath. 

That’s why we’re har­mo­niz­ing our port­fo­lio to offer that tech­ni­cal flex­i­bil­i­ty, which will also offer us com­mer­cial flex­i­bil­i­ty. This is crit­i­cal in the SaaS world, where we have full con­trol of cloud ser­vices, and why we’re expend­ing a lot of R&D on inte­gra­tion top­ics. At SAP, when we devel­op new capa­bil­i­ties, we’re devel­op­ing a lot of them on the SAP Busi­ness Tech­nol­o­gy Plat­form, in a way that’s an inte­gral part of the S/4HANA Cloud pack­age. We see ben­e­fits to being cloud-native. And we’ll be able to offer that flex­i­bil­i­ty to the customer. 

For pro­cure­ment in S/4HANA Cloud, pub­lic edi­tion, we’re build­ing the buy­ing 360 capa­bil­i­ty, a shop­ping cart for pur­chase req­ui­si­tions. This will come pre-inte­grat­ed, as part of S/4HANA Cloud, pub­lic edi­tion, and it feels like part of the over­all solu­tion. But it can also be bought by a cus­tomer who only buys SAP Ari­ba Buy­ing. This helps clean out the port­fo­lio and get rid of redun­dan­cies. Those redun­dan­cies always caused ques­tions for our customers.

Now, a cus­tomer can start by imple­ment­ing a pro­cure­ment solu­tion and, lat­er, if they want to imple­ment a S/4HANA Cloud solu­tion, the pro­cure­ment mod­ule would be iden­ti­cal. There’s no need to re-imple­ment. It will just fit into the broad­er ERP sto­ry. This is the vision we’re work­ing toward, in all areas. 

Q: Tech­nol­o­gy is fac­ing tal­ent short­ages, and our mem­bers tell us that mas­ter­ing tech­ni­cal migra­tions, such as those required in the move from ECC to S/4HANA, is a top pri­or­i­ty. How does SAP pro­vide cus­tomers with the exper­tise they need to nav­i­gate cloud ERP? 

A: There are mul­ti­ple angles to that. First­ly, we help with what we call prod­uct lead growth, espe­cial­ly in the pub­lic cloud. We’re build­ing capa­bil­i­ty into the prod­uct that prompts cus­tomers and end users toward tools they can use. In addi­tion, we mon­i­tor the usage behav­ior to see what the cus­tomer is using ver­sus what they are enti­tled to use, and we can active­ly noti­fy them about what they’ve sub­scribed to that would add val­ue. Addi­tion­al­ly, we should dis­cuss lever­ag­ing arti­fi­cial intel­li­gence. Now, with hype around gen­er­a­tive AI, we are obvi­ous­ly look­ing into dig­i­tal assis­tant tools that will rev­o­lu­tion­ize the user experience. 

At the end of the day, AI could help to accom­plish the vision we’ve been talk­ing about for years: that cus­tomers can talk in busi­ness lan­guage about tech­nol­o­gy prob­lems they need to solve — cre­at­ing pur­chase orders, for exam­ple — and the intel­li­gent dig­i­tal assis­tant will then take over. All the cus­tomers would have to do is add any addi­tion­al miss­ing data. The cus­tomer wouldn’t need to under­stand the plumbing. 

The com­plex­i­ty of the process has­n’t changed; the plumb­ing is still there. That’s always been a strength of ours, that we can actu­al­ly sup­port this com­plex­i­ty. But we need to shield it from the end user. I believe gen­er­a­tive AI will play a huge role here. There’s a big push around AI and gen­er­a­tive AI at SAP, on how can we help cus­tomers more eas­i­ly accom­plish what they need to accom­plish — to help them lever­age the full pow­er of the system.

Q: Out­side of mak­ing sup­port with­in S/4HANA more respon­sive, what oth­er use cas­es do you envi­sion for AI with­in S/4HANA?

A: The most obvi­ous use cas­es are those that help cus­tomers auto­mate process­es, get addi­tion­al insights, improve the user expe­ri­ence, and so on. Oth­er aspects that we’re active­ly look­ing into are ways to improve imple­men­ta­tion time. At the end of the day, a con­fig­u­ra­tion in the sys­tem is noth­ing but answer­ing busi­ness ques­tions, right? It should be pos­si­ble to use AI to help auto­mate con­fig­u­ra­tion, which could bring imple­men­ta­tion costs down. 

From an oper­a­tional per­spec­tive, if you think about mon­i­tor­ing sys­tems, site reli­a­bil­i­ty, and pre­ven­ta­tive ways to avoid out­ages, AI can be tremen­dous­ly help­ful. Inter­nal­ly, we are also look­ing into how we can lever­age tool­ing that helps us devel­op soft­ware, and some of this tool­ing could be made avail­able to cus­tomers and part­ners, because exten­si­bil­i­ty is always going to be a major com­po­nent of ERP. 

In addi­tion to no-code, low-code will get anoth­er boost through gen­er­a­tive AI, let­ting cus­tomers pro­duce pro­to­cols and extend solu­tions with­out being pro­gram­ming experts. That may be lit­tle fur­ther out, but these are all things we’re look­ing into from a devel­op­ment per­spec­tive, and we have start­ed proof of con­cepts (POCs) for.