Treasury Today interviews Nick Bamfield who led the BP team responsible for the project.

What was the context in which BP Finance embarked on this project?

BP today is a very different company from the BP of five years ago. It changed fundamentally in 1998/9, when we started a process of consolidation within the oil industry with BP’s merger with Amoco. The new BP is twice the size of the old company. Soon after merging with Amoco, we acquired Arco, itself a $30 billion transaction. This was followed in quick succession by the acquisition of Burmah Castrol and the minority in Vastar, an Arco subsidiary in the US.

This meant that by the middle of 2000, we had five different heritage groups, all of which were fairly substantial. All of these groups had different treasury systems and processes. At one extreme, the old BP had a fairly centralised model. Amoco was similar, but it did have its own distinctive US traits. Burmah Castrol was at the other extreme; treasury was very localised with each subsidiary essentially funding itself.

What were the main drivers behind the project?

There were two main drivers. Firstly, we needed to weld the five different heritage companies, with their incompatible banking platforms and different processes, into one unit. Secondly, redesign gave us the opportunity to create a new team around a new vision.

What were the key elements of the project?

I think there were three main strands to it:

The first aspect was to create a common systems platform and common treasury processes across BP Finance in both London and Chicago. We wanted to maximise the benefits of global scale from running common systems and standard process whilst still providing a local face to our businesses. The two locations allow us to operate a fifteen hour service window to our businesses around the world. We also wanted to preserve the best of regional practices we had inherited from each of the heritage companies.

Secondly, it was important that we maintained flexibility and tax efficiency globally. In the old BP, we had used an in-house bank approach, where we had run effectively quasi-bank accounts for our entities. Initially we investigated running the whole of the new group through this existing UK in-house bank. However, it rapidly became clear that this approach was not efficient. The solution was to create an in-house bank in the US to mirror the existing UK in-house bank, both using the same integrated treasury platform. The structure had a number of advantages. It was both business and tax efficient. The US in-house bank also now acted as a settlement agent for inter-company trading in the US as the UK one does for the rest of the world, avoiding the costs of intragroup commercial transactions settling through the external banking system.

The third strand concerns our banking structure. We inherited five heritage groups’ banking relationships. In the US alone, we had about 800 different bank accounts and 60 different bank relationships. We have been working to rationalise these down to a sensible number. We will then be able to provide these banks with more business and build more profitable relationships with them.

When did you start this process?

The need to change was obvious by mid 2000. We had tried to run with separate treasuries for a few months, but it became clear that this was not an optimal way to work. By the middle of 2000, the team had developed the concept of a virtual treasury, with one common platform and approach, which provided the same support processes to the business units across the group wherever they are based.

By the end of 2000, we had a worked up project plan, which included twelve sub-projects. Most of the implementation took place throughout 2001, with the final elements being completed in 2002.

Before we look in detail at the way the project was structured and the decisions behind it, can you explain briefly the BP structure now?

Looking at the diagram below, BU represents our business units around the world. A key principle behind virtual treasury is that wherever our businesses are interfacing with treasury, they should have a common experience and level of service. The systems and processes are the same, so when staff move around the world they have the same experience from treasury. The service front door through which they enter treasury is the same whether they are coming into London or Chicago.

We use Citibank as the global overlay bank to concentrate our cash and foreign exchange for the group. The Wall Street system is the main treasury engine.

For every new business, we have to make two key decisions. The first is whether to service them from Chicago or London. This usually depends on time zone. Secondly, we have to decide which in-house bank to use. This is driven by business efficiency. If need be we can run an in-house bank solution for a BP business using a US funding entity out of London, or vice versa.

Wall Street’s key benefit to us is the integration that it provides. The back office functionality, the FX and risk management and the debt book are all in one place. It is fully integrated, avoiding the risks and costs of data reconciliations.

Around the system, we have tried to build as many automated interfaces as makes sense. From the bottom right, we make commercial payments electronically via Citibank. We have electronic interfaces to our businesses where we make payments on their behalf. We act as a settlement vehicle for inter-company transactions. We bring in our balance and transaction information from the banks into Wall Street electronically. We have an automated interface with the Issuing and Paying Agent that we use for our commercial paper programme. We use SWIFT to have automated matching of FX deals to settlement. Our aim has been to build a series of interfaces to Wall Street to try to standardise and automate wherever it is cost justified.

Going back to the project design, what were your key decisions?

I think a given was that we wanted to create a centralised global cash management model. The economic case for running a centralised global treasury model for a group of our size is compelling. We then needed to decide whether to extend the Wall Street System in London to replace the various platforms and systems that had been inherited from other companies. The trade-off was that it would mean redesigning all the treasury processes in the US. However we were convinced that this short term pain would be more than offset in the long term from the benefits of running with one common platform and one set of processes. The Wall Street system was an obvious choice from our experience from running it in London. We particularly valued the full integration it provides between back office, middle office and front office functions which enables us to make the most of BP’s professional dealing capability.

There was a lot of cash management functionality in the Wall Street System which we hadn’t used before. We did a number of reference visits, prior to taking our final decision. A visit to AIG to see this functionality was very useful and reassured the members of the team that it was robust.

Another key issue was the choice of global overlay bank to use, critical to any global cash management solution. As it happened, BP and Amoco both used Citibank as their global cash management bank. Given the investment in the relationship from both sides, it was the obvious choice to make.

We then involved the key third parties early in the project. Wall Street was particularly important, since the system side would determine the pace at which the project as a whole could move. Similarly we kept our core relationship banks aware of what we were doing, because their help and involvement was also critical.

How did you start to plan the project?

The first ideas developed from within the treasury team. Once we decided to start on our process of change, we held a series of sessions throughout October and November 2000 to develop the detailed steps and core timeline. Two people led this process – one in London and one in Chicago. One of these then became the full-time project leader.

The next stage was to break the main project down into twelve sub-projects, each with individual project leaders. Within each sub-project, the project leaders developed a series of detailed work steps, including their timing, completion and costings. This was complete by the end of 2000.

What sort of advice and input did you get from the Wall Street Systems in the planning stages?

In January 2001, we told Wall Street formally that we had appointed them. We had another session in Chicago with Wall Street in early 2001. We got them involved in the project timetable and to act as a sense check to test whether our plan was realistic or not. That led to a few modifications, but generally the time frame looked acceptable. In retrospect one of the best decisions we made was to have one of the Wall Street analysts based with us in Chicago for most of 2001 as one of the team.

We put a lot of emphasis into planning the project in detail upfront but like all good plans we hit several unexpected problems along the way. Each of these required us to rework the plan and modify the timeline. The most significant problems early on were with the new system. To get the cash management functionality we wanted, we had to introduce a different technology platform on which to run Wall Street. We struggled with this through early 2001 but had overcome these problems by April/May. This was an important breakthrough that allowed us to stay on track with the project overall. In parallel to the systems work we were redesigning our treasury processes to allow Wall Street to go live in the US. It went live in two tranches. On 1^st November, we migrated the BP America entities and, on 1^st December, we migrated the Amoco and Arco entities.

In establishing our in-house bank, we were changing the way that all the businesses in the US were being funded and payments were being made. The main issue was controlling the switch over with the banks to redirect payments and cash transfers to the in-house bank on the go-live dates. It wasn’t perfect but we managed through it and after a couple of days, we had all the gremlins sorted. The second switchover was much smoother than the first.

How about the entities in Europe and the rest of the world?

That was a much simpler process. The issue in the US was scale – half the Group’s cash flows were now in the US of which the heritage BP America flows were a very small proportion. In Europe and the rest of the world the process was phased over the whole year. We had a critical mass (the old BP) where the existing processes stayed the same. From day one of each acquisition we plugged the new non US legal entities into our existing treasury model managed out of London.

How did you keep control of the process?

As I mentioned we appointed a full time project manager. Her role was to manage the process, keep everyone informed as to where the overall project was and manage the interdependencies between the separate sub-projects. That was essential and key to the success of the project

We had a fairly formal project review process on three levels. Every other week, detailed review meetings were held in which each of the sub-project managers would report back on their progress. On a monthly basis there were more formal management review meetings. Every quarter we brought the whole team together for two or three day sessions to look at the whole process in more detail and rework the project plan as required. We also had regular review sessions with Wall Street management to ensure any issues were getting the appropriate attention.

Whilst in the process of change, you also had to continue to manage the business. How did you do this?

For us, the number one priority throughout was to ensure that day-to-day operations continued without mishap. We tried as much as possible to create a separate resource pool around the project and ongoing activities. We also brought in additional resource for the project and tried to lessen the workload of the people who were critical to the project to give them time to do it. Broadly that worked pretty well but resourcing was a constant issue that we always kept coming back to – I don’t think we got it perfectly right. At times we ran it pretty tight, but we got by because it was a very motivated and professional team who were dedicated to delivering. In the end the project was completed on time and we had no mishaps in ongoing operations.

Have you got a vision in terms of the ideal bank account structure you want in each country?

In most parts of the world, our model is to use one transactional bank per country and then Citibank as the overlay bank. The choice of the in-country bank is based on our local needs. For instance around Europe where we have a large retail business we select a local bank to provide the branch coverage that we need. So in France for example, BNP is the local transactional bank.

In the US the model is slightly different because of the size of the market and the range of banking activities. We want, where possible, to get to a pan US solution for any particular activity, using the market leader for that type of business. For example, something we are just rolling out is the new cash collection process from our service stations in the US. Previously we used a variety of different methods and a range of regional banks to collect cash around the US. Having tendered the business we are now rolling out a project called Virtual Vault, with Bank of America. Under this project we are standardising across the whole of the US the cash collection process using armoured cars, centralising the data collection process into a ‘Virtual vault’ This will enable us to simplify the business, improve data quality and reduce business costs. To date we have tendered 4 of the 6 distinct banking activities we have identified in the US. When we complete the process next year we anticipate we will end up with three strategic US transactional banking partners.

What are the guiding principles in the design of your cash management model?

Firstly, our objective is to achieve global pooling of our cash and foreign exchange positions on a daily basis. This is the activity that adds the most value, allowing us to net down the balances and then pass the residual positions to our dealing room to trade out directly into the financial markets There are some parts of the world where exchange controls or tax regimes make this very hard to achieve – China is currently the most material gap in our pooling structure – but wherever we can, we put our global pooling model in place.

We also manage centrally all foreign currency, large or time sensitive commercial payments and receipts for the Group. We do this either by file transfer for bulk repetitive payments or for one-off payments we have developed a web-based system where payment requests are fed straight into Wall Street. We also make full use of the automated payment capability from our ERP systems but the majority of the low value, high volume local payments and receipts we leave to our accounting service providers, because we don’t see we can add much value in trying to do that centrally. The key for us is to ensure that they are efficiently sweeping the local bank balances into the local header accounts so we can then achieve effective daily pooling back into the centre.

How do you monitor the accounting service providers?

We set the overall framework through a fairly rigid set of cash and banking operational policies. We are then involved in changes to the banking architecture and any problems that arise. We also look at how efficiently the cash pooling is working. If cash is left behind, then we know that there is a problem with the process. Lastly we have an internal audit process which checks that the policies are actually being followed.

What do standardisation, simplification and automation mean in the context of BP?

We look to standardise, simplify and automate wherever it makes sense. In general, the higher the level of transaction volumes, the greater are the benefits available from automation. But where volumes are low, there is often little point in automating because the benefits don’t justify the costs.

Let me give you an example from three areas of our activities. Our foreign exchange settlements are almost completely automated now from passing our intra-day foreign exchange positions through to our dealers through to automated settlement. We monitor each stage as it is going along, but as long as nothing is going wrong, it needs no intervention. It is high volume, and it is relatively easy to do.

Commercial payments made through BP Finance are largely automated and becoming increasingly so. Some are brought in as payment files, which can be fed into Wall Street and then onto Citibank for final payment. However within the group, we still get one-off payments coming in manually. At the moment, we are trying to use our Internet process to automate them because the volume to cost trade-off means that it is worth doing.

In other areas, it is still most cost effective to handle the activity manually. For example, when purchasing steel for a rig, our business units will consider the currency in which the provider prefers to quote. So if they want to price in Korean Won, we will evaluate that price and if appropriate we will take the FX risk and manage it. If that happens, we have to put in place a tailored hedging programme for that business unit. This is very labour intensive, but very value creative.

In essence, we will automate where we can, when it is cost effective. There are two benefits from automation. Firstly it frees up resource that can be used elsewhere to add value. Secondly, from an operational risk point of view, automation mitigates risk. If you have people keying in data manually, you inevitably will get errors.

I think we push automation as far as we can, but if you make it an end in itself, you can end up with the wrong result.

What have you learnt from this project?

The first thing is that with a project as complex as this, you cannot communicate enough. When something changes, it has implications in many other areas.

Secondly, in retrospect a project like this was a fantastic way to create a new global team. Through developing together a shared vision of where we wanted to get to and then going through the highs and lows of delivering it, it really did fuse together a group of individuals from different heritage companies into one new organisation – one virtual treasury.