Service Operation Fulfillment Access Management Problem Management in ITIL – ITIL Course

Service Operation

Fulfillment Access Management Problem 


Request Fulfillment
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 processare to:
•              Maintain  user  and  customer  satisfaction  through  efficient  and  professional handling of all service requests
•        &n
bsp;     Provide  a channel  for  users  to request  and  receive  standard  services  for which a predefined authorization and qualification process exists
•              Provide informationto users and customers about the availability of services and the procedurefor obtaining them
•              Source  and  deliver  the  components  of  requested  standard  services  (e.g. licences and softwaremedia)
•   Assist with generalinformation, complaints or comments.
The process needed to fulfil a request will vary dependingupon exactly what is being requested,  but can usual
ly 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 throughother processes.

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 requestfrom the organization  to fulfill the Service
Basic Concepts
There are two basic concepts appliedin the Request Fulfillment process:
•   Request Models: Predefined steps to consistentlyhandle frequent requests
•   Service  Request:  Request  from  a user for information,  advice,  a Standard
Change or for access to an IT service

Access Management
In ITIL®, Access  Management  provides  the rightsfor 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 servicewhile preventing access to non-authorized users in order to protect the confidentiality, integrity and availability (CIA) of information and infrastructure.
•   Execute policiesand actions defined in Information  Security and Availability
The objectives of the access management process are to:
•              Manage   access   to  service based  on  policies   and  actions   define in information security management (see ITIL Service Design)
•              Efficiently  respond  to  requests  for  granting  access  to  services,  changing access rights or restricting access, ensuringthat the rights being provided or changedare properly granted
•              Oversee  access  to  services  and  ensure  rights  being  provided  are  not improperlyused
Access management is effectivelythe 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.

The  basic  concept 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  aboutthe 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:  TheService  Desk  will validate  therequest,  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
The   Proble Management   proces aims   at   identifying   the   root   cause(s)   of disruptions, so permanent solutions can be implemented.
The purpose of Problem Management is to minimize the adverse impactof Incidents and Problems on the business that are caused by errors within the IT infrastructure, and to prevent the recurrence of Incidentsrelated 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 implementedappropriately.
Problem management  includes the activities requiredto 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 controlprocedures, especially change management and release and deployment management.
Key Concepts
Key Concepts applied in Problem Management are:
•   Problem: The unknowncause of one or more Incidents
•  &nbsp
;           Workaround: A temporary way of overcoming technicaldifficulties, 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 differentmethods.
A Problem modelis 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 problemexists that has to be resolved.
ƒ    Analysis of incidentsas part of proactiveManagement
•   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 incidentsso 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 targetin place for that priority level.

•    Workarounds
ƒ             In cases wherea workaround  is found, it is important  that the problem record   remains   open   and   detail 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.
< /div>

•   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  resolv 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 majorproblem, 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 seriousfaults, but it is possible that minor faults are not rectified.
Where a decision is made to release something into the production environmentthat includes known deficiencies, these should be logged as Known Errors in the KEDB, together with details of workarounds or resolution activities.

•              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 groupsto 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 primarybenefits of Problem Managementis 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 includecosts that exceed the benefitsof fixing the error, or that the error may be fixed by an upcoming  patchor update from a third party.

ITIL, ITIL Foundation Course, ITIL V3, ITIL Course, ITIL – Course, online itil, itil certification, online material for itil course