ITIL: Design

Service Design

Service Design is involved in the creation of new services and modifications to existing ones, ensuring adherence to Service Strategy principles, which, in turn, lead to the achievement of business goals. Planning can be conducted not only considering existing circumstances but also looking ahead, which can save costs on changes to newly created services. Service Design encompasses a wide range of related IT and non-IT (business) areas, utilizing them to plan service implementation.

The goal of Service Design is to plan a service that best aligns with strategic goals. This includes planning not only the service’s implementation but also the processes and rules it will use. Service Design should ensure that the service is delivered within the specified constraints (timeframe, budget, resources, etc.), and that the service provided will meet the stated quality level. Service Design primarily ensures the Warranty of Service Delivery (remember that service quality is determined by Utility, as well?). Furthermore, Service Designing involves describing the conditions and steps for transitioning the service from one stage to another (i.e., the Service Transition stage) using the Service Design Package.

The task of Service Design is to plan new services that must comply with the Service Strategy, but the strategy can change, technologies can become outdated, and existing services are not always ideal, so the tasks of Service Design also include changing existing services.

Service Design includes the following:

• Design Management;
• Service Catalog Management;
• Service Level Management;
• Availability Management;
• Service Capability Management;
• Information Security Management;
• Vendor Management;
• Service Continuity Management.

What is provided to businesses?

• Reducing the cost of services provided;
• Integrating newly created/modified services into business processes;
• Creating or modifying services in accordance with requirements;
• Defining easily understandable metrics that will help describe the quality of the service provided. This will facilitate further service improvement.

Service Design Package

ITIL recommends that the Service Design stage results in the creation of a Service Design Package, which should describe all aspects of the service throughout its lifecycle. This may include:

• Verified service requirements;
• Description of how the service is planned to be used;
• Key Stakeholders;
• Functional requirements;
• Organizational requirements;
• Service level requirements;
• Technical requirements for the service, such as software, hardware, network communications, technologies, documentation, etc.;
• Outsourcing strategy (e.g., how to choose between free or paid software?);
• Processes required by the service;
• Organization’s readiness to receive/provide the service;
• Service lifecycle plan, aligned with the calendar. It is advisable to plan each stage separately in more detail;
• Operational activity plan;
• Service Acceptance Criteria.

Service Design key elements

When planning, there are four elements to consider (sometimes referred to as the 4Ps):

People. Previously, we discussed the concepts of Resources and Capabilities. In relation to People, these should be viewed as the availability of certain personnel and their knowledge and skills, respectively. When designing a Service, it is necessary to calculate the quantity of each resource required, as well as the knowledge and skills they must possess.

Processes. In addition to the service itself, ITIL recommends planning and documenting all processes that may be used to deliver the service in advance. Failure to plan a process in advance can lead to problems during service delivery, leading to additional costs. One recommendation is to make the designed processes as flexible as possible — this will allow them to be modified as needed with minimal loses.

Products. Products include not only tangible goods, but also various services, intangible goods, and so on. The purchase of Products must also be documented.

Partners. These are individuals who are somehow connected to the Service but are not directly involved in its provision or use. Most Partners are Suppliers of goods or services. Their management will be discussed later.

Building the Service

When creating a service, you should:

• Ensure that all service Utility Requirements are met and that the Service supports the company’s strategic plans;
• Expected level of service provided;
• Specify all technical aspects of the Service using the Configuration Management System. The required hardware should also be described;
• Describe the software and data involved in the service processes;
• Document all processes, including both Core and Enabling processes. It is also important to include contact information.

Key Service Design aspects, STAMP

Service Solutions

First, it’s necessary to define the Service Solutions — what the Service entails and how it will be implemented. This will call for requirements (defined in the Service Portfolio). The Customer job is to define the Service requirements, while the Provider job is to provide the necessary services within organizational, technical, time, financial, and other constraints. The Service Provider is responsible for choosing the service implementation method, but it must comply with corporate policies and not disrupt other processes.

Management Information Systems and Tools

They are used to automate processes and are typically part of an enterprise system. During Service Design, it is necessary to integrate a new or modified service with the management systems in use.

Architectures

A new or modified Service must integrate into existing information systems or business processes without disrupting them. Therefore, it’s desirable for the designed Service to comply with various standards.

Measurement System

If you remember, any service must be measurable, i.e. its effectiveness must be assessable – the designed system must be compatible with the current Measurement System, and if necessary, appropriate changes must be made to it.

Processes

Each service introduces new processes or modifies existing ones. Processes must be structured and designed to ensure their implementation is as efficient as possible. They must also have inputs, triggers, and outputs.

Service Level Management Process, SLM

One of the most important processes, as it creates the foundation for the service, defining a list of key requirements, and builds a vector for service management.

SLM does not track Utility

Goals

Ensuring that the provided and planned services deliver exactly the results defined at the time of agreement. The process’s responsibilities include defining the Service, documenting all its components (especially the business interface), and defining rules for measuring the effectiveness of service delivery — in other words, it is a preparatory process that defines a general understanding of the service requirements. As noted earlier, all processes in ITIL are interconnected, including Service Level Management — this process closely interacts with the Business Relationship process, primarily with regard to Service Level Management, SLM. When discussing service levels, IT and the business should discuss only measurable and achievable goals, defining clear scope, deadlines, budget, and service evaluation criteria. Criteria should also be clearly described, starting with their strategic importance. In addition to the above, these processes interact to determine the customer’s level of satisfaction with the service provided. To achieve this, the Service Provider must constantly communicate with the Customer to determine their satisfaction with the service provided. Focus groups, surveys, and other methods can be used to collect this information. It is important to understand the differences in these processes: the Business Relationship process is more strategic in nature, responsible for interactions with the Customer on a more global level, while the Service Level Management Process monitors the quality of the Service to which it is assigned.

Another objective of the Service Level Management Process is to engage in Continuous Service Improvement. To achieve this, the Service Level Agreement, SLA must define a Service Improvement Plan.

Since any IT service can consist of several elements, managing the level of each of these elements is a good style of execution of the Service Level Management Process – poor management of any element inevitably leads to a degradation in the level of provision of the entire service.

Finally, the Service Level Management Process is responsible for measuring and reporting the level of service provided, and the methods for collecting and reporting this information should be described in the Service Level Agreement, SLA.

Service Level Requirement

These are based on the Customer’s requirements and should be described in the Service Level Agreement, SLA, and the Service Level Management Process should ensure that the business expectations are met as agreed.

Of course, these Service Level Requirements, SLR reflect (albeit, indirectly) business goals. For example, providing email access might include 24-hour email access, data transfer speed and volume, security requirements, and so on. The quality and completeness of these SLRs largely determines the quality of service provided, as well as the Total Cost of Ownership, TCO.

Again, the requirements must be clearly defined, unambiguous, and somehow controllable (verifiable or evaluable).

Service Level Agreement

This document is crucial for the planned (and existing) service – it defines key aspects of the Service (quality level, responsibility, evaluation criteria, etc.), as well as the scope of the service (what the service entails). It is crucial to draft this document clearly and comprehensively, as it is legally binding. However, when providing the service within a single organization, unnecessary legalese should be avoided. The SLA should be written in simple and accessible language, avoiding technical terminology whenever possible (if terms are present, they should be described in detail in a glossary attached to the SLA).

SLA content

First and foremost, an SLA should describe the purpose of the Service provided. These purposes typically represent the Customer strategic business objectives. The agreement’s terms should be clearly defined. It’s also highly recommended to maintain version control and revise the document at least once a year, even if no changes have been made.

It’s important to distinguish between Service Support and Service Delivery. For example, an SLA might describe Service Delivery for at least 23 hours, but Service Support for 8 hours from 10:00 AM to 6:00 PM. This also applies to other aspects, such as the quality and quantity of incidents.

Service availability should be specified separately. If you specify a clear limitation on service availability (e.g., 24 hours), you should protect yourself by describing instances of service unavailability for which you are not responsible (should IT be held responsible for a power outage at the electricity station?).

Service restoration deadlines in the event of malfunctions must be clearly defined. The nature of the malfunctions for which IT is responsible and the timeframe for their resolution must be defined. However, to be fair, it’s worth noting that IT is better off using a “floating” definition of deadlines, as malfunctions can be critical to service restoration.

The SLA must outline the set of measures to be used for information security (cryptographic methods, requirements for passwords, frequency of password changes, etc.).

A description of Incident Levels — their quantitative and qualitative characteristics, and expected resolution timelines — is also important.

If either party requests changes to the Service Level Agreement, SLA, the reasons for these changes must be identified and discussed by representatives of both parties.

Finally, the service’s funding sources, procurement methods, reporting procedures, frequency and purpose of meetings, and attendance must be listed.

How to compose?

Any agreement referenced in an SLA must fall into one of the agreement types below.

Operational Level Agreement, OLA

These agreements are concluded between two divisions of a single company for the provision of a specific level of service. They are a simplified version of a Service Level Agreement (as evidenced by the document’s length—it rarely exceeds two pages). Typically, they contain an agreed-upon period of time for service support, incident management, and other fundamental service agreements (see SLA).

Since the Operational Level Agreement, OLA is an agreement between organizational units of the company, it should be drafted with care, avoiding any legalistic excesses. Like an SLA, the language should be simple and accessible to everyone. Where technical terms are necessary, they should be described in a glossary.

It is recommended to update the OLA at least annually, and, of course, whenever there are any changes to the service provided.

Underpinning Contracts, UC

This is another type of agreement that also contributes to the overall Service Level Agreement, but is concluded with an external Service Provider. This distinguishes it from the Operational Level Agreement, OLA, requiring a more formal drafting process.

The Service Level Management Process is responsible for overseeing reporting performed by the external organization. All other SLA characteristics also apply to the UC.

Structuring of Service Level Agreement, SLA

ITIL distinguishes three types of SLA structure:

• Customer-based. In this structure, the Service Provider provides all the services needed by only one Customer. A large number of services can be a significant disadvantage of this type of structure, as it greatly complicates service monitoring.
• Service-based. In this structure, the SLA is focused on only one Service. A description of the Service must be provided to all its users. This type of organization is convenient for organizing large and “bulky” services, such as internet access. However, it also has a disadvantage in terms of organization – for example, if there are two offices, one of which is located in a hard-to-reach area, it is not advisable to use a Service-based SLA structure, as this agreement will be difficult to implement due to factors beyond the control of the Service Provider.
• Multilevel. Divided into three levels: Corporate – contains information that is available to all employees of the organization; Customer – contains information that is only available to the service customer; Service – contains information only about the Service (there may be several such sections, depending on the number of services).

Monitoring and improving the service

Regardless of the service’s objectives, the Service Provider must always provide the Customer with tools for monitoring the quality of the service provided. For example, if the SLA specifies Incident resolution timeframes, the Service Provider must provide full information about any incident upon request, including the date of occurrence, resolution date, resolution methods, etc.

Of course, a newly created service requires increased attention and, therefore, more frequent reporting. It’s advisable to specify this period in the SLA, but you can also specify a milestone event that signals a change in the reporting strategy. As processes stabilize, the service will require less attention and, therefore, less reporting.

For initial monitoring of a new service, the RAG Report is often used, which is a fairly effective and simple tool for tracking service performance.

It’s important not only to track the final state of the target, but even more important to measure the service’s condition—this adds flexibility and allows for faster response to issues.

Nevertheless, to streamline service management, it’s essential to periodically conduct user and customer surveys. It’s important to understand not only the service’s usability, but also the quality of technical support and the speed of response to incidents. ITIL doesn’t limit managers to this — you can gather any information from customers that can help improve the service. ITIL also recommends holding meetings rather than simply using email and other similar tools. It’s recommended to hold them at least once a month, even if no emergencies have been observed, but the meeting calendar should be established in advance so that all participants are prepared. Below is a list of discussion topics that are typical for such meetings:

• Review of recent events;
• Review of Incidents that have occurred since the last meeting (meaning unique Incidents);
• Review of reports for the last month;
• Identify issues based on reports and make decisions;
• Review of the Service Improvement Plan against previously planned goals;
• Discussion of upcoming business developments;
• Announcement of IT changes that may impact the service.

The meetings should result in adjustments to actions, changes to the SLA or other documentation, in particular the creation of a Service Improvement Plan. All meetings should be recorded.

Service Level Management and other processes

SLM interacts with other services:

Process	How it interacts
Problem Management	Identifying and resolving problems helps improve service
Availability Management	Performs Incident resolution using known resolution methods, facilitating the provision of a higher level of service.
Capacity Management	Manages available service capacity to deliver the required service level.
Incident Management	Focuses on resolving Incidents and restoring the system as quickly as possible. Incident resolution speed is typically a separate clause in the Service Level Agreement, SLA.
IT Service Continuity	Ensures service continuity, which, of course, has a significant impact on service Warranties.
Supplier Management	Uses and influences Underpinning Contracts, UC.
Service Catalog Management	Provides information for signing the Service Level Agreement.
Continual Service Improvement, CSI	Regularly interacts with SLM to create the Service Improvement Plan.
Business Relationship Management	Participates in the creation and management of the Service Level Agreement.

Service Improvement Plan

ITIL doesn’t consider fixing an existing defect to be a service improvement. Instead, service improvement is considered something more global, something that entails changes in the service organization. To achieve this, a formal Service Improvement Plan should be created, which should describe the planned service improvement actions, the current state of the Service, the expected results, and other relevant information.

This plan must have specific deliverables, timeframes, financial, and resource constraints. Once adopted, this plan must be entered into the Continual Service Improvement Register.

Service Catalog Management

Service Catalog must contain two views: one accessible to the Customer and one accessible only to IT. The view accessible to the Customer contains information such as the service name, cost, availability, results, etc. The view accessible to IT contains Enabling Services, as well as technical information about the service. Each view should provide only the information needed by the target audience.

The purpose of Service Catalog Management is to maintain the contents of the Service Catalog in a complete and current state. Furthermore, Service Catalog Management is responsible for ensuring that access to information is restricted to authorized users, with restrictions on access being personalized. It should also include services that are yet to be provided; in other words, the Service Catalog should contain all services offered by the Service Provider, but access to information about them should be selective.

Because the Service Catalog Management process must be maintained in an adequate state, it interacts closely with the Service Transition processes — for example, the Service Catalog must be updated when the service state changes. Subsequently, the process’s task is to provide the required data to those requesting it (assuming they have the appropriate permissions).

Service Catalog Management resrictions

A Service Catalog can be represented by a list of all services, but is typically grouped into Service Packages – these are simply combinations of Core, Enabling, and Enhancement services required to implement a business process.

In addition, logical relationships must be built between services in the Service Catalog, which are created in the Configuration Management System.

Availability Management

This is one of the most important processes in IT service management. To manage availability, it must first be defined. Since availability must be expressed in numerical metrics, it must be determined before providing the Service. The most common way to represent availability is as a percentage — this provides the most visual representation for the customer. The percentage availability indicator must be calculated using a formula agreed upon with the Customer. Regardless of the formula, it represents the ratio of the time the service is available to the customer to the agreed-upon time. For example, if the SLA did not describe that the service should be available on weekends, and it turns out that it was unavailable on Saturday at 4:00 PM, this cannot be considered an SLA violation by the Service Provider.

It’s also important to define availability responsibilities when developing an SLA. Reports must specify the time when a specific element is unavailable (remember, multiple Supporting Services may be used to provide a service), not including network interruptions or power outages. At the same time, all reports must be clear and supported by evidence.

Goals

The objective is quite comprehensive: achieving Service availability at the level defined in the SLA, taking into account current and future business requirements. This requires considering all constraints imposed on the Service Provider, primarily financial ones.

It is necessary to strive to continuously improve the service, and these improvements must be economically justified. The Availability Management process includes both identifying necessary changes and identifying the causes of downtime.

Availability Management tasks

• Developing and implementing a plan for implementing availability requirements, including a long-term plan. It is recommended to prepare it 12 months in advance to determine the budget. However, it is subject to change;
• Proposing improvements for both IT and business (e.g., business process organization);
• Results management. In the event of a forced downtime due to the Service Provider, this process closely interacts with the Problem Management process;
• Assessing all necessary steps to implement the change;
• Taking all preventative measures to improve availability;
• Overall monitoring and control of the availability process.

Availability Management boundaries

In fact, this process is used at all stages of the service lifecycle; the only reason it’s considered in Design is because it’s much better to develop an availability management strategy at the very beginning. At the Operational stage, the Availability Management process is designed to identify downtime, participate in root cause analysis, and conduct measurements and risk assessments.

The Availability Management Process is also included in the SLA negotiations, including discussions of Enhancement and Enabling availability, and for this reason, this process is closely linked to the Business Relationship Management process.

In fact, this process touches on virtually everything related to a service, as it will impact service availability to some degree.

Influence on the Vital Business Functions

When delivering a service, IT must first and foremost focus on business needs. To do this, IT must understand the business’s plans and priorities. This will allow IT to prioritize those service components that require increased attention and are considered Vital.

When designing a Service, it’s important to prioritize and identify Vital Business Functions. To understand this, it’s best to use an example: banking transactions are critical to the business, but paying for telecommunications services is a secondary function. It’s important to note that the criticality of certain functions should be determined by the business, but IT should plan the availability management strategy.

Availability

While ITIL emphasizes the identification and resolution of issues that affect service availability as reactive actions for Availability Management, preventative actions include the aforementioned Availability Management strategy planning, as well as risk identification and management.

Availability itself is comprised of two general concepts: Reliability and Resilience. Reliability is determined by the quality of system components (in particular, software, hardware, communications equipment, etc.). Resilience is determined by the service’s resilience to potential problems. To increase service resilience, backup service delivery paths are often created (e.g., by installing redundant network communications, adding server load balancing, etc.) – accordingly, the more backup service delivery paths, the greater its resilience.

However, no matter how well a service is planned, downtime is inevitable. Service quality is then determined by how quickly service is restored – Maintainability – and is calculated as the Mean Time to Restore Service, MTRS:

$$''MTRS''=\frac{''Total\; downtime,\; hours''}{''Number\; of\; breaks''}$$

ITIL recommends considering the total time to service recovery, as this demonstrates the true effectiveness of support – any incident that occurs must be identified, analyzed, assessed, and only then resolved. For Reliability, the Mean Time Between Service Incident, MTBSI metric can be used, which shows how frequently incidents occur.

Serviceability

This is an important metric that allows businesses to assess how well a Service is supported, and IT to analyze weaknesses in service support. For example, when a third-party Support Service is provided, service restoration may take too long due to the remote location of its employees. In this case, the Customer may require the Service Provider to reduce the problem resolution time, for example, by developing on-site troubleshooting procedures (without calling in a Service Provider employee).

Information Security Management

This is a critical process for providing and storing information. The core of this process is identifying and responding to risks. The information security strategy itself must be aligned with corporate security regulations.

Goals

The goal of Information Security Management is to ensure compliance with corporate security regulations, including technical means, behavioral restrictions, and so on. All data must be provided with access restrictions in mind, using technical means that meet relevant quality requirements. When transferring data to external organizations, its integrity and security must be ensured.

Information Security Management boundaries

Essentially, this process covers all data that is involved in the organization’s work in one form or another.

Information Security Policy designing

To do this, it is necessary, at a minimum, to understand the principles of the organization’s adopted security policy. During development, it is crucial to secure the support of the organization’s management. Typically, an Information Security Policy addresses the following aspects:

• IT Asset Usage Policy;
• Access Policy;
• Password Control;
• Email Policy;
• Internet Policy;
• Antivirus Policy;
• Information Classification Policy;
• Remote Access Policy;
• Policies for Providing Data to External Organizations;
• Copyright Compliance Policy – some companies shift complete responsibility to the employee;
• Resource Release Policy;
• Information Collection and Storage Policy.

Different services may have their own rules regarding Information Security, but they are generally more stringent than the general policy.

Notifying employees about Information Security

ITIL recommends enforcing the Information Security Policy among all employees, regardless of their status. While organizing this information flow falls more under the responsibility of HR, the IT manager is obligated to promote compliance with the organization’s Information Security Policy.

Supplier Management

ITIL defines Supplier Management as the process of exchanging money for needed goods. When designing a service, it’s important not only to select the right suppliers but also to negotiate profitable contracts with them for you (the Customer).

Goals

The goal of Supplier Management is to ensure that the Service Provider will provide the services they are reponsible to. Since the exchange is monetary, the process also includes control over payment (including regulation, volume management, timeliness, etc.) for services.

Supplier Management tasks

This primarily involves choosing the right suppliers and drafting profitable contracts. During contract execution, the IT manager must monitor its performance and, if necessary, manage it.

It is important to rank suppliers based on the criticality of the services they provide. To do this, it is first necessary to establish grading rules. The most common method is an assessment based on the risk of the likelihood and severity of potential problems versus the importance of the service provided by the supplier. The matrix for this method is presented below:

• Strategic Suppliers. Those suppliers with the highest level of risk and service importance are key suppliers. Typically, this type of supplier handles large amounts of corporate information.
• Tactical Suppliers. These suppliers have a medium level of negative risks and provide a medium-priority service. For example, internet access or server support.
• Operational Suppliers. These are typically suppliers that provide services of medium or low importance to the company’s business, and the damage from a disruption to these services is insignificant. For example, office equipment repair services.
• Commodity Suppliers. These are suppliers whose services are very low in importance to the business. These include paper supplies, etc. They require little attention and can be easily replaced with other suppliers.

Of course, these examples are not universal and for some organizations, the supply of paper will be critical, but the above is the most common situation.

In accordance with the established gradation, it is possible to approach interactions with suppliers more flexibly.

Capacity Management

Every service is defined by a set of requirements it must meet. We’ve previously discussed the requirements of Security, Availability, and its components (Supplier Management), but ensuring the required service performance is also crucial. This is the responsibility of Capacity Management — the process of managing the IT service and infrastructure to ensure it meets current and future business requirements.

In essence, Capacity Management is an ongoing process, but at the Design stage it influences both the planned/changed service and the organization of other services or subsystems, with the primary goal of ensuring the required performance of services and subsystems. At the Transition stage, this process ensures that the implemented service meets the provided specification; at the Operational stage, it ensures the required performance on a daily basis; and at the Continual Service Improvement stage, it improves the service to achieve the currently defined or future service requirements.

Current service performance requirements should be defined in the SLA, but this doesn’t mean they should stop there. ITIL requires Continuous Service Improvement, including in terms of performance. Any performance improvements should be planned, and the current service performance assurance should be reviewed periodically, but no more than once a year. Furthermore, when any performance-related incidents occur, the Capacity Management process should not only actively contribute to resolving the problem but also participate in preventive actions to eliminate the causes of the Incident.

A service is expected to always meet its stated performance requirements, but this isn’t always easy to achieve, particularly due to seasonal factors. For example, an accounting department preparing reports at the end of a financial year may experience several times the number of requests to the accounting system, especially for large data sets—this phenomenon can occur from January to April. ITIL suggests that this seasonality should be planned for in advance and the service designed with this knowledge in mind.

Changes in service performance requirements affect, in particular, the number of employees required to provide it.

Subprocesses

The first subprocess is analyzing organizational changes and correlating these changes with the IT infrastructure.

The second is Service Capacity Management, which is responsible for the performance of an individual service and its components.

Finally, the last subprocess is Component Capacity Management, which is responsible for managing the performance of each individual service component. Service Providers should preferably require tools or methods for monitoring component performance. Below is a diagram illustrating the interactions between all subprocesses.

Capacity plan

This plan is one of the deliverables of the Capacity Management process and contains the policy for meeting current and future performance requirements. It closely interacts with the Strategy processes.

This plan should be developed for a period of 12 to 18 months and describe the service’s performance requirements for that period. The introductory section should describe the current infrastructure. The main section should explain the rationale for the chosen development path, and it should be based on measurement metrics.

IT Service Continuity Management, ITSCM

This process is responsible for the continuity of IT services requested by the business. In fact, this process is part of the overall corporate process for ensuring business continuity.

This process is responsible for identifying and developing action plans for potential negative risks (for various scenarios) that could disrupt IT services in one way or another. Of course, these plans must fit within the company’s budget allocated for IT services. This can be achieved, for example, by developing an emergency service recovery plan within established timeframes. To identify critical risks, ITSCM uses Business Impact Analysis. Availability and Security Management processes can be involved in risk assessment. The basic idea is that all possible risks must be identified, quantified, analyzed, and reflected in management plans. This should result in a solution that, in the event of an incident, will allow for the restoration of service, if not immediately, then within the timeframes specified in the SLA. If the risk management plans require the involvement of External Service Providers, the process interacts with the Supplier Management process.

When preventing a negative risk is impossible, measures must be taken to either reduce the likelihood of its occurrence or mitigate the damage it causes. A risk response strategy may include both the measures themselves and a plan for testing their application.

As noted earlier, it is necessary to rank services according to their importance to the business—this will help assess the damage should it occur.

Design Coordination

The purpose of Design Coordination is to coordinate all elements of Design. This includes processes, system components, suppliers, compliance monitoring, financial accounting, and so on—everything that is involved in Design in one way or another.

Roles

As with any task, IT management involves a significant number of people, each with their own responsibilities, called roles. When designing a service, it’s important to design not only the processes and activities required to deliver it, but also the roles of the people who will participate in them. It’s worth noting that ITIL allows for a single resource (employee) to perform multiple roles, but it also allows for multiple resources to perform a single role. However, only one person should be responsible for a process or action. Let’s consider the roles ITIL offers:

Service Owner

This is the role owner. Each service can have only one owner, and therefore only one Service Owner. This role must be clearly and unambiguously defined in the service documentation. The Service Owner is ultimately responsible for the service’s delivery, design, and improvement. However, a single process can involve multiple services, and what happens if the process is unstable? Each Service Owner is responsible for the successful operation of the process within their service. The primary responsibilities of the Service Owner are listed below:

• Ensuring the delivery of the accountable service;
• Ensuring that all agreed service requirements are met;
• Communicating with the service Customer;
• Using the Service Portfolio Management process to identify new services (Enabling) or implement changes;
• Ensuring adherence to the principle of Continuous Service Improvement;
• Ensuring the accuracy of metrics in the provided service reports;
• Ensuring an appropriate level of Service Availability and Performance;
• Clear understanding of all service components, as well as an understanding of all possible negative risks associated with them;
• Participating in meetings with the service Customer and providing them with all possible information regarding the service;
• Ensuring compliance with the adopted Information Security Policy;
• Actively participating in the resolution of incidents, especially major ones;
• Accompliance with the service budget.

Process Owner

Responsible for organizing the process. Since a process may involve more than one service, they frequently interact with the Service Owner. Their responsibilities include:

• Developing process strategy, policies, and standards;
• Designing the process and defining requirements for the services it interacts with;
• Defining process evaluation metrics;
• Documenting the process and maintaining its relevance;
• Auditing the process;
• Ensuring the provision of all resources necessary for process implementation;
• Continuous Service Improvement.

Process Manager

Responsible for the daily provision of the Service.

• Interacting with the Service Owner to ensure service delivery;
• Ensuring the deployment of the required number of resources and their assigned roles;
• Monitoring and collecting metrics characterizing the service provided;
• Identifying necessary service improvements;
• Interacting with the Service Owner and the Continual Service Improvement Manager to implement improvements.

Service Practitioner

This role is comprehensive, as it can encompass virtually all roles except those listed above. Their primary responsibility is to perform the actions required to deliver the Service. The full list of responsibilities for this role varies depending on the specific service, but the main ones are listed below:

• Performing specific tasks;
• Participating in Service Improvements.

RACI Model

As noted earlier, all roles should be clearly defined, and the sooner the better. This model allows for this to be done in the most comprehensive and accessible form. The acronym RACI stands for Responsible, Accountable, Consulted, and Informed. The roles are generally self-explanatory.

The matrix itself may look like this:

Once the matrix has been compiled, it is important to ensure that all identified roles are being fulfilled.