The Moreira Chronicles: Bangemann and Zabel on Shared Services Implementation and Operations [Part 5]
Over the past year, Pedro Moreira has written a series of columns for SSON summarizing his experience in rolling out an enterprise SSO model to a subsidiary, emphasizing the pros and cons of this approach.
Following the conclusion of this series, Pedro interviewed two well-known practitioners – Tom Bangemann of the Hackett Group and Kai Zabel of Heraeus Group, both highly respected practitioners in the field of Shared Services, with decades of implementation experience. Over the next two months, we are sharing a transcript of these interviews right here, covering the role of the SSO, its evolution and future trends; implementations and operations; and a discussion around GBS and new robotic technology.
Left: Pedro Moreira, Shared Services Expert
Middle: Kai Zabel, Head of Shared Services for Accounting, Heraeus Group
Right: Tom Olavi Bangemann, Senior Vice President Business Transformation at The Hackett Group
Shared Services Implementation and Operations
Pedro Moreira: When it comes to implementation, some companies prefer lift-drop-change, others prefer lift-change-drop. From your experience in the multinational environment, which methodology is best? Does it depend on the organization? Does it depend on wanting to show results fast? What is your view?
Kai Zabel: I can share the insights from our organization here. Our migration into shared services is still ongoing and is running more or less in parallel with the implementation of one single ERP system, globally. With that situation, we decided, from a strategic point of view, to move entities with their accounting into the shared service environment prior to the system migration in order to move the effort for doing the system migration into the shared services environment.
Having said that, everyone more or less came to the same conclusion: that lift-drop-change is the right approach for us because the change will come with a single ERP system anyway, so why make the effort prior to moving it into the shared services? Wouldn’t make sense and doubles the effort. For us, in our situation and with our strategic roadmap in this area, it makes more sense to lift-drop and change afterward, when the system is there.
Tom Bangemann: If you look at the numbers on that, there is no clear right or wrong. Companies will select different ways of doing this and different combinations. Most, about 2/3 if I remember correctly, lift and drop or lift and shift, then change the process, we call it lift-shift-transform. It’s the same logic, and that’s what the majority does. However, there are others, a significant minority, that try to do it the other way.
Normally, the main driver is that you have a business case, as I pointed out earlier, that shows the benefits that you’re getting out of this. Therefore, when you run these migrations, you normally run on the basic logic that if you try something small, if something goes wrong the damage is not too big. But after that you quickly move into the big volumes, the business is going to materialize quickly and, as most shared services move quickly into a lower cost location, you are going to get wage arbitrage, so the business case looks better than if you do it slower or if you move big amounts of volumes later. So, the normal way of doing it, just to make the business case look good and be able to scoop the benefit, is to move a big volume if possible, as quickly as possible. That’s the best way to lift and shift and then you transform when you have everything in the center. Also, it is typically easier, to do some change work or redesign work on a process if you’ve got all the people who deal with this in one room. Otherwise, you need to do it in a dispersed environment and that is very difficult to do.
There are pro’s and con’s and it depends on who you ask. If you ask the head of the shared services center, they often say “I’d like to get the processes in after they have moved to the new ERP system and new process systems," because then they just take them in the same design and just add capacity. To take on work like that is easier. It's much more difficult to do the actual transformation job.
PM: How important is a mandate for the reorganizations of activities on a local level? Are many companies enforcing this mandate? How are local organizations reorganizing themselves?
KZ: From a theoretical point of view, and I think that is somehow backed up by practice, one of the biggest mistakes which could happen is that you take those things away from the local organization. Leave them alone and do nothing. That contains the risk that the processes break and then the whole thing doesn’t work. So from that point of view, it needs to be clear to everyone that changes will take place at the local organization, in addition to just taking away activities so that they need to reorganize.
If it’s the Shared Services Center that should be the one reorganizing the process, that’s a different question. From an organizational point of view, from a company perspective, it needs to be clear to everyone that a new set-up of the remaining organization is required and will be very likely to happen.
PM: So you don’t see the shared services entity as leading the change in the local entity?
KZ: Not necessarily. I know that approaches exist where the responsibility for the whole process, end-to-end including the part which remains locally, moves into the GBS organization. That includes the reorganization of activities. But is that necessary? If you have an organization and you take a significant portion of activities, normally you will not stay with the same number of people and you need to reallocate the remaining activities to other persons. These people need to be trained and they are facing a significant change in the remaining organization, as well. In order to make sure that the process is running smoothly, someone needs to take care of that. Depending on the approach, it’s either local management who takes responsibility or it is the GBS organization, if it takes over the responsibility for the remaining local activities as well.
TB: You’ll have different solutions on that. Obviously, a mandate question is always a good one. You need a mandate to run this type of project in general and to get there is always a battle. I can tell you that from experience, it is always like that. It’s not that simple because ultimately, like Kai said, you’re taking away activities and workload and you’re effectively letting people go. One person is taking away maybe 100 people out of someone else’s functional scope or out of their teams and many people still think that the more people they have reporting to them, the more important their job is. Coming from that type of thinking, they are often refusing to let go of most of their “troops”.
It is a strong political battle up to the point where you set up anything like a GBS. An accounting Shared Services center maybe still works, because you’re within the function and the CFO can basically decide how within his or her function work should be done. You’ll still have the battle with the locals about moving things, but at least it is within the function. But when you have multiple functions and multiple regions and they have multiple business units, then it gets really messy and it can be quite a nasty battle.
Ultimately, you have to end up with somebody having a mandate to do certain things. But in reality it is never black and white. You get a mandate but, of course, there will be lots of people waiting to shoot you on the way. It is like in politics: you have to somehow maneuver through it.
This is what happens in most multinationals: Initially you are so busy with trying to get this thing done that you really focus strongly on what you are centralizing or consolidating. That’s the center you’re responsible for, setting it up and running it, and it must work. That’s your biggest interest, it has to work. What comes out of it has to be decent, quickly and it needs to prove the benefits in the business case. That’s the main target. Therefore, the local side is often neglected and is left for others to reorganize on purpose, also for capacity reasons, and because it is simply not the highest topic on the agenda.
Later, people realize that if they want to run end-to-end processes successfully, then they'll have to get those locals aligned too. From a governance point of view, when you get into the GBS model later, you go through a rethinking process and say – “Well, yes it does run. Maybe it can run better if I have the local people who are still out there not reporting into the local MD solid line, but report into GBS solid line, and only dotted line locally, to office or unit.” That’s what we see in most more mature GBS organizations.
Again, I don’t think there is always a right or wrong. There are options and reasons why certain options and certain combinations might be more or less promising.
Continued Next Week...