5.3Supplier management & underpinning contracts

Modern services are sustained by many external suppliers-carriers, cloud providers, maintenance vendors, and more. Whether you can keep the SLA promised to the customer depends heavily on the quality of the parts these suppliers provide. But supplier quality does not fall into place automatically; you need an operation that correctly translates the level the customer SLA requires into contracts with suppliers (UCs) and internal agreements (OLAs), and continuously evaluates fulfillment. This section covers the UC (the contract with external suppliers), alignment with the customer SLA, supplier evaluation, responsibility demarcation during faults, and the cloud shared responsibility model-framed as the judgment of a service manager who ultimately upholds the SLA.

5.3.1Aligning UCs and OLAs with the SLA

• An SLA is the service-quality agreement between the service provider and the customer. An OLA is an agreement between internal operations teams (operational level agreement) that underpins the SLA. A UC (underpinning contract) is a contract with an external supplier that underpins the SLA. The three form a supporting relationship in which "the promise to the customer (SLA) is reliably met by internal (OLA) and external (UC) support underneath."
• Key point of alignment: the level UCs/OLAs promise must reliably meet (at least exceed) the level the customer SLA requires. For example, promising the customer "4-hour recovery target" while the UC with the maintenance supplier essential to that recovery says "on-site response by the next business day" means you cannot keep the customer SLA even if the supplier performs exactly to contract. This SLA-UC misalignment is not the supplier's fault but the service manager's design fault, and must be cross-checked at contract signing and review.

5.3.2Supplier evaluation, responsibility demarcation, and shared responsibility

• Supplier evaluation periodically reviews a supplier's fulfillment against the metrics set in the UC (availability, response time, resolution time, etc.) and demands improvement for any shortfall. Even when work is outsourced, accountability remains with your own organization-not "we handed it to the supplier so it is not our concern"; the ultimate responsibility to the customer stays with the service provider.
• A responsibility demarcation (point) is a clear boundary of "how far is the supplier's scope and where does yours begin" during faults or changes. If vague, faults trigger finger-pointing and recovery is delayed. The cloud shared responsibility model is the archetype: for example, in IaaS the cloud provider is roughly responsible for the physical and infrastructure layers (power/cooling/hardware/virtualization platform) and the customer for the OS and above (OS configuration, middleware, application, data, access management) (the provider's scope widens toward SaaS). Understand which layers the supplier covers and design operations accordingly.

Suppose a service manager is responsible for a core service contracted under an SLA that includes a "4-hour recovery objective (RTO) from a major fault." Hardware maintenance for this service is outsourced to an external maintenance vendor, and it is time to review that contract (UC). Checking the current UC, the vendor's on-site response is conditioned as "by the next business day from the call." Here the service manager notices that the customer SLA's "4-hour recovery" and the vendor UC's "next-business-day response" are clearly misaligned. If a major hardware failure occurs on a Friday night, the vendor need only arrive on Monday per contract, by which point the customer SLA is massively violated. This is not the vendor's fault but a design problem on the service manager's side: the contract (UC) underpinning the promise to the customer (SLA) was not aligned to the required level. As responses, the service manager weighs several options. First, negotiate to raise the UC to "on-site within 4 hours for major faults" (naturally at higher cost). Second, so that recovery need not wait for the vendor, secure a spare unit (cold standby) on your own side, switching to the spare on failure to meet the RTO while leaving physical repair of the failed unit on the next-business-day UC. Third, re-discuss with the customer whether the SLA's RTO truly needs to be 4 hours for the business. What matters here is to verify, every time a UC is signed or reviewed, against the customer SLA, whether the structure is such that "the SLA can be kept if the supplier performs to contract." Because ultimate accountability to the customer stays with your organization even when outsourced, the service manager's judgment in supplier management is to keep designing and operating so that the supporting relationship among SLA, OLA, and UC does not break down-rather than leaving it to the supplier.

5.3.3Section summary

• An SLA (provider-to-customer) is underpinned by an OLA (internal) and a UC (contract with external supplier), and UCs/OLAs must reliably meet the level the customer SLA requires
• An SLA-UC misalignment is the service manager's design fault, not the supplier's, and must be cross-checked against the customer SLA at every UC signing/review; accountability to the customer stays with your organization even when outsourced
• Clarify the responsibility demarcation for faults, and design operations understanding the cloud shared responsibility model (in IaaS the provider owns the infrastructure and the customer the OS and above; the provider's scope widens toward SaaS)