Solar IT Service Management Incident

2. 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)

3. 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

4. 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

6. 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

7. The IT Infrastructure Library consists of 5 volumes: Service Strategy Service Design Service Transition Service Operation 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.

8. ITIL Version 2.0 Consisted of 7 sets of services, however, main focus was generally divided into two main areas: ITIL Service Delivery 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

9. 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: Service/HelpDesk Incident Management Change Management Problem Management Configuration Management Release Management Knowledge Management

13. 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

16. 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.

17. 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.� 

18. What types of Incidents are in Scope? ALL OF THEM! All Incidents must have a ticket logged and follow the Incident Management Process

19. 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

20. 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

21. 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)

22. 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.

23. 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

24. What is the Helpdesk Analyst responsible for? Understanding and complying with the Incident Management Process.

25. 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

26. 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.

27. 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

28. 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.

29. Priorities are automatically generated by Service Center based on the following 4 criteria: �

30. 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: Accuracy Of Priority AND Categorization Ticket Body Content / Contextual Clarity

31. 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.

32. 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.

33. 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

35. 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.

36. Rejected tickets do not go back to previous assignment group � they are sent back to the Help Desk

39. 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)

40. 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.

43. 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.

48. 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.

49. 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.

51. Goal: 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.

52. (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.

53. (IT Analysts) IT Analysts should not: Log tickets for Assignment Groups to which they do NOT belong.

54. Solar Currently has 10 SLA Definitions On-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 DaysOn 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

55. 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:�

56. 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.

59. 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 ?WIP?Resolved.) Service Level Agreements (SLAS):

60. 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

61. Solar�s Knowledge Base Knowledge Manager and Technical Writer Document standards adopted by CAT.

62. 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

63. Implemented Get Answers (GA) Production: June 2005 Solar IT Teams using GA: Helpdesk Lotus Notes Information Security Deskside Finance/Legal/HR Distributed Systems

68.

69.