.png)
The First Three Decisions Before You Redesign Your GBS
- 11 minutes ago
- 4 min read
Every GBS AI programme we've watched stall in the last eighteen months traces back to the same place, and it isn't technology, vendor selection, or budget. The stall begins with a decision that was never properly made before the redesign work started, and the consequence only becomes visible once the programme is too far along to reverse without significant cost.
The teams running these programmes are capable. The strategy slides are credible. What's missing is a small set of foundational decisions that need to happen before the structural work begins, and that most organisations defer because the conversation feels uncomfortable. There are three of them. Think of these less as a checklist and more as the alignment a redesign actually sits on. Skip them, and every structural choice gets relitigated later.
Decision one: what problem are you solving
Most leadership teams assume they've answered this. They haven't. What most GBS redesigns carry into the room is two or three competing problem definitions sitting side by side, none of which have been forced to reconcile.
One stakeholder group wants to reduce cost. Another wants better data quality from finance. A third wants AI capability because the board asked for it. Each is legitimate, but they don't produce the same design. A GBS solving for cost makes different structural choices than one solving for data quality. The technology selection, the role definitions, and the success metrics all diverge. When the definitions never reconcile, what gets built is a hybrid that doesn't fully solve any of them and that nobody quite owns.
The work here is to be explicit about which goal is primary and which are secondary, without ignoring the others. Write that hierarchy down somewhere people can refer back to when later decisions create tension. The hierarchy doesn't constrain the design. It accelerates it, because every trade-off that follows has a reference point.
Decision two: what will you stop doing
Every GBS redesign has a scope conversation, and most have the same shape. There's a long list of what the redesigned GBS will do. There's a shorter implicit list of what it won't do. And there's a third category that almost never gets discussed openly: the things the GBS is currently doing that should stop, but that nobody has been willing to name.
Legacy processes that exist because someone asked for them five years ago and no one revisited the question. Workarounds that became permanent. Reports that get generated weekly because they always have, even though no one reads them. These quietly consume capacity during implementation and turn an ambitious redesign into a busier version of the existing function.
Our Head of Digital, Chang Te Sheng, has been making a similar point about job descriptions, and the same question applies just as cleanly to processes: "If I were writing this for the first time today, knowing what I know about how the work has changed, would it look like this?" Most leaders, asked honestly about their current service catalogue, will say no. The redesign is the opportunity to act on that answer rather than absorb the existing catalogue into the new model by default.
The decision is harder than deciding what to build, because every legacy item has a stakeholder attached. It's political as much as operational, and it needs to happen before the redesign begins rather than as a series of small fights once design work is already in motion.
Decision three: who decides when the design creates conflict
GBS redesigns create conflict. That's not a failure of the programme. It's a feature of doing work that genuinely changes how the organisation operates. Conflict surfaces around which processes move into the GBS, how performance gets measured, and where the boundary with business units sits.
Organisations that handle this well decide, before the redesign starts, who has the authority to resolve these conflicts when they appear. There's a named sponsor with real decision-making power, not nominal seniority. There's a governance structure that resolves issues in days rather than weeks. There's clarity about which decisions the programme team can make on its own and which ones need to escalate, and the escalation path works.
The ones that don't have this clarity find their redesign slowing to the pace of consensus, which is rarely fast enough to maintain momentum. The team spends more time managing alignment than building the operating model, and the programme's credibility with the executives who funded it starts to erode.
Decision rights live as a working agreement about how this group will function when it disagrees, not as a governance document filed somewhere. That agreement needs to be in place before the disagreement arrives.
What these three decisions produce for your GBS redesign
The pressure to start redesigning around AI is real. Boards are asking for AI strategies. Finance functions are being benchmarked against peers who appear to be ahead. Vendors are arriving with decks that promise to compress the timeline. The instinct is to start with structure: draw the new org chart, choose the platform, define the use cases, begin the build. It feels like progress because it produces visible outputs quickly.
The redesigns we've watched come apart are almost always the ones where these three decisions were never properly made, not the ones where the structural work was wrong. The team built quickly, hit the first real conflict, and discovered that the problem definition was contested, the scope was unclear, and no one had the authority to resolve either of them in real time.
These three decisions don't produce a deliverable in the traditional sense. What they produce is alignment, which is the only foundation a redesign can be built on. The conversations are uncomfortable, but they're meaningfully shorter, and meaningfully cheaper, than the conversations you'll have if you skip them.
AGOS Asia is an AI-first digital GBS transformation partner operating across ASEAN. We work with finance and shared services leaders to rethink, redesign, and rewire their operating models for the AI era. AGOS GBS Summit 2026, the ninth edition, takes place on 10 September at Sheraton Petaling Jaya. Visit agossummit.com for more info.
Comments