Small Bangs: Planning & Implementing Shared Services Part II

To view Part I of this feature, click here 

Mark Judd: In the UK we didn’t move it in steps, in as much that we didn’t bring in processes one at a time. We designed one proposition for every part of HR, and we brought in over a period of 8 months, we brought in every part of the business, one after the other, usually in windows of three or four weeks, just so that we could cope with the additional volumes as they came in. By the end of that period, we delivered all transactional and all significant parts of the advisory service to the business and we knew that because we’d turned off all the update access to everybody else apart from ourselves, so you couldn’t do anything unless you did it through us. You couldn’t recruit people, you couldn’t change their terms and conditions, and you couldn’t alter their pay structure. So we’re pretty confident that we brought all of that activity in during that period, now that the doors shut there’s nothing from that point of view left in the business.

Globally we have got more than one platform at the moment; I think that we are moving to a single ERP. I think that the difficulty to some extent that when you exist as a shared service certainly, I think it is true in finance and HR, your very existence sends a message to the rest of the organisation that things that were difficult to before now should be easy. And say for example that information on how the organisation is constructed, how many people have got the capability or what is their career history, immediately becomes expected because you exist as a shared service. I

f you do not have a data depository to share that data out, your credibility is really difficult to maintain for any length of time. One ERP or one non ERP is probably not in itself the deciding factor, it is about having a platform that you have confidence in, whether it is one system or multiple systems, you know that you can get to the information; you know that you can manage the business processes effectively. I think that if you are dealing with a whole multitude of different payrolls, a whole multitude of different data storage systems, then you have got a shared ceiling, not a shared service centre.

Chairman: I agree, efficiency comes from IT and therefore running ERP. But again an example would be accounts payable. I have run shared services that run on lots of different ERP systems but …people talk about being on an ERP system and I would like to see a multinational company that every single company in the group is on the same ERP system on the same version configured to the same level because I still haven’t see that company. I think it should be a holy grail that you must have a standardised ERP system.

My view is quite clear, the difference about waiting – different behaviours – different cultures. If you wait they might do a little bit of customisation and do things a little differently. My preferred way would be doing it together, you know standardising the processes, standardise the ERP system and so on. But, then you get this thing where you are linked with IT, are you are putting the dependencies, there can be things that delay you, we can also delay the IT. So the bigger the project, the riskier it becomes, do you have the trust in your IT department, the implementation department? What risk are you willing to take?

Mark Judd: I agree with you entirely, I think that it wasn’t a scenario that we faced, because we already had the ERP in place, and the problem we faced was that it had been rolled out before we had a shared service centre. So one day one when I joined the organisation without the shared service centre, one of the first emails I got was complaining about the data. I just got here, I hadn’t got my coat off yet, and the first few emails are coming in saying how appalling the data is, and I made it very clear when I joined that I will take responsibility for the data, I will do that, and I will do it from today. My job now will tell you how I cannot give you any confidence in the data until the shared service exists, because I don’t know what people are putting in, and how they are being trained, the controls aren’t there, the monitoring isn’t there. So I can tell you exactly what I can’t do for you with confidence, and now I will tell you how I can get to a position where I can tell you what I can do for you with confidence. But I can only do that once I have brought in that capability under my management control, and I have got some assurances in the way that things are coming in, are the ways that they need to.

You don’t have to have the fully fledged shared service centre necessarily, what you do want to do, certainly when you launch the ERP from a HR point of view is, own that middle square around the data input side, and manage how it goes in, and find ways of channelling that into a small team at least as a start point. To make sure that it doesn’t end up being a corruption of that .

Christian: One of the main reasons of doing big bang in Copenhagen was actually to get control of  the infrastructure, that was both the ERP, we ran at that time three different ERP systems, which was a very big cost for the company. But, also at the same time, into big investments in IT, a new server, a new server platform, and new identity management systems. And we could see that there were very big benefits in the shared service centre, in that it got control of these investments, and made sure that this was a common system and a common process where everybody agreed what to do, that was implemented in the City and not four or five different systems in different departments. So I think the main reason is to get to the shared service centre, to get control of the investment, and to make sure that everyone understands what the target is.

Chairman: I do want to raise another point that is not very exciting or sexy and that is ‘master data.’ Both for finance and HR - one of the conditions on how fast you can do it -depends on how good is your data. 

Mark Judd: I would agree with that, there are three things that make me cry on a Monday morning. One is someone sending me an email complaining about the car parking in the building, another one is about the fridges in the building, and the third one is the CEO asking for data that I know we simply can’t report. Anything else I can cope with.

Attendee: Would any of you advice running a pilot scheme first before going fully live with an implementation?

Mark Judd: I had an interesting experience when I joined Rolls Royce, the team that had been putting the shared service programme together prior to me joining talked about doing a pilot, and I asked the question of what do you mean by a pilot? And they said a pilot, and I said well I can define a pilot, is it a pilot show, like on the television, if people like it they will make a series out of it? Because if it is, I am not up for that, because I have just left the job as I’m going to implement shared services here. So the pilot as far as I am concerned is like the pilot light on the boiler, it is the first spark that tests out the model. Because it is going to light up the rest of the organization. It is the first steps into getting the thing working properly. And I remember that debate raged on for quite a while, because there certainly had been the perception when we talked about the pilot, it was not a done deal that we would be going on beyond that. And I said well then let’s not bother, because you can kill a pilot easily, you can make it not work.

Those people who are not well disposed to this form of change can find dozens of reasons to complain to put processes at jeopardy and so forth. The whole purpose of the pilot has got to be as a test mechanism to get the whole thing working, and that’s what we did, we planned every launch sequentially with dates around it. And the first launches we called the pilots, they were slightly longer, they were...we had some go and no go rules around them and the core spirit and whole intent of what we were trying to do was make it work, and I know that that perhaps sounds philosophical, but it had a very big profound impact on the project, because we charted our whole role out from that point onwards. I mean we had to leave a degree of flexibility, if we felt it was a complete crashing disaster then we might have to rethink again. But I think we put the a lot of responsibility on ourselves, on the function that it was going to work, and those pilot activities were mechanisms to draw out the kind of things that could go wrong that we would fix so that latter implementations would work more effectively.

Chairperson: Christian, you have done one Pilot?

Christian: We did one pilot…yes. If we did more pilots, I think people would have had the same argument, people would have killed the pilot, saying that this was not a good idea, can we stop now.