What Should Your Shared Services Programme Fix First?

Global Business Services (GBS) brings functions together to support growth, control costs, serve customers and manage risk. Making that work means choosing improvements that help employees do their jobs and the business achieve its goals. There is more to do than anyone can fund at once. On a walk through the desert, Ashley and I explore how service data and employee experience help identify a worthwhile first step, and how measuring the result builds confidence and a stronger case for the next investment.

Keyvan: Why are we going all the way round? It’s right there.

I pointed towards a low ridge beyond the trail. We had left Las Vegas the previous afternoon and were walking through the desert west of the canyon. It was seven in the morning, early enough that I still considered myself reasonably outdoorsy.

Ashley looked across, then carried on along the path.

At the next bend, the ground opened up. A dry gully cut straight across my proposed shortcut, with loose rock down both sides. From further back, the near edge and the far edge had looked like one continuous surface.

Keyvan: Couldn’t see that from back there.

Ashley: No.

We followed the bend. I had several other ideas about the route, which I kept to myself.

Keyvan: I’m still thinking about shared services. We bring HR, finance, procurement and IT together to help the business grow, control costs and serve customers. Then we try to use AI and discover how much we’ve left unresolved. The data, the processes, who can decide what. How do you put all that right without taking the whole place apart?

Ashley: Start with something the business needs to do better. Find out which services are getting in the way. You can make progress there while you work out what else needs to change.

The promise of Global Business Services, GBS, was straightforward enough. Making it happen across functions with different budgets and priorities was where I kept getting stuck.

The trap was easy to picture. Each function has more work than it can fund, so it chooses its own priorities. Projects finish, reports improve, but the business still struggles with the things it needed help with. Confidence weakens. The next request for investment gets a harder hearing. With less room to improve, the service teams fall further behind what the business needs.

I could understand how people got there. I wanted to know how they got out.

Keyvan: I’d start with whatever generates the most tickets. We already know where the service desk spends its time. Automate some of that and we should have a saving.

Ashley: We might. What are those people trying to get done when they need help?

I had an answer about the service desk’s workload. I knew less about the work on the other side of the request. If we handled it faster, the employee might get back to their job sooner. That was useful. But if the same difficulty interrupted them again tomorrow, we would still be paying for the interruption.

Keyvan: So we could make dealing with the requests cheaper and still have people coming back with the same problem.

Ashley: Yes. Look at what keeps making them ask. Then follow the consequence. If someone helping a customer has to stop and find support, the customer waits too. The employee’s difficulty gives you a connection to the business result. You need that alongside the ticket count.

That was a more useful way to examine employee experience. Ask what somebody is trying to accomplish, what makes it difficult and who else feels the effect. The person using the service can explain where they struggle. The customer-facing team can explain what happens afterwards.¹

I had been looking at the situation through IT’s spectacles. Everything was labelled in terms of applications and requests. The employee was trying to do a job. We needed to connect the two before deciding which change deserved the money.

Keyvan: Talking to people makes sense. But everyone has a complaint. How do we turn that into something we can make a decision on?

Ashley: Put their experience alongside the records. Service requests, recurring incidents, application performance, the systems and access their role depends on. Look for patterns across them. Which difficulties keep coming back? Who loses time? Which parts of the work are affected? Then check what the analysis suggests with the people doing it.

The records tell us how often a problem appears and how much support it consumes. Application information helps establish what was happening when the work stopped. Employees can explain the workarounds and interruptions that never became tickets. Combining those sources gives us a fuller starting point than any one report.²

It also makes the gaps visible. If we cannot connect a recurring fault to the work it affects, that is something to establish before claiming a return from fixing it.

Keyvan: This could become a fairly sizeable exercise in its own right.

Ashley: Keep the question specific. Choose a group of employees and a business priority. Use the relevant data to establish a baseline, then investigate the recurring difficulties. Where information is missing, collect enough to test the explanation. You need evidence you can act on.

I could see a useful first discussion taking shape. People from the business explaining what they needed to improve. Service teams bringing evidence of where the work was being interrupted. Both looking at the same problem, with something more substantial than a list of complaints.

Keyvan: And we look for the lowest maturity. The biggest room for improvement.

Ashley: That helps you find opportunities. Then weigh the effect on the business against the effort and risk of making the change. Something can be badly run and have little bearing on the priority you’ve chosen. Another improvement may help a lot of people do important work, and be achievable with the resources you have.

We were back to the four questions from the drive: growth, profitability, customers and risk. They gave us a way to judge the opportunities the analysis found. Frequency mattered. So did the consequences, the people affected and whether the change could actually be delivered.³

Access that works consistently. A recurring fault that is finally removed. Support knowledge that employees can find and use. These are familiar service-management jobs. Now we could explain which work they would help and why one deserved attention first.

Something moved across the trail ahead of us.

Ashley stopped. I stopped too, leaving him a little more room than was strictly necessary.

The snake took its time. For once, so did we.

Keyvan: Do you know what kind that was?

Ashley: No.

I was comfortable leaving that particular gap in our knowledge.

Once we were moving again, I came back to the question that had followed us out of the bar.

Keyvan: We’ve found something worth doing. IT may have to pay for the work, while another department gets the benefit. We’ve still got to get past that.

Ashley: Yes. The people who need the result have to help make the case. Agree what should improve, who needs to contribute and how you’ll recognise success. Include the cost of making and supporting the change. Then you have a specific decision about a manageable piece of work.

That was a funding conversation I could picture. The service team could explain the change and the effort. The business team could explain the value of the result. Finance could help settle the funding and the measures. A smaller scope made the commitment clearer. Someone still had to make it.

Keyvan: And we need to be honest about the benefit. Giving people time back can be valuable. It might let us handle more work or look after customers properly. We shouldn’t call all of it cash saved.

Ashley: Agreed. Establish that before you start. And keep the wider dependencies in view. Some improvements will need substantial investment. The first step needs to be useful on its own and fit with the services around it.

This was a practical test for GBS. Could the functions agree to do something because it helped the business, including when the effort and benefit sat in different budgets? The same conversation would be needed wherever those functions reported.

The sun was properly up now. I took off my fleece. Ashley found room for it in his bag without comment, which somehow made it worse.

Keyvan: Suppose we’ve made the change. How do we know it has done what we hoped?

Ashley: Go back to the baseline and the result you agreed. Are people completing the work with fewer interruptions? Has waiting or repeated effort reduced? Check comparable work, because demand can change. Ask the people using the service what still gets in the way. And check whether they are using what you changed.

I could imagine the awkward review where the new process worked perfectly and everyone was still ringing the same helpful colleague. We would have to find out why. Perhaps the new route was difficult to use. Perhaps it missed the urgent cases. Perhaps nobody had helped people get comfortable with it.

That preparation belonged in the work and the budget. The people affected needed a part in shaping the change, help using it and somewhere to raise the things that still failed. We would need evidence that it had become useful in their working day.

Keyvan: Then we take the result back to the people who agreed to fund it. Show what changed, what it cost and what came back. That gives the next request a better starting point.

Ashley: Provided the result supports it. Measure against where you began and use relevant benchmarks to judge the progress. You might extend the change, improve it or decide something else now deserves attention. Review the business priority too. It may have moved while you were working.

This is the discipline behind Value Adoption Services: a data-led improvement plan, tied to business priorities, with adoption and a review of the value built into each step. A measured result gives the next funding decision something firmer to rest on. The plan develops as the evidence does.

I had been thinking of alignment as something agreed at the start of a programme. Here it would get tested every time we chose the next improvement. The business would help decide what mattered. The service teams would show what they could change. They would come back together to judge whether it had helped.

That was how the gap could start to close. Each side would understand more about the other’s decisions, with a result in front of them to discuss.

Keyvan: And the AI exam?

Ashley: You’re doing some of the preparation. Understanding the work, improving the data and settling the decisions for the services you are changing. That gives you a better basis for deciding where AI can help. Test its contribution against the same business result.

The car came into view. I had started the walk wondering how much of an organisation we would have to take apart. I now had a question I could take into the next meeting: what are our people struggling to get done, and what does the evidence tell us we should change first?

Ashley handed back my fleece. I put it on the back seat and asked whether we had time for breakfast.

Keyvan Shirnia is Chief Revenue Officer at Fusion GBS.

Ashley Gionnotti is the ServiceNow Technical Delivery Lead at Fusion GBS, based in London.

This blog is part of The Six Critical Capabilities series. To find out where your service management foundations actually stand, the Fusion GBS scorecard gives you a benchmarked baseline in five working days. It is the front door to Value Adoption Services: use the data to find low-maturity quick wins, link the first improvement to a business outcome, secure modest funding, implement it, measure and benchmark the value, then use the evidence to support the next step. Details at fusiongbs.com/service-management-scorecards