.png)
From Assessment to Action: What a Real GBS AI Roadmap Looks Like
- May 18
- 4 min read
A readiness assessment tells you where the cracks are. We’ve written about what it actually finds: process maturity that varies by market, data quality nobody had measured, governance decisions that were never assigned. Most GBS leaders who run a real one come out of it with a clear, uncomfortable picture of their operational baseline.
Then the picture sits there.
Three months on, when we ask what’s changed in the operation, the answer is usually nothing. The assessment was treated as the conclusion of the work when it was only the preparation for it. What’s missing isn’t more diagnosis. It’s the two decisions that turn findings into a roadmap that actually moves; who owns the first redesign, and which process it should be.
The processes are not what the assessment named them
The assessment already established that a process and its documentation are different things, that Accounts Payable in Manila and Accounts Payable in Bangkok are not the same operation whatever the org chart says. We won't re-argue that. The point here is what you do with it.
You cannot sequence a roadmap against process names. What looks like one process to standardise is frequently three or four workflows that share only a label, and until you know which is which, any prioritisation is a guess dressed as a plan. This is why the first phase of every engagement we run functions like a SWAT team deployment, a short and focused pass through the actual operation that resolves the ambiguity fast rather than spending six months in discovery while the roadmap waits. We map what's genuinely running on the floor, confirm how many distinct workflows are hiding under each name, and come out with something that can be sequenced. Not a fuller diagnosis, but enough operational truth to make the next decision properly.
Name the owner before the GBS AI roadmap, not after the failure
The assessment surfaces the governance gap: the AI decision that gets deployed while the question of who owns it goes unanswered, until something fails and the post-mortem cannot find a name. A roadmap must close that gap at the front end rather than discover it at the back.
That means naming one person, before sequencing anything, who is accountable for the first process redesign. Not a steering committee, not the transformation office, but a single individual who owns the redesign that must happen before any AI is useful, and whose own work gets materially harder if it fails. In practice this is almost never the person who commissioned the assessment. It is the Head of Finance Shared Services, or the GBS Operations Director, whoever lives inside the result rather than presents it upward. If that name cannot be confirmed and documented, the organisation is not ready to proceed, and no amount of roadmap detail compensates for the missing ownership.
Which process goes first is the decision the assessment can't make for you
This is where the roadmap earns its name, and where most of the real work sits.
The process you start with has to be clean enough to redesign before it is automated. A workflow running on years of accumulated workarounds is not an AI candidate, it is something that must be fixed first, because automating it only reproduces the existing problems faster and at higher volume. The assessment tells you which processes those are. It does not tell you to resist starting there, which is the harder discipline, because the broken processes are often the ones generating the most visible pain and therefore the most executive pressure to be seen acting on them.
It also has to carry enough volume and repetition to produce a measurable result inside a short window. Invoice processing in P2P, reconciliation in R2R and order matching in O2C show real numbers within ninety days, and that early proof is usually what earns the next round of investment, because executive patience for AI spending runs out considerably faster than most transformation plans assume.
And the data feeding it must be reliable, which the assessment has already told you it often is not. Inputs corrected by hand, incomplete, or formatted inconsistently across entities will produce wrong outputs faster than the manual process ever did. Where the assessment scored data quality low, that is not a constraint to work around in the roadmap. It is a precondition that either gets resolved first or moves that process out of first position entirely.
The right place to start is rarely the largest or most visible part of the operation. It is the process where something real can be proven quickly, with one accountable owner and inputs clean enough to work with.
The assessment establishes where the organisation stands. The roadmap has to say what happens on Monday morning, and the distance between the two is almost always created by the same two unresolved decisions: nobody named as accountable, and no agreement on which process moves first. Both are organisational, not technical. Both come before any vendor conversation. If the roadmap in front of you doesn't resolve them, the work isn't to refine the roadmap. It's to go back and make those two decisions, because everything downstream depends entirely on them.
AGOS Asia builds GBS AI roadmaps that start from operational reality, not process documentation. Sequenced around what can be proven, owned, and measured first. Start at agosasia.com.
Comments