SAP HANA Effect Episode 2...

HANA Effect Episode 2 – Varian’s Big Bet on ERP 1

SAP HANA EFFECT Title: Episode 2 - Varian's Big Bet on ERP (Duration: 25:34) Publish Date: February 5, 2015 Description: Naga Nallaiah from Varian Medical Systems joins us to talk about their big bet on SAP ERP on SAP HANA. Listen how Varian went through a huge database migration to get the speed and power of SAP HANA for their mission-critical SAP ERP system—for their very first SAP HANA project! THIS IS A RUSH TRANSCRIPT. THIS COPY MAY NOT BE IN ITS FINAL FORM AND MAY BE UPDATED. JEFF: Welcome to The HANA Effect. I’m your host, Jeff

Word, from SAP. Each week we bring listeners the

real stories of how companies are taking advantage

of real-time computing to transform their

organizations and let them share the lessons they’ve

learned along their journey. I’m here with Naga

Nallaiah. He’s the Basis Lead and Architect for the

SAP team at Varian. Welcome.

NAGA: Thank you, Jeff. Good to be here.

JEFF: Varian is a wonderful SAP customer. You’ve been a

customer for years. You guys have a great use case,

but, first, why don’t you tell everybody a little bit

about Varian and what you guys do.


NAGA: We, at Varian, we make radiology/oncology machines used

globally and today, more than 250,000 people are treated

by our machines.

JEFF: So you guys make the cancer diagnostic and

treatment machines that everybody hopes they

won’t ever need but are really, really glad to have

when they need them, right?

NAGA: Yes, exactly.

JEFF: Well, like I said, you’re a wonderful SAP customer.

But we’re going to talk about something a little

different. One of the use cases that is getting very,

very popular now – Suite On HANA. Basically, taking

the SAP business suite, ERP, the core granddaddy of

SAP applications and running it entirely, 100%, On

HANA. That’s a big deal. What kind of drove you

guys to consider that? That was your first HANA

project, right?

NAGA: Yes. Yes. That is our first On HANA project. So, if you look

at the business case for HANA, right, recently there were

other major research forms conducted globally most, more

than thousand CAUs, “what is the biggest challenge you

guys are facing?” And most of the people say that it’s and

performance and usabilities, right? We are not exception,

we are also getting the same issues. And one of the major

challenges we face is performance. So, we are not a


transaction company. We are not a high volume

transaction company. We are high value transaction

company because in the one mission you have a value

more than million dollar. We are not like a Hertz or some

small retailer. They have a high volume sales transaction.

But, we are a SAP customer very long time, so we are

using SAP right from 2.08. So back in 2006, our company

started reimplementation of our ECC. Basically, become

liquid migrate instead of upgrading from 4.60 to ECC, we

did a complete reimplementation to accommodate the new

business demand and new processes. So, it brings lot of

new feature and cool things but the same time it brings a

lot of challenges. So, especially, for backlog reporting and

sales and revenue forecasting and financial closing. And

while it measures based on how much backlog we have,

not how much revenue we make in these quarters. So

that’s for our business is a backlog reporting is very

critical, so all high level people and C-level people always

look at how much backlog we have. So that’s one of the

reports; always cause a lot of performance issues. Some of

the time it runs more than six hours, eight hours, and the

traditional database. We did all our efforts so we have

upgrade from a hardware from power 5 to power 7. We

hired SAP consultant, fine-tuned the program. It did help

for some level, but it’s not a help the level we expected.

JEFF: It was still running on a regular old disk-based

database, right?


NAGA: Yes. Still running on old disk-based and regular audit

limitations, right? Then what happened is that time, SAP

released SAP HANA and we heard a lot of great stories

over SAP HANA. Reports are running from 20 hours to less

than 5 minutes, 6 minutes, and since we are very close

customer of, very, very close with the SAP, and our

management, IT management talking to SAP and how you

guys can help us and so the SAP came to us, okay, we can

do, when we started this thing, SAP released only for BW

On HANA. So SAP proposed to us, why don’t you guys do a

sidecar approach?

JEFF: So the sidecar approach, for the listeners, is when

you take a small HANA box, stick it next to your

production regular database underneath SAP, and

offload some of the tables and reporting workloads

to the HANA system, while still maintaining your

regular architecture there, right?

NAGA: Yep. Yep. So a sidecar basically you put a small HANA box

next to an Easy Suite ECC system and you only do running

critical report there.

JEFF: It’s a pretty low risk way to do it, right?

NAGA: Yes. Yes.

JEFF: Low cost, low risk, pretty fast. Yeah.


NAGA: So we started talking to SAP, and we worked with the SAP

labs and HANA team. So, what we did was we exported all

critical tables, because we don’t own any HANA appliance

in-house, so we work with SAP and SAP agreed to, okay,

why don’t you guys give the data. So we import in our lab

and we do our proof of concept, indelible code, and show

you how fast HANA is.

JEFF: So SAP basically ran the pilot for you guys to test out

how fast this would be as a sidecar, right?

NAGA: Yes.

JEFF: Really good collaboration.

NAGA: Yes.

JEFF: Like I said, you’re a wonderful customer. So what

was the result of the testing?

NAGA: So we gave the export of our data. SAP imported the data

in HANA lab; they did a great job and they demoed us the

report, which used to run more than four hours, ran in

HANA is four minutes.

JEFF: Okay, so from four hours to four minutes, and this is

just as a sidecar, just a small piece of the database?


NAGA: Yes, small piece of database, sidecar approach, which

really caught our eyes.

JEFF: So what was the reaction? What did people say

when they saw that?

NAGA: It’s, wow. This much fast? Okay, let’s look at it. So we

started, we saw the result, we tell the business, yes, yeah,

we are working on it. There’s a lot of new cool technology

from SAP. We’ll do it. So, the business case for these

things; number one is speed. As I mentioned before, we

see a lot of ECC transactions running slow. Then we saw

the proof of concept. Even for one reporting we saw

tremendous performance improvements. And third one is

we saw the potential to offset article database license cost.

JEFF: Let’s talk about that. We don’t like to talk about that

too much here, but that’s a significant aspect to the

business case is you have a database today,

underneath your SAP system, if it’s Oracle it’s the

most expensive option you can get. And so you guys

saw replacing that with HANA and the license

implications of that as a really significant driver of

business value. So for the listeners out there,

basically by eliminating Oracle as the database you

eliminate all of these other ancillary charges that are

driven by the fact that you had Oracle. So by

eliminating that and going with HANA, not only do

you get all the benefits of HANA, but you eliminate a


lot of these clauses that end up triggering more

charges even that you don’t need sometimes.

NAGA: Yep. So, that’s where our management work with us, SAP

gives the good licenses, basically good pricing. So that our

business gets three things: speed and offsetting our Oracle

license cost and then we saw the great performance

improvement in proof of concept.

JEFF: Yeah. So, the speed drives the performance, but as

an extra benefit, it saved you a whole lot of money.

NAGA: Yes.

JEFF: That’s pretty awesome. So how did you guys go from

a small side car test and seeing really massive

improvements for a sliver, a tiny bit, to saying, “You

know, let’s just stick the whole bloody thing on

there, on HANA?”

NAGA: So, we completed our POC. We saw the benefit of the

HANA. Then our management, they said, “Why we need to

go over to only one sidecar, we move completely?”

JEFF: Just the whole enchilada.

NAGA: We’ll get all the benefits of HANA.


JEFF: That’s a big thing. And for listeners that don’t

understand, that’s like having heart, lung, and

kidney surgery on the same day—to just rip out one

database underneath your live, running, very well-

supported ERP system and put it on HANA. I like to

tell people there’s a lot of perceived risk to that, but

the actual risk is actually fairly low. How did you

guys evaluate that risk, especially discrepancy and

risk between a small sidecar versus the whole

bloody thing on HANA? How did you guys think

about that?

NAGA: So, if you look at Varian, always, the cutting edge

technologies, even though it gives a lot of challenges and

it comes with a lot of risk, also it’s always up to date, state

of art technologies so that we can build or grow our

applications.

JEFF: So your corporate culture is, is fairly high risk to

begin with, but you guys must get some really big

benefits of being cutting edge on everything.

NAG: Yep. So even though we see some risk but, is this is a

calculated risk.

JEFF: So the big bosses were convinced. They said, “Let’s

just go for the whole thing, wall to wall.” How did

things proceed from that point, where you said,


“Okay, this is now supported for the suite, let’s do

it?”

NAGA: So, let’s do it and we check with a few customers. As you

mentioned, when we started our project. Only one

customer went live on suite on HANA.

JEFF: So you really were one of the bleeding edge on this

thing.

NAGA: Yes. Yes.

JEFF: So you could only talk to a couple of other people

that had done it. Obviously, you put a massive

amount of trust in SAP and I would imagine we put

in a whole lot of resources to make sure you’re

successful, right?

NAGA: Yes.

JEFF: So talk about the project for a little bit. People like

to understand, especially doing a big migration, how

big was your database under ERP to begin with?

NAGA: So, our source database is 1.8 terabyte. So, if you look at

the challenge and everything, when we started our project,

and we have a lot of challenges. It’s from two sides. One is

the selection of hardware. Another one is selecting the

partner for migration. Sizing the hardware is the biggest

challenge; initial challenge we faced because even the SAP


teams, there are only limited number of people who know

all the things on the suite on HANA because that just

released. So, only the development team, the co-

innovation teams know how to do it. They already did an

inside SAP. So we ran some couple of reports. So when we

run the sizing reports, it gave us an idea of our target

database comes closer to 700 gig.

JEFF: Okay, so about a little over half reduction.

NAGA: Half reduction. And usually our hardware refresh cycle is

every three years. And before buying hardware, then we

did consider whether we’d go with on cloud or on premise.

And even when we look at the on cloud, there is very

limited people out providing the service.

JEFF: Yeah, this was, this was a while back. So, now

everybody’s providing on HANA in the cloud.

NAGA: Yeah. So then we decided, okay, let’s stick with on

premise. We later look at on cloud. So, we stick with on

premise. Then we alerted the, our hardware partners.

We’re a traditionally, IBM shop, which we run on IBM AIX

and Power Platform. And that’s why it’s a cultural shift

because HANA is available only on Intel platform, not on

the Power, RISCs processer thing. So it took some time to

shift from UNIX platform to Intel platform. Our selection

process like that, we invited for RFQ and for all the people.

Then we invited four hardware partners and asked them to


present and based on our target database size, which just

comes to 700 gig, and our monthly database growth is 30

to 45 gig, so in the target, some around 15 to 20 gig in a

month. So, as I mentioned before, our refresh cycle is

every three years, so we need to plan for next three years.

So, right now, 700 gig, even grown 20 gig a month. So in

a year, we’ll grow 200 gig. So, we hit easily 900 gig. So,

as you know, as HANA go by the T-set size. It’s 64 gig,

128, 256, 512, 1 terabyte.

JEFF: Yeah.

NAGA: Then it jump to 2 terabytes. There’s no in-between. So, if

you buy 1 terabyte box, if our database grow 200 gig in a

year, then we are close to 1 terabyte within a year. There’s

another challenge is scale out is not supported in suite on

HANA. So, we would completely replace the box for the

new one. So, then we decided to go with the 2 terabyte

box.

JEFF: And I might add, for the listeners, most of the things

he’s saying have changed now, since this was first

released. So, we do have scalability. We do have a

lot of really easy cloud-based pay-as-you-grow type

of things. But you guys being early adopters, you

faced some of the unfortunate limitations when we

first released things so.


NAGA: Yeah. So since we are long-time listeners very good

listeners to IBM so we went with IBM.

JEFF: Talk us through the process of that migration.

People really want to know what’s really involved

with the technical project aspects of moving over to

a new database underneath a live, running, mission-

critical, can’t fail or you can’t report to Wall Street

company system.

NAGA: Glad you asked that because I discussed only on the

hardware selections. So, we did another similar selection

for migration partner. So, what we did was, we did a POC.

We upgraded our queue environment, which is three to

four month older than production database. We upgraded

our queue environment. We exported a copy of the data

and cleared all the migration partner. Okay, you go ahead

and import a newer lab, see our code and you come back

to us and give the proposal.

JEFF: All right. So let me see if I got this straight. You guys

handed out a copy of your system to a bunch of

systems implementers that had a HANA experience

and said, “Prove to us and show us what the end

result’s going to look like when you’re done with the

project. So, do a test for us and show us what the

end results going to be before we decide who we’re

going to have do the real work.”


NAGA: Exactly. So they came back to us and presented, okay.

Based on the data you gave us, okay, these are the

problems you need to modify. We expected migration

hours. This many hours you need for down time. So they

purposely detailed a project plan.

JEFF: Yeah. Each one of them came to you and said,

“Based on your real live system, if we move this over

to HANA, here’s the effort involved, here’s the cost

involved, here’s what the project will entail.” That’s

a pretty smart way to do it actually.

NAGA: Yes. Based on that, we selected our partners at KPIT.

They’re our migration partner.

JEFF: So tell us about, in general, what you can say, how

big was the team and how long did this project take?

NAGA: Total run time of the project is eight months. We started a

project in October, we went live on May 10th, so is close to

7 to 8 months.

JEFF: How many people kind of involved? How many

resources on a full-time basis?

NAGA: So, the full-time basis is 35 resources from IT, which

included our application, infrastructure, and security. And

25 people from business, which is a part-time for testing

and other things.


JEFF: All right. And how many consultants did you have to

bring in?

NAGA: So consultant is 10 people.

JEFF: So, 10 people. That’s actually a pretty small team.

NAGA: Yes.

JEFF: Let’s talk about this. People always want to know

what the downside of this is, so what went wrong?

What problems did you guys have during this project

that had to be resolved?

NAGA: Number one is make sure your ABAP code is HANA ready.

So we call it “HANAtized.” So, that’s a biggest effort we

put.

JEFF: What does that involve? Explain that to people.

NAGA: So before you go into HANA. So, SAP provides the code

inspector with the HANA ready, so what we did was plus

our partner also came up with their IP tool.

JEFF: So they scanned the code and said, “Here’s the

pieces that are going to need to be HANAfied or

HANAtized.” What does that mean? What did you

actually have to do as part of your?


NAGA: So, we work with our partner and partner had their own IP

tool and code inspector. This came to all the ABAP code

and they listed, okay, these are the programs affected in

HANA, especially for implicit sort on some of the select star

programs. So, they say these are the codes you need to

modify. So, before even going to HANA, our partner with

our development team, they work extensively and

modified all the programs to HANA ready.

JEFF: So, what does that mean when you say modified?

NAGA: Make the code adjustments, right.

JEFF: Okay, so adjustments?

NAGA: Adjustments. If the code is not supported in HANA,

especially implicit sort, which is not supported in HANA at

all. So, they modified the code, which is supported by SAP

HANA.

JEFF: And so, basically it’s a process where you go in,

especially most of this is customized code, where

you go in and say, in HANA we’re going to need to

make this a little bit cleaner. We’re going to need to

make this is a little bit more efficient to take

advantage of some of the things in HANA versus the

way we did it in the old database, right? How would

you describe the effort? Was it a real big pain in the

neck or just kind of, you know?


NAGA: I don’t think it’s a big pain in the neck but it’s manageable.

This is manageable.

JEFF: Okay. When you finally got this done, were there any

surprising things that the users said? What was their

reaction to this new suite on HANA system?

NAGA: We got a lot of good positive from different sections of the

companies. And if we talk some of the people say, okay,

the report used to run in more than 10 minutes is finished

in second.

JEFF: So from 10 minutes to 1 second.

NAGA: Yeah.

JEFF: So the speed, they noticed the speed. But what else

did they say about it? Did it help change the way

they do things because now they have this speed?

NAGA: So now they have speed. That’s what I’m going to talk

about it. This is only phase one. We just took our suite

from Oracle database to HANA. Phase two, what we’re

planning is, we are moving some of the critical report to

HANA layer from above layer.

JEFF: So now you’re really going to start to talk advantage

of the horsepower of HANA.


NAGA: Yes, yes.

JEFF: So, step one was just get it running on suite.

NAGA: Yep.

JEFF: We get a big speed boost –

NAGA: Yep.

JEFF: In a lot of these things and then step two is, now

we’re really going to turbo charge it and take

advantage of the HANA underneath the hood.

NAGA: So, if you look at this right? Our average response time

used to have 1.3 second; this came down to .62, .7. So,

we immediately see 50% improvement.

JEFF: So across the board, on average, everything was

twice as fast.

NAGA: Yes.

JEFF: But I’m sure there was a lot of things that, like you

said, go down from, eight hours down to couple of

minutes, right?


NAGA: Before we go on HANA, we did a benchmarking. So, what

we did was we selected our 61 golden transactions. We ran

the transactions, measured the response time in Oracle.

We see 41 transactions. This is running faster. Okay?

Multifold performance improvement.

JEFF: Like hundreds to thousands of times faster.

NAGA: Yes. The 11 transaction there is no visible difference. Was

running same as things.

JEFF: So those are things like create sales order, VA01,

simple commits, things like that, you wouldn’t

expect those to be much faster, anyway, right?

NAGA: But we did see the two transactions running longer than

our traditional database.

JEFF: Okay. And I imagine you’re going to tell us why.

NAGA: Yeah. Why? So, the part of the upgrade, we did an EHP

server upgrade, right? As a part of the whole migration,

we did upgrade and migrate because that is a mandatory

step for HANA migration. We are still working with SAP.

We are still not solved yet, so we’re still working with SAP

why these two transactions are running slow.

JEFF: So, it’s just one of those little ghosts in the machine

that you just gotta work your way through it and


figure it out. All right. So that’s, honestly, that’s a

great thing to share because the marketing from

SAP, and I’m guilty of this as well, we always talk

about all the benefits. But, especially in this podcast,

we want to make sure people understand there are

warts on this thing; it’s not perfect. But 41 out of 61

thousands of times better.

NAGA: Multifold. Yep.

JEFF: That changes the game pretty significantly, doesn’t

it? So, once you get to that point, how is that really

going to change the business though? I mean, what

are you guys expecting from a business process

improvement?

NAGA: So, as you mentioned, we have phase two, our ABAP team

is working, pushing down the code to HANA layer, making

it even faster. And there’s a lot of new projects already

lined up and we are working with the business and our

enterprise application groups and we make our application

people developing a mobile app and make people access

the application on the road or anywhere, wherever they

are.

JEFF: So now, because you have this power of HANA,

underneath your ERP, you’re actually able to expand

the coverage to more and more and more users to do


more things with the system then they were

previously.

NAGA: Yeah. So, as our IT director used to say, “Our journey’s

just started.”

JEFF: You guys have taken one big step on the journey,

but it was a massive leap. It was a moon shot

compared to a lot of people that take little baby

steps to start with. Because you guys did that,

because you did jump so far on your first step in the

journey towards kind of HANA across the board,

what kind of advice would you give to someone that

was considering suite on HANA?

NAGA: Some of the lessons learned, right? So, if you face any

performance problems or if you’re seeing something our

biggest issue is a suite ECC system, go for it. So, it’s just a

really good platform. I won’t only say the database; it’s a

good platform. Once you move to suite on HANA you can

exploit any number of things. So, one of the things I forgot

to mention is what our plan is. We are trying to use now

leverage HANA live for some of the critical applications like

MRP, revenue forecasting, reality working with the SAP for

a smart financial. So, these are things that make it easier

for us.


JEFF: It’s allowing you to liberate that data and export it

and to show it to more and more users to do more

and more things with it that you were kind of

inhibited from doing that in the past.

NAGA: Earlier, you cleared a lot of frustration with user

community, or this, something like that. So, but if you’re

running faster, it makes your adaptableness a high, high

user adoption. It makes user happy. So, it frees up the

user’s time, so what they can do is they can run the report

and they focus their effort on something else.

JEFF: Instead of going to get coffee or lunch, they

immediately get the answer and can keep working

right?

NAGA: Yep. Yup.

JEFF: That’s great. Like I said, you guys did something a

little bit more risky than most companies. How

would you advise other companies? Yes, go for it, it

works. But how do you advise them to kind of deal

with that risk? Because there is a perception of risk

when you take a live running system and just swap a

database underneath it. Huge benefits, but how do

you explain that risk to the business side of things?

NAGA: So, yes, definitely there’s somewhat of a risk involved. So

my recommendation is do proof of concept.


JEFF: Proof of concept? Yeah.

NAGA: Okay. Work with your partner or work with SAP and do a

proof of concept of your queue system or your test system

or training system and run your transactions and see the

difference.

JEFF: Do the before/after comparisons.

NAGA: Do before/after comparisons. And present with your

business, they’ll happily accept it.

JEFF: And so when you show that to the business and say,

“Okay, here’s what we are realistically going to see

when we’re done with this thing. No pie in the sky

estimates. This is the real deal, exactly what we

expect to have at the end of this. And here’s the risk

that’s associated with it.” You think that that’s a no-

brainer decision for the business, right?

NAGA: Yes. Exactly.

JEFF: Awesome. Well, I would also recommend that with

everybody else. HANA is a little bit different. It’s a

little bit unique compared to what we’re used to. It’s

amazing in so many different ways. There are a few

small drawbacks to it that have to be worked

through, but I love the way that you guys have

approached this to say, “We’re going to test it out;


we’re going to do the before and after. We’re going

to pilot this thing. We’re going to get the right

resources to come in and help us do this, and here’s

the benefit we’re going to give to the business at the

end of it.” But, more importantly, that first step on

your journey has now given you guys the platform to

take all of these extra smaller steps in parallel,

right? It’s kind of snowballing, isn’t it?

NAGA: Yep, yep, exactly.

JEFF: Awesome. Well listen, Naga, this has been

phenomenal. I think our listeners have gotten a

huge amount of value out of this. I wanna first of all

thank you for sharing your story with us.

NAGA: Thanks for having me.

JEFF: It’s an absolute pleasure. We’re thrilled to be able to

share this type of early adopter success story and

share the kind of human aspect of what it’s like to

run one of these things.

For the listeners, if you guys want to get more

information about this, please go to saphana.com.

You can find lots of information on that. Specifically,

if you’re interested in suite on HANA, or ERP on

HANA, go to suiteonhana.com. There is that code

review. There is a transaction monitor. You can ship


that up to SAP, and they can run that analysis to tell

you and pinpoint the transactions in your system

that are going to benefit the most. It’s a great step.

It doesn’t cost anything. It’s real easy to do. I think

it’s transaction ST0N3, if you want to run it, and

suiteonhana.com, and they’ll help you actually make

that business case and estimate what that real world

impact is going to be.

For everybody else to get more information and get

more stories like this, please subscribe to us on

iTunes and SoundCloud, and you can also follow us

for updates at our twitter handle, which is

@hanaeffect.

Again, want to thank you, Naga. This has been great.

Thank you to Varian for being such a great longtime

customer and trusting SAP. We really appreciate that

and we’re thrilled to be able to share your success

story with everyone out there. So, with that we’ll

close this episode and want to say thanks for

listening and “Tschus”.[END]

Date post:	06-Sep-2019
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

SAP HANA Effect Episode 2...

Documents