Differenze tra le versioni di "Known Error Management"

Da itm wiki.
(Management information)
(Etichetta: visualeditor)
m (Services)
(Etichetta: visualeditor)
 
(23 versioni intermedie di 2 utenti non mostrate)
Riga 58: Riga 58:
 
* Finally he/she closes the ''[[Glossary|known error]]'' if this is not automatically done (by the closure of the related ''[[Glossary|problem]]'')
 
* Finally he/she closes the ''[[Glossary|known error]]'' if this is not automatically done (by the closure of the related ''[[Glossary|problem]]'')
  
|| Any requester may become KE owner. Usually, the ''[[Glossary|group manager]]'' assigns it.  
+
|| Any requester may become KE owner. Usually, the ''[[Glossary|group manager]]'' assigns him/her.  
 
   
 
   
 
|-
 
|-
Riga 68: Riga 68:
 
| User  
 
| User  
 
|| Searches for a published ''[[Glossary|known error]]'' and uses the associated ''[[Glossary|workaround]]''.
 
|| Searches for a published ''[[Glossary|known error]]'' and uses the associated ''[[Glossary|workaround]]''.
||Any ''[[Glossary|user]]'' may play this role.
+
||All ''[[Glossary|users]]'' may play this role.
 
    
 
    
 
|}
 
|}
Riga 186: Riga 186:
  
 
{| class="wikitable"
 
{| class="wikitable"
! ''[[Glossary|Service requests]]'' domain areas !! ''[[Glossary|Service]]'' !! ''[[Glossary|Service manager]]''
+
! [[Glossary|Known Error]] domain areas !! ''[[Glossary|Service]]'' !! ''[[Glossary|Service manager]]''
  
 
|-
 
|-
Riga 234: Riga 234:
  
 
|-
 
|-
| <u>''General Information''</u> || <u>Project/Service</u> || To show the ''[[Glossary|service]]'' (or [[Glossary|''project'']]) to which the ''[[Glossary|known error]]'' is related. ||This is automatically set at open time and can't be modified.
+
| <u>''General Information''</u> || <u>Project/Service</u> || To show the ''[[Glossary|service]]'' (or [[Glossary|''project'']]) to which the ''[[Glossary|known error]]'' is related. ||This is automatically set at open time.
  
 
|-
 
|-
Riga 252: Riga 252:
  
 
|-
 
|-
| <u>''Ownership and Groups''</u> || <u>Owner</u> || To define the KE owner. ||The request owner is automatically set to the ''[[Glossary|resource]]'' who takes in charge the ''[[Glossary|service request]]''. He/she can be changed by the service desk members to another member of the service desk.
+
| <u>''Ownership and Groups''</u> || <u>Owner</u> || To define the KE owner. ||The KE owner is usually set by the KE authority.
  
 
|-
 
|-
Riga 272: Riga 272:
 
|-
 
|-
 
| <u>''Ticket Details''</u>
 
| <u>''Ticket Details''</u>
|| Published <u>Workaround</u> || To provide a description of the applicable ''[[Glossary|workaround]]'' aimed to be used by the ''[[Glossary|users]]''. ||An auto tracking field is used enabling to view the ''[[Glossary|user]] ''who has updated. This field is made visible to all the ''[[Glossary|users]]''.
+
|| <u>Published Workaround</u> || To provide a description of the applicable ''[[Glossary|workaround]]'' aimed to be used by the ''[[Glossary|users]]''. ||An auto tracking field is used enabling to view the ''[[Glossary|user]] ''who has updated. This field is mandatory to transition to the "Known Error Requested" status. This field is made visible to all the ''[[Glossary|users]]''.
 
|}
 
|}
  
Riga 281: Riga 281:
  
 
{| class="wikitable"
 
{| class="wikitable"
! View !! Content !! Requester !! Service desk !! Technical team
+
! View !! Content !! Requester !! KE owner !! KE authority !! ''[[Glossary|User]]''
  
 
|-
 
|-
| Requests resolved || ''[[Glossary|Service requests]]'' in status "Resolved".  || X ||  ||  
+
| Known Errors Opened || ''[[Glossary|Known errors]]'' in status "Known Error Opened".  || X ||  X
 +
||  ||
  
 
|-
 
|-
| Requests opened || ''[[Glossary|Service requests]]'' in status "Opened".  ||  ||  X
+
| Known Errors Requested || ''[[Glossary|Known errors]] ''in status "Known Error Requested".  ||  ||   
 +
|| X
 
||
 
||
  
 
|-
 
|-
| Requests owned || ''[[Glossary|Service requests]] ''in status "Opened", "In Charge" and "Resolved" where <u>Owner</u> is the logged ''[[Glossary|resource]].'' ||  ||  X
+
| Known Errors Rejected || ''[[Glossary|Known errors]] ''in status "Known Error Rejected".  ||  ||  X
||
+
|| ||
  
 
|-
 
|-
| Requests routed to my team || ''[[Glossary|Service requests]]'' in status "In Charge" where <u>Solution Group</u> is the ''[[Glossary|solution group]]'' to which the logged ''[[Glossary|resource]]'' belongs to.    ||  || X
+
| Known Errors Unpublished || ''[[Glossary|Known errors]] ''in status "Known Error Unpublished".    ||  || X
|| X
+
|| ||
  
 
|-
 
|-
| Reuests assigned to me || ''[[Glossary|Service requests]]'' in status "In Charge" where the <u>Ticket Worker</u> is the logged ''[[Glossary|resource]]''.    ||  || X
+
| Known Errors Published || ''[[Glossary|Known errors]] ''in status "Known Error Published".    ||  ||  
|| X
+
||  ||X
  
 
|}
 
|}
  
Additionally, the following ''[[Glossary|views]]'' are made available in the '''''Service Request''''' menu for all the organizational roles:
+
Additionally, the following ''[[Glossary|views]]'' are made available in the '''''Known Error''''' menu for all the organizational roles:
  
 
{| class="wikitable"
 
{| class="wikitable"
Riga 310: Riga 312:
  
 
|-
 
|-
| Requests active || ''[[Glossary|Service requests]]'' in status "Opened", "In Charge", "Resolved"
+
| Known errors active || ''[[Glossary|Known errors]]'' in all the statuses but "Cancelled" and "Known Error Closed".
  
 
|-
 
|-
| Requests suspended || ''[[Glossary|Service requests]]'' in status "Suspended
+
| Known errors published || ''[[Glossary|Known errors]]'' in status "Known Error Published"
  
 
|-
 
|-
| Requests closed || ''[[Glossary|Service requests]]'' in status "Closed"
+
| Known errors closed || ''[[Glossary|Known errors]]'' in status "Known Error Closed"
  
 
|-
 
|-
| Requests cancelled || ''[[Glossary|Service requests]]'' in status "Cancelled"
+
| Known errors cancelled || ''[[Glossary|Known errors]]'' in status "Known Error Cancelled"
  
 
|}
 
|}
Riga 329: Riga 331:
  
 
|-
 
|-
|A ''[[Glossary|service request]] ''is opened || ''[[Glossary|Solution group ]]''members'' ''of "Service Desk" || Alert that there is a ''[[Glossary|service request]]'' to manage.
+
|A ''[[Glossary|known error]] ''is opened || KE authority || Alert that there is a new k''[[Glossary|nown error]]'' to manage and a KE owner to set.
 
 
|-
 
|A ''[[Glossary|service request]] ''is taken in charge || The ''[[Glossary|service request]]'' creator || Alert that someone has started to work on the ''[[Glossary|service request]]''.
 
 
 
|-
 
|A ''[[Glossary|service request]] ''is resolved || The ''[[Glossary|service requestt]] ''creator || Alert that the ''[[Glossary|service request]] ''is resolved.
 
 
 
|-
 
|A ''[[Glossary|solution group]]'' is assigned or changed for the ''[[Glossary|service request]]'' || ''[[Glossary|Solution group manager]]'' || Alert that there is a resource to allocate to manage the ''[[Glossary|service request]]''.
 
  
 
|-
 
|-
|A ''[[Glossary|ticket worker]]'' is assigned || The assigned'' [[Glossary|ticket worker]]'' || Alert that there is work to be done.
+
|A ''[[Glossary|known error]] ''is ready to be published (in status "Known Error Requested") || KE authority || Alert that there is a request to publish a ''[[Glossary|known error]]''.
  
 
|-
 
|-
|A ''[[Glossary|service requestt]] ''is suspended || The ''[[Glossary|service request]] ''creator || Alert that the ''[[Glossary|service request]] ''is suspended.
+
|A ''[[Glossary|known error]] ''publication request is successful || KE owner, requester || Alert that the ''[[Glossary|known error]] ''is published.
  
 
|-
 
|-
|A ''[[Glossary|service request]] ''is closed || ''[[Glossary|Solution group]] ''members of "Service Desk" || Alert that the ''[[Glossary|service request]]'' has been closed.
+
|A ''[[Glossary|known error]] ''publication request is rejected || KE owner, requester || Alert that the publication request was rejected.
  
 
|-
 
|-
|A ''[[Glossary|service request]] ''is cancelled || The ''[[Glossary|service request]] ''creator || Alert that the ''[[Glossary|service request]]'' has been cancelled.
+
|A ''[[Glossary|known error]]'' is cancelled || Requester || Alert that the ''[[Glossary|known error ]]''was cancelled.
  
 
|}
 
|}
  
 
== Reporting ==
 
== Reporting ==
A set of standard reports are made available for the ''[[Glossary|request fulfilment]]'' process. It is not required to have the [[Glossary|REP]] ''[[Glossary|module]]'' to use them, however the [[Glossary|''module'']] is required if new or changed reports are needed. The available reports are placed under '''''Service Request/Reporting''''' menu.
+
A set of standard reports are made available for the ''[[Glossary|knowledge management]]'' process. It is not required to have the [[Glossary|REP]] ''[[Glossary|module]]'' to use them, however the [[Glossary|''module'']] is required if new or changed reports are needed. The available reports are placed under '''''Service Request/Reporting''''' menu.
  
 
The following table lists the reports available by default and their visibility:
 
The following table lists the reports available by default and their visibility:
Riga 363: Riga 356:
  
 
|-
 
|-
|Servicve Requests per priority - trend || An histogram showing the ''[[Glossary|service request]]'' volumes per priority monthly trend. || Service desk and technical team members.
+
|Known errors per service - volume || A pie containing the split of ''[[Glossary|knonw errors]]'' per service. || Service desk, KE authority.
 
 
|-
 
|Service Requests per priority - volume || A pie containing the split of ''[[Glossary|service requests]]'' per priority. || Service desk and technical team members.
 
 
 
|-
 
|Service Requests per service - trend || An histogram showing the ''[[Glossary|service request]] ''volumes per ''[[Glossary|service]]'' monthly trend. || Service desk and technical team members.
 
 
 
|-
 
|Service Requests per service - volume || A pie containing the split of ''[[Glossary|service requests]] ''per ''[[Glossary|service]]''. || Service desk and technical team members.
 
  
 
|-
 
|-
|Service Requests per service/priority - volume || An histogram showing the ''[[Glossary|service requests]]'' volume per ''[[Glossary|service]]'' and priority. || Service desk and technical team members.
+
|Known errors per service - trend || An histogram showing the ''[[Glossary|known errors]] ''volumes per ''[[Glossary|service]]'' monthly trend. || Service desk, KE authority.
  
 
|-
 
|-
|Service Requests - in charge time || A pie showing the percentage of ''[[Glossary|service requests]] ''respecting the target defined for the take "In charge time"* ''[[Glossary|objective]]'' (the time elapsed from the "Opened" to the "In Charge" ''[[Glossary|workflow status]]''. || Service desk and technical team members.
+
|Known errors per service/status - volume || An histogram showing the ''[[Glossary|known errors]]'' volume per ''[[Glossary|service]]'' and status. || Service desk and technical team members.
 
 
|-
 
|Service Requests per priority - resolution time || An histogram showing, per priority, the percentage of ''[[Glossary|service requests]]'' respecting the target defined for the "Resolution time"* ''[[Glossary|objective]]'' (the time elapsed from the "In Charge" to the "Resolved" ''[[Glossary|workflow status]]''. || Service desk and technical team members.
 
  
 
|}
 
|}
<nowiki>*</nowiki> "In charge time" and "Resolution time" [[Glossary|objectives]] are defined within the ''[[Glossary|OCE]]'' ''[[Glossary|module]]''.
 
  
A basic form of reporting is also provided by ''[[Glossary|views]]. ''Views basically allow to list ''[[Glossary|service requests]]'' and their attributes but may also be configured to calculates sums, averages on some of them.'' ''The available ''[[Glossary|views]]'' are illustrated in the dedicated [[Incident Management#Views|section]] of this page.
+
A basic form of reporting is also provided by ''[[Glossary|views]]. [[Glossary|Views]]'' basically allow to list ''[[Glossary|known errors]]'' and their attributes but may also be configured to calculates sums, averages on some of them.'' ''The available ''[[Glossary|views]]'' are illustrated in the dedicated [[Incident Management#Views|section]] of this page.
  
 
== Examples of use ==
 
== Examples of use ==
In this section some examples of use of the configured'' [[Glossary|request fulfilment]]'' process are given.
+
In this section some examples of use of the configured'' [[Glossary|known error management]]'' process are given.
  
If you get lost, any time use the '''EXPLORE WORKFLOW''' command of the ''[[Glossary|service request]]'' management form. This enables to view the status of the ''[[Glossary|workflow]]'' as shown in the figure below. By clicking on a relationship between ''[[Glossary|workflow statuses]]'', ''[[Glossary|roles]]'' and ''[[Glossary|users]]'' enabled to perform it are presented.
+
If you get lost, any time use the '''EXPLORE WORKFLOW''' command of the ''[[Glossary|known errort]]'' management form. This enables to view the status of the ''[[Glossary|workflow]]'' as shown in the figure below. By clicking on a relationship between ''[[Glossary|workflow statuses]]'', ''[[Glossary|roles]]'' and ''[[Glossary|users]]'' enabled to perform it are presented.
 
[[File:Explore Workflow IM v1.0.JPG|centre|thumb|848x848px|Explore Workflow window]]
 
[[File:Explore Workflow IM v1.0.JPG|centre|thumb|848x848px|Explore Workflow window]]
 
'''<u>NOTE</u>''': the '''EXPLORE WORKFLOW '''command is available only if the ''[[Glossary|ticket]]'' is first saved.
 
'''<u>NOTE</u>''': the '''EXPLORE WORKFLOW '''command is available only if the ''[[Glossary|ticket]]'' is first saved.
Riga 397: Riga 377:
 
For more information on how to use any workflows, including incident management, please refer to the [[workflow execution guide]].
 
For more information on how to use any workflows, including incident management, please refer to the [[workflow execution guide]].
  
=== Create a new ''[[Glossary|service request]] ''as a final user ===
+
=== Create a new ''[[Glossary|known error]] ''as a service desk member ===
# Login as "finaluser" ''[[Glossary|user]]''
+
# Login as "SDSSpecialist" ''[[Glossary|user]]''
 
# Activate the '''''Self Service''''' menu
 
# Activate the '''''Self Service''''' menu
# Choose a ''[[Glossary|self service topic]]'', ''[[Glossary|self service category]]'' and finally "Service Request" as ''self service request ''(this determines the creation of a new ''[[Glossary|service request]]'')
+
# Choose a ''[[Glossary|self service topic]]'', ''[[Glossary|self service category]]'' and finally "Known Error" as ''self service request ''(this determines the creation of a new ''[[Glossary|known error]]'')
#Fill the ''[[Glossary|service request]]'' form, at least with mandatory form and save with the '''SAVE''' command
+
#Fill the ''[[Glossary|known error]]'' form, at least with mandatory fields and save with the '''SAVE''' command
You have now saved the ''[[Glossary|service request]]'', take note of the ''[[Glossary|ticket]]'' number for further reference or use.
+
You have now saved the ''[[Glossary|known error]]'', take note of the ''[[Glossary|ticket]]'' number for further reference or use.
  
=== Take in charge a ''[[Glossary|service request]]'' as service desk member ===
+
=== Assign ''[[Glossary|known error]]'' owner ===
#Login as "sdspecialist" (therefore a service desk member)
+
#Based on the service where you have created ''[[Glossary|known error]]'', login as ''[[Glossary|group]]''[[Glossary| ''manager'']] of the team in charge of it (see previous [[#services|services]] section), for example login as "AppManager" if you chose the service "itmCLOUD"
# Open the the desired ''[[Glossary|service request]]''; you can do it quickly either by
+
# Assign the KE owner by filling the <u>Owner</u> field (choose "AppSpecialist") and the team to which the ''[[Glossary|known error]]'' is assigned by filling the <u>Solution Group</u> (choose "Application Management")
#* Access the ''[[Glossary|views]]'' in the ''<u>Tickets</u>'' window of the home page and pick a ''[[Glossary|service request]]'' among those listed in ''[[Glossary|workflow status]]'' "Opened"
+
# Save with the '''SAVE '''command
#* Access the '''''Service Request/Requests active '''''menu and pick a ''[[Glossary|service request]] ''in'' [[Glossary|workflow status]] ''"Opened"'' ''among those listed
+
The ''[[Glossary|known error]]'' is now assigned an owner.
#* Insert the reference number of a ''[[Glossary|sedrvice request]]'' in ''[[Glossary|workflow status]]'' "Opened" in '''Quick Search''', after selecting the ''[[Glossary|search context]]'' "Ticket"
 
# Take in charge the ''[[Glossary|service request]]'' by
 
#* Pressing the '''SAVE & NEXT''' command
 
#* Choose the "1. Take In Charge" ''[[Glossary|workflow transition]] ''
 
#* Fill the ''[[Glossary|service request]]'' form and save with the '''SAVE''' command
 
The incident is now in ''[[Glossary|workflow status]]'' "In Charge".
 
  
=== Resolve a [[Glossary|service request]] as service desk member ===
+
=== Define a ''[[Glossary|workaround]]'' and ask for publication ===
# Login as "sdspecialist" (therefore a service desk member)
+
# Login as KE owner ("AppSpecialist" if you followed the steps before)
# Open the the desired ''[[Glossary|service request]]''; you can do it quickly either by
+
# Open the the desired ''[[Glossary|known error]]''; you can do it quickly either by
#* Access the ''[[Glossary|views]] ''in the ''<u>Tickets</u> ''window of the home page and pick a ''[[Glossary|service request]] ''among those listed in ''[[Glossary|workflow status]] ''"In Charge"
+
#* Access the ''[[Glossary|views]] ''in the ''<u>Tickets</u> ''window of the home page and choose the "Known Errors Opened" ''view''
#* Access the '''''Service Request/Requests active '''''menu and pick a ''[[Glossary|service requestt]] ''in ''[[Glossary|workflow status]] ''"In Charge" among those listed  
+
#* Access the '''''Known Error/Known Errors active '''''menu and pick among those listed
#* Insert the reference number of a ''[[Glossary|service request]] ''in ''[[Glossary|workflow status]]''"In Charge" in '''Quick Search''', after selecting the ''[[Glossary|search context]] ''"Ticket"
+
#* Insert the reference number in '''Quick Search''', after selecting the ''[[Glossary|search context]] ''"Ticket"
# Update ''[[Glossary|service request]] ''information (at least fill mandatory fields for resolution, <u>Analysis</u> and <u>Solution</u>)
+
# Update the ''[[Glossary|known error]]'' and fill the workaround and <u>Published Workaround</u> field
# Set the incident in "Resolved" ''[[Glossary|workflow status]]''
+
# Set the ''[[Glossary|known error]]'' to "Known Error Requested" status by
#* Press the '''SAVE & NEXT '''command
+
#* Pressing the '''SAVE & NEXT '''command
#* Choose the "1. Resolve" ''[[Glossary|workflow transition]]'' and press the '''APPLY & SAVE''' command
+
#* Choose the "Request Known Error Publication" ''[[Glossary|workflow transition]]''
The incident is now in ''[[Glossary|workflow status]]''"Resolved".
+
#* Fill the ''[[Glossary|known error]] ''form, if needed (because of missing mandatory fields), and save with the '''SAVE '''command
 
+
The ''[[Glossary|known error]]'' is now in ''[[Glossary|workflow status]] ''"Known Error Requested".
=== Route a ''[[Glossary|service request]]'' to a technical team ===
 
# Login as "sdspecialist" (therefore as a service desk member)
 
# Open the the desired ''[[Glossary|service request]]''; you can do it quickly either by
 
#* Access the ''[[Glossary|views]] ''in the ''Tickets ''window of the home page and pick a ''[[Glossary|service request]] ''among those listed in ''[[Glossary|workflow status]]''"In Charge"
 
#*  Access the '''''Service Request/Requests active '''''menu and pick a ''[[Glossary|service request]] ''among those listed in ''[[Glossary|workflow status]] ''"In Charge"
 
#* Insert the reference number of a ''[[Glossary|service request]] ''in ''[[Glossary|workflow status]] ''"In Charge" in '''Quick Search''', after selecting the ''[[Glossary|search context]] ''"Ticket"
 
# Update <u>Solution Group</u>'' ''field with the technical team you want to assign
 
# Save with the '''SAVE''' command
 
At step 3, you might also want to set a specific member among those of the select technical team by defining the <u>Ticket Worker</u>.
 
  
=== Take in charge a ''[[Glossary|service request]]'' as a technical team member ===
+
=== Publish a [[Glossary|known error]] ===
# Login as a technical team member (for available logins, refer to the [[Incident Management|Role]] section of this page)
+
# Login as a member of the KE authority (for example "AppManager")
# Open the the desired ''[[Glossary|service request]]''; you can do it quickly either by
+
# Open the the desired ''[[Glossary|known error]]''; you can do it quickly either by
#* Access the ''[[Glossary|views]] ''in the ''Tickets ''window of the home page and pick a ''[[Glossary|service request]] ''among those listed in ''[[Glossary|workflow status]] ''"In Charge"
+
#* Access the ''[[Glossary|views]] ''in the''Tickets ''window of the home page and choose the "Known Errors Requested"''view''
#* Access the '''''Service Request/Requests active '''''menu and pick an ''[[Glossary|incident]] ''among those listed in ''[[Glossary|workflow status]] ''"In Charge"
+
#* Access the '''''Known Error/Known Errors active '''''menu and pick among those listed
#* Insert the reference number of a ''[[Glossary|service request]] ''in ''[[Glossary|workflow status]] ''"In charge" in '''Quick Search''', after selecting the ''[[Glossary|search context]] ''"Ticket"
+
#* Insert the reference number in '''Quick Search''', after selecting the ''[[Glossary|search context]] ''"Ticket"
# Press '''SET ME AS TICKET WORKER''' command
+
# Set the ''[[Glossary|known error]] ''to "Known Error Published" status by
#  Press '''SAVE''' command
+
#* Pressing the '''SAVE & NEXT'''command
 +
#* Choose the "Publish Known Error" ''[[Glossary|workflow transition]]''
 +
#* Fill the ''[[Glossary|known error]] ''form, if needed (because of missing mandatory fields), and save with the '''SAVE'''command
 +
The ''[[Glossary|known error]] ''is now in ''[[Glossary|workflow status]] ''"Known Error Published".
  
=== Close a ''[[Glossary|service request]]'' as a final user ===
+
=== Search a ''[[Glossary|known error]]'' as ''[[Glossary|user]]'' ===
 
# Login as "finaluser"
 
# Login as "finaluser"
# Open the the desired ''[[Glossary|service request]]''; you can do it quickly either by
+
# Search a ''[[Glossary|known error]]''; you can do it quickly either by
#* Access the "Requests resolved" ''[[Glossary|view]] ''in the ''Tickets ''window of the home page and pick a ''[[Glossary|service request]] ''among those listed
+
#* Insert a search text in '''Quick Search''', after selecting the ''[[Glossary|search context]]'' "Known Errors"
#* Insert the reference number of a ''[[Glossary|service request]] ''in ''[[Glossary|workflow status]]''"Resolved" in '''Quick Search''', after selecting the ''[[Glossary|search context]] ''"Ticket"
+
#*  Access the ''[[Glossary|views]] ''in the ''Tickets ''window of the home page, choose "Known Errors Published" and browse/filter
# Close the ''[[Glossary|service request]] ''by
+
#*  Access the '''''Known Error/Known Errors published '''''menu and browse/filter
 +
=== Close a ''[[Glossary|known error]]'' ===
 +
# Login as KE owner ("AppSpecialist" if you followed the steps before)
 +
# Open the the desired ''[[Glossary|known error]]''; you can do it quickly either by
 +
#* Access the ''[[Glossary|views]] ''in the ''<u>Tickets</u> ''window of the home page and choose the "Known Errors Opened" ''view''
 +
#* Access the '''''Known Error/Known Errors active '''''menu and pick among those listed
 +
#* Insert the reference number in '''Quick Search''', after selecting the ''[[Glossary|search context]] ''"Ticket"
 +
# Set the ''[[Glossary|known error]]'' to "Known Error Closed" status by
 
#* Pressing the '''SAVE & NEXT '''command
 
#* Pressing the '''SAVE & NEXT '''command
#* Choose the "1. Close" ''[[Glossary|workflow transition]]''
+
#* Choose the "Close Known Error" ''[[Glossary|workflow transition]]''
The incident is now in ''[[Glossary|workflow status]] ''"Closed".
+
#* Fill the ''[[Glossary|known error]] ''form, if needed (because of missing mandatory fields), and save with the '''SAVE '''command
 +
The ''[[Glossary|known error]]'' is now in ''[[Glossary|workflow status]] ''"Known Error Closed".

Versione attuale delle 14:03, 9 mag 2016

The known error management process is supported by a SM workflow cartridge that enables the execution of the process.

Of course the preconfigured process (the workflow cartridge) is just an accelerator and the tuning / completion of the initial configuration will still be required. To this aim, the Workflow Engine guide may be useful.

IMPORTANT NOTE: the configuration below is only one of the possible configuration to deal with the known error management process. The need for a different behaviour of the process may be fulfilled by simple changes of the configuration.

Operational model

The preconfigured process has the objective to facilitate and support the management of known errors which provides a workaround to solve one or more incidents. At the core of the process configuration is the following operational model.

Known Error Management operational model

The technical teams member generate the known error proposals which are examined by the KE authority who decides if thy are valuable solutions to be published to the users. The criteria usually to be met to accept and publish a known error are usually the following:

  • it is the best suitable applicable workaround;
  • it is well written, according to the standard format and easy to understand;
  • all side effects are identified and described.

However, each organization may define its own criteria.

Roles

For this process, the following organizational roles are defined:

Organizational role Description itmSUITE® role mapping
Requester There are several technical teams predefined for different domains. The following table shows which users are members of each team and, therefore, requesters.
Domain Group Member

users

Application management "Application Management" "AppManager"

"AppSpecialist"

Personal devices management "Personal Management" "PersonalManager"

"PersonalSpecialist"

Network management "Network Management" "NetManager"

"NetSpecialist"

Server management "Server Management" "ServerManager"

"ServerSpecialist"

Additionally, the members of the group "Service Desk" and, specifically, the user "SDSpecialist" and the service managers is enabled to this role.

KE owner
  • The KE owner follows the life cycle of the known error
  • He/she completes or prepares the workaround if not done by the requester
  • He/she verifies that the known error fulfils the acceptance criteria and submits it to the KE authority for approval
  • He/she complete corrects it according to the KE authority suggestions
  • Finally he/she closes the known error if this is not automatically done (by the closure of the related problem)
Any requester may become KE owner. Usually, the group manager assigns him/her.
KE authority The group managers of the following groups, "Application Management", "Personal Management", "Network Management", "Server Management" are made part of "KE authority" group.
User Searches for a published known error and uses the associated workaround. All users may play this role.

Process

As for all workflows, new knonw errors can be created by using the self service portal, accessible by means of Self Service menu.

The following requests which trigger a new instance of the known error management process are configured and available to all organizational roles in the self service portal:

Self service topic Self service category Self service request Authorized roles
"Applications" "itmCLOUD" "Known Error" (open a known error) Requesters.
"Personal Devices" "Personal Computers" "Known Error" (open aknown error) Requesters.
"Personal Devices" "Peripherals" "Known Error" (open aknown error) Requesters.
"Personal Devices" "Telephony" "Known Error" (open aknown error) Requesters.
"Network" "Networking Management" "Known Error" (open aknown error) Requesters.
"Technical Services" "Server Management" "Known Error" (open aknown error) Requesters.

A workflow is configured to support the known error management process. The workflow is characterized by workflow statuses and workflow transitions. The figure below illustrates the process.

Known errors management process.

The table below explains the meaning of each workflow status.

Workflow status Description
"Default" A preliminary status which is displayed when a known error is created.
"Known Error Opened" The known error has been recorded and activities to deal with it started (e.g. defining a workaround).
"Known Error Requested" The known error is ready for KE authority to approve its publication.
"Cancelled" The known error has been cancelled. No more activities are possible.
"Known Error Published" The known error has been published and may be searched by users. This is the only status where it is searchable.
"Known Error Rejected" The KE authority has rejected the publication of the known error.
"Known Error Unpublished" The known error is no longer published and can't be searched by users.
"Known Error Closed" The known error is closed.

And finally the table below explains the roles authorized to execute the workflow transitions.

Source status Destination status Authorized executors Comment
"Default" "Known Error Opened" Requesters See the self service portal configuration previously described.
"Known Error Opened" "Known Error Requested" KE owner The requester shall notify the KE owner.
"Known Error Opened" "Cancelled" Requesters or KE owner Problem management may cause this transition too (see related processes).
"Known Error Requested" "Cancelled" KE owner
"Known Error Requested" "Known Error Published" KE authority
"Known Error Requested" "Known Error Rejected" KE authority
"Known Error Rejected" "Known Error Requested" KE owner
"Known Error Published" "Known Error Unpublished" KE owner or problem management
"Known Error Unpublished" "Known Error Closed" KE owner Problem management may cause this transition too (see related processes).

Related processes

Several other IT Service Management processes are related to the known error management one. Some basic interfaces are provided. The tab Related Items of the request and, in particular, the sub tab Tickets of it allows to view all the existing between the known error and other processes (managed through tickets).

Incident management

It is possible to create a new known error starting from an incident. The GENERATE KE command in the incident allows to instantiate a known error by copying some incident information and by creating a relationship between the known error and the generated incident.

Problem management

It is possible to create a new known error starting from a problem. The GENERATE KEcommand in the problem allows to instantiate a known error by copying some problem information and by creating a relationship between the known error and the generated problem. However, the closure of the problem also determines some automatic transitions of the known error:

  • if initial status is "Cancelled" no transition will be performed;
  • if initial status is "Known Error Opened" the final status will be "Cancelled";
  • for all other initial statuses, the final transition shall be "Known Error Closed".

Asset management and configuration management

It is possible to relate configuration items to a known error by using the tab Related Items and, in particular, the sub tab Configuration Items. The ASM and/or CMS modules features are made available here (e.g. view of configuration item details, configuration exploration or impact analysis).

Services

Different services are configured for different service requests domain areas as illustrated in the following table.

Known Error domain areas Service Service manager
Application management Only one application, and the related service ("itmCLOUD") is configured. The user "servicemanager" is configured as service manager.
Personal devices management "Personal Device Management". The user "personalmanager" is configured as service manager.
Network management "Network Management" The user "netmanager" is configured as service manager.
Server management "Server Management" The user "servermanager" is configured as service manager.

Management information

Many management information are available as fields in the service request management configured form. The following table illustrates the intended use of key information and its behaviour. NOTE: information are available (visible) and can be modified according to a specific configuration which is meant to be suitable for the organizational roles involved in the process.

Information group or tab Field Purpose Comments
General Information Ticket Op Status To show the operational status of the known error, see workflow statuses in Process section of this page. Status changes are performed by means of the Save&Next command.
General Information Request Name To show the SRCS request invoked.
General Information Short Description To provide a short description of the known error. Always visible, it can be managed according to workflow status and organizational roles. This field is made visible to all the users.
General Information Requester To identify the name of the requester (who has requested the known error). A list is presented, influenced by.... TBC
General Information Creation Date To show the date and time the known error was created. This information is automatically recorded and cannot be manually changed. See History tab for more detailed tracking information.
General Information Edit Date To show the date and time the known error was last updated. This information is automatically recorded and cannot be manually changed. See History tab for more detailed tracking information.
General Information Creation User To show the user who created the service request. This information is automatically recorded and cannot be manually changed. See History tab for more detailed tracking information.
General Information Edit User To show the user who updated the known error last. This information is automatically recorded and cannot be manually changed. See History tab for more detailed tracking information.
General Information Project/Service To show the service (or project) to which the known error is related. This is automatically set at open time.
General Information Ticket Type To show the type of workflow executed. This is automatically set at open time and can't be modified. This field is made visible to all the users.
General Information Root Cause A flag, showing if the known error contains the root cause. This is automatically set if the Root Cause field is filled.
General Information Workaround A flag, showing if the known error contains a workaround. This is automatically set if the Workaround field is filled.
Ownership and Groups Master SG To define the supervising and first line support team. The "Service Desk" is automatically set as master solution group at open time and cannot be changed.
Ownership and Groups Solution Group To define the team to which the known error is assigned for analysis and/or fulfilment. The four predefined groups ("Application Management", "Personal Management", "Network Management" and "Server Management") are set to be visible. The group is defined by the KE owner and may change during the known error life cycle.
Ownership and Groups Owner To define the KE owner. The KE owner is usually set by the KE authority.
Ownership and Groups Ticket Worker To set the resource who shall work in order to analyse and/or find a workaround. The Ticket Worker may not be set. He/she is generally a member of the team defined in the Solution Group field. Alternatively, it is possible to assign specific tasks to resources by using the Ticket Activities tab.
Ticket Details Description To provide a more detailed description of the known error. An auto tracking field is used enabling to view the user who has updated.
Ticket Details Symptoms To provide a description of the symptoms of the actual or potential incident(s) or problem(s) related to the known error. An auto tracking field is used enabling to view the user who has updated. If generated from an incident or a problem, their description is automatically copied here.
Ticket Details Root Cause To provide a description of the root cause of the actual or potential incident(s) or problem(s) of the known error. An auto tracking field is used enabling to view the user who has updated.
Ticket Details Workaround To provide a description of the applicable workaround for the known error. An auto tracking field is used enabling to view the user who has updated.
Ticket Details Published Workaround To provide a description of the applicable workaround aimed to be used by the users. An auto tracking field is used enabling to view the user who has updated. This field is mandatory to transition to the "Known Error Requested" status. This field is made visible to all the users.

Fields can be mandatory to save the known errors in some workflow statuses. These fields are highlighted with a red asterisk in the management form.

Views

The following views are made available in the Tickets area of the home page:

View Content Requester KE owner KE authority User
Known Errors Opened Known errors in status "Known Error Opened". X X
Known Errors Requested Known errors in status "Known Error Requested". X
Known Errors Rejected Known errors in status "Known Error Rejected". X
Known Errors Unpublished Known errors in status "Known Error Unpublished". X
Known Errors Published Known errors in status "Known Error Published". X

Additionally, the following views are made available in the Known Error menu for all the organizational roles:

View Content
Known errors active Known errors in all the statuses but "Cancelled" and "Known Error Closed".
Known errors published Known errors in status "Known Error Published"
Known errors closed Known errors in status "Known Error Closed"
Known errors cancelled Known errors in status "Known Error Cancelled"

Notifications

The following notifications are configured:

Trigger Recipients Purpose
A known error is opened KE authority Alert that there is a new known error to manage and a KE owner to set.
A known error is ready to be published (in status "Known Error Requested") KE authority Alert that there is a request to publish a known error.
A known error publication request is successful KE owner, requester Alert that the known error is published.
A known error publication request is rejected KE owner, requester Alert that the publication request was rejected.
A known error is cancelled Requester Alert that the known error was cancelled.

Reporting

A set of standard reports are made available for the knowledge management process. It is not required to have the REP module to use them, however the module is required if new or changed reports are needed. The available reports are placed under Service Request/Reporting menu.

The following table lists the reports available by default and their visibility:

Report name Content Access
Known errors per service - volume A pie containing the split of knonw errors per service. Service desk, KE authority.
Known errors per service - trend An histogram showing the known errors volumes per service monthly trend. Service desk, KE authority.
Known errors per service/status - volume An histogram showing the known errors volume per service and status. Service desk and technical team members.

A basic form of reporting is also provided by views. Views basically allow to list known errors and their attributes but may also be configured to calculates sums, averages on some of them. The available views are illustrated in the dedicated section of this page.

Examples of use

In this section some examples of use of the configured known error management process are given.

If you get lost, any time use the EXPLORE WORKFLOW command of the known errort management form. This enables to view the status of the workflow as shown in the figure below. By clicking on a relationship between workflow statuses, roles and users enabled to perform it are presented.

Explore Workflow window

NOTE: the EXPLORE WORKFLOW command is available only if the ticket is first saved.

For more information on how to use any workflows, including incident management, please refer to the workflow execution guide.

Create a new known error as a service desk member

  1. Login as "SDSSpecialist" user
  2. Activate the Self Service menu
  3. Choose a self service topic, self service category and finally "Known Error" as self service request (this determines the creation of a new known error)
  4. Fill the known error form, at least with mandatory fields and save with the SAVE command

You have now saved the known error, take note of the ticket number for further reference or use.

Assign known error owner

  1. Based on the service where you have created known error, login as group manager of the team in charge of it (see previous services section), for example login as "AppManager" if you chose the service "itmCLOUD"
  2. Assign the KE owner by filling the Owner field (choose "AppSpecialist") and the team to which the known error is assigned by filling the Solution Group (choose "Application Management")
  3. Save with the SAVE command

The known error is now assigned an owner.

Define a workaround and ask for publication

  1. Login as KE owner ("AppSpecialist" if you followed the steps before)
  2. Open the the desired known error; you can do it quickly either by
    • Access the views in the Tickets window of the home page and choose the "Known Errors Opened" view
    • Access the Known Error/Known Errors active menu and pick among those listed
    • Insert the reference number in Quick Search, after selecting the search context "Ticket"
  3. Update the known error and fill the workaround and Published Workaround field
  4. Set the known error to "Known Error Requested" status by
    • Pressing the SAVE & NEXT command
    • Choose the "Request Known Error Publication" workflow transition
    • Fill the known error form, if needed (because of missing mandatory fields), and save with the SAVE command

The known error is now in workflow status "Known Error Requested".

Publish a known error

  1. Login as a member of the KE authority (for example "AppManager")
  2. Open the the desired known error; you can do it quickly either by
    • Access the views in theTickets window of the home page and choose the "Known Errors Requested"view
    • Access the Known Error/Known Errors active menu and pick among those listed
    • Insert the reference number in Quick Search, after selecting the search context "Ticket"
  3. Set the known error to "Known Error Published" status by
    • Pressing the SAVE & NEXTcommand
    • Choose the "Publish Known Error" workflow transition
    • Fill the known error form, if needed (because of missing mandatory fields), and save with the SAVEcommand

The known error is now in workflow status "Known Error Published".

Search a known error as user

  1. Login as "finaluser"
  2. Search a known error; you can do it quickly either by
    • Insert a search text in Quick Search, after selecting the search context "Known Errors"
    • Access the views in the Tickets window of the home page, choose "Known Errors Published" and browse/filter
    • Access the Known Error/Known Errors published menu and browse/filter

Close a known error

  1. Login as KE owner ("AppSpecialist" if you followed the steps before)
  2. Open the the desired known error; you can do it quickly either by
    • Access the views in the Tickets window of the home page and choose the "Known Errors Opened" view
    • Access the Known Error/Known Errors active menu and pick among those listed
    • Insert the reference number in Quick Search, after selecting the search context "Ticket"
  3. Set the known error to "Known Error Closed" status by
    • Pressing the SAVE & NEXT command
    • Choose the "Close Known Error" workflow transition
    • Fill the known error form, if needed (because of missing mandatory fields), and save with the SAVE command

The known error is now in workflow status "Known Error Closed".