Traditionally, IT organizations primarily focused on software and hardware. The requirements of the customers were not always necessarily paramount. Since the end of the 1980s, ITIL^® has been representing the core idea that IT services have to be aligned with the needs of customers. Moreover, companies should explicitly agree with their customers on the provided services. Hereby, effective processes and clearly defined responsibilities are decisive.

As an awareness of service and customer orientation is increasingly developing among IT managers, ITIL^® has become the de facto global standard for IT service management in recent years. 

The ITIL^® recommendations are generally valid—they reflect the requirements of most companies and organizations, regardless of their size or industry.

ITIL^® is constantly being developed further. The latest version of the catalog (Version 4, published 2019) focuses on the topic of end-to-end service management—from demand to value creation.

The role of a company's IT department has been changing fundamentally over the past few years. Nowadays, in addition to in-house software and hardware, it also has to take care of IT services from a wide variety of suppliers. This includes software for payroll, an externally booked ticketing system or the control of the fire protection system. It requires corporate IT to orchestrate, plan and monitor the interaction of internally and externally executed services: IT Service Management (ITSM for short).

In context of this development, the major challenge is communication: ITSM is required to develop cross-company processes. In order to avoid misunderstandings among all parties involved, it is essential to have a uniform level of communication with clearly defined terms and a common set of objectives.

This is precisely why ITIL^® as a common standard is more important today than ever before.

With the previous version, ITIL^® v3, criticism arose that the processes described were too rigid for a meaningful and practical implementation.

Therefore, a lot of emphasis was placed on company- and industry-specific flexibility when revising the ITIL^® standards. In addition, ITIL^®4 includes evaluation cycles so that organizations can react better to trends and environmental influences. Axelos, the creator of ITIL^®, has thus focused on a stronger practical orientation in the development of the latest best practice catalog and responded to the needs of IT service providers.

The topics of cloud, IT security and modern communication tools are also covered.

The so-called Service Value System describes overarching dependencies and basic principles in service management that should apply to all organizations. As with ITIL^®4 as a whole, the SVS aims to increase value. Based on a demand or opportunity, precise instructions for action and process-specific practices are applied in order to continuously optimize services as well as to enhance their value (better quality or resource savings).

• Basic principles: The SVS identifies 7 generally applicable guiding principles that provide practical instructions for action in every industry, company and for any service.
• Governance: In the governance section, suggestions are provided for good corporate governance, since top management is the first point of contact and control in matters of communication as well as strategic direction.
• Service Value Chain: The so-called Service Value Chain defines a series of linked activities, describing the roles of process participants and dependencies of the (sub)activities included. The chain starts with the idea or planning and includes all process-related communication, as well as the design and creation of a product or service. It provides the result and value is generated from this overall process.
• Practices: 34 practices address different topics and are further broken down into 3 categories:
  • 17 Service Management Practices
  • 14 General Management Practices
  • 3 Technical Management Practices

In the SVS, 7 guiding principles are defined that apply to every service process and include general, industry-independent recommendations:

• Value orientation: In every activity and process, the generation of value is focused. A value can be, for instance, an increase in quality or a reduction in costs.
• Start where you are: Existing, functioning structures and processes should not be completely rebuilt, but rather developed further purposefully.
• Iterative development with feedback: Processes are subject to constant change, with regular evaluations serving to optimize them. This change occurs gradually so that successes can also be reliably measured.
• Promote collaboration and transparency: Departmental silos (isolated work) must be dissolved, as the combined expertise of a company must be available for innovations. The goal is a guided exchange of knowledge and know-how between all stakeholders.
• Think and work holistically: When making decisions about process changes, all dependencies and framework conditions should be taken into account. Transparent communication within the organization and with customers and suppliers is recommended.
• Pay attention to simplicity and practicability: The number of sub-steps should be reduced as much as possible. This improves the understanding of processes and, moreover, dependencies are easier to recognize. In the standard process, there is no need to have a solution for every exception.
• Optimize and automate: Once processes have been streamlined, they should be automated as much as possible when it makes sense to do so. Despite automation, compliance regulations, budget limits and other factors should be taken into account.

At the beginning of an ITIL^® project, it is advisable to define the services that are to be covered.

After all, the main motivation for introducing ITIL^® is a stronger service focus.

A distinction should be made between services provided to customers and those that are only visible within the service provider organization (the so-called supporting services). Customer services are characterized by the fact that they represent a value for the customer.

If a customer wants a functioning internet connection (customer service), it is irrelevant what kind of technical infrastructure is required for this (supporting service).

To begin with, you should create a list of all business services from existing agreements and documentation. Once it is clear which services will be provided to the customers, you can define the necessary supporting services. These are often directly linked to specific parts of the technical infrastructure, such as an SAP platform.

With the list of all services, you only need to record their relationships to each other to define the service structure.

Later, this service structure is an important basis for implementing the service catalog management process.

For the success of an ITIL^® implementation, it is important that the people who will later take responsibility for the execution of certain processes are involved in designing these processes right from the start. This ensures that as much experience as possible is incorporated into the process definition, and that the role owners can identify with the changes in workflow that ITIL^® will bring.

The required roles are derived directly from the new ITIL^® disciplines to be introduced. For instance, if Problem Management is to be established, the role of the Problem Manager has to be filled.

Particularly in large companies, ITIL^® roles may also need to be divided into further sub-roles, e.g., if one Problem Manager alone cannot deal with all the tasks that arise in this position.

In this step, the roles do not have to be defined in detail directly as this is done implicitly in the course of the detailed definition of the processes in later project phases.

Every new ITIL^® implementation and process reorganization should be preceded by an analysis of the current situation. Thus, it is easier to decide which processes require urgent action and which ones might be postponed. Moreover, this approach will often save time.

However, not all processes should be surveyed, analyzed and documented in detail, as this effort is usually not in reasonable proportion to the result.

An ITIL self-assessment is usually conducted in form of structured interviews with the IT management and selected functional managers. The interviewers guide through the questionnaire and, if it is required, help with background information on specific questions.

The subsequent evaluation covers the following points:

• Level of maturity achieved in the individual ITIL^® disciplines.
• Deviations in the assessment of the processes by individual interviewees.
• Weaknesses in current processes, including underlying causes, and opportunities.

In this step, you build on the results of the as-is analysis from step 4 and define the target process structure.

First, create a list of the ITIL^® processes and sub-processes that need to be introduced or improved. In this way, it is determined what the process structure, including its sub-processes, should ultimately look like.

As a rule, the new ITIL^® processes to be introduced are derived directly from the specific goals of the implementation project.

For example, if user support is to be expanded, incident management must be implemented or improved. Due to the close link with Incident Management, Problem and Configuration Management should also be included in the project scope.

This selection of ITIL^® processes is the focus of this project step.

The target process structure does not yet contain detailed process descriptions, as these will only be developed in a later step.

This step determines both the inputs that the individual ITIL^® processes receive from others and which outputs they must deliver in order for subsequent processes to function.

Frequently, weaknesses occur where one process ends and another one begins. If the information required for a smooth process is not exchanged as intended, this often manifests itself in interruptions in the data flow or in system breaks.

Therefore, the definition of interfaces must take place as a separate step even before defining detailed process flows.

First of all, it must be determined which inputs from the preceding processes can be built upon and which outputs are necessary for the successor process before the actual activities within an ITIL^® process are defined.

This determination of necessary process interfaces builds on the process structure developed in the previous project step.

A particular challenge in defining interfaces is the fact that normally not all ITIL^® processes are introduced at once. Frequently, this means that some of the inputs required for a process are not yet available.

For example, the Privacy Security Management practice might not yet be explicitly defined, while the Service Desk practice already requires inputs such as security alerts.

As soon as the ITIL^® process structures have been established and the interfaces have been defined, process controlling can be set up. Its sequence can only be designed sensibly after it has been determined which quality criteria a process has to fulfill.

Controlling defines suitable methods to ensure that the processes meet their expectations. A well thought-out concept not only serves as an instrument for evaluating the achievement of objectives, it also provides the key figures required for continuous improvement within the service lifecycle in the long term.

In order to be able to decide whether a process is "running well" or not, objective quality criteria (so-called key performance indicators, or KPIs for short) must be defined.

For this purpose, the overarching goals of the ITIL^® project must be defined—for example, the highest possible first resolution rate in the service desk. With these objectives in mind, you can determine the KPIs suitable for assessing successful process implementation.

The final selection of the KPIs depends—among other things­—on the determination options available in the company. Ideally, the KPIs are calculated automatically via a service desk system. Therefore, the measurement methods defined here are also requirements for the systems to be implemented.

However, more is not always better. In practice, it often turns out that a metrics structure that is too complex and entails a disproportionately large amount of work is not well accepted. Therefore, it is no longer used after a short time.

Instead, you should rather define a few but meaningful key figures in order to keep the determination effort and the reporting within a reasonable range.

Moreover, it is not advisable to set any fixed target values in the initial phase. First, you should rather set suitable quality indicators and determine measured values. After some time, when a statistically meaningful number of measurement results are available, target values can be defined on a solid basis.

This step specifies the activities to be performed within each process and the checklists and guidelines that will be used to support their execution.

Usually, the process owners are assigned this task, but all affected parties should be involved, especially the employees who will execute the processes in the future. This ensures that the greatest possible level of experience and knowledge is incorporated into the process design.

Process designs are usually documented as flowcharts, so that the required activities and their sequence are depicted without going into too much detail. The diagrams also specify which roles are responsible for performing the activities.

In order to avoid overloading the process diagrams, you should attach additional information to support process execution as checklists and document templates to the diagrams.

For instance, these could be detailed instructions for registering and forwarding incidents and service requests in 1st-level support.

Now, the process design is complete and the implementation can begin.

If a new or modified technical infrastructure is required to support the processes, this is now procured and set up. The individual steps that are required depend entirely on your project and the implemented processes. Therefore, the following example only describes the requirements definition of application systems.

Functional requirements for the supporting infrastructure can often be derived from the process design. This design defines which work steps have to be supported by the applications.

The process input and output definitions describe which data is to be processed by the systems. For example, the incident management process generates incident records. Therefore, the system supporting this process must be able to manage such data.

Finally, non-functional requirements must also be included.

This results in the following structure for the requirements catalog:

• Functional requirements
  • Reference to detailed process models
  • Additional functional requirements
  • Definitions of process outputs (data structures)
  • Functions of reporting system
• Non-functional requirements
  • Requirements regarding capacities and quantities
  • Performance and throughput
  • Scalability/expandability
  • Availability
• Requirements from an operational point of view
  • Requirements from IT security point of view
  • Interfaces to other systems
  • Appendix
    • Process models
    • Data to be imported from existing systems

Once the catalog is complete, extract a prioritized list of individual items that will serve as an evaluation matrix for selecting a suitable (external) system. The requirements should be organized by category, as in the following example:

• K.O. criteria (priority 1)
• Important requirements (priority 2)
• Desirable requirements (priority 3)

If all key parties have been involved in designing the processes, there should be no need to explain the new processes further to the responsible employees.

However, it may be necessary to train your team on how to use new application systems.

In addition, customers may need to be informed if, for example, a new support group has been established in 1st-level support. Therefore, the procedure for reporting incidents has changed.

In conclusion:

Be sure to communicate changes in processes to all involved parties early on. If process participants are not informed about new process flows until the final phase of an ITIL^® project, a lack of acceptance is inevitable. Therefore, as many of the employees, who will be affected later, as possible should be involved in the design of the processes during the earlier phases of the project.

This practice deals with the management of technologies used in the organization.

The Software Development and Management practice provides an overview of the activities of Software Development and Management.