의사결정 인텔리전스
GCC 운영 모델: 캡티브·BOT·매니지드 중 선택
모델 선택은 통제 수준, 구축 속도, 목표 규모, 철수 용이성의 네 가지로 결정됩니다. 핵심 업무를 장기 수행하려면 캡티브가, 속도와 가역성이 중요하면 BOT 또는 매니지드가 적합합니다.
Decision intelligenceReviewed by Ramesh Rathi, Vice President — GCC Enablement & ImplementationPublished January 2026Last reviewed February 202610 min read
Direct answer
핵심 답변
모델 선택은 통제 수준, 구축 속도, 목표 규모, 철수 용이성의 네 가지로 결정됩니다. 핵심 업무를 장기 수행하려면 캡티브가, 속도와 가역성이 중요하면 BOT 또는 매니지드가 적합합니다.
아래 상세 분석은 영문 원문 그대로 제공됩니다. 영문 전체 가이드 보기
The four models compared
Each model trades control against speed and fixed commitment against flexibility. There is no dominant option; there is a fit to your work portfolio.
| Model | Control | Speed to first delivery | Cost profile | Principal risk |
|---|---|---|---|---|
| Captive | Full — entity, employment, IP, culture and roadmap. | Slowest. Entity setup, hiring and governance are all yours. | Highest upfront and fixed; lowest marginal cost at scale. | Senior attention starves the ramp; the center under-performs while still fully costed. |
| Build-Operate-Transfer | Partial during build, full after transfer. | Fast. The partner already has entity, premises and hiring machinery. | Fee-based during build, then a transfer consideration and a step change to direct cost. | Transfer terms and valuation are ambiguous, and the option becomes expensive or impractical. |
| Managed services | Contractual. You control outcomes, the provider controls delivery. | Fastest. Capability exists on day one. | Variable and largely opex; predictable per unit but rarely cheapest at scale. | Capability never becomes yours, and the work quietly becomes unmovable. |
| Hybrid | Differentiated by work stream — captive core, partnered periphery. | Fast for partnered scope, slower for the captive core. | Mixed; requires disciplined allocation and clear boundaries. | Complexity in governance and accountability if boundaries are drawn loosely. |
What should actually drive the choice
- Criticality of the work: core product, proprietary data and regulated processes push strongly toward captive control.
- Definability: work that can be specified and benchmarked is a candidate for managed delivery; work that requires continuous context is not.
- Speed requirement: if a commitment depends on delivery within two quarters, a pure captive build is usually the wrong instrument.
- Management bandwidth: a captive center consumes senior parent-company time for at least a year. If that time is not genuinely available, choose accordingly.
- Horizon and exit: if the work may not exist in three years, do not build a structure designed to last ten.
In our experience five factors explain most of the decision. Ownership preference on its own explains very little.
What actually goes wrong with BOT
Build-operate-transfer is attractive because it appears to give speed now and ownership later. It works well when the transfer is engineered from the start and badly when it is left to good intentions.
The terms that matter are specific: what exactly transfers (people, contracts, IP, tooling, processes), on what timetable, at what price or formula, under whose employment terms, and what happens if the transfer is delayed by either side. If those are not in the original agreement, the negotiating position at transfer time is weak — the partner holds the operational knowledge and the relationships.
The second failure mode is cultural. A center run for two years under a partner's management system develops that partner's ways of working. Transfer is not complete when the entity changes hands; it is complete when the center operates as part of your organization, and that takes deliberate design during the operate phase, not after it.
A defensible way to reach the decision
- 01
Segment the work portfolio
Classify each work stream by criticality, definability and volatility before considering any model.
- 02
Set the control requirement per segment
Decide what must be under direct employment and what can sit with a partner under contract.
- 03
Test against management capacity
Confirm the senior time a captive core requires is genuinely committed, in named people with reallocated priorities.
- 04
Model the cost curves side by side
Compare models over the same horizon, including transfer consideration and exit cost — not just year-one spend.
- 05
Design the transition and exit before signing
Whatever the model, the terms under which capability moves in or out should exist in writing on day one.
NirjiX view
Our view: choose per work stream, and design the exit before you need it
Enterprises that treat this as a single enterprise-wide choice tend to over-build captive capacity for work that was never strategic, or hand a partner work that quietly becomes the core of their engineering capability.
Hybrid is the pragmatic outcome for most organizations at scale, but it only works when the boundary is drawn by criticality rather than by convenience, and when governance is designed for two delivery modes rather than bolted on afterwards.
Whichever model you choose, write down what would make you change it and what changing would cost. An operating model that cannot be exited is not a model — it is a dependency, and dependencies are repriced by the party that holds them.
Frequently asked executive questions
- Captive vs BOT vs managed GCC: which model is best?
- There is no universally best model — the right one follows from how strategic the work is, how quickly you must start, and how much operating risk you can hold. Captive suits work that is core, long-lived and worth owning outright; build-operate-transfer suits organizations that want eventual ownership without absorbing early setup risk; managed suits scoped, non-core capacity where speed matters more than control. Hybrids are common and legitimate: own the differentiated work, contract the rest.
- Is a captive GCC always cheaper at scale?
- Often, but not automatically. Marginal cost per role is usually lower once a captive is at scale, and that advantage can be erased by low utilization, slow ramp, high attrition or governance overhead that was never costed. The comparison should be run on your own volumes and ramp, over the same horizon for every model.
- How long does a BOT transfer typically take?
- Commonly two to four years from build start to transfer, though the operative constraint is contractual rather than technical. The transfer window, trigger conditions and pricing formula should be defined in the original agreement; negotiating them later is where most value is lost.
- Can we start managed and convert to captive later?
- Yes, and many organizations do — but only if the contract anticipates it. Rights over people, processes, tooling and data at conversion need to be explicit from the outset. Without them, conversion means rebuilding capability rather than transferring it.
- What governance does a hybrid model require?
- A single accountable owner for the whole capability, one performance framework covering both modes, clear boundaries on which decisions sit inside the captive core, and a shared architecture and security standard. Running two governance systems side by side is the most common reason hybrids underperform.
- How does an AI-native design change the operating model choice?
- It usually strengthens the case for owning the core. When AI capability, proprietary data and evaluation are central to how the work is done, that layer belongs under direct control even if surrounding delivery is partnered. It also changes role mix and seniority, which should be reflected in the business case for each model.
Continue
Related intelligence
- DecisionGCC business caseHow to build a case that survives finance review, modelled against your chosen model.
- PortalGCC feasibility assessmentTest intent, work portability, talent, governance and cost before choosing a model.
- ServicesGCC engagement modelsHow NirjiX engages across each model, with comparison tooling and cost calculators.
- PortalBuild your GCC blueprintTurn the chosen model into an execution blueprint with structure, roles and sequencing.
- DecisionAI build vs rentThe same ownership logic applied to AI capability rather than delivery capacity.
- HubGCC consulting hubFeasibility, business case, operating model, blueprint and advisor review in one path.
함께 보기
연관 가이드
이 주제를 더 깊이 살펴보기
- BOT의 이전 단계: 가치가 결정되는 지점
핵심 네 가지 조건은 이전 시점이 아니라 최초 계약에서 확정해야 합니다. 향후 협상이 아닌 산식 기반의 가치평가 메커니즘, 직원 이전 조건(대상자, 근속·처우 승계, 유지 비용 부담), 산출물을 명시한 지식 이전 의무, 그리고 이전 지연·불이행에 대한 구제 조항입니다.
- GCC 거버넌스: 통제 구조를 어떻게 설계할 것인가
효과적인 거버넌스는 보고 체계, 의사결정 권한, 성과 지표, 에스컬레이션 경로를 문서화하는 데서 시작합니다.
- GCC 업무 분담: 무엇을 이관하고 무엇을 남길 것인가
이관에 적합한 업무는 산출물이 정의되고 반복성이 있으며 재량 판단이 제한된 일입니다. 고객에 대한 최종 책임과 규제 판단은 본사에 남기는 것이 원칙입니다.
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.
Decide the model against your own work portfolio
The GCC assessment segments your work by criticality and portability, then the blueprint translates the chosen model into structure, roles and a sequenced plan.
Outputs are preliminary and intended for advisor validation before commercial commitment.