Sourcing, Partnerships, and Location Strategy

Target operating model design

A target operating model is not just about how your employees work. It is also about who does the work at all (you vs. vendors vs. partners) and where the work is done (onshore, nearshore, offshore, or a mix). These choices drive cost, risk, resilience, speed, and your ability to scale.

This chapter focuses on making those choices deliberately, not through legacy, opportunistic deals, or one-off cost-cutting moves.

We will cover:

  • A simple make / buy / partner decision framework
  • How to use shared services, centers of excellence, and outsourcing models
  • How to think about your location footprint
  • How to design vendor governance and SLAs so relationships actually delivera

9.1 Make vs. Buy vs. Partner: A Simple Decision Framework

The starting point is straightforward: for each meaningful activity in your value streams, decide whether you should perform it yourself, outsource it, or partner for it.

You do not need a detailed decision tree for every task. You need a clear logic that senior leaders can apply consistently.

A practical framework uses four questions:

  1. Is this activity core to our differentiation?
    • Does it directly shape customer experience, brand, or IP?
    • Does it significantly influence risk profile or regulatory posture?
    • Would losing control of it erode our long-term advantage?
  2. Do we have (or can we build) distinctive capability here?
    • Do we have strong talent, tools, and know-how?
    • Could we realistically become “better than the market” at this in the next 2–3 years?
  3. Are there mature external providers with scale advantages?
    • Are there specialist vendors who do this at greater scale and lower cost?
    • Is the service relatively standardized and well-understood?
  4. What is the impact on resilience, risk, and flexibility?
    • Does externalizing this make us more or less resilient?
    • Does it introduce concentration risk (one key vendor) or data/security risk?
    • How reversible is the decision?

From these questions you can derive three broad directions:

Make (in-house)

You keep the activity internal when:

  • It is core to differentiation or brand.
  • It shapes proprietary IP, algorithms, or methods.
  • It is critical to your control environment (certain risk, legal, or regulatory functions).
  • External options are immature or incompatible with your risk appetite.

Here, the TOM should:

  • Ensure clear ownership, career paths, and investment in capability.
  • Provide the right tools and data for these teams to be effective.
  • Avoid “accidental outsourcing” of critical knowledge via overly vendor-led delivery.

Buy (outsource)

You outsource when:

  • The activity is non-core, transactional, and standardizable (e.g., certain finance operations, payroll, basic customer service, application maintenance, infrastructure operations).
  • Vendors clearly have scale and specialization advantages.
  • The interface is well-defined; outcomes can be measured objectively.

In practice, this is where you see models like:

  • Business process outsourcing (BPO).
  • IT outsourcing / managed services.
  • Standard SaaS services replacing in-house tools.

The TOM must then define:

  • What remains internal (e.g., process ownership, exception handling, vendor management).
  • How outsourced processes integrate with your value streams and systems.
  • How you ensure continuity and control (governance, audits, exit options).

Partner (co-create / strategic partnership)

You partner when:

  • The activity involves joint value creation, not just task execution.
  • You need access to ecosystems (platforms, distribution networks, data, or technology you cannot or should not build alone).
  • There is mutual dependency and benefit.

Examples include:

  • Joint product development with tech or industry partners.
  • Data-sharing or analytics partnerships.
  • Platform plays where you are one of multiple anchor participants.

The TOM should then:

  • Treat partners as extensions of the operating model, not “just vendors”.
  • Define joint governance, shared KPIs, and clear IP boundaries.
  • Embed partnership management roles and capabilities (not left as side-jobs).

A simple test in design sessions:

  • When a team argues “we must keep this in-house,” ask: “Is this truly core to how we win, or just familiar?”
  • When they argue “we should outsource this,” ask: “Are we outsourcing a headache or outsourcing a capability we might one day need to differentiate?”

The aim is a conscious sourcing architecture across value streams, not a patchwork of inherited contracts.

9.2 Shared Services, Centers of Excellence, and Outsourcing Models

Once you know what stays in-house vs. outside, you still need to decide how internal work is organized and what type of external model to use.

Three common internal constructs:

  • Shared services
  • Centers of Excellence (CoEs)
  • Global Business Services (GBS)

And three common external constructs:

  • Traditional outsourcing (staff or process)
  • Managed services
  • Build–Operate–Transfer (BOT) or similar models

Shared services

Shared services bring together repeatable, transactional work from multiple business units or geographies into a single organization. Typical domains:

  • Finance operations (AP, AR, general accounting).
  • HR operations (payroll, benefits administration).
  • Customer service and back office processing.
  • Certain IT support and infrastructure operations.

In TOM terms, shared services make sense when:

  • Processes are or can be standardized across units.
  • Scale can meaningfully reduce cost and improve quality.
  • Work can be measured with clear SLAs (volumes, cycle times, accuracy).

Design points:

  • Scope: which processes move to shared services in which waves.
  • Relationship: shared service as an internal provider with service catalog and SLAs.
  • Governance: demand management, prioritization, and escalation mechanisms with business units.

Centers of Excellence (CoEs)

CoEs house specialist expertise and methods that support multiple areas but do not own end-to-end processes. Examples:

  • Data and analytics CoE.
  • Automation / RPA CoE.
  • Cybersecurity CoE.
  • Risk methodology or modeling CoE.
  • Process excellence / Lean CoE.

From a TOM perspective, CoEs:

  • Set standards, methods, and tools.
  • Provide expert capacity for high-value problems or initiatives.
  • Coach and enable line teams (not do everything for them).

Design questions:

  • Where do CoEs sit in the structure (e.g., under a Group function, under a platform, or federated)?
  • How do they allocate time (projects, advisory, operations)?
  • How do they measure impact (not just activity)?

Global Business Services (GBS)

GBS is an integrated model that combines multi-function shared services and sometimes CoEs into a single, often global, organization.

Characteristics:

  • Cross-functional scope (finance, HR, procurement, certain operations and IT).
  • Common governance and service management.
  • Often global or regional hubs with satellite locations.

GBS is useful when:

  • You are large and global enough to justify a consolidated services backbone.
  • You want consistent experience, standardized processes, and strong control across functions.
  • You are ready to manage a professional “internal provider” with its own leadership, KPIs, and roadmap.

Outsourcing and managed services

Externally, models range from simple outsourcing to more integrated managed services.

  • Task / FTE-based outsourcing
    • You contract external staff (on- or offshore) for defined tasks or roles.
    • Often priced by FTE or time and materials.
    • Flexible but easy to turn into “body shopping” with weak accountability.
  • Process-based outsourcing (BPO)
    • You hand over a well-defined process or sub-process with volume and quality SLAs (e.g., claims processing, document management).
    • Vendor owns staffing, tooling (to some extent), and continuous improvement within boundaries.
  • Managed services
    • Vendor takes end-to-end responsibility for a capability (e.g., application operations, network services, certain analytics services).
    • Outcomes-based metrics (availability, time to restore, throughput, quality), not just effort.
  • Build–Operate–Transfer (BOT)
    • Vendor sets up a capability or center, runs it for a period, then transfers it back to you.
    • Useful for entering new geographies or standing up capabilities quickly without long-term dependence.

In TOM design, be explicit:

  • Which processes or capabilities will move to shared services vs external providers.
  • Where CoEs will support business and operations, and how they will work with vendors.
  • What your default external model will be for certain work (e.g., application maintenance via managed services, not ad-hoc staff augmentation).

Without this clarity, you end up with fragmented deals, overlapping scopes, and vendors filling gaps you did not intend to outsource.

9.3 Location Footprint: Onshore, Nearshore, Offshore, Hybrid

Location strategy is not just “where is cheap.” It is about matching work types to locations based on cost, risk, customer/regulator needs, and talent.

Common terms:

  • Onshore: same country as core business or customers.
  • Nearshore: nearby countries, often with similar time zones and cultural affinity.
  • Offshore: distant geographies, typically with significant labor cost advantage.

A simple way to structure location choices is around four dimensions:

  1. Cost and scale
    • Labor cost differentials can be material, particularly for large transactional or support operations.
    • But cost advantage must be weighed against additional coordination overhead and risk.
  2. Talent and skills
    • Availability of specific skills (e.g., data engineering, cyber, domain expertise).
    • Depth of talent pool to scale over time.
    • Competition for talent locally.
  3. Proximity and interaction
    • Time zone overlap with core business and customers.
    • Need for frequent real-time collaboration vs. asynchronous handoffs.
    • Language and cultural considerations.
  4. Risk, regulation, and resilience
    • Data residency requirements.
    • Political, economic, cyber, and climate risks in chosen locations.
    • Business continuity considerations (don’t put everything in one city or one vendor site).

In TOM design, you typically end up with a hybrid footprint:

  • Some activities must be onshore:
    • High-touch sales or relationship roles.
    • Certain regulated activities require local presence.
    • Work needing frequent in-person collaboration with business owners.
  • Some activities can be nearshore:
    • Knowledge-intensive work requires good collaboration but not physical presence.
    • Certain customer service or back office activities where language and time zone matter.
  • Some activities fit offshore well:
    • Highly standardized, high-volume transactional work.
    • Certain development, testing, and operations functions with strong processes and tools.

Avoid simplistic rules like “move everything possible offshore” or “keep everything in HQ.” Instead:

  • Map major activities in your value streams to location options.
  • For each, ask:
    • Can this work be standardized enough to move?
    • What is lost or gained in customer experience, risk control, and speed?
    • What is the realistic change and transition cost?

You also need to think in terms of hubs and spokes:

  • Hubs: locations with critical mass, leadership, and multi-team presence (e.g., regional operations hubs, global tech hubs).
  • Spokes: smaller local teams close to customers or specific regulators.

Hubs enable:

  • Scale in operations and shared services.
  • Communities of practice and career paths.
  • Better resilience if designed with redundancy across hubs.

From a TOM perspective, define:

  • How many hubs you will have and for what (e.g., 2–3 global operations hubs, 2 tech hubs, 1–2 analytics hubs).
  • Which countries will primarily host front-line, regulatory-facing, and market-specific roles.
  • How remote and hybrid work patterns fit: what must be co-located vs. can be distributed virtually.

Your location design should be visible on one or two pages—otherwise it will not guide real estate, HR, or vendor decisions.

9.4 Designing Vendor Governance and SLAs

Once you decide to buy or partner, your operating model must define how you manage those relationships. Weak governance turns even good vendors into disappointments.

Vendor governance in TOM terms covers:

  • How you segment vendors and tailor relationship models.
  • What SLAs and metrics you put in place.
  • How you run joint governance forums and resolve issues.
  • How you manage risk and exit options.

Vendor segmentation

Not all vendors are equal. A simple segmentation helps:

  • Strategic partners
    • Large share of spend and/or critical to differentiation (platform providers, key BPO partners, core banking or ERP vendor).
    • Require executive-level relationship management, joint planning, and clear multi-year roadmaps.
  • Key operational suppliers
    • Important for continuity, cost, and quality (e.g., secondary IT vendors, regional operations providers).
    • Need strong performance management and risk oversight, but less co-creation.
  • Tactical suppliers
    • Fill specific gaps or provide niche services.
    • Managed with standard contracts and basic SLA monitoring.

For each segment, define:

  • Governance cadence and level (C-suite, functional heads, operational leads).
  • Type of performance reports expected.
  • Depth of joint planning and innovation discussions.

SLAs and metrics

SLAs (Service Level Agreements) should support your TOM objectives, not just describe today’s status quo. At a minimum, they should cover:

  • Volume and scope
    • Which processes or services are included, in what volumes, and what’s excluded.
  • Performance metrics
    • Timeliness (e.g., turnaround times, availability).
    • Quality (e.g., error rates, rework, right-first-time).
    • Productivity or throughput (e.g., cases per FTE, transactions per hour).
    • Experience where relevant (e.g., customer satisfaction, user satisfaction).
  • Risk and compliance metrics
    • Incident rates, security events, audit findings.
    • Completion of mandatory controls (e.g., reconciliations, checks, reporting).
  • Continuous improvement
    • Expected year-on-year productivity improvements or cost reductions.
    • Innovation commitments (e.g., number of improvement initiatives or automation opportunities per year).

Go beyond SLAs to experience-level agreements (XLAs) where appropriate: measures of how internal users or customers actually experience the service, not just whether tickets closed on time.

Governance forums and routines

You should treat major vendor relationships similarly to internal business reviews:

  • Operational reviews (weekly or monthly)
    • Focus: volumes, SLA performance, incidents, immediate fixes.
    • Participants: vendor delivery managers, internal process owners, vendor managers.
  • Tactical / improvement reviews (monthly or quarterly)
    • Focus: root causes, improvement initiatives, capacity issues, upcoming changes.
    • Participants: functional leaders, CoE reps, vendor leadership.
  • Strategic reviews (semi-annual or annual for strategic partners)
    • Focus: long-term roadmap, innovation, pricing models, structural changes, risk.
    • Participants: senior executives on both sides.

The TOM should specify, at a minimum:

  • Which vendors fall into which cadence.
  • Who owns each relationship internally (single accountable “vendor owner”).
  • Standard templates for performance packs (to avoid every contract having its own reporting style).

Risk management and exit options

Vendor relationships can fail or need to be rebalanced. Treat this as part of the operating model:

  • Identify concentration risks:
    • Single-vendor dominance for critical services.
    • Excess dependence on one location or site.
  • Design fallback options:
    • Contractual rights for transition assistance and knowledge transfer.
    • Ability to dual-source key services or move some volume to other providers or back in-house over time.
  • Ensure data and IP protections:
    • Clear rights to your data, including formats and hand-back obligations.
    • Limits on how vendors can reuse your process knowledge or models.

A simple vendor governance checklist for your TOM:

  • Have we segmented vendors and assigned internal owners for each important relationship?
  • Do we have standard SLA and XLA templates aligned with our TOM KPIs?
  • Are governance forums and review cadences defined for strategic and key operational vendors?
  • Do we have visibility on risk, concentration, and exit options for critical services?
  • Are vendor metrics incorporated into our own performance dashboards, not tracked in isolation?

If you can answer “yes” to most of these, your sourcing and partnership choices are becoming an integral part of the operating model instead of a parallel universe of contracts.

How to get started

1

arrow-down-blue

Tell us about your project

2

arrow-down-blue

Interview candidates

(We’ll provide bios within 48 hours on average)

3

Select your consultant and start work

Find a Consultant

or email us at: [email protected]