HP Shows Extent and Benefits From Successful Application Consolidation With Own Global Project

HP Shows Extent and Benefits From Successful Application
Consolidation With Own Massive Global Supply Chain Project
Transcript of a BriefingsDirect podcast on how Hewlett-Packard tackled an internal multi-year
effort to streamline supply chain efficiencies and effectiveness.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor:
Hewlett-Packard.

Access more information on Application Consolidation.
Read the full-length case study on HP's Application Consolidation.
Learn more about the Application Transformation Experience Workshop.

Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you’re
listening to BriefingsDirect.

Today, we present a sponsored podcast discussion on learning about best practices
and execution accelerators for large, often global, application-consolidation
projects. We'll take a look a telling case-study, a massive multi-year application-
consolidation project at Hewlett-Packard (HP) that involved hundreds of
applications and thousands of people around the world.

We'll look first at why the Global Part Supply Chain project at HP was undertaken,
but just as importantly, why the project needed to be invigorated after it bogged down by sheer
scale and complexity. The project quickly became hugely successful, however, and we'll learn
how and why.

These are by no means trivial projects, and often involve every aspect of IT, as well as require a
backing of the business leadership and the users to be done well. The goal through these complex
undertakings is to radically improve how applications are developed, managed, and governed
across their lifecycle to better support dynamic business environments. The stakes, therefore, are
potentially huge for both IT and the business.

We're here with an executive from HP to look at proper planning and execution for massive
application-consolidation projects by specifically looking at an HP project itself.

Please join me now in welcoming Paul Evans, Worldwide Marketing Lead on Applications
Transformation at HP. Welcome to the show, Paul.

Paul Evans: Hi Dana.

Gardner: Tell me why applications are so numerous in many of these extended business
processes, about the whole notion of part supply chains, and why that's such a big deal for HP.

Evans: As you can imagine, HP is an extremely large organization. It makes
products, as well as sells services, etc. In terms of product, just imagine your
average PC, or your average server and think of the number of components that
are made up inside that device. It runs into hundreds of thousands, whether it's
memory chips, disk drives, screens, keyboards, or whatever.

For a company like HP, in the event that someone needs a spare part for whatever
reason, they don't expect to wait a signiﬁcant period of time for it to turn up. They want it
delivered 24 hours later by whatever means that suits them best.

So, it's essential for us to have that global supply chain of spare parts tailored towards the ones
that we believe we need more rather than less and that we can supply those parts quickly and
easily and, at the same time, cost effectively. That's important for any organization that is dealing
in physical components or in the provision of a service. You want to maintain customer
satisfaction or increased customer satisfaction.

Customer centric

For us, it was essential that a massive global supply chain organization was
extremely customer centric, but at the same time, very cost effective. We were
doing our utmost to reduce costs, increase the agility of the applications to service
the customers, and fuel growth, as our organization and our business grows. This
organization has got to respond to that.

So, the primary reason here was that this is a large organization, dealing with multiple
components with pressures on it both from the business and the IT side.

Gardner: With HP of course, there have been mergers and acquisitions over the years. Suppliers
come and go. Product lines may start small, but then ramp up rapidly. So, we're talking about
many different organizations and many different applications that had to be brought into this now
lean, or hopefully lean, process.

Evans: One of the primary reasons we had to do this is that HP has been an amalgam of
companies like Hewlett-Packard, originally, Compaq, Tandem, DEC. All of these organizations
had their own bills of materials, their own skills, and basically this thing has just grown like
Topsy.

What we were trying to do here was to say that we just couldn't continue to treat these systems as
un-integrated. We had a lot of legacy environments that were expensive to run, a lot of
redundancy, and a lot of overlap.

The goal here clearly was to produce one integrated solution that treated the HP customer as an
individual and in the back end consolidated the applications, the ones we really needed to move
forward. And also, a goal was to retire those applications that were no longer necessary to
support the business process.

The whole notion of this coming about through mergers and acquisitions is very common in the
marketplace. It's not unique just to HP. The question of whether you just live with everybody’s
apps or you begin to consolidate and rationalize is a major question that customers are asking
themselves.

Gardner: If you look at this problem from the perspective of IT, of course, you have multiple
platforms, legacy applications, and a mixture of different architectures and hardware. And, they
have their own set of requirements that they're focused on.

But, if you look at it through the lens of the user, many users are wed to that application, even if
it's an older interface. They don't really care about what's underlying in terms of infrastructure.
They just want to be able to get their work done without being disrupted.

What we have are perhaps multiple agendas that need to be aligned, and politics and persuasion
come into play. Tell me what may have gone awry for a period of time with this project and how
some of these other issues about multiple agendas can be managed?

Siloed thinking

Evans: Well, this is a challenge in any situation, and this has been true not only with this
particular supply chain project with HP, but for all of us. The rationalization that has taken place
inside HP around its IT organization and technology is that because we are human beings, most
people think in a very siloed way.

They see their suite of applications supporting their business. They like them. They love them.
They’ve grown up with them, and they want to continue using them. Their view is, "Mine is
perfect to suit my business requirement. Why would I need anything else?"

That's okay, when you're very close to the coal face. You can always make decisions and always
deem to the fact that the applications you use are strategic -- an interesting word that a lot of
people use. But, as you zoom out from that environment and begin to get a more holistic view of
the silos, you can begin to see that the duplication and replication is grossly inefﬁcient and
grossly expensive.

We've seen that in HP. We saw it in this particular supply chain situation. We were looking at
three totally different solutions in three different companies: Compaq, HP, and DEC. We were
looking over 300 applications. Clearly, that was not the way forward, because it wasn't only just
a cost-reduction exercise.

If you're looking into the future and saying you need a much faster, speedier, agile situation to be
working with, you can't do that in the whole legacy environment. It's just something that's tying
you down. That problem is not unique to HP. I deﬁnitely understand that.

Gardner: So, when you decided to look into your part supply chain activities, I understand there
were hundreds of applications involved, multiple sites, geographies, and countries. Was this
something that was driven by the business? Was it driven by IT? Both? How did the impetus for
this begin?

Evans: Well, from the IT side, there was clearly a view from the top down that said living with
300 applications in the supply-chain world was unacceptable. But also from the business side,
the real push was that we had to improve certain metrics. We have this metric called Spend-to-
Revenue ratio which is, in fact, what are we spending for parts as opposed to what we are getting
in terms of revenue? We were clearly below par in those spaces.

So, we had some business imperatives that were driving this project that said we needed to save
money, we needed to be able to deliver faster, and we needed to be able to do it more reliably. If
we tell a customer they're going to get the part within 24 hours, we deliver in 24 hours -- not 36
or 48, because we weren't quite sure where it was. We had to maintain the business acumen.

Complexity kicks in

At the same time, when viewed from a technological angle, we were running old, expensive
applications. As always, when you're running far too many applications, the complexity kicks in.
How does that all work? This volume of applications -- or applications bloat, as some people call
it -- is a real impediment to agility. You just can't move forward quickly with 300 apps in an
environment where you know you're probably looking at a tenth of that. It’s a bit like saying,
"How could I run fast if I have 300 feet?" You can't. You can do it with two, but you couldn't do
it with 300.

So, our whole goal here was to align business and IT in terms of a technological response to a
business drive.

Gardner: From the business side, I suppose they're very concerned about business process,
primarily, the applications. They're probably not concerned about some of the more strategic,
long-term IT implications, those being how do we better manage applications as a life-cycle,
rather than just ﬁxing the problem of getting 300 applications down to 30.

At that point, it gives them the opportunity to come and say, "Let's look at this methodologically.
How do we now put in the governance, put in the processes where we can create the
applications, manage them, but also sunset them appropriately?"

So how does that factor in, that notion of making this a mature process and no longer a cherry-
picking, complex stew of different styles?

Evans: The area you just addressed is probably one of the primary ones. When we submitted the
project, we were basically driving it by committee. Individual business units were saying, "I need
applications x, y, z." Another group says, "Actually, we need a, b, c." There was virtually no
ability to get to any consensus. The goal here is to go from 300 apps to 30 apps. We’re never
going to do it, if you could all self-justify the applications you need.

What we did was discard the committee approach. We took the approach, basically led by one
person from the business side, who had supply chain experience, and one from the IT side who
had supply chain experience, but both had their specialist areas. These two people were the
drivers. The buck stopped with these people. They had to make the big decisions.

To support them, they had a sponsorship committee of senior executives, to which they could
always escalate, if there was a problem making a ﬁnal decision about what was necessary.

Randy Mott, the CIO, has the direct support of Mark Hurd, the CEO. In my experience, that's
absolutely essential in any project a customer undertakes. They have to have executive
sponsorship from the top. If you don't, any time you get to an impasse, there's no way out. It just
distills into argument and bickering You need somebody who's going to make the decision and
says, "We're going this way and we're not going that way."

Getting on track

So for us, setting up this whole governance team of two people to make the hard decisions, and
their being supported by a project management team who are there to go off and enact the
decisions that were made was the way we really began to move this project forward, get it on
track, get it on time, and get it in budget.

Gardner: I see. So the impasse, the bogging down of this process where it sort of went off the
rails in terms of an expected timeline, that's where it was bogged down by committee versus
committee. It's when you broke through that, almost at an organizational managerial level, that
you were able to accelerate. Is that right?

Evans: Absolutely. In my interaction with customers, I see this time-and-time again. We’ve
always said that the experience that HP has gained internally we would share with our customers.
We even have a regular customer event, where we share all our best practices and we are not
afraid to share the things that go wrong. In this instance, when we started by saying let's have a
big committee to help my decisions, it was the wrong approach. We were going nowhere. We had
to rationalize and say no.


Two respected individuals, one from the IT side and one from the business side, who were totally
aligned on what they were doing, shared the same vision in what they were trying to achieve. By
virtue of that, we could enforce through decisions, sometimes unpopular. People sometimes do
not understand why a particular application is going to get turned off in place of another. But,
those were the hard realities we had to take to get the cost down and get the efﬁciency and the
effective result.

Gardner: So, we're talking now about decision-making. We're talking about governance. We're
talking about the intersection of IT governance with political governance. This is something you
can't buy. You don't necessarily purchase a box that does this. This is a combination of
technology, professional services, methodology, standards, experience, and even, I would
imagine, a change in management among the leadership.

Tell me how HP internally focused across these multiple disciplines, not just product, not just
technology, and then how that relates to what you do with your customers now?

Evans: A lot of people would say it's just technological problem. You’ve got 300 apps running
on old platforms using old technology and you want to use the latest and greatest, the fastest, the
smartest, whatever. But, as we’ve discussed, at least 50-60 percent of the solution has nothing to
do with technology. It had all to do with making decisions, making the right decisions that would
lead us to the right outcome for the business.

We knew what we wanted to achieve. We knew that we had to be more agile. We had to get our
cost down. We had to optimize this whole spend-to-revenue ratio. As always with the supply
chain business, inventory had to go down. Going up is not a good plan, because you're paying for
parts that are sitting on the shelf.

Agile and sleek

One of the goals was to get the solution so agile and sleek that we didn't have to use air
transportation to get parts from A to B. We could use surface transportation. If we could put the
parts in the right place, where they needed to be to get to the right customer, rather having to use
air, which of course is very fast, but it’s very expensive compared to surface, we could also get a
dramatic reduction in the CO2 emission that we were putting out by virtue of that transportation.

There were lots of things here that had nothing to do with technology. They all had to do with
business beneﬁts and outcomes that we wanted to achieve, both internally to HP, like saving
money, but also to the customers in terms of delivery of a better service.

Some will call them peripheral, and some may call them fundamental, but things like using
different transportation techniques to cut CO2 we felt were pretty important.

What we've done as always with these experiences is translate them into how can we be smarter,
better, and more helpful to our customers in learning from these experiences. In the whole HP-

IT story, we have outpoured so many best practices and good ideas and bad ideas, which we're
quite happy to share with people.

Similarly, we'd like to think that those organizations that are out there with a supply chain
challenge could now look at this and say, "Maybe we could do the same thing." Deﬁnitely the
alignment between business and IT is probably one of the most paramount of facets. Let me do
with which platform, which network, which disk drive, or which operating system. You can have
a lot of fun with that. But, in this instance, a lot of the success was driven by setting up the right
governance and decision-making structure with the right sponsorship.

Gardner: Now, I'd like to look at some of the paybacks. As I understand it, you turned the
corner on this project back in 2006. At the time, you didn't realize that was "the good old days."
The agility and lean aspects of processes in a supply chain are great during growth, but they're
also extremely important, when there is a contraction.

So, is there an opportunity to look back and say, "Wow. We didn't know it at the time, but by
conducting this application consolidation with the proper governance, we were able to dial down
on our delivery of products and services when that was required, and now dial back up." That's
probably is something that is a lesson to be learned at the macroeconomic level, but can we apply
some metrics of success from your project? Any thoughts about what the paybacks were,
especially in a topsy turvy general economy?

Evans: In taking the more holistic view and talking to a lot of customers they would say,
"Maybe 18 months ago or two years ago, we knew that we had a legacy app problem. We knew
we were spending too much on the underpinning infrastructure, but we could sort of afford it.
Was it perfect? No. Was it a bit of a mess? Yes. Should we have really been focusing on the
legacy apps issue, thinking maybe the economy is never going to sustain what it was?" But, of
course, hindsight is a wonderful thing.

Smarter and better

Now, when I am talking to clients, I mean their comments are, "We need to be smarter. We need
to be better. We need to retain our customers, deliver better quality of service to our customers,
and we have to do it at a low cost." We've seen a massive change in the approach with the legacy
environment, whether that’s applications or infrastructure.

Over the last 12 months what people have realized that it is now time for those organizations that
want to remain competitive and innovative. Unfortunately, I still see a lot of companies that
believe that doing nothing is the thing to do and will just wait for the economy to rebound. I
don't believe it's going to rebound to the same place. It may come back and it may be stronger,
but it may end up on a different place.

The organizations that are not waiting for that, but are trying to be innovative, competitive, move
away from the competition, and give themselves some breathing space are the ones who are
going to sustain themselves.

Within HP, we were not in great shape a few years back in terms of our IT spend. It was way too
high, and we openly admit that. We had to take some fairly drastic actions, and it is probably
well-known and documented. We went from about 6,000 apps went down to about 1,700 today,
and we'll probably plateau at around 1,500. We went from 83 data centers to 6.

We were not in great shape, but we took action. I don’t believe we took action because we knew
the economy was going to change. We don’t think we're that clever. We just had to take it,
because economically it was just not the right solution, and nor technically.

We had to focus on driving this both from business and IT. As I said in this small example, we
went from 300 apps to 30 apps. We had a 39 percent reduction in our inventory dollars. We
reduced our supply chain expenses. We reduced the cost of doing next day delivery. We're
heading toward reducing our CO2 emissions by 40 percent on those next day deliveries.

But overall, the global supply chain, this measure of spent revenue, we drove down by 19
percent. We're running a better, faster, cheaper organization that is more agile. As you said, it
positions us better to exploit situations as they change and feel that they’ve become more of an
opportunity rather than a threat.

Gardner: For those organizations that are in some sort of a multi-year approach, looking at their
portfolio of applications, probably shocked by how many there are, what the redundancies are,
what the actual landscape looks like, but perhaps also a little bit chagrin by the daunting
complexity, where do you suggest they start as resources? Is there a way to start thinking
strategically about both the technology, the business, and process issues, as well as those
governance, operational, and methodological issues?

First, take stock

Evans: A number of people I have talked to say that their biggest challenge is that they don’t
know what they’ve got. So, ﬁrst and foremost, the advice is always that you need to take stock of
what you’ve got, because if you don’t know what you are dealing with, then you’ve got a
problem.

I’ll give you an example. I spoke to two large organizations at a recent event we ran here in HP.
One organization openly admitted they didn't know what their problems were. They knew they
had a massive, complex, and growing applications portfolio that was basically losing touch with
the business. That was one side.

Another customer openly admitted that they knew the applications that were causing them
problems. They said, "We have these 14 apps that are killing us, and we need to do something
about it. We need to streamline those apps. We need to use contemporary technology."

They need to use a new software environment that gives them a much smaller code base, if they
are moving from COBOL to something like Java or C#, using new database technologies. Using

new testing techniques that don’t mean that we load testing to the end of the session. Then, when
time gets tight, what gets cut? The testing gets cut.

That was a good example we used in the supply chain example. We used an HP product, Quality
Center, that gave us this process, this rigor that said, "We're going to test things. We're going to
throw out different scenarios, and we're going to test it to death. We're not going to test it to death
at the end when it’s too late, but we're going to do that throughout the development cycle so that
we can make those adjustments and modifications as we go along."

So, we ended up with a high-quality product at the end. Talking to a lot of customers, the speed
by which they can develop, as well as modify, applications, and that is connected directly to
customer satisfaction, is paramount.

In the financial services industry, your application is your business. If you are in the Telco
industry, the level of service you can offer is very much aligned to the application. If you can
improve the speed, and the momentum you can create in terms of introducing new editions and
you can do those with a very high quality and a high level of integrity, then you're heading
towards delivering a much better service to your customer.

There are so many lessons learned here addressing what people have in terms of portfolio and
then also delivering new, contemporary, revised types of applications and/or infrastructure,
Underneath all that is the ability to save money, which, of course, is fairly important, isn’t it?

Gardner: We talked a bit about the how and the why of this massive application consolidation
projects issue, but this specific Global Part Supply Chain project at HP is now a case-study,
which you have written up and which is available for people to get some more detail from. Are
there are some other resources, sites, or places where they can go for not only learning more
about how you solve this problem, but where they can start on their journey or continue the
journey.

Open about experiences

Evans: We have always said that we're going to be very open about our experiences, only
because I think people don’t want to begin new things. They don't want to be the first to take a
leap, but as I said, pretty much every customer in my mind is doing some form of application
transformation, whether small, large, or medium scale.

We have always said that the experiences we gain from our own work we would share openly,
and sometimes we’re quite happy to say where we did go wrong. In this instance, we’ve written
up a case study to give people an insight in more detail than I have been able to provide today.
We're going to post that on our portal. If people want to go there, it’s relatively simple.

It’s http://hp.com/go/applicationtransformation, and they’ll find the case-study. They’ll find
videos and other materials of other customers who have embarked on these journeys, whether
they’ve been driving that from the top down, from an application’s nature, or whether it’s people

who are coming in from the infrastructure, who will say, "I have aging obsolete infrastructure
that I need to change, but I know there is a collateral impact on my application. How do I go
about that?"

We're trying to cover all the bases in terms of those people that are coming with top-down
applications, bottom-up infrastructure, or looking to create a new software environment. If they
go to that URL, they can find all the materials, and I hope that they might find useful.

Gardner: Paul, before we close out, perhaps a look to the future. I've heard so much now about
cloud computing and software as a service. This is not necessarily just talking about custom,
packaged, and on-premises apps. We now need to think about different sourcing options. How
does that relate to this process of application transformation and the rationale around where to go
for the best economic bang for the buck?

Evans: Cloud is just a part of the application transformation journey. If you think of history over
the last 50 years -- and that’s all technology is; it’s only 50 years old in this space -- we’ve done
everything inside. We did everything ourselves. We did everything in big machines, crammed
everything in, then we’ve gone more distributed. We’ve gone to PCs and all rest of it. We began
to spread the web, before we even knew what the word "Web" meant.

Now, we’ve gotten used to interacting with the Internet, and more importantly, the web. We're
beginning to say, you know, maybe there are some services that we don't need inside of firewall,
or in a private cloud -- so it’s inside but not inside." The point is that we get this ability to have
an elastic environment. We haven’t got dedicated systems to run a service that maybe we only
want to use 20 percent of the time.

The notion of using the web or technologies that have been formed from the web development is
just like falling off a log. We'll argue probably for at least the next 12 months about what is the
cloud and what’s not the cloud, but the use of the World Wide Web is a part of our day-to-day
business that's irreversible.

We're never going to go backwards now, whether it’s just interaction with consumers who want
to get questions answered and order a PC or whatever, or the provision of services that we'll use
and our customers will use by utilizing the web. It’s just going to be there.

Also, merging with this whole notion of the cloud is mobility. The mobile, the smartphone, or
call it what you want, is going to be the most voluminous device that will attach to the web in the
future. People are not just going to want to play games, send SMS, and all the rest of it. They're
going to email, they are going to want to do things, and they are going to want to interact in a far
richer environment than they do today.

I think these technologies are converging rapidly in terms of a notion that says we’ve got to
update and transform what we’ve got and at the same time start the more strategic view of what
are we going to incorporate going forward. We may not incorporate them today, but we sure need
to leave that socket open that says I may want to plug it in the future.

Gardner: Well great. We've been talking about best practices in execution accelerators around
large application consolidation projects. We’ve been joined by Paul Evans, World Wide
Marketing Lead on Applications Transformation at HP. Thank you, Paul.

Evans: Thanks, Dana.

Gardner: This is Dana Gardner, Principal Analyst at Interarbor Solutions. You’ve been listening
to a sponsored BriefingsDirect podcast. Thanks for listening, and come back next time.


Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor:
Hewlett-Packard.

Transcript of a BriefingsDirect podcast on how Hewlett-Packard tackled an internal multi-year
effort to streamline supply chain efficiencies and effectiveness. Copyright Interarbor Solutions,
LLC, 2005-2010. All rights reserved.

You may also be interested in:

• Doing Nothing Can Be Costliest IT Course When Legacy Systems and Applications Are
Involved

• Application Transformation Case Study Targets Enterprise Bottom Line with Eye-
Popping ROI

• HP's Paul Evans, Oracle's Lance Knowlton on Application Modernization and IT
Transformation

HP Shows Extent and Benefits From Successful Application Consolidation With Own Global Project

Recommended

Recommended

More Related Content

Recently uploaded

Recently uploaded (20)

Featured

Featured (20)

HP Shows Extent and Benefits From Successful Application Consolidation With Own Global Project