Change Management

Its main objective is to minimize risks and negative impacts on the organization's services.

With this section in Pandora ITSM, all organizational changes can be managed with the power provided by tasks and tickets, and where change teams will be able to intervene in them.

• Standard (pre-authorized): Pre-authorized and low-risk changes (such as server reboots).
• Emergency: Critical changes that must be implemented immediately (example: applying a security patch).
• Normal: Planned changes that require approval (for example, a software update).

• Change Initiator: Person who proposes a change.
• Change Manager: Responsible for overseeing the change and its impact. It is usually the Manager of the assigned Team.
• Change Team: Group in charge of implementing the approved changes.

When creating the change, the user will be able to configure the following elements:

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

A change request will look similar to:

Inventory objects or the required attached files can be assigned to the Change. The inventory objects correspond to the elements affected by the change, and new inventory objects considered necessary can be added in the future.

The same happens with attached files:

For correct change tracking, Notes can be added, which will not count towards its resolution time.

The tracking of each of the modifications made in the Change will be displayed in the Tracker section.

The Change Manager will be responsible for approving that the change can be carried out.

The change can be approved by providing a brief assessment of the reason why the change is Approved.

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

Once the Change is approved, the Change status will change to Scheduled. The Tasks and subtasks needed to carry out the requested change can be configured.

When generating the task, you can define a name, Manager, Team, Start/End, estimated hours, whether it has a parent task or not, the description, and its priority, risk, and impact.

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

In turn, tickets can be opened to complete these tasks. The hours computed in the tickets will be added to the tasks.

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

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

The task progress will be completed when the Manager of each of the tasks marks each of them with a Completed status. Within the tasks and the tickets associated with the tasks, the time spent performing them will be computed through Workunits.

The sum of these times will be counted towards the total estimated time for each task, and upon its completion, the Manager will edit the task to the Completed status, having reached or exceeded the estimated time, to display its 100%.

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

When the Change status is Review, it means that all tasks are completed and pending validation (otherwise, the Scheduled stage and each of its tasks must be reviewed).

To do this, the task Manager can validate them by changing their status to Verified. If all tasks are Verified, the option to Approve the change will appear in the Closure Information tab:

At that point, the Change Manager will be able to close it by providing an epilogue.

When creating a Change, and having one or more Change Templates, choosing one allows quickly changing the following parameters (except for the Name and Description fields):

The statuses are defined by the following conditions:

1. New: Newly opened status, pending Authorization by the Change Manager.
2. Authorized: Status that has been authorized by the Change Manager, it does not have any Tasks generated yet. If denied, it will go to the last status on this list.
3. Scheduled: Scheduled status, it has all its tasks pending and unstarted.
4. Implement: As soon as one of the tasks is started, it will automatically transition to this status.
5. Review: All tasks are finished and the status is pending review.
6. Closed: Finished and closed change. It can be due to having been unauthorized or by having finished correctly after going through the entire process and completing as well as validating all pending tasks.

As a specific behavior, the Standard type is pre-authorized and when selected, the change will transition to the Authorized status. It is important that this type can only be configured from a pre-authorized template.

By default, there are three types of each: Low, Medium, and High. By clicking on their names, you can edit their names and distinctive colors.

Their names can be edited without changing the order. Pending is the status where the task has not yet started, In process when it starts, Completed when it has finished, and Verified when the Manager ensures it has been correctly performed and fully completed. As many intermediate statuses as needed can be added and deleted, which will always occupy a position between Completed and Verified.

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

Teams will have associated changes and change tasks.

With the exception of the description field, the other fields are mandatory. The Change option must be active. Highlighting among them is the Email field, where a group mailbox will normally be defined so that the entire team receives change notifications when they are generated.

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

• Change Read: Read access bit for a profile that allows the user with this profile to view the Changes of the team or teams to which they belong.
• Change Write: Can create new Change requests and will only have access to view the configurations in the Changes → Management menu. They can also add certain users to the team to which they belong or remove themselves from it. In the latter case, only a superadmin or a user with the Change Management bit can reinstate them to the team.
• Change Management: Will be able to see all open and closed changes and edit the changes that their role within the Change allows.

• superadmin user:

Will be able to see all changes generated in ITSM as well as manage them as if they had its Manager profile. In a fresh PITSM installation, the user named admin is created as a superadmin by default.

• Change Manager user or one with a Team Manager profile:

Will be able to manage all Changes with Manager permissions for which they are the manager or Team Manager. They can validate and approve these changes, as well as edit all elements belonging to it and fully manage its Tasks.

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

Will have access to all changes associated with their Team, as well as those they have opened themselves. They can manage all Changes with Manager permissions where they are its manager. For the rest of the Changes, they can add Workunits to tasks, change the task status, add notes, and other elements for proper Change tracking.

• Read-only user belonging to a Team:

Will only have access to all Changes associated with their Team, as well as those opened by the user themselves. For the Changes opened by the user, they will have editing permissions; for the rest they can view in read-only mode, they will only be able to add Workunits, notes, files, etc., without being able to modify important elements of it.

←Return to the Pandora ITSM documentation index