Body
This getting started article will help you get started with your Change Management processes in the TeamDynamix environment for Ticketing.
Overview
IT service change management is the process of identifying, classifying, controlling, communicating, and reviewing changes that may affect IT services. The information technology infrastructure library (ITIL) is one of the key IT frameworks that addresses IT service change management. In TeamDynamix, IT service change management is all handled within the Ticketing Applications.
Transcript
Using the TDAdmin interface, the IT service change management module shows how to build a change management process. Starting with defining what is a change for your organization, you'll learn how to create a workflow that includes approvals and how to use the calendar along with blackout and maintenance windows to coordinate your changes.
Where to Find This
This process takes place in the TDAdmin and TDNext interfaces.
Navigate to configuration for Change Management following these paths:
- TDAdmin >
- Applications > [Ticketing Application]
- Applications > [Ticketing Application] > Workflows
- Applications > [Asset Application]
- TDNext >
- [Ticketing Application]
- [Ticketing Application] > Ticket Calendar
- [Asset Application] > Blackout Windows
- [Asset Application] > Maintenance Windows
IT Service Change Management Process and Activities
IT service change management is a way for IT professionals to work together more effectively and more efficiently. Additionally, studies have shown that 80% of IT outages are due to changes. Effective change management can therefore improve the quality of IT service.
Typically, IT service change management's scope includes changes to production systems. However, institutions may also include changes to development systems, IT processes, or even to the IT organizational chart. Organizations track these types of changes to ensure the potential risk and impact are identified and to help ensure the change can be implemented as planned.
IT service change management has several key activities. The following table outlines the sequence of activities and describes what each entails.
IT Service Change Management - Sequence of Key Activities with Definitions
| Key Activity |
Definition |
| 1. Defining what is a change |
It is likely that your institution has some work that requires changing a production system, but that should not be called a change. For example, rotating a log file. Your institution should identify its threshold for what is considered pre-approved work vs. what should be tracked as a change. |
| 2. Logging the change |
Before a change is performed, it will be logged or documented. In TeamDynamix, this means creating a ticket classification change. This change may be logged by an end user requesting the change, or anyone else including the person who will eventually perform the change. |
| 3. Classifying the change |
Logged changes can be classified to identify a rough sense of how risky they are or what their potential impact might be. |
| 4. Reviewing the change |
Changes are then reviewed and approved, often in proportion to the anticipated level of risk or impact. See also A risk-based approach to change review and approval. |
| 5. Building the change |
The change is then built or prepared. This is a big step and includes most of the actual work of a change, such as scripting the change to be in production mode or writing the code. |
| 6. Testing the change |
Ideally the change is tested in a non-production environment to confirm that it works. |
| 7. Scheduling and communicating the change |
When the change is ready for production, it is scheduled and potentially communicated to relevant stakeholders. |
| 8. Implementing the change |
At the scheduled time, the change is implemented in production. If there are issues, appropriate roll-back plans are used to revert the change. |
| 9. Closing out the change |
After the change has been implemented, it is closed. A post-implementation review can be conducted to identify lessons learned for future changes. |
| 10. Emergency change process |
The process used for changes that must be implemented to restore production service. |
It is common for change approval to happen after the change has been built and tested, prior to the production roll-out of a change. However, this means that the change management process is always stalling the production implementation, which can lead to many emergency or expedited changes.
In TeamDynamix, IT service changes are recorded as a ticket classification change. Change tickets often have workflows associated with them to map to an organization’s change management processes. One institution may have one simple notification-based change process; another may have a large set of change workflows depending on the ticket type or level of risk identified.
Frequently Asked Questions (FAQ)
Q. How do I raise a change from an incident?
A. In the incident, select the Create Parent action.
Q. How do I model change approvals?
A. Change approvals are usually modeled with ticket workflows. Depending on how changes are raised, you may have one change workflow per group and/or one change workflow per change type. Dynamic approvers can sometimes be used to reduce the number of workflows.
Q. Why are my changes turning into service requests?
A. In the past, service requests in TeamDynamix represented anything that needed approval. When workflow attached to a ticket that's just been created, the ticket's classification changes to service request. You can use the workflow to force the correct classification, by changing the promotion classification to change, and by having the promotion occur before the first step of the workflow.
Q. What are the different kinds of changes my institution should be tracking?
- Standard Changes – Pre-approved changes, usually low-risk, low-impact, no formal approval
- Normal Changes – Need to go before the change advisory board (CAB) for vetting, approval, and scheduling
- Emergency Changes – Need to go before the Emergency CAB, usually very urgent, high-risk, high-impact.
Q. How do I show change requests on a calendar?
A. The ticket calendar within the TDNext ticketing application can show calendar information related to tickets. The most important icon in this report is the filter or funnel icon in the upper-right corner. This lets you select only the change classification. Change-related work can display up in two ways:
- If you record a start and end date for the change itself, then the change will show up
- If you record maintenance activities for a change, then those maintenance activities will show up.
Q. How do you raise a change from an incident?
A. In the incident, navigate to Actions > Create Parent OR Actions > Set Parent if the change already exists. You will then be able to create a parent change for that incident. Once a change has child tickets, when you update the change's status you will have the option to cascade status updates to child tickets. For example, you can use this to close all child tickets related to the change.
Gotchas & Pitfalls
These issues may affect how quickly you can implement an IT service change management process:
- When implementing an IT service change management process, someone who can speak with authority to the mandate for change management ideally needs to be included, so that decisions can be made about the process while it is being implemented in TeamDynamix.
- Some project teams may not have knowledge of IT service change management, or an awareness of why the process exists. This can hinder the decision-making process for the implementation. This could be mitigated by ensuring the project team has an orientation.
Examples
The following are examples of IT service change management:
- Alex in networking needs to upgrade a core network switch. Alex logs a change request for this upgrade. That change request is then reviewed and approved as a low-risk change. It is noted that no communication is required. Alex schedules and then performs the core network switch upgrade. The upgrade goes as planned and Alex closes out the change request.
- Billy on the systems administration team needs to perform a routine OS upgrade to the campus enterprise resource planning (ERP) system. Billy logs a change request for this upgrade. As part of the change request review, it is noted that the last time a change like this occurred, the service was down for a long time. The change is approved as a medium-risk change after a back-out plan is identified. Billy performs the change during a maintenance window. There are a few hiccups, but Billy still completes the change within the window. Billy closes out the change request.
- Carter on the database administration team needs to add database extents to a financial system. However, no one besides Carter knows what that means, and the work has previously been de-prioritized. Carter logs a change request for this work. As part of the change review, people learn more about the importance of the change. They also realize that the work needs to happen immediately so that the financial system can handle the year-end financial rollover. The change is identified as a high- risk change due to its business impact and the change is approved to be completed ASAP. IT managers work with the finance department to schedule a special outage window and communicate with the departments affected. Carter can perform this important work and close out the change request once it is performed.
The following resources could provide some ideas for using IT service change management: