Service Operation 2 of 3: The Processes

Nov - 12
2018

Service Operation 2 of 3: The Processes

There are 5 processes underService Operation. They are Event Management, Incident Management,  Problem Management, Access Management and Request Fulfilllment Management.
There are 4 functions (and 2 sub-functions) underService Operation. They are Service Desk,  Technical Management, IT Operations (the subfunctions are Operations Control & the Facilities Management) and Application Management.
First the Processes:

1) Event Management:
 
An Event is a change of state which has significance for the management of a Configuration Item or IT Service.
Event Management provides the basis for operational monitoring and control by detecting events, make sense of them and determine the appropriate control action.
An Alert is a warning that a threshold has been reached or that something has changed
Points to remember: 
  • Event Management process is responsible for managing Events throughout their Lifecycle.
  • The scope of Event management, is all the Services and Configuration Items.
  • Event can be classified as Informative, Alerts and Exceptional.
2) Incident Management:
 
An Incident is an unplanned interruption to an IT Service or a reduction in the Quality of an IT Service. Failure of a Configuration Item that has not yet impacted Service is also an Incident.
Incident Management process is responsible for managing Events throughout their Lifecycle. The primary Objective of Incident Management is to return to the “normal” IT Service to Users as quickly as possible.
 
Points to remember: 
  • Understand the differences between Incident Management and Problem Management.
  • The scope also includes the events, which are “likely” to cause an impact to Service.  Eg.: Failure of a Mirror Disk.
  • Major Incidents must have separate procedures, with shorter timescales and greater urgency. The Business Impact determines the priority. priority = impact x urgency.
  • An Incident Model contains the pre-defined steps that should be taken for dealing with a particular type of Incident. This is a way to ensure that routinely occurring Incidents are handled efficiently and effectively. The SLA for the type of Incidents would also be included.
  • The “normal” service means, the service operating within the limits, specified in the SLA.
  • Incident Managements creates value to business, by reducing the impact to the Business (due to the incident), in case the incident is not completely resolved.
  • The closure if Incidents are done by the user. Service Desk does it only with the consent of the user.
  • An Incident Manager should be given the authority to manage Incidents effectively through multiple levels of escalations (L0, L1, L2, L3 etc.), so as to quickly restore incidents.
  • The costs and risks may not be “direct” considerations for the Incident Management process, while resolving the Incidents.
  • Incident data / trends are important inputs to Problem Management.
  • Incident Management & Service Desk enable the Resolver groups be  “away” form direct customer queries. Might result in incidents being managed efficiently.
  • Hierarchical (Vertical with authority. ie.: Management) and Functional (Horizontal with technical capabilities. ie.: Skilled support teams) are both essential, to manage Incidents effectively.
  • Workarounds are used to reducing or eliminate the Impact of an Incident or Problem for which a full Resolution is not yet available. They are pre-defined technique to restore service, as seen before. To be recorded in the Problem record. In the absence of associated Problem record, in the incident record itself.
  • To the Resolvers (and to the Service Desk staff), the following be available, to enable them to quickly provide resolutions:
CMS
KEDB
Workarounds
Tools to search/ access information
Remote (access) Tools
Input from monitoring tools 
 
3) Request Management:
 
An Service Request is arequest from a User for information, or advice, or for a Standard Change or for Access to an IT Service. For example to reset a password, or to provide standard IT Services for a new User. 
Reason for a separate process for managing requests: Many of these are actually small changes – low risk, frequently occurring, low cost, etc. or maybe just a question requesting information. Their scale and frequent, low-risk nature means that they are better handled by a separate process, rather than being allowed to congest and obstruct the normal Incident and Change Management processes. 
Request Fulfillment is influenced heavily by the success of Change Management and what types of pre-approved changes can be effectively managed, controlled and implemented by the IT department.
Points to remember: 
  • Many elements of Request Fullfilment may be automated through the use of self-help such as websites and user applications, with manual activities being used where necessary.  Best activities to automate are the ones which are simple, clear and well-understood.
  • Usually managed by the Service Desk
  • Pre-defined approvals, eligibility criteria and procedures need to be satisfied.
4) Access Management:
 
Access is the level and extent of a service’s functionality or data that a user is entitled to use
 
Access Management grants authorised users the right to use a service (or a group of Services). but denies unauthorized users access.  
Points to remember: 
  • Executes the policies, rules  and actions, specified by the Information Security and Availability Management processes. 
  • Also referred as Identity Management or Rights Management.
5) Problem Management:
 
Problem is the unknown cause of one or more incidents
 
Problem Management is to prevent problems and incidents, eliminate repeating incidents and minimize the impact of incidents that cannot be prevented
Points to remember: 
  • Understand the differences between Problem Management and Incident Management.
  • Problem Management manages the problems throughout their Lifecycle
  • known-error is a problem that has a documented root cause and a work around.  Known Error Database (KEDB) is the repository of all known errors and associated workarounds.
  • ITIL v3 recommends the creation of a Known Error at any point of time, as and when, it could be useful to do so.
  • The Problem Management process is subdivided into Proactive (Through Trend Analysis, by Operations) or Reactive Problem Management (by Operations and by CSI)
  • Generating Root Cause Analysis (RCA) report, following-up for permanent resolutions through change requests, doing a post implementation review(PIR) after the change is implemented and the closure of Problem Ticket after the PIR are some of the Problem management activities.
  • Would follow a similar categorization followed by Incident Management
  • Problem Management uses Incident records as an input.
  • A Major Problem Review examines
  • Things that were done correctly
  • Those things that were done incorrectly
  • How to prevent recurrence and
  • What could be done better in the future
 

 

Leave a Reply

Your email address will not be published. Required fields are marked *

Open chat