Finance Roll

Q: John, let's begin with a bit of background. How did you get to your current role?

A: My background is finance. I qualified about eighteen years or so ago, and I've spent most of my career in finance, management accounting, statutory accounting business analysis etc - I moved around quite a bit. I sort of fell into shared services, I guess, about eight or nine years ago at Reuters, where I was asked to set up a pilot for the financial shared services area, established that and ran it for a couple of years, expanding it throughout the head office and UK area. Then as part of the shared services management team, we built a global shared services model based around five regional service centres. I did some change management at the time, bringing in the ERP and the PRP, then decided to take a job that concentrated on the transactional area. I had never actually done that sides of the work and I wanted to get a full spectrum of the shared services work.

We established the shared service centre in the UK, and I ran the transactional shared service centre. The plan was to set the five regional shared service centres up, and then to move into a global model. So, whilst I ran the transactional side for two years, there were various discussions taking place as to where we should build the global service centre; we eventually settled on Bangalore. I was asked to head up the global design team, to build the model and the design around the Bangalore SSC. So I went over there for a bit, did some benchmarking, recruited a management team, and we re-designed all of the processes in the five shared service areas. It was quite interesting; although they were only established two to three years earlier, they diversified so much (even though we had a central core team that was supposed to keep all of the processes standard, each service centre had diversified) and it was a case of going back in, understanding the gaps and building the model, and then implementing it. We successfully implemented that in 2005. Then at the beginning of 2006 I joined Citi.

Q: Since then you've been partly responsible for a revolution in Citigroup's procurement supply operations. Tell us the story of that - what has changed?

A: Sure, I played a part. I'm not sure how big a part because I have only been there for two and a half years. This actually started five, six years ago with the implementation of the ERP system globally; it was predominantly put in in the US, which makes up approximately two-thirds of the people in Citgroup - so there are well over two hundred thousand people there. It was re-implemented across the larger countries across EMEA. (One thing I would say there, in hindsight, is that we actually changed Oracle quite dramatically, and that's had an impact on the countries we can roll out to, purely based on cost, because now the maintenance and the implementation is far more difficult than if it was just a delivered system.)

So I entered two and a half years ago, when Citi had been extending the coverage of PP - we actually call our Oracle system PP, as well as the process - and at first it was a case of extending that further, we had the systems teams to roll it out. Then it was a case of building the procurement - transactional procurement - and payment services and we started doing that by building a regional process centre in Budapest.

Q: How big is that centre now?

A: Well we started a year ago. We have now got about 120 people there, and we are still moving the larger countries there; we expect to have double that amount by the end of the year. Fundamentally we've moved out the transactional procurement, our accounts payable, our expense compliance, and we have moved some HR functions there as well.

Q: How far have you succeeded in freeing up working capital?

A: I think we are just starting. The benefit of moving into Budapest was that we could get some really good quality staff. We've now bedded down the service centre, we have got through the stage of the labour arbitrage, cost savings and so on. So I would say that we are now just starting on the process of putting up working capital. For example we have a prompt payment discount team; they have been in there for about four or five months and we are ahead of the game on the realisation of our prompt payment discounts. In what is just a pilot at the moment - we are targeting the UK first because it's the largest country in EMEA - we're working very closely with our strategic source department, who are negotiating the deals, and then we have a specialist team based in Budapest who are realising those prompt payment discounts. I think it's early days. I think four or five months into it we have hit the prompt payment discounts via the purchase order route. We are trying to accelerate the payment on account route, where we work with various suppliers or categories that do not fit in with the PO profile. That has worked fairly well.

Q: What about integrating procurement and AP: how long has the process taken, is it still ongoing, and what does it involve?

A: That was quite interesting, because in Reuters I'd integrated the procurement and accounts payable functions when I set up the shared services. When I went to Citi, although they were part of a very large shared service organisation, they were still independent. It was only when we set up the SSC that we co-aligned the transactional procurement with the accounts payable team. That was about a year ago, and that proved really successful - so much so that they have actually now made that a global model and about four months ago that was globally transitioned across America and the Asian countries as well. So that had been a huge success. It makes a big difference: the team work better together, we build up the subject matter expertise. The real quick win is the problem resolution: we solve problems very quickly together.

Q: What were the biggest obstacles you encountered with the integration of procurement and A/P?

A: I think it was selling it to the business. We tried to sell them the whole package; we implemented the no-PO-no-pay model, at the same time that we rolled out the service centre, and at the same time we integrated procurement and A/P. The biggest obstacle in Citigroup is that we don't mandate anything in Citigroup: we negotiate everything with our business clients, and the biggest obstacle was getting them to buy into it. That took a lot of discussions.

Q: Why?

A: The thing about banks is, when you go to them and say "if you do this you save £100,000" you're talking to investment bankers who are dealing with millions everyday, and they don't really care! Also I think they didn't like the idea that there was going to be more self-service in the process - they were going to have to requisition by the Oracle system. Before, they just rung up their suppliers, who they wanted to deal with. If you are an approver within the business, there's a misconception that you can go and order on behalf of the business. That's not the case: we had to work with them to get them to really understand that we wanted to control who they dealt with. Once we did that it was up to them to control how much they spent with their client.

Q: And what about the importance of KPI's?

A: KPIs are hugely important. You ned to understand that they they also evolve along with the project (we're looking at this as a project even though we're out of the new phase now). As I said before, it was very difficult and you had to negotiate every step of the way; KPIs were vitally important as they reflected any changes we had on the performance, cost, speed, and accuracy. In the long term, it was so important to show the quick wins, and generally it is a lot easier to get agreement, to take the next step forward, if you have proved to be successful in the previous step.

We tried to have meetings where possible - if not, we would issue dashboards, or email updates - and while not wanting to bombard our customers we constantly tried to show that we had produced this quicker, or that was better controlled, and this was cheaper. KPIs made a huge difference as we went along, as we could prove that we were successful at various phases.

Yes, we had problems: you always have problems, moving to a shared services organisation, and putting people through a standard routine with procurement and accounts payable. But KPIs were hard facts; you'd have people complaining, or they'd get word of mouth, where one person wasn't happy and everyone would start to moan. The KPI's were the one way that you could prove in black and white that we were improving cycle-times, we were improving accuracy, and we were saving money for the company.

Q: Who drew up the KPIs?

A: I worked very closely with the guy heading up the procurement transition: we had both previously worked in Reuters,and we both joined Citi together. We had a fair idea of the KPIs we wanted; we sat down with the project team and we developed those over a period of a couple of months. KPIs change as you sort of evolve through the project: first of all it is just the basics - how many and how accurate - and then you change those.

Q: How important was leadership buy-in?

A: Hugely important. People don't generally want you to do this kind of thing: you're talking shared services, you're talking centralisation, and you take away people's power.They like to order what they want, when they want to order it; any time there's a problem, people jump on it - and they will highlight the issues, the errors - so from an internal point of view leadership is crucially important to keep people - both the project team and the operational team - focused. It's also crucial to go out and influence these people, your customers; you need to have someone they are going to listen to, just have the vision and drive to push things through. I needed, many times, senior sponsorship.

Q: What would you do differently next time round?

A: I mentioned the ERP: I would make changes. Other than that I think the one thing that always catches us out is what is left in the country rather than what you have moved. Everyone concentrates on what they want to move into the shared services area or the procure-to-pay area, and they don't look at what's left out in the country. They don't take as much time on that; that's always a problem. I think as well that there are always exceptions that cause the problems. You can sit there and write up the process flows and the procedures, until your hands are sore - but there's always ten percent of any process that is going to be an exception. It's understanding those exceptions that's important, because that's what's going to trip you up afterwards.

Q: How far can Citi's experience be a marker for other companies, in particular smaller institutions?

A: Great question. I don't think that there is any barrier to any company making changes. Ok, Citi is a huge company - we've got 52 countries in EMEA, and therefore we have the funding etcetera to move to a regional service centre. But you don't have to move region: you can do it within country. You don't have to buy huge Oracle or SAP systems; there are plenty of ERP systems there that you can use. I think it's just about the basics: even re-structuring your department is fairly easy to do. It doesn't have to be on a huge, grand scale to save significant money. You know, Citi with 370,000 people is huge and Reuters with 14,000 people is not small, but they have both achieved the same goal: I think that smaller companies can do that. National companies can do it - it doesn't just have to be international companies either.

Q: Finally, what is the most important advice that you would give to anyone at the beginning of their shared services journey?

A: There is no order on these, so I'll just waffle through...

Always understand what the end goal is; even if the project has changed you have got to keep an eye on the end goal. For example at Reuters, we knew the end goal was going to be setting up the regional service centres and moving them to a global service centre. Within Citi the end goal is setting up a regional service centre, and we're looking to add the value; so different outcomes if you like, but we are aware of what they are. Always keep them in mind, because you can very easily get waylaid.

Set targets along the way, short-term. Once you can prove you have hit your previous target and have been successful in that, it is a lot easier to get support sponsorship to get to the next bit. Don't look at it like some huge project: break it down into smaller chunks.

Keep the system as vanilla as possible, it is easy to roll out and far easier to maintain an upgrade. That's a massive one I think.

You need to have strong support from senior management, otherwise you will be there negotiating forever. At Reuters, we had a bit of a burning platform; it was very easy with the MD and FD onboard, and it has taken a lot longer in Citigroup. We're not struggling in financial terms, but it is a tough time for banking; all of a sudden it becomes much easier because the senior management is saying "let's do it".

Build a strong project team. What I like to do is build a team that is split between those that have expertise in engineering, and those that know the business. So for example in Reuters, we used consultants when we first built the ERP and set up the regional shared services, but used wholly internal people for the global re-organisation, because they had been through the pain. You need to have that team that know the business. You don't want just engineering people, you need to know the business as well.

Only migrate standard processes and systems: that doesn't mean that you have to standardise them before you migrate, but don't take in different systems and different processes. What you generally find is once you have actually proved that you can be successful in certain things, you get a lot of customers saying they want to move this and that. Make sure what you move ties in with your strategy. Be ready to say no to a system or process if it doesn't fit in with what your strategy/plan.

You have to make sure that roles and responsibilities are defined from the kick-off wherever you are moving to. Too often the sending parties just "dump and run", particularly if the outcome is that they leave the organisation. That's tied in with SLAs: to be honest when I started many years ago, I thought they were just a piece of paper to go through. I've learnt, though, that they're vitally important because - particularly when you are starting - they can help to protect the new SSC staff. Once you've got them signed off it gives you certain leeway. You're going to make mistakes, but they help you against customer complaints. They also help to remind other parties of their responsibilities. They're really important.

I think lastly, as part of the process, make sure you go through everything in infinite detail: walk through the process flows. We have conference pilots when we move work, and we try and lift as many exceptions as possible because as I said they are the ones that catch you out.