Differenze tra le versioni di "DChange Management"

Da itm wiki.
(Process)
(Etichetta: visualeditor)
 
(53 versioni intermedie di uno stesso utente non sono mostrate)
Riga 1: Riga 1:
''[[Glossary|Problem Management]]'' process is supported by a ''[[Glossary|SM]]'' ''[[Glossary|workflow cartridge]]'' that enables the execution of the process according to the ITIL and ISO/IEC 20000 guidelines.
+
''[[Glossary|Change Management]]'' process is supported by a ''[[Glossary|SM]]'' ''[[Glossary|workflow cartridge]]'' that enables the execution of the process according to the ITIL and ISO/IEC 20000 guidelines.
  
 
Of course the preconfigured process (the ''[[Glossary|workflow cartridge]]'') is just an accelerator and the tuning / completion of the initial configuration will still be required. To this aim, the [[Workflow engine|Workflow Engine]] guide may be useful.
 
Of course the preconfigured process (the ''[[Glossary|workflow cartridge]]'') is just an accelerator and the tuning / completion of the initial configuration will still be required. To this aim, the [[Workflow engine|Workflow Engine]] guide may be useful.
  
'''<u>IMPORTANT NOTE</u>''': the configuration below is only one of the possible configuration to deal with the ''[[Glossary|problem management]]'' process. The need for a different behaviour of the process may be fulfilled by simple changes of the configuration.
+
'''<u>IMPORTANT NOTE</u>''': the configuration below is only one of the possible configuration to deal with the ''[[Glossary|change management]]'' process. The need for a different behaviour of the process may be fulfilled by simple changes of the configuration.
  
 
== Operational model ==
 
== Operational model ==
The preconfigured process has the objective to facilitate and support the resolution of ''problems'' or the provision of ''workarounds''. At the core of the process configuration is the following operational model.
+
The preconfigured process has the objective to facilitate and support the effective and efficient execution of ''[[Glossary|changes]]''. At the core of the process configuration is the following operational model.
[[File:Problem Management Operational Model v1.0.JPG|centre|thumb|500x500px|Problem Management operational model]]
+
[[File:Change Management Operational Model v1.0.JPG|centre|thumb|800x800px|Change Management operational model]]
The requester, typically a member of the ''service desk'' or a technical team requires to open a ''[[Glossary|problem]]''. This may happen reactively (as a consequence of dealing with an ''[[Glossary|incident]]'') or proactively (in order to avoid future ''[[Glossary|incidents]]''). The ''[[Glossary|problem]]'' is opened on a ''[[Glossary|service]]'' and the ''[[Glossary|service manager]]'' takes in charge it in order to coordinate the initial classification, prioritization and analysis. In this phase a problem owner is assigned who will coordinate the following steps of the process where ''[[Glossary|workarounds]]'' and solutions for the ''[[Glossary|problem]]''.
+
The requester, an authorized ''[[Glossary|client]]'', service manager, member of the ''[[Glossary|service desk]]'' or technical team or n related process (such as [[Glossary|''Incident Management'']] or ''[[Glossary|Problem Management]]'') requires to open a ''[[Glossary|Request for Change]]'' (RfC). The service manager takes in charge it and assigns an owner who coordinates all the tasks needed to fulfil the ''[[Glossary|change]]''. The owner requests the ''[[Glossary|change]]'' authorization to the ''[[Glossary|change authority]]'', if needed. As appropriate, technical team members may directly implement and deploy the ''[[Glossary|change]]'' or make it through the ''[[Glossary|Release Management]]'' process and later the ''[[Glossary|Depolyment Change]]''.
  
 
== Roles ==
 
== Roles ==
Riga 18: Riga 18:
 
|-
 
|-
 
|Requester ||  
 
|Requester ||  
* Opens ''[[Glossary|problems]]'' on behalf of himself/herself or for a third party
+
* Opens ''[[Glossary|requests for change]]'' on behalf of himself/herself or for a third party
||  This role is assigned to members of ''service desk'' (''[[Glossary|users]]'' belonging to ''[[Glossary|group]]'' "Service Desk")  and to members of the technical teams (see Technical team member role).
+
||  This role is mapped on:
 +
* a system ''[[Glossary|resource]] ''with ''[[Glossary|user]] ''of ''[[Glossary|user type]] ''"Requester". The login identifier of this ''[[Glossary|user]] ''is "FinalUser";
 +
* service manager (see after);
 +
* service desk members (system ''[[Glossary|resources]] ''with ''[[Glossary|user]] ''of ''[[Glossary|user type]] ''"Resource"; the login identifier of this ''[[Glossary|user]] ''is "SDSpecialist";
 +
* technical team members (see after).
 
   
 
   
 
|-
 
|-
| Problem owner ||
+
| Change owner ||
* Assigns the ''[[Glossary|problem]] ''for analysis and resolution
+
* Requires ''[[Glossary|change]]'' approval to the change authority after its assessment is completed
*  Watches over and monitors the ''[[Glossary|problem]] ''along all its life cycle ensuring target service levels are achieved
+
* Assign tasks to be performed to complete the ''[[Glossary|change]]''
 +
*  Watches over and monitors the ''[[Glossary|change]] ''along all its life cycle ensuring target service levels are achieved
 
* Activates escalation/ routing/ requests
 
* Activates escalation/ routing/ requests
 
* Manages all the communications with the requester
 
* Manages all the communications with the requester
* Checks the implemented resolution and sets the ''[[Glossary|problem]] ''to resolved
+
* Checks the implementation and sets the ''[[Glossary|change]] ''to to completed
* Closes the ''[[Glossary|problem]]''
+
* Closes the ''[[Glossary|change]] ''after completing the final checks
 
|| Role assigned by the service manager to himself/herself or to a technical team member.   
 
|| Role assigned by the service manager to himself/herself or to a technical team member.   
 
   
 
   
 
|-
 
|-
 
| Technical team member  ||  
 
| Technical team member  ||  
* He/she receives the notification on the assignment of an activity concerning a ''[[Glossary|problem]] ''(e.g. conducting the analysis and finding a resolution or ''[[Glossary|workaround]] ''for it)
+
* He/she receives the notification on the assignment of an activity concerning a ''[[Glossary|change]] ''(e.g. conducting the assessment or designing/implementing it)
  
 
* Carries out the assigned tasks
 
* Carries out the assigned tasks
Riga 40: Riga 45:
  
 
{| class="wikitable"
 
{| class="wikitable"
! Domain !! ''[[Glossary|Solution group]]'' !! Member
+
! Domain !! ''[[Glossary|Group]]'' !! Member
 
''[[Glossary|users]]''
 
''[[Glossary|users]]''
  
Riga 63: Riga 68:
 
|-
 
|-
 
| Technical team manager ||  
 
| Technical team manager ||  
* Receives the notification about the assignment of the ''[[Glossary|problem]] ''to his/her team in order to find a resolution or ''[[Glossary|workaround]] ''for it
+
* Receives the notification about the assignment of the ''[[Glossary|change]] ''to his/her team in order to implement it
 
* Assign the member of his/her team who should work on it (this can be done by setting the ''[[Glossary|ticket worker]]'' or creating and assigning ''[[Glossary|ticket activities]]'')
 
* Assign the member of his/her team who should work on it (this can be done by setting the ''[[Glossary|ticket worker]]'' or creating and assigning ''[[Glossary|ticket activities]]'')
 
* Watches over and monitors the work of his/her team
 
* Watches over and monitors the work of his/her team
Riga 69: Riga 74:
  
 
{| class="wikitable"
 
{| class="wikitable"
! Domain !! ''[[Glossary|Solution group]]'' !! ''[[Glossary|Solution group manager]]''
+
! Domain !! ''[[Glossary|Group]]'' !! ''[[Glossary|Group manager]]''
  
 
|-
 
|-
Riga 87: Riga 92:
 
|-
 
|-
 
| Service manager ||  
 
| Service manager ||  
* Takes in charge and assigns the problem owner
+
* Takes in charge and assigns the change owner
* Monitors how the ''[[Get started with itmSUITE®|problems]]'' are evolving for the ''[[Glossary|service(s)]]'' he/she is responsible for
+
* Monitors how the ''[[Get started with itmSUITE®|changes]]'' are evolving for the ''[[Glossary|service(s)]]'' he/she is responsible for
 
|| This role is mapped on a system ''[[Glossary|resource]] ''with ''[[Glossary|user]] ''of ''[[Glossary|user type]] ''"Project/Service Manager". There are different service managers configured for specific ''[[Glossary|services]]''. See [[Incident Management#Services|Services]] section in this page for further information.  
 
|| This role is mapped on a system ''[[Glossary|resource]] ''with ''[[Glossary|user]] ''of ''[[Glossary|user type]] ''"Project/Service Manager". There are different service managers configured for specific ''[[Glossary|services]]''. See [[Incident Management#Services|Services]] section in this page for further information.  
 +
 +
|-
 +
| Change authority ||
 +
* Approves the ''[[Glossary|change]]'' implementation
 +
* Approves the ''[[Glossary|change]]'' deployment
 +
|| This role is mapped based on the required authorization and ''[[Glossary|change]]'' classification.
 +
 +
For ''[[Glossary|change]]'' implementation authorization:
 +
{| class="wikitable"
 +
! <u>Change Type</u> !! ''<u>Change Category</u> '' !! ''Change authority''
 +
 +
|-
 +
|"Emergency" ||  || Service manager
 +
 +
|-
 +
|"Normal" || "Minor" || Service manager
 +
 +
|-
 +
|"Normal" || "Significant" || CAB
 +
 +
|-
 +
|"Standard" ||  || Change owner
 +
 +
|}
 +
The CAB is mapped on a ''[[Glossary|group]]'': "CAB".
 +
 +
For ''[[Glossary|change]]'' deployment authorization: 
 +
{| class="wikitable"
 +
! <u>Change Type</u> !! ''<u>Change Category</u> '' !! ''Change authority''
 +
 +
|-
 +
|"Emergency" ||  || Service manager
 +
 +
|-
 +
|"Normal" || "Minor" || Change owner
 +
 +
|-
 +
|"Normal" || "Significant" || Service manager
 +
 +
|-
 +
|"Standard" ||  || Change owner
 +
 +
|}
  
 
|}
 
|}
In some organizational contexts, the role of the service manager may be played by the manager of a dedicated problem management team, mapped on a specific ''[[Glossary|group]] ''and the role of problem owner by a member of this team.
 
  
 
== Process ==
 
== Process ==
As for all ''[[Glossary|workflows]]'', new ''[[Glossary|problems]]'' can be created by using the ''[[Glossary|self service portal]]'', accessible by means of '''''Self Service''''' menu.  
+
As for all ''[[Glossary|workflows]]'', new ''[[Glossary|changes]]'' can be created by using the ''[[Glossary|self service portal]]'', accessible by means of '''''Self Service''''' menu.  
  
The following ''[[Glossary|requests]]'' which trigger a new instance of the ''[[Glossary|problem management]]'' process are configured and available to all organizational roles in the ''self service portal'':   
+
The following ''[[Glossary|requests]]'' which trigger a new instance of the ''[[Glossary|change management]]'' process are configured and available to all organizational roles in the ''self service portal'':   
  
 
{| class="wikitable sortable"
 
{| class="wikitable sortable"
Riga 103: Riga 150:
  
 
|-
 
|-
| "Applications" || "itmCLOUD" || "Problem" (open a ''[[Glossary|problem]]'') ||Requesters and service managers.
+
| "Applications" || "itmCLOUD" || "Change" (open a ''[[Glossary|change]]'') ||Requesters
  
 
|-
 
|-
| "Personal Devices" || "Personal Computers" || "Problem" (open a ''[[Glossary|problem]]'') ||Requesters and service managers.
+
| "Personal Devices" || "Personal Computers" || "Change" (open a ''[[Glossary|change]]'') ||Requesters
  
 
|-
 
|-
| "Personal Devices" || "Peripherals" || "Problem" (open a ''[[Glossary|problem]]'') ||Requesters and service managers.
+
| "Personal Devices" || "Peripherals" || "Change" (open a ''[[Glossary|change]]'') ||Requesters
  
 
|-
 
|-
| "Personal Devices" || "Telephony" || "Problem" (open a ''[[Glossary|problem]]'') ||Requesters and service managers.
+
| "Personal Devices" || "Telephony" || "Change" (open a ''[[Glossary|change]]'') ||Requesters
  
 
|-
 
|-
| "Network" || "Networking Management" || "Problem" (open a ''[[Glossary|problem]]'') ||Requesters and service managers.
+
| "Network" || "Networking Management" || "Change" (open a ''[[Glossary|change]]'') ||Requesters
  
 
|-
 
|-
| "Technical Services" || "Server Management" || "Problem" (open a ''[[Glossary|problem]]'') ||Requesters and service managers.
+
| "Technical Services" || "Server Management" || "Change" (open a ''[[Glossary|change]]'') ||Requesters
  
 
|}
 
|}
  
A ''[[Glossary|problem]]'' may also be automatically opened during the execution of an [[Incident Management|incident management]] process by the ''[[Glossary|resources]]'' dealing with it.
+
A ''[[Glossary|change]]'' may also be automatically opened during the execution of other processes by the ''[[Glossary|resources]]'' dealing with them.  
 
 
A ''[[Get started with itmSUITE®|workflow]]'' is configured to support the ''[[Glossary|problem management]]'' process. The ''[[Glossary|workflow]]'' is characterized by ''[[Glossary|workflow statuses]]'' and ''[[Glossary|workflow transitions]]''. The figure below illustrates the process.
 
 
 
[[File:Problem Management Workflow v1.0.JPG|centre|thumb|800x800px|Problem management process.]]
 
  
 +
A ''[[Get started with itmSUITE®|workflow]]'' is configured to support the ''[[Glossary|change management]]'' process. The ''[[Glossary|workflow]]'' is characterized by ''[[Glossary|workflow statuses]]'' and ''[[Glossary|workflow transitions]]''. The figures below illustrate the process.
 +
[[File:Change management Operational Model 1 of 3 v1.0 .jpg|centre|thumb|800x800px|Change management process (1 of 3).]]
 +
[[File:Change management Operational Model 2 of 3 v1.0 .jpg|centre|thumb|800x800px|Change management process (2 of 3).]]
 +
[[File:Change management Operational Model 3 of 3 v1.0 .jpg|centre|thumb|800x800px|Change management process (3 of 3).]]
 
The table below explains the meaning of each ''[[Glossary|workflow status.]] ''
 
The table below explains the meaning of each ''[[Glossary|workflow status.]] ''
  
Riga 134: Riga 181:
  
 
|-
 
|-
| "Default" || A preliminary status which is displayed when a ''[[Glossary|problem]]'' is created.  
+
| "Default" || A preliminary status which is displayed when a ''[[Glossary|change]]'' is created.  
  
 
|-
 
|-
| "Opened" || The ''[[Glossary|problem]]'' has been recorded and activities to resolve it started.  
+
| "Opened" || The ''[[Glossary|change]]'' has been recorded.  
  
 
|-
 
|-
| "Requested" || The ''[[Glossary|problem]]'' is confirmed and the service manager may start to analyse it and assigns the problem owner.  
+
| "Requested" || The ''[[Glossary|change]]'' is confirmed and has been requested (it is a ''[[Glossary|request for change]]'').  
  
 
|-
 
|-
| "Problem Assigned" || The ''[[Glossary|problem]]'' is assigned a problem owner and the analysis activities plan is defined.  
+
| "In Analysis" || The ''[[Glossary|change]]'' assessment and planning is ongoing.  
  
 
|-
 
|-
| "Problem in Analysis" || The problem owner coordinates the analysis. The root cause is investigated and found. ''[[Glossary|Workarounds]]'' may be found too. Finally a plan to implement the resolution is prepared.  
+
| "Implementation Approval Requested" || The ''[[Glossary|change]]'' approval request for implementation is submitted to the change authority.  
  
 
|-
 
|-
| "Problem in Resolution" || The plan to implement the ''[[Glossary|problem]]'' resolution is executed. A ''[[Glossary|change]]'' may be opened at this stage.   
+
| "Approved" || The ''[[Glossary|change]]'' is approved for implementation.   
  
 
|-
 
|-
| "Cancelled" || The ''[[Glossary|problem]] ''is not confirmed and, therefore, cancelled.   
+
| "Not Approved" || The ''[[Glossary|change]]'' is not approved for implementation.   
  
 
|-
 
|-
| "Resolved" || The ''[[Glossary|problem]] ''is resolved, meaning that the plan to implement a resolution is positively concluded.  
+
| "In Progress" || The ''[[Glossary|change]]'' implementation is ongoing.
  
 
|-
 
|-
| "Suspended" || The ''[[Glossary|problem]] ''execution is temporarily suspended. In this status ''[[Glossary|service levels]]'' calculation are suspended too.  
+
| "Ready for Test" || The ''[[Glossary|change]]'' is ready for testing.
  
 
|-
 
|-
| "Major Problem Review" || In case of major ''[[Glossary|problem]], ''in this status a review is performed.  
+
| "In Test" || The ''[[Glossary|change]]'' testing is ongoing.
  
 
|-
 
|-
| "Closed" || The ''[[Glossary|problem]] ''closure has been confirmed. No other changes are possible.  
+
| "Deployment Approval Requested" || The ''[[Glossary|change]]'' approval request for deployment is submitted to the change authority. 
 +
 
 +
|-
 +
| "Deployment Approved" || The ''[[Glossary|change]]'' is approved for deployment. 
 +
 
 +
|-
 +
| "Completed" || The ''[[Glossary|change]]'' is completed. 
 +
 
 +
|-
 +
| "Change Review" || The ''[[Glossary|change]]'' review is ongoing. 
 +
 
 +
|-
 +
| "Cancelled" || The ''[[Glossary|change]] ''is not confirmed and, therefore, cancelled. 
 +
 
 +
|-
 +
| "Suspended" || The ''[[Glossary|change]] ''execution is temporarily suspended. In this status ''[[Glossary|service levels]]'' calculation are suspended too.
 +
 
 +
|-
 +
| "Aborted" || The ''[[Glossary|change]]'' execution is aborted. 
 +
 
 +
|-
 +
| "Closed" || The ''[[Glossary|change]] ''closure has been confirmed.  
 
   
 
   
 
|}
 
|}
Riga 174: Riga 242:
  
 
|-
 
|-
| "Default" || "Opened" || Requesters, technical team members, service managers. ||See the ''[[Glossary|self service portal]]'' configuration previously described.
+
| "Default" || "Opened" || Requesters ||See the ''[[Glossary|self service portal]]'' configuration previously described.
  
 
|-
 
|-
Riga 187: Riga 255:
  
 
|-
 
|-
| "Requested" || "Cancelled" || Requester, service manager. ||
+
| "Requested" || "Cancelled" || Requester, service manager, chabge owner. ||
  
 
|-
 
|-
| "Requested" || "Suspended" || Service manager. ||
+
| "Requested" || "In Analysis" || Service manager, change owner. ||
  
 
|-
 
|-
| "Suspended" || "Requested" || Service manager. ||
+
| "Deployment Approved" || "Aborted" || Service manager, change owner. ||
  
 
|-
 
|-
| "Problem Assigned" || "Problem in Analysis" || Problem owner, service manager. ||
+
| "In Analysis" || "Requested" || Service manager, change owner. ||
  
 
|-
 
|-
| "Problem Assigned" || "Suspended" || Problem owner, service manager. ||
+
| "In Analysis" || "Approval Requested" || Service manager, change owner. ||
  
 
|-
 
|-
| "Suspended" || "Problem Assigned" || Problem owner, service manager. ||
+
| "In Analysis" || "Cancelled" || Service manager, change owner. ||
 +
 
 +
 
 +
|-
 +
| "Approval Requested" || "Approved" || Change authority. ||Depending on ''[[Glossary|change]]'' classification (see [[DChange Management|roles]] for more details).
  
 
|-
 
|-
| "Problem Assigned" || "Cancelled" || Problem owner, service manager. ||
+
| "Approval Requested" || "Not Approved" || Change authority. ||Depending on ''[[Glossary|change]] ''classification (see [[DChange Management|roles]] for more details).
  
 
|-
 
|-
| "Problem in Analysis" || "Suspended" || Problem owner, service manager. ||
+
| "Approval Requested" || "In Analysis" || Service manager, change owner. ||
  
 
|-
 
|-
| "Suspended" || "Problem in Analysis" || Problem owner, service manager. ||
+
| "Not Approved" || "Cancelled" || Service manager, change owner. ||
  
 
|-
 
|-
| "Problem in Analysis" || "Problem in Resolution" || Problem owner, service manager. ||
+
| "Approved" || "In Progress" || Service manager, change owner, technical team member. ||
  
 
|-
 
|-
| "Problem in Resolution" || "Problem in Analysis" || Problem owner, service manager. ||
+
| "Approved" || "Suspended" || Service manager, change owner. ||
 +
 
  
 
|-
 
|-
| "Problem in Analysis" || "Cancelled" || Problem owner, service manager. ||
+
| "Approved" || "Aborted" || Service manager, change owner. ||
  
 
|-
 
|-
| "Problem in Resolution" || "Cancelled" || Problem owner, service manager. ||
+
| "Suspended" || "In Progress" || Service manager, change owner. ||
  
 
|-
 
|-
| "Problem in Resolution" || "Resolved" ||Problem owner, service manager. ||
+
| "In progress" || "Suspended" || Service manager, change owner. ||
  
 
|-
 
|-
| "Problem in Resolution" || "Suspended" || Problem owner, service manager. ||
+
| "In progress" || "Aborted" || Service manager, change owner. ||
  
 
|-
 
|-
| "Resolved" || "Major Problem Review" || Automatic ||The ''[[Glossary|workflow transition]]'' is automatically performed when the field <u>Major Problem</u> is set to "Yes".
+
| "In progress" || "Ready for Test" || Service manager, change owner, technical team member ||
  
 
|-
 
|-
| "Requested" || "Problem Assigned" || Service manager. ||
+
| "In progress" || "In Test" || Service manager, change owner, technical team member. ||
  
 
|-
 
|-
| "Major Problem Review" || "Closed" || Problem owner, service manager. ||Any related ''[[Glossary|incident]]'' is set to closed (''[[Glossary|workflow status]]'' "Resolved" in ''[[Incident Management#Process|incident management]]'') and any related ''[[Glossary|known error]]'' is unpublished (''[[Glossary|workflow status]]'' "Known Error Unpublished" in ''[[Known Error Management#Process|known error management]]'').
+
| "In progress" || "Deployment Approval Requested" || Service manager, change owner. ||
  
 
|-
 
|-
| "Suspended" || "Problem in Resolution" || Problem owner, service manager. ||
+
| "In progress" || "Completed" || Service manager, change owner. ||Only for ''[[Glossary|changes]]'' with <u>Change Type</u> "Standard" or with Change Type "Normal" and <u>Change Category</u> "Minor".
  
 
|-
 
|-
| "Resolved" || "Closed" || Requester, problem owner, service manager. ||Any related ''[[Glossary|incident]] ''is set to closed (''[[Glossary|workflow status]] ''"Resolved" in ''[[Incident Management#Process|incident management]]'') and any related ''[[Glossary|known error]] ''is unpublished (''[[Glossary|workflow status]]''"Known Error Unpublished" in ''[[Known Error Management#Process|known error management]]'').
+
| "Ready for Test" || "In Test" || Service manager, change owner, technical team member. ||
 +
 
 +
|-
 +
| "Ready for Test" || "Suspended" || Service manager, change owner. ||
 +
 
 +
|-
 +
| "Ready for Test" || "Aborted" || Service manager, change owner. ||
 +
 
 +
|-
 +
| "In Test" || "Deployment Approval Requested" || Service manager, change owner. ||
 +
 
 +
|-
 +
| "In Test" || "Suspended" || Service manager, change owner. ||
 +
 
 +
|-
 +
| "In Test" || "Aborted" || Service manager, change owner. ||
 +
 
 +
|-
 +
| "Deployment Approval Requested" || "Deployment Approved" || Change authority. ||
 +
 
 +
|-
 +
| "Deployment Approval Requested" || "Suspended" || Service manager, change owner. ||
 +
 
 +
|-
 +
| "Deployment Approval Requested" || "Aborted" || Service manager, change owner. ||
 +
 
 +
|-
 +
| "Deployment Approved" || "Completed" || Service manager, change owner. ||
 +
 
 +
 
 +
|-
 +
| "Completed" || "Change Review" || Service manager, change owner. ||
 +
 
 +
|-
 +
| "Completed" || "Closed" || Service manager, change owner. ||Not allowed for ''[[Glossary|changes]]'' with <u>Change Type</u> "Emergency" and <u>Change Type</u> "Normal" and <u>Change Category</u> "Significant"
 +
 
 +
|-
 +
| "Change review" || "Closed" || Service manager, change owner. ||
 +
 
 +
|-
 +
| "Not Approved" || "In Analysis" || Service manager, change owner. ||
  
 
|}
 
|}
  
 
=== Related processes ===
 
=== Related processes ===
Several other ''[[Glossary|IT Service Management]]'' processes are related to the ''[[Glossary|problem management]]'' one. Some basic interfaces are provided. The tab ''<u>Related Items</u>'' of the ''[[Glossary|problem]]'' and, in particular, the sub tab <u>''Tickets''</u> of it allows to view all the existing between the ''[[Glossary|problem]]'' and other processes (managed through ''[[Glossary|tickets]]'').
+
Several other ''[[Glossary|IT Service Management]]'' processes are related to the ''[[Glossary|change management]]'' one. Some basic interfaces are provided. The tab ''<u>Related Items</u>'' of the ''[[Glossary|change]]'' and, in particular, the sub tab <u>''Tickets''</u> of it allows to view all the existing relationships between the ''[[Glossary|change]]'' and other processes (managed through ''[[Glossary|tickets]]'').
  
 
==== Incident management ====
 
==== Incident management ====
It is possible to create a ''[[Glossary|problem]]'' from the ''[[Incident Management#Problem management|incident management]]'' process or to relate an existing ''[[Glossary|problem]]'' to an ''[[Glossary|incident]]'' and vice versa.
+
It is possible to create a ''[[Glossary|change]]'' from the ''[[Incident Management#Problem management|incident management]]'' process or to relate an existing ''[[Glossary|change]]'' to an ''[[Glossary|incident]]'' and vice versa.The ''[[Glossary|change]]'' usually implements the resolution of an ''[[Glossary|incident]]''.
  
==== Change management ====
+
==== Problem management ====
It is possible to create a new ''[[Glossary|change]]'', managed via the ''[[Glossary|change management]]'' process. The '''GENERATE CHANGE''' command allows to instantiate a new ''[[Glossary|change]]'' by copying some ''[[Glossary|problem]]'' information and by creating a relationship between the ''[[Glossary|problem]]'' and the generated ''[[Glossary|change]]''.
+
It is possible to create a ''[[Glossary|change]] ''from the ''[[Incident Management#Problem management|problem management]] ''process or to relate an existing ''[[Glossary|change]] ''to a ''[[Glossary|problem]] ''and vice versa.The ''[[Glossary|change]] ''usually implements the resolution of a ''[[Glossary|problem]]''.
  
 
==== Asset management and configuration management ====
 
==== Asset management and configuration management ====
It is possible to relate ''[[Glossary|configuration items]]'' to a ''[[Glossary|problem]]'' by using the tab ''<u>Related Items</u>'' and, in particular, the sub tab <u>''Configuration Items''</u>. The ''[[Glossary|ASM]]'' and/or [[Glossary|''CMS'']] ''[[Glossary|modules]]'' features are made available here (e.g. view of ''[[Glossary|configuration item]]'' details, ''[[Glossary|configuration exploration]]'' or ''[[Glossary|impact analysis]]'').
+
It is possible to relate ''[[Glossary|configuration items]]'' to a ''[[Glossary|change]]'' by using the tab ''<u>Related Items</u>'' and, in particular, the sub tab <u>''Configuration Items''</u>. The ''[[Glossary|ASM]]'' and/or [[Glossary|''CMS'']] ''[[Glossary|modules]]'' features are made available here (e.g. view of ''[[Glossary|configuration item]]'' details, ''[[Glossary|configuration exploration]]'' or ''[[Glossary|impact analysis]]'').
 
 
==== Known error management ====
 
It is possible to create a new ''[[Glossary|known error]]'', managed via the ''[[Glossary|known error management]] ''process. The '''GENERATE KE '''command allows to instantiate a new ''[[Glossary|known error]] ''by copying some ''[[Glossary|problem]] ''information and by creating a relationship between the ''[[Glossary|problem]] ''and the generated ''[[Glossary|knonw error]]''.
 
  
 
==== Release and deployment management ====
 
==== Release and deployment management ====
A ''[[Glossary|release]]'' may include the solution of one or more ''[[Glossary|problems]]'' even if this may happen rarely (more frequently a ''[[Glossary|release]]'' includes changes generated to resolve ''[[Glossary|problems]]'' and related to them,  The relationship between a ''[[Glossary|release]]'' and and [[Glossary|problems]] is more frequently created working from the ''[[Glossary|release]]''. In any case, this can be done from the ''[[Glossary|tickets]]'' tab ''<u>Related Items</u> ''and, in particular, the sub tab ''<u>Configuration Items</u>'' by using the '''ADD EXISTING''' or '''SELF SERVICE''' commands. <nowiki/>
+
A ''[[Glossary|release]]'' may include one or more ''[[Glossary|changes]].'' The relationship between a ''[[Glossary|release]]'' and and [[Glossary|change]] can be created from the ''[[Glossary|change]]'' but is is more frequently created working from the ''[[Glossary|release]]''. In any case, the relation from the ''[[Glossary|change]]'' can be created from the ''[[Glossary|tickets]]'' tab ''<u>Related Items</u> ''and, in particular, the sub tab ''<u>Configuration Items</u>'' by using the '''ADD EXISTING''' or '''SELF SERVICE''' commands. <nowiki/>
  
 
== Services ==
 
== Services ==
Different ''[[Get started with itmSUITE®|services]]'' are configured for different ''[[Glossary|problem]]'' domain areas as illustrated in the following table.
+
Different ''[[Get started with itmSUITE®|services]]'' are configured for different ''[[Glossary|change]]'' domain areas as illustrated in the following table.
  
 
{| class="wikitable"
 
{| class="wikitable"
Riga 287: Riga 397:
  
 
== Management information ==
 
== Management information ==
Many management information are available as fields in the ''[[Glossary|problem]]'' management configured form. The following table illustrates the intended use of key information and its behaviour. '''<u>NOTE</u>''': 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.  
+
Many management information are available as fields in the ''[[Glossary|change]]'' management configured form. The following table illustrates the intended use of key information and its behaviour. '''<u>NOTE</u>''': 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.  
  
 
{| class="wikitable sortable"
 
{| class="wikitable sortable"
Riga 293: Riga 403:
  
 
|-
 
|-
| <u>''General Information''</u> || <u>Ticket Op Status</u> || To show the operational status of the ''[[Glossary|problem]]'', see ''[[Glossary|workflow statuses]]'' in [[Incident Management#Process|Process]] section of this page. ||Status changes are performed by means of the '''Save&Next''' command.
+
| <u>''General Information''</u> || <u>Ticket Op Status</u> || To show the operational status of the ''[[Glossary|change]]'', see ''[[Glossary|workflow statuses]]'' in [[Incident Management#Process|Process]] section of this page. ||Status changes are performed by means of the '''Save&Next''' command.
  
 
|-
 
|-
Riga 300: Riga 410:
  
 
|-
 
|-
| ''<u>General Information</u>'' || <u>Short Description</u> || To provide a short description of the ''[[Glossary|problem]]''. ||Always visible.
+
| ''<u>General Information</u>'' || <u>Short Description</u> || To provide a short description of the ''[[Glossary|change]]''. ||Always visible.
  
 
|-
 
|-
| <u>''General Information''</u> || <u>Requester</u> || To identify the name of the requester (who has requested the ''[[Glossary|problem]]''). ||A list is presented, influenced by.... TBC
+
| <u>''General Information''</u> || <u>Requester</u> || To identify the name of the requester (who has requested the ''[[Glossary|change]]''). ||A list is presented, influenced by.... TBC
  
 
|-
 
|-
| <u>''General Information''</u> || <u>Creation Date</u> || To show the date and time the ''[[Glossary|problem]]'' was created. ||This information is automatically recorded and cannot be manually changed. See ''<u>History</u>'' tab for more detailed tracking information.
+
| <u>''General Information''</u> || <u>Creation Date</u> || To show the date and time the ''[[Glossary|change]]'' was created. ||This information is automatically recorded and cannot be manually changed. See ''<u>History</u>'' tab for more detailed tracking information.
  
 
|-
 
|-
| <u>''General Information''</u> || <u>Edit Date</u> || To show the date and time the ''[[Glossary|problem]] ''was last updated. ||This information is automatically recorded and cannot be manually changed. See ''<u>History</u> ''tab for more detailed tracking information.
+
| <u>''General Information''</u> || <u>Edit Date</u> || To show the date and time the ''[[Glossary|change]] ''was last updated. ||This information is automatically recorded and cannot be manually changed. See ''<u>History</u> ''tab for more detailed tracking information.
  
 
|-
 
|-
| <u>''General Information''</u> || <u>Creation User</u> || To show the ''[[Glossary|user]]'' who created the ''[[Glossary|problem]]''. ||This information is automatically recorded and cannot be manually changed. See ''<u>History</u> ''tab for more detailed tracking information.
+
| <u>''General Information''</u> || <u>Creation User</u> || To show the ''[[Glossary|user]]'' who created the ''[[Glossary|change]]''. ||This information is automatically recorded and cannot be manually changed. See ''<u>History</u> ''tab for more detailed tracking information.
  
 
|-
 
|-
| <u>''General Information''</u> || <u>Edit User</u> || To show the ''[[Glossary|user]]'' who updated the ''[[Glossary|problem]]'' last. ||This information is automatically recorded and cannot be manually changed. See ''<u>History</u> ''tab for more detailed tracking information.
+
| <u>''General Information''</u> || <u>Edit User</u> || To show the ''[[Glossary|user]]'' who updated the ''[[Glossary|change]]'' last. ||This information is automatically recorded and cannot be manually changed. See ''<u>History</u> ''tab for more detailed tracking information.
  
 
|-
 
|-
| <u>''Ticket Classification''</u> || <u>Project/Service</u> || To show the ''[[Glossary|service]]'' (or [[Glossary|''project'']]) to which the ''[[Glossary|problem]]'' is related. ||This is automatically set at open time and can't be modified.
+
| <u>''Ticket Classification''</u> || <u>Project/Service</u> || To show the ''[[Glossary|service]]'' (or [[Glossary|''project'']]) to which the ''[[Glossary|change]]'' is related. ||This is automatically set at open time and can't be modified.
  
 
|-
 
|-
Riga 324: Riga 434:
  
 
|-
 
|-
| ''<u>Ticket Classification</u>'' || <u>Problem type</u> || To enter the information whether the ''[[Glossary|problem]]'' is reactive (opened as a consequence of one or more ''[[Glossary|incidents]]'') or proactive (opened to avoid potential ''[[Glossary|incidents]]''). ||
+
| ''<u>Ticket Classification</u>'' || <u>Chage Area</u> <u>Change Objective</u> <u>Change Type</u> <u>Change Categor</u>y
 +
|| To set the ''[[Glossary|change]]'' key classification information.This is used for statistic reasons but the <u>Change Category</u> may also be configured to drive the ''[[Glossary|change]]'' authorization. ||<u>Change Area</u>, <u>Change Objective</u> and <u>Change Type</u> are independent fields. <u>Change Category</u> is available only if <u>Change Type</u> is set to "Normal": In such a case, its value is influenced by the ''[[Glossary|change]]'' assessment fields (see below). The classification information initially provided can be changed.
  
 
|-
 
|-
| ''<u>Ticket Classification</u>'' || <u>Problem Classification</u>  
+
| ''<u>Ticket Classification</u>'' || <u>Change Scope</u>  
|| To set the ''[[Glossary|problem]]'' classification information (domain).This is used for statistic reasons. ||The classification information initially provided can be changed.
+
|| To set the ''[[Glossary|change]]'' scope.This is typically used for statistic reasons. ||The classification information initially provided can be changed.
  
 
|-
 
|-
| ''<u>Ticket Classification</u>'' || <u>Major Problem</u>  
+
| ''<u>Ticket Classification</u>'' || <u>Service impact</u> <u>Capacity impact</u> <u>Security impact</u> <u>Cost estimation</u> <u>Performance impact</u>  
|| To show if the ''[[Glossary|problem]]'' has to be considered major or not. ||This impacts the need of a final review (if major) or not.
+
|| These fields are the ''[[Glossary|change]]'' assessment elements. The values given will influence the <u>Change Category</u> value. ||The classification information initially provided (number and content of fields) as well as the rules to influence the <u>Change Category</u> can be changed.
  
 
|-
 
|-
| <u>''Prioritisation & Planning''</u> || <u>Required Solution Date</u> || To provide the date of solution requested by the <u>Requester</u>. ||This is normally set for reactive ''[[Glossary|problems]]'', according to the related ''[[Glossary|incidents]]'' priorities and status.
+
| <u>''Prioritisation & Planning''</u> || <u>Required Solution Date</u> || To provide the date of ''[[Glossary|change]]'' implementation required by the <u>Requester</u>. ||  
  
 
|-
 
|-
| <u>''Prioritisation & Planning''</u> || <u>User Priority</u> || To provide the priority given to the ''[[Glossary|problem]]'' by the <u>Requester</u>. ||A four level scale is set but it can be changed.  
+
| <u>''Prioritisation & Planning''</u> || <u>User Priority</u> || To provide the priority given to the ''[[Glossary|change]]'' by the <u>Requester</u>. ||A four level scale is set but it can be changed.
  
 
|-
 
|-
| <u>''Prioritisation & Planning''</u> || <u>Ticket Urgency</u> || To define the urgency for the resolution. ||A three level scale is set but it can be changed.
+
| <u>''Prioritisation & Planning''</u> || <u>Forecasted Solution Date</u> || To provide the date of ''[[Glossary|change]] ''implementation forecasted. ||
  
 
|-
 
|-
| <u>''Prioritisation & Planning''</u> || <u>Ticket Impact</u> || To define the impact on the business of the ''[[Glossary|problem]]''. ||A four level scale is set but it can be changed.
+
| <u>''Prioritisation & Planning''</u> || <u>Forecasted Solution Date</u> || To set the forecasted resolution date and time for the ''[[Glossary|change]]''. ||
  
 
|-
 
|-
| <u>''Prioritisation & Planning''</u> || <u>Ticket Priority</u> || To view the calculated priority of the ''[[Glossary|problem]]''. ||The priority is automatically set based on <u>Ticket Urgency</u> and <u>Ticket Impact</u>. The driving matrix can be configured.
+
| <u>''Ownership and Groups''</u> || <u>Master SG</u> || To define the supervising team. ||This is set by the service manager and mandatory from the <u>Ticket Op Status</u> "In Analysis".
  
 
|-
 
|-
| <u>''Prioritisation & Planning''</u> || <u>Forecast Solution Date</u> || To set the forecasted resolution date and time for the ''[[Glossary|problem]]''. ||
+
| <u>''Ownership and Groups''</u> || <u>Solution Group</u> || To define the team to which the'' [[Glossary|change]]'' is assigned for analysis and/or implementation. ||This is set by the service manager and mandatory from the <u>Ticket Op Status </u>"Approval Requested".
  
 
|-
 
|-
| <u>''Ownership and Groups''</u> || <u>Master SG</u> || To define the supervising team. ||This is set by the service manager and mandatory from the <u>Ticket Op Status</u> "Problem Assigned".
+
| <u>''Ownership and Groups''</u> || <u>Owner</u> || To define who is the ''[[Glossary|change]]'' owner who should monitor the lifecycle of the ''[[Glossary|change]]''. ||This is set by the service manager and mandatory from the <u>Ticket Op Status</u> "In Analysis". He/she can be changed by the service manager and the <u>Owner</u> him/herseilf.
The team may change during the ''[[Glossary|problem]] ''life cycle.
 
  
 
|-
 
|-
| <u>''Ownership and Groups''</u> || <u>Solution Group</u> || To define the team to which the'' [[Glossary|problem]]'' is assigned for analysis and/or resolution. ||This is set by the service manager and mandatory from the <u>Ticket Op Status </u>"Problem Assigned".
+
| <u>''Ticket Details''</u> || <u>Description</u> || To provide a more detailed description of the ''[[Glossary|change]]''. ||An auto tracking field is used enabling to view the ''[[Glossary|user]]'' who has updated.
The team may change during the'' [[Glossary|problem]]'' life cycle.
 
  
 
|-
 
|-
| <u>''Ownership and Groups''</u> || <u>Owner</u> || To define who is the ''[[Glossary|problem]]'' owner who should monitor the lifecycle of the ''[[Glossary|problem]]''. ||This is set by the service manager and mandatory from the <u>Ticket Op Status</u> "Problem Assigned". He/she can be changed by the service manager and the <u>Owner</u> him/herseilf.
+
| <u>''Ticket Details''</u> || <u>Analysis</u> || To provide a detailed analysis of the assessment of the ''[[Glossary|change]]''. ||An auto tracking field is used enabling to view the ''[[Glossary|user]] ''who has updated.
  
 
|-
 
|-
| <u>''Ownership and Groups''</u> || <u>Ticket Worker</u> || To set the ''[[Glossary|resource]]'' who shall work in order to analyse and/or resolve the ''[[Glossary|problem]]''. ||If the analysis is performed by the problem owner, the <u>Ticket Worker</u> is normally not set. He/she is a member of the team defined in the <u>Solution Group</u> field.However setting him/her is not mandatory. Alternatively, it is possible to assign specific tasks to ''[[Glossary|resources]]'' by using the <u>''Ticket Activities''</u> tab.
+
| <u>''Ticket Details''</u> || <u>Solution</u> || To describe the required implementation for the ''[[Glossary|change]]''. ||An auto tracking field is used enabling to view the ''[[Glossary|user]] ''who has updated.
  
 
|-
 
|-
| <u>''Ticket Details''</u> || <u>Description</u> || To provide a more detailed description of the ''[[Glossary|problem]]''. ||An auto tracking field is used enabling to view the ''[[Glossary|user]]'' who has updated.
+
| <u>''Ticket Details''</u> || <u>Comments</u> || To provide helpful comments. ||An auto tracking field is used enabling to view the ''[[Glossary|user]] ''who has updated.
  
|-
+
|}
| <u>''Ticket Details''</u> || <u>Analysis</u> || To provide the analysis of the cause(s) of the ''[[Glossary|problem]]''. ||This field is only visible to service desk and technical team members.
 
  
An auto tracking field is used enabling to view the ''[[Glossary|user]] ''who has updated.
+
Fields can be mandatory to save the ''[[Glossary|change]]'' in some [[Glossary|''workflow statuses'']]. These fields are highlighted with a red asterisk.
  
|-
+
== Views ==
| <u>''Ticket Details''</u> || <u>Solution</u> || To describe the solution applicable to the ''[[Glossary|problem]]''. ||This field is only visible to service desk and technical team members.
+
The following ''[[Glossary|views]]'' are made available in the ''<u>Tickets</u>'' area of the home page:
  
An auto tracking field is used enabling to view the ''[[Glossary|user]] ''who has updated.
+
{| class="wikitable"
 +
! View !! Content !! Requester !! Change owner !! Technical team !! Service manager !! Change authority
  
 
|-
 
|-
| <u>''Ticket Details''</u> || <u>Comments</u> || To provide comments helpful for the analysis and/or resolution of the ''[[Glossary|problem]]'' or for future memory (e.g. continual improvement).. ||This field is only visible to service desk and technical team members.
+
| Changes completed || ''[[Glossary|Changes]]'' in statuses "Completed", "In Review". || X ||  || || ||  
  
An auto tracking field is used enabling to view the ''[[Glossary|user]] ''who has updated.
+
|-
 +
| Changes requested || ''[[Glossary|Changes]]'' in status "Requested". ||  || 
 +
|| ||X ||
  
 
|-
 
|-
| <u>''Ticket Details''</u> || <u>Comments for Requester</u> || To provide comments to the requester of the ''[[Glossary|problem]]''. ||An auto tracking field is used enabling to view the ''[[Glossary|user]] ''who has updated.
+
| Changes owned || ''[[Glossary|Changes]] ''in all the statuses but "Opened", "Cancelled", "Aborted", "Closed" where <u>Owner</u> is the logged ''[[Glossary|resource]].'' ||  ||  X || || ||
  
This field is not the only way to interact with the requester. To this aim messages, manage via the <u>''Messages''</u> tab, can be very useful
+
|-
 +
| Changes routed to my team || ''[[Glossary|Changes]]'' in all the statuses but "Opened", "Cancelled", "Aborted", "Closed" where <u>Solution Group</u> is the ''[[Glossary|solution group]]'' to which the logged ''[[Glossary|resource]]'' belongs to.    ||  || || X || ||
  
|}
+
|-
 
+
| Changes assigned to me || ''[[Glossary|Changes]]'' in all the statuses but "Opened", "Cancelled", "Aborted", "Closed" where the <u>Ticket Worker</u> is the logged ''[[Glossary|resource]]''.    ||  ||
Fields can be mandatory to save the ''[[Glossary|incident]]'' in some [[Glossary|''workflow statuses'']]. These fields are highlighted with a red asterisk.
+
|| X || ||
 
 
== Views ==
 
The following ''[[Glossary|views]]'' are made available in the ''<u>Tickets</u>'' area of the home page:
 
 
 
{| class="wikitable"
 
! View !! Content !! Requester !! Problem owner !! Technical team !! Service manager
 
  
 
|-
 
|-
| Problems resolved || ''[[Glossary|Problems]]'' in statuses "Resolved", "Major Problem Review".  || X ||  || ||  
+
| Changes suspended || ''[[Glossary|Changes]]'' in status "Suspended".   || || X
 +
||  ||X ||
  
 
|-
 
|-
| Problems requested || ''[[Glossary|Problems]]'' in status "Requested". ||  ||
+
| Changes to review || ''[[Glossary|Changes]]'' in status "Completed" where <u>Change Type</u> is "Emergency" or where <u>Change Type</u> is "Normal" and <u>Change Category</u>" Significant"..    ||  || X
|| ||X
+
|| ||X ||
  
 
|-
 
|-
| Problems owned || ''[[Glossary|Problems]] ''in status "Problem Assigned", "Problem in Analysis", "Problem in Resolution", "Resolved" and "Major Problem Review" where <u>Owner</u> is the logged ''[[Glossary|resource]].'' ||  ||  X
+
| Changes to authorize for implementation || ''[[Glossary|Changes]]'' in status "Implementation Approval Requested".    ||  ||  ||  || ||X
|| ||
 
  
 
|-
 
|-
| Problems routed to my team || ''[[Glossary|Problems]]'' in status "Problem Assigned", "Problem in Analysis", "Problem in Resolution" where <u>Solution Group</u> is the ''[[Glossary|solution group]]'' to which the logged ''[[Glossary|resource]]'' belongs to.    ||  ||  
+
| Changes to authorize for deployment || ''[[Glossary|Changes]]'' in status "Deployment Approval Requested".    ||  ||  
|| X ||
+
|| || ||X
  
 
|-
 
|-
| Problems assigned to me || ''[[Glossary|Problems]]'' in status "Problem Assigned", "Problem in Analysis", "Problem in Resolution" where the <u>Ticket Worker</u> is the logged ''[[Glossary|resource]]''.    ||  ||  
+
| Changes evaluated by Change Authority || ''[[Glossary|Changes]]'' in status "Approved" or "Not Approved".    ||  || X
|| X ||
+
||  || X
 +
||
  
 
|-
 
|-
| Problems suspended || ''[[Glossary|Problems]]'' in status "Suspended".    ||  || X
+
| Changes approved for deployment || ''[[Glossary|Chnages]]'' in status "Deployment Approved".    ||  || X
||  ||X
+
||  || X
 +
||
  
|-
 
| Major problems to review || ''[[Glossary|Problems]]'' in status "Major Problem Review".    ||  || X
 
||  ||X
 
  
 
|}
 
|}
  
Additionally, the following ''[[Glossary|views]]'' are made available in the '''''Problem''''' menu for all the organizational roles:
+
Additionally, the following ''[[Glossary|views]]'' are made available in the '''''Change''''' menu for all the organizational roles:
  
 
{| class="wikitable"
 
{| class="wikitable"
Riga 434: Riga 539:
  
 
|-
 
|-
| Problems active || ''[[Glossary|Problems]]'' in status "Requested", "Problem Assigned", "Problem in Analysis", "Problem in Resolution", "Resolved" and "Major Problem Review".
+
| Changes active || ''[[Glossary|Changes]] ''in all the statuses but "Cancelled", "Aborted", "Suspended", "Closed"
  
 
|-
 
|-
| Problems suspended || ''[[Glossary|Problems]]'' in status "Suspended
+
| Changes suspended || ''[[Glossary|Changes]]'' in status "Suspended
  
 
|-
 
|-
| Problems closed || ''[[Glossary|Problems]]'' in status "Closed"
+
| Changes closed || ''[[Glossary|Changes]]'' in status "Closed"
  
 
|-
 
|-
| Problems cancelled || ''[[Glossary|Problems]]'' in status "Cancelled"
+
| Changes cancelled || ''[[Glossary|Changes]]'' in status "Cancelled"
  
 
|}
 
|}
Riga 453: Riga 558:
  
 
|-
 
|-
|A ''[[Glossary|problem]] ''is requested || Service manager || Alert that there is an ''[[Glossary|problem]]'' to assign for resolution.
+
|A ''[[Glossary|change]] ''is requested || Service manager || Alert that there is a ''[[Glossary|change]]'' to manage.
  
 
|-
 
|-
|A ''[[Glossary|problem]] ''is assigned a owner || Problem owner || Alert that the ''[[Glossary|problem]]'' was assigned to him/her.
+
|A ''[[Glossary|change]] ''is assigned a owner || Change owner || Alert that the ''[[Glossary|change]]'' was assigned to him/her.
  
 
|-
 
|-
|A ''[[Glossary|solution group]] ''is assigned or changed for the ''[[Glossary|problem]]'' || ''[[Glossary|Solution group manager]]'' || Alert that there are resource(s) to allocate to manage the ''[[Glossary|problem]]''.
+
|A ''[[Glossary|solution group]] ''is assigned or changed for the ''[[Glossary|change]]'' || ''[[Glossary|Solution group manager]]'' || Alert that there are resource(s) to allocate to manage the ''[[Glossary|change]]''.
  
 
|-
 
|-
|A ''[[Glossary|problem]] ''review shall be executed (the ''[[Glossary|problem]]'' is in ''[[Glossary|workflow status]]'' "Resolved" and the Major Problem field is set to "Yes") || Problem owner, service manager || Alert that a ''[[Glossary|problem]]'' review is to be done.
+
|A ''[[Glossary|change]] ''review shall be executed (the ''[[Glossary|change]]'' is in ''[[Glossary|workflow status]]'' "Change Review") || Change owner, service manager || Alert that a ''[[Glossary|change]]'' review is to be done.
  
 
|-
 
|-
|An ''[[Glossary|problem]] ''is resolved || The ''[[Glossary|problem]] ''creator, the requester || Alert that the ''[[Glossary|problem]] ''is resolved.
+
|A ''[[Glossary|change]] ''is completed || The ''[[Glossary|change]] ''creator, the requester || Alert that the ''[[Glossary|change]] ''is implemented.
  
 
|-
 
|-
Riga 471: Riga 576:
  
 
|-
 
|-
|A ''[[Glossary|problem]] ''is suspended || The ''[[Glossary|problem]] ''creator, the requester, the service manager, the problem owner || Alert that the ''[[Glossary|problem]] ''is suspended.
+
|A ''[[Glossary|change]] ''is suspended || The ''[[Glossary|change]] ''creator, the requester, the service manager, the change owner || Alert that the ''[[Glossary|change]] ''is suspended.
  
 
|-
 
|-
|An ''[[Glossary|problem ]]''is closed || The ''[[Glossary|problem]]''c reator, the requester, the service manager, the problem owner || Alert that the ''[[Glossary|problem]]'' has been closed.
+
|An ''[[Glossary|change ]]''is closed || The ''[[Glossary|change]] ''creator, the requester, the service manager, the change owner || Alert that the ''[[Glossary|change]]'' has been closed.
  
 
|-
 
|-
|An ''[[Glossary|incident]] ''is cancelled || The ''[[Glossary|problem]] ''creator, the requester, the service manager, the problem owner || Alert that the ''[[Glossary|problem]]'' has been cancelled.
+
|A ''[[Glossary|change]] ''is cancelled || The ''[[Glossary|change]] ''creator, the requester, the service manager, the change owner || Alert that the ''[[Glossary|change]]'' has been cancelled.
 +
 
 +
|-
 +
|A ''[[Glossary|change]] ''implementation approval has been requested || Change authority || Alert that a ''[[Glossary|change]]'' implementation request has to be examined.
 +
 
 +
|-
 +
|A ''[[Glossary|change]] ''implementation approval request has been examined || Change owner, service manager || Alert that the change authority has given a feedback on a ''[[Glossary|change]]'' implementation request.
 +
 
 +
|-
 +
|A ''[[Glossary|change]] ''deployment approval has been requested || Change authority || Alert that a ''[[Glossary|change]]'' deployment request has to be examined.
 +
 
 +
|-
 +
|A ''[[Glossary|change]] ''deployment approval request has been examined || Change owner, service manager || Alert that the change authority has given a feedback on a ''[[Glossary|change]]'' deployment request.
  
 
|}
 
|}
  
 
== Reporting ==
 
== Reporting ==
A set of standard reports are made available for the ''[[Glossary|problem 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 '''''Problem/Reporting''''' menu.
+
A set of standard reports are made available for the ''[[Glossary|change 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 '''''Change/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 490: Riga 607:
  
 
|-
 
|-
|Problem per priority - trend || An histogram showing the ''[[Glossary|problem]]'' volumes per priority monthly trend. || Service managers and technical team members.
+
|Change per category - trend || An histogram showing the ''[[Glossary|change]]'' volumes per category monthly trend. || Service managers and technical team members.
  
 
|-
 
|-
|Problem per priority - volume || A pie containing the split of ''[[Glossary|problems]]'' per priority. || Service managers and technical team members.
+
|Change per category - volume || A pie containing the split of ''[[Glossary|changes]]'' per category. || Service managers and technical team members.
  
 
|-
 
|-
|Problem per service - trend || An histogram showing the ''[[Glossary|problem]] ''volumes per ''[[Glossary|service]]'' monthly trend. || Service managers and technical team members.
+
|Change per service - trend || An histogram showing the ''[[Glossary|change]] ''volumes per ''[[Glossary|service]]'' monthly trend. || Service managers and technical team members.
  
 
|-
 
|-
|Problem per service - volume || A pie containing the split of ''[[Glossary|problems]] ''per ''[[Glossary|service]]''. || Service managers and technical team members.
+
|Change per service - volume || A pie containing the split of ''[[Glossary|changes]] ''per ''[[Glossary|service]]''. || Service managers and technical team members.
  
 
|-
 
|-
|Problem per service/priority - volume || An histogram showing the ''[[Glossary|incidents]]'' volume per ''[[Glossary|service]]'' and priority. || Service managers and technical team members.
+
|Change per service/category - volume || An histogram showing the ''[[Glossary|changes]]'' volume per ''[[Glossary|service]]'' and category. || Service managers and technical team members.
  
 
|-
 
|-
|Problem - assign time || A pie showing the percentage of ''[[Glossary|problems]] ''respecting the target defined for the take "assign time"* ''[[Glossary|objective]]'' (the time elapsed from the "Requested" to the "Problem Assigned" ''[[Glossary|workflow status]]''. || Service managers and technical team members.
+
|Change - analysis time || A pie showing the percentage of ''[[Glossary|changes]] ''respecting the target defined for the "Analysis time"* ''[[Glossary|objective]]'' (the time elapsed from the "Requested" to the "In Analysis" ''[[Glossary|workflow status]]''. || Service managers and technical team members.
 
 
|-
 
|Problem per priority - resolution time || An histogram showing, per priority, the percentage of ''[[Glossary|problems]]'' respecting the target defined for the "Resolution time"* ''[[Glossary|objective]]'' (the time elapsed from the "Problem Assigned" to the "Resolved" ''[[Glossary|workflow status]]''. || Service managers and technical team members.
 
  
 
|}
 
|}
<nowiki>*</nowiki> "Assign time" and "Resolution time" [[Glossary|objectives]] are defined within the ''[[Glossary|OCE]]'' ''[[Glossary|module]]''.
+
<nowiki>*</nowiki> "Analysis time" is defined within the ''[[Glossary|OCE]]'' ''[[Glossary|module]]''.
  
A basic form of reporting is also provided by ''[[Glossary|views]]. ''Views basically allow to list ''[[Glossary|problems]]'' 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]]. ''Views basically allow to list ''[[Glossary|changes]]'' 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|problem management]]'' process are given.
+
In this section some examples of use of the configured'' [[Glossary|change management]]'' process are given.
  
If you get lost, any time use the '''EXPLORE WORKFLOW''' command of the ''[[Glossary|problem]]'' 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|change]]'' 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 524: Riga 638:
 
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 and request a new ''[[Glossary|problem]] ''as a technical team member ===
+
=== Create and request a new ''[[Glossary|change]] ''as a final user ===
# Login as "appspecialist" ''[[Glossary|user]]''
+
# Login as "finaluser" ''[[Glossary|user]]''
# Activate the '''''Self Service''''' menu
+
# Activate the '''''Self Service''''' menu
# Choose a ''[[Glossary|self service topic]]'', ''[[Glossary|self service category]]'' and finally "Problem" as ''self service request ''(this determines the creation of a new ''[[Glossary|problem]]'')
+
# Choose ''[[Glossary|self service topic]]'', ''[[Glossary|self service category]]'' and finally "Change" as ''[[Glossary|self service request]] ''(this determines the creation of a new ''[[Glossary|change]]'')
#Fill the ''[[Glossary|problem]]'' form, at least with mandatory form and save with the '''SAVE''' command
+
# Fill the ''[[Glossary|change]]'' form, at least with mandatory fields, and save with the '''SAVE''' command (the ''[[Glossary|change]]'' is now in ''[[Glossary|workflow status]]'' "Opened")
You have now saved the ''[[Glossary|problem]]'', take note of the ''[[Glossary|ticket]]'' number for further reference or use.
+
# Set the ''[[Glossary|change]]'' in ''[[Glossary|workflow status]]'' "Requested" with the '''SAVE & NEXT''' command
 +
You have now saved the ''[[Glossary|change]]'', take note of the ''[[Glossary|ticket]]'' number for further reference and use.
  
=== Assign a ''[[Glossary|problem]]'' for resolution as a service manager ===
+
=== Assign a ''[[Glossary|change]]'' for analysis as a service manager ===
 
#Login as "servicemanager"
 
#Login as "servicemanager"
# Open the the desired ''[[Glossary|problem]]''; you can do it quickly either by
+
# Open the the desired ''[[Glossary|change]]''; you can do it quickly either by
#* Access the "Problems Requested" ''[[Glossary|view]]'' in the ''<u>Tickets</u>'' area of the home page and pick a ''[[Glossary|problem]]''  
+
#* Access the "Changes Requested" ''[[Glossary|view]]'' in the ''<u>Tickets</u>'' area of the home page and pick a ''[[Glossary|change]] ''  
#* Access the '''''Problem/Problems active '''''menu and pick a ''[[Glossary|problem]] ''in'' [[Glossary|workflow status]] ''"Requested"'' ''among those listed
+
#* Access the '''''Change/Changes active '''''menu and pick a ''[[Glossary|chanve]] ''in'' [[Glossary|workflow status]] ''"Requested"'' ''among those listed
#* Insert the reference number of a ''[[Glossary|problem]]'' in ''[[Glossary|workflow status]]'' "Requested" in '''Quick Search''', after selecting the ''[[Glossary|search context]]'' "Ticket"
+
#* Insert the reference number of a ''[[Glossary|change]]'' in ''[[Glossary|workflow status]]'' "Requested" in '''Quick Search''', after selecting the ''[[Glossary|search context]]'' "Ticket"
 
# Assign the key roles  
 
# Assign the key roles  
#* Fill the ''[[Glossary|problem]] ''form with <u>Owner</u>, <u>Solution Group</u> and, may be, <u>Master Solution Group</u>, <u>Ticket Worker</u>,  
+
#* Fill the ''[[Glossary|change]] ''form with <u>Owner</u>, <u>Solution Group</u> and, may be, <u>Master Solution Group</u>, <u>Ticket Worker</u>,  
 
#*  Pressing the '''SAVE & NEXT''' command, choose the "1. Assign ticket" ''[[Glossary|workflow transition]] ''
 
#*  Pressing the '''SAVE & NEXT''' command, choose the "1. Assign ticket" ''[[Glossary|workflow transition]] ''
The ''[[Glossary|problem]]'' is now in ''[[Glossary|workflow status]]'' "Problem Assigned".
+
The ''[[Glossary|change]]'' is now in ''[[Glossary|workflow status]]'' "In Analysis".
 +
 
 +
=== Perform analysis and request ''[[Glossary|change]] ''implementation authorization as a change owner ===
 +
# Login as a ''[[Glossary|user]] ''owning a ''[[Glossary|change]] ''(see assign a ''[[Glossary|change]] ''for analysis as a service manager described previously)
 +
# Open the desired ''[[Glossary|change]]''; you can do it quickly either by ................................................... TO BE CONTINUED
 +
#* Access the ''[[Glossary|views]]''in the''Tickets''area of the home page and pick a''[[Glossary|problem]]''among those listed in''[[Glossary|workflow status]]''"Problem Assigned", "Problem in Analysis", "Problem in Resolution" where the''[[Glossary|user]]''is owner
 +
#* Access the'''''Problem/Problems active'''''menu and pick a''[[Glossary|problem]]''among those listed in''[[Glossary|workflow status]]''"Problem Assigned", "Problem in Analysis", "Problem in Resolution" where the''[[Glossary|user]]''is owner
 +
#* Insert the reference number of a''[[Glossary|problem]]''in''[[Glossary|workflow status]]''"Problem Assigned", "Problem in Analysis", "Problem in Resolution" where the''[[Glossary|user]]''is owner in'''Quick Search''', after selecting the''[[Glossary|search context]]''" Ticket"
 +
# Update some fields (e.g.AnalysisorSolution)
 +
# Pressing the'''SAVE & NEXT'''command, choose a transition to update the''[[Glossary|workflow status]]''
 +
 
 +
=== Authorize ''[[Glossary|change]]'' implementation as change authority ===
  
=== Monitor and control a ''[[Glossary|problem]] ''as problem owner ===
+
=== Monitor and control a ''[[Glossary|change]] ''as change owner ===
 
# Login as a ''[[Glossary|user]]'' owning a ''[[Glossary|problem]]'' (see assign a ''[[Glossary|problem]]'' for resolution as a service manager described previously)
 
# Login as a ''[[Glossary|user]]'' owning a ''[[Glossary|problem]]'' (see assign a ''[[Glossary|problem]]'' for resolution as a service manager described previously)
 
# Open the desired ''[[Glossary|problem]]''; you can do it quickly either by
 
# Open the desired ''[[Glossary|problem]]''; you can do it quickly either by
Riga 550: Riga 676:
 
# Update some fields (e.g. <u>Analysis</u> or <u>Solution</u>)
 
# Update some fields (e.g. <u>Analysis</u> or <u>Solution</u>)
 
# Pressing the '''SAVE & NEXT '''command, choose a transition to update the ''[[Glossary|workflow status]]''
 
# Pressing the '''SAVE & NEXT '''command, choose a transition to update the ''[[Glossary|workflow status]]''
=== Analyse and resolve a [[Glossary|problem]] as a technical team member ===
+
=== Implement a [[Glossary|change]] as a technical team member ===
 
# Login as a technical team member working on the ''[[Glossary|problem]]''  ([[Incident Management|<nowiki/>]]<nowiki/>see assign a ''[[Glossary|problem]]'' for resolution described previously)
 
# Login as a technical team member working on the ''[[Glossary|problem]]''  ([[Incident Management|<nowiki/>]]<nowiki/>see assign a ''[[Glossary|problem]]'' for resolution described previously)
 
# Open a ''[[Glossary|problem]] ''in status'' ''"Problem in Analysis"; you can do it quickly either by
 
# Open a ''[[Glossary|problem]] ''in status'' ''"Problem in Analysis"; you can do it quickly either by
Riga 559: Riga 685:
 
# Save the problem by pressing '''SAVE''' command
 
# Save the problem by pressing '''SAVE''' command
 
# Send a message to the problem owner to notice the progress you made (use the tab <u>''Messages''</u> of the ''[[Glossary|ticket]]'').
 
# Send a message to the problem owner to notice the progress you made (use the tab <u>''Messages''</u> of the ''[[Glossary|ticket]]'').
=== Perform a major ''[[Glossary|problem]]'' review as a service manager ===
+
 
 +
=== Request ''[[Glossary|change]]'' deployment as a change owner ===
 +
 
 +
=== Authorize ''[[Glossary|change]]'' deployment as change authority ===
 +
 
 +
=== Perform a ''[[Glossary|change ]]''review as a service manager ===
 
# Login as "servicemanager"
 
# Login as "servicemanager"
 
# Open the the desired ''[[Glossary|problem]]''; you can do it quickly either by
 
# Open the the desired ''[[Glossary|problem]]''; you can do it quickly either by
Riga 569: Riga 700:
 
The ''[[Glossary|problem]]'' is now in workflow status "Closed".
 
The ''[[Glossary|problem]]'' is now in workflow status "Closed".
  
=== Close a ''[[Glossary|problem]]'' as a problem owner ===
+
=== Close a ''[[Glossary|change]]'' as a change owner ===
 
# Login as a ''[[Glossary|user]] ''owning a ''[[Glossary|problem]] ''(see assign a ''[[Glossary|problem]] ''for resolution as a service manager described previously) which is not major
 
# Login as a ''[[Glossary|user]] ''owning a ''[[Glossary|problem]] ''(see assign a ''[[Glossary|problem]] ''for resolution as a service manager described previously) which is not major
 
# Open the the desired ''[[Glossary|problem]] ''(one which is not major); you can do it quickly either by
 
# Open the the desired ''[[Glossary|problem]] ''(one which is not major); you can do it quickly either by

Versione attuale delle 11:20, 18 lug 2015

Change Management process is supported by a SM workflow cartridge that enables the execution of the process according to the ITIL and ISO/IEC 20000 guidelines.

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 change 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 effective and efficient execution of changes. At the core of the process configuration is the following operational model.

Change Management operational model

The requester, an authorized client, service manager, member of the service desk or technical team or n related process (such as Incident Management or Problem Management) requires to open a Request for Change (RfC). The service manager takes in charge it and assigns an owner who coordinates all the tasks needed to fulfil the change. The owner requests the change authorization to the change authority, if needed. As appropriate, technical team members may directly implement and deploy the change or make it through the Release Management process and later the Depolyment Change.

Roles

For this process, the following organizational roles are defined:

Organizational role Description itmSUITE® role mapping
Requester This role is mapped on:
  • a system resource with user of user type "Requester". The login identifier of this user is "FinalUser";
  • service manager (see after);
  • service desk members (system resources with user of user type "Resource"; the login identifier of this user is "SDSpecialist";
  • technical team members (see after).
Change owner
  • Requires change approval to the change authority after its assessment is completed
  • Assign tasks to be performed to complete the change
  • Watches over and monitors the change along all its life cycle ensuring target service levels are achieved
  • Activates escalation/ routing/ requests
  • Manages all the communications with the requester
  • Checks the implementation and sets the change to to completed
  • Closes the change after completing the final checks
Role assigned by the service manager to himself/herself or to a technical team member.
Technical team member
  • He/she receives the notification on the assignment of an activity concerning a change (e.g. conducting the assessment or designing/implementing it)
  • Carries out the assigned tasks
  • Notices when completed or unable to complete
There are several technical teams predefined for different domains. The following table shows which users are members of each team.
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"

Technical team manager
  • Receives the notification about the assignment of the change to his/her team in order to implement it
  • Assign the member of his/her team who should work on it (this can be done by setting the ticket worker or creating and assigning ticket activities)
  • Watches over and monitors the work of his/her team
There are several technical teams predefined for different domains. The following table shows which users are set as solution group manager for each domain.
Domain Group Group manager
Application management "Application Management" User "AppManager".
Personal devices management "Personal Management" User "Personal Manager".
Network management "Network Management" User "NetManager".
Server management "Server Management" User "ServerManager".
Service manager
  • Takes in charge and assigns the change owner
  • Monitors how the changes are evolving for the service(s) he/she is responsible for
This role is mapped on a system resource with user of user type "Project/Service Manager". There are different service managers configured for specific services. See Services section in this page for further information.
Change authority
  • Approves the change implementation
  • Approves the change deployment
This role is mapped based on the required authorization and change classification.

For change implementation authorization:

Change Type Change Category Change authority
"Emergency" Service manager
"Normal" "Minor" Service manager
"Normal" "Significant" CAB
"Standard" Change owner

The CAB is mapped on a group: "CAB".

For change deployment authorization:

Change Type Change Category Change authority
"Emergency" Service manager
"Normal" "Minor" Change owner
"Normal" "Significant" Service manager
"Standard" Change owner

Process

As for all workflows, new changes 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 change 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" "Change" (open a change) Requesters
"Personal Devices" "Personal Computers" "Change" (open a change) Requesters
"Personal Devices" "Peripherals" "Change" (open a change) Requesters
"Personal Devices" "Telephony" "Change" (open a change) Requesters
"Network" "Networking Management" "Change" (open a change) Requesters
"Technical Services" "Server Management" "Change" (open a change) Requesters

A change may also be automatically opened during the execution of other processes by the resources dealing with them.

A workflow is configured to support the change management process. The workflow is characterized by workflow statuses and workflow transitions. The figures below illustrate the process.

Change management process (1 of 3).
Change management process (2 of 3).
Change management process (3 of 3).

The table below explains the meaning of each workflow status.

Workflow status Description
"Default" A preliminary status which is displayed when a change is created.
"Opened" The change has been recorded.
"Requested" The change is confirmed and has been requested (it is a request for change).
"In Analysis" The change assessment and planning is ongoing.
"Implementation Approval Requested" The change approval request for implementation is submitted to the change authority.
"Approved" The change is approved for implementation.
"Not Approved" The change is not approved for implementation.
"In Progress" The change implementation is ongoing.
"Ready for Test" The change is ready for testing.
"In Test" The change testing is ongoing.
"Deployment Approval Requested" The change approval request for deployment is submitted to the change authority.
"Deployment Approved" The change is approved for deployment.
"Completed" The change is completed.
"Change Review" The change review is ongoing.
"Cancelled" The change is not confirmed and, therefore, cancelled.
"Suspended" The change execution is temporarily suspended. In this status service levels calculation are suspended too.
"Aborted" The change execution is aborted.
"Closed" The change closure has been confirmed.

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

Source status Destination status Authorized executors Comment
"Default" "Opened" Requesters See the self service portal configuration previously described.
"Opened" "Requested" Requester, service manager.


"Opened" "Cancelled" Requester, service manager.
"Requested" "Opened" Requester, service manager..
"Requested" "Cancelled" Requester, service manager, chabge owner.
"Requested" "In Analysis" Service manager, change owner.
"Deployment Approved" "Aborted" Service manager, change owner.
"In Analysis" "Requested" Service manager, change owner.
"In Analysis" "Approval Requested" Service manager, change owner.
"In Analysis" "Cancelled" Service manager, change owner.


"Approval Requested" "Approved" Change authority. Depending on change classification (see roles for more details).
"Approval Requested" "Not Approved" Change authority. Depending on change classification (see roles for more details).
"Approval Requested" "In Analysis" Service manager, change owner.
"Not Approved" "Cancelled" Service manager, change owner.
"Approved" "In Progress" Service manager, change owner, technical team member.
"Approved" "Suspended" Service manager, change owner.


"Approved" "Aborted" Service manager, change owner.
"Suspended" "In Progress" Service manager, change owner.
"In progress" "Suspended" Service manager, change owner.
"In progress" "Aborted" Service manager, change owner.
"In progress" "Ready for Test" Service manager, change owner, technical team member
"In progress" "In Test" Service manager, change owner, technical team member.
"In progress" "Deployment Approval Requested" Service manager, change owner.
"In progress" "Completed" Service manager, change owner. Only for changes with Change Type "Standard" or with Change Type "Normal" and Change Category "Minor".
"Ready for Test" "In Test" Service manager, change owner, technical team member.
"Ready for Test" "Suspended" Service manager, change owner.
"Ready for Test" "Aborted" Service manager, change owner.
"In Test" "Deployment Approval Requested" Service manager, change owner.
"In Test" "Suspended" Service manager, change owner.
"In Test" "Aborted" Service manager, change owner.
"Deployment Approval Requested" "Deployment Approved" Change authority.
"Deployment Approval Requested" "Suspended" Service manager, change owner.
"Deployment Approval Requested" "Aborted" Service manager, change owner.
"Deployment Approved" "Completed" Service manager, change owner.


"Completed" "Change Review" Service manager, change owner.
"Completed" "Closed" Service manager, change owner. Not allowed for changes with Change Type "Emergency" and Change Type "Normal" and Change Category "Significant"
"Change review" "Closed" Service manager, change owner.
"Not Approved" "In Analysis" Service manager, change owner.

Related processes

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

Incident management

It is possible to create a change from the incident management process or to relate an existing change to an incident and vice versa.The change usually implements the resolution of an incident.

Problem management

It is possible to create a change from the problem management process or to relate an existing change to a problem and vice versa.The change usually implements the resolution of a problem.

Asset management and configuration management

It is possible to relate configuration items to a change 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).

Release and deployment management

A release may include one or more changes. The relationship between a release and and change can be created from the change but is is more frequently created working from the release. In any case, the relation from the change can be created from the tickets tab Related Items and, in particular, the sub tab Configuration Items by using the ADD EXISTING or SELF SERVICE commands.

Services

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

Incidents 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 change 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 change, 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 change. Always visible.
General Information Requester To identify the name of the requester (who has requested the change). A list is presented, influenced by.... TBC
General Information Creation Date To show the date and time the change 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 change 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 change. 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 change last. This information is automatically recorded and cannot be manually changed. See History tab for more detailed tracking information.
Ticket Classification Project/Service To show the service (or project) to which the change is related. This is automatically set at open time and can't be modified.
Ticket Classification Ticket Type To show the type of workflow executed. This is automatically set at open time and can't be modified.
Ticket Classification Chage Area Change Objective Change Type Change Category To set the change key classification information.This is used for statistic reasons but the Change Category may also be configured to drive the change authorization. Change Area, Change Objective and Change Type are independent fields. Change Category is available only if Change Type is set to "Normal": In such a case, its value is influenced by the change assessment fields (see below). The classification information initially provided can be changed.
Ticket Classification Change Scope To set the change scope.This is typically used for statistic reasons. The classification information initially provided can be changed.
Ticket Classification Service impact Capacity impact Security impact Cost estimation Performance impact These fields are the change assessment elements. The values given will influence the Change Category value. The classification information initially provided (number and content of fields) as well as the rules to influence the Change Category can be changed.
Prioritisation & Planning Required Solution Date To provide the date of change implementation required by the Requester.
Prioritisation & Planning User Priority To provide the priority given to the change by the Requester. A four level scale is set but it can be changed.
Prioritisation & Planning Forecasted Solution Date To provide the date of change implementation forecasted.
Prioritisation & Planning Forecasted Solution Date To set the forecasted resolution date and time for the change.
Ownership and Groups Master SG To define the supervising team. This is set by the service manager and mandatory from the Ticket Op Status "In Analysis".
Ownership and Groups Solution Group To define the team to which the change is assigned for analysis and/or implementation. This is set by the service manager and mandatory from the Ticket Op Status "Approval Requested".
Ownership and Groups Owner To define who is the change owner who should monitor the lifecycle of the change. This is set by the service manager and mandatory from the Ticket Op Status "In Analysis". He/she can be changed by the service manager and the Owner him/herseilf.
Ticket Details Description To provide a more detailed description of the change. An auto tracking field is used enabling to view the user who has updated.
Ticket Details Analysis To provide a detailed analysis of the assessment of the change. An auto tracking field is used enabling to view the user who has updated.
Ticket Details Solution To describe the required implementation for the change. An auto tracking field is used enabling to view the user who has updated.
Ticket Details Comments To provide helpful comments. An auto tracking field is used enabling to view the user who has updated.

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

Views

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

View Content Requester Change owner Technical team Service manager Change authority
Changes completed Changes in statuses "Completed", "In Review". X
Changes requested Changes in status "Requested". X
Changes owned Changes in all the statuses but "Opened", "Cancelled", "Aborted", "Closed" where Owner is the logged resource. X
Changes routed to my team Changes in all the statuses but "Opened", "Cancelled", "Aborted", "Closed" where Solution Group is the solution group to which the logged resource belongs to. X
Changes assigned to me Changes in all the statuses but "Opened", "Cancelled", "Aborted", "Closed" where the Ticket Worker is the logged resource. X
Changes suspended Changes in status "Suspended". X X
Changes to review Changes in status "Completed" where Change Type is "Emergency" or where Change Type is "Normal" and Change Category" Significant".. X X
Changes to authorize for implementation Changes in status "Implementation Approval Requested". X
Changes to authorize for deployment Changes in status "Deployment Approval Requested". X
Changes evaluated by Change Authority Changes in status "Approved" or "Not Approved". X X
Changes approved for deployment Chnages in status "Deployment Approved". X X


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

View Content
Changes active Changes in all the statuses but "Cancelled", "Aborted", "Suspended", "Closed"
Changes suspended Changes in status "Suspended
Changes closed Changes in status "Closed"
Changes cancelled Changes in status "Cancelled"

Notifications

The following notifications are configured:

Trigger Recipients Purpose
A change is requested Service manager Alert that there is a change to manage.
A change is assigned a owner Change owner Alert that the change was assigned to him/her.
A solution group is assigned or changed for the change Solution group manager Alert that there are resource(s) to allocate to manage the change.
A change review shall be executed (the change is in workflow status "Change Review") Change owner, service manager Alert that a change review is to be done.
A change is completed The change creator, the requester Alert that the change is implemented.
A ticket worker is assigned The assigned ticket worker Alert that there is work to be done.
A change is suspended The change creator, the requester, the service manager, the change owner Alert that the change is suspended.
An change is closed The change creator, the requester, the service manager, the change owner Alert that the change has been closed.
A change is cancelled The change creator, the requester, the service manager, the change owner Alert that the change has been cancelled.
A change implementation approval has been requested Change authority Alert that a change implementation request has to be examined.
A change implementation approval request has been examined Change owner, service manager Alert that the change authority has given a feedback on a change implementation request.
A change deployment approval has been requested Change authority Alert that a change deployment request has to be examined.
A change deployment approval request has been examined Change owner, service manager Alert that the change authority has given a feedback on a change deployment request.

Reporting

A set of standard reports are made available for the change 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 Change/Reporting menu.

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

Report name Content Access
Change per category - trend An histogram showing the change volumes per category monthly trend. Service managers and technical team members.
Change per category - volume A pie containing the split of changes per category. Service managers and technical team members.
Change per service - trend An histogram showing the change volumes per service monthly trend. Service managers and technical team members.
Change per service - volume A pie containing the split of changes per service. Service managers and technical team members.
Change per service/category - volume An histogram showing the changes volume per service and category. Service managers and technical team members.
Change - analysis time A pie showing the percentage of changes respecting the target defined for the "Analysis time"* objective (the time elapsed from the "Requested" to the "In Analysis" workflow status. Service managers and technical team members.

* "Analysis time" is defined within the OCE module.

A basic form of reporting is also provided by views. Views basically allow to list changes 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 change management process are given.

If you get lost, any time use the EXPLORE WORKFLOW command of the change 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 and request a new change as a final user

  1. Login as "finaluser" user
  2. Activate the Self Service menu
  3. Choose a self service topicself service category and finally "Change" as self service request (this determines the creation of a new change)
  4. Fill the change form, at least with mandatory fields, and save with the SAVE command (the change is now in workflow status "Opened")
  5. Set the change in workflow status "Requested" with the SAVE & NEXT command

You have now saved the change, take note of the ticket number for further reference and use.

Assign a change for analysis as a service manager

  1. Login as "servicemanager"
  2. Open the the desired change; you can do it quickly either by
  3. Assign the key roles
    • Fill the change form with Owner, Solution Group and, may be, Master Solution Group, Ticket Worker,
    • Pressing the SAVE & NEXT command, choose the "1. Assign ticket" workflow transition

The change is now in workflow status "In Analysis".

Perform analysis and request change implementation authorization as a change owner

  1. Login as a user owning a change (see assign a change for analysis as a service manager described previously)
  2. Open the desired change; you can do it quickly either by ................................................... TO BE CONTINUED
    • Access the viewsin theTicketsarea of the home page and pick aproblemamong those listed inworkflow status"Problem Assigned", "Problem in Analysis", "Problem in Resolution" where theuseris owner
    • Access theProblem/Problems activemenu and pick aproblemamong those listed inworkflow status"Problem Assigned", "Problem in Analysis", "Problem in Resolution" where theuseris owner
    • Insert the reference number of aprobleminworkflow status"Problem Assigned", "Problem in Analysis", "Problem in Resolution" where theuseris owner inQuick Search, after selecting thesearch context" Ticket"
  3. Update some fields (e.g.AnalysisorSolution)
  4. Pressing theSAVE & NEXTcommand, choose a transition to update theworkflow status

Authorize change implementation as change authority

Monitor and control a change as change owner

  1. Login as a user owning a problem (see assign a problem for resolution as a service manager described previously)
  2. Open the desired problem; you can do it quickly either by
    • Access the views in the Tickets area of the home page and pick a problem among those listed in workflow status "Problem Assigned", "Problem in Analysis", "Problem in Resolution" where the user is owner
    • Access the Problem/Problems active menu and pick a problem among those listed in workflow status "Problem Assigned", "Problem in Analysis", "Problem in Resolution" where the user is owner
    • Insert the reference number of a problem in workflow status "Problem Assigned", "Problem in Analysis", "Problem in Resolution" where the user is owner in Quick Search, after selecting the search context" Ticket"
  3. Update some fields (e.g. Analysis or Solution)
  4. Pressing the SAVE & NEXT command, choose a transition to update the workflow status

Implement a change as a technical team member

  1. Login as a technical team member working on the problem (see assign a problem for resolution described previously)
  2. Open a problem in status "Problem in Analysis"; you can do it quickly either by
  3. Optionally update problem information (for example Analysis and Solution fields)
  4. Save the problem by pressing SAVE command
  5. Send a message to the problem owner to notice the progress you made (use the tab Messages of the ticket).

Request change deployment as a change owner

Authorize change deployment as change authority

Perform a change review as a service manager

  1. Login as "servicemanager"
  2. Open the the desired problem; you can do it quickly either by
    • Access the view "Major Problem to Review"in the Tickets window of the home page and pick a problem
    • Access the Problem/Problems active menu and pick a Problem among those listed in workflow status "Major Problem Review"
    • Insert the reference number of a problem in workflow status "Major Problem Review" in Quick Search, after selecting the search context "Ticket"
  3. Update some fields (e.g. Comments, or add a review report as attachment)
  4. Pressing the SAVE & NEXT command, choose the "1. Close" workflow transition

The problem is now in workflow status "Closed".

Close a change as a change owner

  1. Login as a user owning a problem (see assign a problem for resolution as a service manager described previously) which is not major
  2. Open the the desired problem (one which is not major); you can do it quickly either by
    • Access the "Problems resolved" view in the Tickets area of the home page and pick a problem among those listed where the user is owner
    • Insert the reference number of an problem in workflow status "Resolved" where the user is owner in Quick Search, after selecting the search context "Ticket"
  3. Close the problem by

The problem is now in workflow status "Closed".