Practitioner Course Incident Management & Service Desk

Practitioner Course Incident Management & Service Desk
Give the participants a warm welcome.

Introductions You Your role(s) Your expectations Your presenter
The Art of Service Introduce yourself:increase your credibility by providing your profile (experience) Let the participants introduce themselves. Let them clarify their role(s), current and previous. Take notes, so you can use their experience throughout the course. Eg, is someone was once involved in selecting a reporting tool for availability of IT services, then involve them in that discussion. Exercise 1 is about understanding the expectations. This is a good moment to hand it out. Write their expectations on a flipover and manage their expectations. © TAOS version 0.1

Program 09.00 Start 10.30 Morning tea / coffee 12.30 Lunch
Afternoon tea / coffee 17.00 End Spend also some time on: - Where are the toilets? - Where are the fire exits? - Switch off mobile phones. - Etc. © TAOS version 0.1

Agenda Day One: Day Two General Introduction
Overview Service Management Overview IT Infrastructure Library Service Desk Incident Management (part I) Case Analysis Day Two Incident Management (part II) Tools Reporting Exercises Exam preparation ITIL Foundations is a prerequisite for this course, but it can be some time ago that they actually did this course. Therefore, some time will be spend on going through the entire ITIL model. Special focus will be on the relationships between Incident Management & Service Desk and all other processes. © TAOS version 0.1

Course Objectives In-depth understanding of the Incident Management process and its activities. In-depth understanding of the Service Desk function. Good understanding of the relationships with all other IT Service Management processes. Ability to execute the Incident Management activities and work within the Service Desk function. Preparation for the EXIN Practitioner Exam Case based 120 minutes 40 multiple choice questions (pass mark = 26 points) Check that this is what they want to get out of this course. Does it meet their expectations on the flipover? © TAOS version 0.1

Course Approach Presentations Discussions Exercises Hand outs
Slides handouts in your binders Discussions Exchange experiences Exercises Going through the process of reaching a solution Hand outs Reference materials for back in the office: Syllabus Case studies (source: Internet) White Papers (source: Internet) Just to let the participants know, this course is not a one way presentation. About 70% is covered in exercises and discussions. Show them the binder and go through it. © TAOS version 0.1

Overview Service Management
Give a brief overview of the whole IT Service Management concept. ITIL Foundations is a prerequisite for this Practitioner Course. So, keep it to brief overview. Refresh their memory!! © TAOS version 0.1

Why Service Management?
Business more and more dependent on IT Complexity of technology increases Customers demand more Environment becomes more competitive Focus on controlling costs of IT Low customer satisfaction ... Do they recognise this? © TAOS version 0.1

Service Management = The Objective Tree =
Quality Flexibility Cost management ORGANISATION BUSINESS PROCESSES How / What ? Why! IT SERVICE PROVISION ITSM is not something on its own, but closely linked to the business. Explain difference between ‘effective’ and ‘efficient’. SERVICE MANAGEMENT effective efficient organisation IT service provision © TAOS version 0.1

The Functionally Oriented Organisation
GOAL GOAL GOAL GOAL GOAL GOAL ACTIVITIES ACTIVITIES ACTIVITIES ACTIVITIES ACTIVITIES ACTIVITIES FEEDBACK FEEDBACK FEEDBACK FEEDBACK FEEDBACK FEEDBACK Explain the characteristics of a “purely” functionally oriented organisation. RESULT RESULT RESULT RESULT RESULT RESULT the lines decide © TAOS version 0.1

The Process Driven Organisation
Explain the characteristics of a “purely” process driven organisation. Explain the benefits of processes in general. Draw a basis process diagram on the broad and explain: - process is a set of activities with a common goal. - can measure the input, output and activities. - link these measurements to targets. - targets come from SLAs and organisational objectives. GOAL ACTIVITIES RESULT the processes decide © TAOS version 0.1 FEEDBACK

Positioning ITSM Processes
Incidents problems CMDB Collect Config. Data Forward Events ... Convert Events System Management Layer Agent Layer Service Management Layer Store Performance Data Incident and Problem Mngt Configuration Mngt Change Management etc. Event Browser display Performance Data Summaries Performance Data Analyse Performance Data Application Topology Operator Support Personell Service Level Management Layer SLA Availability Performance Management Capacity Planning Operational Infrastructure Business View Network Intranet Application Systems Databases Management Processes Positioning ITSM Processes Explain how the ten ITSM processes fit at the various layers: the Strategic, the Tactical and the Operational Also, this slide gives the more technical staff the assurance that they can still do the things they like. An IT organisation still needs skilled IT staff on a technical level (operational infrastructure level). The only thing IT Service Management changes is the way the activities are managed. Availability Management is a tactical process, but a lot of measurements on individual components takes place at an operational level. © TAOS version 0.1

IT Service Management (ITSM) Focus
Organisation People During the next two days we will focus on one of the processes (Availability Management). But an IT organisation needs to focus on all these aspects to deliver the right IT services (effective) in the right way (efficient). Generally, the technology perspective gets a lot of attention (time, budget, people etc). More and more people see the importance of processes (which is why ITIL is getting so popular). There is also an organisation perspective: the alignment of vision, strategy and goals with the day to day activities in IT. This is useless, if it is not communicated (which is virtually always the case [in my experience, MB] And finally, there is the people perspective, which looks at the ‘soft side’: is your staff happy, do they have the right skills, are you managing them effectively etc. Don’t just show this slide, get them to play around with it with examples Process Technology © TAOS version 0.1

Continuous Improvement
Plan Do Act Check Explain that continuous improvement is a part of every process. Implementing ITIL is not about setting up a project, implementing it and moving on to the next challenge: It is an ongoing this, where you improve quality through incremental steps. Quality Assurance Improvement Source: Deming © TAOS version 0.1

Questions? ? This slide provides a natural break in the course. If there are no questions from the participants, maybe you can ask them something. Start a discussion. Ask about their experiences. Give them some extra real life examples. © TAOS version 0.1

Overview IT Infrastructure Library
Give an overview of the ITIL model. ITIL Foundations is a prerequisite for this Practitioner Course. So, keep it to brief overview. Refresh their memory!! © TAOS version 0.1

ITIL Jigsaw Implementing ITIL
ITIL is a set of books. This jigsaw gives an overview of the new set of books. © TAOS version 0.1

What is ITIL all about? Developed by the British Government
Official standard (BSI No: PD0005) in the UK De facto standard in Europe A “framework” and not a methodology A non-proprietary set of best practices A process based approach A quality approach (and can support ISO certification) Providing “optimal service provision” (balanced with costs) Aligning IT services with business requirements Explain that ITIL is a “framework” for organisations to design their own processes. It does not tell you step-by-step how to do it (e.g. make your cluster of HP Unix boxes more reliable). © TAOS version 0.1

Who is involved in ITIL? OGC - Office of Government Commerce
Before April 2001: CCTA “Owns” ITIL itSMF - IT Service Management Forum Membership based networking forum for ITIL EXIN, ISEB and others Examining bodies The Art of Service and others Accredited providers of ITIL education and consultancy Promote membership of itSMF. © TAOS version 0.1

ITIL: Service Support Processes
Service Desk Change Management Incident Management Configuration Management This is one of many models of the Service Support processes (developed by Michiel Berkhout). CFG is in the center, as all other processes feed into it. IM and CHG are closely related to the Service Desk, PM and RM more back-office. Use this slide to explain the processes and especially their relationships. Ultimately, all processes relate to each other. Ask for examples! Spend some, but not a lot on the relationships between Incident Management and these processes. This is part of exercise 2. Release Management Problem Management service continuity service control service flexibility © TAOS version 0.1

ITIL: Service Delivery Processes
defining services Service Level Management IT Service Continuity Management Financial Management managing $ managing risk This is one of many models of the Service Delivery processes (developed by Michiel Berkhout). It shows four perspectives to Service Delivery: defining services (through the customers), providing services (through service providers, internal & external), managing costs & revenues (or $) and risk management. CAP and AVM are drawn closely together, simply because of their close relationship. By drawing a vertical line through the middle (through SLM and CAP/AVM) you’ll see the IT value chain: service providers – ITSM – customers, again stressing that the business (customer) is the end point. In practice, participants easily get confused with CAP and AVM. Explain the difference (up front) with a non-IT example: Imagine you’re having a good night with the lads: soccer and beer (this will get their attention). The things you might be concerned with are: Is the TV working? -> AVM Is there enough beer? -> CAP Is the beer cold enough, ie is the fridge working? ->AVM Are there enough seats? CAP What options are there to prepare for this great night?? spare TV (AVM / ITSCM) Spare fridge (same) Check # friends coming over (CAP) Agreement with neighbours, regarding beer (CAP) Agreement with neighbours, regarding TV (AVM / ITSCM) Cushions / spare chairs (CAP) While you’re at it, make sure the difference between AVM and ITSCM is clear; if not, explain or refer to later on when ITSCM is covered. Spend some, but not a lot on the relationships between Incident Management and these processes. This is part of exercise 2. Capacity Management Availability Management providing services © TAOS version 0.1

Service Level Management
Key Relationships Service Level Management Incident Management Service Desk Nothing new, just a selection of the previous slides. Incident Management is owned by the SD, hence sits on top of it, although IM activities of course are carried out throughout the support organisation. SLM provides guidelines through SLAs. Problem management focuses on underlying causes and will provide the SD with info on known errors, problems and workarounds. The SD can be an input to Chg Mgt by passing through RFCs and acting as a 2-way info centre, publishing FSCs etc. Also mention the role of standard changes. Spend some, but not a lot on the relationships between the Service Desk function and these processes. This is part of exercise 2. Problem Management Change Management © TAOS version 0.1

ITIL Service Management
security IT Service Continuity Management Availability Management Capacity Management Service Delivery Set IT Infrastructure Financial Management for IT services Release Management Service Support Set Service Level Management Change Management Put this slide up during the discussion around exercise 2. Let the students explain what the relationships are between Incident Management & Service Desk and the other IT Service Management processes. Correct them if they are wrong!! Make sure that they understand that Incident Management is not an isolated process, but: - Provides input for Problem Management - Changes can cause new Incidents - Information needed from Configuration Management - Resolution targets in the Service Level Agreements - Extreme Incident might invoke the ITSCM Plan - etc. Service Desk Configuration Management Incident Management Problem Management © TAOS version 0.1

Service Desk Homework: study the Handout Notes.
The Service Desk is there to structure the communication at operational level between the end-users and the IT organisation. A full blown Service Desk serves as the front office for the other IT departments, and can deal with many customer queries without needing to contact specialist personnel. © TAOS version 0.1

The Service Desk The Service Desk
supports the agreed IT service provision by ensuring the accessibility and availability of the IT-organisation and by performing various supporting activities. © TAOS version 0.1

The Service Desk Role Service Desk 1st line 2nd line 3rd line support
Support group Support group Customer & End User Service Desk support call Support group Support group solution The main SD role is that of single point of contact (SPOC). You want to avoid users calling the various support groups all the time. What happens within an organisation without a single point of contact? -> end-users spend a lot of their time on solving technical problems and on co-ordination technical work. Do they recognise this: a business manager organising a telephone, desktop, user-ids, network patch etc. for a new staff member. This business manager should spend his / her time on his / her own job and the Service Desk should do all this co-ordinating work (Standard Change or Service Request)! Support group Organisation 1st line 2nd line 3rd line Source: the Art of Service © TAOS version 0.1

Activities Contact with / supporting the users Management tasks
processing of incidents processing of service requests processing of (standard) requests for change Management tasks controlling maintenance suppliers backups, restores, user accounts, … Incident: e.g. screen of laptop freezes. Service request: e.g. a question about the opening hours of the SD. Request for change: e.g. a new laptop. Some organisations have given the SD a very central role within the IT department, in which they manage suppliers, manage the CMDB, manage backups etc… © TAOS version 0.1

Reactive or Proactive ? (I)
customer call work around pro-active support of business operations knowledge of business operations The Service Desk Have a discussion on whether the Service Desk is reactive or proactive. Service Desk integrates on an operational level IT with the business processes and needs to be proactive to add maximum value to the business. incident 1st / 2nd / 3rd line support © TAOS version 0.1

Reactive or Proactive ? (II)
customer pro-active support of business operations knowledge of business operations knowledge of customer(& -processes) is necessary unambiguous determination of urgency insight in impact of incidents timely (pro-active) action becomes possible personal approach of the customer becomes possible Have a discussion on whether the Service Desk is reactive or proactive. What information does the Service Desk need to be proactive? Service Desk integrates on an operational level IT with the business processes and needs to be proactive to add maximum value to the business. © TAOS version 0.1

Service Desk Types (I) Expert SD Skilled SD Unskilled SD Call Center
First line resolution Skill level 100% Expert SD Skilled SD Unskilled SD Four main types of SD, ranging from call center to expert SD. As you climb up, the skill level increases, as will the costs (of the SD). [call center just passes on calls; unskilled SD solves a few; skilled SD solves a lot; expert SD solves everything!] Give examples of all 4 types and discuss where which type would be appropriate. Call Center 0 % Costs Source: the Art of Service © TAOS version 0.1

Service Desk Types (II)
Call Centre only logging of calls rapid response through short conversations doesn’t offer solutions direct transfer to specialised IT personnel Unskilled Service Desk raw data  quick routing (“call dispatch”) skilled in supervising incident progress standards and procedures necessary (telephone-)scripts necessary Explain each type. Ask what type of Service Desk the participants are working on. What do they see as the benefits / disadvantages of each type? © TAOS version 0.1

Service Desk Types (III)
Skilled Service Desk solves large % incidents little routing various specialisms present risks too involved with complex problems expertise causes certain level of arrogance perform only the “nice tasks” that go with their own specialisation Explain each type. Ask what type of Service Desk the participants are working on. What do they see as the benefits / disadvantages of each type? © TAOS version 0.1

Service Desk Types (IV)
Expert Service Desk all incidents and problems are solved strong interlink with Problem Management very well educated personnel (expensive) qualified personnel is hard to get and /or to keep extensive and intensive training (expensive) use of specialised / dedicated diagnostic tools (expensive) Explain each type. Ask what type of Service Desk the participants are working on. What do they see as the benefits / disadvantages of each type? © TAOS version 0.1

Centralised Service Desk
Organisation (I) Centralised Service Desk User Group User Group User Group Service Desk This slide and the next 3 show different organisational forms for the Service Desk. The central Service Desk is based on the concept of 1 Service Desk for the organisation. Support Group Source: OGC (Service Support) © TAOS version 0.1

Distributed Service Desk
Organisation (II) Distributed Service Desk User Group Service Desk Service Desk Service Desk This organisation type has a dedicated Service Desk for each customer group – usually, this is a regional split, e.g. a North America, Europe and Asia Pacific Service Desk. Occasionally, a central Service Desk is chosen for specific tasks, such as providing management reports. Support Group Source: OGC (Service Support) © TAOS version 0.1

Split Function Service Desk
Organisation (III) Split Function Service Desk User Group Service Desk Service Desk A split function Service Desk could be chosen if e.g. you have an IT and a business Service Desk. Both Service Desks are seen as a central point of contact for their specific responsibilities. Attention should be give to making it clear to users which desk does what. The desks can share procedures, communication activities etc. Support Group Source: OGC (Service Support) © TAOS version 0.1

Organisation (IV) Virtual Service Desk User Group User Group
SD Analyst SD Analyst Service Desk SD Analyst SD Analyst SD Analyst SD Analyst In the virtual Service Desk, the analysts could physically be anywhere! They could be grouped over the organisation, over several locations or even working separately from home. Think about the technology you’d need to do this. Support Group Source: OGC (Service Support) © TAOS version 0.1

business understanding
Knowledge & Skills technical skills communication skills business understanding Basically, there are three areas of required expertise for Service Desk staff: Technical skills for first line call resolution (unless it’s a call center). Communication skills: listening, reasoning, negotiating, conflict resolution etc… Business understanding: in order to determine the effect of incidents, requests etc on the business – this one is usually understated It is up to the organisation to determine the focus of skills: how much technical etc? Question: “What’s the focus in your organisations?” Source: the Art of Service © TAOS version 0.1

STAFF TURNOVER - FRIEND OR FOE?
Resources Number of SD staff will depend on: Size of organisation (number of users) Type of organisation Complexity of IT infrastructure Reliability of infrastructure Diversity of systems (degree of standard / non standard systems) Geographical locations Service Level Agreements Budget Discussion Also discuss the type of resources that you need Discuss the fact that many IT staff look down on Call Centre staff and how to overcome this perceived low value thin. How do you minimise / mitigate the high turnaround figures at a Call Centre? Look at STAFF TURNOVER - FRIEND OR FOE? Submitted February 18, 2000 by John Carver, Call Centre Manager Bank of Montreal, MasterCard Division. What's the most likely topic of conversation when two or more Call Centre Managers get together? New technology is sometimes discussed and/or debated. Good management practices may be shared. Benchmarking, targets, first call resolution, customer complaints, the web, results...some of these issues may creep into the conversation. It depends on how well the members of the group know each other. But without fail, in a formal group meeting or in a subsequent social get-together, EMPLOYEE TURNOVER is raised, and usually in negative tones. Why is that? Turnover has traditionally been viewed as a negative measure. The higher the turnover rate, the more the Call Centre Manager has been perceived to be ineffective. High turnover causes higher recruitment, hiring and training expenses. Is there a cause and effect between turnover and morale? Does high turnover lead to bad morale or visa versa? But it doesn't have to be that way. Turnover can be viewed positively. In our Call Centre turnover is encouraged, in fact, celebrated. The higher, the better. It's part of our Culture. A week without a couple of promotions out of the centre is a rare one. No, I haven't lost my mind. Let me explain. When we hire into our Call Centre we hire people looking for a career, not just in the Call Centre, but anywhere in our Bank. We recognise that many have higher ambitions, and that they are applying for a Call Centre agent position because they see it as a door opener. I talk with each new hire class and let them know we're OK with that, and that we're here to give them a start, an entry into the Bank of Montreal. We give them a fantastic grounding in sales and service in the card business, where they master negotiation and communication skills, and then send them on their way. Be successful in our Call Centre and your management team will do all it can to help you move along with your career. Two years ago we had a 100% turnover rate. Last year and this year to date it's running at 60%. We see ourselves as a human resource pool for our Bank. I believe this strategy is worth considering in any call centre in any industry. Is there a better way to become well versed in your business than to talk with 100 or more of your customers every day for a year or two? If this strategy doesn't fit your particular situation, there are many other good reasons to view turnover positively. Here's a few to consider: Attitude: If your hiring is done right, new agents will bring positive attitudes to your centre. We've found that new agents are generally very receptive to change, and we all know, change is a way of life in call centres. Enthusiasm: Don't exclude students when hiring new agents. You may have to work their school hours into your schedule, but once this is accomplished, they are receptive to flex hours which is a plus for most call centres...and, they are full of enthusiasm. How long has it been since you heard a positive buzz on your floor? Students do that for you. Another plus...many will return to you when they have completed their education. Training: Turnover means new, fresh minds to challenge your training group, and challenged minds become more creative. Morale: Yes, morale can improve with high turnover. We've proved it in our centre. Our employee commitment index is the 10 highest in our bank (of 700 groups measured) and best of groups with more than 100 people. As we all know, call centres are not expected to lead the way in morale measures. There are other good reasons to view turnover positively, but these, to me, are significant ones, worthy of mention. The most important message I can provide is "start looking at, and talking of turnover in a positive light". Be a leader in this regard. When the Manager sets the climate, employees respond. submitted by: John Carver, Canadian winner of the 1999 Global Call Centre Manager of the Year Award Bank of Montreal, MasterCard Division. Back to The top of the Page or to The Case Files or Home Page © TAOS version 0.1

Statements – What do you think?
“Service Desk staff should be selected on their communication, rather than technical skills” “A single point of contact is a utopia: there will always be users who call IT staff directly” Statement #1 is v. extreme; of course, communication skills are important, but so are technical and business skills. If you opt for a call center function, then the statement is valid. Statement #2: if this is so, ask yourself why?? And how is it dealt with? Why is it important to deal with users bypassing the SD? © TAOS version 0.1

Incident Management Homework: study the Handout Notes.
© TAOS version 0.1

Service Management = The Objective Tree =
Quality Flexibility Cost management ORGANISATION BUSINESS PROCESSES How / What ? Why! IT SERVICE PROVISION Incident Management is not a process on its own, but linked to the business. E.g. how priorities are set is at the Service Desk is dependent what business processes are the most critical. SERVICE MANAGEMENT effective efficient Organisation IT service provision Incident Management © TAOS version 0.1

The Service Support Set = Interconnection between the processes =
M D B D S L H Incident Management Problem Management Change Management Configuration Management Release Management Problem Work Around Known Error Customer, Supplier, etc. RFC Focus on the relationship between: Incidents, Problems, Known Errors, RFCs and structural resolution. Focus on the fact that the goals of Incident Management and Problem Management are conflicting. Make sure the participants fully understand the difference. Change SOLUTION © TAOS version 0.1

Incident Management = Goal of the process =
restores normal service operation as quickly as possible with minimal disruption to the business, thus ensuring that the agreed levels of availability and service are maintained. Focus is on “as quickly as possible”. So, providing Work-arounds is fully accepted. Incident Management is NOT about root cause analysis or implementing structural solutions. Normal service operation is defined in the SLAs. © TAOS version 0.1

Terminology (I) incident
any event which is not part of the standard operation of a service and which causes, or may cause, an interruption to, or a reduction in the quality of that service can be reported by: users IT service provision IT systems  events … Explain the definition. © TAOS version 0.1

Terminology (II) service request
a request by a user for information, advice or documentation functional question request information request status account request batch jobs request back ups / restores request password / authorisation … Explain the definition. © TAOS version 0.1

= Service Desk responsibility
Process Model Detection & Recording Classification & Initial Support Ownership, Monitoring, Tracking & Communication Investigation & Diagnosis Resolution & Recovery Each activity will be explained in next slides. Ask why the Service Desk should own the recording, closing and monitoring activity. Ask them to list the inputs and outputs of the process. The inputs of the Incident Management process are: Incident details sourced from (for example) Service Desk, networks or computer operations. Configuration details from the Configuration Management Database (CMDB) Response from Incident matching against Problems and Known Errors. Resolution details Response on RFC to effect resolution for Incident(s). The outputs of the Incident Management process are: RFC for Incident resolution; updated Incident record (including resolution and / or Work-arounds) Resolved and closed Incidents Communication to Customers Management information (reports) Closure = Service Desk responsibility © TAOS version 0.1

Incident Detection & Recording
Which incidents? Incident sources? (where from?) What information? How much detail? Who’s responsibility Classification Monitoring Investigation Resolution Closure Incidents can come from different sources: detection and reporting by a user incident logging via telephone, , fax, … detection by a system event is automatically logged as incident detection by Service Desk personnel personnel takes care of incident logging detection by personnel of another IT department personnel takes care of incident logging or reporting via Incident Management The tasks within this activity are: Record basic details of the Incident Alert specialist support group(s) as necessary Start procedures for handling the service request © TAOS version 0.1

Classification & Initial Support (I)
Recording Priority, based on: Impact & Urgency Type of incident: Eg mainframe, desktop, application Need clear guidelines for quick entry: Simple Unambiguous Effective Classification Monitoring Investigation Resolution Closure The tasks for this activity are: Classify Incidents Matching against Known Errors and Problems Informing Problem Management of the existence of new Problems and of unmatched or multiple Incidents Assigning impact and urgency, and thereby defining priority Assessing related configuration details Providing initial support (assess Incident details, find quick resolution) Closing the Incident or routing to a specialist support group, and informing the User(s) © TAOS version 0.1

Classification & Initial Support (II)
Urgency 1 2 3 1 1 2 3 Priority Impact 2 2 3 4 Impact: degree to which the business is effected by the incident Priority: degree to which the incident resolution can be delayed (this includes ease with which incident can be solved). Expected effort plays also a role. Ask participants to give examples for the extremes in the diagram (outer corners) 3 3 4 5 Source: OGC (Service Support) © TAOS version 0.1

Classification & Initial Support (III)
Incident Matching Has a similar Incident occurred before? is a provisional solution known (work around)? Can the Incident be related to an already existing Problem or Known Error? Spend some time on making the difference between Incidents and Problems clear. Spend some time on the relationships between Incident, Problem, Known Error, Request for Change, structural resolution. © TAOS version 0.1

Investigation & Diagnosis (I)
Recording Can take place anywhere in support area If necessary, escalate! Dependant on CMDB Classification Monitoring Investigation Resolution Closure The tasks for this activity are: Assessment of the Incident details Collection and analysis of all related information, and resolution (including any Work-around) or a route to n-line support © TAOS version 0.1

Investigation & Diagnosis (II)
Hierarchical Escalation Combination Functional: to find someone who can solve the incident Hierarchical: to inform someone of the incident (and the [potential] effects on the SLA) In practice, they will often be combined. Give examples!! Functional Escalation Source: the Art of Service © TAOS version 0.1

Resolution & Recovery Not interested in underlying cause
Recording Not interested in underlying cause Focus on removing symptoms Solved when original functionality retained (e.g. user can print again) Classification Monitoring Investigation Resolution Closure The tasks for this activity are: Resolve the Incident using the solution / Work-around or, alternatively, to raise an RFC (including a check for resolution) Take recovery actions © TAOS version 0.1

Incident closure Only after consulting with user
Recording Only after consulting with user Only done by Service Desk Classification Monitoring Investigation Resolution Closure The tasks for this activity are: The confirmation of the resolution with the Customer or originator Update Incident details Close Incident © TAOS version 0.1

Ownership, Monitoring, Tracking & Communication
Recording Service Desk accountable for ALL incidents, regardless of who’s dealing with them Service Desk should have authority to (re)allocate resources in other areas Hierarchical escalation to inform management Focus on SLAs Support tool helps keep track of multiple incidents Classification Monitoring Investigation Resolution Closure The tasks for this activity are: Monitor Incidents Escalate Incidents Inform User © TAOS version 0.1

Process, Procedure & Work Flow (I)
Why & how? Procedures What, who, when & where? All of these should be aligned. So start with high level process. Exercise 4 with this module asks them to come up with Service Desk / Incident Management procedures and after selecting one, mapping it out. Work instructions are very operational, usually with screen shots of the tool used. Work instructions How (exactly)? © TAOS version 0.1

Process, Procedure & Work Flow (II)
Swim lane Result Trigger Process Flow Decision Process Step Record call Solved? phone This should help them in the exercise If necessary, demonstrate with a simple process on the chart. solved Service Desk Operations © TAOS version 0.1

Process, Procedure & Work Flow (III)
AR Step 4 A R Step 3 C Step 2 Step 1 Group D Group C Group B Group A ARCI Model Index: A: Accountable (owns it) R: Responsible (does it) C: Consulted (provides info) I: Informed (receives info) Model to link process activities with responsibilities. 4 types of responsibilities (in blue index). This works on any level, so process, procedure etc. Steps within process/procedure on vertical axis. Rules: only 1 ‘A’ per row (clear ownership), at least 1 ‘R’ per row, as many of the others as necessary. If a certain column remains empty, then that group has no involvement in process. If multiple columns have identical entries, than those groups can be merged from a process point of view. © TAOS version 0.1

Incident Management = Costs, Points of Attention, Advantages =
P ersonnel A ccommodation also for physical storage of process documents, … S oftware tools and equipment for analysis, reporting and H ardware communication (e.g. adjustments to telephone system) E ducation ITIL Master Class / IM-Practitioner, telephone training, communication training, … P rocedures design & manage Incident Management, documentation, instruction sets (telephone scripts), … Self-explanatory. © TAOS version 0.1

Points of Attention - general social skills of the service personnel work overload / stress bottleneck if many incidents through lack of time incidents are no longer optimally (or even not at all any more) registered bypassing by users the “FUTZ-factor” (valuable data is lost) Gartner in starting phase a lot of 2nd line involvement process discipline the process driven way of working often demands a change in culture: resistance within the organisation Self-explanatory. © TAOS version 0.1

Points of Attention - incident handling are all calls registered? under a unique number? which priority codes do we use and how is the priority determined? organisation of the 1st line organisation of the 2nd line which % “closed on first call” is possible through Incident Management? Self-explanatory. © TAOS version 0.1

Points of Attention – incident handling coding system for incident categorisation coding system for priority codes agreements on the long and short error description (form + content + language) the incident categorisation is related to / depends on other incidents, problems or known errors. procedures for closing incidents (telephone-)scripts Self-explanatory. © TAOS version 0.1

General Advantages ongoing optimisation of the (availability of) IT service provision reduction of the number of incidents independent, customer oriented tracking and guarding of incidents no more “lost” or “forgotten” incidents better deployment of IT-personnel useful reporting by effective usage of the available information Self-explanatory. © TAOS version 0.1

Advantages to the Customer enhanced relationship between customer and IT through optimal and clear communication there is no need for the customer to have extensive IT-knowledge development of a knowledge centre for the customer increase in productivity through: quick, timely solutions decrease of the number of incidents pro-active warning with potential problems pro-active identification of the consequences when problems arise Self-explanatory. © TAOS version 0.1

Incident Management = Functionally Oriented vs. Process Driven =
mainframe network pc-lan Incident Management The Art of Incident Management is a process, which runs through all departments involved in restoring normal service operation. Not only the Service Desk, but also Network Support, Application Development etc. Incident Management is owned by the Service Desk. © TAOS version 0.1

Tools for Incident Management & Service Desk
The next few slides are on the technology that is used to support the Incident Management process and / or the Service Desk function. © TAOS version 0.1

Service Desk Support Tools (I)
Service Desk / Help Desk tools Telephony tools Service Management tools (Configuration, Problem, Change Management) Network monitoring tools (availability, capacity) Network Management tools (remote support, user account management) Release Management tools Knowledge Management tools Any more detail would be welcome © TAOS version 0.1

Service Desk Support Tools (II)
Websites to check out: Search on Google: Service Desk, Call Centre, Helpdesk tool, Support tool (support tools) (white papers) Any more detail would be welcome © TAOS version 0.1

Tool Selection (I) Tool requirements: Determine need / nice to haves
Which fields to support process? User friendliness Speed Knowledge base: search on historical info? Security: read / write access Modules Reporting functionality Selecting a tool involves tool requirements and vendor requirements. You could have a great tool, but if the supplier goes bankrupt, you’re stuck. These are fairly straightforward requirements: what else can you come up with? © TAOS version 0.1

Tool Selection (II) Vendor requirements: Reputation / history
Support focus Training & consulting? Future plans (new modules?) ITIL awareness? References (visit them!) Partnership? As mentioned on previous page, equally important. Explain the potential role of the itSMF in tool selection (networking with peers / references). Exercise 5 is about the formulation of requirements for a tool that needs to support the Service Desk and Incident Management process. Consider to separate into the following groups: - Service Desk staff -> need to use the tool daily. - Service Desk manager -> needs to manage / report on the process. - IT Manager -> needs to pay for the tool. © TAOS version 0.1

Costs associated with tools
Tool costs: Back end Front end: licenses Equipment costs: Server / disk space Network capacity Desktop requirements? Training: Support staff Tool maintenance staff Consulting: Tool configuration (Future) changes: adaptability? TCO of tool is (much) more than what you initially think See Peregrine slides (on your CD-ROM) © TAOS version 0.1

Selection Process Set up a project structure Project manager & team
Scope Deadlines / time frame (project plan) Selection criteria Request for tender (optional) Short list vendors Presentations / demo’s Final cost benefit analysis Selection Buying a tool should be considered as a project in itself, given the costs (previous page) © TAOS version 0.1

Reporting for Incident Management & Service Desk
The next few slides are on reporting and answers questions like: How to align the Service Desk to the business strategy? What to measure? What to report on? © TAOS version 0.1

Aligning Goals Vision / mission statement Strategy / business plan
Goals / objectives Exercise 6 with module 2 has to do with formulating a mission statement. A Mission Statement should be appropriate for a specific organisation. Avoid fuzzy, generic, non-committal statements (like the one in the slide). A Mission Statement should provide staff with a clear direction, a sense of motivation and a base for operational goals. The business plan will explain how you intend to realise your vision or live up to your mission statement. The goals / objectives are specific components of this (make sure they are SMART). The KPIs will tell you to what degree you’re successful. Link this back to the Objective Tree and the different definitions of the Service Desk structures. Key Performance Indicators (KPIs) © TAOS version 0.1

Reporting (I) Efficiency: Productivity: # staff per period Value add:
First line resolution Knowledge mgt: # knowledge base hits etc… Effectiveness: Timeliness: Resolution time Accuracy: % correct resolution Quality: % solved within SLA etc… Explain difference in efficiency and effectiveness. What generic metrics can they come up with? © TAOS version 0.1

Reporting (II) Questions: What? Who? Where? When? Why??
Straightforward questions around reporting: What are we reporting on: KPIs Who is responsible: for getting info (authority?), for putting it together, for QA, for distribution, to whom and who acts upon this info?? Where does the info come from? Which department? Which persons? Which specific systems? Restrictions?? When does all of this take place? Gathering info? Putting it together? Sending out reports? Review/follow up? Who determines this? And finally, why are we doing this? So, is there enough commitment around reporting, both from sending, as the receiving end?? Is all of this documented? Are there procedures around reporting? © TAOS version 0.1

Reporting (III) Report to various target groups Report on (e.g.)
customer, other process managers, company management Report on (e.g.) # reported and registered incidents, # solved incidents perhaps divided according to processing time and solution time # open incidents + their status list of incidents per time frame, customer(group), solution group, category, priority, per … These are specific examples for the Incident Management process. © TAOS version 0.1

Practitioner Course Incident Management & Service Desk

Similar presentations

Presentation on theme: "Practitioner Course Incident Management & Service Desk"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Practitioner Course Incident Management & Service Desk

Similar presentations

Presentation on theme: "Practitioner Course Incident Management & Service Desk"— Presentation transcript:

Similar presentations

About project

Feedback