BAE Systems (formerly British Aerospace and Marconi Electronic Systems) is one of the world's largest defense contractors. Based in the U.K., its offerings include avionics, military and regional jet aircraft, air defense systems, missiles, artillery locators, communications and navigation systems, radar, ships, space systems and aerospace electronics. BAE also owns 20 percent of Airbus, Boeing's only competitor for large commercial aircraft. The company operates on every continent and in 2003 had sales revenue of $22bn and booked orders valued at $72bn. The scope and diversity of BAE's activities, along with a history of growth by acquisition, have resulted in geographically dispersed business units that operate a host of disparate systems and buy from myriad suppliers. As program manager for the company's Integrated Supplier Information System, James Donlevy's task is to bring order and discipline to procurement activities across the enterprise.

Q: You came to BAE by way of Marconi?
Donlevy: Yes, I joined Marconi in 1974 and progressed through various positions to that of procurement manager. Marconi and British Aerospace merged toward the end of 1999. For the past few years, I have been engaged in looking at the company's systems, in particular procurement systems, and defining those a bit more. I am program manager of our internal Integrated Supplier Information System, or ISIS. ISIS is a single instance, global system and it covers our businesses from Australia to the U.K. and companies in North America. It is basically the Supplier Relationship Management tool from i2 Technologies that we configured to our needs. We really use it like a global data warehouse.

Q: What problem was ISIS designed to solve?
Donlevy: If you look at the roots of Marconi and British Aerospace, both organizations grew by acquisition over their life spans. The resulting product portfolio makes for a very wide-ranging and diverse organization. Most of the business units were autonomous and so had their own policies and practices. And, of course, there are a lot of disparate information systems.

We have 75 sites, numerous MRP systems and 45 separate instances of ERP. These range from Oracle, SAP and Manugistics to a whole mix of legacy systems. They range across all our different geographies. And before implementing i2/ISIS, we didn't have a single, standard commodity-code structure. We didn't have a standard supplier-addressing format. So these were prime areas that had to be fixed. Until they were fixed, we could not consolidate supplier information from all our businesses. We couldn't analyze information on a commodity or category basis to find out what we were spending or with whom.
What we wanted to do was to be able to see what we were buying in a particular commodity class across the enterprise and to consolidate that spend-whether it was PCs or integrated circuits or raw metals, whatever.

This was a strategic corporate decision. The way we are structured in BAE Systems is that we have a procurement council that is made up of the heads of procurement at all the business groups. They are our sponsors. These procurement directors meet once a month and it was their decision that it would be strategically important for the organization to capture purchasing activity in this way. So when we wanted to introduce a commodity-code structure, we had a steering group and a strong sponsoring body made up of the main experts in this area.

Q: How much do you spend annually on materials?
Donlevy: We probably spend on materials around $78m per annum and that is of course the whole spectrum. For an organization of our size there are things like travel and catering that, although not core to the business, still represent a big spend.

Q: Can you explain how you use the SRM product?
Donlevy: First of all, we have changed our processes. This is not a requirement of the tool but there are things you need to do, by common sense, to make the tool meaningful. For example, we had all these different companies using various suppliers but no single process for entering suppliers and no single master list. So what happens is that people would free-format names and addresses. You then searched for an existing supplier and if you had different spellings or Inc. instead of plc, or any of the variations that people come up with, you don't find a match.

At an early stage we decided we wanted to physically fix this once, so we configured SRM to make it the supplier master.

We actually bought the i2 tool at Marconi in '98, before the merger with BA. But it wasn't i2 then, it was Aspect Development, which was later acquired by i2. We chose them for a couple of reasons: one, there weren't many vendors in the market at that time, so the choices were pretty limited. And, two, we already were using another product from Aspect called CIS, or component information system, which was the foundation for our parts master. So we talked with i2/Aspect and told them that we were looking for a solution that enabled us to do with suppliers what the CIS tool allowed us to do with parts. They had actually been thinking along the same lines and Marconi became a lead pilot site for what was later known as i2's SRM.

The first thing we had to do was set up a pilot project with i2. We established a pilot site and then we actually wrote a corporate commodity code list for BAE Systems-a list of all of our parts and all of the categories that are meaningful to us. We decided to code all these and make up a single list. At that time each of the different organizations had separate commodity code lists. Some were good, some bad, some were used, some weren't. But the point is there wasn't one single, common list. They were all different. So, rather than pick a favorite, we decided to write a fresh one. That was our first big milestone-to develop a commodity code structure that everyone would use.

So, basically, we were looking to rationalize our commodity codes. When we started we had in excess of 20,000 codes being used throughout the enterprise. Now we are down to something like 700-plus. We kept it very simple. For example, if we purchased 10 types of resistors, these would be R01 through R10. So, that was the first hurdle. The next big issue was, OK, now that you have a single list, how do you get all these different systems to recognize the new codes? We could have gone back into all our ERP systems and made this change, but if we had chosen to do that we would probably still be at it today.

What we did instead was very simple. First, we said that any new systems that come into the company would start to use these commodity codes from day one. That's very long term because we don't change ERP systems that often, but that is still an important step. Second, we very simply cross-referenced all the local commodity code lists with the new corporate commodity code list. That is a little bit subjective in some areas, but bearing in mind where we were and where we wanted to get to, it was probably the easiest and most cost effective solution for us. So, we mapped into the i2 SRM product all of our different local commodity codes and cross-referenced them to a commodity master. We basically did this using an Excel spreadsheet with two codes. It works, it was cheap and it is very quick. And now when we ask how much do we spend on resistors, we get one answer-but it is really made up of variable commodity codes from 75 different sites.

I'm not saying we did it the right way or the wrong way. I'm just saying this is what worked for us.

Q: Did you take basically the same approach to your supplier master?
Donlevy: We had basically the same problem with suppliers and supplier code numbers, but when we started we had 97,000 suppliers, so we couldn't do a cross-reference for all of that lot.

We knew we could clean up the supplier list and get rid of the massive redundancies and get all the names and addresses correct, but we wanted to be sure we stopped the problem from happening again in the future. So, again, we came up with idea of making the SRM database the supplier master and making SRM the place where people added supplier names and addressees. SRM then triggers the message back to the various ERP systems.

To do this, we actually disabled the functions in all the ERP systems that allowed people to add suppliers. That code was essentially replicated in the i2 SRM product and we wrote interfaces, so that when someone using Oracle or SAP or Baan goes into ISIS they see exactly the same field as they would see if they went into the ERP system. We had to do it that way because, if we required more key taps, people would not want to use it, so we had to mirror exactly what they were doing before. The nice thing with SRM is that we were able to put all that on one page or screen, whereas people had to go through several pages with the ERP systems. So they actually enter the information in SRM and the i2 product updates all the different ERP systems.

As soon as we made these changes, our supplier list plateaued, because now everyone had visibility to the same system. If someone in one part of the country wanted to add a supplier, they went to SRM, and the process we installed meant they had to ask SRM if the supplier already existed in the system. If it did, it could not be added again. Before SRM, people could not see that. We still get some errors with it, where people enter the names differently and a supplier gets duplicated, so maybe twice a year we go through a supplier consolidation process where we clean up the list. But this is now down to a maintenance function rather than a massive exercise. Our master now has about 14,000 names on it, which is quite a bit different than 97,000.

Q: So now you aggregate your spend with each supplier?
Donlevy: Yes. What a commodity manager will do is to look at a particular commodity group to see what we are spending there. They will then see who our top suppliers are for this commodity and focus their negotiations on those suppliers. Before that point, we couldn't tell which businesses were spending what with whom. Our real driver was to actually have that visibility. And also to consolidate and rationalize.

Q: Can you share any quantitative results in terms of savings?
Donlevy: We don't normally share information on material spend or savings. I will say that we feel we have had a good return on investment.

We have expanded the use of SRM. We are now using it to hold financial information like accounts payable. It also holds all our purchase orders and all our invoices. And we are also feeds from our corporate credit card account. So, now we have total spend in one place. At the moment we are looking to enhance SRM to hold supplier quality accreditations as well.

The way we use it, the SRM tool can best be described as a data warehouse. We take data from all these different facilities and consolidate it and roll it up and have it available for analysis.

We also have started tailoring the data for different business groups, so when users log on to our intranet, they see their view of the data as opposed to the whole view. This makes it easier to use. We have added advanced analytics, which was needed because there is so much data. We are probably storing something like 60 million pieces of data-we have 4.5 million parts and typically about 3 million purchase orders, so it is massive amounts of data. The advanced analytics we have added on top allows users to see this information graphically and summarized in a way that makes it easier to work with. One of the problems with vast amounts of data is presenting it in a way that users can actually understand. The SRM product is really quite good at that.

Q: Are there lessons you derived from this project that you would like to share?
Donlevy: When you are doing your design specification, it is very important to identify upfront all the pieces of data you need, and by that I mean what you need to make sense of a consolidated view. This would be things like suppliers, purchase order numbers, values, dates, part numbers-all the things that when you want to ask the question, how much do I spend on this part, you will be able to get a meaningful answer. So the design requirement at the front end is absolutely vital. Difficult but just vital. If you don't clean up your foundational database, your investment will be wasted.

You also need to have good processes in place, so that things stay in sync whenever you add new information.