Modern Change Management: Adoption Playbook & Maturity Journey
Table of Contents
- Introduction
- Personas
- Technical specifications
- Defining key Modern Change concepts/capabilities
- Best Practice Guidance
- Recommendations on how to Modernize your change process
- Modern Change maturity journey
- Maturity stage 1: Reduce complexity & subjectivity
- [Coming soon] Maturity stages 2-5
- Other questions
- Learning & resources
The purpose of this article is to provide prescriptive guidance to new customers as well as those who want to migrate from their legacy, usually heavily customized Change implementations to take advantage of OOTB features to simplify and automate Change. What we’ve published so far takes you through the first stage of the Modern Change maturity journey as well as Best Practice Guidance. Over the next weeks/months we will keep adding new content to this guide, such as the remaining maturity stages material and a Modern Change Lab Guide – showing how to configure examples for each key feature. We will also publish short videos demonstrating some of the capabilities covered here. Please come back regularly to view the additional content as it evolves!
We’re also keen to get your feedback on how useful this is or if there are any areas we have not covered yet, which you’d like us to? Please let us know via the comments.
Thank you!
Introduction
Back to top & table of contents
What do you mean by ‘Modern Change’?
The key goals of Change Management haven’t varied much over time – the challenges our customers have faced in the past face are still valid today (e.g., increased change volume, desire to reduce incidents caused by change, desire to reduce failed change impact) and continue to persist. As change volumes continue to grow and modern delivery methodologies have led to increasing change frequency, we need a fresh approach to overcome these challenges. ‘Modern Change’ is our approach to help deliver higher volumes of changes that are more compliant, less likely to impact service, improve the requestor experience of raising changes, and manage change risk in a data-driven way.
It’s no secret that organizations and Change teams find these outcomes desirable, but often a challenge to achieve. This is because many customers have customized their legacy change implementation to meet evolving requirements only to find this adds unnecessary complexity for their users, increases technical debt, and inhibits their ability to update newer features for change. The trend we are increasingly seeing is many customers want return to ‘out of the box’, to drive better value from the latest change features and simplify the user experience.
So how does ServiceNow help customers begin to modernize their Change processes within their constrained budgets and resources?
A model-based approach
Central to our Modern Change solution are change models. Change models, along with key supporting change features (e.g., approval policies, data-driven risk), are key for customers looking to modernize their existing implementations. A model-based approach to Change enables customers to simplify legacy ITIL Change implementations, adapt to meet new change requirements, and help better manage increasing change volume using automated governance.
Customers can simplify their Normal Change workload (which is often overburdened and complex) by applying fit-for-purpose change models to unbundle discrete use cases from Normal change and run them in their own, more efficient process. Teams can deliver changes faster by leveraging models built just for them, to automate the onerous parts of the process. This frees up their time from unnecessary process ‘admin’ and allows them to focus on just the necessary steps and requirements for their specific use cases.
By automating change criteria for discrete use cases and right-sizing governance requirements across the different models, Change Managers can reduce the oversized governance burden to improve change outcomes without additional ongoing manual effort, freeing up time for them and their teams to focus on more complex change activity.
What pain points/problems does modernizing change solve?
Customers are experiencing an evolution of their technology value streams due to faster development cycles and new governance challenges. Our customers tell us their challenges align to three key themes:
-
Balancing delivery speed with quality & compliance
-
Increasing volume and frequency of changes results in more incidents and service impacts from failed change
-
Balancing the need to move fast with enterprise governance requirements can create bottlenecks due to subjectivity and reliance on manual reviews
-
Avoidable fire drills in production caused by quality and compliance checks occurring too late, just prior to deployment, instead of earlier in the lifecycle.
-
-
Desire to evolve vs. inertia to change
-
Hesitancy to adapt and disturb the legacy Change implementation which “works”
-
Waste due to over-customized, arduous legacy processes that are a “black box”
-
Increased pressure on constrained budgets.
-
-
Moving from subjectivity to data-driven governance
-
Limited traceability – the relevant data isn’t always associated to the change request
-
Subjective impact & risk results in slower decisions & issue triage
-
Hindered ability to drive automation & optimization without access to the relevant data.
-
Why ServiceNow is uniquely positioned to solve these pain points
ServiceNow’s unique modern Change Management features will simplify, automate, and accelerate change velocity using built-in AI, data-driven flows, and fit-for-purpose change models to deliver faster time to value without sacrificing governance rigor.
Personas
Back to top & table of contents
Who are the key personas involved in Modern Change?
- Change Management Process Owner: Owns and maintains the Change Management process. The role of Process Owner is usually a senior manager with the ability and authority to ensure the process is rolled out and used by all stakeholders.
- Change Manager: Responsible for the day-to-day facilitation of the change process. This role is focused on the management and administration of all changes. In ServiceNow a change manager will require the change_manager role.
- Change Requester / Implementer: Responsible for the creation and implementation of changes. Requires itil role, or sn_change_read and sn_change_write.
- Change Assessor (technical / peer reviewer): Evaluates proposed changes for technical accuracy, impact, risk, feasibility, and value and determines if change needs more information, should be rejected, or should be moved to the Authorize state for final approval. Requires approver_user role as well as itil role, or sn_change_read and sn_change_write (or business_stakeholder role).
- Change Approver: Decides if a change meets the organization’s criteria for approval – including whether it has been well planned enough to have mitigated the risk to services as far as is possible. Requires approver_user role as well as itil role, or sn_change_read and sn_change_write (or business_stakeholder role).
- Note: The role of approver may, in some models, be replaced by automated quality or policy checking features such as Change Approval Policies.
- CAB Manager: Facilitates the CAB meeting or can delegate the responsibility. The sn_change_cab.cab_manager role is required.
Technical specifications
Back to top & table of contents
How is Modern Change licensed?
Modern Change comprises several capabilities with differing entitlements. See below for those capabilities and the licensing required (note: only Change Management related features/products are listed here. See here for full suite of ITSM licensed capabilities)
Core Change Management Features (req. ITSM Standard)
- Automated Flows: Streamline the entire change lifecycle from initiation to closure.
- Change Models: Apply a fit-for-purpose process to specific change use cases.
- Risk Conditions and Calculation: Evaluate potential risks associated with each change based on predefined properties and conditions to calculate a risk value.
- Risk Assessment: Survey prompting information from change requestor to assess a risk value.
- Conflict Detection: Gain visibility of change conflicts based on configurable system properties. Scheduling Assistant can automatically select a conflict-free period for you.
- Change Impact Visualization: Provides a clear view of the potential impact of changes on IT services and business operations based on data in the CMDB.
- Change Calendars: Visualize planned changes, blackouts, and maintenance schedules.
- Approval Definitions and Policies: Define and manage automated and manual change approvals based on business requirements and platform data.
- CAB in SOW: Define, schedule and run CAB meetings from within Service Operations Workspace.
- Standard Change Catalogue: Manage pre-approved standard change templates.
- Integration Capabilities: Integrate with other ServiceNow modules and external systems.
- Reporting and Analytics: Gain insights into change management performance and identify areas for improvement.
Additional Change Management Features (req. ITSM Pro or above)
- Change Success Scores: Use a numeric score to automate approvals for low-risk changes and evaluate probability of success based on past performance.
- Risk Intelligence: Use machine learning algorithms to make data-driven risk predictions.
- Calculated Risk Score: Configurable risk score based on probability of success and impact.
- Platform Analytics Change Dashboards: OOB dashboards to track performance of Change Management KPIs.
Generative/Agentic AI add on capabilities (req. ITSM Pro Plus or above)
- Now Assist
- Change Summarization
- Change Risk Explainer
- Agentic AI
- Change Planner: Use a team of AI agents to autonomously generate the implementation, backout and test change plans for a given change request based on similar change requests and best practice.
Additional related Products
- DevOps Change Velocity: Integrate seamlessly with DevOps tools. Keep distributed developers in their tools while automating DevOps changes. Gain insights on key value stream metrics such as DORA and Flow. Also see our DCV Community site for help on getting started (Requires ITSM Pro or above).
- Digital Product Release: Speed time to market with automated readiness and 360º visibility into releases. Also see our DPR Community site for help on getting started (Requires ITSM Pro or above).
What are the main actions required to install the Modern Change capabilities?
- The Change Management Process Guide, available in ServiceNow Best Practices, provides best practice guidance to achieve alignment to the out-of-the-box Change Management process that we ship in the platform.
- Follow the instructions to set up and configure Change Management plugins.
- The ITSM guided setup provides a sequence of tasks that help you configure Change Management on your ServiceNow instance. To open ITSM guided setup, navigate to Guided Setup > ITSM Guided Setup. For more information about using the guided setup interface, see Using guided setup.
Where does DevOps Change Velocity (DCV) fit?
Modern Change as a solution includes leveraging OOB integration with 3rd party CI/CD DevOps tools feeding the DevOps data model and using that data to drive automated change creation and approval via policy checks. Think of DevOps Change Velocity as a capability within the Modern Change overall solution.
Where does Digital Product Release (DPR) fit?
DPR is a Release orchestration tool which can automate your release processes by shifting release compliance left and automating release readiness via policy checks. DPR can simplify and streamline your change process by moving release compliance checks, typically done during change approval, into earlier release phases.
Key Modern Change concepts/capabilities
Back to top & table of contents
Change Models
Change models allow organizations to define fit-for-purpose models to simplify and streamline change across common use cases. Change models define the process a particular change use case will go through.
OOTB we ship models for the 3 traditional types of ITIL changes (Standard, Emergency and Normal) as well as some other change use case examples suitable for separate models (e.g., Change Registration, Cloud Infrastructure, Unauthorized change, DevOps changes). These other use case examples would historically have been processed as a part of Normal Change, which is usually more inefficient, or as a part of Standard Change, which may be inappropriate as Standard lacks any run-time governance.
Like the change types used for legacy ServiceNow change implementations, change models have several artifacts (e.g., change states, state transitions, approval policies, templates) associated to them. The primary difference though is artifacts for change models are modular in nature, so they can be maintained/modified individually and reused across models, compared to being directly integrated into a monolithic workflow for change types. This vastly reduces the technical complexity of change models and the maintenance requirement for them. See below for a visual of the artifacts associated with example change models.
One additional benefit of change models is they can better facilitate the capture of relevant structured data based on the change use case. This structured data can then be used to inform risk evaluation and approval decisions – a good example is the DevOps change model that can consider DevOps data (e.g., work items, code commits, test results, security scans) into automated governance decisions.
Workflow vs Flow
We recommend customers migrate from legacy Workflow-based Change to use Flows. Flows will help enhance efficiency, usability, and performance of your change process. Workflows were used in legacy Change implementations and are typically monolithic and complex, making them difficult to enhance without significant development and testing effort. Change Flows are modular and reusable by design. Today, we ship OOTB state-based flows for each Change model. These can easily be cloned and updated to meet your specific process requirements.
Why are Flows better? Flows are designed to run asynchronously by default, ensuring fast execution without impacting the calling thread. The reusability of sub-flows and flow actions streamlines development, making it more efficient. The intuitive low-code, natural language interface accelerates workflow creation and comprehension. Leveraging the NowMQ in-memory queue for asynchronous processing, flows achieve faster execution speeds. Additionally, flows offer advanced capabilities for filtering content and managing workflows with precision, ensuring optimal performance and effectiveness.
In summary, migrating to Flows not only aligns with modern development practices but also significantly improves the overall workflow automation experience. It’s important to note that existing Change Workflow and model-based Change Flows can co-exist and both run in parallel to provide a smooth migration path for change workloads.
Change Approval Policies
Approval policies can use any ServiceNow data as input to automatically evaluate and apply approval decisions based on business requirements. Changes can be:
- Auto approved
- Auto rejected
- Sent for manual review to a user or group
Approval policies provide an audit trail within each change request, can be linked to change compliance, and are reusable and independent from state-based flows (flows call them).
The key benefit of using Approval policies is they allow you to tailor your change approvals to align with your organization's appetite for risk. This can dramatically increase change velocity with sacrificing governance, audit and control.
How do Approval policies work?
When an approval policy is triggered in a flow (typically when a change is transitioning from New to Assess/Authorize), policy inputs are gathered and fed into the dynamic approval engine (If…Then decision hierarchy) which will determine the approval decision/action for the change. Policy inputs can be any data available on the ServiceNow platform or external data retrieved via a REST API call.
Once a decision is matched, an Approval Definition, another key component to Approval Policies, is evaluated to dynamically determine which individual or group (and how approval needs to be obtained within a group) will be making the decision on a change. If the change is automatically approved or rejected, it will be on behalf of the user/group in the Approval Decision. If the change is routed for manual review, the user/group will be notified to review and approve/reject.
Approval Policies satisfy regulatory requirements when auto-approving changes. They accelerate time to value for the business by reducing or removing manual effort when configuring approvals and making approval decisions on changes. They enable a high degree of agility and allow you to respond quickly to changing governance conditions.
Examples of Approval Policy usage
- Auto-approve low risk changes for specific services or teams with high success
- Add manual approvals based on critical business services, change conflicts or teams with low success
- Auto-approve DevOps changes which meet development and operational governance criteria
Risk Evaluation Methods
ServiceNow provides four evaluators which can be used to calculate change risk. These can all be used together or individual evaluators can be activated / deactivated according to customer need.
- Risk Assessment
- Risk Conditions
- Risk Intelligence (requires ITSM Pro or above)
- Calculated Risk Score (requires ITSM Pro or above)
The risk evaluation framework takes the different risk evaluation methods you’ve configured to run on your change and provides a derived risk score, which OOTB is the most conservative (highest) risk score evaluated. All risk scores that were fed into the risk evaluation framework are also visible on the change.
Overviews of each risk evaluation method are below:
Risk Assessment
Risk Assessments are well established in most customers’ implementations.
- Risk assessments are an extension of the surveys and assessments core platform feature.
- Risk assessments can be configured and triggered using conditions. Different sets of questions can be used for different conditions (e.g., Normal change risk questions can be different to Emergency change)
- Questions in risk assessments are weighted, and the final score is calculated from the answers and weightings.
- Risk assessments can be run multiple times for a single change.
- The latest risk assessment is used for risk scoring.
- The history of risk assessment answers is stored against the change for audit and compliance.
| Pros | Cons |
|
|
We recommend you consider replacing subjective Risk Assessment questions with more objective, automated, data-driven risk calculation features to improve accuracy (see below).
Risk Conditions
Risk Conditions
- Automate the process of setting change risk and impact values based on data
- Can be triggered according to filter conditions
- Allow you to ensure that organizational compliance is adhered to
- Provide an audit trail
- Take the subjectivity out of risk decisions and allow the use of structured data
|
Pros |
Cons |
|
|
Calculated Risk Score (requires ITSM Pro or above)
- Uses established method to calculate risk - combination of change success Probability (change success score) + Impact (risk conditions) to determine risk
- Change probability X Impact matrix is configurable by customer
|
Pros |
Cons |
|
|
Risk Intelligence (requires ITSM Pro or above)
Predictive intelligence is a data-driven machine learning solution provided out of the box with ITSM Pro or above.
- Select from and configure one of two algorithm solutions (Classification or Similarity)
- It can be configured to work with the data and process that you have and works well with minimal configuration.
- You can trial the predictive intelligence solution to view the predicted risk values, then tweak and re-train the model until you are happy with the results, before configuring the solution to set the Risk value in ‘live’ use.
|
Pros |
Cons |
|
|
Change Success Scores
Change Success Score is a numeric ‘credit’ score, calculated using historical data to help determine likelihood of success based on a team’s change history. The more successful a team is, the higher their score and the reverse is also true.
Scores range from 0 to 850, where:
- 700 – 850 is rated Excellent
- 600 – 699 is rated High
- 500 – 599 is rated Medium
- 0 – 499 is rated Low
If you need to modify the score ratings, please follow instructions here.
Success scores are also tracked for Change Type and Model so you can monitor performance of those across your enterprise.
Success scores can be used as an input for calculating risk as well as for approval policies. e.g. If a team has an Excellent success score, their approvals can be automated, whereas a team that has a Low or Medium success score requires manual review / approval to ensure their changes meet compliance and quality expectations. This allows for more flexible governance based on the data for a team’s performance. It also allows you to identify teams with Low success who may need additional training and support.
How to activate and start using change success scores
To use change success scores the ‘Change Management – Change Success Score’ plugin is required. Once this plugin is activated, a number of platform analytics (PA) jobs are added: Change success score metrics (Daily), Change success score metrics (Historical data), Change success scores (Historical data), and Change success scores for today. You can optionally choose to run the historical data jobs to set a baseline of success scores based on the past 30 days of changes, or alternatively you can begin using the daily job that will increment the change success scores from a base of 500. After the first job run, a Change Success Score card icon appears next to the Assignment group field on the change request form in UI16. At the moment of writing this FAQ, SOW change does not surface the Change Success Score modal information, but this is a gap that will be addressed in an upcoming release (please check release notes to see if has been updated at the time you are reading this). If you click this icon, you can view the score card details of the assignment group.
Each team starts with a baseline score of 500. Their scores are then adjusted up or down by the daily PA job. Scores for each team, type and model (as well the overall enterprise) and trends over time are tracked and displayed on the Change Success Score dashboard.
How Change Success Scores work
The following indicators are used to collect data daily for the changes completed on the previous day.
- Total Changes
- Successful changes
- Unsuccessful changes
- Successful changes with issues
- P1 incidents caused by change
- P2 incidents caused by change
- P3 incidents caused by change
If you want to add a custom indicator, please follow the instructions in this knowledge article which shows you how to add Outages for Change as a new indicator.
Configurable formula indicators are used to calculate the success scores. These indicators apply a multiplication operation to the data collected by the automated indicators to arrive at the final score.
You can view and configure the Change success score formula indicators in Performance Analytics under the indicator group Change success score - multipliers.
Below are the default multipliers used in success score calculation. If you need to modify the score calculation see this page.
|
Automated indicator |
Multiplier applied by formula indicator |
|
Successful changes |
3 |
|
Successful changes with issues |
-2 |
|
Unsuccessful changes |
-5 |
|
P1 incident caused by change |
-10 |
|
P2 incident caused by change |
-5 |
|
P3 incident caused by change |
-2 |
Change in Service Operations Workspace (SOW)
In Utah, release we introduced Change Management into the Service Operations Workspace experience. Our aim was to not only modernize, but also accelerate change management with an elevated, data-driven experience. Since then, we have continued to evolve Change capabilities in SOW.
Dynamic Overview tab
One of the highlights of SOW Change is the new Dynamic Overview page which helps reduce the clutter on Change forms and render contextual information relevant to the Change state and the persona using the application. The intent is that users who are new to Change Management no longer need specific process knowledge to navigate the full Change lifecycle without relying on classic UI. This new, modern, experience is more intuitive and driven by the underlying state model and helps focus users on the next “job-to-be-done” as they fill in information and move from one state to the next. More experienced users can still manually fill in information using the Details tab if they choose to.
Schedule tab
The change scheduling experience has been improved by providing a comprehensive scheduling calendar view that highlights areas of potential conflict (blackout windows, other related/relevant changes) within SOW. SOW Change will automatically look for conflicts and the next available conflict-free time slot for the planned change duration. If desired, ServiceNow can automatically schedule your change in the next conflict-free window. The Details tab will also update to show the planned start and end date, as well as if any conflicts were detected.
Configure the Dynamic Overview page
You can use the table-based configuration to align the SOW Dynamic Overview pages with your organization’s change process.
Configuration options allow you to define how the Dynamic Overview pages render throughout the change life cycle. This includes configuration options for overview pages, contextual sidebar and activity stream behavior for each state.
You can configure the following components:
- Control the display of the cards in the contextual side panel
- Control the order of the cards to be displayed in the Overview pages
- Control the display of activity stream bar in the Overview pages
- Configure the journal fields
See the documentation for more details: Manage the workspace configuration for a Change request in Service Operations Workspace
CAB Workbench
As of May 2025, we have also brought the CAB Workbench experience into a new improved user experience in SOW. CAB in SOW launched with functional parity with the legacy CAB Workbench, supporting reviews of CAB-relevant changes, failed changes, and standard change proposals. As a part of the improved user experience, there are more options within agenda management for in progress CABs, such as pausing, deferring, and restoring agenda items. CAB efficiency is improved by encouraging pre-CAB reviews and commentary on upcoming changes. Look out for future enhancements to CAB in SOW in upcoming releases.
DevOps Change Velocity (DCV)
By leveraging DevOps Change Velocity, customers can significantly enhance and modernize their change management processes, leading to improved efficiency, compliance, and overall productivity. Key benefits include automated change creation from CI/CD pipelines, automated approval/rejection of changes based on DevOps data, and compatibility with all major DevOps tools. This reduces manual activities for developers, change managers, and release managers, increases change throughput, and ensures full traceability and auditability. Additionally, it centralizes data in the DevOps Data Model and automates control and governance through data-driven policies.
This results in improved compliance with a single source of truth for change control and governance data, and continuous improvement with greater visibility to enhance cross-team culture and process health. This leads to a lower failure rate, improved mean time to recovery, and optimized deployment frequency, with everything tracked through out-of-the-box integrations.
DCV addresses challenges such as eliminating the need to switch between tools and reduces manual work to manage changes, improving the correlation between changes and release content, enhancing visibility and transparency between Dev and Ops teams, enabling the increasing volume and velocity of DevOps changes, and reducing compliance risks. Through automation and integration, the non-intrusive approach allows developers to stay in their own tooling. See our DevOps Change Velocity Community page for more info.
Best Practice Guidance
Back to top & table of contents
Change Approvals
This section contains best practice guidance to ensure change approval adds value to your process and doesn’t become unnecessarily burdensome.
The goal of Change Management is to balance the benefit vs the risk of the change to drive business outcomes within the risk profile of the organization. A well-balanced process should enable change to occur as rapidly as possible to meet the business need, while ensuring the associated risks are well understood and planned for. Aim to minimize the number of approvers in your process, to avoid change approval becoming a bottleneck.
Having large numbers of approvers on a change who don't perform a specific role in the process, should be avoided. Additional manual approvers may not necessarily lower the risk but can add significant manual overhead for the teams involved. For each approval level, try to limit the approval to a single group or person accountable. If this accountability is unclear or spread across multiple teams or people, it can create ambiguity and unnecessary manual overhead.
Change Approver Accountabilities
Change approval has a very specific function within the Change Management process. Each approver should have clearly defined accountabilities and a list of what they need to check for when performing a review. There should be as little overlap as possible between the different levels of approvers. Amongst other things, approvers should be checking to ensure:
- The risks and impacts of the change are clearly articulated
- There is sufficient evidence provided to cover implementation, testing, post-implementation validation, backout; including catering for scenarios of what could go wrong and how to mitigate any issues if they arise.
Avoid using Change Approval as a proxy for Change Notification
Change approval is sometimes used as a proxy for notification of upcoming changes. This is poor practice and should be avoided. There are many ways to enable notification of the forward schedule of planned changes without needing to be an approver (e.g. change schedules, reports, dashboards, VTBs, CI subscriptions etc.). Unnecessary approvals (especially if there are many levels across different groups) can slow the process, make it difficult to navigate, dilute the accountability of the other approvers and detract from the valuable outcomes that change governance delivers to the organization.
Recommended Approval Levels
We recommend that approvals are generated for:
- Peer review (technical assessment) - usually by a peer in the Assignment Group other than the change assignee (for all risk levels)
- Change Management for quality & compliance review (for medium and high risk)
- CAB (for high risk)
- Service Owners – only if their service will experience a planned outage
- Others only as needed (e.g. Firewall changes would usually require approval from the Security team)
Task Assignees should not be Approvers
Task assignees don’t also need to be Change approvers. This adds unnecessary approvers to a change. Acceptance of a task can be managed by the change owner populating only the assignment group on the CTASK (not the Assignee field). Assignment groups can monitor their task queues and acceptance for the task can be indicated by populating an Assignee name on the CTASK. If a CTASK Assignee is blank, the change owner can follow up with the relevant group. They can also add a work note to provide more details if required.
Maintenance and Blackout Schedules
Use Blackout and Maintenance windows to help your teams schedule their changes during optimum periods to lower the risk and impact to service.
- Blackout windows specify times during which normal change activity should not be scheduled. e.g. a change freeze period during critical processing times such as holidays or End of Financial Year.
- Maintenance windows specify times during which change requests should be scheduled to minimize service disruption. E.g. changes are scheduled between midnight and 4am when the service is not being used.
Conflict detection uses blackout and maintenance schedules to find potential scheduling conflicts for the configuration items (CIs) associated with a change request. When conflict detection runs, it determines if either type of defined schedule applies to the change request. If a potential conflict is identified, a warning message appears and conflicts are listed in the UI.
As well as blackouts or maintenance schedules which are global in nature (i.e. periods which apply to all changes), you should also consider more granular blackouts and maintenance schedules for discrete groups of services, CIs, or even assignment groups (or other data points relevant to your organization). More granular blackout and maintenance schedules (based on a specific set services for example) are more effective because they are specific and targeted. This helps avoid unnecessary conflicts which global schedules can generate.
How to Modernize your Change process
Back to top & table of contents
Modern Change Maturity Journey
Shown above is our perspective on an outcome-focused maturity journey to realize a modern change management process within your organization. The top boxes in this visual represent the top-level outcomes as well as sub outcomes that can be achieved at each maturity stage. The bottom boxes in red represent the data that should be available to leverage within this process at each stage.
At a high level, through this maturity journey we aim to help customers visualize how they can realize the outcomes described through the planned adoption of our Modern Change features while limiting impact to ongoing business operations. This maturity is most applicable to existing customers looking to migrate away from their legacy change implementations but is also broadly applicable to new customers.
- This starts with evaluating your as-is process and identifying use cases where you can begin experimenting with change models, flows, approval policies, etc. to familiarize yourself with what’s available (this is applicable to legacy customers looking to migrate).
- Then it moves to expanding on use of models for more use cases and beginning the planning, building, and testing to migrate from change types to models for ITIL changes.
- With that foundation, next is defining and leveraging data available within ServiceNow in your change process – such as blackout and maintenance schedules, data-driven risk conditions, operational data, change historical performance, engineering data – into robust approval policies to drive automated governance over your change process.
- Along the way, we recommend thinking about simplifying your change process by looking at products like Digital Product Release, which can help shift left release validations often added into change approval, instead of earlier in the release lifecycle.
- And by the end, customers can get to the point of achieving full change automation for certain use cases, from creation to approval. Additionally, GenAI/Agentic AI capabilities can be used to reimagine how changes are created and managed.
It’s important to mention that based on a customer’s maturity and requirements, it may make sense to start at different points along this journey. What’s shown is our general recommendation for the path a customer can take.
Before you begin
Before you get started on your maturity journey, it’s a good idea to plan and document the outcomes you want to achieve with Change Management. It’s also important to document how you will measure success, so you can track your progress to achieving your goals and correct course if necessary.
Think about the key goals and outcomes you want to drive. Here are some examples:
- Better manage increasing change velocity
- Handle a higher volume of changes
- Improve change quality
- Improve service resilience and stability
- Drive more accurate risk assessments
- Reduce incidents caused by change
- Reduce manual approvals
- Achieve robust controls & compliance
- Simplify and uplift the user experience
- Make CAB more efficient
All of these can all be achieved with ServiceNow’s modern change solution. Prioritizing which goals are most important to your organization and how you will measure success, can help you plan and sequence your own Change maturity journey and roadmap.
Maturity Stage 1: Reduce complexity & subjectivity within your change process
The first stage in the Modern Change maturity journey is mostly relevant to customers with legacy change implementations, but there are elements (like how to identify change model use cases, defining new change models, creating and using approval policies, setting up structured risk evaluation methods) that will be applicable to all customers.
At this stage, the primary outcome is to reduce the complexity and subjectivity of your existing change process by removing the burden on highly customized, legacy change processes through the adoption of select modern change features. This entails:
- Defining and using more pre-approved Standard changes for frequent, low risk use cases which have a good history of success
- Identifying and experimenting with the first change model use cases and testing their effectiveness with select teams
- Activating data-driven risk conditions to use alongside other risk evaluation methods
- Defining initial approval policies to help automate governance decisions
1). Review your current Change Management process to gain a clear understanding of which steps and data are mandatory for your organization. Over time, processes can become cumbersome and inefficient and should be regularly reviewed to ensure their effectiveness and efficiency. It’s important to not recreate any existing process issues within your new models and flows. It’s good practice to question the value and necessity of every input, step, and output in your current process to ensure:
- Alignment to your organization’s goals for Change Management (refer to ‘Before you begin’ section in this document for example goals)
- Alignment to the Technology Risk & Controls frameworks applicable in your industry
- Every input > step > output should add value (i.e. eliminate waste and unnecessary toil)
2). Identify pilot low risk use cases & teams to test with to unburden what often is an overloaded, complex Normal Change process. We recommend starting with frequent, low risk change use cases that would be appropriate for either a Standard Change template or for a change model.
Standard Changes are pre-approved and are appropriate for repeatable, low risk use cases that have a strong history of success, thus not requiring approval at run time. If you need to add an approval step to a low risk use case, we recommend using a change model instead. Change Models enable more flexibility than a Standard change. Used in conjunction with an approval policy, a ‘Low Risk’ change model can allow for automated approvals when policy parameters (e.g. risk is low, non-critical CI/service, no conflicts detected) are met to provide the speed of a Standard change, but can also route a change for manual approval if details of the change or operational environment elevate the risk outside of defined conditions.
Examples of low risk change use cases are:
- Cloud infrastructure provisioning
- Deployments to non-production environments
- Applying non-critical software patches
- Standard firewall rule changes
- Low-risk administrative actions (e.g., user account provisioning, email distribution list updates)
Guidance on how to identify use cases for change models:
- Review your current Normal and Standard change workload to identify initial use cases. Think about frequently used low risk use cases where the implementation, testing and backout steps are well understood and have a good history of success. This could be for specific teams, CIs, applications, services or other patterns.
- Think about changes which can be made more efficient because there is little value in them having to traverse the full Normal change lifecycle. Examples include: Patching, Cloud Provisioning, Minor Application Enhancement.
- Consider Standard Changes that could benefit from adding an approval step to better manage changing operational conditions (e.g., if the CI being changed is experiencing an incident/outage, or there is an urgent blackout in place conflicting with the change à auto-reject change or add a manual approval step to review risk prior to implementation). A low risk change model with associated approval policies can enable more flexibility and automatically cater to changing operational conditions.
Whether your organization decides to use Standard Change or a ‘Low Risk’ change model is up to your governance requirements. At this stage, look to identify what these repeatable, common low risk use cases are.
At this step, we also recommend identifying a short list of teams (maybe start with just one) that you can test this new process with before rolling out to the broader organization.
3). Begin reducing change complexity of your existing change process through the adoption of select Modern Change features.
- Introduce or expand use of Standard Changes and Standard Change catalogue
- Guidance on proposing, approving, and maintaining Standard Change templates
- Proposing Standard Change Templates
- Standard Change templates proposals can come from both the Change management team as well as change requestors (via propose standard change UI action)
- Templates proposed should be for low-risk, well-understood, and repeatable use cases with a good history of success
- Robust standard change template proposals should have all necessary change details populated (e.g., description, implementation plan, backout plan, test plan, justification, affected CIs, impacted Services etc.)
- Approving Standard Change Templates
- Proposed Standard Change Templates should be reviewed by the change management team and relevant stakeholders (e.g., technical SMEs, service owners) – this may happen as a part of CAB/equivalents
- Review proposals for completeness, clarity, technical accuracy, operational readiness to support, service impact and compliance with security, regulatory, and organizational policies
- Assign ownership for ongoing oversight and accountability
- Maintaining Standard Change Templates
- Set up regular governance to ensure approved Standard Changes are performing as expected and not causing any incidents or outages. If a Standard change is continually unsuccessful and/or causes an incident or outage, the associated Standard Change template should be deactivated
- Track usage metrics and feedback to continuously improve template quality
- Update templates promptly after any process, tool, or system change
- Retire templates that are outdated or no longer in use
- Proposing Standard Change Templates
- Guidance on proposing, approving, and maintaining Standard Change templates
- Activate Risk Conditions for more data-driven risk evaluation.
- Risk Conditions are predefined property- and condition-based checks used to evaluate change risk (e.g., if the service/CI is critical à Risk = High, if schedule conflict exists à Risk = High).
- Risk Conditions are defined using no-code (e.g., condition builder) and low-code (e.g., advanced condition script)
- Risk Conditions are defined using no-code (e.g., condition builder) and low-code (e.g., advanced condition script)
- Risk Conditions help to:
- Automate the process of setting change risk and impact values based on data
- Can be triggered according to filter conditions
- Allow you to ensure that organizational compliance is adhered to
- Provide an audit trail
- Take the subjectivity out of risk decisions and allow the use of structured data
- To activate Risk Condition(s), you must check the ‘Active’ checkbox for each condition to be utilized
- By default, our dynamic risk engine will capture the risk outputs from the various risk evaluation methods you have activated (e.g., risk assessments, risk conditions) and set the change to the most conservative (i.e., highest) risk evaluation.
- Define initial change model and pilot use case with targeted team. Steps to consider as you do this:
- For legacy change customers, before creating anything it’s essential to ensure legacy change types can run in conjunction with models by updating existing Change Workflow so it can run in parallel. This will allow you to begin creating models as you work to migrate your change workload from Workflow to Flows and ensure your current process remains unaffected by running Change Models while at the same time, running your current Change workflow.
- Review current Change process workflow, Business Rules, ACLs, UI policies, Data policies, any customized fields, field values or other customizations, to gain a comprehensive understanding of any mandatory steps and fields which must apply to new changes models, as well as which can be ignored.
- Update current change workflow to ignore any changes created from a model. This ensures the current change workflow can continue to operate without conflicting with new change model flows. i.e. they can both run separately in parallel.
- Identify your current change workflow for Normal change. Navigate to Workflow Editor > Change Request - Normal is the OOB workflow. Note: your instance may have multiple workflows with different names.
- Checkout workflow
- Go to Properties > Conditions
- Set workflow trigger conditions to ignore any changes executing via a Model
- Update > Save > Publish workflow
- In a similar way, repeat this for Business Rules, UI Policies, ACLs etc. to ignore changes which are processing via a model, unless you need to have these also execute for model-based changes.
- Creating the pilot change model(s)
- Leveraging one of the ideal use cases identified as a part of step 2 (identify pilot use cases) and create a model for it. It may be easiest to duplicate and modify the OOTB Normal Change model.
- Determine the ‘Implementation states’ (this is typically only the Implement state)
- Define record presets (preset change field data)
- Set up security rules to restrict access to the model (optional, but recommended for the pilot)
- Create the model states which are applicable for the use case.
- Model states are the states that changes using this model can progress through (e.g., New > Assess > Authorize > Scheduled > Implement > Review > Closed OR Cancelled)
- Not all states will be relevant to change model use cases. Any unnecessary states can be removed.
- Create the state transitions (what states can transition to other states (e.g., New can only go to Assess OR Cancelled) and transition conditions (conditions that allow for automated or manual transition between states)
- Create the approval definitions for the model
- An approval definition specifies the approval action, who will be doing the approval. Approval definitions are called in approval policies. In approval definitions you define the following:
- Approval action (approve, reject, add user approval, add group approval)
- Approver source (e.g., approval definition, change request (can be dynamic))
- Approver source reference (e.g., user field, group field)
- Wait for or approval type (e.g., first response, all approvers, % of approvers in the group)
- An approval definition specifies the approval action, who will be doing the approval. Approval definitions are called in approval policies. In approval definitions you define the following:
- Create the approval policies and decisions for the model
- Approval policies define the inputs, rules and conditions that assess those inputs, and ultimate approval decision for a change.
- Approval policies are powerful in that they can leverage structured data within ServiceNow as the inputs.
- At earlier stages of change maturity these policies may only look at risk and state, but as you make use of additional data these policies can become more complex and robust.
- At later stages in the Modern Change maturity journey we’ll define other operational data and external data that can be used to augment approval policies and drive more robust change approval automation
- The approval definitions defined in the prior step will be used as the possible outcomes of the approval policy decisions (auto-approve, auto-reject, route for manual user/group approval)
- Create or update the flows to associate with the model and approval policies
- Approval policies will not be associated to or trigger with any changes unless they are tied to the relevant flow in Flow Designer
- There is an OOTB action in Flow Designer to ‘Apply Change Approval Policy’
- If you are creating a new flow, we recommend duplicating one of the OOTB flows and modifying it
- It’s best practice to create flows that are unique to both the change model AND the change model state (i.e., state-based flows). This will ease ongoing maintenance of these specific flows. Flows can be easily duplicated and modified to fit other change model use cases.
- Test the new change model, associated flows, and approval policies
- Check that the following are in place: access controls, appropriate record presets and read only fields, model has the correct states, manual vs automated state transitions execute as expected, and flows and approval policies execute as expected
- Deploy initial change model to pilot teams and monitor effectiveness using available (Change Success Score, Change Model Success, Change Velocity, etc.) or better yet, build your own reporting and dashboards using Platform Analytics.
- Leveraging one of the ideal use cases identified as a part of step 2 (identify pilot use cases) and create a model for it. It may be easiest to duplicate and modify the OOTB Normal Change model.
- Summary & putting it all together.
- This first stage in the maturity journey is about setting up the foundation for expansion into broader change model usage, adoption of additional modern change functionality, and enabling a transition away from legacy change implementation technologies (e.g., workflow, change types)
- Note how the different features within Modern Change are modular in nature. They are defined and maintained individually but are put together, in different combinations, to define an organization’s change process. Change models define the change process for a particular use case, approval policies define the governance, and state-based flows define change state validation and progression.
**Our team is still working on building out our more detailed recommendations for maturity steps 2-5. Please refer back to this article periodically to see these additional recommendations and review any updates to this maturity journey.**
Other questions
Back to top & table of contents
How is Change Management related to Release Management?
Change Management is the process of managing changes (planning, scheduling, assessing, implementing) to an organization’s IT infrastructure that may impact IT services or systems with the goal of ensuring that changes are deployed in a controlled manner and do not negatively impact IT services or systems. Release Management is the process of managing the release (planning, designing, building, testing/validating, deploying) of new or updated IT services or systems into production.
In simple terms, one can think of Change Management as the final gatekeeper with the objective of protecting the production environment and Release Management as the implementation process that prepares new code/changes ready for deployment to production. Before the product of a release - a new version of an IT service or application - can be pushed to production, a change request is necessary as the final gate to minimize potential negative impact and provide traceability.
Learning & Resources
Back to top & table of contents
Where can I learn more about Modern Change?
- One of the best places to both engage with us and customers like you is ServiceNow’s ITSM Community page. There are a few key articles related to Modern Change you can reference:
- Modern Change Management Launch & Learn series – webinar series covering an overview of what Modernizing Change means and deep dive sessions into key capabilities we provide to support Modern Change
- Modern Change Academy – monthly, ongoing webinar series that covers one Modern Change related topic. This article has the link to register and links to past sessions.
- DevOps Change Velocity Community – Community page dedicated to assets related to DevOps Change Velocity. Helpful assets include:
- Now Create Collateral – assets to support in your implementation/adoption journey
- DevOps Change Velocity Fundamentals
- Now Learning Assets – courses to support in your understanding of ServiceNow capabilities
