Avoiding Mistakes when Implementing Incident and Problem Management
Upcoming SlideShare
Loading in...5
×
 

Avoiding Mistakes when Implementing Incident and Problem Management

on

  • 98 views

Many organizations find it attractive to consider Incident and Problem Management as a foothold for implementing IT Service Management. Quite often, such attempts result in situations wherein process ...

Many organizations find it attractive to consider Incident and Problem Management as a foothold for implementing IT Service Management. Quite often, such attempts result in situations wherein process immaturity, excessive bureaucratization or deficient connections between processes become evident.

The lack of a holistic vision of IT and poor organizational change are often some of the reasons behind most these issues.

Javier Garcia shares his thoughts and 25 years of practical expertise to help you identify and rectify common mistakes to ensure that your ITSM strategies will result in both efficiency and maturity moving forward.

Statistics

Views

Total Views
98
Views on SlideShare
85
Embed Views
13

Actions

Likes
0
Downloads
2
Comments
0

1 Embed 13

https://www.linkedin.com 13

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Avoiding Mistakes when Implementing Incident and Problem Management Avoiding Mistakes when Implementing Incident and Problem Management Presentation Transcript

  • Flawless design, implementation and improvement of Incident and Problem Management Javier García Bolao @JGarciaBolao fgarciabolao@gmail.com Avoiding Mistakes
  •  ITIL®: most commonly accepted set of best practices for IT Service Management.  Incident: The unplanned interruption or degradation of an IT service, or the failure of a component that has not yet impacted in the service.  Problem: underlying cause of one or more incidents.  Any IT organization DEALS with incidents and problems, but MANAGING them requires putting processes in place. Laying the Groundwork
  •  Identifying usual mistakes common to many implementations of IT processes for incident and problem management.  Finding possible solutions to such mistakes.  Understanding the relevance of: – Adopting a holistic vision to IT Service Management. – Ensuring the connections between ITSM processes. Objectives of this webinar
  •  Every business has a different answer for this question.  Interdependence with other processes (sets of activities)  It is likely that IM and PM could be implemented first, as long as we don’t neglect the rest of the SLC. Which process should I implement first?
  • Thinking that IT is all about the Operation Stage
  • Linking Incident and Problem Management
  •  A problem is the underlying cause to one or more incidents  An incident NEVER becomes a problem  A problem is not an incident that has to be investigated  A problem is not a major incident  A problem is not an escalated incident  Incident and problem are different concepts Misunderstanding the concept of “problem”
  •  In order to restore the Service, it may be necessary applying a bypass solution (workaround)  The aim of Problem Management should be providing a permanent solution to the the problem. Workarounds becoming permanent solutions
  •  Your Service Desk knows what it takes for being efficient at solving incidents. – Ask them to assist you at defining the IM process – It will facilitate change – It will help you to discover gaps in other SLC stages Defining without taking stakeholders into account
  • Linking Incident Management with CSI and KM
  •  Your Customers are the requestors. Start managing expectations right from the beginning. – Meetings for LISTENING and UNDERSTANDING – Satisfaction surveys – Periodic follow-up meetings Defining without taking stakeholders into account
  •  Most things work best if they are kept simple (K.I.S.S.) – The “S” of K.I.S.S. does NOT stand for “sloppy”  When designing: – Define the objective of the process – Keep in mind the objective along the design stage – First draft with every detail supporting the objective – Final draft only with the essential elements – Simple writing, adequate for different audiences  Mind the culture of the organization – “Culture eats Strategy for breakfast”. Bureaucratizing processes
  •  Understand that you’re leading a change  Put the right people at the right place  Maintain the communication with stakeholders  Service may slip before improving: act in advance  Be proactive in your relationships with customers. Transitioning without good communication
  •  Do NEVER lie about expected outcomes of processes  Drive the change, but MAKE IT THEIR IDEA  You are not “doing ITIL”: you are enabling ITSM Poor organizational change
  •  Know what and when to communicate  Educate and re-educate  “Evangelizing” might not be a good idea within certain organizational cultures.  Communicate with your team: share evidences of improvements. Being unaware of the organizational culture
  • Links to Organizational Change Management
  •  If the role has been assigned to the Service Desk Manager, a certain level of authority has to be clearly defined. Incident Manager doesn’t have enough authority
  •  Getting every incident registered might be challenging, especially at early stages of the implementation.  Not registering systematically will delay the maturation of the process.  Promote the use of Self-Service tools. Incidents are not consistently registered
  •  Stress is a cause for people leaving the SD  Define an operational margin that will enable them to manage peaks  Hold meetings that would allow them to “open the pressure valve” without risk  Do NOT tolerate abuse, but manage the required solution through the right channels Ignoring that your Service Desk is under pressure
  •  SLAs have to be clearly defined and communicated  Users may want their issues fixed “right now”  The success of your Service Desk will depend on your ability to train them on what, when and how to do things. Lack of links with Service Level Management
  • Links to Knowledge Management
  • “Those who forget History Are doomed to repeat it” Marcus Tullius Cicero (106 BC – 43 BC)  Make sure that you preserve the knowledge gained along the IM process and make it available to others who may need to address a similar incident in the future. Not managing the knowledge gained at IM
  •  Measuring is the first thing you should do for improving the performance of your processes.  Start with a baseline of the situation, saving data of how the activities are performing right before the implementation.  If you couldn’t capture a baseline, the first measurement can become your baseline.  Culture: Metrics are NOT bad! Not measuring
  •  Objective CSF KPI Measurement  Mind the business when you define the objective and the CSFs  Present the right information in the right format to the right persons  Data Information Knowledge Wisdom Not measuring (or measuring the wrong thing)
  • Conclusions
  •  A process is just a set of activities for accomplishing a specific objective.  Understand that your IT is a system on which different processes should be naturally inter-connected.  Make sure that the links between processes are connected, “clean” and operational.  MIND THE BUSINESS Conclusions
  • There is no one perfect approach for everyone
  • Javier García Bolao @JGarciaBolao fgarciabolao@gmail.com es.linkedin.com/javiergarciabolao/ Thank you for attending