Service Operation
Fulfillment Access Management Problem
Management
Request Fulfillment
Introduction
Request Fulfillment helps to process requests
using predefined
and
standardized
approvals.
Goals and Objectives
The purpose of Request fulfilment is the process is managing
the lifecycle
of all service requests from the users.
The objectives of the request fulfilment process
are to:
• Maintain user and customer
satisfaction through
efficient
and
professional
handling of all service requests
• Provide a channel
for
users
to request and receive
standard services
for which a predefined authorization and qualification process exists
• Provide information
to users and customers about the availability of services and the procedure
for obtaining them
• Source
and
deliver the components of requested
standard services
(e.g. licences and software
media)
• Assist with general
information, complaints or comments.
Scope
The process needed to fulfil a
request will vary depending
upon exactly what is
being
requested, but can usually be broken down into a set of activities
that have to be performed. For each request, these activities should be documented
into a request model and
stored in the SKMS. It will be up to each organization
to decide
and documents which service requests it will
handle
through
the
request fufilment
process and which will have to go through
other processes.
Roles
The Request fulfillment
process
is monitored by the Service Desk,
however many roles may play a part in executing or delivering the actual Request.
The roles of Request Fulfillment are undertaken by:
• Service Desk Staff: Together with Incident Management staff is responsible for initial response and handles the request
• Other Staff: Responsible for ensuring eventual fulfillment of the request
• External Suppliers: Upon request
from the organization to fulfill the Service
Request
Basic Concepts
There are two basic concepts applied
in the Request Fulfillment process:
• Request Models: Predefined steps to consistently
handle frequent requests
• Service
Request: Request
from a user for information, advice,
a Standard
Change or for access to an IT service
Access Management
Introduction
In ITIL®, Access Management
provides
the rights
for users to access
services
or group of services that have been agreed.
Purpose and Objectives
The goal of Access Management is to:
• Grant authorized users the right to use a service
while preventing access to non-authorized users in order to
protect the confidentiality, integrity and availability (CIA) of information and infrastructure.
• Execute policies
and actions defined in Information Security and Availability
Management
The objectives of the access management process are to:
• Manage access to services based
on
policies and actions defined in information security management (see ITIL Service Design)
• Efficiently respond
to
requests for
granting access to services, changing access rights or restricting access, ensuring
that the rights being provided or changed
are properly granted
• Oversee
access
to
services
and
ensure
rights being
provided are not improperly
used
Scope
Access management is effectively
the execution of
the policies in information security management, in that it
enables the organization to manage
the
confidentiality, availability and integrity of the organization’s data and intellectual property.
Concepts
The basic
concepts in Access Management must be clearly
understood and differentiated.
• Access: Refers to the scope of services or data that the user can use. In other words: whether or not a user is allowed to use a service.
• Identity: Refers to the information about
the user that is unique to only that user
• Rights: Refers to the actual settings where the user is granted access to a
Service or group of Services
• Service groups: A set of related services to which access simultaneously
• Directory Services: Refers to a specific type of tool that is used to manage access and rights
Roles of Service Operation functions
Activities and functions carried out in Access Management are:
• Service
Desk: The
Service Desk will validate the
request, disseminate the request to appropriate levels and teams; and ensure user has been informed of the status of their request.
• Technical and Applications Management: Assist in the mechanisms
created during Service Design, test the service and perform Access Management for the systems. Sometimes they provide and revoke access to services.
• IT Operations Management: Providing or revoking access to services.
Problem Management
Introduction
The Problem Management
process aims
at
identifying the root
cause(s) of disruptions, so permanent solutions can be implemented.
Purpose
The purpose of Problem Management is to minimize the adverse impact
of Incidents and Problems on the business that are caused by errors within the IT infrastructure, and to prevent the recurrence of Incidents
related to these errors.
Problem Management is the process responsible for:
• Managing the Lifecycle of all Problems.
• Diagnosing the root case
of Problems and
determine the solution to those problems.
• Ensuring that the resolution is implemented
appropriately.
Scope
Problem management includes the activities required
to diagnose the root cause of incidents and to determine the resolution to those problems.
It is also responsible
for ensuring that the resolution is implemented
through
the appropriate control
procedures, especially change management and release and deployment management.
Key Concepts
Key Concepts applied in Problem Management are:
• Problem: The unknown
cause of one or more Incidents
• Workaround: A temporary way of overcoming technical
difficulties, for example, Incidents and Problems
• Known Error: Problem that has a documented root cause and a work-around
• Known Error Database
(KEDB): Database containing all Known Error Records
Basic Concept
Problems are generally unique and needs to be handled using different
methods.
A Problem model
is a way of predefining
the steps that should be taken to handle
Problems caused by a Known Error or an error.
Process Flow
• Problem detection
ƒ There are multiple ways of detecting problems in all organizations. These will include:
ƒ Suspicion or detection of an unknown cause of one or more incidents
by the Service Desk
ƒ Analysis of an incident by a technical support group
ƒ Automated
detection of an infrastructure or application fault, using event/alert tools
ƒ A notification from a supplier or contractor that a problem
exists that has to be resolved.
ƒ Analysis of incidents
as part of proactive
Management
• Problem Logging
ƒ Regardless of the detection method,
all the relevant details of the problem must be recorded so that a full historic record exists.
• Problem Categorization
ƒ Problems must be categorized in the same way as incidents
so that the true nature of the problem
can
be
easily
traced in
the
future
and meaningful management information can be obtained.
• Problem Prioritization
ƒ Problems must be prioritized in the same way and for the same reasons
as incidents.
Problem
Prioritization
should also consider
the severity of the problems.
• Problem Investigation and Diagnosis
ƒ An investigation should be conducted to try to diagnose the root cause of the problem but the appropriate level of resources and expertise should be applied
to finding
a resolution commensurate with
the priority code allocated and the service target
in place for that priority level.
• Workarounds
ƒ In cases where
a workaround is found, it is important
that the problem record remains open
and
details of
the workaround are
always documented within the Problem Record.
• Raising a Known Error Record
ƒ As soon as
the
diagnosis
is
complete, and particularly where
a workaround has been found, a Known Error Record must be raised and placed in the
Known
Error
Database
so
that
if further incidents
or problems arise, they
can
be identified
and
the service
restored
more
quickly.
• Problem Resolution
ƒ Ideally,
as soon
as a solution
has been found,
it should
be applied
to resolve the problem. However, there may be some problems for which a Business Case for resolution cannot be justified. In such cases a
decision
may be taken to leave the Problem Record open but to use a
workaround
description
in
the
Known Error Record
to detect
and resolve any recurrences quickly.
• Problem Closure
ƒ When any
change has been
completed and the resolution has been applied, the Problem Record should be formally closed. The status of any related Known
Error
Record should
be updated to show that the resolution has been applied.
• Major Problem Review
ƒ After every major
problem, a review should be conducted to learn any lessons for the future. Specifically, the review should examine:
¾ Those things that were done correctly
¾ Those things that were done wrong
¾ What could be done better in the future
¾ How to prevent recurrence
¾ Whether there has been any third-party responsibility
It is rare for any new applications, systems
or software releases to be completely error-free. It is more likely that during testing of such new applications,
systems or releases a prioritization system will be used to eradicate the more serious
faults, but it is possible that minor faults are not rectified.
Where a decision is made to release something into the production environment
that includes known deficiencies, these should be logged as Known Errors in the KEDB, together with details of workarounds or resolution activities.
Roles
• Problem Manager: The Problem
Manager is the Single
point of coordination and the owner of the process. Responsibilities include:
ƒ Coordinating all Problem Management activities
ƒ Acting as the liaison with all Problem resolution groups
to ensure the swift resolution of Problems within SLA targets
ƒ Ownership and protection of the Known Error Database
ƒ Gatekeeper for the inclusion of all Known
Errors
and management of search algorithms
ƒ Formal closure of all Problem Records
ƒ Acting as the liaison with suppliers
and contractors to ensure that third parties fulfill their contractual obligations for Problem resolution
ƒ Arranging,
running,
documenting and
all
follow-up
activities
relating
to
Major Problem Reviews
• Problem Solving Group(s) Staff: Performed by one or more technical
support groups, suppliers of support
contractors.
This group ensures allocation of resources is done appropriately.
Relationships
with other Processes
One of the primary
benefits of Problem Management
is demonstrated in the
“Many to One”
relationship between Incidents and Problems.
This enables an IT
Service Provider to
resolve many Incidents in an efficient manner by correcting the underlying root-cause.
However, not all Problems
are diagnosed,
perhaps
because the root-cause of the Problem is not always found. It may also be seen that some Known Errors are not fixed. The reasons for this may include
costs that exceed the benefits
of fixing the error, or that the error may be fixed by an upcoming patch
or update from a third party.
ITIL, ITIL Foundation Course, ITIL V3, ITIL Course, ITIL - Course, online itil, itil certification, online material for itil course
