The Change Catalog has been created to ensure smooth workflow processes during times of transition (Change Lifecycle). This can include pre-approval for standard changes and low level risk changes with a proven history of success. The change catalog allows you to create templates to ensure changes always adhere to the basic organizational approved processes.
Before you proceed, click here to gain a better understanding of Change Management and the Change Management Lifecycle.
Some of the most common motivators for change are:
- Software upgrades
- Hardware upgrades and much more
Prior to making any changes, please consider the following factors:
- Company resources
- The effect on the organization during the change process
- Simultaneous change collision - Can multiple changes occur at the same time?
- Moving forward to ensure you deliver organizational success and outcomes
Changes may be unique in the specific details, however numerous change processes can utilize the same change template to achieve successful outcomes. As the templates are editable, the same "Family" (Network, Applications, Infrastructure etc.), and even across families, we can rely on the basic structure of the template and customize it to take into account the specifics relevant to the change being addressed.
All changes require consideration of factors such as team members affected, budget etc. By creating Change Catalog Items (CCIs) defined here as templates, you can include all general processes, thereby accelerating the Change Request (CR) process and ultimately the CM lifecycle.
The Change Catalog is a repository of Change Catalog Items (CCI), which are change plan templates that you have predefine for each change type. The use of these templates by change requesters and implementers will help enforce the use of consistent ITIL best practices across your organization, reduce manual processing times and change failures caused by poorly planned changes.
Each Change template can be added to the Portal Guide for Portal users to initiate approved changes
Implementing Change Processes provides numerous benefits across your organization, such as:
- Driving consistency in routine Change Plans
- For example: Changing a network router is standard procedure. Whether you want to upgrade or replace a faulty router, over 80% of the change processes are common across all types of routers.
- Accelerate and streamline Approval and Execution workflows and much more.
- As in the example above, by providing a template to request a network router change, the organizational process has already been approved and all that is left is to follow the preset guidelines.
To maximize the benefits of smooth and efficient Changes throughout your organization and throughout the Lifecycle of the Change being implemented we have provided the following best practices.
- Create a unique CCI for every type of change (Standard, Normal and Emergency)
To help you understand how to work with CCI's, we have provided three examples out-of-the-box:
- Replace hard drive in server
- Operating system update using SolarWinds Patch Manager
- Add email server and Spam Experts
- Include type and "family" in the naming convention (Network, Application, Infrastructure etc.)
- Make sure relevant permissions are assigned per user to allow each role to best carry out their responsibilities in the Change Process.
Contact your administrator for proper permission assignment.
- Attach Incidents to CCI created, as you work, the AI capabilities in your Service Desk will offer relevant Incidents that relate to the CI created.
- Whenever you have repeat requests, important to schedule the request in advance via the actions column and/or the Actions icon button. This is useful for requests such as
- Backup servers
- Check fire extinguishers etc.
- Always update your change calendar. From the Actions menu, select Change Calendar to receive a link that is supported by all applications that support iCalendar.
- Changes that are declined or On Hold status will not be pushed to the calendar
- The change calendar only reflects changes available to the user that created the changes via their roles and permissions. Therefore, important to share only with users with equal or greater permissions. Anyone with limited permissions will not have access to view the changes on the calendar.
Refresh of change calendar - Changes are updated via the schedule of the application you select to use with the calendar, therefore changes made are not reflected immediately.
For a deeper understanding of utilization of your Change Calendar, click here.
Change Catalog Index Page
To view the Change Catalog index page navigate to Service Desk > Change Catalog.
Below you will see the index page breakdown:
You can filter, edit and customize your index page (For example: add, delete and reorganize the columns). For more details, please click here.
|Name||The name does not affect the process and is for your benefit. It is recommended to include the type and family (Network, Application, Infrastructure etc.) in the naming convention.|
|Description||Explain the relevant topics in the change you plan to achieve|
|Created By||Individual that opened the request|
|Created At||Date request was created (When you select the CCI, date and time are revealed in the CCI details page)|
|Scheduled||Yes or No in this column reflect whether or not a change request has been scheduled|
Based on the state of the CCI, the following actions will be available:
Initiating a scheduled request can be accomplished via the Actions column and/or the Actions icon button in the upper right hand corner of the CCI.
Please click here to learn more about scheduling a request from the Change Catalog.
To increase control of the process, you must manually update the State. This ensures the request process does not begin prior to all phases of the plan being put in place.
Admins can schedule changes via the Change Catalog Items (CCIs) which allows Standard Changes to run on their own with a defined cadence.
Notice the 'Schedule' Tab on the CCI page that displays all scheduled change requests. (Admins can update scheduled change requests directly from this page).
Notice the fields for 'Planned Start' and 'Planned End' dates above the area where changes are scheduled.
The scheduled date is when the change is requested while the planned start/planned end date is the number of days after the scheduled date, which is when the change is executed.
A change is requested on Friday, November 20. However, it is NOT executed on this date because the planned start/planned end date is 3 days. This means that the change is executed (implemented) 3 days AFTER November 20, which is Monday, November 23.
Best Practices and Use Cases
- Schedule CCIs allow customers to automate schedule Standard Changes to occur without human intervention.
- As a result, customers can automatically run change requests that need to be carried out on a regular basis. This includes the following use cases:
- A change runs every month to check for backups on all of an organization's servers.
- A change runs every 6 months to check license counts on all SaaS software to ensure an organization doesn't exceed their licenses or to see if they can cut their licenses.
To learn how to create new Change Catalog Items (CCIs), click here.
The Changes index page displays all the requested Changes. The icon allows you to filter the view, and below we have provided a breakdown of the default columns reflected:
Remember - by selecting the icon, you can edit the columns in your view, Add, delete or return to default table view.
|Number||Reflects the number of changes that have been requested|
|State (color coded)||
|The birds eye reveals a pane on the right and displays the Change details, Change, Rollback Test Plans etc.|
|Title||Name of the requested Change|
|Assigned To||The Change Implementor|
|Created||When the Change request was made|
|Requester||Person complete the request information|
|Started At||When Start Process was initiated, not the Request itself|
|Last Update||When was the last update on this change made|
|Actions||Ability to delete request|
By selecting the Change title, the details of the CR are revealed including all plans outlined to carry out a successful change process. The Process tab reflects all approvals/denials and general workflow required to move forward or abort the change.
Once the Change assignee completes review of the CR, the change process can begin:
- To begin you can click Start Process
- There is also the option to Start Process Automatically. By selecting the edit icon in the Process tab, you can toggle the pill bar to On which will trigger an automatic start once the Request is made.
To make changes once the process has begun, you can stop the Process by clicking Stop Process, modify the workflow directly in the Process tab and when ready, re-initiate the Process by clicking Start Process once again. Not all changes require a relaunch of the process. Changes such as field values (system and/or custom fields) can be made while process continues.
Ad Hoc Change
Whenever a single use Change is necessary, an Ad Hoc Change is the best way to proceed. This Change does not require nor create a CCI.
For example: Across your organization you are replacing the phone system with VoIP (voice over IP) technology. Once this process is complete, it will not need to be repeated, therefore you can request an Ad Hoc change that will not be saved as a CCI for future use, rather it will just appear as a Change created without a template.
From the Changes index page, select the icon. Select Create New Ad Hoc Change from the dropdown menu. Notice the information requested is similar to that of a CCI with the execution of the Custom Fields that are included in this form.