Flow Description - Incident Management

Incident Management
Process Flow Description

Lisa Callihan
8/10/2011

Incident Management Process Flow Description August 2011 2 of 19

PROCESS NAME: Incident Management Process ORIGINAL DOCUMENT DATE: 1/4/2011
PROCESS MANAGER: Lisa Callihan LAST REVISION: 8/10/2011
APPLIES TO: Information and Technology
Services
ATTACHMENT(S): <N/A>

DOCUMENT PURPOSE
The purpose of this document is to describe at a high level the process steps and activities of the Incident Management
Process.

This document aligns directly with the Incident Management Process Flow Diagram.

Related information can be found at:
Incident Management Process Flow Diagram
Incident Management Process Summary
ITS Operating Level Agreement
Significant Incident Process Flow Diagram
Significant Incident Procedures
Incident Management J ob Aids

Table of Contents
DOCUMENT PURPOSE ...........................................................................................................................................2
INCIDENT MANAGEMENT PROCESS OVERVIEW ...........................................................................................4
1100 Incident Registration .........................................................................................................................................4
1200 Research and Assignment ..................................................................................................................................6
1300 Investigation and Diagnosis ...............................................................................................................................9
1400 Resolution ....................................................................................................................................................... 11
1500 Incident Closure .............................................................................................................................................. 13
1600 Service Request .............................................................................................................................................. 15

INCIDENT MANAGEMENT PROCESS OVERVIEW
1100 Incident Registration
1200 Research and Assignment
1300 Investigation and Diagnosis
1400 Resolution
1500 Incident Closure
1600 Service Request

1100 INCIDENT REGISTRATION

1110 Record User and Determine Nature of Incident
Workflow Status: Identification and Recording
Record Status: New
Fields: Customer, Corporate ID, Contact, Quick Action Link, and Customers Incidents
Description: In the Record user and Determine Nature of Incident step, the Incident Initiator enters the user uniqname into the
Customer field, hits enter. The Initiator can then hover over the field to review and validate data for accuracy and the
uniqname populates in the Corporate ID field. The data comes from a People record stored within the application. The
People record is populated with a load from an authoritative source such as HEODS or M-Community. If the Incident
Initiator is unable to find the end user record using search capabilities then the record must be entered as Unknown by
using --- in the Customer field. The Incident Initiator cannot add new people records. Errors in the Customer record, must
be corrected at the authoritative source. If the phone number is different, updates can be made to the phone number by
clicking the double arrows, then edit Phone Number field, but will only be attached to the specific record being worked on
and will not update the overall people record for the end user.

A. New or existing Incident?
At this stage the question is asked, Is this a new Incident or existing Incident? This can be determined by
reviewing the Customers Incidents under the Quick Action link. This link populates after the customer name
information is entered from the uniqname. The Incident Initiator will review Incidents and determine if there is an
open Incident for this issue for the customer. If there is, the process moves to 1160, Update Existing Incident where
the existing record is worked. If there is not an existing record, then the process moves to step 1120, Record
Incident Notes and Summary. NOTE: if the customer information is Unknown then the information returned in
the Customers Incident link will not be valid.
1160 Update Existing Incident
Record Status: New
Fields: Customers Incidents Link
Description: In the Update Existing Incident step, the Incident Initiator highlights the existing Incident and clicks View, the
existing Incident is now in Modify mode and can be updated as appropriate, then Save. The Incident Initiator clicks Close to
close the existing incident, then Close again and Ok to navigate away from incident form without saving.


B. Template available?
At this stage the question is asked, Is a Template available? to use for this Incident. The Incident Initiator clicks
in the Template field and hits enter. The Incident Template Selection box appears. Choose the Support Group,
highlight the Template Name and click View to review or Select to use. Information from the Template is
automatically populated into the Incident fields. Verify information is correct and Save.

1170 Use Template to fill out Incident
Record Status: New
Fields: Template
Description: In the Use Template to fill out Incident step, the Incident Initiator clicks in the Template field and hits Enter, the
Incident Template Selection box is displayed. The Initiator selects from the drop down to view templates for Support
Groups, and highlights the desired Template, then selects View to review or Select to Use, then Close. The contents of the
Template are added into the Incident fields.
1120 Record Incident Notes and Summary
Record Status: New
Fields: Notes and Summary
Description: In the Record Incident Notes and Summary step, the Incident Initiator enters a description of the issue as it is
currently understood. The Summary field is used for a short description and the Notes field is used for a long, more detailed
description of the issue the end user is experiencing. Attachments, such as screenshots of error codes, reports, etc should
be included as a Work Detail entry using the Work Info Type of General Information. Use Initiator Script if available found
under the Initiator Script link, step 1180. Note: The Summary and Notes field are for issue description only and is the
information sent the Assignment Notification to the Support Group when Assigned. Any notes regarding resolution
investigation must be in a Work Info entry with a Work Info Type of Working Log.

1180 Use Initiator Script if available
Record Status: New
Fields: Initiator Script, Notes and Summary
Description: In the Use Initiator Script if available step, the Incident Initiator clicks on the Initiator Script link, the Select
Initiator Script box is displayed. Select from the Viewing Scripts for Support Group drop down menu, highlight the desired
Script and the details are displayed. The Initiator adds the necessary data to the Script box and clicks Select. The Notes and
Summary fields are populated with the data.
1130 Identify Configuration Item and Service
Record Status: New

Fields: Service and CI
Description: In the Identify Configuration Item and Service step, the Incident Initiator selects the service for which the
Incident request has been submitted by filling out (part of) the service's name and subsequently pressing the Enter key or
selecting the Service in the drop down menu. Then select the configuration item (CI) that is causing the service disruption or
that the requester wants to know something about.
1140 Establish Impact, Urgency and Priority
Record Status: New
Fields: Impact, Urgency and Priority
Description: In the Establish Impact, Urgency and Priority step, the Incident Initiator selects a value from the Impact field to
reflect how many people or widespread the issue is. The Urgency value represents how quickly the Incident needs to be
resolved. Together, the Impact and Urgency fields are calculated to determine the Priority value based on weight. The
definitions for Impact and Urgency values can be found in the ITS Operating Level Agreement.
1150 Classify Type, Source, and Save
Record Status: New
Fields: Service Type, Reported Source, Assign to Me, Assignee Group, Assignee and Save
Description: In the Classify Type and Source step, the Incident Initiator uses the Service Type field to identify if the issue is
an Incident (break/fix) by selecting the User Service Restoration value, or by selecting the User Service Request option
to indicate the issue is a Service Request or question. The Infrastructure Restoration value is used when Incidents are
automatically generated from a monitoring event. The Incident Initiator uses the Reported Source field to indicate the
incoming source of the issue. Commonly used values include Email, Phone, Direct Input or Web (SRM). Other values, such
as Voice Mail, External Escalation, Fax, Systems Management, Walk In and Other are rarely used. Use the Assign to Me
Quick link to update Assignee Group and Assignee name field with Incident Initiator data, then clicks Save to save the
Incident record. The Incident automatically assigns a Support Group Owner Group (either ITS Service Desk or IS
Operations, depending on the Incident Type.)

C. What type of request?
There are three different type of issues handled by the Incident Management Process; Service Request, Incident (Service
Restoration) and Events (Infrastructure Event). After the records are initiated and classified, the Incident and Event
records are handled in the same fashion. If the recorded issue is a Service Request, then the process is slightly different.
At this stage of the process the Incident Initiator reviews the record type and moves to the 1600 series in the process for
Service Requests and the 1200 series for Incidents.

1200 RESEARCH AND ASSIGNMENT

1210 Review Broadcast Message
Workflow Status: Investigation and Diagnosis
Record Status: Assigned

Fields: View Broadcast Link, and Relationship Type
Description: In the Review Broadcast message step, the Incident Initiator reviews any open Broadcast messages from the
View Broadcast link to determine if there is a related issue already shared via Broadcast. If there is a related issue then the
Incident Initiator will complete the relationship with the appropriate Relationship Type. Normally, this is Related to, or
Duplicate of. The relationship will be visible on the Relationships tab of the record.
1220 Search Knowledge
Fields: Search Knowledge Base Link
Description: It is important to perform a knowledge search and determine if there are any similar issues currently open,
contained in historical data or documented in the Knowledge Base. The Search Knowledge process is a search process
completed by the Incident Initiator and is done to determine if there are existing Knowledge, Problem, Known Error or
Incident records that are similar in nature. Being able to locate a similar issue has the potential to expedite a resolution, or
add more insight into the overall impact the issue is having. The Incident Initiator clicks the Search Knowledge Base link
under Links. To modify results, the Advanced Search is used.

A. Duplicate Exists?
The results of Reviewing Broadcast, 1210 and Search Knowledge, 1220 A, consist of finding a duplicate Incident record.
In the question Does a Duplicate Exist? the Incident Initiator is reviewing the results of Broadcast Message and the
Search Incident results to determine if a match is found. In this case, the process is specifically referencing matched
Incidents even though the Search Knowledge process brings back match information from Knowledge, Problem, Known
Errors and Incidents. If a match is found the process moves to step 1250. If duplicate Incident is not found the process
moves to Decision B, Solution Available?

1250 Relate duplicate as child and join with parent Incident
Fields: Relationships Tab and Fields
Description: In the Relate duplicate as a child and join with parent Incident step, the Incident Initiator clicks on the Incident
link in the Search results, this will open the record in a Modify Incident window. Review the details, if the new Incident is
the same as the existing Incident displayed, go back to the new Incident, click the Relationships Tab, under Request Type
choose Incident click Search. Type the Incident ID from the Search results into the Incident ID field click Search. In the
Relationship Type box choose, Duplicate of, Relate, Ok then Close. The Relationship will be displayed on the
Relationships tab and the Child Incident will be Resolved when the Parent Incident is updated.

B. Solution Available?
The results of Reviewing Broadcast (1210) and Knowledge Search (1220) include finding similar Incidents, Problems,
Known Error or Knowledge documents that may provide a viable workaround. If, after reviewing the records it is felt
that viable workaround is available, the Incident Initiator moves to step 1260, Use Knowledge or Relate to a Problem or
Known Error. If no workaround is identified, then the process moves to Decision C, Broadcast Required?


1260 Use Knowledge or Relate to Problem or Known Error
Description: In the Use Knowledge or Relate to Problem or Known Error, the Incident Initiator has found a Knowledge
Article, (KBA) Problem Investigation, (PBI) or Known Error, (PKE) that relates to the Incident. If a KBA, the Incident
Initiator clicks on the KBA link, reviews the article and if appropriate, clicks Use. The Relationships Tab is updated with the
Knowledge Base information with a Relationship Type of Resolved by. If a PBI or PKE, the Incident Initiator closes the
Search Knowledge window, clicks on the Relationships Tab, clicks the Request Type drop down menu, chooses Known
Error or Problem Investigation and clicks Search. In the window, add the Known Error or Problem ID number and click
Search. In the Relationship Type drop down menu, select Resolved by and click Relate, then Close.

C. Broadcast Required?
In some cases the Incident has a large enough impact to warrant further notification to support staff. In the question, Is
a Broadcast Required? the Incident Initiator reviews the details of the Summary, Notes, Impact, Urgency, Work Detail
and Relationships tab to understand the need to further notification. If needed the process moves to step 1230, Broadcast
Incident. Otherwise, the process moves to step 1240, Assign to Support Group for Investigation and Diagnosis.

1230 Broadcast Incident
Fields: Broadcast Incident Quick Action, Broadcast Incident Fields
Description: In the Broadcast Incident step, the Incident Initiator clicks the Broadcast Incident link under Quick Action then
clicks Create to launch the New/Modify Broadcasts Form. The Incident Initiator completes the following fields: Subject,
Broadcast Message, Broadcast Type, Broadcast Start Date and View Access as the default Internal. Select Yes from the
Notify Field Drop Down and Select Support Group from the Support Group Field Drop Down to receive Broadcast
Notification.
1240 Assign to Support Group for Investigation and Diagnosis
Fields: Assigned Group, Assign to Me, Owner Group, Owner
Description: In the Assign to Support Group for Investigation and Diagnosis step, the Incident Initiator completes the
Assignee Group field by filling out (part of) the Support Group name or selecting the Support Group in the drop down menu,
which allows the record to be worked by Support Staff. It is often the case that the Incident Initiator is the Incident
Assignee, in this case the Assign to Me Quick Action link should be used, but in some cases a different skill set is required
and the assignment is made to a specific support group.

The Incident Owner is the second assignment that is completed as part of the Assign to Support Group for Investigation and
Diagnosis. The Owner Group assignment is automatically assigned by the system, which is always the ITS Service Desk or
IS Operations Support Groups. Specific Support Staff information is added in the Owner field.
After completing the assignments, the Incident Initiator then uses the Save button to save the record. As a result, the record
status will change from New to Assigned or In Progress and a Notification to the Assigned Group is sent.

D. Incident correctly assigned?
A member of the Assigned Support Group will review the Incident details and decide if the Incident is appropriate for
that Support Group. If the answer is Yes, the process moves to 1300 Investigation and Diagnosis. If the answer is No,
the process moves to 1270 Assign to correct Support Group or Incident Owner.

1270 Assign to Correct Support Group or Reassign to Incident Owner
Fields: Assigned Group
Description: In the Reclassify and Assign to Incident Owner step, the Assignee knows the original assignment was either
done in error or knows another group would be more appropriate and needs to be assigned to another group. In order to
accomplish this step, the Assignee creates a Work Info entry describing the issue and if the correct Support Group is known,
updates the Assigned Group with the correct information. If the correct Support Group is not known, the Assigned Group is
moved to the Incident Initiator Support group, either the ITS Service Desk or IS Operations.

1280 Reassign Incident for Investigation and Diagnosis
Fields: Assigned Group
Description: In the Reassign Incident for Investigation and Diagnosis step, the update is completed by the Incident Owner. In
order to accomplish this step the Incident Owner creates a Work Info entry describing the issue and updates the Assigned
Group field to the correct Support Group. As a result, a Notification to the updated Assigned Group is sent.

1300 INVESTIGATION AND DIAGNOSIS

1310 Perform Preliminary Diagnosis
Record Status: In Progress
Fields: Assign to Me, Assignee, Status, Summary, Notes, and Work Detail
Description: In the Perform Preliminary Diagnosis step, the Assignee clicks the Assign to Me link under Quick Actions to
indicate they are working the Incident, then clicks Save. The Workflow Status changes to Investigation and Diagnosis, the

Assignee field is updated with the Assignee name, and the Status is moved to In Progress. The Assignee then reviews the
Incident Summary, Notes and any Work Detail entries.
1320 Search for Knowledge
Description: The Search Knowledge process is done to determine if existing Knowledge, Problem, Known Error or Incident
records that are similar in nature are available to assist with the resolution of the incident. The Assignee clicks the Search
Knowledge Base link under Links. To modify results, the Advanced Search can be used.

A. Solution or Workaround available?
At this stage, the Assignee asks, Is a known Solution or Workaround available? to resolve the Incident. If yes,
the process moves to 1400, Resolution otherwise the process moves to 1330, Gather Facts and Investigate.
1330 Gather Facts and Investigate
Fields: Work Detail, Work Info Type, Source, Summary, Notes, Add Attachments, and View Access.
Description: In the Gather Facts and Investigate step, the Assignee is troubleshooting and researching a solution for the
Incident. Any work completed during this step is documented in Work Detail. The Assignee clicks Create to record a Work
Info entry. Selects the Work Info Type and Source from the Drop Down Menus, includes a Work Info Summary, Notes,
Adds Attachments and chooses View Access as Internal or External, clicks Save. This information will be displayed in the
Work Detail Box.

B. Assistance Needed?
At this stage the Assignee asks, Is additional assistance needed to resolve the Incident? If Yes, the Assignee
works with other support staff to gather facts and investigate to resolve the Incident. If the Incident has a Priority
Value of Critical, the process moves to Decision C, Critical Incident? If specific tasks are necessary, the Assignee
can use Optional steps 1340 and 1350 to assign tasks. If No, the process moves to Decision D, Solution or
Workaround Available?

1340 Generate Tasks
Fields: Tasks
Description: In the Generate Tasks step, the Assignee assigns Tasks to other Support Groups while maintaining assignment
of the Incident. Click Tasks under Links, under Request Type select Ad hoc and click Relate. In the Task box, add Name,
Summary and complete Task Assignment and Dates/Times under the Assignment/Dates tab. Save, then Close.


1350 Close Task Activities
Fields: Tasks
Description: In the Close Tasks step, the Assignee clicks on Tasks and highlights the desired Task and clicks View. Work
task through process and once complete, update Status to Closed.

C. Critical Incident?
At this stage the Assignee asks, Does the Incident Priority Value =Critical? If Yes, the process moves to 1700,
Initiate Significant Incident Process. If No, the process moves to Decision E, Reassignment Possible?

D. Solution or Workaround Available?
At this stage the Assignee asks, Is a Solution or Workaround Available? If Yes, the process moves to 1400,
Resolution, if No, the process moves to Decision E, Reassignment Possible?

E. Reassignment possible?
At this stage the Assignee asks, Is Reassignment of the Incident possible? If the Assignee know the correct
Support Group or Individual to resolve the Incident, the process moves to 1240, Assign Incident for resolution. If
the answer is No, the process moves to 1360, Request Problem Investigation.

1360 Request Problem Investigation
Fields: Create Problem, Relationships Tab
Description: In the Request Problem Investigation step, the Assignee clicks on the Create Problem link under Create Other
Requests (reference Problem documentation for details in creating a Problem Investigation) Save Problem Investigation,
Close. The Problem Investigation is listed under the Relationships Tab.

1400 RESOLUTION

1410 Determine How to Resolve Incident
Record Status: In Progress to Resolution
Fields: Work Detail, Resolution

Description: In the Determine How to Resolve Incident step, the Assignee determines what needs to be done to Resolve the
incident and the process moves to Decision A.

A. Change Required?
At this stage the Assignee asks, Does the Resolution require a Change Request? If Yes, the process moves to
1450 Create Request for Change. If No, the process moves to Decision B, Root Cause Analysis Required?

B. Root Cause Analysis required?

At this stage the Assignee asks, Is Root Cause Analysis of the Incident needed? If Yes, the process moves to
1460, Request Problem Investigation. If No, the process moves to 1420, Resolve Incident

1420 Resolve Incident
Workflow Status: Resolution and Recovery
Record Status: Resolved
Fields: Resolution Categorization Tier 1, Tier 2, Tier 3, Resolution, Status Reason, Service, CI, Work Info Type, Summary,
Notes, View Access
Description: In the Resolve Incident step, the Assignee records the Resolution to the Incident. The Assignee clicks Resolve,
then on the Modify Incident form, the Assignee selects Resolution Categorization Tier 1, Tier 2 and Tier 3 from the drop
down menus, records the Resolution Details in the Resolution Field and selects a Status Reason. The Assignee adds a Work
Info entry with the Work Info Type, Resolution Communications so the end user can reference the solution using SRM and
Save. The Incident moves from the Resolution and Recovery Status to Incident Closure and the Status is changed to
Resolved. A Resolution Notification is sent to the Incident Owner.
Where appropriate, the Assignee communicates the Resolution to the end user in step 1430, otherwise the Incident Owner
communicates the Resolution to the end user in step 1430.

1430 Communicate and Execute Solution or Workaround
Workflow Status: Incident Closure
Fields: Resolution Details, Work Detail
Description: In the Communicate and Execute Solution or Workaround step, the Assignee or Incident Owner communicates
the solution or workaround to the end user, this communication can be done verbally or electronically.

C. User Immediately Available?
At this stage the Assignee or Incident Owners asks, Is the User Immediately Available? to confirm the Resolution
works. If Yes, the process moves to Decision D, if NO, the process moves to 1500 Incident Closure.

D. Resolution Confirmed?

At this stage the Assignee or Incident Owners asks the end user if the Solution or Workaround resolves the Incident.
If Yes, the process moves to 1500, Incident Closure. If No, the process moves to 1240, Assign Incident for
Resolution. The Workflow Status returns to Investigation and Diagnosis and the Record Status returns to Assigned.

1450 Create Request for Change
Fields: Create Change, Relationships Tab
Description: In the Create Request for Change step, the Assignee clicks on the Create Change link under Create Other
Requests (reference Change documentation for details in creating a Change Request) Save Change Request, Close. The
Change Request is listed under the Relationships Tab.
1460 Create Problem Investigation
Fields: Create Problem, Relationships Tab
Description: In the Request Problem Investigation step, the Assignee clicks on the Create Problem link under Create Other
Requests (reference Problem documentation for details in creating a Problem Investigation) Save Problem Investigation,
Close. The Problem Investigation is listed under the Relationships Tab.
1470 Create Knowledge Management document if missing
Fields: Create Knowledge
Description: In the Create Knowledge Management document if missing step, the Assignee or Incident Owner add the
Incident resolution to the Knowledge Base. The Assignee or Incident Owner clicks Create Knowledge under Links and
completes the Create Knowledge form (reference Knowledge Management documentation for details in creating a
Knowledge record.)

1500 INCIDENT CLOSURE

1510 Validate and Update Work Detail

Fields: Work Detail
Description: In the Validate Work Info step, the Incident Owner verifies the Work Info is correct under Work Detail. If Yes,
the process moves to 1530, Validate Categorization. If No, the Incident Owner updates the Work Detail.

1520 Validate and Update Categorization
Fields: Categorizations, Resolution Categorization Tier 1, Tier 2, Tier 3, Resolution Product Categorization
Description: In the Validate Categorization step, the Incident Owner verifies the Resolution Categorization is correct using
the Categorizations Link under Links. If No, the Incident Owner updates the Categorization fields. If Yes, the process
moves to Decision A, Broadcast exists?

A. Broadcast Exists?
At this stage the Incident Owner asks, Does a Broadcast Message exist? for this Incident. If Yes, the process
moves to 1530, Update Broadcast Message. If No, the process moves to Decision B, Did User confirm
Resolution?

1530 Update Broadcast Message
Fields: View Broadcasts
Description: In the Update Broadcast Message step, the Incident Owner highlights the Broadcast Message and clicks View.
On the View Broadcast Form, the Incident Owner clicks Modify, updates the Broadcast Message and Broadcast End Date,
then Save, Close.

B. Did User confirm Resolution?
At this stage the Incident Owner asks, Did User confirm Resolution? If the User confirmed the resolution was
satisfactory and no further work is needed for the Incident, the process moves to 1550, Close Incident. If the user
has not confirmed the resolution was satisfactory, the process moves to 1540, Resolved Incident, Auto Close in 8
days.

1540 Resolved Incident, Auto Close in 8 Days
Fields: Status

Description: In the Resolved Incident, Auto Close in 8 Days step, the Incident Owner leaves the Incident in Resolved Status.
Using this status gives the User time to contact the ITS Service Desk to report the Incident Resolution was not satisfactory.
If the User does not respond, the Incident will automatically close in 8 days.

1550 Close Incident
Record Status: Closed
Fields: Status
Description: In the Close Incident step, the Incident Owner can either click the Status field drop down menu and choose
Closed or click the drop down menu from Incident Closure and choose Close, then Save to Close the Incident record. Once
updated to Closed Status, no additional changes can be made to the Incident record.

1600 SERVICE REQUEST

A. Request for Information or Enhancement?
At this stage, the Incident Owner determines if the User Service Request is a request for information or an
Enhancement Request. If the User Service Request is a request for information, the process moves to 1610, Search
Knowledge. If the User Service Request is an Enhancement Request, the process moves to 1640, Assign to Support
Group for Answer.

1610 Search Knowledge
Fields: Search Knowledge Base link
Description: It is important to perform a knowledge search and determine if there are any similar issues currently open,
contained in historical data or documented in the Knowledge Base. The Search Knowledge process is a search process
completed by the Incident Initiator and is done to determine if there are existing Knowledge, Problem, Known Error or
Incident records that are similar in nature. Being able to locate a similar issue has the potential to expedite a resolution, or
add more insight into the overall impact the issue is having. The Incident Initiator clicks the Search Knowledge Base link
under Links. To modify results, the Advanced Search can be used.

1620 Research Information
Fields: Work Detail
Description: In the Research Information, the Incident Initiator is researching an answer for the user question. Any work
completed during this step is documented in Work Detail. The Assignee clicks Create to record a Work Info entry. Selects

the Work Info Type and Source from the Drop Down Menus, includes a Work Info Summary, Notes, Adds Attachments and
chooses View Access as Internal or External, clicks Save. This information will be displayed in the Work Detail Box.

B. Answer Available?
At this stage the Incident Owner determines if an Answer is available for the Requested information. If Yes, the
process moves to 1400, Resolution. If No, the process moves to 1630, Assign to Support Group for Answer

1630 Assign to Support Group for Answer
Fields: Assigned Group, Owner Group, Owner
Description: In the Assign to Support Group for Answer step, the Incident Initiator completes the Assignee Group field by
filling out (part of) the Support Group name or selecting the Support Group in the drop down menu, which allows the record
to be worked by support staff.
The Incident Owner is the second assignment that is completed as part of the Assign to Support Group for Answer step. The
Owner Group assignment is automatically assigned by the system, which is always the ITS Service Desk or ITS Operations
Support Groups. Specific Support Staff information is added in the Owner field.
After completing the assignments, the Incident Initiator then uses the Save button to save the record. As a result, a
Notification to the Assigned Group is sent.

1640 Review and Evaluate
Fields: Assign to Me, Incident Notes, Summary, and Work Detail
Description: In the Review and Evaluate step, the Assignee assigns the Service Request to themselves using the Assign to
Me button, and moves the Service Request to In Progress. The Assignee reviews and evaluates the enhancement request
details in the Incident Notes, Summary and Work Details recommended by the User.

C. Valid for Change Request?
At this stage the Assignee asks, Is the user request valid for a Change Request? If the Enhancement Request is a
valid request, the process moves to 1650, Create Request for Change. If the Enhancement Request is not valid and
will not be considered further, the process moves to 1660 Update Work Detail.

1650 Create Request for Change
Fields: Create Change Link

Description: In the Create Request for Change step, the Assignee clicks on the Create Change link under Create Other
Requests (reference Change documentation for details in creating a Change Request) Save Change Request, Close. The
Change Request is listed under the Relationships Tab, the process moves through Change Management (see Change
Management documentation) to 1670, Update Work Detail.,

1660 Update Work Detail
Record Status: In Progess
Fields: Work Detail
Description: In the Update Work Detail step, the Incident Owner or Assignee adds information to the Work Detail. Click
Create to record a Work Info entry. Select the Work Info Type and Source from the Drop Down Menus, include a Work Info
Summary, Notes, Add Attachments and choose View Access as Internal or External, click Save. This information will be
displayed in the Work Detail Box, the process then moves to 1400, Resolution.

1700 SIGNIFICANT INCIDENT (REFER TO RUNNING A SIGNIFICANT INCIDENT STEP BY STEP GUIDE)
1700 Initiate Significant Incident Process, contact ITS Service Center or IS Data Center Operations
Fields: Work Info
Description: The Incident Assignee contacts the Service Center (or Operations after hours) to initiate the process as soon as
it is suspected that a significant incident is occurring.
1710 Notify Incident Manager
Fields: Work Info
Description: The Incident Manager (or backup SPOCs ) is contacted based on the Callback Listing.
1720 Begin Significant Incident Tracking
Fields: Work Info, Broadcast

Description: Establish the authoritative or parent incident record for tracking purposes and Broadcast. Remind staff working
the issue that all findings and effort must be recorded in the incident record to ensure shared status and knowledge.

1730 Coordinate Initial Stand Up Meeting
Fields: Work Info

Description: Coordinate an initial stand-up meeting. This meeting should be conducted within the first 30 minutes of when
the significant incident was identified.

1740 Build Working Team
Fields: Work Info
Description: Team should include a list of technical and product support personnel as identified by the incident assignee.
The Incident Manager will expand the list to ensure all technical areas are represented as well as related process managers
and ITS Leadership.
1750 Assist Resolution Efforts as Directed
Fields: Work Info
Description: Cross ITS Support Groups will assist with resolution efforts as needed.
1760 ITS Leadership Communication
Fields: Work Info

Description: Send email notification to ITS AVP Lead Team (its.extended.lead.team@umich.edu) regarding the issue, see
template and examples.

1770 Ongoing Meeting and Communication Coordination
Fields: Work Info
Description: The purpose of ongoing stand-up meetings is to ensure appropriate progress is being made and troubleshooting
options are discussed.

1780 Ongoing Significant Incident Recording
Fields: Work Info

Description: Ensure all ITSM incidents are related appropriately.

1790 Work Incident
Fields: Work Info

Description: Ensure ITSM parent incident accurately reflects Significant Incident efforts.

Moves to 1400 Resolution
1800 Significant Incident Review and Closure

Flow Description - Incident Management

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Flow Description - Incident Management

Uploaded by

Copyright:

Available Formats

Incident Management

Process Flow Description

You might also like