Multimodal Change
ServiceNow is pioneering the way forward when it comes to change modernization. Over the past few releases, we have introduced dynamic Change Approval Policies allowing teams to easily tailor automated approvals to individual change conditions. In Paris, Change Success Score delivered numerical expressions of each team's change success history similar to a karma or credit score. It can be used to evaluate the likelihood of future success, determine the level of change rigor required and serve as a basis for reducing change failures. In Quebec, we introduced another level of automation with Multimodal Change (Change Models) to deliver “fit-for-purpose” change combined the ability to leverage ML to predict change risk using Now Risk Intelligence capabilities. Leveraging the full power of these native ServiceNow Change Management capabilities increases change velocity and removes artificial bottlenecks that are inherent with legacy change management practices.
Multimodal Change is a new innovation from ServiceNow that delivers a convenient and easy way to tailor change related activities and flows to the specific use cases they serve. Multimodal change is an extension of the legacy ITIL change types. It allows for fully optimized change life cycles along with the ability to automate state transitions when certain conditions are met. The automation of state transitions is based on the change condition criteria defined by your Change team. This behaves similar to the way Dynamic Change Approval policies use change conditions (e.g., auto approve low risk changes) to automate approvals. Combining Change Approval Policies with Multimodal Change from ServiceNow creates a change automation superhighway without compromising stability or governance.
Multimodal delivers “fit for purpose” change models with a suite of succinct flows and flow actions built in Flow Designer. So instead of trying to force all change activity into predefined change workflows (Normal, Standard & Emergency), change teams can selectively transition to a wide range of “fit-for-purpose” models that are fully optimized for the specific use cases they serve (e.g., Change Registration). This new feature serves as a conduit for high velocity change and meets dev teams exactly where they are based on their practices, tool chains and maturity.
With multimodal, the constraints associated with one dimensional change types have been eliminated without compromising existing investments. For those customers that want to reap the benefits of change models and flow designer without transitioning away from legacy change types, we have mimicked the Normal, Emergency and Standard change types as change models to ensure the experience remains unchanged. Change Models can be easily tailored to a wide range of use cases and updated quickly to adapt to changing conditions on the ground. In short, change teams define state models and state transitions based on the use case it is intended to serve.
Few would argue that legacy change management practices are dated and in need of modernization. Transitioning to highly automated change programs can feel a bit like turning a battleship at times but with the introduction of Multimodal Change, the practice of Change Management is far more agile, flexible and dynamic. Change teams can quickly define targeted state models along with varying degrees of automation so that every change is managed with absolute precision. Now teams can begin transitioning segments of change volume over to these new streamlined experiences without having to modernize the entire program all at once.
While multimodal change is intended to replace the Change Management – State Model Plugin, Multimodal Change and the legacy Change State Model can be run concurrently. That means that each customer can decide when to migrate to Change Models and what degree of automation is acceptable. For upgrade customers, this new feature is NOT set to active out of box and the existing State Model behavior has been preserved to protect existing investments. For new customers, Multimodal Change with Flow Designer will be the default change management experience.
Multimodal change is a feature that every customer can benefit from. It is available for all ITSM customers. However, existing change behavior has been persevered for upgrade customers allowing teams to seamlessly transition from “types” and “Workflow” to “models” and “Flow Designer”.
Feature Highlights
Change in Flow Designer
Along with multimodal change, a suite of modern Flows and Flow Actions have been introduced as part of the existing ITSM spoke plugin. These are intended to further optimize change request processing and create greater extensibility when tailoring a model to a specific use case. Flow designer provides a very clear ordered list of steps which eliminates the need to traverse or debug complex workflows. Change flows and flow actions are targeted and easy to debug when creating change models. Change Managers are able to drill down into the specific activity of each step and have greater auditability since each phase of the model can be linked back to the execution of a specific change flow.
New Change Landing Page
A new landing page has been introduced with Multimodal Change as well to further simplify the change engagement experience. The legacy interceptor was preserved for upgrading customers, but this new landing page renders a consumer-friendly card view of the change models and pre-approved changes available to me. Hovering over the “State model” text on any of card exposes the state model for that change request card. All “Preapproved” change models show current success rate as well. You might be questioning how “Preapproved” changes differ from “Standard” changes and the answer is simple, they don’t. We opted to use the term “preapproved” since one of our key design principles was to make every aspect of the experience simple and intuitive. The “preapproved” label is intuitive regardless of the consumers background or knowledge of ITIL. All existing standard change templates are rendered as “Pre Approved Change” cards on the new landing page. Additionally, you can pin frequently used models for quick access or repeated use as long as you have been granted access to invoke that model. Change teams are now able to easily manage access to specific change models so that they are able to maintain oversight of the multimodal transition and evaluate related KPIs using the new Change Velocity Dashboard.
Creating State Model Definitions
Setting up new change models is both intuitive and flexible. Advanced settings allow for the evaluation of state transitions along with automation capabilities that enable high velocity change. In the example below, it is easy to visualize the simplicity of creating Change Model that are precisely aligned to the use cases in your organization.
- Create unique name for model
- Choose whether the change model can be invoked directly from landing page
- Select color for this change model card on the landing page
- Include a change model description for easy identification
- Assign any record presets (e.g., preset field values which will be read only)
- Declare the lifecycle states that are relevant for this model
- Specify the state sequence for this change (No longer bound by linear state models)
Setting State Transition Conditions
With change models aligned to the exact use cases in the organization, it is time to add some automation by configuring the state transition criteria. The state transition conditions are stored in the [sttrm_transition_condition] table and it is important to note that multiple conditions can be associated with a single transition. Conditions can be scripted or defined via condition builder. In the example below, it is easy to visualize how to set transition state conditions so that precise degree of rigor and automation can be added to any change model.
- Select the model state
- Choose if this state is the initial state for this model
- Specify if the transition can be automated when change conditions are satisfied
Choose from a range of predefined transition conditions or setup your own using condition builder or script. Select a table that this condition relates to and the condition will be available for models built on that table and/or its extensions. Automating state transitions has never been easier.
New Change Model Tables
There are a few new tables that come along with Multimodal change.
State Transition Model [sttrm_model]
• Allows configuration of a State Transition Model for any table using a choice list for state definition
• configuration of a table and a field for the use in the creation of a model
• At present, only used through the extension Change Model [chg_model]
Model State [sttrm_state]
• Holds the information for a state that can be used in the model
• This table contains values copied from the state field’s selected choice list entry
• Each model can contain a complete or subset of the choices available in the field
Model State Transition [sttrm_state_transition]
• Defines a transition between two states in the model
• When all the conditions are met, and the model is evaluated, the state will change
New Change Properties
There are also some new properties that allow access to the change model features. Enter sys_properties.list in the navigation filter and enter *change_model in the search bar to view and edit the properties associated with Multimodal change. These can be extremely useful for upgrade customers as the begin the transition from types to models.
Conclusion
In today’s markets, the business has to be able to respond quickly to changing market conditions. Many dev teams can deliver software releases multiple times per day or per hour and now change management can accommodate. With Multimodal Change, it isn’t just about going faster. It is about optimizing change with fit-for-purpose change models that provide exactly the right balance of velocity, stability and governance.
22 Comments
