Dave Essex: I'm David Essex industry editor at
search SAP. Today I'm discussing S/4HANA migration
with Jesse Rothermel, SAP transformation lead
and partner in the technology consulting practice
at EY. For more information on S/4HANA
implementation, click the link above or in the
description below. How do you folks at EY try to
characterize or explain the different flavors of
S/4HANA? Kind of leaving a site on premises
S/4HANA, which is a big thing, too? How do you
like? What are the key terms that you use to help
them sort of understand the difference? Because I
do think there are there is some confusion.
Jesse Rothermel: Oh, I Yeah. I mean, look, I think
we've with almost every client, we've had, you
know, we all had to either have a conversation or
joint conversation with SAP to try to clarify some
of the principles. And I think it's not so much
around SAP marketing strategy, where the confusion
comes, it's because of a lot of the experience and
expectations of legacy SAP customers, and not
understanding what it means because they had, you
know, for a long time, everyone said, you know,
what, in the SAP space, the move was cloud cloud
cloud meant, hey, put your infrastructure on
hyperscalers. Right, that was the move, right? It
was still an on premise solution in terms of it
was years and years only. And you still hosted it,
but it was server wise out there on the cloud,
right? The processing power. And I think that
became the mantra and a lot of people's heads. And
then people started, our customers started seeing
real cloud solutions out there, like the you know,
the workdays and the ServiceNow calls, and you
know, that that kind of a mindset and said, is
that what SAP means by cloud? Is that the same
thing? Or is it not the same thing. And SAP does
have truly comparable, full public cloud
solutions, like we talked about, but for the most
part, the clients that we're talking to are
looking for that middle ground. So they say, What
does private cloud really mean? The way I
explained it, in the simplest terms, is you you
still own your instance, meaning it's yours, it's
only got your data in it, it is a single database
with your data as a client, there's no tables that
are shared with you and somebody else. But that
instance, is totally built and maintained by
somebody else. That's the private cloud
perspective of it. So you know, they're the ones
who deal with the hyper scalar, SAP, right? They
own that relationship, they build your actual
system for you, and you're just using it, you're
using it to store your data and run your
transactions. I think that's the simplest way to
put it. And they say, well, what's the downside?
Why would I ever want to go that route, as opposed
to the traditional on prem or pick my own hyper
scalar option? And it's really the, it's the
maintenance of the solution and the introduction
of new capabilities, right, which they weren't
able to do before. By keeping to some kind of a
standard and hosting that all centrally, they've
got the ability to, you know, actually provide new
capabilities much faster than they ever did before
to the software package.
Dave Essex: How do you walk them through that, in
terms of figuring out that maybe they need to go
for the on premises version, they can't go for any
kind of cloud version, or especially the multi
tenant SAS version?
Jesse Rothermel: Yeah, I mean, it's the there's
not an easy way to answer it, David. And the
reason why I say that is because the answers a
little bit different based on different modules of
SAP and functionality, right. I think that if
you're a purely or primarily finance focused
customer, there isn't a lot of difference anymore,
right? I think when you get down to manufacturing
and integration with shop for shop floor
solutions, that's where I think there's still some
maturity to be had in the on prem versus the cloud
version, which is, you know why you see some of
the multi tier decentralized solutions that exist
today around AWS and some of the other like,
closer to the closer to the warehouse or shop
floor level solutions, staying on some level they
have of their old on prem and then having a cloud
version in the middle. Outside of that, I think
that we typically will try to scope the client
pretty quickly and understand which modules they
may use, and then do a level of on prem versus,
you know, rise or private cloud comparison just
because it gets so specific or what functions
they're using.