Change
Presentation
Change Management is the process responsible to evaluate, coordinating and deciding about making change proposals to Configuration Items (CI).
According to ITIL, the main goal of this process is to ensure that changes are made in a controlled way, and being evaluated, prioritized, planned, tested, implanted , and documented.
Changes can be categorized as follows:
- Standard Change;
- Normal Change; and
- Emergency Change.
Categories | Description | Example |
|---|---|---|
Standard Change | Authorized of low risk, it occurs with frequency. It is initiated by a defined trigger that follows a procedure or works instruction to make the activities - well known - have a pre-determined budget. | Install a standard desktop application package. |
Normal Change | Any change in services other than emergency or standard. It follows the policies, deadlines, and procedures defined by the organization. | |
Emergency Change | Changes that need to be done as soon as possible. The Change Management process usually has a specific procedure to handle emergency changes. | Change to resolve a Major Incident or implement a security fix. |
Changes, as defined by the client, can be recorded and managed. Methods by which a change can be recorded must include (at a minimum):
- A manual entry
- Launched by an actionable alert and linking the change to the alert notification
- From an incident and link to the incident record
- From a problem and link to the problem record
- From a request and link to the request record
Where DevOps is in use, changes can be systematically created from within the DevOps pipeline.
Vendor response: Changes can be recorded and managed manually, from alerts, incident, problem and requests.
Form request
From Incident
Business justification such as business cases or specific business requirements, and business approvals can be recorded or linked to the change.
Vendor response: Yes, business cases or specific business requirements, and business approvals can be recorded or linked to the change. Customer can use change description field, request, project tab, kanban, documents, attached and all approval can be tracked in change form
Requirements for, and results of technical peer and technical management reviews, and the resulting approvals can be recorded in or linked to the change.
Vendor response: Yes, using workflow, customer can define how many approvals level each change will need to be performed.
Multiple service, component, and asset records can be searched for in the respective repositories, from within the change record, and applied or linked to the change.
These records can be distinguished as to whether they are the subject of the change or impacted by the change.
Vendor response: Yes, on left side bar there are all components that will be impacted by change and on Review and Closure stage all process impacted by the change
Identify duplicate changes and flag these changes for appropriate action to be taken by the client.
Vendor response: Yes, before the customer create a change, the system machine learn will compare information about portfolio and service catalog and match if some related or equal change are opened.
Risk assessments can be performed, calculated, and recorded within the change record, and the results may be used to identify the appropriate type of change (refer to CM7), and or specific change models (refer to CM9).
Common risk criteria and calculations can be provided out-of-the-box, but the client can define their own risk criteria. Examples of common risk assessment criteria may include, but are not limited to:
- A change implementation requested during a blackout period
- A CI or service that is designated as mission- or business-critical and subject to regulatory compliance, level of disaster recovery, continuity status, etc.
- An emergency or expedited type has been requested
- A predefined threshold of authorized/scheduled changes for a particular date/time (change capacity/conflict)
- The history of similar changes that have been successful or have a history of failing based on service, CI, location, and even the change requestor/implementor
- The cost or effort above a threshold, unusual skills, or technology
Clients must be able to define their own risk criteria in addition to what might be provided out-of-the-box.
Vendor response: Yes, on change risk analysis before customer create a change, system will provide a risk assessment OOTB.
Different types of changes can be identified based on assessed risk, necessary lead times for review and authorization, and other client-defined criteria. Examples of this may include, but are not limited to:
- Changes with acceptable levels of risk, or no risk that have been pre-authorized
- Changes with varying degrees of risk that require different lead
- Changes required to resolve active incidents
- Changes required by the business demands that do not fit into a standard review and authorization cycle
Clients must be able to define their own change types in addition to what might be provided out-of-the-box.
Each type of change may have specific review and authorization tasks and lead times.
Vendor response: Client can define different types of changes and can be identified based on assessed risk, necessary lead times for review and authorization, for each one a model can be created
Client admins can create and apply templates for all types of changes (CM7) that are needed for their organization with different forms, fields, and possibly pre-filled data, depending on the type of change.
Vendor response: Yes, it does. Models can be defined on change portfolio and pre-defined values can be pre-filled.
Client admins can create and apply specific models for all types of changes (CM7) that are needed for their organization that including templates (see item CM8), review and authorization tasks specific to the type of change, and necessary workflows.
Vendor response: Yes, it change hold a specific workflow that can be customized by customer
Models for changes that have been pre-authorized are managed so that they cannot be misused by other types of changes.
Vendor response: Yes, managers can define change pre-filled models and analysts just can use.
Knowledge articles can be linked or applied to change templates and models, so they are available whenever a particular type/model of change is used.
Knowledge articles can be searched from within an active change record or related workflow task, and the article can be related to or linked to the change record or task.
Vendor response: Yes, customer can link knowledge articles in models, tab documents or on workflow.
A method to prioritize changes is available that can be based on risk, lead time, severity, business need, workload, and other client-defined criteria.
Vendor response: By default, the platform to prioritize changes using Importance, Impact, Urgency, Workflow, Risk Assessment. Workload can be managed on Kanban boards. Customers can create fields for prioritize changes
The following information, at a minimum, can be recorded in a change, or linked/related to the change. This information can be used for the change review and authorization of the change:
- Validation of test results
- Validation of the creation and delivery of user and support communication, documentation, and training
- Linked/related release records, project records, and/or service assurance records that would include the above items (validated test results, user communication, and training)
- Remediation plans
- Change validation plans and actions, to confirm the state of the change upon implementation
- Linked/related incident records that may have triggered the need for the change
Clients may also identify other required criteria needed for review and authorization.
Vendor response: Customer can link result tests, documentation, remediation plans, incident, request and problem related or use change fields
Clients may define different and multiple levels of authorization for each type of change and change model. Some levels of authorization may be provided out-of-the-box, examples of which can include, but are not limited to:
- A single person, or multiple people
- A specific authorization group or entity
- Virtual authorization (requiring a certain number of individual approvals)
- Automated (in support of DevOps)
Vendor response: On workflow can be defined multiple levels of authorization for each type of change and change model
Change review and authorization workflows can be defined by the client based on the type of change, as well as other criteria such as service, component, location, etc.
While pre-defined workflows may be provided out-of-the-box, clients must be able to adjust them for their specific needs and add additional workflows if needed.
Vendor response: Yes, customer can design their won workflow. Platform delivery OOTB a bundle of change workflows for each basic need.
Additional review and authorization tasks can be added dynamically into live workflows based on conditional information such as a risk level above certain thresholds, the breach of expected thresholds, and lead times.
Vendor response: Yes, using requests for request additional review. For authorization. Including new approvers can be added.
Multiple change blackout periods and change windows, based on the service or component, or a business cycle can be created and can be published on a change schedule.
These can be used to assist in the scheduling and risk assessment of changes. Examples of this include, but are not limited to:
- Increasing the risk of changes scheduled outside of a change window
- Preventing changes that are not critical or emergent from being scheduled during blackout periods, or increasing the risk of these changes
- Requiring additional authorization of changes scheduled in a blackout period or outside of a change window (refer to CM16)
Vendor response: Multiple change blackout periods and change windows can be created and can be published on a change schedule, including change conflicts
Change authorization tasks (approvals) can be performed by designated approvers in the following manners (at a minimum):
- In the toolset
- Via web access (portal, service catalog, etc.)
- Via email
- Via mobile application (if the mobile app is supported)
Approval tasks can be dynamically managed based on pre-defined thresholds. For example:
- An approval task that is not completed within a certain timeframe is systematically re-assigned to another approver, or a notification is sent to a stakeholder for further action.
Vendor response: The platform allows customer approve change via web, mobile, email and approval notification will be sent based on another approval (This feature need to be customized based on customer needs. All threshold depends of workflow designed, approval methodology and customer business rules. By default, customer can change approver manually)
Different actions can be taken as a result of review and authorization. This must include (at a minimum):
- The change can move forward in the defined workflow based on the approval(s)
- Conditional tasks for additional action or review can be added; the approval is pending until the conditional tasks are completed
- Rejection, which could result in either of the following:
- The change is closed as rejected
- The change can go back to an earlier point in the change process for consideration
Vendor response: Yes, it does. All workflow actions must to be defined by customer, the platform default allow that new members can approve change, if rejected change is closed and change can go back to early point.
Clients can create and publish a change schedule, or multiple change schedules. The schedule must include (at a minimum):
- Predefined change blackout periods
- Predefined change windows
- Present changes on the schedule by the implementation dates
- Filter the view of the schedule based on criteria such as the type of change, the status of the change, location, service, component, implementor, etc.
- The ability to access any change record from the schedule
All critical stakeholders have access to the schedule, though what each stakeholder can view, or access may be limited by roles-based security.
The change schedule must be native to the toolset, but this does not preclude the ability to integrate with external scheduling systems if desired by the client.
Vendor response: Clients can create and publish a change schedule and track via reports and calendar
Changes can be systematically assigned to a group or person for review or implementation based on the type of change, the change model, or other predefined criteria such as location or department, service, component, etc.
The ability to manually assign the change to a group or person, in addition to or to override the systematic assignment.
Vendor response: Yes, groups can be pre-defined on models
Service and component information and/or IT assets can be added to or updated in the change record at any point in the change workflow.
Services, components, and/or IT assets can be updated within, or added to the respective repositories, as needed from any point within the change workflow.
Vendor response: Customer can link services, assets and components on change and update in needed.
Deviations from the authorized change can be flagged and trigger client-defined notifications; examples of this can include, but are not limited to:
- The authorized implementation start date passes without any activity
- The authorized implementation end date passes, and the change is still active
- The expected completion of specific review and approval tasks
- An overrun of the change window
- The implementation of remediation or back out plans
Vendor response: The platform allows all deviations methods and notifications based on workflow. Customer must configurate email notification messages in workflow and define the statuses for each step.
Notifications to all stakeholders, such as change requestors, the service desk, and other interested parties can be automated and triggered at predefined points or by certain conditions within the change life cycle.
Vendor response: The platform allows stakeholders notifications based on workflow. Customer must configurate email notification messages in workflow and define the statuses for each step.
Changes can be linked to or related to appropriate service or internal support agreements, as well as vendor contracts as needed in order to monitor agreed change service levels and to launch automatic notifications to predefined stakeholders.
The ability to establish change service levels based on predetermined time frames for each type of change type and requested implementation date(s).
Vendor response: Yes, it does. On Change Model customer can define contracts with agreements and workflows that support notifications.
Detailed information about the change can be documented throughout the life cycle of the change, within the change record and related tasks.
This can include system updates and notifications as well, such as status changes, results of automated tasks, etc.
Vendor response: Yes, all information can be documented on each workflow step using kanban boards, documentation fields, customized fields, forms and attachments.
Changes can be manually closed upon the completion of all change tasks in the workflow or systematically closed based on task completion and satisfaction of pre-defined conditions.
The client has the ability to define methods of closure that may be unique for different change models.
Vendor response: All business rules can be defined on workflow and pre-defined mandatory fields for each phase.
If the change results in, or causes an incident, problem, and/or a request, these corresponding records can be launched from within the change and linked to the change.
The change is recognized and reported as ‘causing’ the resulting record and can be distinguished from changes that result from these actions.
Vendor response: Yes, it does use change relationship left board and review/closure tab
The relative success of a change can be designated at the end of the change based on client-defined criteria and conditions, the final state of the change. These conditions may include, but are not limited to:
- Timeliness of completion (did not over-run planned implementation dates or change windows)
- Implementation of remediation plans
- Complete back out of the change, did not complete the change
- The status of the implemented change in comparison to what is expected
- Resulting incidents or problems
While some of these conditions may be provided out-of-the-box, clients must be able to define their own criteria.
Vendor response: Yes, it does and customer can add new attributes/fields as condition.
A post-change review based on the final state of the change and other client-defined criteria, and to define a workflow to manage the post-change review process.
The ability to launch the post-change review manually, whenever needed.
Vendor response: The post review change can be done on workflow as new step/phase, using closure and review change process or design new forms with different fields. Including on workflow a Post review Request can be triggered as customized process if customer need.
