Change Management

Change management in IT is an essential process to ensure that modifications to the technological infrastructure, software, processes and information systems are planned, controlled and executed in a structured manner. Its main objective is to minimize risks and negative impacts on the organization's services.

With this section, in Pandora ITSM you may manage all the changes of the organization with the power that tasks and tickets give and where change teams will be able to intervene in it.

• Standard Change: Pre-authorized, low-risk changes (such as a server reboot).
• Normal Change: Scheduled changes that require approval (e.g. software upgrade).
• Emergency Change: Critical changes that must be immediately implemented (e.g., applying a security patch).

• Change Initiator: The person who proposes a change.
• Change Manager: Responsible for overseeing the change and its impact. Usually the Manager of the assigned Team.
• Change Team: Group in charge of implementing the approved changes.

Any user with access to Changes may propose a change by submitting a Change Request.

The user will be able to configure the following elements when creating the change:

• Name (required).
• Change template.
• Change status: At creation, this field is disabled and is automatically set to the initial state (New).
• Change equipment (required).
• Change type.
• Priority.
• Risk level.
• Impact.
• Administrator (required).

A change request will look similar to:

Inventory items or attachments may be assigned as needed to the Change. The inventory items correspond to the items affected in the change and new inventory items may be added in the future as they are considered.

The same applies to attachments:

For correct change follow-up, notes that will not count time in the resolution of the change may be added.

The tracking of each of the changes made to the Change will be displayed on the Tracker section.

The Change Manager will be in charge of approving that the change can be carried out.

The change may be approved by indicating a brief assessment of why the change is approved.

There is also the option to deny the change. If this is the case, the change is closed immediately.

Once the Change is approved, the status of the Change will change to Scheduled. The Tasks and subtasks that need to be performed for the requested change may be configured.

In task generation, you may define a name, Manager, Team, Start/End, estimated hours, whether it has a parent task or not, the description and priority, the risk and the task impact.

If there is a task parent, it is displayed as follows:

You may in turn open tickets to complete these tasks. The hours computed in the tickets will be added to the tasks.

To associate the ticket to the task, it must be done from the advanced options of the ticket:

Once associated, it will be displayed in the associated tickets section within the Change:

The times computed on the ticket, will be counted as time to complete the task.

The progress of the task will be completed when the Manager of each of the tasks checks as each of them as Completed status. Within the tasks and the tickets associated to the tasks, the time spent on the tasks will be computed through Workunits.

The sum of these times will be counted over the total estimated time in each task and at the end of the task, the Manager will edit the task to Completed status, having reached or exceeded the estimated time, to display its 100 %.

Once all tasks are in Completed status, the Change goes to Review status.

When the Change status is Review, it means that all tasks are completed and pending validation. To do so, the Task Manager may validate the tasks by changing their status to Verified.

If all tasks are Verified, the Approve Change option will appear in the Closure Information tab.

At that time the Change Manager may close the Change by indicating an epilogue.

You may have different Change templates preconfigured so that when requesting a change, if it is related to one of the templates, the following parameters (except for the Name and Description fields) are configured in the default change:

Change Templates may be created from the Changes → Management → Templates section. Once created, they will appear as an option in the Templates field when generating a new change.

The following Exchange Statuses are available by default:

You can edit their names from the Changes → Management → Statuses section without changing their order. The statuses are defined by the following conditions:

• New: Status just opened, pending Authorization by the Change Manager.
• Authorized: Status that has been authorized by the Change Manager, but has no Task generated yet. If it is denied, it will move to the last status in this list.
• Scheduled: Scheduled status, you have all your tasks pending and unstarted.
• Implement: As soon as one of the tasks is started, it will automatically switch to this state.
• Review: All tasks are completed and the status is pending review.
• Closed: Change completed and closed. It may be because it has been deauthorized or because it has been successfully completed after going through the whole process and all pending tasks have been validated.

Previously described: Standard, Normal, Emergency. From the Changes → Management → Types menu, their names can be edited.

As a specific performance, the Standard type is pre-authorized and when selected, instead, it will change to Authorized status. It is important for this type to only be configured from pre-authorized template.

By default there are three types of each: Low, Medium and High. Clicking on their names will allow you to edit their names and characteristic colors.

By default the following states:

You may edit their names without changing their order. Pending is the state in which the task has not yet started to be performed, In process when it is started, Completed when it is finished and Verified when once the Manager makes sure that it has been performed correctly and completed in its entirety.

Until all tasks assigned to the Change are in Verified status, the change cannot be Validated and Closed.

These are the user groups that will be in charge of managing a change. Within the Team of the change, there must be a Manager (which in most cases will match the Change Manager that has been assigned to the Team).

Within the Change → Teams section, you will be able to create all Teams necessary to manage all Change requests. They will have associated changes and change tasks. They will be used to manage their ACL.

With the exception of the description field, the other fields are mandatory. Among them, the Email field should be highlighted, where normally a group mailbox will be defined so that the whole team will receive the change notifications when they are generated.

Team users may be added and/or edited by clicking on the Add users icon. The selected Manager will automatically appear within this view and will be the only fixed user of the team.

In the Setup → Setup → Changes setup menu , you may define the notifications to be received when changes take place in the Change section:

In the Setup → Setup → Email template setup section, you may configure all email templates used in change management.

• Change Read: Read access bit for a profile that allows the user with this profile to see the Changes of the team or teams to which it belongs.
• Change Write: You will be able to create new Change requests and will only have access to see the settings in the Changes → Management menu. You will also be able to add certain users to the team to which you belong or withdraw from it. In the latter case, only a superadmin or a user with Change Management bit may rejoin the team.
• Change Management: You will be able to see all open and closed changes and edit the changes that your role within the Change allows you to make.

• User superadmin:

They will be able to see all the changes generated in ITSM as well as manage them as if you had the ITSM Manager profile. In a new installation of PITSM the user named admin is created by default as superadmin.

• User Change Manager or with Team Manager profile:

They will be able to manage all the Changes with Manager permissions of which they are manager or Team Manager. You will be able to validate and approve these changes as well as edit all the elements belonging to it and completely manage its Tasks.

• User belonging to the assigned Team, without Manager profile:

They will have access to all the changes associated to their Team, as well as to those they opened themselves. They will be able to manage all the changes with Manager permissions in which they are manager. In the rest of the changes you will be able to add Workunits to tasks, change task status, add notes and other elements for correct change follow-up.

• Read user belonging to Team:

They will only have access to all the Changes associated with their Team, as well as those opened by the same user. In the Changes opened by the same user, they will have editing permissions on the rest that can be viewed in read mode and will only be able to add Workunits, notes, files, etc., without being able to modify their important elements.

Back to Pandora ITSM Documentation Index