GCC Build OSv0
/api

Vendor strategy — confirm strategic-partner-by-tower as future-state.it.decisions.d07

P0 G

Summary

Replaces opportunistic engagement model. Decision owner (sheet): IT Head + Procurement. Sheet target: Wk 2.

Rationale prompt skeleton

Capture the rationale for this decision. Sheet-recorded justification: "Replaces opportunistic engagement model.". Reference the evidence questions, name the alternatives considered, and explain how this decision propagates to design, BoM, and operating model.

Default options (2)

strategic_by_tower Strategic partner per tower (target)

Single named vendor per tower (network, endpoint, EDR, M365, ITSM, SOC, helpdesk) with multi-year commercials.

Pros
  • + Volume leverage
  • + Knowledge continuity
  • + Faster new-site setup
Cons
  • − Concentration risk
  • − Exit cost
opportunistic Opportunistic engagement (status quo)

Vendor selected per project; no group-level partnership.

Pros
  • + Project-by-project flexibility
Cons
  • − No continuity
  • − No volume leverage
  • − Repeat onboarding cost

Default approval chain

  1. Admin
  2. ExecutiveViewer

Linked evidence questions (4)

id prompt workstream
it.vendors_contracts.q01 Strategic vendor assignment by tower (network, endpoint, EDR, M365, ITSM, SOC, helpdesk) — exists today? Or opportunistic engagement? it.vendors_contracts
it.vendors_contracts.q02 Existing MSAs / framework agreements at group level (incl. ours). Duration remaining, renewal options, scope expansion clauses, exclusivity. it.vendors_contracts
it.vendors_contracts.q05 Per subsidiary: who delivers new office setup today (network, server, cabling, AV)? Named partner or ad-hoc? Knowledge-continuity gap evidence. it.vendors_contracts
it.vendors_contracts.q07 Across the asset base: where support contracts can/cannot be claimed (e.g., support purchased in India, asset deployed in UAE). Audit gaps. it.vendors_contracts