You are on page 1of 218

These are the topics that will be covered on the course.

Your course director will explain the agenda you will follow on this specific course in
more detail.
Course Administration and Introductions Service Management and ITIL Service
Management as a practice The Service Lifecycle
Service Strategy
Service Portfolio Mgt, Demand Mgt, Financial Mgt
Service Design
Service Level Mgt, Service Catalogue Mgt, Availability Mgt, Information
Security Mgt
Supplier Mgt, Capacity Mgt, IT Service Continuity Mgt
Service Transition
Change Mgt, Service Asset & Configuration Mgt, Release and Deployment Mgt
Service Operation
Incident Mgt, Event Mgt, Request Fulfilment, Problem Mgt, Access Mgt
Service Desk, Technical Mgt, Application Mgt, IT Operations Mgt Continual
Service Improvement
Improvement process

Sample Exam Real Exam

The Student workbook consists of the following sections; Section 1


Covers Course Overview, Assignments Section 2
The slide set with notes. Section 3
Summary Aids Section 4
Exam Preparation Hints and tips, Sample Exams. Section 5
Acronyms and Glossary.

The processes covered in the Capability Stream are: Service Offerings and Agreements
(SO&A)
Service Level Management, Financial Management, Service
Portfolio Management, Service Catalogue Management,
Demand Management and Supplier Management
Planning, Protection and Optimization (PP&O)
Capacity Management, Availability Management, ITSCM,
Risk Management, Demand Management, Information Security
Management
Release, Control and Validation (RC&V)

Change Management, Release & Deployment Management,


Service Asset & Configuration Management,Request Fulfilment,
Evaluation, knowledge Management and Service Validation and Testing
Operational Support and Analysis (OS&A)
Service Desk, Incident Management, Problem Management,
Request Fulfillment, Event Management, Knowledge
Management and Access Management

Examination Boards
The syllabus for this course is based on OGC's IT Infrastructure Library Examination for
the Foundation Certificate in IT Service Management The examination which normally
concludes the final day, takes the form of a closed book multiple choice paper of 40
questions, and lasts for one hour. Students who do not have English as their first
language are allowed an additional 15 minutes and can consult a language dictionary.
To pass the examination, you will need to achieve 65% (or 26 correct answers). Your
paper will be collected at end of the exam and sent for marking. Your result is usually
sent to you within two weeks.
An examination entry form will be given to you by the course director.

ITIL is a Registered Trade Mark, and a Registered Community Trade Mark of the
Office of Government Commerce, and is Registered in the U.S. Patent and Trademark
Office

The Course Objectives are described above.


This course is designed to meet the criteria of the certification body ARM Group.
The key concepts and terms used in the processes are described in the Acronyms and
Glossary section of this manual. The course covers all the ITIL Service Lifecycle
including the relevant processes and functions, paying attention to the objectives and
the activities of the process and the relationships with other processes.
The course is designed to enable students to successfully pass the exam for the
Foundation Certificate in IT Service Management.

The customer will need to take the service , but without claiming the full owner ship
of the whole infrastructure to implment the service ,the service provider should
always be the owner of all needed infrastructure.

Process Owner responsibilities include:


Documenting and publicizing the process
Designing the KPIs to judge effectiveness and efficiency
Ensuring staff have the right skills and awareness to fulfil their roles within the process
Continual improvement and management of change affecting the process under their
care

With modern technology, Incidents may be recorded by customers, support groups or


event systems directly. They may be skeleton records in the case of customer or event
systems. It is common for Incidents to be reported by fax or e-mail. If using these
methods you must ensure that these channels are properly managed as the customer
will start their "resolution clock" running as soon as the fax or e-mail has been sent don't forget that both methods will be timed. They all still enter the Incident
Management process.
For Requests for Change the 'specialist support group' will be Change Management.
To record details of the Incident, the Service Desk will use the CMDB to find data
about the related items such as what PC the customer is using, or what Service is
affected if a server has gone down.
During Incident recording, errors on the CMDB such as a customer showing different
location details, or having a different workstation can be identified and the relevant
record updated.

Note that term "Good Practice" is sometimes also referred to within the ITIL
framework as "Best Practice".
Good Practice is ,a proven way for doing things ,it is a tested ,done many times and
proved to be a good working model

The Wheel diagram illustrates the ITIL framework which contains advice on good
practice in Service Management.
IT Governance refers to the various frameworks, models and standards that can be
applied to Service Management to bring about management control and ensure that
IT Service provision conforms to organizational strategy and direction.
Frameworks include ITIL, COBIT, Prince2.
Models include CMMI and Standards include ISO/IEC 20000:2005, ISO/IEC
27001:2005.
ISO/IEC 20000 provides a formal and universal standard against which organizations
can be audited and accredited. ITIL offers the knowledge to be able to achieve the
standard.
The CORE arrow refers to the five publications of Service Strategy, Service Design,
Service Transition, Service Operation and Continual Service Improvement.
The COMPLEMENTARY arrow refers to a complementary set of publications containing
guidance specific to industry sectors, organization types, operating models and
technology architectures will be available as time go on.
The WEB SUPPORT SERVICES arrow refers to various supporting training courses,
documents, tools and templates that support the principles described in the core
publications will be available more and more.

Utility is perceived by the customer from the attributes of


the service that have a positive effect on the performance
of tasks associated with desired outcomes. Removal or
relaxation of constraints on performance is also perceived
as a positive effect.
Warranty is derived from the positive effect being
available when needed, in sufficient capacity or
magnitude, and dependably in terms of continuity
and security.
Utility is what the customer gets, and warranty is how it
is delivered.
Warranty and Utility are both crucial elements of creating real value for customers
and the business as a whole. Customers cannot benefit from something that is fit for
purpose but not fit for use, or vice-versa. For example, the customer may be delighted
with the friendly customer interface and functionality offered by the service, but the
service has not been designed with the necessary data security protection and
recovery mechanisms. Alternatively, the service may meet and exceed all agreed
targets of availability, but is missing a vital functional component that allows the
customer to achieve his/her business objectives

Resources need capabilities to use the available resources to develop distinctive


value-adding services to customers
Capabilities cannot produce value without adequate resources
35
Resources provide the raw material necessary to produce the services that the
business requires. Capabilities transform those resources into value adding services.
Capabilities cannot in themselves add value without the appropriate resources.
Resources cannot in themselves add value without the appropriate deployment of
those resources to meet business objectives.

Capabilities will develop over time and will be enhanced as experience is gained and
lessons are learned. Capabilities can be used to develop distinctive service offerings to
gain and retain customers

A Service Model is a representation of a service which documents its key


characteristics which can be used to help understand the nature of the service. For
example at a high level an airline organisation will have models which reflect the types
of flights on offer to the customers. There may be a long haul, medium haul and short
haul service models. Each model will have certain defaults that will apply to every
model (such as the basic safety procedure). As well as that each model will have
distinguishing or even unique features, such as luggage limitations, meals, in-flight
entertainment, seating area, club and business class privileges, etc. Understanding
each model will be the first step to helping the organization to improve the service.
Each model will have a configuration e.g. type and layout of the aircraft (Configuration
of service assets) such as seating layout and leg room for the different grades of flight.
In addition each model will also have more dynamic elements (Service Dynamics) such
as customer feedback, demand for places, skills of flight-crew etc. A service
improvement programme could focus on the issue of improving the comfort of the
customers, by having less seats on the plane (Configuration) or improving the in-flight
experience by focusing on the films or meals on offer on long hauls or the number of
or experience of cabin crew (Dynamics). Service models will continually evolve based
on feedback from customers and from internal service management processes

Contract Risks are those risks associated with poorly negotiated agreements which
jeopardize the ability to deliver to agreed service targets and adversely affect
customer confidence.
Design Risks arise from the failings or shortcomings of converting requirements into
attributes of services.
Operational Risks arise from technical or administrative failings in the supporting the
service in the live environment.
Market Risks are those risks associated with the ever changing and increasingly
competitive business environment. An example of a market risk is failure to take full
advantage of an opportunity to exploit a gap in the market, perhaps as a result of poor
time to market strategies or lack of appropriate knowledge pertaining to recent
market trends.

Examples of demand management.


Recruitment drive by an organization may stimulate more business activity around any
given process (for example email communications) which may in turn place additional
demands on the network infrastructure which may initiate a requirement to expand
the capabilities of the network.

Answer : a

Answer : a

Answer : a

New or changed services must be designed within appropriate timescales and costs
whilst ensuring that it is both fit for purpose (utility) and fit for use (warranty).
Service Design must also design:and manage the processes for the design, transition, operation and improvement of
high quality IT services taking into consideration supporting tools and information
systems
Secure and resilient IT infrastructures, environments, applications and information
resources to meet the current and future need of the business
Measurement methods and metrics for assessing the effectiveness and efficiency of
design processes and their deliverables

Service Design Package is the deliverable of this phase

To achieve service improvement, four areas need to be considered:


Effective and efficient IT Service Management processes Good IT Infrastructure in
terms of tools and technology
People with the right skills, appropriate training and the right service culture.
Effective and properly managed relationships and partnerships with manufacturers
and suppliers
Unless all four areas are considered and implemented appropriately the objectives of
IT Service Management will not be realised. The culture of the organization will be a
key factor in determining the speed of implementation of Service Management. For
example, where there is a high degree of resistance to change this will slow down the
implementation process

Organizations have to consider a wide variety of strategies in order to deliver cost


effective and competitive services to their customers. The range of alternatives gives
organizations some flexibility with delivery options, but each option will have
advantages and disadvantages and must be carefully assessed for risks and suitability
for the proposed business initiative.
For example, In-sourcing will be simpler to manage and allow the organization more
direct control, but may limit the organization in terms of scale. Out-sourcing will allow
for better economies of scale and allow the organization to concentrate on core
business, but will carry risks associated with selecting appropriate suppliers and
managing the relationship carefully to avoid conflicts of interest.
All of the above options can be provided on-shore or off-shore.

Designing Service solutions


A formal or structured approach is required to produce the new service within the
cost, functionality, quality and time constraints. The approach for design and
subsequent stages in the life-cycle must continually ensure that they reflect the
evolving needs of the business. Design of service solutions will include all agreed
functional requirements, resources and capabilities
Designing the Service Portfolio to include the appropriate level of detail to articulate
business needs and provider's responses, and giving the ability to management and
control services throughout their lifecycle.
Designing the technology architectures and management systems to produce a
"blueprints" for development and deployment of an IT infrastructure, including
applications and data, to satisfy current and future needs of the business
Design of the processes necessary to design, transition, operate and improve services
throughout their lifecycles
Design of the measurement systems necessary to control the design processes and
ensure that the measures are appropriate to enable the processes to be regularly
assessed for efficiency, effectiveness and compliance. "If you can't measure it, you
can't manage it"

As illustrated by the diagram, the Service Catalogue needs to be designed to provide a


single source of consistent information on all of the agreed services and ensure that
this information is widely available to both the business and IT support services at the
appropriate level of detail.
The business will require an accurate, consistent picture of IT services, their detail and
their status. The business will not necessarily be interested in the complexity of the
infrastructure required to support the IT services, so the information in the Business
Service Catalogue needs to be meaningful from the business perspective. In other
words, how the services are used, which business processes do they enable, and the
quality of service the customer can expect.
The Technical Service Catalogue will present a view of the services which will give the
necessary technical detail to enable fast and efficient response to service related
issues. The information will contain details of the hardware, software, application and
data components, and their relationships, necessary to support the provision of the
service.

The Service Level Management (SLM) Process is responsible for proposing, negotiating
and maintaining Service Level Agreements (SLAs).
Also within the scope of this process is the establishment of Operational Level
Agreements (OLAs) and Underpinning Contracts (DCs) with external support supplier
organizations.
SLAs provide an important method of measuring IT Service quality and Service Level
Management drives the Continual Service Improvement Program.

The goal of SLM is to maintain and improve IT Service quality within cost justified
limits based on business requirements. This is done by an iterative process of setting
an agreed level of service, monitoring and reporting on the set levels and repeating
with improved levels.
The steady improvement of service quality and reduction in service disruption that
SLM can achieve reduces the cost/quality ratio of service provision and improves the
relationship between customers and IT.

Definitions:
Service Level Agreement (SLA)
A written agreement between an IT service provider and the IT customer(s) defining
the key service targets and responsibilities of each party
Operational Level Agreement (OLA)
An agreement between an IT service provider and another part of the same
organization that assists in the provision of the service
Underpinning Contract
A legally enforceable agreement to manage external supplier arrangements

IT Service Providers are generally dependent on internal support


providers and external suppliers to help support at least some of their services.
For internal support providers, Operational Level Agreements (OLA's) are
needed to ensure support levels meet the Service Level Requirements as
documented in the SLA.
For external suppliers, Underpinning Contracts (UCs) should be in place stipulating the
required level of support.

Service Based SLA


This is a suitable SLA when all Customers use the service in the same way for example,
corporate services such as Email.
Care must be taken to ensure that variations in the levels of usage of the service by
customers are understood and the service delivery requirements of different
customers can be incorporated.
Customer Based SLA
A Customer based SLA is one which covers all the services received by a single customer
group.
It has the advantages of being easier to negotiate as there will not be conflicting customer
requirements and there is normally only one signatory, customers often prefer this type of
SLA as all their services are covered in a single document.
This structure is one adopted by many organizations.
Corporate Level covering all generic targets appropriate to all customers.
Customer Level covering all targets specific to that customer group, regardless of the service.
Service Level covering all targets relevant to a specific service in relation to a specific
customer.
Variants of the customer level services or exceptions to service levels are documented at the
Service Level.
The structure chosen should be suitable for the particular organization and a combination of
structures may be necessary.

The SLAs document the roles and responsibilities of both sides which reduces the risk
of misunderstandings and omissions. Having a common understanding of the
expected service also manages expectations both sides will understand and agree on
the timescales for deliverables. Having performance targets allows service quality to
be measured which paves the way for future improvements and also removes the
possibility of conflict over what constitutes 'good' or 'bad' service. Measuring service
quality also highlights weak areas for future improvement.

Availability Management is a balancing act of being able to deliver the appropriate


component and service availability while at the same time ensuring this is done cost
effectively. Therefore understanding the business drivers of the need for availability,
especially high availability, is essential to getting the appropriate investment to
provide the necessary infrastructure

Availability Management works with Service Level Management in setting realistic


availability and reliability targets for the SLAs. These targets are based on the Service
Level Requirements and ensure appropriate levels of component reliability,
serviceability and maintainability are met. Availability Management monitors and
reports on service and component availability and reliability, investigates shortfalls
and instigates actions to overcome them

In today's highly competitive and service oriented business environment,


organisations are judged on their ability to continue to operate and provide a service
at all times. ITSCM is concerned with managing an organisation's ability to continue to
provide a pre-determined and agreed level of IT Services to support the minimum
business requirements following an interruption to the business. This may range from
an application or system failure, to a complete loss of the business premises. As such,
ITSCM forms an integral part of the Business Continuity Management process to
ensure that IT Services and facilities can be provided.
These days, a reactive approach to dealing with risks to Business Continuity is not
acceptable. Directors have a 'duty of care' to their shareholders, Customers and
creditors and could find themselves personally liable if they have been negligent,
whatever their professional discipline.

Definition: post-mortem: In information security terms, a method of data analysis and


investigation performed after an intrusion has already occurred.

The Information Security Policy (ISP) should have the backing of senior management
both within IT and the business.
The policy should be widely available to all customers and users as well as IT staff.
The ISP should be referred to in SLAs and underpinning agreements and key areas of
the policy should be highlighted to ensure full understanding of roles and
responsibilities and help ensure adherence to the policy The Policy should be
reviewed at least on an annual basis.

Is often combined with availability management process and act as one team.

Business Capacity Management


Trend, forecast, model, prototype, size and document future business requirements
Service Capacity Management
Monitor, analyse, tune and report on service performance, establish baselines and
profiles of use of services, manage demand for services
Resource Capacity Management Monitor, analyse, tune and report on the Utilisation
of components, establish baselines and profiles of use of components

Answer : c

Answer : a

Increasing satisfaction for the customer, user, and Service Management staff can be
realised by successful transition of new or changed services. An essential part of the
transition is to ensure that all stakeholders are :properly communicated with especially during the deployment phase,
have all the necessary release documentation (release contents, user guides, FAQs
etc),
are properly trained to use or support the new or changed service
have all the necessary knowledge required to help use and support the new or
changed service

Specifically, Service Transition adds value to the business by improving:


the ability to adapt quickly to new requirements and market developments
management of transition during mergers, acquisitions etc
the success rate of changes and releases
the predictions of service levels and warranties
confidence in the degree of compliance with governance requirements during
change
estimates of resources and budgets
productivity of the business by successful transition of services that create value for
the business
management of changes to hardware and software maintenance contracts
understanding the level of risk during and after the change

Change may be initiated from either IT or business ,but in both case business need are
assesed

Planned is important here as we can say ITIL has now gone a long way to integrating
with project changes.

The above figure shows a typical scope for the IT service Change
Management process and how it interfaces with the business and
suppliers at strategic, tactical and operational levels.
For example a strategic change to the business will impact on the service
portfolio or the service design. A tactical change in the business may
mean a change to the services delivered. A supplier change may impact
the way we manage our services or operate our services. And then there
are internal IT changes.
All must be considered or there will be a drop in the quality of the services
delivered.

Change Management should coordinate the production and distribution of a 'Change


Schedule1 (CS) and a 'Projected Service Outage' (PSO).
The latest versions of these documents should be available to everyone within the
organisation, preferably contained within a commonly available Internet or intranet
server.
The CS contains details of all the Changes approved for implementation and their
proposed implementation dates. Because new Changes need to be integrated into the
CS in the most effective way it may be reordered frequently.
The PSO contains details of changes to agreed SLAs and service availability because of
the currently planned CS.

These documents should be agreed with the relevant customers within the business,
with Service Level Management, with the Service Desk and with Availability
Management.
Once agreed, the Service Desk should communicate any planned additional downtime
to the user community at large, using the most effective methods available.

A Standard Change would be initiated by a customer / user via the Service Desk. The
organisation may issue an appendix to the SLA that shows the amount of notice
required and what information will be required at initiation. Following this each box in
the diagram will be associated with a role that will complete the activity.
Documentation will detail what each activity involves and the recording required.

Change Management must review all implemented Changes after a predefined period
has elapsed. This process may still involve CAB members; Change Management may
look to them for assistance in the review process.
Change reviews may be tabled at CAB meetings, for CAB members' information and to
agree any follow-up action that may be needed.
Where a Change has not achieved its objectives, Change Management (or the CAB)
should decide what follow-up action is required, which could involve raising a revised
RFC.
If the review is satisfactory or the original Change is abandoned, the RFC should be
formally closed in the logging system.

It is the responsibility of Change Management to ensure that all records are


completed retrospectively, at the earliest possible opportunity. This is vital to ensure
valuable management information is not lost.
Not all emergency changes will require ECAB involvement. If the change is predictable
both in occurrence and resolution, and well understood in terms of the change itself,
then it may be appropriate to delegate authority to the Operations teams to action
the change and ensure it is properly documented and reported on.
As much testing as possible should be carried balancing the potential impact of the
change not working against the impact to the business of delaying the change.
Completely untested changes should be avoided.

Weather?
Sounds a little strange at first but imagine you are working in the US and are employed
by a company in an area that may get hit by tornados -then having prior warning is
important information.

Service Asset Manager and Configuration Manager Two roles


but may be combined ,and normally combined
Both have similar responsibilities

A Service V Model can be used to represent the different configuration levels to be


built and tested to deliver a service capability.
The left hand side represents the specification of the service requirements down to a
detailed service design.
The right hand side focuses on validation arid testing activities that are performed
against the specifications defined on the left hand side. At each stage on the left hand
side, there is direct involvement by the equivalent party on the right hand side. For
example, customers who sign off the agreed service requirements will also sign off the
service Acceptance Criteria and test plan.
Note the baselines, once each stage is complete it is formally reviewed and agreed
(baselined), any future changes must now be carried out under strict change
management control the impact of a change at any level after baselining will impact
the lower levels and must be considered very carefully

Answer : c

Answer : b

In Service Operation the focus on day-to-day activities to optimize the cost and quality
of the services. This has been described as the "Factory of IT
From customer's viewpoint, Service Operation represents where the actual value is
seen

The Service Desk is a vitally important part of an organization's IT department arid


should be the single point of contact for IT users on a daily basis.
The modern IT Service Desk is customer-facing and by being an effective and
efficient means of customerIT interaction it improves the customer's perception and
satisfaction with IT Services. As a Service Desk matures it should become more
proactive in dealing with customer situations.

Local Service Desk


A single local support desk is viable but having many local support desks within one
organization can present problems. These include:
Not using common processes and procedures across all locations Making localised
skills known and available to other Service Desks Ensuring compatibility of hardware,
software and network infrastructure
Not using the same escalation procedures, and the same impact, severity, priority and
status codes across all locations
Not using common management reporting metrics Not using a (logically) common
shared database

Centralised Service Desk


For organizations located within one region or country, rather than having multiple
local Service Desks, a centralised Service Desk may be used. This has many benefits
including:
Reduced operational costs Consolidated management overview Improved usage of
available resources

Virtual Service Desk


For large, international organizations a Virtual Service Desk may be a solution. The
benefits include:
Reduced operational costs
The scope for a consolidated management overview Improved usage of available
resources However, there are some considerations including:
All persons accessing the Virtual Service Desk should use common processes,
procedures, terminology and language. Customers and users still need to interact with
a single point of contact.
There will be the need for a physical presence on site by a specialist or maintenance
engineer from time to time.
Consistent ownership and management processes for Incidents should be used
throughout the Virtual Service Desk, with automated transfers of Incidents and
Incident views between local desks.

Other Staffing Considerations:


Training
Training plans should include:
A formal induction program including business awareness and
customer service training
Shadowing and mentoring
Technical skills transfer
Keeping abreast of new developments in technology
Staff Retention
Staff retention techniques include:
Role recognition and reward
Team building and rotation
Structured succession planning

Methods of measuring user satisfaction include:


Call-back or outbound telephone survey After-call survey Personal or group interviews
Postal, e-rnail or online surveys
Inclusion of the Service Desk survey in wider IT Satisfaction surveys
Feedback captured in other processes, e.g. Service Level Management reviews

Incident Identification
Incident Management is reactive and cannot be initiated until an Incident has
occurred and been reported
Incidents reports can come from Event management Directly via a web interface
A phone call or e-mail from a user via the Service Desk Incident logging
All Incidents must be logged and date/time stamped Incident categorisation
Reflects the exact type of Incident Categories may be multi-level Incident prioritisation
Priority should reflect the urgency and impact of the Incident and be referenced by
SLAs

Urgency reflects how quickly a resolution is required


Impact reflects the degree of adverse business effect
The priority may need to be adjusted during the life of the Incident
Major Incident identified at this stage

Problem Management works together with Incident and Change Management to


ensure that IT service availability and quality is increased. Problem Management will
use the information from Incident Management to identify ways of speeding up
resolution times and identifying permanent solutions.

Used for servie request and pre approved services and changes (toner change ,re
allocation )

Mainly things that are auto detected and alerted.

Informational categories do not require action and do not represent an exception.


examples a user logs onto an application
a batch job completes successfully.
Warning categories are generated when a service or a device is approaching a
threshold.
example

memory utilization is currently 65% and

increasing. If it reaches 70% performance will begin to degrade.


Exception categories are typically generated when an OLA target or SLA target has
been breached and the business is impacted.

examples server is down


response time is more than 5 seconds (SLA target for acceptable response is 5 seconds
or less).

Console Management Defining and using centralized monitoring capabilities


Job Scheduling The management of routine batch or background jobs or scripts
Back-up and Restore On behalf of Technical and Application Management groups and
users
Print and Output Management The collation and distribution of all centralized printed
or electronic output
Maintenance On behalf of Technical and Application Management

Deming backs up the previous slide as it is a suitable method for ensuring all
improvements are well thought out, their objectives are achieved and they are
embedded into the organisation in order that they do not "slip back".
Plan
Determine goals and targets
Determine methods of reaching the goals
Do
Education and awareness
Implementation plan

Measure performance Check (Study)


Assess the measurements and report results Act
Take action to standardize or improve the process

Look at your organisations reports and ask:


Why are we reporting?
Are we reporting on the right things
Is anyone using the data?
How long do we need to keep measuring?

Examples:
Improvement
XYZ Computing achieved a 20% reduction in the number of failed changes after
implementation of a formal change management process.
Benefits
XYZ Computings 15% reduction in failed changes has saved the company
20,000 in the first year
ROI
The formal Change Management process cost 15,000 to implement, the ROI was
therefore 5,000 or 33%
VOI
The implementation of the formal Change Management process freed up resource in
the IT department (previously used to rework chnages) which could then utilised
elsewhere.

You might also like