ITIL recognizes that services cannot be offered in isolation; they require plenty of continuous support to complete the delivery, and the support of external parties. These external parties could be customers, users, sponsors, suppliers, or other agencies that could hold a stake with legislation and other compliance parties.
- 1.
Relationship management
- 2.
Supplier management
- 3.
Service level management
You can expect between two to three questions to appear from this chapter.
Relationship Management
Not all stakeholders measure up equally in the scale of importance. Some could be like a lifeline for a service provider, while others could vary on a scale of importance. So, logic dictates that not all the stakeholders will be treated equally. Each of the stakeholders is engaged at a separate level to get the most value at every identified stage.
At a corporate level, we engage with stakeholders at a strategic, tactical, or operational level. Let us take an example of an IT company that uses MS Teams for collaboration. The company’s success in delivering to their customers depends on how well their teams can collaborate with the other involved teams. So, MS Teams becomes all the more important; Microsoft will be treated as a strategic partner, and they would enter into agreements to ensure that the company gets the latest updates and product road maps visible well before other normal customers. The strategic relationship looks at a long-term relationship. The same IT company partners with a cab company to commute their employees to and from their homes. There is an agreement that the cab company retains the prices for the entire calendar year and also makes any number of vehicles available within the hour. This is a tactical relationship that helps the company look ahead in a medium term. Then there are operational transactions where the company procures or transacts on a case to case basis. For example, they could place an order for one thousand cartridges for their printers. There is no burden of relationship between the supplier and the company. It’s transaction based. There need not be relationship managers meeting officials in the company from time to time exploring options to help further their businesses.
ITIL Definition of Relationship Management Practice
The purpose of the relationship management practice is to establish and nurture the links between the organization and its stakeholders at strategic and tactical levels.
Relationship Management Activities
- 1.
Identification
- 2.
Analysis
- 3.
Monitoring
- 4.
Continual Improvement
Stages of relationship management
Value co-creation formula
The various stakeholders of products and services have their own set of requirements, and understanding it wholly and completely is essential. Plus, some requirements will be more important than the others, so it is important to understand the prioritization of the requirements as well.
The prioritization and requirements per se are not set in stone and are quite likely to change regularly. So, it is essential that regular conversations take place and ensure relationships are transparent to open up completely.
At a strategic and tactical level, value co-creation must be the objective. Conflicts, if any, must be sorted out—the earlier the better.
Manage customer satisfaction; take necessary steps to keep customers happy. Also handle customer complaints and escalations.
The relationship management practice was first introduced to ITIL in the ITIL 2011 version as the business relationship process. It was considered as a big brother to the service level management process, which we are going to look at later in this chapter.
Engagement in Service Value Chain
Relationship Management in SVC
SVC Activity | Involvement | Details |
|---|---|---|
Plan | High | Requirements are passed onto Plan for planning exercise. Keeps a finger on the pulse of the market trends, which determine strategic direction undertaken including portfolio decisions. |
Design and Transition | High | Feedback from customers is passed on to Design and Transition, which improves the service and reduces the possible kinks. |
Obtain/Build | Medium | This activity gets to hear the requirements from the horse’s mouth, which reduces possible problems coming from misalignment from Plan activity. |
Engage | High | Engage deals with third parties, and relationship management exists to build the bond with stakeholders. |
Deliver and Support | Medium | Feedback on services is passed to the Deliver and Support activity. |
Improve | High | Services are improved on the back of strong relationships with customers and other stakeholders and the open feedback received. |
Supplier Management in SVC
SVC Activity | Involvement | Details |
|---|---|---|
Plan | High | The sourcing strategy comes from the supplier management practice under Plan. |
Design and Transition | High | The requirements, functional terms, and conditions are to be defined by the supplier management practice under this activity. |
Obtain/Build | High | Service delivery from suppliers is directly and indirectly consumed in the Obtain/Build activity. |
Engage | High | Supplier management practice manages suppliers and all their constituent activities in the Engage activity. |
Deliver and Support | High | Performance management is carried out under this activity. |
Improve | Medium | Along with suppliers, improvement opportunities are identified, tracked, and closed in this activity. |
Service level management in SVC
SVC Activity | Involvement | Details |
|---|---|---|
Plan | High | Operational service performance influences the planning activity around services and service portfolios. |
Design and Transition | Medium | Feedback on operational service performance will influence the designs of existing and future designs. |
Obtain/Build | Medium | Obtain/Build will receive service levels for services and components, and the various reporting capabilities that are necessary. |
Engage | High | Service levels will act as a critical input for engaging with various stakeholders and the core of service reviews. |
Deliver and Support | Medium | Deliver and support will receive service levels that they need to keep up with. |
Improve | Medium | Feedback received from customers will act as an input to Improve activity for initiating improvement activities. |
Supplier Management
Supplier management practice is one of the mature practices in the ITIL framework. Before I get into the practice details, the word supplier must be understood.
A customer obtains services from a service provider. The service provider likely will have other service providers servicing in the form of goods and services. These service providers from the perspective of a customer are called suppliers. In short, a service provider’s service provider is referred to as a supplier. Outside of ITIL, suppliers are also referred to as vendors.
ITIL Definition of Supplier Management Practice
The purpose of the supplier management practice is to ensure that the organization’s suppliers and their performances are managed appropriately to support the seamless provision of quality products and services.
Supplier Management Activities
This is a vast practice and it manages several activities. The primary ones are as follows.
Supplier Strategy and Planning
The practice is expected to draw a strategy for identifying and planning the activities that the suppliers will manage. This strategy is drawn from the customer’s requirements and the capabilities of the service provider.
The service provider will evaluate what parts of the service can be inherently offered and which ones are to be sourced from a supplier. Based on the analysis and decision making, suppliers are chosen and their engagement is planned.
Supplier Evaluation and Selection
The role of a supplier is up for grabs. Many prospective suppliers pitch their goods and services to the supplier management practice, which is tasked with evaluating and selecting suppliers. The evaluation and selection is normally done through a request for proposal process where the suppliers are technically evaluated first based on their response to a preset questionnaire. Then, among the shortlists, commercial factors come into play while selecting the supplier.
Contract Negotiations
The second round of selections involving commercial factors comes under the contract negotiations activity. While capable suppliers are shortlisted, the best among equals are determined based on commercial factors.
Contract negotiations happen at multiple levels, and it may not always happen at the beginning of a relationship. Contracts are reviewed on a periodic basis and rate negotiations carried out depending on the market circumstances.
Drawing up new contracts, renewing existing contracts, and terminating contracts are a result of this activity.
Supplier Categorization
Under relationship management practice, we looked at the practice working with strategic and tactical stakeholders. The supplier management practice is responsible for categorizing suppliers into three categories generally: strategic, tactical, and operational. The most important suppliers (strategic and tactical) will be additionally managed by the relationship management practice.
Managing Performance
The suppliers are not exempt from measuring their effectiveness and efficiencies. The service provider carries out regular performance checks to ensure that the supplier is holding up its end of the bargain. If the supplier falls short, this may be grounds for termination of their contract.
Before managing performance and during contract negotiations, KPIs and SLAs are agreed, and the terms of measurement too are defined.
Sourcing Strategies
An organization can choose a supplier strategy based on various circumstances among security, legal, and legislative aspects. The decision to choose one or the other is purely strategic in nature, and every company might choose to go in a different direction.
- 1.
We want one service provider to handle everything, which leads to single point of management coupled with optimum rates coming out of the collaboration that can be achieved.
- 2.
Development is a different piece of cake from support. The expertise required is different as well. We need service providers who are leaders in their industry, so splitting development and support is the best option.
- 3.
It is too risky to put all our eggs in one basket. We don’t want any of the service providers to feel that they can hold us to ransom by managing all our services. So we split the application into multiple parts and hand it over to different organizations. We understand that the costs could escalate, but we are not an organization that’s price sensitive for the development and management of this application.
Let us look at the different sourcing strategies that are employed.
Insourcing
Although insourcing is fast becoming extinct, there are companies that want to do everything on their own. The products and services are delivered within the same organization.
Outsourcing
The delivery of products and services is handed over to different organizations. The tenets are the same as insourcing. Instead of an internal organization providing services, it is handed over to an external one. This has been quite popular over the last two and a half decades.
Single Sourcing
Single sourcing is like outsourcing, but all products and services are handed over to a single service provider. In some cases, it could also be an external service integrator managing multiple service providers on behalf of the customer. Having a single supplier has its advantages in terms of ease of collaboration, sharing of knowledge, and cost optimizations.
Multisourcing
The delivery of products and services is not handed over to one but to multiple organizations. The division of services could be on the lines of capability or geographic sense. For example, organizations that are supreme in SAP could get the SAP part of the application, an organization that is commercially reasonable could get the generic parts of the application, and infrastructure support could go to a company with relevant expertise. This way, the customer gets the best of all worlds. Managing multiple service providers is going to be a challenge though. This is mitigated by bringing a service integrator into the picture.
Engagement in Service Value Chain
Service Level Management
ITIL Definition of Service Level Management
The purpose of the service level management practice is to set clear, business-based targets for service levels, and to ensure that delivery of services is properly assessed, monitored, and managed against these targets.
ITIL Definition of Service Level
One or more metrics that define expected or achieved service quality.
It is a measure of a service that is agreed upon and defined that is deemed minimum for a service to be fit for purpose and fit for use. For example, when you order a pizza from Domino’s, the pizza company advertises that it will deliver within 30 minutes (in some geographies) or the pizza is free. The 30 minutes is a metric or a service level that is defined and tracked to ensure it is met. If it is not met, then the consequence in the IT world could be followed by penalties, which is equivalent to a free pizza if the delivery took longer than 30 minutes.
Primary Activities of Service Level Management
- 1.
Agree service levels with the customers that are binding. Example: availability levels, capacity levels, incident resolution timelines, etc.
- 2.
The practice ensures that the service provider organization meets the agreed service levels. The practice has an oversight of the various service levels and although it may not directly manage service delivery teams, the service level management practice is accountable to meet the service levels. To do this, the practice monitors the service levels, collecting, analyzing, and reporting the service levels back to the customer.
- 3.
Regular service reviews are performed, especially if the service levels are less than adequate, to identify the root cause and to ensure that corrective actions are put in place. If improvements are necessary, it feeds into the Improve activity in the service value chain.
- 4.
Following up from the service review activity, the practice logs all the shortcomings and issues back to the customer and other stakeholders including internal management.
Remember that all the agreed service levels are against a service and not individual components of a service. For example, the service availability of an end to end service is measured. The individual servers that make up a service, although their individual availabilities are measured, do not come under the ambit of the service level management practice as long as the service is not impacted.
Service Level Agreements
ITIL Definition of Service Level Agreement
A documented agreement between a service provider and a customer that identifies both services required and the expected level of service.
The service levels that are agreed with the customers are put together in a document called a service level agreement (SLA). This document is generally appended to the contract document between the customer and the service provider. A good practice is to map the SLAs against the parameters of services that directly or indirectly impact business processes.
Service level requirements (SLRs) are the set of expectations that the customer puts on the table with respect to IT services (or aspects of it). SLRs are aligned to business objectives and form the basis for negotiating and agreeing to service levels between the customer and the service provider.
To state a few examples of SLRs, the customer might ask for critical incidents to be resolved within the hour, might ask for changes to the systems to be implemented within a day, and might ask for 100 percent availability of Internet service. Not all SLRs are feasible, even by the top service providers. In fact, the cost of services tends to go up exponentially as the service level requirements hit a high percentage. So, the art of negotiation is to find the balance between the service levels and the cost of providing services.
Then there are some SLRs that are impossible to match, even by the best of service providers, perhaps implementing system changes within a day. Not all changes may be feasible given the timeline, as changes need to be developed, tested, and then deployed. It takes a lot of planning, coordinating, risk measures, and countermeasures. If the service provider signs off on an SLR stating that all changes would be implemented within a day, he would be setting himself up for a grand failure.
A service catalog is a collection of all services that the service provider offers; it’s like a restaurant take-out menu. So, when an SLA is defined, it must be referenced to the service catalog and not be arbitrary.
There are a number of ways service levels can be defined and agreed. A service may have multiple facets and each of them could be a service level to be defined and tracked. Achieving all but one facet may look green on the outside, but the customer could be hurting based on a particular area where the service levels had dropped below expectations. Therefore, it is important to define service levels in conjunction with the context of the business. For example, if an Internet service provider provides over 99 percent availability of services in a period of a month, it may still not be sufficient if the Internet availability is not 100 percent during the processing of month-end activities. So, a good SLA document breaks it down into two sections or maybe three: one for month-end, one for general working hours, and the other for nonworking periods. And the service provider can claim that all things are going well if the month-end and working hours service availability are in the green.
The SLA must be drawn between the service provider and the customer. It is important, however, to ensure that on the business front, all relevant stakeholders agree to the levels and also are aligned on the service provider’s organization. This is critical, because you want the service levels to match with the actual business processes; this is taken care of when the right business stakeholders are involved. Also, the expected service levels must be feasible to arrange from the service provider’s side. So, it is imperative that the delivery organization along with the design team is involved before finalizing the agreements.
I mentioned earlier that the SLA document is an addendum to the contract document. It is expected that the contract document is worded legally, but the SLA document must be devoid of all things legal. It must be put down in a simple and straightforward manner, and devoid of ambiguity. This will ensure that both the business and service provider understand what the agreement states after the lawyers are no longer involved. This will ensure maximum alignment between the parties.
The Watermelon SLA Effect
You know that a watermelon is green in color. When you cut into it, the insides are red. A thing being green on the outside but red on the inside is a popular metaphor in the service management world.
Consider the example I quoted earlier about the Internet availability levels. Meeting 99.9 percent availability in a month is no mean achievement. And yet the customer is not happy. Why? Because the Internet failed 0.1 percent of the time during the last working day of the month, the period when the month-end jobs were getting processed. This 0.1 percent Internet failure contributed to various delays and the customer did not meet his targets.
The customer does not appreciate the Internet service even though it rates high on the availability scale. In other words, the SLA for Internet availability is green because the SLA states that a minimum of 99.5 percent is to be achieved. However, it is red from the customer’s perspective because it failed them when it mattered. Just like a watermelon: green on the outside and red on the inside.
This is a common mistake that happens time and time again. Both parties must ensure that the right business parameters are considered, and SLAs are drawn to avoid the watermelon effect.
Engagement in Service Value Chain
For the activities in the service value chain, the service level management practice acts as an input and acts as the voice of the customer from an operational standpoint.
Knowledge Check
- 8-1.Which of the following stages does not feature in the relationship management practice?
- A.
Identification
- B.
Analysis
- C.
Monitoring
- D.
Continuous delivery
- A.
- 8-2.What is a supplier?
- A.
A supplier services the customer as a service provider for goods.
- B.
A supplier is generally a service provider for a service provider.
- C.
A supplier is contracted by the customer to manage the customer’s service providers.
- D.
A supplier is engaged by a service provider to engage with the customer and offer services.
- A.
- 8-3.Relationship management practice deals with the customer at what levels?
- A.
Strategic, tactical, and operational
- B.
Strategic and tactical
- C.
Tactical and operational
- D.
Strategic
- A.
- 8-4.What is the objective of service level management?
- A.
The service level management practice exists to ensure that the supplier details are documented in the contract between the customer and service provider organizations, and the performance of suppliers is tracked.
- B.
The service level management practice exists to ensure that the service providers and suppliers agree on the service levels for the services offered to customers, and they are tracked.
- C.
The service level management practice exists to ensure that the customer agrees to the service levels that can be delivered by the service provider.
- D.
The service level management practice exists to ensure that the service levels are agreed between the customer and service provider organizations, and they are tracked.
- A.
- 8-5.Which activity in the service value chain is responsible primarily for providing feedback from customers?
- A.
Deliver and Support
- B.
Obtain/Build
- C.
Engage
- D.
Plan
- A.
- 8-6.Which of the following is not included in an SLA document?
- A.
Service levels
- B.
Service objectives
- C.
Metrics
- D.
Key performance indicators
- A.