ITIL: Introduction

IT services management

Best practices can be obtained from several sources:

• Experience and knowledge of the supplier (monitoring service owner)
  • As a rule, strict organizational constraints are poorly documented and difficult to apply to other organizations;
  • May be highly confidential due to company secrecy.
• Industry standards
  • Differences between various elements are well documented and verified.
  • These include ITIL, PMBoK, ISO 9000, ISO/IEC 20000, ISO/IEC 27001, Prince2, COBIT, CMMI, Six Sigma, Lean, MOF, etc.
• Training and research
  • Typically based on standards that enable staff to acquire the necessary knowledge and skills.

---

Services, Customers and Stakeholders

According to ITIL the services is:

It is a means of providing a benefit to the customer by assisting him in achieving the results he expects, without burdening the customer with the risks and costs of execution.

To clarify this, it’s worth imagining a telephone service: the consumer doesn’t think about the technology and means of providing them with the ability to communicate over the phone; they simply use something that wasn’t created by them. At the same time, everything has to be paid for, and the consumer, of course, understands this and pays for the service without assuming the cost of operating the telephone exchange, personnel, communication channels, equipment, etc., and without risking virtually anything.

ITIL understands the result as follows:

IT service result is the result of the service provider’s actions leading to the receipt of what the customer wants to receive.

IT service

This is a service provided by an IT service provider. An IT service is a combination of IT, processes, and people. Direct services provided to the service consumer should contribute to improving business processes, and their quality is defined in the SLA. Other services, which are auxiliary, are not provided directly to the customer but are necessary.

Although the service consumer bears no financial burden or risk for the service, the cost of the service must be manageable and controllable. Cost is expressed in terms of Return on Investment (ROI) and Total Cost of Ownership (TCO). The service consumer doesn’t need to know the full cost and its origins, but they do need to know the final cost and the value of the service’s benefits to understand its necessity.

Customers

Exposed by two types:

Internal Customers. These are people (a department, group, community, etc.) working within the organization. For example, when an internal HR department makes payments for services.

External Customers. These are people who are not employees of the organization or who work under a contract. Payment for services is determined by the contract and is made through invoice payments, bank transfers, etc.

Regardless of the type of Customer, services must be provided in accordance with the [Stated Level of Service (SLA)].

Stakeholders

Like PMBoK, ITIL considers any individual or entity with some ability to influence a service or an interest in it to be a Stakeholder. However, ITIL also identifies several key groups:

• Customers. They purchase services. They define service requirements and set SLA Levels, but at the same time, they may not be the primary consumers of the service. As noted earlier, they are divided into Internal and External;
• Users. Those who use the service on a daily basis. An important aspect of interaction with Users is keeping them informed about their interests. For example, keeping them informed about the status of a problem or Incident. Users should also be informed of the agreements relating to the service (see Service Level Management). This can be achieved, for example, by providing them with a Service Catalog.
• Suppliers. This group includes those who sell services or products necessary for the implementation of the target service. For example, an internet or telecommunications provider, a software vendor, etc.

Services

ITIL also distinguishes between types of services: External and Internal. Internal Services are provided between different departments within a single organization. External Services are provided to an External Customer.

Often, delivering a service requires combining the efforts of External and Internal Service Providers. This, of course, entails additional costs.

Types of Services

Core Services. Services that generate the primary outputs consumed by one or more customers. These are services that the customer needs and is willing to pay for. For example, providing an organization with email.

Enabling Services. These are services necessary for the providing of Core Services. For example, ensuring the availability of email requires power, stable operation of servers, software, and the network, as well as the availability of personnel to maintain them.

Enhancing Services. These are services that make Core Services more convenient and attractive to the customer. For example, providing access to email through a web portal on a smartphone.

Type of Service	Definition	Description
Supporting (Infrastructure) Service	A service that is not visible to the Customer, but is necessary. For example, a service for maintaining error logs for various software	Sometimes these services are not shown to the Customer because they are needed only to provide Customer-facing Services. If the Service owner cannot explain why the service is needed, then the question of its feasibility arises. An SLA may not apply to this type of Service, but an Operational Level Agreement (OLA) should always apply to them.
Internal Customer-facing Service	An IT service provided to an Internal Customer directly for the organization’s operations, such as an ERP system, a reporting system, etc.	Defined by the business – if they can’t describe it, it’s a Supporting (Infrastructure) Service. Typically implemented using Supporting (Infrastructure) Service. Execution is monitored using SLAs.
External Customer-facing Service	A service provided to an Internal Customer – for example, providing Internet access	Provided to an external customer and paid for according to the contract. Completion is monitored using an SLA.

Service Management

ITIL treats Service Management as:

A set of specialized organizational technical capabilities that provide the Customer with certain benefits in the form of Services.

Service Provider

An organization that provides Services to one or more Customers.

The role of the Service Provider is to understand the business requirements for Services and provide them efficiently and at a cost effective manner (either for themselves or for the customer, depending on the specific case).

IT Service Provider

There are three types:

• Internal Service Provider. Located in the same organizational unit where it provides services. For example, a support Service for several websites owned by a single organizational unit;
• Shared Service Provider. Similar to an Internal Service Provider, except it provides services to more than one organizational unit. It is commonly used in large corporations where the IT department provides Services to several subsidiaries;
• External Service Provider. Provides services to External Customers.

In reality, a IT Service Provider can belong to several of the above types.

IT Service Management, ITSM

ITSM: the implementation and quality management of IT services required by the business. ITSM is implemented by the IT Service Provider through processes, the people and technologies that perform them.

ITSM must meet business needs within the constraints set by the business. This requires good collaboration between the Service Provider and the Customer. This is where three key constraints on IT service delivery come into play: acceptable Cost, acceptable Quality, and acceptable Performance. It is assumed that these three constraints, as well as business requirements for the Service, will be documented in a Service Level Agreement. The SLA should clearly describe the service, the obligations and responsibilities of the parties (Service Provider and Customer), and the required Performance.

Organizing for Service Management

Organizing for Service Management should not and cannot be a universal and it is the manager’s responsibility to apply standards in accordance with the organization’s management policies.

Service Lifecycle

Below is a diagram of the Service Lifecycle:

• Strategy. This is the foundation of the Service Lifecycle – Strategy describes the approach to Service Delivery;
• Design. Describes the principles of Service Design in accordance with stakeholder requirements and the Strategy;
• Transition. Describes the principle of Service Transition from one state to another, as well as the principle of making changes to an existing service;
• Operation. Describes the day-to-day management of the Service, including optimization and improvement activities;
• Continuous Improvement. Describes one of the key management principles - engagement in constant Service improvements.

Processes

ITIL describes the process as follows:

A structured set of operations required to achieve a goal (process results).

Processes are a core component of ITSM, and ITIL itself is built around a process approach. The philosophy of the process approach is presented below:

As can be seen from the diagram, each Process must have three groups of entities defined: Inputs, Instruments, and Outputs.

A Process can use any entities, both IT entities and business entities, as Inputs. Outputs from other Processes are often used as Inputs. For example, the Input for a process providing access to email via a mobile device is a request to receive emails using the appropriate authorization methods and means, software, hardware, etc.; the Input for a Process for identifying software problems is the software itself, a description of the problem, possible sources of the problem, personnel, hardware, etc. To track the need, a Trigger is defined, whose task is to track the need to initiate other Process. The Trigger can be anything, such as an Incident request about a malfunction.

As noted above, any Service has the right to exist only if it is justified by business goals (you remember that the Enabling Services is designed to facilitate the implementation of the ordered Core Service?), and any Process should be performed only if it is determined by the corresponding need - at the foundation of any Process lies the Process Objectives, which can also be Outputs.

To transform Inputs into Outputs, you need to define Instruments, which, by the way, are often incorrectly associated with the Process itself (a Process is a complex of Inputs, Instruments, and Outputs). You can define Roles and Responsibilities, linked by Instructions, Procedures, and Activities that will be performed during the Process, and define Metrics to evaluate the rocess’s performance. It is worth noting that defining Metrics is highly desirable – this allows you to evaluate the quality of the process’s execution. Resources and Capabilities are designed to support the Process.

To simplify the process representation from an ITIL perspective, let’s consider the example of a sawmill. To produce a batch of wooden boards, raw materials—trees—are required (these are the Inputs). Trained personnel (Resources), using equipment (Capabilities and Resources), in accordance with their job descriptions (Roles and Responsibilities), and guided by instructions (Instructions), perform a set of Procedures and Activities. Metrics are used to evaluate the quality of Process execution; for example, in our case, this would be the number of wooden boards that meet stakeholder requirements. Only those wooden boards that meet customer requirements are considered as the Outputs of the Process. The Trigger would be, for example, a production order.

Any process is characterized by the following:

• Measurability. The Process (and its Activities) must be measurable in terms of its effectiveness. It’s also advisable to define several metrics that will allow the Process to be evaluated from various perspectives. For example, management might be interested in cost trends and the quality of the Process, technical specialists might be interested in the number and nature of problems, and users might be interested in accessibility and speed.
• Results. A Process is characterized by its Result. This can be anything, but is usually something tangible, such as a statistical report, a malfunction response, or any other product.
• Stakeholders. The Process must meet the requirements of its Stakeholders, both in terms of Results and the Activities themselves (incidentally, this requirement is quite rare).
• Trigger. The Process must be linked to an event.

Functions

According to ITIL, a Function is any resource or tool that utilizes a process or its Activities (perhaps it would be more accurate to call this entity a functional unit). As you may know, a process must have clearly defined Roles for each participant involved in the Process lifecycle. ITIL divides Functions into:

Group. Resources performing specific Activities. Typically viewed as a group of people, combined (possibly temporarily) into a structural unit. An example would be a group of resources involved in Incident Management;
Team. A pool of resources working on specific, pre-planned tasks. It also differs from a Group in that it is more structured (documented). A classic example is a software development team;
Department. An organizational unit whose resources may perform different types of activities, but whose activities lead to common results. Typically, it functions as a “workhorse” – performing the same type of Activities day in and day out;
Division. A combined group of Departments.

Service Automation

Implementing automation into business processes and replacing manual labor with automated ones allows for:

• Reduce the cost of performing Activities and ensure access to the organization’s services within 24 hours;
• Assess the quality of service delivery;
• Optimize business processes;
• Share accumulated knowledge within the organization.

But remember that only those tasks with clearly defined processes and clear Inputs, Instruments, and Outputs should be automated; otherwise, automation will only add costs and problems. By analyzing an automated service, you can identify its weaknesses and address them, which will lead to improved service quality.