意思決定インテリジェンス

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.

Comparison of GCC operating models across control, speed, cost profile, principal risk and exit.
ModelControlSpeed to first deliveryCost profilePrincipal risk
CaptiveFull — 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-TransferPartial 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 servicesContractual. 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.
HybridDifferentiated 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

  1. 01

    Segment the work portfolio

    Classify each work stream by criticality, definability and volatility before considering any model.

  2. 02

    Set the control requirement per segment

    Decide what must be under direct employment and what can sit with a partner under contract.

  3. 03

    Test against management capacity

    Confirm the senior time a captive core requires is genuinely committed, in named people with reallocated priorities.

  4. 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.

  5. 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.

関連情報

このテーマをさらに深く

  • 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.