for joining good morning good afternoon good evening wherever you are um this is the first session of our modern change management launch and learn series my name is Greg holis I'll be your host uh throughout the series and let's let's jump in so thanks for bearing with us everyone uh before we get into the presentation I'm sure you've seen this slide many times but we have the Safe Harbor notice here so there may be some forward looking statements throughout this presentation they're Bas they're based on our best understanding at this point in time so don't take anything set in stone as it could change the cover so there's a bit of a recap first we've got a lot to cover today uh so recap from the webinar we did two weeks ago just a ground ISM because not everyone may have seen that webinar or been on it um and understand where we are in the journey this is a specific part of the journey we're talking about today so um thinking about it you know as as I have for the last couple of years and as other people the call as well like Chris and cam Ira um the first thinking what the first step would be on Journey for people because we have a lot of features in change it's a feature Rich product and it's a critical product right it's a compliance risk process within it uh what we want to see is customers using the features we have within the product understanding what order to kind of deploy the the things we've put built into change to make modern change management work and and really the starting place the jumping off point for that the enabler for other parts of the product to be used is change models so as you can see here we've got a model based approach to change so that that's what we're going to talk about today I'll explore more about that later models is not our concept it's been around for a long time but this allows us to uh to have new ways of working whilst we continue to use the existing itle changes normal standard an emergency um we're not we're not getting rid of them we're not moving away from them we're just moving into doing something as well and that allows us to simplify what those changes look like technically simplify them simplify them from a process point of view and simplify things for end users as well and all those things give us the outcome of increasing change velocity being able to handle more volume and improving the stability and governance that change leads to so a lot of you will be experiencing um Paradigm Shift where you know as as organizations move do digital transformation as digital products get more embedded into the into what the business does it gets more embedded into what the business is actually directly delivering um we see a need to move faster uh we see smaller incremental changes that leads to a higher volume of changes as we have more it we also have a higher volume of changes as we have more security threats and vulnerabilities to patch again higher volume of changes and and it's talking across customers and some pretty big customer sample here it's roughly doubling in less than every year so the amount of changes organizations are seeing the volume of changes hitting the change team is roughly doubling um every year for all of our teams and what we're measured on is stability and our ability to implement governance so we have to move faster handle more and be stable and provide governance to that okay so we have a a a modern change adop adoption journey we'll talk more about the specific areas of this as we go through but what we're trying to do is we're trying to move away technically from what we had before so we're trying to uh to stay in line with what the platforms offering so for instance workflows have been around for a long time we've replaced them with flows a while ago we want you to be able to do that it's hard when you're working in change because you have a lot of of investment in the workflows that you have some people will have moved to flows already we want you to identify and Define new change models again that's what this webinar is about and use the state model Transitions and the state based flows uh within those models and then we have when we've done that we have the ability to start identifying opportunities to uh to improve risk management to improve the way we evaluate changes because what we end up with is purpose-driven changes so we can start looking at this particular Change Model we have the team's making that change and start looking at how they do risk in that area so what change models allows us to do or one of the things it allows us to do is it allows us to start dividing up our change but we'll talk about more about that in the next few slides while we're doing a recap okay so we have our iil change models right we used to them we know them if you're a change manager you will will know these types of change we have standard change emergency change and normal change and we know the definitions as well I don't need spend a lot of time in here but it's a placeholder to just kind of level set where we are so these three types of changes Define how we bucket change and what the process is around change traditionally within I based organizations and organizations around kind of the iil uh world the iil ecosystem um and we have repeatable change standard change lowrisk repeatable change and then emergency change is things that we have very little lead time for all we're doing after the fact and then everything else is normal change and that means we have a lot of normal changes we should have a lot of standard changes as well they can make things flow a bit faster but if it's not repeatable or if it's not low risk then it goes in normal change and the emergency change as I said before is one low lead timle as the fact also quite often unauthorized change fits in emergency change as well so what we have in the service now platform around these changes is technical artifacts so we do things like we have approvals built into our workflows we have one big monolithic workflow normally for each one of these change types and that has to handle in the instance of normal change a lot of different situations there's a lot of different types of change being thrown into that normal bucket and the workflow has grown and grown and become more complex as the change process has evolved so if you did your implementation especially if you did your implementation a few years ago you'll probably be in a position now and I've seen a lot of times where your workflow normal change is is it's pretty huge um and also because of that maybe slightly fragile It's Not Fragile in operations because you're not changing it but any changes you want to make to it require a lot of work require a lot of assurance and require a level of risk so with the artifacts we've got around change we have a lot of business rules that been built up over time that trigger certain things to happen in the change process outside of the world and we will have templates and we will have a state model which is leveraged to make the change flow from end to end and these things are pretty much nailed down for each one of these changes so we have a nailed down state model and then we have a workflow that fires which will call approvals and business rules will be called and there are three ways in which you can do this which leads to a high degree of complexity within normal change so as I said before within normal change we have many different kind of subtypes of change and within emergency change we have a subtitle of change within service now unauthorized change is an emergency change so what do we do with this this means that as the logic around the change CL as we Implement logic we have to handle more and more types and as we have new ways of working things like Cloud INF things like devops these do things slightly differently and we have to adapt the normal change process to cater for that sometimes we use standard change for devops right and that's I I think we'd all agree it's probably not a good thing devops changes are not low risk they're not repeatable but standard changes used to catch them because sometimes we don't have a better way of doing it and we do have a degree of assurance to the left of the change process with devops we have a degree of assurance in the processes they're using the tools they're using by the nature of devops that by the time those changes hit the change process we have already done some checks we know we've done some checks but what we want to do is we want to be able to demonstrate that from within the change process so we may need a different type of change so here's where we come across the concept of change models so you can see that normal change has become smaller because we've taken the other changes out of it so on the left of the screen we have our iil change models it's important to note they now change models I'll talk a little bit when we do the demo about the difference between the technical difference between type and model which isn't that great but we have our three iil change models and you get these out of the box for service now so we provide the models for you and we provide the flows to make those models work and we provide the states for you we also have the idea of Federated changeing models and we do provide some of these out the box as well I'll show you that in the Dem these this is where you can start to make things more appropriate for your organization you can start to work with teams that are out there in the in the the business or within it to create models that work for their processes that make make their processes as efficient as possible and by doing that we declutter normal change so we make normal change more of a target for optimization and as you can see as we move things out standard change devops change grows bigger we know what's happening within devops because we have a model defining it when they rise a change it's a devops change we know because the models have devops we know the changes within that are devops and we know the changes in standard change are now low risk and repeatable okay so I'm going to move to Dem now hopefully this will work hopefully I can switch across to my um to my browser we can look at an instance of service now but what we're going to cover in the demo is how models are different from types and uh why you should start using the model field instead of the type field so there's some actionable things you can do on the back of this course maybe start considering them maybe even start moving with them maybe you are starting to move and this will uh increase your understanding of how and why we use models so what are the first things you need to do to start using models switch across and okay so we're in service operations workspace in service now and I'm going to go and look at a change so in here we've got a list of changes right in the service operations word space view and you can see we can see the model straight away um and in in that model uh you can see at the top of the list we have some OT changes don't worry too much about them at the moment but it's example of models being used there are different type of change being done by a different bit of the business that needs to use change management and is rightly using change management uh to do its changes but we have normal and standard changes in here and if I go into one of these changes so I'll go into a standard I'll go into a normal change for this um we can see that we have the state model nicely expressed across the top so we have the different states that that change will flow through so if you're using change models this is reason one of the reasons to move across the change models this state uh model this progress bar will reflect the states that in the model and your progress within that model if I click on the details pagent here you'll see that we have model and type are both set to nor so this is important we're still using the type field we still have it there we're still setting it to normal we also have the model set to normal so we can leverage our logic to use that field or our logic can leverage that field so for your ital changes the type and model should probably for the moment remain in sync when the model is not one of standard normaly then we need to have a new type of model in there so we have something like infraa and the type then should probably not be set to normal standard or emergency so from within the type field the reason for that is is that you will probably at the moment have a lot of logic that leverages that type field within your instance that's in in a sense technical Deb so you'll have business rules that fire when the type is something or you'll have a trigger condition on your workflow that makes the workflow fire when the type is normal um by having a type in there some customers have found it useful to to type called Model we can make sure that our business rules don't fire our normal business rules don't fire when we have a model that isn't the normal but effectively from a technical point of view the reason we made this change the reason we didn't just extend the type field is the model field references another table change models we'll see that in a minute we needed to do it for technical reasons and that gives us a lot of power to be able to leverage things like the state model things like State transitions um within change models okay I'm just going to click on one more model so in here or one more type of change you can see for standard change into that it will show us the state model is slightly different for standard change because standard change don't have the same flow you can see that we're skipping the assess and authorization States so this is giving our users a better experience it's showing them where they are in that specific process it's not showing states that will then be skipped or we won't use if we had different states you know we might go and have a state for instance with a with a with an application type change um where we're using SL site reliability management where we go and get an error budget that might be one of the states it might be something you choose to do that would be reflected in here if you if you configured that in the model and again we're going to have a look at where that's configured okay so now I'm going to switch across and show you some change models so all I did here was just navigate from ui6 which is a more traditional interface Str still there into change models this is part of of the change menu that we used to use in the change navigation and from within change models you can see that out the box we have some models again because this is a demo instance I've got a few extra ones that are in here that have been turned on by another plugin these have appeared in change models because they're models that that bit the business want to use but for the moment we're going to focus on the ones that come out out of the box with change management you can see we've got normal emergency and standard we've also got an authorized change in there I'm going to click into normal change so you can see when I load the normal change model which should be loading now second okay you can see that what we do from here is we conf figure the model so this is an activity that would probably be done by admins with support of the change management team it's something you could maybe in future as you get more experience with this this process could be Federated out a little bit to other teams but the change team want to be in control of what models are available to everyone within it and you can see from here what we're doing this is important as well is we're controlling the process we're not controlling the content of the of the change there are some record presets in here and I'll give you an example we look at an authorized change later of the kind of things we want to control for record presets but they kind of relate to process so you can see here we're setting the type to normal so this means that for a normal Change Model the type is also also set to normal every time and that means that if you have logic which fires off the normal change if you have business rules if you have workflow triggers then they will still fire when you have a change model you can still continue to use your existing workflows you can still continue to use your existing business rules we'd recommend looking at them and kind of over time reducing that technical Deb switching them over to use the model field to trigger on instead but you don't have to do that immediately and you don't have to do it all at once okay from within here as well we have security so we have role-based access built into the models this is more important normally with the other models that you bring out the new models that that you implement because what we can do is we can control who has access to the model and that's important for two reasons first of all it allows us to control generally who has access to that model it improves the user experience as well because only that will only be available to them they will only see the models that they Med see if you have someone in infra who's not meant to be I don't know raising changes uh for applications will only see the infro changes change models the other thing it allows you to do is from a point of view of a pilot it allows you to make this model only available to a small subset of your users so you can be sure that whilst you continue to use normal standard emergency change types and models if you stand up a new model like something like devops or maybe something like patching you can make that patching model available to just a very small team to Pilot with to understand how it works to keep a close eye on it and that that allows you to kind of wipe glove your pilot that allows you to to maintain compliance by having people in the loop so you're mitigating the risk that that having that change that new Change Model the the the learning experience of having that new change model in place the risk that that contains by making sure that only a small number of people use it only a small number of changes will be created using it and that you can have someone watch those changes for a short period to make sure that that that model of change is doing what it's expected to do so as you do your pilot we recommend that you use these roles these read roles to to contain who can then use that mod so for normal standard emergency you want to keep the read roll very open maybe iil and SN change reader isn't here but for the new models you stand up you may want to consider reducing the group of users who can use that model to reduce the risk of implementing that model until you want to scale it out make more people able to use it okay uh if we look at the bottom here the other important thing is we've got model States so the model states are reusable once you implement them on a model though once you create a new state for the normal change model and this is given to you out the box that thing is then locked into the normal change so if you if I open this up and show you for the new state we have a set of model transitions that means that when if I make changes to these model transitions it doesn't change them for all the changes that use new it won't change it for the new state of the standard change it won't change it for the new state of the devops change it will only those model State transitions will only be available the changes you make will only be available on the normal change so we can be sure if you make changes to the normal Change Model it's not going to have a cross impact for those other change models the reason this is so important to look at now I'll show you the state transitions in a minute is you need to visit the state model transitions in order to adopt change models whether you're using workflow or whether you're using State based flow and we'll talk more about what state based flow workflow in a minute so I'm going to look in here so we have need to assess so these are the moves we can make from one state to another in the normal Change Model we can go from new to assess or we can go from new to canell I'll open up assess you can see in here we can go from assess to authorized assess to canceled or we can go back to New interestingly in here as well there is something else which you can adopt kind of further along the learning Cur we've got things we've got automatic State transitions to so again not something to worry about straight away necessarily but we can see that we have an automatic State transition that means if a task is rejected uh if sorry if the if the assignment group rejects the change it will go back to the new state so what we're doing is we're taking automation units of Automation and we're provisioning them in the model itself so the automation is directly related to the purpose of the change so if you think about that you've got situations like patching you've got things like app changes you've got infro changes you got Cloud changes how those changes flow what you want to be filled in on on those changes What fields you want to be filled in in those changes um and how you want to automate the flow when certain data is captured is specific to each model so if we go into the state transition conditions we can see we've got the ability to script um or we've also got some choices about what will happen uh to this in this state transition so as we move further along the maturity curve with our change models um as we move further on the maturity code with our change mods we can start using automatic State conditions and that allows us to take logic out of the workflow to take it out of the flows to make the workflow just about the kind of overarching change flow and then specific things that happen from state to state can be handled in here that makes your workflow less complicated that makes it less prone to failure when you change it makes it less complex making the workflows in change less complex is something that a lot of change managers a lot of service NS talk about move back here so we've just seen that we have that we have state Transitions and we can control them and we can do things that make sure fields are filled in before the change moves forward and what that does is again it improves the user experience for the change because it tells us exactly what we want to see for a change what we need to be filled in for it to move forward and if the right fields are filled in in a given State we can automatically move the state forward to the next date if we want to we don't have to but if we want to so it gives us the opportunity to automate the change flow so coming back to this level and just recapping again on our Change Model we were in the normal Change Model we can see we've got the states that you can uh that you flow through for this change including canel which you can go to from on to these states we've got the state transitions the reason it's important to visit these is if you are using workflow or if you using flow if you do not have the state transition configured from within here if you if this doesn't have a transition that allows you to move from for instance assess to authorize if the workflow tries to move it it will throw out an error it will make the change error so it won't move forward you need to you need to go in here and make sure that these transitions are correct and out the box the state transitions are in there for you but you need to just have a quick look at them make sure they're the things you want to do make sure if we've got like we've got the assess to new condition here make sure it's appropriate for you there's not that many to look at and you'll soon get used to them but these are things these are these are units that need to be visited for you to adopt uh change models and they will help you to decl your change flow okay I'm going to go back to one more thing before we head back into we flows and workows and we also have a a question we want to discuss live when you when you get a minute as well okay we will do that in uh in just a minute so what I'm okay we can do the question then okay T I see you're raising your hand here let me take you off mute if you want to ask it directly I was having audio issu can you hear me now yeah so basically in regulated Industries like I was like I'm a part of you know life sciences farmer um the concern is that users when they are presented with the option that is an easy in a path of least resistance will use those models as opposed to the model that they should be rightly using so how do we make sure that we have some gatekeeping control some guard rails around what model can be used by or by which system or by which team you know I don't know what the options are how do yeah so that's a really good question so at the moment what we're doing is we're only allowing certain teams to use certain models um and so that means that uh that you should have the right people using the right uh models of change um I don't think we we actually at the moment we don't support um having restrictions around then kind of what goes into that model so restrictions around saying you can only put a certain CI in the CI field for this particular type of model that's something we'd like to look into but for the moment those teams that are meant to use that model through the role-based access controls um you can control who has access so at least the right people the authorized people have access to that model and that's part of compliance is making sure that you know you have role based access that the authorization for use of a model is there and it can be restricted right the change still needs to go through approval in a lot of cases as well remember so so you know that that's that's part of the process a lot of changes will still have an approval step when you don't have approval it's either something that's inherently lowrisk like a standard change and that's something that's kind of EXT stand that we have already or it's something that's driven through automation so for instance the devops change you wouldn't want someone manually raising a devops change A devops Change Is raised automatically through the pipeline it's beyond the scope of this call but you would have a devot model that flows that has a certain State model to it has certain logic around it State conditions but you would make sure people can't manually raise that change that you would only do it through an automation which would call an API from the right systems that's assured and only those only that those systems will be able to open the devops change does that help uh yes sort of I mean the the the other um slight fuzziness that occurs is if you have an application um that then has all manners of changes raised against them some low risk you know um and some high risk and so on so we can't really control it by the application you know just talking about say maybe ECC manufacturing for sap you've got labels on the extreme End Printing labels there's some changes to labels being made which are extremely low risk but then there's manufacturing Logistics stuff that is pretty high risk so if you look at the application service level you can't control it that way it's the same thing with the team which is practically speaking if you give access to a team to do something as in an access to a lower path of resistance with less approvals or no approvals and something else that is more appropriate how do you stop them from you know using this or the other one so I think that's challenging in that in theory I get it in practice operating it is a little difficult okay so uh we have another uh launch session on um approval policies and Greg if you could make a quick note that we need to answer this question in that session specifically with the demo so the when we have changes that flow through as I said most changes will still require a level of authorization Maybe that will happen at more than one step maybe we'll have some approvals in assess as well like technical approvals peer approvals um using approval policy using Dynamic approvals we can look at the facets of the change we can look at the CIS which are part of that change we can look at operational data around it we can look at anything we want really that we have in the system or that we can call through an API and that can do one of two things that could either drive up the risk rating through risk conditions for example or that can directly make us root something for approval so we could still have a step that Roots the for cab if it's on a certain system if you select a certain system no matter what you know for for the sap model for example and that's a good example of where we might use a model um if they choose certain uh CIS with certain attributes on them we can then ensure that that change is rooted regardless of the model they're choosing into the right approval policy so what we're doing here is with with the model we're controlling the process that the change follows at a high level the states that it must go through what must be captured at each state and how those States May automatically transition who can see that model who can use it and who can edit that model as well that's what the right roles are in there and some certain data which which causes things to be pre-filled on the change I was going to show you that it's a good example just to go through igation working quite expected to that let see I'm going to show you an unauthorized change but anyway so we can ensure that certain data is captured and filled in on the change but then we can use approval policies to make sure that it has the right approval um the other thing that we can do with models is make sure that we have the right data captured so with different processes around business that are using change for instance devops we have test data that we can leverage um we have pipeline data that we can leverage we have stories and planning data that we can leverage so what we're saying is if it follows this devops policy we'd expect to see some stories for our commit and if it does have that we can allow the change to flow faster but if it doesn't have it and if you were Miss using that change your thing wouldn't have it then it would not flow faster so there's control by process and then control by actually by access controls as well so I think we do answer that question I know we answer that question so there's approval how approval policies work there's also how we calculate risk and that can drive approval policy and there's also how we uh the the the particular change mons give you opportunity to capture and enforce specific data being captured for that change to be able to move in the way it does does that answer the question a little bit better it's a really good question so I'm just waiting for for the me to to navigate back to models if that doesn't happen um I will skip back okay we're going to skip back to a recap on this and I'll cover flows later when my instance is recorded So we talked about the move from type to model and we talked about the technical reasons why we have a model field and a type field we talked about identifying the business logic which is triggered by the type field so looking at conditions on business rules we were going to look at workflows I couldn't quite cover that because my demo instance is having a bit of a moment we'll cover that when I when I come back to do the next demo but that's looking at what triggers a flow what triggers a workflow making sure we don't have the normal change workflow fire at the same time we have a new Change state-based Model flow fire we talked about States and state Transitions and migrating to them and the importance of looking at um State transitions when you're doing this migration we talked about role based access and controlling access to the change um and then we also so uh we're talking about how we make the the transformation away from normal change to use models making it low risk uh and we encourage you to experiment and learn with new models and we talked a little bit about how we can use the role based access to allow you to experiment with teams create new models in a safe way and then scale this slide's really as a as a kind of takeaway so we just listed out some of the things that are really important as you start moving for models so you know type a model the same we covered that start replacing the the type condition of business rules analyze your business rules and workflows and start replacing with model we've covered a lot of these already what I was talking about so this is ready so that you can take it away and follow through this list to help with your uh your migration to models so we're going to talk a little bit about identifying new models and we're not going to get overly complex with this there are lots of ways you can do this in practice and you will learn your own ways and what's appropriate for your organization we give you some models out the box and we're just going to talk through a few examples of models ready to get you started to get you thinking about where new models would be um some of our customers use a demand process for this as well so some of them use a process where people will tell them about ways they can have new models so you may have the model that is available at box for something like patching or you may find with the example we were given in the question like sap that you want to set up a new model for them because they do some of the work somewhere else to the left of the change process it's appropriate to give them a new model um but in these change models we have different layers of Art effects with the change so we have things like what states we're using and models allow the state to flow in a way that's appropriate for that type of change so it allows us to define a set of States why those stats together and use them a specific way for a specific type of change and control the state state transitions it allows us to use flows as well I couldn't show you this in the demo we'll show it in a second but there's a different way of doing flows with models and that's because we have different states that can be wired together in different ways and so we need the flows to be specific to each state so that if we choose not to use a state or if we choose to have states that go in a different order for instance an authorized change where the change has already happened and then we authorize it um we need to we need those flows to fire for that state so endtoend workflows become very cumbersome and a lot of a lot of you will have experienced this with a normal change flow being able to navigate from any given state to Any Given State between on a one big monolithic workflow is something that creates technical complexity you need to be able to handle in that one workflow any movement from any state by moving to state-based flows which is what we provide out the box and I'll show you an example um we can we can then decouple our flows from the end to endend picture we can say for this date this flow fires we have these State transitions from within flows we call approval policies So within a state we will call an approval policy and the approval policy can dynamically look at data on the change can look at things around the change and make decisions about how things approved and produce an audit Trail about why an approval happened in a certain way or why the change completely skipped approval so it's auditability as well in there we're going to cover approval policies in a later launcher there and as well different changes have different structured data so if I build this out we can see that things like devops have a lot of structured data around them and by bringing that data into the devops picture into change for devops so it's the actual change that you're raising as your pipeline fires we get visibility of of what was happening for that change why we allowed it to flow so fast and we can do that from within the change so when we when we want to audit the change when we want to see why A change is approved we have the data not just on the change record but around it we have related records like test results like stories like commits around the change and other areas have that too so you may find that within app teams they have other systems other places where data is stored and models give you the opportunity to say in this context this data is really important it might be that you want to look at the error budget that was in uh an application performance monitoring type situation and you have a specific model then for that that will pull that data and allow you to make the change FL faster because you can pull the data in you can inspect it with an approval policy you can have your states that are appropriate to that makes the change F faster and again something we're looking at forward looking is the ability to tie templates to models so the template controls the content of the change the model controls the process you will have lots of different types of content different specific contents for different models like with standard change standard change is a model right the standard change model you can have hundreds if not thousands of templates for standard change that use the standard change model so what this allows us to do is create a set of components that we can kind of decouple from the three ital change models and gives us opportunities to use new uh components to use new sources of data to use templates in a specific area so that someone if they have maybe they want to add an IP address to a firewall um we can have a template for that and we can make sure it only drives through that particular model so that's something we're looking to do in the future is tie templates to models for the moment templates are strongly tied to standard change as ever so we have standard change templates and the standard change model and the whole standard change structure works exactly as it did before within models the same way as it did in times but we're looking to maybe extend that as we move forward with service net relases just a little look again at the state flow so as you can see as we move through this as we re use these different states we have different examples I tried to show you what the demo example it didn't work but you can see for unauthorized change there second from the bottom we schedule we implement we review we close it's using the same States as normal it's just using less of them and in a different order so we haven't we're not creating loads and loads and loads of artifacts um that we need to to maintain what we're doing is we're saying okay for this particular state for an authorized change we're going to pick uh these states for that model uh we're going to wire them together in this order and then we're going to lay and state transitions specifically to that model to make that change flow or to prevent it flowing if it doesn't have the right data okay so change models so again normal change model standard change model so normal was a captal process and this means as we said before that it became or has become very complex complex business logic and workflows it's a high volume process so there's a lot of risk of changing it and there's a lot of things going through it it's only as fast in a lot of cases as the slowest change moving through so you may have a system which is where the the the risk on that change means that uh it has to go to cap because if you if you are in normal change and you rate A Change Is high risk it goes to cap it may be that for that particular uh type of change you're doing you don't want it to go to cap if it's high risk you want to have a service owner approve it instead you don't have the opportunity to do that within normal change without making the workflow increasingly complex that's just one example it may not apply to you um normally a high number of approvals because again the approval system has to cater for all the changes flow through normal it's high maintenance it's difficult to optimize because any opportunities to optimize take into account your changing normal change which is a high risk activity and as we said before a lot of customers reported to is that the normal change workflow the endtoend workflow and the logic around it the business logic is is quite fragile if you start poking at it bad things happen and bad things happen across all of change all of normal change which is a big area difficult to prove the improve the change experience we can't say you know if you open a normal change we can't say specifically this is what we want to see or specifically we want to limit the choices in this particular field to these particular things because it's a normal change we just don't know what it is it doesn't have a purpose it's normal it's a catch but if we have a change model we can start looking at opportunities to say oh we have this devop St over here we can pull that in or it's automatically pulled in so we don't need to have maybe uh one of the fields filled in the change maybe we don't need to have a test plan because we know it's over here in another system so we don't make that field something this has to fill in or we can automatically fill in fields because we know for that type of change the data is here we can pull it in so it gives us opportunities to make the change experience better and we can show and I'll show you at the end for our users in service operations workpace that change overview page allows us to tailor the fields that they see for each one of the states for each of our models so we're only showing them from that huge change form that has so many fields on it we're only showing them the fields they need for that particular state for that particular model that works for normal change models but it also can be extended into other changes where you may not want to see the same fields that on the change standard change so there is a high maintenance in in uh in a high overhead maintaining the the standard change catalog because as changes cause impact and then stand a change we need to review and make sure that that particular change is not standard anymore we need to look at the quality of change within standard change to ensure it's still appropriate for it to be a standard change some organizations have thousands of standard changes they need to do this with um sometimes people misuse standard change so they will not report failure and they will then cause stability issues which we don't see as change managers so it's difficult to to impose scrutiny on it and it's subject to intentional deliberate misuse and there could be compliance issues as well for instance using devops as a standard change is not really really technically I think um what we should be doing and we don't have the ability to apply operational context to our changes and what by that I mean you could have something which you want to be a standard change most of the time but you don't want it to be within a blackout window or you don't want it to happen when that system is subject to a P1 right now in production we can't investigate that with standard change because we don't have approvals so what we need to do uh is have a different way of doing change and this is just one example of change models so example would be low risk change so a low risk change sits in between normal and standard and it is a large amount of change that organizations do so it's not quite lowrisk or repeatable enough to be a standard change maybe it doesn't even have all the fields you need on the template right maybe maybe it's just not templated enough maybe it's it's something that occasionally has a risk profile to it um it may be that some teams can do that change without approval and some teams can't so it may be that a team is particularly good at do change particularly well qualified they can do a change with very little approval but you want to apply more approval to another team that's doing that change which has a less uh proven track record making the change so you don't get opportunities within standard change to be particularly Dynamic it's all or nothing you either do a standard change with no approvals it's low risk it's repeatable or you're a normal change and you could end up in a cap in the middle we can put lowrisk change and we can use approval policies to drive how that change is approved and we can incorporate operational data we can look to see whether there's any p1s right now whether that changes a Blackout Window whether there are conflicts whether the team have a good success record so we can drive it through operational context we can drive approval through performance um we can automate the catalog as well because if we're looking at these changes and we see a failure if we if the change that particular uh lowrisk change starts falling below a certain threshold or the group doing that change their success rate Falls below a certain threshold we can start imposing approvals on them so they have to ask for an approval or additional approvals if their success rate Falls um so that means that the low RIS change can flow faster in certain context and will be halted when we have other contexts that require it to be halted so it gives us a lot more options than standard change did but it also takes a load of changes out of normal change a load of logic out of normal change makes the normal change more efficient makes it less complex makes it easier to maintain and because we've put these changes in a bucket called low risk they're identified as low risk we make them if we look back we know it's a low risk change we know why approval policies were applied in a certain way we know why they were assessed in a certain way so it's auditable too um the hypothesis is that team will be more incentivized to report failure with these changes because they're not kind of taken out the standard change catalog for one failure so we may see some better behaviors being driven uh around change reporting in that area too so let's move across to a demo um so we're going to look at enter and flows State based flows we covered some of the other stuff earlier um and we also need to start looking at what we need to do to use State base flows as well hopefully my okay so we are now in the workflow un and if we if we look at here we can see that we have if I go into change so you can see we have within here we have the different change flows and if if if you look at these they've actually got for each one of the states as I explained before we have a specific flow so if I go into the normal authorized flow you can see this flow just handles the authorization step uh for change the normal changes Okay so here we can see it f an approval policy we've also interestingly for those who are technically minding with service now we've also got a parallel flow that handles on hold here as well so these flows are specific to the states within the flow so we can chain them together in different ways if we skip a state we don't have to handle that logic in the work in in the flow because as you move from state to state different flows and you can see as I said before we have uh we have state based flows for your Norm standard emergency and devops uh um models and we also have an authorizing there as well so we support state based flow for the models that we give you box if you want to stick with workflow for the moment for the normal change model or for the standard change model or for emergency Change Model you're welcome to do that we we we we we support that um there are advantages using flow we encourage you to move towards it we encourage you to also move towards State base flow um but we can understand as well that that might be a gradual transition it might take you a long time or you might not have time right now to look uh at the at the at the um normal change workflow it may be particularly big may be particularly clunky so here is the normal change workflow I'm going to load it up and show you it's it's an end turn flow even this one which is the simplest one that's out the box which most customers will configure when they do their service implementation and mostly this will grow over time sometimes this is huge sometimes it takes several seconds to scroll left and right and up and down see what's happening uh in the workflow I've had customers as well who only have one or two people that actually understand it enough to be able to make any changes to it at all or even customers that I've been to that feel extremely scared about making changes because the person who WR the workflow is no longer with them what this gives us an opportunity to do is to make this flow simpler by breaking it down into states by taking logic like the approval out of it by taking conditions out of it as well to check for values and putting them into the state transitions so it's an opportunity to make the normal process make the normal flow less complex and just handle what we need to do the high level things we need to do in each date in each flow uh I'm going to as well a quick look at triggers this is important for your migration So within you can see in here out the box now we've got the type is normal and the model is empty so that means this will fire when the type of change is normal and we don't have a model that means if you start using change models for normal change out the box this will not fire uh if you have a normal Change Model now you're likely to have edited this condition in your instances you're not likely to have uh a zbo instance like this one that's fresh you're likely to have your own conditions you need to check these conditions on your workflows to make sure the right workflows fire at the right times you don't have more than one fire ing it's quite simple to do it's easy to test but it's something you need to do it's one of the steps so as well as the business logic you have within your change the business rules the UI policies you need to check the workflows and make sure that the conditions are appropriate that's one of the tasks that you have to do when adopting models and it's a one-time task once you've set things up to use models going forward things should only trigger off the correct model okay I think one more thing I'm going to show that I didn't manage to show in the last demo so if I go [Music] back quite work change I was just going to show you an example from earlier unauthorized change of what we meant by content in the change model uh processing Change Model you can see in here that the record presets were only controlling things that would always be the same for that model that are important to the process of that model so for an authorized change we want to set the start date to now because it's now uh when we detect the unauthorized change that's when the change date starts uh we have a a short description that captures it's an authorized change and we also set the unauthorized field on the change to true we would never have an unauthorized change that didn't have the unauthorized value set to true so what we're doing with these record presets is we're not using them as a template like we do for standard change what we're doing them is is we're setting fields on the change that we don't want the user to have to change or to be able to change later so these are important from a process point of view so what you do with models is Control process templates are a different thing that control the content it's not a good idea to start trying to control content from within here generally okay going to skip off the demo now right to the sles everything seems to have warmed up a little bit be working a bit ni okay so just to recap the model States as we said before are reusable you have a new state you have an assess State we attach them to models and then we create specific State transitions for that model State transitions simplify the flow as well as we said before when you have a state transition that automates the collection of some data or whether a change can move forward from one state to another you're taking a lot of logic out of your workflow of flow for Change and the state based flows are also uh reusable so we can attach a state based flow say an authorized State based flow to more than one model you don't need to have a different a different flow for each one of your Chang models if the process is the same for authorized across three different models use the same flow for each one of those three different models to authorize it so some examples of change models so we're just talking about you know what you would look for when you're creating your new models or what you look for in the out the box models we talked about a low-risk change model before that's using approval policy to drive Dynamic approval in a very similar way to standard change but not as rigid as standard change so it can actually handle more tyght of change with better compliance with better velocity than normal change um and we can see in here we've got we can use automatic State conditions with this to make things flow faster we can attach Tas to the change uh some of the things we're talking about here are road map items so you know we're thinking about the ability to link task templates outside of standard change so being able to extend the use of templates so that you can attach templates to models and tasks to templates and therefore you can start uh making a more consistent pattern around how changes are used because we uh have heard from you that templates are used a lot within change or that people want to use templates a lot more we've heard that you like what we do in standard change and really we should be using that across more of change uh and what that also means is that you have more consistency so change is better with consistency it's better if we don't ask people to fill things in if we just know what they want to put in there if we help them it's better for the user it's better for the change process it's better for reporting so templates are a good area for us to move forward in we want to be able to see how successful those templates are so possibly maybe template success scores we have at the moment standard change success scores we could extend that to and putting these change templates into the catalog as well in the future so looking at a catalog of lowrisk change templates as well as a catalog of standard change templates again something for the future looking at deadbox change we have slightly different kind of key attributes key components for a deop change and so that allows us to drive the change slightly differently that's why we've got a model for it right we're looking at different data we're capturing different data our process is then driven to the purpose of that change it leverages the data to make the change flow as fast as possible but to apply the brakes if we don't have the right data or if something's happening maybe like a P1 in production at the moment that means we want to get some approval we don't it to flow naturally or we want to reject the change so what this allows us to do for devops is make sure when a devops team promises that they're following certain processes the guard rails are up they can't their pipeline is so well configured that they can't possibly do anything different than create great changes that are very stable for you move the data automatically into change examine the data and if they're doing it the change flows just like they said but what we can also do is by moving the devops data into service now we also start uh looking at an end to end kind of product Paradigm it's a little bit beyond the the scope or a lot beyond the scope of this call but what we're doing is we're having visibility of the devop data in service now that then we use for change it has a context far beyond just using in change so so the devops Integrations are really important beyond the change process change registration here a really important type of change that we sometimes misses an industry so what we're doing here is these are changes like uh when one of your vendors tells you that they are making a change to a system you don't get to approve it they're making that change it may be that you don't want to do other types of changes during the period they're making that change you need it on your schedule of change a full schedule of change increases change stability so in here we have a specific flow for change registration we have specific States we want to skip the assess and authorize and schedule uh states of that we want to move it to implement when they're doing it and maybe move out so have automatic transitions on date and time so that we know when the change is being implemented we know forward looking when it's going to happen it's in schedule there may be some tasks to check they've done it right so they've said that they've done this thing have they done this thing you may want to review the change in that way so we can drive better compliance around change registration uh and give ourselves a full view of the forward schedule of change and we can make sure of course with ro base access that only the right people can use that type of change as uh person pointed out who asked a question earlier on we don't want to make that model available so people could run through that production change for whatever it is without any uh authorization or scrutiny we may also want to use it for changes where uh a lot of companies don't have time or or don't have the the impetus or have tools for devops and other systems like that that mean they they don't want to quite move into the Paradigm of uh of a uh of a full integration with devops um these types of changes are better captured as change registration than as a standard change because they're not standard changes you're accepting that you're not checking these changes but you have them in your schedule you know when they're going to happen it's kind of like we we know it's not a good thing that we're not approving these changes in change management that we're not kind of intercepting the data but we accept as part of the process they've already done this their checks to the left where we are maybe the sap team maybe a devot team we accept that they're doing that um and we want to register the change and it's a very kind of low effort process to put in place to allow you to capture more of what's going on and I think most change managers agree capturing more around the change in the organization it's better than kind of hiding changes underneath you know grouping them together or hiding them underneath of the ban like extended change and just one last slide which is a recap on the change models we're just looking at again so what we've done is we've taken these change models out of normal change we've created specific flows for them we've kept our ital change models and we're moving them possibly from workflow to flow and state base flow over time but we've moved them into change models which then allows us to start running Pilots at areas like infa patching doing unauthorized change outside of emergency change which is a great idea maybe doing lowrisk changes we went through quite a lot of detail earlier so that's the idea about do to change mods okay and I think we probably better off there just wrapping and talking about uh see if there any questions to answer because we're getting short on time Q&A we're nothing in the Q&A um nothing no questions or we nothing left in the Q&A we've gone through okay anyone can come off Mike then I suppose we have a couple in the chat Harry or Cory do you want to come off mute and the ask sec Rich raise your hand if you do and I'll uh allow you to talk okay Richard are we sure we've got change manag on this call then Richard are you there Richard you're still on mute you can unmute and talk okay maybe we'll go back to that one yeah how about that Harry yeah can you hear me yes yep yeah so I just had a question about the Federate to change models that you were showing at the end are those just examples or those out of the box ones that are provided through some plugins cuz I have seen in my PDI I know unauthorized change I've seen devops that comes with the plugin but things like patching low risk change are those examples you're just kind of suggesting or are those available through some particular plug-in installation there's no plug-in for um it change management that we're probably all talking about here so there's no plugin that gives you any additional models there are the OT changes we saw before I won't go into that but that's a different bit of service now um the reason I deliberately covered those changes as opposed to the ones that are out the box is to show you that you can create your own that's idea you can create your own changes for this and I've been working quite closely with a number of customers some of which are on this call around things like patching changes around thing like around things like lowest changes we did ask a question earlier in the uh or had to have a poll earlier where we talked about having content we want to create more content around this we want to kind of get feedback from people uh we watch to see what models uh you're using in your instances if we see a kind of trend around people doing something sap seems to be one in there as well seems perfectly appropriate you know it may be that we start creating some content around these things as well or that some of our our partners in the ecosystem start creating content for change models so it's something that you can do yourself you get some out of the box uh and we will be looking to provide more content in this area that's the model State transitions the state based flows uh in the future okay perfect thank you okay thanks for the question uh Corey oh Cory okay Cory's question was answered no more questions do we have any in the chat we have a Carmen do you w to come off mute and us I think Ian Ian had a question Ian Baker Ian Baker yep hi can you hear can you hear me sorry yep um just a question around um sort of firewall changes so if we're looking at um our one of our third parties to do manage our firewalls y but we'd still want to see a record yeah so apart from sort of I don't know what system they use I think they use jir apart from sort of building an API back in what what template would we use going forward if we wanted just to capture them change registration so you make either through an API or or you'd enter them manually um uh a change registration model which because you're not authorized ing that change right you're just logging the change on your schedule of change yeah at the moment we sort we sort of authorize it because we're still partially implementing it but we're looking at getting third party to implement all of it so yeah it would just be for visibility really yeah you want to know when the changes are happening that's right visibility change registration is a really good example of of a model that does that um and you can make it available via API so they can log their changes automatically or you can raise changes it's fairly quick you can make the you can say what data you need um and you can automate through um State transitions you can automate the the movement of that change as well because you have things like dates that will key and tell you where the change is being moved to implement there or then out of implement as well that's great thank you it's a good example it's a good question any more question questions anyone else wants to come off mute and ask just raise your hand see one Jason can you hear me yes hi there um so I have three questions can one flow call another flow yes brilliant um you wouldn't do that I think if you had State base flows so if you have one for authorize and one for assess it's it would fire on that state change so you wouldn't have one flow fire another usually right that's that's but you can have one one flow fire yes yeah because if you wrote a complex flow that you want to use in multiple States say it checks something to do with risk time of the day CI lots of complex things and you could reuse it throughout all your models yeah um and then secondly probably not that important given you can do this is whether you can have parent flow where you create one flow a bit like um objects oriented inheritance and then you say right you can't tample with this flow but if you use it you can build extra characteristics on top of it Ira or Cam do you want to I I think I know the answer but ir and cam will give a better answer than I will to that question maybe Ira if I put you on the spot yeah no not at all uh I can jump in so the you can and your flow can have a subflow so if you want to share around some common functionality Define it in a subflow no problem and then your flows can just execute that in terms of creating some kind of hierarchy with your flows I'm not sure how um how obvious that setup will be will be to be honest with you uh in flow but in terms of creating common uh flows to be shared around or to be reused that's absolutely possible actions as well right absolutely yeah yeah you can you can define an action which does a set number of uh procedures if you like uh but it's slightly more restricted uh I would say but you can definitely build actions as well okay and then and then leading on from that imagine you an approval model um or you use some element across lows and lows of flows and someone says right I'm going to change that approval model is there an easy way to understand the impact across multiple flows like where it's used which flows Etc H um so if you're talking about a change model model um I mean ultimately if anybody modifies A Change Model uh and any of the state transitions in there of course it's going to affect any change request that's referencing that model um I would say I would say your model is at the top so if you're looking if you're drawing this out let's say and how you're designing it your model is on top that defines your whole process for your change request your flow is just a mechanism if you like of implementing uh uh your model because of course you can do it via workflow as well you could do it via business logic but your flow is just a mechanism for for implementing so your flow would be simply saying if the model is is the approval model um and I'm running at this particular Junction in the changes life cycle let's say when it's in the state of assess um uh that that that's the that's the scope that we're looking for or that we recommend as a best practice can we we see where approval policies are used in flo I think you just have to check FL right sorry sorry are we talking about approval policies yeah sorry approval policies not model so let's imagine you had a policy which is a a director has to approve a change when the hits the fan yeah you put that in lots of flows so you can put a break on instantly and then someone says well Hang on we're going to change that policy where where is it used in the system you can retrospectively check this via the change policy apply table so you can see the kind of change request that it's hitting but in terms of where it's implemented there isn't a straightforward method of doing that just yet but it sounds like a I think you you can tell what models of change you're using have used it in the past Jason by looking at the polic