hello everybody Good morning good afternoon good evening Welcome to this iteration of the modern change academy Uh where we're going to be focusing on change models and flow how we can help you get from from zero to one Uh my name is Kayn Castello I'm an outbound product manager within ITSM Uh with me today I have Danielson the inbound product manager for change Uh and we'll be leading you through this uh session We'll do a little bit deeper intros in just a second but before we jump into it I do have to show this safe harbor notice Um there are going to be some things that we may talk about in this presentation that are forward-looking Um please know that those are kind of based on our best understanding of factors at this time but those things can change So don't take anything that's forward-looking as set in stone All right Uh from an agenda standpoint we're going to do introductions first Uh then I'm going to take us through what we commonly hear from customers like you around your challenges and kind of the core outcomes you're looking to achieve uh through your change process Uh then we're going to talk about our perspective on a modern change solution and our latest um iteration of the maturity journey that we're working through to help you get there Uh and then we're going to dig into the meat and potatoes of this presentation talking about change models talking about moving from workflow to flow Uh and then a few demos related to that and then ending with recommendations and Q&A Okay Uh intros I'll I'll go first since I think we got a hand up but it might have gone back down Oh we got a hand up already Let's see Theresa was it No I don't see the hand up anymore Okay Oh no There was a hand up Oh Oh it's gone Okay People just testing the buttons Good Good I'm glad to see that Um uh all right intros Uh so my name is Kaylin Castle Like I mentioned I'm an appound product manager with ITSM Been in service now for about three years now Um done a variety of things while I've been here but most recently focused on our service resilience products So speaking to a lot of customers like you about things around modern change so change management and devops change velocity as well as release um our new uh release management product digital product release And with me I have Dan and I'll hand it over to you Hello there So my name is Daniel Um I look after the change and SLM products from an inbound product point of view So that means I'm responsible for the the road map and the innovation the engineering behind them And I work with Kaylin who's the uh outward space of change management with service now over 10 years working in implementation Did a lot of change management implementations led the teams to the ITSM in Northern Amir and led the architects out of UK and then joined the product teams a few years ago So yeah Kaylin I just there's there are a couple of hands up I don't know if they're real hands up Uh Paloma you got your hands up as well I think we'll probably just press on unless this urgent or Yeah I think so This will help with this housekeeping slide I think to set some We'll have time at the end right As it says there for sure Definitely have time at the end So um like it says here we'll have time at the end for Q&A Love to see the hands coming up now Um it'll probably be a little hard for us to do that throughout Actually you know maybe Dan you can stop me if you see any that are persistent we can stop and ask ask answer any questions then Uh but in the meantime please use the Q&A functionality within Zoom to ask questions and we'll either save those for the end to talk about live or we'll answer them in the chat Uh so so everybody can see the answers there Uh this presentation is also going to be recorded and shared to community So if you need to reference it later or share it with a colleague or a peer um you can do that on community It'll be up in about a week And then after the event we have a short survey Uh we love hearing your feedback So please please fill that out Uh Paloma I'm going to actually allow you to talk since your hands up Do you have a question You should be able to talk Okay I'm just going to press on then Okay Um so let's let's kick this off with a poll Give me one moment I'm g to watch this poll Okay Um if you've been a part of our modern changemies you've probably seen this question before but we like to ask it What does modernizing change uh mean to you Is it increasing automation Is it managing a higher volume of change Is it enabling changes to happen faster Having more accurate risk um better experience for your requesters and change approvers and implementers Uh is it moving to a more federated process Um you can It's a multiple choice question so it could be everything It might be everything Very likely is everything Give this just another five seconds I'm going to end it here because I think the trend is clear All right Sharing results So as you can see and is what we expected it's it's a pretty you know even spread across these these different outcomes Uh but we often see that a better experience for requesters and other folks in the change process is a big one and here in this group increasing automation is big as well Okay So so what do we hear from uh customers like you uh in the many one-on- ones and one of many engagements that we've had with customers we've heard some clear themes around challenges that uh they face as they try to keep up with faster development cycles and new governance governance and regulatory requirements The first theme is related to the need to balance a desire for increasing the velocity of their change So how fast they process changes with their imperative to maintain stability quality and compliance around their um estates So customers are only ever seeing an increasing volume of change year-over-year I think a stat that Dan shared with me is that a lot of our customers are seeing change roughly double year-over-year So a lot of more changes every year Um and that's due to more distributed product development adoption of DevOps greater product complexity a number of factors And organizations want to handle this increased volume without a proportionate increase in the volume of incidents that they see Uh and they also want to comply with their enterprise GRC uh requirements as well Additionally because many quality and compliance checks are validated only once changes are um made to production or just before they're being deployed to production customers often experience avoidable fire drills in that period of validation just before deployment that could have been more proactively remediated Um so they're thinking about how do we automate some of those checks How do we shift them further left in the process The second theme is around a common desire to evolve Uh but we often find that inertia within organizations can hold hold customers back Um so existing stakeholders are often hesitant to adapt and disturb what works Um change has been around for a while and it's been working for a while Why do we need to change it Next um particularly for customers who have legacy implementations of change uh we see a lot of waste in their process due to overcustomized arduous systems and processes that have grown to try to accommodate um kind of so much and as a result have become a black box and are really daunting to to change Uh and the waste around these processes puts additional pressure on budgets And finally uh the third theme is around transitioning from feeling to a more datadriven form of governance and around decisions Uh so for change in particular the lack of traceability to the right data to a change request can slow down approval decisions Additionally without a holistic view of a change's impact assessing risk can often be subjective Uh and identifying failed changes that cause incidents or outages is is difficult Um so without proper data organizations are heavily uh held back in their ability to define policies and enable automation over their change process So these challenges are keeping a lot of organizations in what can feel like a break fix loop So things are breaking and you're just rushing to fix them holding them back from being able to actually scale their business deploy innovations faster and uh manage costs more efficiently Uh and this is where we think modernizing one's change management process can be be helpful Okay another poll Oh I never stopped sharing that Okay I'm going to launch this next poll Um this poll is related to the first and related to what I just talked about but are you feeling the pressure to modernize your change uh from your business If so what what's uh the cause of this imperative Again this is multiple select And second question here is what's the biggest challenge you face in in modernizing change What's what's holding you back if anything is um around getting to a more modern change process Give you all about 20 more seconds to respond here Let's see a Q&A Hey D you got that one Thanks share Okay So it looks like in terms of of pressures to modernize it's again as we expect a lot of these these different things that we're talking about uh business expecting faster time to market uh needing to respond quicker when when things are found to be uh vulnerable Um increasing focus on compliance But the challenges that uh this group faces mostly is around awareness of features and information that will definitely be helpful this session It's one of our core focuses and then buying from different personas in an alignment That is a harder challenge but we also hear that quite often from a lot of folks Okay Moving forward Um so so what is our our modern change solution from service now's perspective uh we believe that that by taking a federated model approach to change we can enable change which as I mentioned is often overburdened and complex particularly for legacy implementations to be uh broken up simplified and better fit uh your business requirements This not only helps increase the throughput of change by allowing teams to move faster and leverage automation but it also will help improve stability by right sizing and governance over your change process and reducing the burden u that a lot of customers have over uh their normal change process in particular to accommodate so many things So how can you achieve change modernization Um shown here is our perspective on an outcome focused customer maturity journey for change Uh this is our latest iteration of this You might have seen a different version of it in a prior session but um we keep trying to evolve this and make it more useful and impactful for you The top portion of this visual represents the outcomes at each maturity stage that can be achieved and the bottom boxes in red represent the data that we believe should be available to you at each of these stages to leverage Um I'm not going to go through this thing in in super great detail here I think we'll have probably a follow-up session on this specifically as we we refine this and nail it down But I do want to mention that we are planning to build um really more detailed prescriptive FAQs and guidance that align to this maturity journey for our customers to reference as they they embark on this this modernization journey So keep an eye out for that We'll make sure that it's published to community once we have it It's it's work in progress right now though Um so at a high level through this maturity journey we aim to help customers with legacy change implementations visualize how they can move to adopt the latest and greatest uh features within change while at the same time not impacting their business operations uh and realizing value over time incrementally Um and this all starts with really evaluating what you have today for change So evaluating your ASIS process identifying use cases where you can begin experimenting with some of these new change features like models flow approval policies just to get more familiar with what's available and what it can do It then moves into expanding the use uh from those initial use cases to more use cases So you can begin to um kind of reduce the technical debt over your ITIL change types that you have and you can begin planning building and testing the migration uh of uh your change types to models over time And once you have that foundation of everything built upon models and with flow it's then all all about building upon the data available to you to use in your change process to drive automation So you can use things like scheduling data uh risk data uh operational data around the change So things like incidents and outages You can look at historical performance of your change process through success scores Uh you can even use things like engineering data if you bring in that data into service now And you can pull all of that data into more robust approval policies that help drive automated governance over your change process And that's kind of several stages in the middle here uh of this journey Along the way we also recommend thinking about simplifying your change process by looking at products like digital product release uh which we think pairs really well with change U we see a lot of customers typically stuff a lot of validations in their change process by virtue of not having a full release process for a lot of their software changes in particular So how do you set up a release process where you do a lot of the validations when they actually are relevant in the phases of your release and development versus having to do them all just before change Um and by the end of this journey we want customers to get to a point of having a nearly fully automated change process from creation through approval uh as well as the ability to leverage some of our more um kind of optimization focused capabilities like uh Genai recommending future uh models or templates uh for you to consider to accelerate your process even further So that's at a high level Um but like I said we're going to talk more about this probably in a future session Okay one more poll There will be one more after this as well Okay this one's just around getting uh an understanding of your familiarity with with change models Um are you aware of it Have you used it Have you used them for a while Are you getting started You have no idea what it is Already got great responses Okay so it looks like uh a little less than half are uh getting started or already using models Some have been using it for a while That's great to hear Um a lot do not know what models are haven't heard of them So that's great That's what this session will help with Okay so let's talk about uh two key components of getting started with our modern change solution It's just worth calling out a 21% saying they've not heard of change models We we we have a do we have a slide at the end that points people back towards the the site and yeah head head that way uh because this is like an add-on to those sessions we did last year so if you're one of those 21% they never heard of trade models head to the link at the end of the presentation have a look around we've got plenty of material sorry go no that's great yeah as Dan called out we we did a launch and learn series last year that's on community that really digs into each of these uh things in a lot of detail we're going to talk about models and flow and and good detail here but there's more introductory sessions that we have already posted Um okay So first I'm going to talk about uh models but what you actually see here aren't models These are ITIL change types that likely you know quite well Um standard change is around lowrisk repeatable changes that are pre-approved Emergency change is for low or no lead time changes So fix on fail fix or fail situations Uh typically done after the fact Uh and normal change is really accommodating everything else Um so uh it's it's a pretty robust process Typically has the uh most layers of approval Traditionally within service now these types of changes the ITIL change types have had many technical artifacts associated to them So there's a state model defining the relevant uh change states that it progress through There's templates that you can define that help populate uh frequent data within uh these use cases for these changes uh and there's a workflow to help facilitate the process of these change types which calls on things like business rules etc to trigger things outside of the workflow uh and as well contains the tasks and approvals that are executed throughout the change process The primary challenge with these legacy change types that run on workflow is that um they're each all incorporated in a singular monolithic workflow So all of these different technical artifacts are incorporated into that workflow Uh and that workflow has become often highly customized and complex and difficult to maintain and this directly leads to kind of a blackbox feeling that I mentioned uh earlier and it makes it hard for customers to adapt their process So today in practice many organizations will have a number of change use cases sitting within their legacy change types Uh normal change has the most uh it contains things like patching infrastructure application lowrisk changes more than this as well Uh with standard change we've seen um a lot of customers use uh standard change for DevOps changes as well Uh even though we think DevOps changes probably should exist outside of standard change just because they aren't necessarily low risk or repeatable There probably should be a level of governance over those Uh and within emergency change we also see customers use um that for unauthorized change And what this has meant for a lot of organizations is they've attempted to adjust the logic of these change types in that large complex workflow to accommodate all of these use cases making them ever more complex overburdened and ultimately fragile and hard to to touch and modify So where do customers move from here If this sounds like you this is where uh change models can help and shine Um so here on this slide on the left you see the model versions of those same ITIL change types Um note that they're a little bit smaller than the circles we had in the prior slide The the relative size of the circle represents the relative amount of of changes um we think that uh should fit into this model Uh and on the right side of this are some federated uh use case examples of models for other well understood change use cases With change models what we allow customers to do is create fitfor-purpose models for well understood use cases uh and separate them out from the legacy change types thus simplifying those legacy change types in the process So think of this as making normal and standard change smaller and needing to accommodate less thus making them simpler and easier to maintain And at the same time the separated use cases that we we defined can move through their own processes more quickly as they only contain the relevant change states transition criteria approval policies and automation uh that fit that use case So today out of the box we provide the three ITIL change types uh or sorry change models that you see on the left Um and these can be leveraged to initially transition uh two models and flow from workflow over time Uh and as for federated models we provide a few examples out of the box as well Things like change registration cloud infrastructure unauthorized and devops One thing that's uh really important to note here before I move on is that change models can be used in conjunction with your legacy change types meaning you don't have to cut over and use models all at once Uh which would make adopting them I think quite difficult for many customers In fact what we see and and expect is that most customers transition over time to use models Um typically we see them first starting with a pilot or P of a specific use case Um and then as they prove the efficacy of that use case with some teams they can then uh expand the use of that model and then look at other use cases for models and over time through that reduce the burden on normal standard change making them easier to ultimately migrate from Uh one thing to call out here is that change models within them and you'll see this in the demo have rolebased access controls So as you define those initial PC use cases you can actually restrict the use of those models to certain user groups uh within the platform um or assignment groups as well so that uh you can test it out with specific teams that that you want to before rolling it out more broadly So uh it's really common for organizations to keep using their legacy change workflows as they do this migration to models um because standard emergency and normal are really critical for business operations And over time as you simplify those the the use of those workflows you can get to a point where you're at a state where you can migrate them to flow Okay Um so just to dig a little bit deeper into the anatomy of a model within change models themselves uh like the legacy change types there's artifacts Uh the primary difference though with models is that these artifacts are not directly embedded into a complex uh workflow Instead models and their artifacts are modular Um so change monitor managers would define the change process within the model itself So that's where you define the states that the model can move through the transition criteria uh between those states Uh separately from that you define the flows that execute automation for certain states Um and separately from that you define the approval policies that can be called from flows as well So flows and approval policies as well as models um are modular and flows and approval policies can be shared across models You can duplicate them and modify them Um and what this does is it just makes maintaining and updating the different components of a change process or a change use case much easier as opposed to having try to trying to figure out what you need to modify in a very large uh workflow One additional benefit of models is that they can also better facilitate the capture of structured data for particular use cases Uh a really good example of that is the uh DevOps change model that we provide out of the box Um this model would be used when changes are created automatically from DevOps change velocity uh via pipeline executions And what it does is uh it helps associate a lot of that DevOps data to change requests uh for auditability sake and traceability And what this data then provides is the ability to reduce uh MTR if an issue occurs just by having by virtue of having that commit data and planning data and security and test data to those changes So it just helps with MTR and it can also be used to automate the change approval process further like I mentioned by using a lot of that data in approval policies as well All right last slide I have here on models just to explain kind of how they work and visualize this for you Um this share shows a a view of different change models uh as well as use cases and um examples of applicable change states for those models So in a normal change model you progress through uh kind of all of the typical change states from new assess authorize schedule implement review to close Uh but for a use case like change registration where you're just registering a change that kind of a third party is making that you don't have control over So it's really for more for visibility you don't really need all those states You just have four states that are needed Schedule implement review and close Um so it's readily apparent that if you have fewer states that helps accelerate the change process But uh important to note with with these models uh because they're fit for purpose um they also progress more quickly by the virtue of the transitions and and policies that you define relevant to them uh and how it can work with the data within those changes change use cases themselves Okay going to the final poll and this is a poll about flow So flow is the other really critical piece that fits with well flow and approval policies that fit with u modernizing change and moving to models Um so just want to understand your familiarity with flow compared to workflow We talked about it a little bit but we're going to have one slide I think that that goes into better detail on it Kaylin just a quick question came up in the Q&A while you were talking So uh are we sharing this deck We can Yes it'll be I think it'll be posted to community as a PDF All right I'm going to end this poll share the results So it looks like uh we have about was that 30% of folks who um are using Flow or they're in process of migrating to Flow Um most uh 40% do not use flow but they're looking to migrate to flows from workflow Um so that this is what the rest of our presentation will be relevant to that Uh a couple 20% haven't heard of flow and um some aren't looking to migrate just yet Okay So let's talk about workflow uh uh workflow and flow and and uh the difference between the two and what it would take to uh think about migrating So a critical step in modernizing one's change process within service now is and moving to a more federated way of conducting change and realizing the most out of models is to migrate away from workflow to flow Um boom here's a here's a visual of what workflow looks like in the in uh the platform um workflow was a really powerful capability uh and what it was able to do but uh truly was a little bit cumbersome in how it was structured and vis visually displayed uh as well as was difficult to modify and maintain So on the left here you'll see an example of what a simple workflow looked like This is what the out of the box emergency flow was Um and this is before any customer modified this configured it customized it based on any requirements Now just extrapolate that to you know having this implemented for a decade all these new requirements come in over time and you keep modifying and making this even more and more complex I I struggle to understand what's going on in this simple form Just imagine for some customers what it looks like after a decade Um so this complexity is really has what made modifying workflow uh such an arduous task for many customers and why um it's hard for them to kind of adapt their change process to more the more modern ways of working that we're seeing today So now let's compare this to our modern change uh solution leveraging models flow and approval policies and how it's architected Um so starting with models each uh change model contains the process over which a change will go through Um so models contain the states and how those states can transition from one another uh whether that be manual or automated So if the automation is simple like waiting for a certain field to be populated that can be managed within the state transition conditions themselves in the model But if the automation transition is more complex like needing to call on approval policies or waiting for completion of several tasks that's where flow becomes relevant Um so it's important to note that not every change model or this transition between states within a model will need a flow associated to it In fact uh most don't For example it you know typically at the new state when you want to move to authorized uh you you want the user to you know submit a button saying request approval Um so you don't really need a flow there But typically we see the assess authorize and implement states use a flow to automate and other states are sufficient with either manual transitions or simple automated transitions defined within the model themselves For assess and authorize flow is where approval policies are called and applied to changes And for implement flow is used to check for the completion of all implementation tasks and they're um once those are all completed it'll move it to review The best practice around uh flows is what we call statebased flows So you want to define flows specific to both a change model and also the specific state in that model Um and what this does is it makes it so that when you update and maintain adjustments to that flow or the process based on new requirements or changes in your process uh you don't need to touch the entire change process You can focus on that specific component making the maintenance a lot easier U the other thing to note about flow is that they uh because they're modular they can also be duplicated and reused for other change models oftentimes you might have a flow that would be applicable to another model Uh you would just duplicate that rename it just so that you know kind of what you're using in that process and you can uh maintain those separately The last component or piece uh in this architecture is approval policies Um so just like statebased flows they're defined specific to a particular change model Uh so in this example here we have a a lowrisisk change model approval policy uh and approval policies are called uh with from within flows to check against the conditions defined in them So they have a bunch of input parameters like uh uh change conflict data risk data operational data engineering data Uh and from that data they can make automated decisions over those governance decisions over those changes Uh just like flows approval policies uh can be duplicated and adjusted for particular use cases So the best practice here is to um maintain them at the at the change model level Um I want to at this point acknowledge that um for a lot of our longtime customers uh this is a really great technology to use and I think there's a lot of benefits to it But I think something that we acknowledge that um we haven't done the best job of is helping provide proper you know utilities or tools or guidance on how to how to get there and do that transition Um so that's what we're really trying to work on here in this presentation by giving you some initial recommendations and then like I said earlier based on that maturity journey that I shared earlier we're working on building out kind of more detailed prescriptive FAQs and guides on how to step through that maturity and help you get to a more modern change solution All right final slide for me here is just quickly summarizing again the benefits of moving from workflow to flow So on the left you'll see some of the challenges encountered to workflow Uh there's hidden logic in a large complex inflexible workflow Uh and ultimately it ends up serving as technical debt that blocks the use of uh newer capabilities And on the right you see the benefits of moving to models and flow Uh you have more modular components that are easy to be duplicated They're easy to reuse They're easier to modify They're easier to test They're easier to deploy They're easier to maintain Uh and they're also easier to configure Okay That is the end of my section I'm going to hand it over to Dan Dan I don't know if you want to answer any questions before you transition into the demo Okay cool We're going to answer some of the demo I've been I've been um I've been answering questions as we've been going through Uh we have a quick look while we're doing that Okay we can leave these till the end now because I'm going to do some demo And Kaylin maybe you can grab some while we're Yeah I can I can look at that depth Yeah Okay Right Cool Um so looking at looking at change models Kayla you gonna are you going to step through these slides You're going to I'm going to talk through them You're Yeah Okay So we've got a normal change and a standard change and we're aware of these things We've got a lot of changes in normal and normal is the capsule Right So normal is normally complex typically a complex process And as Kalin showed on the previous slides like there was a little like a section on the left hand side where there was like an example uh workflow that was end to end for change And really to fit that on and to show it that that isn't anywhere near as complex as the workflows I've seen customers have for end to end change I mean one of the biggest things is like roll backs between states and how you handle that And you know there can be tons of logic and I've seen them are truly scary when I look at some people's normal change process and then handling all the different types of change within normal that that go into the normal change process Um so trying to push something through the normal change process also sometimes triggers things to happen that you don't want to happen for that type of change You know it could be triggered things like lead times or cab or if you're doing a DevOps change quite often people place it into standard change right or then we get into the paradigm of standard change and standard change typically doesn't have any approval It's something that's repeatable and low risk Um so you want to be able to enable the organization to do this thing really fast using a template using a very standard process Uh and you set up standard change templates right And like for inance here at service now I think we're at 98% of our changes are standard changes very very fast changes using a template But there is a ground in the middle right And we can move on to the transition here Caleum right Where we're thinking about things that are generally low risk Okay So you have something which if you do it during a blackout window you need an approval right or if it's done to a critical system right criticality one system you need an approval or maybe if it's done in production you need approval subproduction doesn't so now we get into slightly more complex things and what we're doing is in there and to answer one of the questions that came up really early on about datadriven change what you would do with normal and standard change in that thing is you would allow the user at the start of the change process to decide you know they they've got a standard change they want to do it and they're going to follow this zero approval process using a template and if it needs any approval then it can't be templated You can't use that process It excludes it So they follow the normal process They have to fill in the form Or maybe they use a change template but they're not quite as rich as standard change templates If you use a lowrisisk change what you can do is you can assess data on the change to see whether it needs to be rooted for approval So you can set up a lowrisk change that most of the time goes through with no approval Or if it's in a subproduction environment and you know that from your CFDB uh then it would go through with no approval or maybe if it's during a blackout window or during a maintenance window it has zero approval If it's during normal business working times then it's requires a low level of approval and if it's during a blackout window then it requires exact approval So what you can start to do is you can start rooting more changes down this kind of gray area between standard change and normal change Um so looking at lowrisisk change and what what the the features of a low-risk change are Um you can use things for normal change you can configure the state condition So the the transitions between states you can configure specifically for your lowrisk change You can have an approval policy specifically for lowrisk change You could have task for low-risk change Now it's worth mentioning here that looking forward in releases and we're looking at probably targeting Australia but it may be a little later than that We're looking at opening up the ability to have a change template that looks like a standard change template for any model right So we're looking to be able to allow you to use the ability to propose a a really good change as a template and then attach it to a certain model so that people can use templates and have tasks attached that get generated according to that template for any model they want Just to clarify that the template will be attached to a specific model but as a change manager you can set up templates for anyone So what that allows you to do is have highly templated changes that don't necessarily need zero approval right And having highly templated changes you all tell me customers tell me is a really good thing right Having the ability to have this um template out there in the catalog so someone can pick to do uh a network IP change on a firewall or they can uh pick to do you know a certain server reboot or they can pick to change a cache size on a database or something It may be something that needs approval but you want to template it That's what we do in would do in lowrisk change Okay So I covered a couple of things there One is that gray area between normal change and standard change So not full approval for a normal change Not quite zero approval for a standard change but maybe some edge cases you want to pick out that may require the change to be rooted for approval And the second thing is expansion of templates beyond just standard change So you can propose version retire templates for models beyond standard change Okay Uh I think that's what we're going to cover there Okay Time for a live demo And I haven't pre-anned any of this So we're going to see how it goes But um we're going to have a quick look at ching new change model in the starting place which is in our um service operations workspace uh admin center Let me share my screen Okay So it should just be about five minutes It's quite a quick So my service operations workspace admin center For those of you who aren't aware this exists if you go find it You can see here I have a link to service operations workspace admin And if I click on it it takes me to this page And you can see in here there's areas you can go in and configure different bits of service operations workspace So service operations workspace is where you know modern net change incident some item stuff even uh lives It allows people to work in a seamless way across IT center processes Everything I'm going to show you and some of the screens I show you are in our more uh traditional UI6 we call it interface But for the moment I'm going to show you what we've done most recently because I'm a product manager That's what I do Okay So in here you can see we can make configurations to various things with this open workspace I'm going to go into change management So I click on change management and you can see in here we have some suggestions right these are to tie in what we're doing with these things like launch and learns live on service now events with our collateral So it's kind of grouped and themed in the same way so you can find your way around easier But the first thing we would say to do is start looking at change models And the reason we say start looking at change models is change model starts unlocking other things within a change process So by moving towards change models you can make your normal change simpler by taking changes out of it without actually touching the normal change at all You can just make less changes hit normal change You can make the changes that were a normal change flow more efficiently flow faster You can report on them better You can see what changes infrastructure are making by the model And in future releases you'll be able to have templates for that model limited for use in that model You'll be able to use datadriven approaches because within normal change it's complex to kind of attach data because you don't always know what kind of thing will be going through You don't know what to go to With a model you're able to specifically target certain types of data like DevOps right You can start saying a DevOps change needs to have work items It needs to have commits It needs to have a pipeline It needs to have artifacts A normal change won't necessarily have those things and trying to code in or or configure the normal change process to sometimes need some things means it gets more and more and more overloaded How am I in for time Kaylin Am I good Yeah you're good Okay I'm talking more than I thought I would Okay so we're going to change models Um so in here we have a list of our change models and you can see in here we've got flow designer as well So we're giving you handy links to take you to the places you need to go and configure And in here we have changes registration as an out of the box model We have cloud infrastructure just some holding places out of the box change models for you And then we have our known and loved ITIL change types We also have an authorized change in there I'll go into that one first Okay So if we look at what we've got in here we can click on one and have a look at it I'm going to set up a new one in a second but I'm just going to look at this one first So you'll notice we go back out of the workspace view into our UI6 view the one we're used to for years and years Uh the reason for this is we have a slight technical limitation around how this list presents We can't do it in workspace yet We will get there Okay So the reason I'm pointing this out to you unauthorized change is a really interesting case because we have a state flow We're using states from the normal change process but the changes already happened So we need to authorize it right We don't have to assess the change We don't have a new state It's happened right So we want to authorize it review it and close it Uh if we had an emergency change it might be quite a lot of you do this Um some of you might shout at me for saying this but definitely quite a lot of you do this You for an emergency change you do the change and then you authorize it or uh you go through a state of implementation and then you do authorization afterwards So you can see we're using the same states in a lot of cases we're just doing them in a different order or having less of them Having less states makes us more efficient Okay The other really interesting thing about unauthorized change in here is we have uh presets The type uh so in here we the type is set to emergency and unauthorized is set to true This unauthorized set to true means every time this model is open the unauthorized flag is marked and the change is true We know it's an unauthorized change So these record presets in here and I'll show you the configuration later They're not to set values in the justification field right They're not to fill in the short description They're not like a change template They're to fill in values that you know will be true for that change all the time And an authorized change will always have its authorized flag set as true Okay So it's kind of process basically rather than context Templates control content Models control process basically Okay I'm going to go into a new one now So let's go into here I'm going to do change show you how easy it is hopefully Uh so if I go in here I'm going to go with um let's call it um okay Uh and I'm going to say this change to in here we have a type The type if you notice here is set to model That's really important If I drop this down you can see the type field is being set here Right So we have on the change a model field The model in this one would be core info We also have a type field But normal changes the model is normal The type is normal For standard the type is standard The model is standard Um so you can see there they're kept in par that way If we're using a custom model we set the type to model That will become more become more apparent exactly why we do that later But it's to do with your trigger conditions is so that we can say it's so that you don't have changes being picked up as the type is normal when the model is infra right so it's important to note that when we have our own changes we would recommend that you set the type to model this is something we dropped into the platform at bad year okay in here as well I'm not going to set any other record presets we have security on the record too so in here we have the ability to say who can use this change who can read it and then who can administer this change model as well we can set them in here with simple lists Um I'm just going to submit the change first So save it And you can see in here now I've got the advanced security button ticked And we can also use something called user criteria A bit beyond the scope of this but this allows you to have more complex queries around who can write the change and who can read the change Your technical people will help you with that Okay So what you would do is you'd pick in that list something like all in for engineers And there's somebody in the background one of your technical people have already set up a user criteria for you They're used across the platform Okay So model states what we're going to do is we're going to add some new model states Now the model states allow you to pick from a set of states These can be configured We don't normally find people need to go much beyond these Right So normally typically I should say the states we have are a subset of the normal change state So I'm going to go new We have a new state We'll get to the initial state Okay And I'm going to submit that You can see we now have a new state And I'm going to go a new one And I'm going to pick authorize Uh I think you get the picture So I'm going to just add one more I'm going to review it and then close review So what this is doing is it's picking from a list of predefined states Again you can configure that list You can configure this list here if you want to Uh but normally you would pick one for these because normally we follow the same path I'm going to put cancelled in as well just for the sake of completeness And you can see they have a sequence as well That's the order they flow in So what we've done here is there's no flow attached to this change at the moment Right haven't configured any flow to fire when this change fires but we have a set of states configured for the change And what we can do in here is we can configure model state transition So we've got our states and we can configure what state we can move to and from without the need for any flow from new to authorized It's an automatic transition Save it first I get options there Okay And then we can set a condition Again we're going into the weeds a bit here and you know technical people may want to help you with this but this is as well something that maybe the slightly more technical or slightly more service now savvy change managers can set up especially using the examples we've obviously So you can have in here transitions and you can set what fields need to be mandatory for the change to move on or say when a field is populated the change will automatically move out of the new state So when you filled in the short description justification backout plan uh and you've put a CR on the form and an assignment group it will automatically move from new to authorize or you can say until you filled this thing in you can't move from new to authorize So and you can also do it with scripts again if you want to write some Java you want to go and call out to a different system or call an API or something like that It's all in there for you probably a bit beyond scope of this I'm not going to add a transition condition into this one at the moment Just we don't want you to Am I good for time Kaylin Yeah you have maybe finish this up just so we can do the other demo Yeah Okay I'll finish up there Okay so we have set up our change now And what we need to do now is we need to attach a process beyond the state transitions to this change Okay so we've we've set up the change core infra We've given it a set of states These states are specific to infra now we've kind of copied them into infra So when we set up a state transition on these they that transition will be specific to the core infra change Um we've set up the the preset So the type is model and the name is infra And if I now update that change we should have it in our list So if I refresh hopefully I said it was active I don't know whe there we are So we've got the change now available It's not active yet because we're still deming it We haven't attached a flow right We can make that active and then we can start using uh our workflow Okay Like I remember from the start of the demo was I going to show flow in here as well Uh here Yes I think it's worth showing you So what you've got now is your set of flows What we did what I did to get here is I clicked on this open flow designer but I actually just applied a quick filter on it as well to make things faster for us So you can see in here I've got I've actually filtered it down to just show the change flows and you can see that we previously we had end to end flows for change So change standard is an end to end flow for standard change But we also have these statebased flows So if we want to have an authorize if we want to use the authorize flow and I'll click into it you can see here that we have a flow right for authorize and so this flow will fire when the trigger condition is set is set and it will take care of authorization for us what we can do is we can either use this flow for our info change if we want to use exactly the same process for authorize as we do for no or we can copy it I think it's in here uh no we copy this flow and edit it to use it as a starting point And inside this flow we have the change approval policy So this is where we take the policy inputs and we approve the change So the components we've got here are the model and the states and state transitions We showed them earlier We've got the flow that will fire that change and we're going to cover the trigger conditions of this later Um and then we've got approval policies which have been called by the flow Generally what you do in flow for change is called approval policies So the example we've got here is we can copy this change normal authorized flow and we can call a different approval policy for infra It may be that we need to check slightly different things for infer or we need to route it slightly differently We can have we can have a flow that calls that specific approval policy does things slightly differently So what we're doing with the models is we're controlling the process that the change follows We're not controlling the content controlling the process Have I covered end of everything Kate I don't have the slide in front of me my screen Yeah I think you have Okay cool Do you want to take over Yes I will share recap Okay So in that demo that Dan just walked through um he walked through you know kind of creating a change model um end to end and all the different components and and modular pieces that fit together that that make that uh work Uh and this is for the lowrisk use case He showed about uh the access controls that you can can define within the model uh the statebased flow that you saw in in flow designer there uh for relevant stages within the model and also the approval policies that you can call from within those models worth there's a question earlier and I just worth answering it here the the interaction with flow who configures that who makes it that's an admin right or a technical person so this screen this flow we wouldn't expect change managers to be doing to-do list you have a very limited number of flows right and we would expect you to reuse them across models if you need a new flow or you need something slightly different it would be a story that you raise with your developer your engineers your admins to do Change managers configuring the models I would say that's within the realms of what most change managers may want to attempt to do but again you may want to get your admins to do that for you It's up to your governance model You need to talk to your platform Good Good point All right Dan's got one more quick demo about talking about transitioning from from types to models and some considerations and things and helpful things that we've uh built for you to do that So take it away Dan Just take a few minutes here I'm gonna be quick So I think I'm still Am I still sharing my screen Kayla I think you took over Uh don't let me stop sharing Now you are Yep Okay So in here you can see we've got a trigger on our flow And what we're doing is we're triggering this normal authorized flow to to fire uh in certain states So when the state is authorized and the model is normal if we wanted this to trigger for more than one uh type of model of change we need to add in an additional criteria in there So do or model is that I can pick my change out of the list He's enter right pick one there I couldn't find the one I did earlier So I think maybe because it's not active So in here we we're firing this when it's normal or standard change Um the important thing to note here is that this can work with you or against you Right So a lot of you at the moment have workflows that fire and they will be triggered on the type of change So you need to now we have the type is equal to model we've got that additional choice in the type field We can set the type to model That means that when you create your own models the type will be set to model and the out of the box configuration for end to end flows for all the traditional um uh legacy change bits will not fire because the type is not normal anymore The type is model You need to check those conditions So you need to check the conditions on the workflow to make sure that you don't get normal change workflow firing when you set up your new model It may be that you haven't adopted that yet You haven't got changes with type model It may be you're on an older version platform You don't have that choice You can add it yourself Um we recommend you upgrading rather than do that But if you need to you can The same thing happens if I look in here Um I look in the change request list This is again something that admins would do But you need to tell your admins to go through and have a look at things like business rules because business rules have conditions on them too And it may be that you want to apply these business rules to models Okay And if we look here it will pop up You can see in here we've got where the type is standard Okay So this will only fire where the type is standard You may want it to fire for other models You may not but it's worth going in and just getting someone to analyze your business rules and analyze your workflows at the start of for the existing logic that you've got Just make sure it's it complies with what you're going to do with models make sure it's using the type field uh to set the change appropriately or making sure that when you have new business rules that you put in that the conditions will cater for models So you can see in here we could change this one simply by going model and then we can pick standard in there instead Now the actual implementation how this done is probably a little bit technical right but once you've done it once right once you've gone through and had a look at the business rules and make sure they only fire for normal changes or the only fire for standard changes or the only fire for emergency changes once you've assured yourself of that because when you set up your new models you the type is equal to model they will be in their own area right you can play with them you can use them the existing logic the existing workflows the existing flows will not fire but it's worth up front just making sure that you understand these trigger conditions and how they work Okay All right So as a quick uh recap of that uh Dan chatted about some of the things that you can modify within Flow uh to and and also the business rules that you should check to transition from having them trigger off of type to model Um and there's probably some other things that we we didn't have a chance to get to Uh but we'll we'll have those in in subsequent how-to videos that we're planning to work on as well Um just for the sake of time want to get to this recommended path on on migrating to models Um Dan do you want to walk through this one or you want me to walk through it I can I can do it So yeah So start using the model field for your logic for your flows for your workflows Like I say that we have we have kind of future proofed it We have had a guardrail by having the the uh type is equal to model but just start using the model field for more logic going forward because the model will be the field that you use uh in the future Okay So start replacing the type condition as you go through when you have new business rules or when you revisit business rules Make your devs aware that you're using the model field now And then what you can do is you can experiment and learn with new change models Right It could be that infra change that I set up there You just allow it to be used by 10 engineers in infra to start off with to raise a few changes on firewalls and subdrouction to see how it goes to make sure the flow works You could then expand that and allow them to do production changes using it Um once you're happy with that how that cohort is working with that change and then it works well you can then scale it out and start using it say across all of info But you don't have to be everywhere all at once Okay you can keep your normal change working You can give this special new model to a few people using that user criteria or using the the access conditions Allow them to use it experiment with it wipe glove support and then when you're happy with it you can uh scale the adoption Um using state transitions is really useful So using state transitions makes your flow less complex You don't have to code those into the flow anymore They're encapsulated in the state itself They're really easy to see They're point and click Um so start replacing logic in workflows with state transitions or start building new new flows that have state transitions in instead of having it in the workflow Um and then use the statebased flows as well because having a flow per state makes that particular flow reusable across many different models means you don't have to have roll back conditions between different states It means that when someone needs to make a change to that flow they're only possibly affecting that state They're not potentially affecting every state for all of normal change So it's more granular It's more secure Um and it's a more efficient way of working Okay Kale Right Oh compatibility mode Look on our doc site for compatibility mode We have something called compatibility mode It allows you to work in mixed ways It's beyond the scope of what we're talking about today but if you are interested have a look on the doc site I'm sorry we couldn't cover it today All right I know we only have two minutes Want to quickly flash this call to action um asking you all to you know start experimenting with some of these modern change uh features that we talked about today particularly models You can do that subroad Nice thing about models is you can actually begin testing that um with with specific teams in production if if you're comfortable with that as well We have a launch and learn series um that we'll link out to in this document Please review that if you want to learn more about models flow approval policies uh risk We have we have a session on all of those things as well as some helpful blogs here In the last minute I have a couple questions that I've teed up uh to ask Dan live Um the first set of questions are from from Aaron Um I'm going to start with his his second question because I think it's probably the most relevant Is there any guidance on what to consider a low-risk change I'm challenged with educating practitioners on ITIL changes and I'm concerned about how they would consider what's low risk Yeah So I I would say that uh anything that needs an approval right that can be highly templated is highly repeatable So a lowrisk change is something that um may have to have some guardrails applied So if you like I said if you have something like maintenance schedules or you're using blackout schedules where you want to check them So it allows you to take a more datadriven approach to standard changes So kind of think along the same lines of standard change Think about the changes that you couldn't put into standard change because they sometimes need approval Think about the things that are in standard change and probably if you're you know being honest about it they should need approval sometimes Um think about standard changes that fail right that cause failure or impact and and so they're taken out of standard change and put into normal change there they're all really good candidates and uh also going forward you know we should have with a the AI based approaches we're using for change we're developing ways of identifying these types of changes these these groupings of changes so when you get a cluster of changes being made you get something that's being used frequently and is repeatable um and it shows as low risk it will the system will trust it and suggest you create a model that's where you'd be looking at maybe having a lowrisisk change model for it Yeah good answer Uh second question is around uh is there a reason templates aren't built into the playbook experience Do we see a future where that overlap may happen Uh possibly It's a big question Uh we're not thinking at the moment of using playbook in change Um we we may do that There are some opportunities with AI in playbook but um it's beyond scope Okay And then the last question I have here is from um Brian Um he's asking for any tips that we can provide to troubleshoot should a change not transition as expected Um he has this challenge with workflow He's trying to get started with flow Just any tips Um if you are getting problems with the change not transitioning as expected then raise a case with support and it will probably uh come my way So if it's not working as expected support will service support will triage that and make sure it's not working it's it's working as they well they will make sure it's working within the bounds and have a look and if there is something odd happening um then we will have a look at it for you I'm not aware of anything there but um yeah open application support or talk to your partner expert services team all right we are two minutes past thank you Dan uh for for the great demos thank you everybody for attending Erin feel free to drop me an email if you want on that yeah Sounds good Thank you everybody Have a great rest of your day Byebye Byebye