Incident management activity descriptions

This table lists the specific activities as referenced in the Incident Management level 1 workflow diagram and provides some level of detail as to how these activities are performed.

Activity Number

Activity

Description

0

Incident Identified

An incident has either been reported by a colleague or detected by the IT organization.

1

Log Incident

Incidents will be fully logged regardless of whether they are raised through a Service Desk telephone call, business personnel ?walk up?, or whether it was automatically detected via an event alert.

2

Categorise

Incident

A suitable incident categorization code is selected and priority is allocated so that the exact type of the call is recorded. This allows Service Desk staff to research the correct known solutions and immediately escalate critical incidents as required.

3

Request or

Incident?

The support analyst should review the nature of the call and select the appropriate ?Record Type?. If it is a Service Request, then the Request management process should be followed. If the query is an incident then the step 4 should be followed.

4.

Prioritise

Incident

A priority will be automatically assigned based on a matrix defined by the selections made when choosing the appropriate ?Urgency? and ?Impact?.

4a.

Parent Incident Exists

If there are multiple incidents of the same nature a Parent Incident is created and communicated

4b.

Link to Parent Incident

Child linked to Parent Incident with the appropriate relationship.

5.

Major Incident?

Does the priority coupled with the other details of the incident qualify as a Major Incident? If they do, then the Major Incident Management process should be followed. If not, then step 6 should be followed.

6

Knowledge Framing

The analyst should seek to capture the question or symptom in the language of the customer (customer?s context), not necessarily every word verbatim but rather the key essence of the question or symptom (Complete thoughts, not complete sentences). The text entered will be used to search the knowledgebase, so the length of text string should be limited to only 2 lines.

7

Knowledge Searching

Searching the Knowledgebase should be the first thing that occurs in the support workflow, to ensure that the support analyst will leverage off the knowledge already gathered by the organisation and reduce the risk of re-solving issues that are in progress or have previously been solved. The act of searching forms the basis for refining and improving knowledgebase search ability and findability.

Keywords and/or additional phrases can be added to the search string to enrich or filter search results.

Unsuccessful search strings should be recorded in the system logs and used to frame new WIP (Work In Progress) Articles.

8

Knowledge Matching

Knowledge articles returned in the search results should be viewed for relevancy. Irrelevant knowledgebase articles should be updated to reduce the likelihood of returning at the top of the search results. Relevant KAs should be updated to improve its knowledge search ranking.

8a

KA Exist?

If a suitable knowledge article displays in the search list, then move to step 9. If there are no suitable KAs then move to step 8b.

8b

Search Policy Exceeded?

There are no hard and fast rules on the number of acceptable searches that

should be performed before creating new knowledge articles. Each company will have their own policy, but a general rule of thumb is no more than 3.

If you are unable to find a suitable KA within this time, then a new WIP article should be created and linked to the incident record and escalated to 2nd/3rd level support. Any duplicate KAs found should be merged together as part of weekly knowledgebase maintenance tasks.

8c

Perform Initial diagnosis & Update Work

If there are no suitable KAs, then the support analyst should perform Initial diagnosis which may involve

  • Validation and Replication of the issue
  • Capture the environment
  • Testing thoughts, concepts and scenarios.
  • Consider workarounds.

Each activity performed should have an equivalent incident work log recorded in the incident record.

8d

Solution Identified?

If no resolution is found move to step 8e. If a resolution is found immediately then move to step 8f.

8e

Create Knowledge (WIP Status)

Before escalation, the incident record should be updated with the appropriate information from steps 2, 4 and 6. A new Work in Progress (WIP) KA should be created from the details of the incident record by selected the ?Create Knowledge? Button. This will copy the incident content into a new KA and then

link it to the incident record before escalation to 2nd or 3rd level support.

All of the required fields should be completed with the exception of ?Cause? and ?Resolution?. This is because we are yet to find a resolution for the incident. The resolution will be entered by the support team who actually resolves the incident.

The KA?s status should be specified as Work In Progress (WIP) before saving. The status will immediately notify other support analysts who encounter the same issue, that the support organisation is aware of the issue, and they should also link the WIP KA and escalate the incident as well.

8f

Create a new DRAFT KA

If a solution is found during step 8c, then the solutions that has been verified by the customer should be recorded into the Resolution fields of the Incident Record.

When all of the Resolution data has been finalised, the support analyst should create a knowledge article from the Incident Record by selecting the ?Create Knowledge? button. This will automatically capture the;

  • Framed Question / System,
  • The Environment details,
  • The cause,
  • The work around or solution
  • The operational classifications, and,
  • The product classifications into a new Knowledge Article.

The knowledge Article status should be set to ?Draft?.

Saving the new KA will automatically link the KA to the Incident Record which should be viewable via the relationships tab in the incident record.

9

Escalation

Required?

Some knowledge articles are procedural based; they may notify 1st level that incidents of this nature need to escalate to 2nd or 3rd level support. If escalation is required, then the KA should be rated (9a) and then escalated in accordance to the escalation procedure.

9a

Knowledge Rating & Update

It is good practice to rate the usefulness of knowledge articles when viewed or used. This ensures the article is still relevant and helpful, and also draws attention to authors who need to improve their authoring skills.

Concurrently if the Support analyst has the appropriate rights and privileges they should make the required updates immediately. If the Support analyst does not have the appropriate rights and privileges they should flag the knowledge article for update, and comment on the desired changes.

9b

Knowledge

If a KA was available and step 9a was completed, the knowledge article should be linked to the incident record. This is achieved by selecting the ?Use? button in the KA. The KA will record into the Relationships tab of the incident.

9c

Assign Incident

to Relevant Group

The incident record is assigned to the appropriate 2nd or 3rd level support group.

10

Knowledge Usage

Relevant Knowledge articles should be viewed, and linked to the incident record by selecting the ?Use? button in the KA.

Subject to the support analyst?s Knowledge role, the Knowledge Articles should have been rated, updated or flagged for update where appropriate (see step 9a).

11.

Solution Successful?

Has the incident record been resolved? Customer validation is required to qualify resolution.

11a

Rate KA & flag any modification requirement

The solution specified in the KCS article was not successful. The KA should be rated by the Support analysts and modified if appropriate. It?s also worth flagging the KA for an update, because you will need to escalate the incident to 2nd or 3rd level support.

12

Review & Update Linked Knowledge Article

The solution specified in the KCS article was successful. KCS defines reuse as review. If the knowledge article is used, then it should be validated as relevant. If the knowledge article is out of date, unclear, or hard to read, then it should be updated immediately, or flagged for review.

13

Use KA for resolution and resolve the incident.

Clicking on the KA?s ?Use? button will automatically copy the Resolution categories into the incident?s resolution tab. It will also copy the ?Customer Friendly Resolution? into the incident?s ?solution? field.

This table lists the specific activities as referenced in the Incident Management workflow levels 2 and 3 diagram and provides some level of detail as to how these activities are performed.

Activity Number

Activity

Description

1

Assess assigned incident

This is a pre-defined process that will take into account details of the incident record to determine the necessary party to escalate to. At this stage Operational Level Agreements should be triggered to ensure a fair response time so that resolution time is met.

2

Correctly assigned?

The escalation group should analyse the content of the Incident record and determine if the record was correctly assigned.

Incorrect assignment would require judgement on behalf of the support analyst and adherence to the incident management policy which states that the owner of the incident is the current assignment group.

All actions should be made with the customer?s experience in mind. If the escalation group knows who should receive the incident they should assign it to them immediately. If they do not know the correct assignment group, they should assign it back the previous group.

In both situations there should be an assignment reason called ?Incorrect Assignment? applied on escalation. This will help identify process improvement.

2a

Update Case, attach KA & assign to appropriate group

Each of the support groups involved with the incident handling will

investigate and diagnose what has gone wrong ? and all such activities need to be recorded into the work log of the incident record. This includes details of any actions taken to try and resolve or re-create the Incident

3

KA attached to case?

Each escalated incident should contain a linked KA.

The Incident record will provide a graphical indication that a KA has been attached.

The types of KAs that should be attached are:

  1. A new framed KA
  2. A Draft KA that has been ?Flagged for Update?

A Published KA that has been ?Flagged for Update?.

If there is not a KA attached then this will be recorded as a breach of the KM process, and step 3a should be followed.

3a

Was a KA available?

There are two scenarios where the escalation group should investigate Knowledge linking.

  1. There was no KA for the previous group to use, so there should have been a Framed KA.
  2. There was linked KA but it was not relevant to the incident.

In both cases the escalation group should double check if there actually was a relevant KA available for this group to use.

If there was not, then the escalation group should create a framed WIP article immediately and make it available to the previous group. If there was relevant knowledge they should indicate that Knowledge was not used (See 3b).

3b

Flag that a viable KA was not used

In the case where the relevant knowledge was available but not used by the previous support group, there should be the ability to indicate that knowledge was not used. The question needs to be asked: ?Why was it not used?

The answer could be:

Lack of adherence to the KM policy

The relevant KA was not searchable or findable and will need to be enhanced. For both scenarios ?Knowledge was not used? should be noted within the incident record.

4

Search Knowledge Base for corresponding KA in your group

It is common for 2nd and 3rd level support teams have knowledge articles segmented from other teams. This could be due to additional skills, privileges or tools required to perform diagnostic and resolution activities. On receiving escalated support event records, they should immediately check their own knowledge repository to ensure they leverage off the knowledge already captured by the organisation. They should use , create, update and improve any new knowledge required.

5

KA Exists in your group?

If there is not a relevant KA for the escalation group then step 5a should be followed. If there is a relevant KA the step 5e should be followed.

5a

Frame / Draft a KA

Before additional investigation and diagnosis is performed, the incident details should be copied into a new Work In Progress (WIP) KA by selecting the ?Create Knowledge? Button. This will copy the incident content into a new KA and then link it to the incident and will be made available to the escalation group.

All of the required fields should be completed with the exception of ?Cause? and ?Resolution?. This is because we are yet to find a resolution for the incident. The resolution will be entered by the support team who actually resolves the incident.

The KA?s status should be specified as Work In Progress (WIP) before saving.

The status will immediately notify other support analysts who encounter the same issue, that the support organisation is aware of the issue, and they should also link the WIP KA and escalate the incident as well.

5b

Investigate incident

Investigate and diagnose what has gone wrong ? and all such activities need to be recorded. This includes details of any actions taken to try and resolve or re-create the Incident

5c

Solution found?

Is there a relevant Draft or Published KA available? If yes, the follow step 5d. If no, then follow step 5e

5d

Solution successful?

If there is a relevant KA, was the solution successful?

If yes, follow step f. If no, then follow step 5e

5e

Requires escalation?

Is further investigation required?

5f

Update KA and (if applicable) promote to Draft

If the solution in the KA was successful, then the KA should be promoted to Draft, promoted to Published, Rated, updated, or flagged for update.

5g

Assign visibility / create KA for previous level

KAs should be considered which groups in the support chain should have view rights. There may be a need to create multiple KAs for the one issue but in the context of each support group. Level 1 KAs could mention preparation and escalation procedures, and Level 2/3 KAs could mention resolution and recovery.

5h

?Use? KA to resolve incident

If the KA used by the escalation group was successful, then the KA be applied to the incident record by selecting the ?Use? button. This will auto populate the incident resolution details, and created a link in the incident?s relationship tab.

6

Apply solution as per KA

If the escalation group has a relevant Draft or Published KA (Step 5) they should apply the solution to resolve the incident.

7

Solution successful?

Did the applied solution successfully resolve customer?s solution? If Yes, the follow step 8. If No, then follow step 7a.

7a

Requires escalation?

Is further escalation required?

7b

Refine KA & apply / Investigate incident

If the applied solution did not successfully solve the issue, then the KA should be updated to specify the exception details, and move to step 5b. If further investigation does find a solution, then it should be applied and step 7c followed.

7c

Solution successful?

Did the applied solution successfully resolve customer?s solution? If Yes, the follow step 8. If No, then follow step 7a.

8

Rate KA and (if required) flag for update

If the solution in the KA was successful, then the KA should be promoted to Draft, promoted to Published, Rated, updated, or flagged for update.

9

?Use? KA to resolve incident

If the KA used by the escalation group was successful, then the KA be applied to the incident record by selecting the ?Use? button. This will auto populate the incident resolution details, and created a link in the incident?s relationship tab.

10

Complete/Flag any necessary amendments to KAs

Finalise any last minute updates to the KA or flag for update, and/or add any appropriate comments.

11

Change Required

Is a change request required to resolve the incident? If a change is required to resolve the incident, then follow step 11a. If not then follow step 12.

11a

Follow Change Process

Follow the agreed Change Management process.

12

Resolve Incident

After resolution confirmation from the customer. Follow the Incident Resolution procedures as specified in the incident management policy.


Return to top of page Back to top