Disclaimer: Transcripts are the exact conversation for the presentation and may contain grammatical errors and

other mistakes.
SAP is providing these transcripts, so you can read the presentation in its original form.

SAPPHIRE '06 Orlando

How Grainger Achieved Success with Its Big Bang Implementation

¢ Brian Vogt, Vice President, SAP

¢ George Rimnac, Vice President and Chief Technologist, W.W. Grainger Inc.

Brian Vogt, Vice President, SAP

Hello, and welcome to the Grainger success story on their Big Bang. My name is Brian Vogt, I am a Vice
President working on the SAP Consulting organization. I am here today to introduce to you the Grainger
project that they went live with earlier this year. In order to do that, we are going to go through the
following agendas, so that we can update you on what Grainger went through. This was one of the
largest Big Bang implementations ever attempted at SAP, not only from the sheer size of this
implementation, but also from all the modules and the components they implemented with all the bolt-
on products as well on a one-day, Big Bang Go-Live.

Agenda

° SAP Perspective
° Company Profile
° Project Profile
° Challenges
° Tactics
° Results

Copyright 2006 W.W. Grainger, Inc. 1

Webcast Time: 00:00:29 / Agenda

What we're going to do is, I'm going to talk a couple of minutes, give an SAP perspective on some of
the key elements that made them successful in this endeavor. Then George Rimnac will come up here
and he's going to talk to you about the company profile, as well their project profile, the challenges that
they were faced with, the tactics they had to engage in to get through some of those challenges. Then
finally what were the final results when they did go live on that historic day that we'll never forget,
George. Right?
 SAP Perspective œ Brian Vogt

Key Elements of the Grainger Project:

° Implementation Scope was Mapped Out with SAP Before the
System Integrator was Selected
° Governance Models Were Created and Used Throughout the
Implementation
° Technology Partnership Support was Coordinated Though SAP
MaxAttention
° Heavy Volume and Business Testing
° Openness and Scalability Achieved with Netweaver Technology

Copyright 2006 W.W. Grainger, Inc. 2

Webcast Time: 00:01:18 / SAP Perspective œ Brian Vogt

From an SAP perspective, if we look at what Grainger did it is probably not too unlike what you've done
on your projects. But what they were really able to accomplish is that they were able to execute to an
art form in some of these key areas and one of the first areas that they focused a lot of time and
attention on is that, after they bought the SAP software, they didn't immediately go to implement it. It
took them about a year and a half to really understand what type of scope they were going to have to
put in on this Big Bang implementation. They worked with SAP to understand what products were
mature, were probably in their second release, and what capabilities did we not have so that they could
go out there and get the appropriate certified partner software, or even in some situations, non-
certified partner software to design what they felt would be their idea of business solution.

They also engaged in a very heavy governance model. I'm sure a lot of companies have governance
models, program management offices, but what Grainger did that was really unique, and I've been with
SAP and doing implementations for thirteen years, is they really made the governance model critical to
their success. They made sure that their Board of Directors, they made sure that their C-business
executives, that the system integrators, SAP, the hardware vendors were all part of the governance
model, to make sure that the governance model delivered what it was supposed to do.

It is supposed to provide leadership, it is supposed to remove roadblocks, and it is supposed to provide

consistency for the project over the years and not waver from the initial scope that they set out to
deliver. Technology partnership and support was coordinated through SAP and Max Attention. As you
listen to George talk about what they implemented, it was absolutely critical in the Big Bang
implementation that you do not have any issues with your hardware, your operating systems or even
your business processes when you turn that switch on. In order to do that, we had to bring together an
escalation process that consisted of certified partners of SAP and non-certified partners of SAP,
leveraging the centers of companies of Sun , HP, and Oracle, in order to make sure that, if there was
an issue, either reimplementation or post implementation, we went after the executives of those
companies so that the issue was resolved rapidly.

Also, a key element of the Grainger implementation was the heavy testing that took place. I've never
seen an implementation where there was so much testing. Not only was there a unit testing, there was
also a special testing cycle at the end of the project, called business readiness assessment testing which
really proved out that the corporation was ready for turning the switch on, to make sure that there was
very little if any business disruptions on day one, and to make sure that the end users were fully aware
and that you didn't have that typical, when you go live, you get that typical peak that goes soft for a
little while, and then goes back up. What Grainger tried to do was to avoid any down time within their
operation. From the business standpoint and from the technology standpoint, and they were extremely
successful in doing that. Then the ESA theater. The other key component of the solution was to make
sure... Grainger is a tremendously high-volume customer of SAP. they had to make sure that, first of all,
that the system was scalable and that it was open, because they were not just implementing SAP, there
were other software components, and there was other development that they had to do in order to
successfully pull off their Big Bang project.

So without further ado, I would like to introduce to you George Ramnic. He is a man that most people
think was crazy or nuts for actually trying to propose this implementation plan to Grainger's board. But
also he is recognized as one of the top technology officers by Computer World Magazine in 2006. So,
without further ado, George Rimnac from Grainger.
George Rimnac, Vice President and Chief Technologist, W.W. Grainger Inc.

Thank you very much. The key to success for this project was due in no small part to partnership and
probably the one person that always comes to my mind about partnership is Brian Vogt, and the
relationship that we had with SAP, so clearly we could never have accomplished what we've
accomplished without SAP and without Brian's support in particular, so I appreciate that very much.

Facts About Grainger

° Founded in 1927

° $5.5 billion in sales

° 16,500+ employees

° 2 million customers

° 1,200 suppliers

° 582 branches

° 18 distribution centers

° Access to 500,000+ products

° United States, Mexico, Canada, and China

Copyright 2006 W.W. Grainger, Inc. 3

Webcast Time: 00:06:03 / Facts About Grainger

Let me give you a brief background about Grainger, in case you don't know anything about Grainger.
Grainger is a business hardware store. We supply the maintenance supplies for businesses all across
the United States, Canada and Mexico, to support those businesses and keep those businesses facilities
in good working order. We were founded back in 1927, have 5 billion in sales, have branches all over
the place, millions of business customers and over half a million products available.

Economics of Small Item Purchasing

Copyright 2006 W.W. Grainger, Inc. 4

Webcast Time: 00:06:35 / Economics of Small Item Purchasing

The reason people buy stuff from us is because they try to solve a very specific problem, and that
problem is, that when everybody gets together in a company to buy a facilities maintenance product
like a hammer, the cost of a hammer is actually a very low cost relative to the total process cost of
executing that order. So all these people got together and spent one hundred dollars to buy that
seventeen-dollar hammer, to make sure that the price isn't sixteen twenty five or sixteen dollars. Well,
the challenge that we have in our industry is that we can help our customer either get that hammer for
the price they are looking for or help them drive real cost out of that procurement process. If we can
drive that cost out either one goes down to the bottom line and we think our customers prefer to put
twenty/thirty dollars of that process' cost to their bottom line as opposed to the seventy-five cents
they'd otherwise save.

Grainger‘s Goal

° Save customers time and money

as they maintain, repair and
operate their facilities.

° Do this by:
° Offering a broad range of products
through multiple channels
° Having high product availability
with a local presence

Copyright 2006 W.W. Grainger, Inc. 5

Webcast Time: 00:07:28 / Grainger's Goal

So Grainger's goal is to help, not hassle, our customers. When we're talking about hassling the
customer. What is that? That means not billing the customer for the correct amount, not including the
right paperwork with the order so that when it arrives at the receiving department it can't be properly
received. So if it doesn't show up on time for the facilities maintenance person it is probably trying to
solve a very critical need for that business at that point in time. All those things have to go well, and
the key to doing that is a tightly integrated set of systems and set of services that can be executed
perfectly time after time hundreds of thousands of times a day.

Grainger‘s Scale Advantage

° Broad product line

° Efficient logistics network
° Customer coverage
° Integrated information systems

Copyright 2006 W.W. Grainger, Inc. 6

Webcast Time: 00:08:11 / Grainger's Scale Advantage

So Grainger's advantage is in scale. We have a very broad product line, we have a logistics network
that is able to deliver those products in that timeframe, and all of this contributes to a very complex
business systems problem. And this is the problem that we faced, that was being faced with a disparate
number of systems from all over, that we had put together to try to serve our customers well, and the
conclusion that we came to after working with SAP was that a fully configurated, fully integrated
solution from SAP was the answer that we needed to satisfy our customer's needs.

Grainger‘s Reach
Ground Service to Reach Customers Fast 1 Day Service 2 Day Service

Seattle

Minneapolis

San Jose Cleveland

Chicago Princeton
Denver

Los Angeles Kansas City

Memphis
Greenville

Dallas

Distribution Centers Jacksonville

Master Branches

Copyright 2006 W.W. Grainger, Inc. 7

Webcast Time: 00:08:48 / Grainger's Reach

The reach that we have across the United States is we have to serve every territory. We have branch
offices, we have warehouses in all of fifty states as well as in Canada and in Mexico and Puerto Rico.
And the small spots in red represent the few places in the United States today where we cannot get a
shipment to next day. So, a hundred thousand times a day, customers call us up wanting facilities
maintenance products that they expect to either receive that day or the next day, guaranteed.

From Guiding Principles to Implementation

° Build a platform of common processes

° Create a consistent customer experience across all channels
° Shift to a process-oriented business architecture
° Offer a standardized, configurable menu of services
° Establish a single source of truth for all information
° Design transactions to be complete and accurate

Copyright 2006 W.W. Grainger, Inc. 8

Webcast Time: 00:09:23 / From Guiding Principles to Implementation

With that as a background to the kind of business that we are trying to support, we created a set of
guiding principles, and those guiding principles were really the foundation not only for us to explain to
our business executives and the rest of our business leaders why this system initiative was so critical to
the operation of their business but also to help the team in the day-to-day decision making that they
had to make and be engaged in, solving one problem after another. And so these guiding principles
really served as a foundation. Once we set the foundation, it was time to get to work.
 Task Ahead

No day is ever the same.

same.

Copyright 2006 W.W. Grainger, Inc. 9

Webcast Time: 00:09:58 / Task Ahead

This is the kind of problem our customer faces every day. It is an unexpected, unplanned problem.
They didn't know they had the problem this morning. What they do know is that Grainger has a solution
for them, and if that they can get their hands on that solution either today or early tomorrow morning,
that would solve that problem. In a very interesting way, the project faced the same issue. Every day
there was a different problem. Every day there was a different issue. That we were always focused on
delivering a very successful single-day implementation. So let me tell you how we prepared to do that.

Recipe for Implementation

° Almost 20 SAP modules

° More than 20 Business application Bolt-Ons
° 460 servers
° 5 terabytes of data in R/3
° 500,000 business transactions per day
° 10,000 users, 6,000 using SD and CRM
° Single Go-Live weekend
° Retire 50+ legacy systems
° Easy to follow instructions

Copyright 2006 W.W. Grainger, Inc. 10

Webcast Time: 00:10:38 / Recipe for Implementation

The recipe for a solution like this is: you take all of this stuff, literally dozens of SAP modules and
components, bolt-on software products, hundreds of servers, dozens of terabytes. This 5 terabyte
number just represents the core R/3 system alone, there was another 5 terabytes for BW and for all the
other supporting systems that we implemented. Add ten thousand users, and then follow the very
simple-to-follow instructions that you receive from SAP and you can have a very successful
implementation.
 Project Challenges

° Design of Grainger‘s business

° High transaction volume and complexity
° Large, geographically dispersed workforce
° Substantial custom development
° Large number of technology suppliers

Copyright 2006 W.W. Grainger, Inc. 11

Webcast Time: 00:11:15 / Project Challenges

But there were a few challenges in our circumstance, and those challenges included the design of our
business. It was very difficult for us to consider breaking up the business, regionalizing the business in
such a way because we had a lot of national account customers, people who bought from all over the
U.S. for anywhere in the U.S. and it was very difficult to partition up this business in such a way that we
could consider either a regional or district level rollout. So we couldn't do that. The very design of our
business and the way our customers wanted to be served forced us into a situation where we had to
consider a Big Bang implementation.

We had very high transaction volume. And that high transaction volume certainly struck fear in the
hearts of all the technical people that were looking at it because they knew exactly how it would
manifest itself in all the different components and subsystems. We also had to deliver this across a very
large geography. So, in all fifty states, all four hundred and some locations around those fifty states we
had hundreds and thousands of employees, all of which would have to be trained and prepared to use
this new system and be ready to go on a single go-out day. And finally, we had a very large collection
of technology suppliers. And what was critical to me was that I had to figure out with the help of my
team how we could get all those technology suppliers to join our company and be part of this project
team in order to make it successful.

Process Scope
Awareness to Inquiry ATI

Inquiry to Cash ITC

Forecast to Pay FTP

Create
Initiate
Awareness
Inquiry

Reconcile
Payment
Place
Order
Forecast
Stocking
Levels Available to
Promise

Financial and Operations Management

Copyright 2006 W.W. Grainger, Inc. 12

Webcast Time: 00:12:43 / Process Scope

To give you a back up for how we thought about our business, we drew this very simple process
drawing, and quite frankly I would believe that this process description probably matches every
business that is represented here in this theater.

In this case, we started by creating awareness in the eye of the customer about the products and
services that we offer. The costumer initiates an enquiry. And against that enquiry, the customer talks
to us about these products and services that they need and from there we take an order. Consummate
the order, fulfill the order, the customer pays us for it and, if that was a good experience, two things
happen: the first thing that happens is that they come back and try us again. The second thing that
happens is we look back across our supply chain to make sure that the products that we need to have
in stock and available continue to remain so in the supply chains.

SAP Modules
Awareness to Inquiry ATI

CRM Inquiry to Cash ITC

Forecast to Pay FTP

Create
Initiate
Awareness
Inquiry

CIC Integrated CRM

and Order
SD Processing

High Volume
Reconcile FSCM AR and Credit GTS
Payment Management
Place
Order
PLM
Forecast
Stocking
Levels PP Available to
APO MM Promise
SCM WM
SRM

Company Wide Self Service

FI CO BW SEM EBP HR MSS ESS EP XI

Copyright 2006 W.W. Grainger, Inc. 13

Webcast Time: 00:13:41 / SAP Modules

So how do we do that? Well, we did that with a number of SAP modules and components. In fact, this
represents, if you lay those components and modules against the various functions that I described in
this process cycle, this is where they would fit. So, all of these, where all of the components we
implemented are together in this go-live event.

Now, let me point out a couple of key features of this. First, we set up a tight integration between
customer interaction center and sales and distribution, so that we can use the features and functions of
CIM to help our telephone agents to take the majority of our orders, while the people who stand at the
counter and take orders from our business customer at our branch locations the opportunity to know by
contact name who our customer is, what happened to him the last time they did business with us, any
information about their preferences, about how they want business conducted, as well as any historical
information that may be pertinent to making the experience that they have this time as successful as it
can possibly be made. That seamlessly transitions into actually taking the order in sales and
distribution. And this is happening across the six thousand sales agents that we have both on the phone
and at the counter across the network. As a matter of fact, at this time of day we're at around our peak
hour now, and this is when the system would be the busiest. In addition to that, we have to deal with
all the remittance payments that our customers make against that, so the fifteen thousand something
checks that come in every day have to be applied against all that open account billing because that is
the primary way in which our customers pay for the products that they purchase from us.

And so, in that circumstance, it is also a very high volume operation, highly automated with an
automated log box. When you're managing the open account billing for millions of businesses. in fact,
our management of that credit is so critical to our operation that it is the single most important factor
when it comes to management of day sales outstanding. And just a few days of day sales outstanding
represent literally tens of millions of dollars to a company like Grainger.

So, making sure that that works well and works under very high volume was critical to us and was
incorporated in a very special way in a lot of the testing that we did in order to make sure that financial
supply chain management was up to the task. In addition to that, we underwent a major shift in the
organization getting everyone acclimated to self-service. Not only self service in the HR component,
both in play and management self service, but also self service from the expanse purchasing standpoint
with electronic professional.

There, a lot of expanse processing goes on, not only in our branches but also in our corporate offices
and among our corporate employees. All of that is done through a self service workflow-oriented
solution that's been implemented across the board. And all of that under the umbrella of the enterprise
portal. All these components were new to our implementation.

Software Bolt-Ons
Awareness to Inquiry ATI

Inquiry to Cash ITC

Pricing Management
Forecast to Pay FTP
Contract Management
Create
Initiate
Awareness
Inquiry

Credit Card
Search Engine
Sales Tax
Document Scanning Imaging
Workflow
Reconcile
Customer and Supplier Rebates
Payment Sales Commission Place
Billing Address Correction Order
Forecast
Stocking
Levels Available to
Workflow Promise
MSDS
Shipping Manifest

Tax Returns IRS Audit Check Printing Payroll Tax

Copyright 2006 W.W. Grainger, Inc. 14

Webcast Time: 00:17:01 / Software Bolt-Ons

In addition to that, we had to supplement some parts of the system where clearly an SAP solution was
insufficient to solve all of our needs and address all of our needs. Some of them are very
straightforward, as you may well imagine, such as credit card processing or sales tax or employee
payload tax, but also some very specific functional areas where we had very specific requirements that
had to be met by bolt-on products. In all these circumstances, we use The NetWeaver technology and
open architecture of SAP to help us to integrate those effectively and still accomplish our goal of
establishing a single integrated solution for our business.

Ready For Go Live?

AP Photo

Copyright 2006 W.W. Grainger, Inc. 15

Webcast Time: 00:17:44 / Ready For Go Live?

So, the real question is, are you ready for go-live? And I can assure you that many people in our project
team viewed the go-live event as it approached not exactly in the same way that this particular young
man is facing this wave. Evidently, this constitutes sport in Australia, and this is a photograph of
someone just south of Sydney apparently who is actually just standing there waiting for the wave to
wash over him. Well, not everyone was so enthusiastic.
 How Grainger Prepared

° Project Governance
° Technical Readiness
° Business Readiness
° Technology Supplier Partnership

Copyright 2006 W.W. Grainger, Inc. 16

Webcast Time: 00:18:17 / How Grainger prepared

So, how did we prepare exactly for this process? There were four major areas, and I'm going to spend
some time talking about each one of them. Let's start with project governance.

Project Governance

° An informed and engaged executive team

° A large project team focused on the work
° Technology suppliers informed and integrated
° Continuous refinement of the project plan
° A balance of inclusion and mandates
° Defined and reviewed the scope with SAP
° Strong management of:
° Scope
° Change
° Risk

Copyright 2006 W.W. Grainger, Inc. 17

Webcast Time: 00:18:25 / Project Governance

In project governance, the most important thing, as Brian mentioned, is making sure that our executive
team is both engaged and well educated about what the project was about, what we were trying to
accomplish and actually taking that executive team deep into the details of the project.

Why did we take them into the details? We had steering committee meetings every two weeks. During
those steering committee meetings we engaged the senior team in detailed discussions of all the
problems that the project team faced. Why? Because it gave them a confidence to understand what we
were facing and why we were having the issues that we were having and what assistance we needed
from them in order to be successful.

So it is very contrary to the normal advice that you get, to the average advice that you get, which is to
keep your steering committee at a high level. We didn't; we brought them into the detail. I will not tell
you that it wasn't painful, it was VERY painful. And I'm not going to tell you that it wasn't difficult in
order to explain many of these complex details to the senior team. But what it did do was that it gave
them the opportunity to understand the progress that we were making and see visibly that progress
and have the confidence that we were not only finding problems but knocking them down and
resolving them.

We had a very large project team that we had to keep focused on the work for over two years. Keep
them engaged, keep them understanding where we were in the process of delivering a solution and
also keeping them confident that we would deliver on time. We had to get our technology suppliers
informed and engaged as well, and tightly integrated into the project team, and I can tell you that as a
result of some of the work that we did you couldn't tell the difference walking down the hallway and
dealing with the project team who was from other company and who was actually an employee of
Grainger.

We had a continuous refinement of the project plan. A project like this is not a project where you put a
plan together for a two year set of activities, for literally hundreds of employees and dozens of
technology suppliers and then essentially execute that plan. It is a plan that is continuously refined,
continuously driven to even lower levels of detail as you understand more, as you're able to take the
ambiguity and the risk out of the project and helping people to understand that it is okay to have a
project plan that continuously be refined over time turned out to be a challenge in its own right.

We also had to balance the issue of inclusion, getting people involved in the decision-making process,
and also mandating. There were certain decisions where inclusion just wasn't appropriate. We had to
mandate some decisions, but make sure that we balanced that against a set of inclusion decision-
making processes otherwise. we had to define the scope with SAP and we did that ahead of time, Brian
mentioned that. We sat down and we said basically: are we nuts, thinking that we can do this?

And the answer was, after some reflection and some investigation is to how we were thinking about it
and the steps that we might take, the answer was: no, you're not crazy, but what you're trying to do is
going to be very ambitious and it's going to be very complex and from the beginning we began to
identify the things that we needed to focus on to make sure that we got it right. We also had to make
sure that the scope of the project was well managed. That scope, the change process and also the risk
process. Early on we identified proactively as many risks as we could, in moving through this project
plan and made sure that we had navigation steps identified for every risk step that we took.

Technical Readiness - A Year of Testing

Business Vision Go Live

Business Readiness Test
Process Design System Performance Validation
Cut-Over Dress Rehearsals
Sub-Process Design
Business Comparison Test

Functional Design/BPPs Integration Test

String Test
Technical Design Unit Test

Configuration/
Programming

Copyright 2006 W.W. Grainger, Inc. 18

Webcast Time: 00:22:07 / Technical Readiness œ A Year of Testing

From the technical preparedness standpoint, the key was testing. And it is no exaggeration to say that
we spent a year testing. So, one way of looking at this diagram, which we thought was somewhat
useful, was that we spent a year essentially coming down the left-hand side of that V, going through
the design processes and the construction process and bottoming out in configuration and
programming. We then spent a year marching up the other side.

Now, why is this important? Because testing turned out to be critical to our success. We understood
that as the key way of navigating a lot of the risk that we faced. The other thing that we had to
understand was that to find problems as early as possible was critically important.
 Theory of Testing

° Defects exist in processes, data, and software

° The later you find a defect, the more it costs to repair
° Good tests are designed to find defects
° Don‘t repair all defects, just the critical ones
° You won‘t find all the defects

Copyright 2006 W.W. Grainger, Inc. 19

Webcast Time: 00:22:55 / Theory of Testing

Why is that? Because the theory of testing is, the purpose of testing is to find problems. Testing does
not prove that your system works, testing just tell you where your problems are in the solution that
you've constructed. The later you find that problem, the more expensive it is to correct, because you
have to go back in repeat all the testing in that V that you have previously executed prior to finding that
defect. So, finding the defect the higher you go up on that V, the more disruptive, the more expensive
it is to the process.

The other key learning for us was that you can't find all the defects so you have to understand clearly
what you're going to do when those details present themselves after go-live and the second piece is
understanding that you're under no obligation to repair all the defects. You only have to repair the
defects that you have to repair, the ones that are critical for you to repair, because even the action of
repairing defects puts you in the position of risking the integrity of the work that you've completed thus
far. Everything is a change, and change can be both good and bad. It typically hits you in a bad way, in
ways that you didn't expect or didn't anticipate.

SAP MaxAttention

Source: SAP

Copyright 2006 W.W. Grainger, Inc. 20

Webcast Time: 00:24:10 / SAP MaxAttention

One of the things we did to manage that was our use of safeguarding and MaxAttention in particular.
And this chart really represents the standard cycle for dealing with risk, and while this is specifically
organized around the notion of managing the risk that's technical, the same thing could be true of any
business elements that also present risk in a project like this. And there are many business in change
management and preparedness issues that present risks that are equal or greater than the risk that you
would see technically. But in this particular circumstance, we were trying to attack the technical risks
and getting people to understand that we needed to identify them, understand what we were going to
do about them after they were properly diagnosed, come up with a navigation plan and then make sure
that we executed it against that navigation. We followed this cycle very deliberately with documentation
at every point in the process for literally tens of thousands of defects and risk items that were
identified. We invited people in from all our technology partners to do proactive technical reviews to
actually evaluate the work before it was completed, while it was still in a stage of design to make
constructive criticism that we logged as defects that we then managed, and then decided whether we
wanted to correct or not.

Business Readiness

—Sustain Performance“
—Prepare for New Work“
ADOPTION OWNERSHIP
Commitment
ment

—Clarify the Details“ ACCEPTANCE

—Build the
Commit

PERSONAL
UNDERSTANDING
Foundation“
GENERAL
UNDERSTANDING
Change Commitment Curve
AWARENESS

Time Source: Deloitte

Copyright 2006 W.W. Grainger, Inc. 21

Webcast Time: 00:25:42 / Business Readiness

It is one thing to be ready technically and it is another to be ready as a business. So the other thing we
had to do in business readiness was to get the entire organization, with over 10,000 employees, up this
business readiness curve. And we took this curve very seriously and understood and measured the
progress that we made following this curve all the way through to commitment. So let me describe to
you some of the things that we did in order to understand that.

The Path to Ownership

° Regular communication to the entire organization

° Business led deployment team
° Timely and effective classroom and web based training
° Large power user community
° Regular employee surveys

Copyright 2006 W.W. Grainger, Inc. 22

Webcast Time: 00:26:08 / The Path to Ownership

 We made sure there was regular communication with the entire organization. For that entire 2-year
period, we kept telling people what we were doing, what problems we were having, what successes we
were having and what was going on and what would come next. That turned out to be not only good
for our business but also important to our team because it helped the team to have the right state of
morale about the progress they were making, and a bit of pride, about what they were doing, even
when the results weren't very concrete.

One of the things that is very big challenge in a two-year project like this is, nobody gets to see
anything. It is very difficult to see anything that's concrete. In fact, the people who are investing in the
project are probably the most skeptical of all, because all they've seen is you paying a lot of invoices
and having an awful lot of people running around doing an awful lot of work that doesn't seem to be
particularly relevant to anything they need in the here and now, and you're continuously asking them
for their support in that effort and yet you have very little to show them. So what was important was to
find as many ways as we could to demonstrate that we were making progresses and to communicate
that progress. We had business people calling from the operational side of our project involved in
leading the deployment team. And the deployment team was involved in the training, in the preparation
and the site preparedness for all the locations around the business to make sure that everybody was
ready and prepared to go for this Big Bang implementation.

We had very timely classroom and Web-based training. In fact, by the conclusion of the project, we had
executed almost 800,000 hours of classroom and Web-based training across the entire employee
population, including testing, and one of the things that we did with testing in particular was, we made
sure that the exams were not easily passed.

So, even though they were open-book, even though you could go back and check on the reference
material that we provided as part of the training class, many people did not pass the exam the first
time. That was a bit disconcerting for an awful lot of people in the company who had felt up until that
point that they had mastered that particular functional area. But now here is the new system, and it
wasn't important whether you understood how your business processes worked per say, it was whether
you understood how your business processes works in the context of this new system and are you
prepared to be able to use this new system, to execute against that process.

So, a number of us, myself included, had to take any number of the exams repeatedly until you were
able to pass it. But it did make sure that we took the materials seriously and all of that training was
executed in the last three months of the project.

We had a large power user community, which meant that we had designated over 1,200 people in the
company as getting specialized training, and they were identified with pins and identified to their teams
as being power users, which meant these are the people you can turn to on the go-live day and every
day following with the tough, first-level questions that you might have and the personal assistance that
you might need in order to get your work done during those early days.

The last thing we did was regular employee surveys, where we made sure we understood what was
working and what wasn't working, what people understood and what people were still confused about,
to make sure that we have a level of understanding that we had to have in order to be successful in the
implementation.

Technology Supplier Partnership

° Technology supplier summit

° SAP led volume and performance effort
° Shared problem escalation process
° Open technology, Netweaver based architecture for
integration Functional Technical
Issues Issues

Supplier
Involvement

Discovery & Operations &

Implementation
Evaluation Continuous Improvement
Go Live Source: SAP

Copyright 2006 W.W. Grainger, Inc. 23

Webcast Time: 00:29:54 / Technology Supplier Partnership

We also established the technology supplier partnership. And this was really critical to me, because
from my standpoint this was pulling together all of my technology suppliers who all had critical roles to
play in this project, and making sure they were part of the team, so we had a supplier summit, where
we brought all of the senior executives from these technology companies into our auditorium in our
corporate headquarters and hosted them for a day.

During that day we had our CEO, our president, our CIO and members of the project team all present
to them, so that they could understand what the project was all about, why our senior team was
committed to our success and what role they had to play in order to help us achieve that success.

The other thing that was critical in that summit was that we had all of our technology suppliers share
with one another the escalation procedures for their individual companies, so everybody knew what
everybody else's escalation process looked like, so when there was a problem everyone knew how we
were going to respond to that problem and who would get engaged to help solve it.

SAP led our volume and performance testing cycle, and that volume and performance testing cycle ran
for literally months and during the course of that volume performance test, round the clock testing, 24
hours a day, seven days a week were executed, as many of the people who were involved in that
testing were testified to.

What was powerful about that was the high degree of confidence that everybody had at the conclusion
of that testing effort that this system was actually going to work.

But the other thing that we did after we got through with all that testing was the business readiness
test that Brian Vogt mentioned. And the business readiness test is where we literally carved out a
section of the country (it happened to be our Dallas-Fort Worth area, with forty something branches,
and the distribution center in Dallas-Fort Worth) and we had them repeat on a weekend the entire
activity, business activity for that region of the country from the previous Friday. During the course of
that day, we were able to rehearse what a go-live day would look like.

The value to this wasn't so much that we were able to prove once and for all that the system would
really work from the technology standpoint; the value to this was that we understood whether the
training worked, whether our procedures worked, whether our help desk was prepared and understood
what they'd have to do to handle the volume and the types of questions that were likely to show up as
a consequence of it. And it also gave the whole business a level of confidence, that "hey, you know
what? These guys were able to repeat a whole day's business successfully on a new system. Maybe it is
really ready after all".

Finally, we used NetWeaver to help us integrate all these components. And quite frankly, I can't
imagine trying to get all the integration work done without the NetWeaver technology being in place for
us. That was another critical element, not only for the success of the project, but for the success of all
the technology suppliers that worked with us in order to accomplish our goals.

What Was Delivered

° 320 million rows of data

° 345 custom development objects
° 105 business warehouse objects
° 1400 security roles defined
° 350 EDI maps built
° 460 servers installed
° 70 software packages installed
° 2 data centers equipped

Copyright 2006 W.W. Grainger, Inc. 24

Webcast Time: 00:33:21 / What Was Delivered

So, what was delivered? What did we actually accomplish? Let me give you some statistics that help put
this in a framework, at least frame it so that you can understand the magnitude of the event. We
moved 320 million rows of data out of our legacy environment into this new system. About 320 million
rows of data took over 5 weeks in a 5,000-step project plan that was executed step by step literally
hung on the wall of the project management office as we went though that 5-week period. We went
three rehearsals of that data load and data conversion process prior to the go-live event.

That 5-week exercise was executed with six sigma quality. Literally, the measurements that we took on
data accuracy both before and after the conversion left us with the conclusion that we had achieved six
sigma accuracy in the conversion effort, and by the way it finished within fifteen minutes of the
scheduled time that it was supposed to complete.

We built 345 custom development objects. Those customer development objects ran the gamut of
specialized interfaces to critical components that we needed, but there wasn't a single quagmire made
in the entire system. All of our customer development objects were made in accordance with the
standard user exits and other standards that are supplied by SAP, and we had the Safe Guard Team
evaluate all that work to make sure that we had in fact had adhered to these standards correctly. We
created a large number of business warehouses objects. We implemented for the first time in the
company role-based security, which was absolutely brand new to the business as well as the versa
product for evaluating and understanding the separation of duty issues.

We have a very robust EDI operation, and all that mapping was done as well as testing we did with key
suppliers to make sure that EDI worked before go-live. And of course a substantial number of servers.
Those servers involved not only Sun Microsystems and the Sun Microsystems' large servers for our
databases, but also involved Linux and Intel Base servers from HP, that served in the application server
layer.

There were seventy software packages that we were engaged. Some of those software packages were
for technical support, system monitoring, HP OpenView and other components like that. But the rest of
them were the business components that I've mentioned before. Oh, and by the way we also built a
second data center. During the course of the project we also implemented a second 10,000 sq ft data
center at our Kansas City distribution center and interconnected the two sites with two interoperable
storage networks that are kept in synch using a high-speed OC48 network connection between our
Chicago data center and our Kansas City location, for disaster recovery and support.

We also constructed a significant number of applications to provide disaster recovery and support for
our operation so that we didn't leave a single point of failure anywhere in our network or in our system
solution design.

Now, we accomplished all of that, but there is a real important significance to the picture. And the
picture is, and it is a thing I'm most proud of, we implemented without once disrupting the relationship
between the person behind the counter and the costumer that we were doing business with. So, from
that standpoint with very few if any exceptions we did not interfere with the business and the operation
of the business after go-live starting from the very first day.

So, what did we learn? We learnt that a Big Bang implementation is not something to be taken lightly.
We learnt that a Big Bang implementation is not appropriate for everyone. But if it is appropriate for
you, I believe that you'll define that the following things will be critical to its success: first, make sure
everyone, and I mean everyone, is aligned: your technology suppliers, your employees, your
teammates, your senior team, your product suppliers, your customers; everyone understands what are
you doing, why you're doing it, how are you getting it done, and why they need to have confidence in
the success of your implementation.

Second, you need a test: and you need a test more than you ever imagined you could. And you need to
understand why you are doing the testing and what the value of each level of testing is, and how to
manage through the testing process and understand the wall of change management in the context of
that testing process.

You have to understand deployment, and put special emphasis in making sure that you understand
your readiness, both your business' and your business partners' and the people's who are going to use
the system.
 What Was Learned

Alignment

Successful
Testing Big Bang Deployment
Implementation

Partnership

Copyright 2006 W.W. Grainger, Inc. 25

Webcast Time: 00:38:43 / What Was Learned

Are they ready, are they trained? Do they know what to do in as many different circumstances as you
can train them for? Do they understand why you are doing what you are doing? And do they
understand why they should have confidence not only in you and your team, but in themselves and in
their ability to use this new system and all the capabilities they can enjoy with it.

And finally, you have to make sure that you have a partnership. We could not have done this without
our partners. And I cannot say enough for them; in fact we are bringing them all back together again
for a second technology supplier summit so we'll have the chance to thank them all for the terrific work
that they did.

I think for me, the key moment in the project was a few days after go-live, when we had a
performance problem. When we had that performance problem, I walked into the team room where the
technical team was working and a person from SAP was sitting there and they were saying: I think the
problem is in SAP. And the person from Oracle, who was sitting across from him, said: no, I think you're
wrong, I think the problem is in Oracle. And the person from Sun Microsystems was very insistent that
the problem was in Sun Microsystems' configuration. It was at that moment that I understood that we
have a team of people that were all working for Grainger, and all working for the success of this
implementation. I would have never believed, at the beginning of the project that such a thing was
possible, but I can tell you that such a thing not only is possible, but relatively simple to do. Just simply
bring people together, give them a goal, give them a challenge, tell them why you want to do it, tell
them why it is important that it gets done. And then give them the opportunity to show you that it is
doable, that they did understand what you said, and that they can achieve that goal with your help.

So, with that, I'm open to any questions. Yes, madam.

Audience
Inaudible question

George Rimnac
The question is, what governance have we put in place for support and maintenance. We are pursuing
a MaxAttention agreement with SAP. That is one critical element. we kept a lot of the governance
elements that we constructed in the project after the project so for example one of the things we had
was what we referred to as a cross-process leadership team, where we had all the business process
leaders engaged in a monthly meeting all the way through the project and those meetings continue to
this day, and we have them actively involved in all the prioritization process with regard to changes,
updates and also the break fixes activities going on. Yes, sir.

Audience
Did you use the ESA process methodology, and did you use SAP specifically as the SI?

George Rimnac
Let me start at the end and work my way towards the beginning. We used the ESA process but, while
we had SAP actively involved in the implementation, our system integrator was Deloitte, and one of the
reasons we selected Deloitte was both because of their experience in industrial distribution, but also the
fact that they used the ESA process as the methodology for SAP projects.
With regard to our enterprise systems organization, it is about 400 people, and that stayed the same at
this point, although a lot of the things people are doing are very different from the work they were
doing before the project. We have also substantially increased the number of functions that we are
supporting and many of the business capabilities that the business is now able to enjoy as a result of
the project. What was the first question?

Audience
That is all right. Did you guys also work on a logical data model up front? Did you transform your
business as part of the process, or was it basically a look a like model?

George Rimnac
Let me answer it this way: we didn't use a data model per say, but we did go through a very extensive
process modeling exercise which certainly had data model elements in it. One of the key things that we
did on the project was to actually sit down with the businesses before the project started and give them
an orientation around the idea of a process design around the business, so we identified those key
processes that we thought that were critical to the success of our business, identified business leaders,
made them the process owners, got key people from their organization to lead the process design effort
and so, when we entered the blueprint process, we had all those people lined up with the appropriate
subject matter experts. This was very much a business-led project, not really an IT or enterprise
system-led project. Yes, madam.

Audience
Inaudible question.

George Rimnac
The training was delivered in a very short period of time. The key to that was web-based training. We
did some classroom training. We have a very large training facility at our corporate headquarters at
Lake Forest, where there were ten classrooms. We did some of it but in addition to that we did a
regional trainings center, but the majority was delivered web-based. We used a couple of different
companies to help us actually prepare all those materials. One of the challenges that we faced, because
we had to get it done in a very short period of time was literally finding enough infrastructure to run
that straining system on. Even the company that we engaged for the web-based training was
unprepared for the volume of people that we had on, because we had people training well into the
early hours in the morning, during the week and on the weekends.

One of the questions that I think is related to that is, why did we try to compress all that training in
such a short period of time? The answer to that is relatively simple: number one, we wanted to make
sure that the training materials were completely in synch with the system as it would be delivered so
that we weren't showing you how the system worked before we fixed all the bugs we found in testing,
which is very disruptive and annoying for people going through training to find that the system doesn't
really work the way the training materials represented it to. But the other piece was, our experience
with training, particularly web-based training was that the longer the period of time between being able
to use it and receiving the training, the less effective the training was overall for preparing people to
use the system. People had the tendency to go back. One of the great things about web-based training
was that it put us in a position where people could go back, take refreshers even the weekend before
go-live in case they felt that too much time had expired. I think I have time for one more question. Yes,
sir.

Audience
How early on in the process did you start with your data standardization? Did you actually use any tools
to help you accomplish that?

George Rimnac
With regard to data preparation: data preparation started in blueprint, so we had a specific data team.
In fact we named a group of people, information engineers representing the product information, the
costumer information, and some of the transactional information areas early in the blueprint process
and made them totally responsible for those elements. They then became the information management
team and the data conversion team later in the project. The specific tool that we used to help us with
the mechanics of extracting the data, transforming it and preparing it was a tool from a company called
Back Office, here in the theater. Yes, one more, sure.

Audience
Thanks for emphasizing the benefits of testing. Did you use Suns reference architecture program to do
a prototype, to look at scalability and performance of the architecture?

George Rimnac
We did that. We also used the Mercury tool set to facilitate the actual testing, so LoadRunner and all
that to synthesize workloads. We built a full scale system of course, production environment and did all
the testing on the actual production environment. We had a second environment in our quality
assurance environment is also full sized for any testing, for any improvements that we make now in the
environment and deliver them forward to transport. It is an ongoing process, it is not a one-time deal.
Right. Thank you very much.