Dear Deb… (No. 5) The real risk: Not that AI fails. That it works beautifully inside a bad model.
Dear Deb,
For companies that are not ready to adopt a formal GBS model, what is the minimum set of standards, governance, and end-to-end process ownership they should establish now so AI doesn’t institutionalize fragmentation instead of eliminating it?
Lacramioara Ardeleanu,
Senior Director Finance Operations, Universal Music Group
Dear Lacramioara,
I’m going to begin with an uncomfortable truth, because it is where most of the trouble starts.
As much as our pundits push GBS, some enterprises are just not ready for a formal GBS model. Not every organization is ready to redraw accountabilities, move work, change reporting lines, upset functional leaders, or have the grown-up conversation about who actually owns work once it crosses the border between finance, HR, procurement, IT, commercial, and the regions.
But “not ready for GBS” should not mean “not ready for discipline.”
Companies say they are not ready for a GBS model, when what they really mean is that they are not ready for the politics that come with GBS. They are not ready to challenge functional autonomy. They are not ready to tell every region, business unit, and functional leader that their favorite exception is not a business strategy. They are not ready to admit that the same process has been redesigned twelve times because everyone wanted local control and no one wanted enterprise accountability.
So they keep the familiar structure. Finance operations stays in finance. HR operations stays in HR. Procurement operations stays in procurement. Commercial support stays somewhere else. Everyone breathes more easily because there has been no formal “transformation,” no new GBS label, no debate over scope, and no awkward conversation about who gets to decide—all of which disturb the world order.
Lovely. Except AI is now walking straight into that operating model with a toolkit, a budget line, and an alarming amount of executive enthusiasm.
And AI will not politely wait until your organization matures. It will not pause at the door and say, “Perhaps you should sort out your process ownership first.” It will land exactly where the work sits today. If that work is fragmented, locally interpreted, inconsistently governed, and weakly owned, AI will not magically create integration. It will automate the fragmentation, scale the workarounds, and give every broken handoff a more expensive user interface.
That is the real risk. Not that AI fails. That it works beautifully inside a bad model.
It will make a broken process faster. It will give each function its own clever tool. It will produce dashboards for five different versions of the truth. It will allow local teams to automate around dysfunction instead of confronting it. And before long, the enterprise will have convinced itself it is modernizing work, when in reality it has simply digitized its excuses.
So, what is the minimum? Start with a common definition of the work. Not a glossy taxonomy or service catalog admired once in a steering committee and then abandoned to SharePoint, but a practical enterprise view of what work exists, where it sits, who performs it, what systems it touches, which policies govern it, and which variations are genuinely required versus merely tolerated. If you cannot describe the work consistently, you cannot govern it. If you cannot govern it, you have no business pointing AI at it and pretending the outcome will be coherent.
The second minimum is a shared process language. This sounds basic because it is. It is also the bit many organizations still somehow manage to skip while congratulating themselves on being digitally ambitious. “Order to cash,” “record to report,” “source to pay,” “hire to retire,” “customer onboarding,” “vendor management”-- whatever the architecture is, agree it, use it, and stop letting each function invent its own dialect. AI is very good at operating within patterns. It is also very good at amplifying confusion when the enterprise cannot agree what the pattern is.
The third requirement is end-to-end process ownership, even if you are not ready to call anything GBS. Someone has to own the process across the seams. Not just the finance bit, or the HR bit, or the transaction, or the system, or the policy. The process. And by ownership, I do not mean the privilege of chairing a monthly meeting in which everyone reviews the same red risks and agrees to “take it offline.” I mean real authority to set standards, challenge exceptions, prioritize improvements, approve automation use cases, define controls, and escalate when functional preference is damaging enterprise performance.
This is where the room usually gets quiet, because organizations love the language of end-to-end ownership right up until someone asks what the owner is actually allowed to decide. If the answer is “influence,” “align,” “coordinate,” or “socialize,” then you do not have an owner. At best you have a hardworking diplomat with no passport control. At worse, you have a nice nanny. Useful, perhaps. Transformational, no.
The fourth minimum is governance that decides. Not governance that narrates. Not governance that admires the problem in twelve-point font. Most governance forums are beautifully designed to consume time and avoid consequences. They review slides, note dependencies, discuss risks, thank the team, and conclude that further alignment is required. Everyone leaves feeling responsible in principle and untouched in practice.
That will not survive AI. You need a governance body that can decide which processes get standardized, which AI use cases move forward, which exceptions are legitimate, which data definitions apply, which tools are allowed, and where local experimentation crosses the line into enterprise risk. This does not require a giant bureaucracy. Please, for the love of sanity, do not build another one of those. But it does require teeth. Governance without decision rights is theater, and AI does not need more theater. It already has enough theatrical demos.
The fifth minimum is a single intake and prioritization mechanism for automation and AI use cases. Otherwise, every function will chase its own shiny object and call it innovation. Finance will build one thing, HR another, procurement a third, and IT will be blamed when none of it connects. The business will complain about speed, the functions will complain about constraints, and the enterprise will wonder why all this activity has not produced a cleaner operating model.
A real intake process asks harder questions before anyone falls in love with the tool. Is this solving an enterprise problem, or just making one team’s workaround faster? Is the process stable enough to automate, or are we about to laminate stupidity? Who owns the upstream data? Who owns the downstream impact? What controls are required? What happens to the exception? Will this reduce fragmentation, or will it make fragmentation permanent?
That last question should be asked every time. Preferably before the vendor demo, when people are still capable of their own judgment.
The sixth minimum is data discipline. AI cannot compensate for bad master data, inconsistent definitions, competing hierarchies, local fields, shadow spreadsheets, and reporting logic that changes depending on who is presenting. It can mask the problem for a while. It can produce confident answers, which is apparently enough to impress some people. But confidence is not accuracy, and a slick answer built on rubbish data is still rubbish, only now with better formatting.
So companies need to decide which data matters most, who owns it, what quality thresholds apply, which definitions are mandatory, and what controls cannot be bypassed because someone important wants an easier route. This is not glamorous work. It does not photograph well at conferences. It is, however, the difference between AI as a capability and AI as a liability.
The seventh minimum is transparency on exceptions. Every enterprise has exceptions. Some are legitimate. Regulation, customer requirements, market constraints, risk, economics— these are real. The problem is not that exceptions exist; the problem is that they become invisible. They hide inside local practice, legacy policy, stakeholder preference, and that immortal phrase, “this is how we do it here.” Then AI comes along, learns the exception as if it were the rule, and suddenly the organization has machine-assisted folklore.
So name the exceptions. Price them. Review them. Sunset them where possible. And when someone insists an exception is necessary, ask whether it is required by law, customer value, risk, economics, or habit.
Habit should have a much shorter shelf life than it currently enjoys.
Now, to the part of your question I like most: the people doing GBS-type work inside functions. They matter enormously, because in many companies they are already the operating backbone, even if the organization has not had the courage to call them that. They understand the process, the data, the controls, the handoffs, and the tiny points of failure that senior leaders discover only after something lands in escalation. They know where the work really breaks, not where the PowerPoint says it breaks.
But they are often treated as functional support rather than enterprise capability. That is a mistake. Even without a formal GBS model, these teams should be connected across functions, given common standards, included in AI prioritization, and made central to process governance. They should not have to wait for a reorganization to behave like an enterprise network. In fact, building that network may be the most practical bridge to a more formal model later.
This is not about sneaking GBS in through the side door. It is about admitting that work does not respect the boxes on the organization chart. Customers, suppliers, employees, regulators, and financial outcomes do not experience your enterprise function by function. They experience the seams. And the seams are exactly where fragmentation breeds.
AI raises the stakes because it rewards clarity and punishes ambiguity. If the enterprise has defined work, common process language, accountable owners, disciplined governance, reliable data, and a ruthless view of exceptions, AI can help simplify the model. If not, AI will simply make the existing mess faster, more convincing, and harder to challenge because now the mess comes with a roadmap and a steering committee.
So no, a company does not need to adopt formal GBS tomorrow. But it does need to stop using “not ready for GBS” as a hall pass from operating discipline.
Because AI will not eliminate fragmentation because the strategy deck says it will. It will eliminate fragmentation only if someone has already done the harder work of establishing standards, ownership, governance, and decision rights.
Otherwise, congratulations. You have not built the future of work. You have taught a machine bad habits.
Deborah
