00 Service desk Processes regarding the service desk activities (according to ITIL). Documented processes: 00_00_overview_service_desk 00_01_new_ticket 00_02_phone_call_visit 00_03_document_resolved_issue 00_04_solve_request 00_05_solve_event 00_06_incident_management 00_07_problem_management 00_08_change_management 00_09_issue_escalation
Overview service desk // (requestor) contact the isginf service desk by phone, ticket or other means. [Create ticket] A ticket is created if ne exists yet. Submit {0} Ticketing system receives ticket Requestor gets confirmation Dispatch {1} Dispatch ticket Requestor gets tification mail with ticket owner. Owner changes when necessary. request Update ticket and inform requestor Requestor receives mail and answers if necessary. d? Close request Requestor gets tification mail that request is closed. Close {0} [00_00_overview_service_desk.vsd, v1.1, 14/6/2010, luca]
New ticket Submit ticket Submit ticket Submit ticket // (requestor) submit a new ticket by mail or form. Submit {0} Ticketing system receives ticket Requestor gets confirmation ticket Check title, message text, customer info. Filter irrelevant tickets Move SPAM, irrelevant messages, etc. to <Trash> queue. Go to ticket properties Check/Set <Group> <Group>: Group of the requestor (usually automatically assigned). Check/Set <Service> <Service>: The service the ticket is related to. Check/Set <Category> <Category>: 1 Request: General service request. 2 - Event: Event/Information. 3 - Change: Change request. 4 - Incident: Unexpected service interruption. 5 - Problem: Resolution of root-cause of an event or incident. Set <Owner> [and <Responsible>] <Owner>: Owner of the ticket (working on ticket). <Responsible>: Responsible for ticket (defaults to first owner). Dispatch {1} <Submit> changes Requestor gets tification ticket [00_01_new_ticket.vsd, v1.2, 14/6/2010, luca]
Phone call or visit // (requestor) call or visit the service desk. Open new phoneticket Submit {0} Set <Subject> and <Text> Consult with requestor and set a meaningful short description. Set <From> <From>: Customer (uname or mail address). Set <To> <To>: Queue of the ticket owner. Set <Group> <Group>: Group of the requestor (usually automatically assigned). Set <Service> <Service>: The service the ticket is related to. Set <Category> <Category>: 1 Request: General service request. 2 - Event: Event/Information. 3 - Change: Change request. 4 - Incident: Unexpected service interruption. 5 - Problem: Resolution of root-cause of an event or incident. Account time Dispatch {1} <Create> ticket Requestor gets tification ticket [00_02_phone_call_visit.vsd, v1.1, 14/6/2010, luca]
Document resolved issue Open new phoneticket This process describes how to document work which has been already done without a previous existing ticket. Set <From> <From>: Requestor (uname or mail address). Set <To> <To>: Who resolved the issue. Set <Subject> and <Text> Set a meaningful short description of the work done. Set <Group> <Group>: Group for which the issue was resolved. Set <Service> <Service>: The service the resolved issue is related to. Set <Category> <Category>: 1 Request: General service request. 2 - Event: Event/Information. 3 - Change: Change request. 4 - Incident: Unexpected service interruption. 5 - Problem: Resolution of root-cause of an event or incident. Account time Inform customer? Decide if the requestor should be informed of the resolved issue (including ticket number). <Create> ticket Requestor gets tification Close ticket Requestor gets tification Set <Next ticket state>to <closed> <Create> ticket Document [00_03_document_resolved_issue.vsd, v1.1, 14/6/2010, luca]
request Owner changes when necessary. request Open new reply Set <Next ticket state> <Next ticket state>: open: ticket is open closed: ticket is closed (solved) waiting for user: wait for answer from user waiting for other: wait for other/external pending close: automatically close on specific date pending reminder: remind owner on specific date stalled: ticket on hold Account time <Submit> mail Requestor receives mail and answers if necessary. d? Update status Escalate? Escalate request Escalate Close request Requestor gets tification that request is closed. Close {0} [00_04_solve_request.vsd, v1.1, 14/6/2010, luca]
event event Significance? Exception Informational: event does t require action and does t represent an exception. Warning/ Informational Warning: a service or device is approaching a threshold. Exception: a service or a device is operating abrmally. Correlate Correlate event with other events. Need action? Create new ticket with given <Category> <Category>: 3 - Change: Change request. 4 - Incident: Unexpected service interruption. 5 - Problem: Resolution of root-cause of an event or incident. Change/ Incident/ Problem Close event Add a meaningful description as te when closing the ticket. Close [00_05_solve_event.vsd, v1.1, 14/6/2010, luca]
Incident management Incident identification Incident categorization and priorization An incident is an unplanned interruption to an IT service or reduction in the quality of an IT service. Failure of a component (e.g., HD in a RAID) that has t yet impacted a service is also an incident. Communicate/ publish high impact incident Need escalation? High impact incidents are communicated trough the following channels (as needed): - isginf homepage - mails to or affected users Escalate incident Investigation & diagsis Resolution & recovery Incident solved? Communicate/ publish high impact incident resolution Problem resolution needed? Create new problem ticket Document incident resolution Close incident Close [00_06_incident_management.vsd, v1.2, 14/6/2010, luca]
Problem management A problem is an unkwn cause of one or more incidents. Problem identification Problem categorization and priorization Investigation & diagsis Need escalation? Escalate problem Change needed? Change management Problem resolution Problem solved? Document problem resolution Close problem Close [00_07_problem_management.vsd, v1.2, 14/6/2010, luca]
Change management A change is an event that results in a new status of one or more components. change Decide if change will be implemented Document change decision Consider: - Other (relevant) processes -Policies - Motivation - Needed resources - Dependencies -Impact -Risks Review assessment and approval OK? Communicate decision to requestor Approve Will implement? Implement change Implement Document implementation Review impl. Review/test OK? Communicate deployment Deploy Check deployment Deploy Document Close Close change The requestror can reopen a closed ticket if the ticket is t solved in a satisfactory way. [00_08_change_management.vsd, v1.0, 14/6/2010, luca]
Issue escalation Hierarchical escalation? Escalation is required for an issue that an isginf member can t resolve alone. Usually this happens because of technical, kw-how or organizational reasons. Contact other member(s) Functional escalation: The support of a higher level specialist is needed to resolve the problem. Issue Issue resolved? Functional escalation Inform/contact isginf head Discuss ad-hoc escalation/ resolution options and process Hierarchical escalation: A manager with more authority needs to be consulted in order to take decisions that are beyond the competencies assigned to this level, for example, to assign more resources in order to resolve a specific incident. Issue Hierarchical escalation [00_09_issue_escalation.vsd, v1.0, 14/6/2010, luca]