downloaded here

Caterpillar: Confidential Green

Solar IT Service Management

Incident / Change / Problem

“Setting Standards In Motion”


Class Goals Overview - (05 Mins)

Intro To ITIL / ITSM - (10 Mins)

Incident Management Process - (95 Mins)

Lunch or Break - (30 Mins)

Get Answers/ITSCAT/SC Use - (30 Mins)

Change Management Process - (60 Mins)

Problem Management Process - (15 Mins)

Class Agenda


Why is Solar doing This?

Promote Better Internal processes

Promote Improved Communication• EOS Survey

Set Forth Standards Enforce Expectations .. What is “my” role?

Timeliness – Many new employees• Since last formal training

Class Goals Overview


Together we proactively address IT security concerns

Together we deliver quality products and services utilizing our combined global competencies

Together we intelligently simplify our products and services

Together we utilize standard tools and supporting processes

Together we celebrate successful deployments that deliver positive business results

Together we comply to the standards set for IT performance

“One IT” Will Be A Success When . . .

You are Fully Engaged in Relentless Execution with Us--John Heller / CAT Global IT VP and CIO

and . . .


Intro To ITIL / ITSM


ITIL (®) - IT Infrastructure Library• Series of documents used to aid the

implementation of a framework for IT Service Management (ITSM).

• This framework defines how Service Management is applied within specific organizations.

• Being a framework, it is completely customizable for applications within any type of business or organization that has a reliance on IT infrastructure



The IT Infrastructure Library consists of 5 volumes:1) Service Strategy

2) Service Design

3) Service Transition

4) Service Operation

5) Continual Service Improvement

UK Government originally created the ITIL

Rapidly been adopted across the world as the standard for “best practice” in the provision of information technology services.

As IT services become more closely aligned and integrated with the business, ITIL assists in:

• Establishing a business management approach and discipline to IT Service Management

• Stressing the complementary aspects of running IT like a business.

What Exactly Is ITIL?


ITIL Version 2.0• Consisted of 7 sets of services, however, main focus was generally

divided into two main areas:o ITIL Service Deliveryo ITIL Service Support

Service Delivery• Management of the IT services themselves

• Involves a number of management practices to ensure that IT services are provided as agreed between the Service Provider and the Customer.

• Includes 5 disciplines: Service Level Management, Capacity Management, Continuity Management, Availability Management, and IT Financial Management



Service Support• The practice of those disciplines that enable IT Services to be

provided effectively. The 7 Service Support disciplines implemented at Solar Turbines are:

o Service/HelpDesko Incident Managemento Change Managemento Problem Managemento Configuration Managemento Release Managemento Knowledge Management




The ITIL FrameworkThe

Business

The Technology

Planning To Implement Service Management

Applications Management

Service Delivery

Service Support

SecurityManagement

Th

e Bu

siness

Pe

rspe

ctive

Th

e Infrastr u

cture

M

an

age

me

nt


ITSM (®) - IT Service Management• Series of documents used to aid the

implementation of a framework for IT Service Management (ITSM).

• This framework defines how Service Management is applied within specific organizations.

• Being a framework, it is completely customizable for applications within any type of business or organization that has a reliance on IT infrastructure




IT Service Management is concerned with:

Delivering and supporting IT services that are appropriate to the business requirements / objectives of the organization

IT service providers must continually strive to improve the quality of their service, while at the same time trying to reduce the costs or, at a minimum, maintain costs at the current level


• Purpose: The purpose of the Incident Management Process is to ensure ALL Incidents are consistently logged, tracked and resolved across the Solar IT environment.

• Goal: To restore normal service operation as quickly as possible and minimize the impact on business operations.

Incident Management Process


An “incident” is defined as:

“Any event that is not part of the standard operation of service and causes, or may cause, an interruption to or reduction in

the quality of that service.”

Incident Definition


What types of Incidents are in Scope?

ALL OF THEM!

All Incidents must have a ticket logged and follow the Incident Management

Process

Incidents / Scope?


Who is responsible for the Incident Management Process?

Everyone In ITS Is Responsible!

We are all responsible for:– Understanding– Following– Monitoring– Identifying– Reporting non-compliance

Responsibility


What is the Process Owner responsible for?

– Creating, documenting, and training on the Incident Management Process to all of Solar ITS teams. This is why we are here!

– Monitoring compliance and reporting results– Ensuring process compliance across IT

environment– Current process owner is:

• Helpdesk Supervisor - Carl Farmer

Process Owner Responsibility


What is the IT Manager (ITM) responsible for?

Ensuring:– All resources are educated on the process– Monitoring compliance– Correcting compliance– Reporting non-compliance issues– Responsible for process compliance

across their team(s)

IT Manager Responsibility


What is the Queue Manager responsible for?

Ensuring all members of his/her queue:– Are educated on the Incident Process– Monitoring compliance– Correcting compliance issues– Reporting non-compliance for all tickets that

are closed while assigned to their queue.

Queue Manager Responsibility


What is the IT Analyst responsible for?

Ensuring:

– A ticket is logged every time an incident is reported.

– Ensuring all required fields in the ticket are correctly populated at all times (Service Type, Classification, Priority, Description, Resolution)

– Contact the client directly in order to collect additional incident details as necessary.

– Regularly update tickets assigned to you with all pertinent Incident details and status changes

– When resolved, contacting the client to validate that they agree and are back up and running

IT Analyst Responsibility


What is the Helpdesk Analyst responsible for?

– Understanding and complying with the Incident Management Process.

HelpDesk Analyst Responsibility


• The Service Type designates the general category or process area the ticket belongs to. Currently we are using 2 types:– Incident - any event that is not part of the standard

operation of service and causes an interruption / reduction of that service

– Service Request - a request for new or additional service.

• It is critical that the correct type is selected, as Service Requests do not fall under the same process requirements as Incidents

Service Type


• When ServiceCenter is used to track Service Requests, the Incident Management process should be followed.

• In these instances, it is important to remember to populate ‘Service Type’ in the Incident ticket as a “Service Request”, and to follow the basic Incident process steps.

Service Type


• Classification includes Category, Subcategory, Service/Product, and Issue Type

• Guidelines for classification• Tickets should be classified according to the Root Cause

of the Incident • The Helpdesk always makes a best effort to classify the

Incident correctly according to the information available when they log the ticket.

• As additional information becomes available, all ticket Assignees should update classification to reflect the most accurate, current assessment of the Incident root cause.

• The Assignee who resolves the Incident is accountable for ensuring the ticket is classified correctly

Classification


• Newer analysts don’t know enough about the incident or related application

• High call volume requires the Helpdesk to handle calls as quickly as possible

• No information on what is required in the GetAnswers Knowledge database.

Classification


• Priorities are automatically generated by Service Center based on the following 4 criteria:

Business Importance Service Impact

Related to Response & Recovery times Reflects the # of people impacted by Incident

Not Selectable - Hard coded to Service/Product based by BIL as determined by IT Managers.

1-1010-100100+ or VIP

Customer Impact Customer Urgency

Related to the Customer(s) ability to work How critical the customer perceives the incident to beComplaint = Customer work can continue, but issue is a nuisance or annoyingCompromise = Customer work can continue, but is degraded and requires extra effort (eg manual workaround)Down = Customer process cannot continue, work effectively stopped

Low = Work is not critical, extended timeframeNormal = Work is important but not critical, standard timeframeEmergency = Customer believes work to be critical, should be completed ASAP

Priority


• The Helpdesk always makes a best effort to prioritize correctly, but..

– It is the responsibility of the Assignee to update priority as appropriate to accurately assess the priority.

– Remember:

• When you “Accept” a ticket you also accept:

o Accuracy Of Priority AND Categorization

o Ticket Body Content / Contextual Clarity

Priority


• Standard Process for Statuses

• There are several non-mandatory Status options – use as appropriate to notate current state of ticket

• Pending Customer/Vendor/Other• Promote to Test, Test, Tested, Scheduled

• NOTE: Some statuses are not available until a prior status has been recorded. For example, no status is available for selection until ‘Work In Progress’ has been selected and saved.

AssignedAutomatically setwhen AssignmentGroup is selected

AcceptSignifies acceptanceof responsibility for

Incident byAssignment Group

ClosedAutomatically set

when ticket closed

Work in ProgressSignifies initiation oftrouble-shooting to

resolve Incident

ResolvedSignifies Assignee

believes Incident to beResolved

Statuses


• The incident details should include as much information as possible:

• Complete description of the Incident

• All research and trouble-shooting efforts

• All escalation efforts and activity

• All client interaction and feedback

• Anyone looking at the ticket must be able to understand what is being done to fix the problem without having to contact the analyst for more details.

Incident Description


The resolution must:– Detail what steps were taken to resolve the

incident.

– Not say “Done” / “OK” / “Resolved” / etc

– Include client validation that the resolution fixed their problem

– Be documented in the Solution Field• Field is grayed out until you click the “Close” button

Incident Resolution


Closing Tickets


• The ONLY legitimate cause for rejecting a ticket is:– When the ticket was assigned to the wrong queue

(Assignment Group). It should NOT be rejected for any other reason.

• If additional information is required, the responsible IT Analyst should call the client directly, keeping in mind the purpose of Incident Management which is to get the client up and running as soon as possible.

Rejected Tickets


• Rejected tickets do not go back to previous assignment group – they are sent back to the Help Desk

Rejected Tickets


Rejected Tickets


• At times duplicate tickets may be logged for the same incident.

• There are two correct methods for handling duplicate tickets:– The determining factor is whether the

Contact(s) for the each of the duplicate tickets are the same or different

• Identical Contact• Different Contact(s)

Duplicate Tickets


• Contacts are identical:– The first ticket logged becomes the “Parent” ticket. All

duplicates (“Child” tickets) should be linked to the parent ticket.

– An update must be made in each duplicate (“Child”) ticket referencing the parent ticket number, and stating that information related to the incident can be found in the parent ticket.

– After calling the Contact to explain that duplicate tickets exist, and giving the Contact the parent ticket number, the child ticket(s) can be closed.

– The resolution field of the Child ticket(s) should state that this ticket is an exact duplicate of the parent ticket, and resolution information can be found there.

Duplicate Tickets (Identical)


Duplicate Tickets


• Contacts are different:– Each ticket should remain open until the incident is

resolved. – The first ticket logged becomes the “Parent” ticket, and

all activity related to the incident should be tracked in this ticket. All duplicates (“Child” tickets) should be linked to the parent ticket.

– An update must be made in each duplicate (“Child”) ticket referencing the parent ticket number, and stating that information related to the incident can be found in the parent ticket.

– The child ticket(s) must remain open and assigned to the same queue as the parent ticket until the parent ticket is closed.

Duplicate Tickets (Different)


Duplicate Tickets


• Reopen Ticket:– An Incident ticket should be reopened when the

incident in question was NEVER resolved..

• New Ticket:– A NEW ticket should be created if the original

incident was resolved and subsequently reoccurred, no matter how short the timeframe between the resolution and the new incident.

Re-Opening Tickets


• Helpdesk: – Can reopen all tickets. The IT and/or

HelpDesk Analyst must determine whether or not the issue was ever resolved and decide whether to reopen the ticket.

• Helpdesk has the authority to either refuse or insist a ticket be reopened.

Who Can Re-Open Tickets ?


Re-Assigning Tickets

Goal: Get The Client Up And Working ASAP!!!Get The Client Up And Working ASAP!!!

Per Incident Management:

If you determine assistance from another IT group is required to resolve an issue:

– Reassign ticket to the appropriate Assignment Group. – Clearly detail the reason for the reassignment in the ticket. – When possible, give the other group a courtesy call.– Do NOT reject the ticket as that will prolong the support process.

When an Assignment Group receives a reassigned ticket, they should follow the Incident Management process


Goal: Get The Client Up And Working ASAP!!!Get The Client Up And Working ASAP!!!

Per Incident Management:

If your group receives a reassigned ticket:– Follow the Incident Management process in its entirety. – If your group feels the ticket was incorrectly reassigned, call and speak

to the person who assigned the ticket to you. Do not simply reassign the ticket back to the original Assignment Group.

– In instances where two teams cannot agree on who should work the ticket, contact your management, the Helpdesk Leads or Supervisor, or the Incident Manager.

Again, remember the goal of Incident Management is fast resolution for the client. ‘Bouncing’ tickets between queues greatly slows down resolution.

Re-Assigning Tickets


(IT Analysts)

• If an IT Analyst is the first to ‘discover’ an incident, and the incident will be resolved by you or a member of your Assignment Group, you may opt to log your own ticket.

• If you or your team will not resolve the ticket, you must call or email the Helpdesk to open a ticket for you.

Self-Logging Tickets


(IT Analysts)

• IT Analysts should not:– Log tickets for Assignment Groups

to which they do NOT belong.

Self-Logging Tickets


Solar Currently has 10 SLA DefinitionsOn-Site (Office) Hours are 6:00 AM - 6:00 PM

On-Call (After Office) Hours are 6:00 PM - 6:00 AM

SLA Time To ‘Accepted’ Status Time To ‘Resolve’

On Site (Office hours):• Solar Priority One – On Site 1 Hour 4 Hours• Solar Priority Two – On Site 1 Hour 12 Hours• Solar Priority Three – On Site 12 Hours 5 Days• Solar Priority Four – On Site 3 Days 10 Days• Solar Priority Five – On Site 3 Days 20 Days

On Call (After Office hours):• Solar Priority One – On Call 4 Hours 8 Hours• Solar Priority Two – On Call 4 Hours 12 Hours• Solar Priority Three – On Call 2 Days 5 Days• Solar Priority Four – On Call 3 Days 10 Days• Solar Priority Five – On Call 3 Days 20 Days

Priority Alerts Chart


• Alert: Is a notification that a ticket is getting closer to the expected Service Level Agreement (SLA).

• There are 4 pre-set ‘alert stages’ for Incidents: – Alert Stage 1 : Within 60% of time to get from Assigned->Accepted status

– Alert Stage 2 : Within 90% of time to get from Assigned->Accepted status

– Alert Stage 3 : Within 99.9% of time to get from Assigned->Accepted status

– DEADLINE -100% of guaranteed resolve time (Resolved status)

• The time allowed to go from Assigned Accepted status, and to Resolved status, is determined by the SLA assigned to the Incident.

• The SLA assigned is determined by the Priority Code of the Incident and the time of day the Incident is opened:

Alerts


SLA/Alert escalations are suspended during the following statuses:

• Pending Customer, Pending Other, Pending Vendor

• Once an Incident is in an ‘Accepted’ status – all future ‘alert stages’ are cancelled/removed. The DEADLINE ALERT is only cancelled once an Incident is placed in ‘Resolved’ status.

• The Deadline Alert is always scheduled for an interval after the open time of the ticket, and is not affected by updates to the ticket.

• The SLA definition in use can be viewed on the SLA tab while viewing an Incident. The future ‘alert stages’ can be viewed on the Alerts tab.

Priority Alerts Chart


Alerts – SLA Tab


Alerts –Tab


• Deadline Alert:– Total Amount of time allocated to resolve a ticket and meet

the Service Level Agreement (SLA).

• Deadline alert clock starts running from the time the ticket is open until it has been put into resolved status.

• Once the deadline alert has been stopped by resolving the ticket, it cannot be reactivated even if ticket status is changed to another status.– (e.g. Resolved WIPResolved.) – Service Level Agreements (SLAS):

Deadline Alert


• Remember, it is your responsibility to understand and comply with the Incident Process.

• If you have any questions:• Contact your Lead/Supervisor/Manager, or

the Incident Process Owner

• Service Desk Admin – x7520

Questions?


• Solar’s Knowledge Base• Knowledge Manager and Technical Writer• Document standards adopted by CAT.

Get Answers


– GA is result of 2003 ServiceDesk KM Project– KM Project started 2004– Goals of KM were to:

• Increase 1st call resolution• Decrease cost per incident• Increase customer satisfaction• Reduce training time• Improve HDA job satisfaction

Get Answers


• Implemented Get Answers (GA)• Production: June 2005• Solar IT Teams using GA:

– Helpdesk– Lotus Notes– Information Security– Deskside– Finance/Legal/HR– Distributed Systems

Get Answers


This shows Helpdesk performance across ALL tickets received, showing TOTALS, resolutions (blue) and escalations (yellow). Mostly this shows the growth of all incoming contacts to the Helpdesk – We’ve gone from 5000 tickets a month to over 10,000 a month since 2004

Get Answers


Where we can show solid improvement is in PHONES – this is where the Helpdesk has the opportunity to close calls on “1st contact”. As the chart shows, volume has increased, but resolutions have increased also, while the Escalations has stayed flat. We are closing more calls per agent with KM.

Get Answers


Priority 1 and 2 tickets are escalated to Operations per Solar’s Escalation Policy:

(All IT Analysts should familiarize themselves with the Escalation Policy.)

– Operations (not Helpdesk) contacts Support Analyst. If primary and secondary support analysts not available, SLM or ITM shall determine who responds to ticket.

– Support Analyst is responsible for updating the ticket including proper categorization and prioritization.

– Support Analyst responsible for contacting Operations (who conferences in Helpdesk) and providing updates (including but not limited to progress and resolution) on a regular basis.

Escalation – P1/P2 Issues


Primary reason for Helpdesk Cloud Message?

Reduce Call Volume To Helpdesk!Reduce Call Volume To Helpdesk! (Contrary to what some believe, it is not posted in order to make anyone look bad!!!)

– Decision to post Cloud Message based on current and/or anticipated call volume and determined by Helpdesk staff.

– Decision can be subjective.– Not all P1/P2 issues will result in a Cloud Message. Also, there may be P3/P4

issues that could require a post.– Cloud Message removed ONLY when Helpdesk is made aware that issue has

been resolved. Notification by Support Analyst (as required by Escalation Policy) via Operations helps.

• NOTE - Do not rely on telepathy to convey notice !

Escalation – Cloud Messages


Peregrine Service Center Assignment Groups

ServiceCenter Queues


ServiceCenter Queues

Peregrine Service Center Assignment Groups


Change Management Process

Change Management Presentation


Problem Management Process

Problem Management


Completion Topics

THANK YOU !!

Course Content Evaluation• Course Name : Solar ITSM

• Classroom : Computer Rooms 1 & 2

• Solar Location : Harbor Drive

Course Assessment• A Score Of At Least 80% Is Needed For A Passing Grade

downloaded here

Business

service management itsm

service level management

infrastructure management

capacity management

availability management

continuity management

financial management

itil itsm