Processes can be defined as a structured set of coordinated activities designed to produce an

outcome and provide value to customers or stakeholders. A process takes one or more inputs
and through the activities performed turns them into defined outputs.


Processes are strategic assets.


A process owner is the person responsible for ensuring that the process is fit for the desired
purpose and is accountable for the outputs of that process.


A process manager is the person responsible for the operational management of a process.
There may be several Managers for the one process or the same person may be both the
process owner and process manager (typically in smaller organizations).


RACI stands for:
R Responsibility (actually does the work for that activity but reports to the function or position
that has an A against it).
A Accountability (is made accountable for ensuring that the action takes place, even if they
might not do it themselves). This role implies ownership.
C Consult (advice/ guidance / information can be gained from this function or position prior to
the action taking place).
I Inform (the function or position that is told about the event after it has happened).

A RACI Model is used to define the roles and responsibilities of various Functions in relation to
the activities of Incident Management.
General Rules that exist:
Only 1 A per Row can be defined (ensures accountability, more than one A would
confuse this).
At least 1 R per Row must be (shows that actions are taking place), with more than one
being appropriate where there is shared responsibility.



NOTES:
The
Service
Lifecycle
phases
(and
ITIL
books)
are
shown
through
the
arrows at
the
bottom;
The
concepts
in light
shading
are the
V2 ITIL
concepts;
The
concepts
not
shaded
are the
new ITIL
V3
concepts;
The
concepts
in dark
shading
are
Functions.


It is important to note that most of the processes defined do not get executed within only one
lifecycle phase. As an example:
Service Strategy Phase: Determine the needs, priorities, demands and relative importance for
desired services. Identifies the value being created through services and the predicted financial resources
required to design, deliver and support them.
Service Design Phase: Designs the infrastructure, processes and support mechanisms needed to
meet the Availability requirements of the customer.
Service Transition Phase: Validates that the Service meets the functional and technical fitness
criteria to justify release to the customer.
Service Operation Phase: Monitors the ongoing Availability being provided. During this phase we
also manage and resolve incidents that affect Service Availability.
Continual Service Improvement Phase: Coordinates the collection of data, information and
knowledge regarding the quality and performance of services supplied and Service
Management activities performed. Service Improvement Plans developed and coordinated to improve any
aspect involved in the management of IT services.


Service Warranty + Service Utility = Service Value

Service utility is Fit for purpose and Service warranty I Fit for use





The processes included in the Service Strategy lifecycle phase are:
Service Portfolio Management
Financial Management
Demand Management

Services are grouped into three distinct categories in the Service Portfolio:
Service Pipeline (services that have been proposed or in development).
Service Catalogue (live services or those available for deployment).
Retired Services (decommissioned services).



The processes included with the Service Design lifecycle phase are:
Service Level Management (Design)
Capacity Management
Availability Management
IT Service Continuity Management
Information Security Management
Supplier Management
Service Catalogue Management



Three types of SLAs structures that are discussed within ITIL are Service-based, Customer-based and
Multi-level or Hierarchical SLAs.



A Supplier and Contract Database (SCD) should form an integrated element of a comprehensive CMS
(Configuration Management System) or SKMS (Service Knowledge Management System), recording all
supplier and contract details, together with the types of service, products etc provided by each supplier,
and all the other information and relationships with other associated CIs(Configuration Items). This will
also contribute to the information held in the Service Portfolio and Catalogue.

The primary goal of Service Catalogue Management is to ensure that a Service Catalogue is produced,
maintained and always contains accurate information on all operational services and those ready for
deployment.
The scope of this process is to provide and maintain accurate information on all services that are being
transitioned or have been transitioned to the live environment.

Capacity Management goal is to ensure the current and future capacity and performance demands of
the customer regarding IT service provision are delivered for in a cost-effective manner.

Business Capacity Management
Manages Capacity to meet future business requirements for IT services
Identifies changes occurring in the business to assess how they might impact capacity and
performance of IT services
Plans and implements sufficient capacity in an appropriate timescale
Should be included in Change Management and Project management activities.

Availability Management goal is to ensure that the level of service availability delivered in all services is
matched to or exceeds the current and future agreed needs of the business in a cost-effective manner.





IT service Continuity Management goal is to support the overall Business Continuity Management by
ensuring that the required IT infrastructure and the IT service provision can be recovered within
required and agreed business time scales.** Often referred to as Disaster Recovery planning. **



Service Transition Processes
Knowledge Management
Service Asset & Configuration Management
Change Management
Release & Deployment Management
Service Validation and Testing



The actual roles related to Service Asset and Configuration Management include:
Service Asset Manager
Configuration Manager
Configuration Analyst
Configuration Administrator/Librarian
CMS/Tools Administrator
Change Manager (all Changes to CIs must be authorized by Change Management)





Release and Deployment Management is responsible for maintaining the DML & DS






Event Management is a process carried out by IT Operations Control.




Incident Management is not concerned with the root cause, only addressing the symptoms as
quickly as possible.





Access Management ensures that users are given the right to use a service, but it does not
ensure that this access is available at all agreed times this is provided by Availability
Management.



The DML contains master copies of all controlled software in an organization ... along with licence
documents or information. The change schedule is not included.
The service level manager has responsibility for, amongst other things...negotiating and agreeing OLAs
A process owner should ensure process documentation is current and available. Knowledge
management is a process not a role. The service owner can be responsible for service documentation.
The CIO may be responsible for IT strategy documentation.
Request fulfilment is the processes of dealing with service requests from the users.
The four key stages of the Deming cycle are Plan, Do, Check and Act
the ability to detect events, make sense of them and determine the appropriate control action is
provided by event management.
A workaround is the technique used to restore service based on an Incident that has been seen before
Sequence of Handling Incident : identification, logging, categorization, prioritization, initial diagnosis,
functional escalation, investigation and diagnosis, resolution and recovery, closure
The service desk manager may often be the incident management process owner but not problem
management.







Processes are structured sets of activities designed to achieve a specific objective. Processes have four
basic characteristics:
1. They transform inputs into outputs
2. They deliver results to a specific customer or stakeholder
3. They are measurable
4. They are triggered by specific events


Functions are self-contained subsets of an organization intended to accomplish specific tasks. They
usually take the form of a team or group of people and the tools they use. Whereas processes help
organizations accomplish specific objectives--often across multiple functional groups--functions add
structure and stability to organizations.



Service Assets or (more generally) assets refer to the resources and capabilities which a Service
Provider must allocate in order to offer a service.

Change Authority
In ITIL the entity charged with approval of a Request for Change is called the Change Authority. In
most environments, the identity of the Change Authority varies with the type of change under
consideration. For many ordinary changes, the Change Manager may act as the Change Authority.
However, for extremely large changes, the Change Authority may be an executive or even the board of
directors.

Change Model
A Change Model is a template or pre-defined set of steps, procedures, and guidelines for execution a
specific type of change. Change Models are used to help minimize risk, save costs, and improve the
consistency of execution around changes.

Configuration Management System (CMS)
The Configuration Management System is the controlled repository and interfaces for management of
information concerning items under configuration control (Configuration Items) in the environment.
The purpose of the CMS is to provide accurate and up-to-date information regarding how the
environment is configured.

Problem Management uses techniques such as Kepner-Tregoe, Ishikawa diagramming, and Fault Tree
Analysis to identify the root cause of incidents.

ITIL introduces the concept of bounded rationality in its discussion of the role of automation in IT
Service Management. Bounded rationality refers to the limits which constrain humans ability to
entertain more than a few factors at a time when seeking to make decisions in complex situations.



Raised, reason, return, risks, resources, responsible, and relationship are commonly
referred to as:
Seven Rs of Change Management