2006 05 sapphire us or0422 transcript

¢

¢

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.

1Copyright 2006 W.W. Grainger, Inc.

Agenda

° SAP Perspective

° Company Profile

° Project Profile

° Challenges

° Tactics

° Results

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

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

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

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

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

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

Los Angeles

Dallas

Kansas City

Chicago

Jacksonville

Greenville

Princeton

Memphis

Cleveland

Denver

San Jose

Minneapolis

Seattle

Distribution Centers Master Branches

Ground Service to Reach Customers Fast 1 Day Service 2 Day Service

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

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.


No day is ever the s ame.No day is ever the same.

Task Ahead

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

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

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

Place Order

Available to Promise

Forecast Stocking

Levels

Reconcile Payment

Create Awareness Initiate

Inquiry

Awareness to Inquiry ATI

Inquiry to Cash ITC

Forecast to Pay FTP

Financial and Operations Management

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

Place Order


Forecast Stocking

Levels

Reconcile Payment


Inquiry


Inquiry to Cash ITC

Forecast to Pay FTP

FI CO BW SEM EBP HR MSS ESS EP XI

SD

WM MM

PP

FSCM

CIC

PLM

SCM

SRM

CRM

GTS

APO

Integrated CRM and Order

Processing

High Volume AR and Credit Management

Company Wide Self Service

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

Place Order


Forecast Stocking

Levels

Reconcile Payment


Inquiry


Inquiry to Cash ITC

Forecast to Pay FTP

Document Scanning Workflow Customer and Supplier Rebates Sales Commission

Billing Address Correction

Credit Card Search Engine

Sales Tax Imaging

Workflow MSDS

Shipping Manifest

Pricing Management

Contract Management

Payroll TaxCheck PrintingIRS AuditTax Returns

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

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

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

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

Process Design

Sub-Process Design

Functional Design/BPPs

Technical Design

Configuration/ Programming

Unit Test String Test

Integration Test

Business Readiness Test Go Live

Business Comparison Test Cut-Over Dress Rehearsals

System Performance Validation

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.

t


Theory of Testing

° Defects exist in processes, data, and software

° The later you find a defect, 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

the

Webcast Time: 00:22:55 / Theory of Tes ing

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

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

OWNERSHIPADOPTION

GENERAL UNDERSTANDING

AWARENESS

Com

mit m

ent

Com

mitm

ent

—Build the Foundation“

—Clarify the Details“

—Prepare for New Work“

PERSONAL UNDERSTANDING

ACCEPTANCE

—Sustain Performance“

TimeTime

Change Commitment Curve

Source: Deloitte

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

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

Issues

Go Live

Operations & Continuous ImprovementImplementation Discovery &

Evaluation

Technical Issues

Supplier Involvement

Source: SAP

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

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

Successful Big Bang

Implementation

Alignment

Partnership

Testing Deployment

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.

2006 05 sapphire us or0422 transcript

Documents