In Issue 22 I wrote about why PE backed companies consistently underdeliver on GBS transformation. The constraints they face are often insurmountable . Compressed hold periods, LP pressure for early wins, talent gaps in their portfolio companies, and consulting incentives that favor structural decisions over root cause work. Those conditions make it genuinely difficult to do the foundational work that better outcomes require.
Large enterprises do not have those constraints. If they do, they are often self imposed based on faulty data or over ambitious executives who likley haven’t been fed the right level of details.
Enterprises often have the following working in their favor: solid capital, stable leadership, and organizational heft to have the real mandate conversation at the board level. There is time to do the diagnostic work properly. Resources should be available to build measurement infrastructure before go-live rather than after. The structural advantages that PE backed companies lack are, or should be, standard operating conditions for large enterprise GBS builds and transformations.
Despite this, outcomes are often no better. There is a playbook that has been scrutinized and “approved” so why is there still so much wanting? The practices that separate GBS transformations that deliver from the ones that restructure the same dysfunction under a new org chart have been demonstrated repeatedly, in greenfield builds and in transformations of existing functions across industries and geographies.
What I’ve written about below are those must haves to have a successful GBS.
The Mandate Conversation Comes Before Everything Else
In every GBS build I have seen deliver on its original mandate, the leadership team made one decision that many programs do not. They had the mandate conversation with the CFO and the business before drawing the first org chart. Not the scope conversation. Not the headcount conversation. Not the technology conversation. The mandate conversation. What will be measurably different about this enterprise in three years because this function exists and is run well? Stated in financial terms with baselines and named accountability.
In a greenfield build that conversation is a genuine opportunity window many don’t get to experience. No legacy structures, no inherited reporting lines, no political history baked into the existing setup. The first 60 to 90 days are the best opportunity a GBS leader will ever have to define what the function is accountable for before the business defines it for them. The programs that used that window deliberately spent real time building the mandate conversation before committing to structural decisions. They also had a fundamentally different relationship with their CFO in year two and year three. Budget conversations became performance conversations rather than cost justification exercises. Isn’t that something to aspire to?
In a transformation of an existing function the mandate conversation is harder because there is almost always a gap between what the GBS team believes they are accountable for and what the business believes it is paying for. That gap rarely surfaces directly with the exception of antidotal complaints that get swept under the rug and treated as “training opportunities” . It appears in the subtext of budget reviews, in the skepticism that greets improvement claims, and in the recurring sense that the function is one cost-cutting cycle away from being questioned. Surfacing it before the transformation begins is uncomfortable and difficult. Finding it two years in, after the program has committed resources and generated expectations, is a different kind of problem entirely.
Measurement Infrastructure Before Process Infrastructure
This is the investment that feels half baked and wrong under time pressure and proves indispensable in every program review that follows.
Most GBS builds prioritize getting processes running as quickly as possible. It’s reasonable given the pressure to demonstrate progress. But the programs that can actually demonstrate what they delivered, not assert it but demonstrate it, make different sequencing decisions. They invested in the data and measurement architecture before the first transaction processed rather than after the first budget challenge arrived.
In practice that means three specific things. Baselines get established before go-live, not reconstructed afterward when someone asks what actually changed. Attribution methodology gets agreed with the CFO before the first improvement is claimed, not negotiated when the first disagreement about credit arises. And the metrics selected are the ones that connect directly to what the CFO measures. Working capital. Revenue at risk. Decision making cycle time. Not the metrics that happen to be available from the system being implemented.
Without that sequence the program is always one skeptical question away from a conversation it cannot come out of cleanly. It creates doubt. With that specific sequence, every performance discussion starts from evidence rather than assertion.
Diagnose Before You Redesign
The most expensive transformation decisions I have seen were made before anyone fully understood what the existing operation was actually doing. Not what the process documentation said it was doing. What it was actually doing. Where the manual workarounds were, why they existed, what upstream failures they were compensating for, and what institutional knowledge lived in the people performing them that would disappear if those people were displaced before it was captured.
In a greenfield build the diagnostic question is about the upstream environment the new function will work from. What contracting and quoting behaviors will generate O2C complexity downstream? What procurement discipline exists that will determine P2P performance? What data quality lives in the systems the new function will depend on? Building without mapping that “real” environment is designing a solution for a problem that has not been fully read.
In a transformation the diagnostic question is about the gap between the documented process and the actual process. The manual workarounds in any established GBS function are not random. They are adaptations to upstream process failures, system limitations, and customer behaviors that the formal process was never designed to handle. Restructuring without mapping them moves the dysfunction rather than resolving it.
Four to six weeks (or longer) of serious diagnostic work before any structural decision is made changes every subsequent decision in the program. It is the investment most consistently cut under schedule pressure and most consistently cited in post-mortems as the thing that should not have been cut.
Staff for Judgment, Not for Transaction Volume
This is a pet-peeve of mine in the staffing space. The staffing decision made in year one of a GBS build shapes the function’s capability profile for longer than almost any other decision made in that period.
The pressure is always toward filling seats quickly. Showing headcount decisions and demonstrating the function is being built overrides thoughtful analysis of the work that is actually being done.
The programs that built functions with genuine staying power made a different calculation. Smaller teams with higher analytical capability, with process and technology infrastructure built around them rather than people infrastructure built around process are more scalable and yes, more expensive per head in year one. But structurally different in year three when the scope conversation comes back up and when the technology landscape inevitably shifts and the CFO asks the function to take on something it was not originally designed to do. You will be able to do it with a much lighter lift
The transactional work that justified large GBS headcount is the work most directly in the path of automation and AI. A function built around that work faces a structural question as the technology matures. A function built around the judgment, analysis, and relationship management that sits above that work has a different answer to that question.
Vendor Selection Is an Operating Model Decision
The technology and BPO partnerships established in the first year of a GBS build shape the operating model for far longer than any contract term.
The programs that navigate this well completed the operating model design before selecting the technology, not the other way around. Technology was selected to enable a defined model and the programs that struggled flipped that sequence of events. Technology was selected first, often driven by procurement timelines and existing vendor relationships, and the operating model was designed around what the technology could do rather than what the business needed it to do.
The outcome based shift I wrote about in Issue 23 makes this even more consequential because a vendor relationship structured around activity, FTEs provided, transactions processed, service hours delivered, is structurally different from one structured around the outcomes the activity is supposed to produce. Understanding that distinction before signing, and building contracts that reflect it, requires knowing what outcomes you are trying to produce before you know which vendor will help you produce them. That sequence only works if the operating model comes first.
The CFO Relationship Is Built Before It Is Needed
The GBS functions that have genuine organizational influence and get investment when they need it and support when transformation creates friction (and it will), built the CFO relationship during the periods when they did not need anything from it. Many of you may already be in the CFO organization and think that qualifies as the relationship I’m referring to and it does not.
They ones with influence showed up with analysis, not just reporting. They surfaced working capital patterns before the CFO asked about them. They brought the revenue leakage conversation, the cost structure opportunity, and the close cycle analysis to the CFO rather than waiting to be asked. They reported in the language the CFO uses to evaluate the business rather than the language the GBS function uses to describe its own operations.
That is not a relationship management technique but a repeated display of “the function understands what the business is trying to accomplish” and has something specific to contribute to that conversation. The functions that built it that way had a different kind of budget conversation than the ones that showed up simply with benchmark comparisons and SLA reports.
What This Looks Like When It Works
The GBS functions that delivered on their original mandate, the ones the CFO points to as a genuine source of enterprise value rather than a managed cost, share a recognizable profile that traces back to early decisions.
The mandate was defined in enterprise financial terms before the org chart was drawn and. measurement infrastructure was built before go-live. The diagnostic work was thorough despite timing pressures because that is the foundation of the thing you’re building. The staffing model was built around judgment rather than volume of things being done. The vendor relationships were structured around outcomes rather than activities and the CFO relationship was treated as something to build and be mutually beneficial.
None of those decisions are complicated but understandably difficult to execute on if you don’t have the right experience. Several of them are counterintuitive under the pressure that every transformation generates when all you want to do is get that squeaky wheel oiled. At the end of the day, all of them are available to any large enterprise GBS leader operating with patient capital, stable leadership, and the organizational weight to have the right conversations at the right level about the right topics.
Ian P. Thompson is a finance operations and GBS executive with over 30 years of experience. He writes the Clear Cycle Dispatch for finance operations and GBS leaders who want to understand how the work is actually changing. If someone forwarded this to you and you want to receive future issues, subscribe at https://lnkd.in/eMfv4FMv