- Understand ITSM and the fundamentals of the ITIL® Framework
- Be able to name the 5 phases of the Service Lifecycle
- Understand the characteristics of processes in ITIL®
- Understand the characteristics of functions in ITIL®
- Understand the standard roles in ITIL®
- Understand organizational structures and their relation to ITIL®
- Understand the various types of service desks in ITIL®
- Understand the Technical Management function
- Understand the Application Management function
- Understand the IT Operations Management function
- Understand the RACI Model
IT Service Management (ITSM) is the complete set of activities required to provide value to a customer through services, including policies and strategies to Plan, Design, Deliver, Operate, and Control IT services. This leads us to the question, what is the definition of a service. A Service is a means of delivering value to customers by facilitating the outcomes customers want to achieve without the ownership of specific costs and risk.
For example, if you own a company that wants to host a website, you would want the functionality of having a website up and running for your customers to access 24 hours a day, 7 days a week. But, you may not want the expense involved in buying the servers, paying the IT personnel to run those servers, and all the other associated costs. So, instead, you can pay a service provider to run your website for a monthly fee. You, as a customer, have now received the outcome you wanted without the ownership of the specific costs or risks.
There are many different IT Service Management models and frameworks in the industry, but we are only going to focus on one: ITIL®. The Information Technology Infrastructure Library (ITIL®) was developed as a framework for organizations to use in order to perform ITSM. Not surprisingly, on the ITIL® Foundation certification exam, the only ITSM framework that is tested is the ITIL® framework. For that reason, this book will only focus on the ITIL® processes and functions.
The ITIL® framework is made up of the best practices from throughout the IT industry. Best practices are proven activities or processes that have been successfully used by many different organizations in a specific industry. These best practices come from multiple sources, including standards, industry practices, academic research, training and education, and internal employee experiences.
THE SERVICE LIFECYCLE
The ITIL® Framework is built around the Service Lifecycle. This lifecycle consists of 5 phases: Service Strategy, Service Design, Service Transition, Service Operation, and Continual Service Improvement. There are many ways to visualize these five phases and how they work together. The official ITIL® Framework materials like to depict it as follows:
While this lifecycle diagram is useful, it doesn’t really depict the reality of the ITIL® Service Lifecycle as it is used in the real-world. Instead, I prefer to diagram the lifecycle with a continuously feedback loop, as shown in this modified lifecycle diagram:
As shown in the lifecycle diagram, each service begins its life in Service Strategy, then moves up and to the right from phase to phase in the lifecycle. At each and every point, there is a continuous feedback opportunity to the Continual Service Improvement phase, where those changes can be implemented in earlier stages (for the next version of a given service). This really captures the idea of Continual Service Improvement more clearly, and more closely reflects the reality you will experience in the real-world IT Service Management.
Each phase of this service lifecycle will be covered in-depth in subsequent chapters of this book. As we cover each phase, we will also cover its associated processes and functions to ensure you are ready for those questions on exam day.
A process is a set of coordinated activities that combine resources and capability to produce an outcome that creates value for the customer. In the ITIL® Framework, there are 26 distinct processes covered throughout the 5 phases of the service lifecycle. But, only 22 of these processes are covered in-depth by the Foundation exam.
Each and every process has to have the same four characteristics. First, they must respond to a specific event, called a trigger. Second, they must be measurable by using metrics like performance, cost, productivity, quality, and duration. Third, they must produce a specific result. Finally, they must deliver a result to a defined customer to meet expectations.
In the summary chart on the next page, you will see a complete list of all the processes and functions covered on the ITIL® Foundation exam. Each of these processes and functions will be covered in-depth later in this book as we cover each of the service lifecycle phases in their own chapters.
Each process can be depicted using a three-layered model containing its process control, the process itself, and the process enablers. The process controls include process policies, ownership, documentation, review programs, etc. The process itself contains the steps of the process, procedures, work instructions, roles, triggers, metrics, inputs, and outputs. The process enablers include resources and capabilities that are required to support the process.
Functions are self-contained units of an organization specialized to perform specific tasks and are responsible for an outcome. These functions actually perform the activities of processes. Functions consist of a group of people and the tools they use to create a given outcome through a process.
So, to clarify, what makes a process different than a function? Processes help organizations achieve certain objectives, even across multiple functional groups. Functions, on the other hand, add stability and structure to the organization by being mapped to the organizational chart, having a budget tied to them, and even having defined reporting structures associated with them.
Processes rely on functions to accomplish their outcomes. In fact, many times, processes rely on multiple functions to accomplish their outcomes. Processes and functions are both very intertwined, and processes would not be effective without supporting functions. Additionally, both processes and functions have roles associated with them, which we will cover in the next section.
Roles are a collection of specific responsibilities, duties, or positions within a process or function. Each role can be held by an individual or team of individuals. Additionally, a single person or team can have more than one role. In the ITIL® Framework, there are four standard roles that are utilized: service owner, process owner, service manager, and process manager.
The service owner is accountable for the overall design, performance, integration, improvement, and management of a single service. They are responsible for:
- Initiation, transition, and maintaining of the service
- Ensuring service delivery is met
- Identifying service improvements
- Being the liaison to the Process Owners
- Reporting and monitoring
- Overall accountability for delivering the service
The process owner is accountable for the overall design, performance, integration, improvement, and management of a single process. They are responsible for:
- Initiation, transition, and maintaining of the process
- Defining the process strategy and policy
- Assisting in the process design
- Ensuring the process is documented
- Auditing the process for efficiency
- Communicating the process to others
- Provisioning resources and training
- Inputting suggestions into the service improvement program
The service manager is accountable for the development, performance, and improvement of all services.
The process manager is accountable for the development, performance, and improvement of all processes.
There are two additional roles that are not considered part of the standard roles: the product manager and the process practitioner. The product manager is accountable for the development, performance, and improvement of a group of related services. The process practitioner is responsible for actually conducting the actions and functions associated with operating the service. For example, the person answering the phones in the service desk may be considered a process practitioner for the Service Request Fulfillment process.
One of the most common questions I have been asked by management when they are looking to adopt the ITIL® Framework in their organization is “How should we organize our workforce to support ITIL®?” Well, this is exactly the wrong question to be asking, because ITIL® does not provide a model for how to structure your organization!
Instead, the ITIL® Framework provides some useful guidance on organizational structure, but none of it is to be considered prescriptive in nature. In fact, each volume of the ITIL® Framework manual has as its 6th chapter, guidance on organizational structure. Just open up any of the manuals (Service Strategy, Service Design, Service Transition, Service Operations, or Continual Service Improvement), and you will find Chapter 6 as “Organizing for _______”.
In these chapters, you will find numerous roles and responsibilities listed. But, you should use these as more of a checklist to see if you have considered the roles, not as a requirement to create all of those roles in your own organization.
So, if ITIL® doesn’t dictates organizational structure, what should you be concerned with when it comes to this topic? There are a few key concepts here to remember. First, roles can be filled by multiple people, and one person could fill many different roles. If there are many people filling a given role, you need to ensure there are no gaps or seams in their job responsibilities, or else things could “fall through the cracks”. Always ensure that all roles required are filled by someone inside your organization.
ITIL® focuses on the relationships between functions and processes, and between the four standard roles. Much of the focus in ITIL® is placed on the four major functions that support the various processes: Service Desk, Technical Management, Application Management, and IT Operations Management.
The service desk provides a single, central point of contact for all users of IT services. The is the first point of contact for all issues with all services, including inbound incidents, service requests, change requests, and much more. Usually, the service desk also owns the Incident Management process, since they are the first call by a customer when something goes wrong with a given service.
Many organizations have a help desk while others have a service desk, but what is the difference? Well, the first service desks were simply call centers or help desks. These help desks really focused on answering customer calls and fixing broken services for the customers. Over time, these help desks became better organized and evolved into full-blown service desks, offering more than just a “break-fix” mentality to problem solving. These service desks became the singular point of focus for customers, handling break-fix issues, upgrades, training, and much more.
There are four major types of service desk models: Local Service Desk, Centralized Service Desk, Virtual Service Desk, and Follow-the-Sun.
The local service desk is physically located close to the customers they support. Usually, they reside in the same building or offices as their customers, such as an embedded IT support person inside the accounting department, or even a singular service desk to support the entire building.
The centralized service desk model makes better use of resources, improves consistency, and centralizes management. Under this model, a single service desk would remotely answer all telephone support calls, regardless of the location of the customer.
The virtualized service desk doesn’t require a centralized location, but can still make better use of resources, improves consistency, and centralizes management. Under this model, the location of the service desk personnel is irrelevant and could even include remote home-based teleworkers. Customers simply call a centralized telephone support number and their call is routed to the next available agent, regardless of the customer’s or agent’s location.
The follow-the-sun service desk model combines local, centralized, and virtual service desks, allowing for 24x7 coverage across all time zones. As shown in the image, during the normal business hours the calls are routed to a call center in that time zone (for example, a New York support desk during office hours in the United States). If a United States customer calls for service after normal business hours, their call is routed to a different call center based on the normal working hours of those service desk locations.
The technical management function is responsible for the procurement, development, and management of the technical skill sets and resources required to support the infrastructure and the ITSM efforts. This function provides technical resources to all phases of the ITIL® Lifecycle. The technical management function ensures that the Service Provider has the right skill sets available to deliver the services it offers to its customers. Generally, technical management is divided into specialty areas, such as networking, security, databases, storage, servers, and other specialized fields required to support the overall service provider objectives.
The application management function provides end-to-end management of applications in the environment, and involves cultivating the skill sets and resources to support all phases of the lifecycle. Application management also helps to identify software requirements and their sourcing (internal/external).
Application management is focused on the ongoing oversight, operational management, and improvement of applications for both utility and warranty. Application development, on the other hand, is focused on design and construction of an application solution to gain initial utility.
Application management is a function that supports and does not replace other core processes, such as Incident Management, Problem Management, Change Management, Availability Management, and many others.
IT OPERATIONS MANAGEMENT
The IT Operations Management function provides a stable platform on which services can be delivered to meet the agreed-upon business needs. It performs the day-to-day running of the IT infrastructure and the facilities that house that infrastructure. IT Operations Management split into two sub-functions: Operations Control and Facilities Management.
Operations Control monitors the infrastructure for optimal performance minute-by-minute and conducts the normal maintenance cycles required. To do this, operations controls performs Console Management, backup and restoral operations, media management, batch job execution, and more. These operations are usually controlled from the Network Operations Center (NOC) or the Operations Bridge. In this example, an Operations Bridge is being used to monitor local traffic conditions, as well as the automated systems that help to alleviate them like using traffic cameras and stoplights.
Unlike Operations Control, Facilities Management is only concerned with physical environment of the IT infrastructure, including the power, cooling, fire suppression, and physical access to the data centers and server rooms. To be effective, though, the facilities management team must have a close working relationship with the Operations Control watch team. In many organizations, both the Operations Control and Facilities Management personnel are collocated in the same workspaces.
THE RACI MODEL
The RACI Model is a generic tool for reviewing and assigning four key roles to any activity: Responsible, Accountable, Consulted, and Informed. Each activity can have many roles who are responsible, consulted, and informed, but only one role can be listed as accountable. As the old saying goes, if everyone is accountable, then nobody is accountable!
The RACI Model provides a visual indication of the linkages between roles, their responsibility, and the accountability for a given task in a process. Responsible (R) refers to the person who executes or performs the activity. Accountable (A) refers to the person who owns the activity and must answer for its outcomes. Only a single person can be held accountable for a given activity. Consulted (C) refers to the person who reviews and provides advice and authorization for the activity. Informed (I) refers to the person who receives updates on activity’s progress.
A simplified version of a Responsible, Accountable, Consulted, and Informed (RACI) Matrix for the Incident Matrix Process is provided as an example: