Decision intelligence · India GCC
GCC Work Split: What Work Should Move, and What Should Not
The work split determines almost everything else — role mix, city, cost, governance and whether the center becomes a capability or a queue.
Move end-to-end ownership of something. Distributing fragments of many processes produces coordination cost without capability.
Decision intelligenceWritten by NirjiX GCC AdvisoryReviewed by Ramesh Rathi, Vice President — GCC Enablement & ImplementationPublished January 2026Last reviewed February 20269 min read
Direct answer
What work should move into a GCC?
Move work that is durable, definable and separable end to end: complete processes or product areas the center can own outright, with clear inputs, outputs and quality measures. Keep work that requires physical presence, local regulatory accountability, direct customer or regulator relationships, or continuous informal context that cannot survive documentation. The critical design rule is to transfer ownership of whole processes rather than fragments of many — fragmented transfer creates coordination overhead that consumes the economics and leaves the center unable to improve anything.
Transfer ownership, not tasks
The instinct in most transitions is to move the parts of each function that are easiest to describe. The result is a center performing the routine twenty percent of fifteen different processes, with every exception routed back to the origin team. Coordination cost rises, the origin teams retain most of their load, and nobody can point to something the center owns.
End-to-end transfer inverts this. The center receives a complete process with defined inputs, outputs and quality measures, and is accountable for the result including exceptions. That is what allows it to improve the process rather than execute it, and process improvement is where the durable value in capability centers actually accumulates.
It is harder to design and it takes longer to transition. It is also the difference between a center that is renegotiated every budget cycle and one that becomes structurally embedded in how the group operates.
What travels well, and what does not
The test is not complexity. Highly complex work transfers successfully; work dependent on physical presence or local accountability does not.
| Characteristic | Suitability | Reasoning |
|---|---|---|
| Definable process with measurable output | Strong candidate. | Can be transferred with quality standards and owned outright. |
| Engineering and product work with a clear backlog | Strong candidate. | Benefits most from continuity and accumulated context; the classic anchor workload. |
| Analytical and reporting work with governed data access | Good candidate once data access is resolved. | Access and permitted-purpose questions are the constraint, not capability. |
| Work requiring local regulatory sign-off | Retain. | Accountability sits with the licensed or regulated entity and cannot be relocated. |
| Direct customer, supplier or regulator relationship management | Retain, with center support. | Relationship continuity and local presence outweigh cost advantage. |
| Work dependent on undocumented tacit knowledge | Defer until documented. | Transferring it without documentation moves the fragility rather than the work. |
Design rules for a workable split
- Transfer whole processes, not the routine portion of many.
- Give the center accountability for exceptions, not only for the standard path.
- Define quality measures before the transfer, and agree who owns them afterwards.
- Keep decision rights where the accountability legally sits, and be explicit about it.
- Sequence transfers so that the first wave builds credibility rather than exposing the center to the hardest process.
- Document the process as it is actually performed, including workarounds, before moving it.
These are the rules we apply when structuring a transition scope.
How to run the work split analysis
Four to six weeks per function, run with the process owners rather than for them.
- 01
Map processes end to end
Map the whole process including handoffs and exceptions, not the org chart. Splits designed from org charts inherit the fragmentation that already exists.
- 02
Classify by transferability
Assess each process against physical presence, regulatory accountability, relationship dependency and documentation quality. Record the reason for every retain decision so it can be revisited later.
- 03
Test durability
Ask whether the process will still exist in three years in its current form. Automating or retiring a process is a better outcome than relocating it.
- 04
Assemble coherent scopes
Group transferable processes into scopes a single team can own with a single accountable leader. If a scope needs three managers in two countries, it is not one scope.
- 05
Sequence the waves
First wave: high durability, moderate complexity, cooperative sending team. Prove the transition machine works before attempting the difficult scope.
NirjiX view
The NirjiX view
The most damaging pattern we see is the center as an execution queue: it does the routine work, sends everything unusual back, and is measured on throughput. That center will never own an outcome, and it will be compared to a vendor on price until it is eventually replaced by one.
We also treat undocumented processes as not ready to move. The documentation effort is frequently the real value of the exercise — organizations discover during it that the process is more variable than anyone believed, and that finding is worth more than the transfer.
Frequently asked executive questions
- Should the first wave be the simplest work?
- It should be work that is durable, cooperatively supported and moderately complex — not trivial. Trivially simple first waves prove nothing about the transition machine and set an expectation of the center as a low-value execution shop that is difficult to reverse later.
- Can judgement-intensive work move to a GCC?
- Yes, provided the judgement can be developed rather than merely instructed, and the center is given enough context and tenure to develop it. What does not transfer is judgement that depends on physical presence or on a local relationship. The constraint is context, not capability.
- How do we handle work that fails the durability test?
- Do not move it. Work that is being automated or retired should be automated or retired; relocating it consumes transition capacity and leaves the center holding a shrinking mandate that will be used against it at the next review.
- Who should decide the work split?
- The functional owners, with a central design authority to prevent fragmentation. Left entirely to individual functions, each transfers its own routine portion and the aggregate becomes exactly the fragmented split that fails. Left entirely to a central team, the scope is unrealistic about how the work is actually performed.
- What would change a retain decision?
- Documentation of a tacit process, a regulatory clarification, or a change in the relationship model — for example a supplier interaction that moves onto a platform. Retain decisions should be recorded with their reason and revisited annually rather than treated as permanent.
The main guide on this topic
Captive vs BOT vs managed GCC: which model is best?
This page covers one part of the decision. The full NirjiX guide to GCC operating model sets out the whole picture.
GCC operating model →Decide next
Related decisions
- 01 · GCC decisionGCC transitionWave design, knowledge transfer, dual running and acceptance criteria.
- 02 · GCC decisionGCC feasibilityWorkload durability, scale, talent depth and management bandwidth.
- 03 · GCC decisionGCC operating modelsCaptive, BOT, managed and hybrid compared on control, speed, cost profile and exit.
- 04 · GCC decisionGCC governanceReporting lines, decision rights and the measures that set the center's ceiling.
Continue
Related intelligence
- DecisionGCC transitionHow agreed scope actually moves without service degradation.
- DecisionGCC feasibilityWhether the workload supports an owned center at all.
- DecisionGCC operating modelsHow ownership structure changes what the center can be trusted to own.
- PortalGCC assessmentStructure the work split alongside talent, economics and readiness.
Transparency
Sources and methodology
This page reflects NirjiX practitioner experience designing, costing and standing up capability centers in India, and the same modelling logic used in the NirjiX GCC business case builder and blueprint.
We do not publish generic per-seat or per-FTE benchmarks as if they were universal. Compensation, real estate, statutory cost and attrition vary materially by city, role mix, seniority and hiring speed, and a business case built on an averaged benchmark is usually wrong in both directions at once.
The models we build with clients use your own baseline cost, your own role mix and your own ramp assumptions, then stress-test them with sensitivity ranges rather than presenting a single deterministic number.
Test the decision against your own numbers
The GCC assessment establishes whether the workload and economics support a center; the business case builder models the cost, savings and sensitivities behind it.
Outputs are preliminary and intended for advisor validation before investment decisions.