cover the uh modern change management for digital services and products and we'll have a guest speaker today Daniel Davidson who will cover that that topic so um we'll go ahead and get started and I'll as we go here so let's let me let some more folks in Jason hi there Daniel hi everyone else hey Daniel how you doing great I'm all right I had to join as an attendee it wasn't letting joins the host so I don't know if you can just click on me and make me host oh I should be able to let me try that make host oops cancel make co-host there we go see if you're good there you have the uh I can share now that looks like I share awesome well thanks everybody uh welcome to this week's Digital Services Forum uh we're going to talk about modern change management for digital services and products with Daniel Davidson uh so first of all welcome new members if you're a new member today uh put yourself uh in your name in the chat and uh we'll welcome you to the group so welcome to all the new folks uh and um again we have a shared instance for the folks that are new uh if you want to take a look at that you can send John SPO an email uh he'll give you access to that uh quick overview of the vision about the Digital Services Forum uh really we're this is run by the Enterprise architect team here at service now uh really bringing together our customers with our technical leaders and sharing best practices and knowledge around how um how our customers are are are using the platform in digital transformation and the subjects that we talk about in The Forum are related to uh to that uh various aspects so it's the real world experience of how we actually deploy work uh in the platform and using best practices and knowledge from other customers as well um so feel free this is an open Forum we can share you have any questions uh you know feel free to post them in the chat so once Daniel starts his presentation I'll go ahead and monitor the chat as well so as I said today's agenda is modern change management for digital services and products a pretty significant area uh for our customers especially when we look at how change management is changing over time uh and how it's evolving I think Dan's going to hit on some key points uh around that so um so looking forward to the discussion here there a couple other housekeeping uh items uh you can join the community here and spread the word about the Forum you can send an email uh to myself or John uh if you uh would like to have uh the word spread around from your teams uh and we do Post these on YouTube so you'll be able to see them later as the recording uh there are other previous sessions as well out there uh so you know feel free to uh to go out to our Forum community and pull out all uh a lot of the different videos that we've already posted so again thank you for joining and without further Ado I think we'll pull it uh over to Dan hey everyone and uh it seems like the word is spreading because this forum is so much bigger than uh last time I presented which is probably like three years ago I think I think it was a covid call um where I presented on uh digital portfolio management with Caitlyn who's the yeah it's it's definitely changed a lot we we have over 1,200 now members uh so and um yeah so we've grown from we've doubled the membership by the way so for those on the call who who want to know we we've really expanded uh a lot so again customers are very interested in the subject and you know again we're getting a lot of traction on it so yep right I'm going to just going to switch across to my my screen and I'll be a slight break while make sure we're in am I sharing my presenter view or my prese view your present I've got the right one showing right no it's the present view or presenter view sorry yeah there you go are we good are we good now yes okay okay cool uh right nice to meet everyone so um the presentation is going to be in three main parts so first of all uh it should take about 20 minutes I think depending on how much we need to stop and interrupt for questions or whatever which you're welcome to do Post in the channel I think is there a Q&A is that how we're doing it or are they just posting in the chat uh they can post the chat or ask questions either one but we do prefer the chat initially while you're presenting and then we can we can save the end for Q&A uh for actual discussion but yeah just so we don't disrupt your your presentation but yeah happy to I'll be monitoring the chat as well feel free to drop drop questions in there okay cool um so F the first bit is very short which is just on kind of positioning where we are with digital product service and how change fits into that and why change is changing right what what the imperative the imperatives around changing change being for a while why that's been accelerated by thinking about services and products the second part of the presentation is around what we're doing in the change product to enable Federated change and other things um and then we'll show you a bit around the change road map that we have um in your planning around um what we've got now and what we see with adoption Journeys and and maybe what we've got planned for um future releases uh again with the context of um changing service management so without further Ado we should probably kick off um there we are safe High Harvest slide absorb memorize and move on okay so digital product and life cycle I'm know this skips the next slide you can see in here we've got this is a maybe a familiar service now slide we've put it in a lot of decks and it shows full life cycle and what's really interesting is for a long time when we talked about Services we were just talking about the thing on the right so service operate and so things would be delivered into service and then they go into an operational life cycle so you probably do a bit of planning before that happened but mainly around how it was going to be supported how the service was going to be supported or what that service looked like when it went live uh and we'd have service life cycles so we plan Services we'd iterate on Services we'd improve Services retire Services replace services but as we move into more into the digital product Paradigm we're seeing that there there are people responsible and teams responsible for that whole life cycle so going through from ideation on one side thinking about things developing products so then we've got like coding building testing planning uh handing over to operations so release and deploy and the separation of release and deploy which is really key to change and we'll touch on that again during the talk and also then the hand over to service so when it is eventually released or when things are deployed but service need to know about those two things so you've got a much wider life cycle that we need to talk about in terms of the visibility of of how we get from there's an idea to we're building the idea we're writing stories about it to we're planning when those things are going to be released and what the features are to we're implementing changes and maybe those changes are like feature toggled or blue green Maybe not on when they go into production but we're still having changes make their way into production and then eventually we got a date when we do a release and we switch things on and things change for our end users and the service teams need to be aware of all that happening so key to what we're talking about today is around separation of release and deploy that has a major impact on how we do change and also with the teams working like this with teams going end to end how do we allow these teams that work in a variety of different ways so teams that are doing you know looking after the frame maybe working in a quite a traditional way looking after the as 400s looking after the core Network versus teams who are doing things like patching versus teams who are doing things like you know complete digital products end to end digital products and they're using devops and they've got application performance monitoring and you know they're making a thousand changes a day and everything in between those teams right how do we enable change management to work in that Paradigm and so what that involves is a switch away from what we've traditionally got used to in change types going to cover that next so first survey we've got um what does Federated change mean to you guys I think we're all Syed up here Jason I think you can pop up the first survey here okay let me let me pop that up real quick there all the three questions are in the same one but we can uh yeah can you guys see that get a sneak preview of the questions I'm going to ask later so just answer the first one for now and we'll give a couple of minutes to um answer that okay it also gives me an idea about when I'm talking what we need to emphasize as you're answering this and I see the bars filling up so uh yeah okay so while that's just completing I'm going to talk a little bit about Federated change and we'll go into more detail as we go on but the question we get asked right when I attend exact briefings with you know big global companies and even talking to some of our smaller customers um one of the questions that pops up at kind of cxo level is how do I Federate things while I maintain control so how do I have all these teams sitting around my business that want to do things differently I have vendors who are doing things differently I have internal teams that have being brought in by marketing nothing to do with it who are delivering digital products and they're not following our centralized compliance rules they're doing what they do because they've been brought in and then you know quite often this when it goes into into the service layer gets kind of thrown over the fence at it saying now you got to look after this so how do we make sure we align those teams and we allow them to Federate and give the business the velocity it needs that Federation provides and the flexibility that Federation provides whilst we're still able to control so whilst we still have centralized control we still have control of our compliance while we still know that guard rails are being adhered to so I think we're starting to see I think most people answer that question now okay so most people should we uh can we Jason is there a neat way of publishing it or should I just read out what the results were yeah you can you can read out so about half the people said number one which was no idea please leave me alone right which I understand right it it it is it is something that's new to us and it is around you know how we delivering digital products into a service Paradigm um the second most common answer was that people's bosses are talking about that right roughly a quarter of you said people's bosses are talking about and that's what I have found talking to customers nearly every one's Senior Management or exec management is talking about this as a problem one of the big problems that's facing them uh 20% said we're getting there which is great right that means you're looking at Federated change you're looking at ways of doing things I'm interested to know out of that group maybe we can do at the end of the at the end of the presentation I'm interested to know how you're doing that with service now you know whether you're following the same ideas that I'm going to present to you whether you're doing differently whether there things that I can learn from you or you know or vice versa and around 8% said they already have a f ating process which is great so they're in that space looking at federating change so that teams can work at different velocities and have different ways of working so in service now we have I just my screen uh we have some technology that allows us to work with Federated change and that this centers around something we call change models and people are probably been service now the the more people I talk to are now aware of change models within service now so change models allow us to move away from iil change types we can preserve iil change types I'm going to show that in a minute but they allow us to have the flexibility to move away where it's appropriate and where we want to move away from ital change typs and so this is because change managers are serving a wide range of different teams right and trying to squash them all into one box doesn't quite work the same way so the hypothesis is bying breaking down the change process into components by allowing that to be built back together in a way that's compliant we can allow those teams to work how they want to work within the guardrails that the organization has been s uh maintain control whilst allowing them to Federate and have the Velocity they need to work it so we all know the ital change types I'm not going to dwell on this slide too much but for those of you who may not right we've got standard change and standard change are the repeatable changes which are low risk and what we do is we Define them in advance and then we let teams do them with very little supervision with no approval sometimes little approval fits in there but generally speaking and kind of dogmatically speaking no approval needed for a standard change what we do is we review those changes as a group from time to time periodically or when something breaks because of them and we decide whether we want to carry on doing it with no approval and the problem with that is if it's not a standard change it's got to fit in one to the other two changes that we've got and you can see we've got normal change which is the Big Planet these slides are kind of the planet slides right I've done them it looks a lot like planets to me in my head any um and so we've got most things are fitting within normal change and that means we have one big monolithic process which normally has a workflow that you have to kind of squint and scroll a lot to get through or or flow and what happens with that is it becomes a bit kind of maddeningly complex because you've got within that normal change process you've got to have you know if statement switches different processes different Tas that get spawned different templates that you can use and there's no real control over for instance what templates you can apply to an nor change you can generally apply whatever template you like to a normal change and then we've got emergency change which should be fairly limited so that's break fixed changes there are changes that we need to do sometimes we need to do them in retrospect in service now's way of working they can be unauthorized changes as well um or there can be changes that we've had to just fix it knowing that we don't have a change in place and then we're going back and looking at what change is happening or we need to make an approval very quickly in the kneecap to make the change happen and we try and minimize those changes because they're very risky right and they are prone to producing service outages they're also the reason that they're the way we fix service outages as well a lot of the time and what we have within this Paradigm is a whole set of things in service now that we can use so we have a state model which is pretty much now defined and agreed on for iil um in the industry so you know we have we have new we have assess we have authorized we have schedule we have influence we have review we have close right the changes go through those stages standard change skips the authorized state but it still get scheduled and the problem with that is that endtoend work for has to handle things like State Transitions and roll backs if teams don't do states and things happen if if if we need to go back on a state we need to reset tasks it also means that things like uh approvals are embedded in that big monolithic workflow even if we're using techniques like approval policy we still still need to embed all the logic into that big workflow we also have things like Tas generation embedded that workflow it becomes very complex so what we're trying to do is we're trying to declutter this big normal change workflow that handles most things so that we can be more specific and by being more specific we enable the organization to tailor change to Federate change out to specific teams that could be a digital product team that could be a particular service that could be doing change in a way which is or could have a way of doing change which is more appropriate to them so I'm going to go on to some more clets so if you look at what's inside these changes if you start going to break them down we start approaching something we've called change models and it's not service Downs idea it's been around for 20 years right it was another idea along the side itel that we have changed models and So within emergency change in service now you have an authorized change and I'm not sure if that's quite the right place for it to be but that's where it is um so that's a change that we didn't approve that we find later so something changes in the CNB or someone changes out of RAM on a server or someone released some code without change and we find out later we have a process for assuring that the right things happened even though they didn't happen at the right time and then in normal change we have different things happening so this isn't these are just examples there could be this many there could be less there could be more right you could have 20 or 30 of these different buckets within normal change and you can see from looking at this straight away that these things probably don't all follow the same process so you have things like patching we do a lot of patching right and certain teams certain Services certain product teams will be doing a lot of patching right so teams that work within your kind of middleware layer teams that work within windows or you know wiel or Unix or or whatever we're doing in their database layer they'll be carrying out a lot of patching and that tends to be done we have a lot of assurance up front a lot of planning up front changes are planned quite a way in advance normally and then when you come to execute the change you're doing the same thing repeatedly repeatedly repeat and you tend to open multiple changes at least even if you're grouping things you tend to open multiple changes to do patching so patching tends to be more about scheduling um you have things like infr changes that may need you know a very heavy process on approval they may need a lot of stakeholders in the room to be able to say the change can go ahead because you're patching one of your core routers you have Cloud infra which is a different beat Al together right that could be do an infrastructure as code which is done in a very very fast way you know instead of changing things what we're actually doing each time is destroying what's and recreating it ephemeral and immutable Cloud resources we have app changes so how we change an app is different and we may need to link a team doing app changes to infa changes and in a devops paradigm that product even though it may be a couple of services in your definition it may not be that product itself will probably own the whole stack right so apart from the very very base level of infra that they've got there which is like you know your cloud service provider and their core services that team will be doing the whole release and deploy deoy activity for the inferus code um for the configurations and for the app itself and the app code itself so they need to be coordinated um we've also got things in there like devops right devops and some of these other changes will have and increasingly will have shift left data and what that means is they have a lot of data in their own tools and they have a lot of process in their own tools they'll be doing planning they'll have code repos they'll be doing testing and security scanning and they'll have a pipeline that automatically deploys the code and checks or should check that these activities have met certain thresholds and they want to move really fast because they're like our pipeline means that we can't break stuff more or less all the time so we shouldn't need to do all this stuff and change we're just cutting and pasting stff to change and and at worst if they're a normal change Paradigm you could find that we're really slowing them down right we're having to make them wait until they have change approval boards every two weeks you know the agenda overruns they get skipped to two weeks afterwards and like why do we have to wait four weeks right and you end up stacking up changes and and you end up with these teams who are really fast and work best if they can deploy things frequently and small that's when they break things least you end up stacking their changes up and deploying it all in one go as it it was never meant to be deployed in that way and that in itself can cause outages so actually allowing them to have that velocity allowing them to have very little lead time get stuff out quickly check it works means that we will have less severe and even less overall impact service okay we've also got low risk change in there probably talk about that one later if I'm not overrunning hey Dan I had a question for you just kind of in the interum here yeah some of our customers are dealing with you know especially when it comes to devops change you know when we're multiple pipelines going at the same time and how to manage the governance on that like H how you know how how customers can help um what I would say is is determine changes need to be pushed at what time with this you know with a multiple kind of pipeline devops framework going on at the same time is that something you've dealt with or is it something you could comment on yeah so there's a couple of ways of looking at that depending on how mic how macro micro you're taking that like multiple pipelines so across an organization um you will have people doing activities and you may not want a developer to be running a pip line at the same time another set of developers running a pipeline even though those two systems are not interrelated just because it presents high risk right you don't want to do you don't want to change your core banking systems uh at the same time as you change your customer facing banking app in a bank right that that might not be the case by the way it's just an example I made up just now but yeah so um so that is to do with that's generally to do with um looking at blackout windows and also being able to compare when pipelines run now pipeline runs are tracked through our devops tool so so we have a thing called devops we have a product called devops which tracks pipelines running and we can we can actually monitor them for conflicts and we can hold pipelines uh if there's another pipeline running it's a little bit more involved and not the scope of what we're talking about today but we can do that now generally speaking that's more of a case when you have um a set of different people working on the same kind of stack and you want to make sure those pipelines run sequentially because you want to make sure the INF is in place before you apply the code or whatever that's generally done to the left of service now that's generally done within a release orchestration tool which is an area of the market we're not um we're not looking at at the moment is you know we're not playing in there are really good developer tools that are established that run that kind of stuff so within a product stack your release orchestration is done within your release orchestration tool but we can check to make sure that that kind of check has been has been done and maybe I'll plug something else in sorry Jason do you have that was it no thank you okay so just to just to add so this comes down to the separation of release and deploy so you have activities around planning um when you're going to release things when you're going to switch them on um and those are really your kind of big events that are happening and those are related to Features right when you're turning features on that's the level for digital product that you want to be making your services teams aware so at this point this feature will be activated or this set of features will be activated when we develop service now that's what we do right as a product manager I look at features and I say to the customer these features are being released or these features are being deprecated or these features are being improved I don't tell the customers about the stories generally ever really because we have loads of stories that we've got to write right we have stories we have defects we have enhancements we have dependencies we have all these artifacts that live within the shift left world that that people aren't really that interested in so when you're looking at your business stakeholders they're talking about release you know your big compliance activities has it been signed off by the business has it been signed off by legal have we done an operational Handover do we know what services taking this on has the hand over to them happened are we ready to go go no go can we go is everything in place to go let's go right those kind of activities are your release Pipeline and they're release activities and they're not change activities so traditionally people have placed them within change and that really slows change down because suddenly you've got meetings where you got to have 80 people involved and you're actually signing off a release within a change now there's nothing wrong with doing that for a lot of the kind of older slower moving applications but for modern digital applications for High Velocity applications what you want to do is continually be able to release code because it's like we know we're good to go with this we've written Stories the stories are linked to the code the codee's been scanned uh we've done our security testing we've been through uat and now we're going to prod with it and it's switched off it's feature toggled off or or maybe it's it's it's live when we go live with it but we've already assured that that feature at the point at which that goes into production we've switched to feature so we have a relationship between release which is looking at features at the top and then changes which are really looking at things like defects and stories that developers have been working on the individual defects individual enhancements individual stories that make up a feature or change a feature so just to recap on all that because I've just covered a lot separation of release and deploy by separating them you can speed up the change process because you take activities out which are kind of very time consuming and kind of much longer in scope put them in the release scope and the change activities then just become around making sure fit for purpose fit for use scheduled right um technically sound tested secure we can release it oh sorry we can deploy it okay so talking about that I'm just going to do the slide build again on this one right the devops change here so within normal change we had before we had devops within normal change and that means we need to either vary our normal change process to allow devops to work so say okay we don't need to send it to cab because it's a devop change and that means we need to think quite hard about what we're talking about with our change process we need to go into normal change and all of its documents and say there's actually there's something different for our compliance teams around how devop change Works within normal change so and then from a technical point of view we need to change the flows right we need to change our business rules we need to change how normal change Works to allow devops to work and that can be a risky thing to do both from a compliance point View and from an engineering point of view and it can be a time consuming point of view because there's a lot to test and a lot to unpick the other Paradigm which I see a lot is we make standard change a bit bigger and we put devops in there because it's kind of a standard change because we don't need to now the devops change is not a standard change there are times when operational teams need to be aware that pipeline's firing right you may have a P1 on your uh on one of your apps at the moment that means you shouldn't be running pipelines right so there are times when you need to know about what's happening in operations in your service layer and tell the developers about that so that's where service now comes in because we tie together the information about the pipeline mods we can Hal pipelines using the devops tooling that we have so pipelines in other tools we can communicate with them and tell them right okay right now we need a product manager to approve this because there's a P1 in our production systems at the moment can we just wait a few hours till that's cleared before we start running our pip so that requires a level of approval which means it's not standard change it could be as well that developers have fallen outside of the thresholds that we want them to fall in for them to be doing that kind of change right they might be failing a lot so we can incorporate things like success course a little more on that data so actually what we end up with and I hope I've not lost everyone on the way here but we end up with ital change models that work on one side but we're shrinking them right we're taking the other things out of them and by that the planets get smaller right normal change gets smaller the amount of stuff we're doing in normal change become smaller it's going to coexist for a long time within the Paradigm standard change is still there as well we will still have server reboots and standard change we will still have emergency changes but actually to the right of that line we've got all these changes which are specific models and there is a thing called a change model for normal standard and emergency change in service now out of the box right it's been around for a few years now so you can have a model for those things in service now and you can use and they work just the same way as they did using change types but we can also have models for these other types of changes so we can have a specific model for devops a specific model for an authorized change that actually reviews the change first and then um authorizes it have a specific model for patching that allows us to work within the patching Paradigm to tailor our process to the data they provide or the process they need so what that allows us to do is to take these things to the right of the line and speed them up and also make normal change simpler which means we can look to improve it we can look to change it we can look to take more stuff out of it because we understand more and more about what the normal changes were but we still have normal change we still have emergency change we still have standard change it's just hopefully we're using them a bit less so just to kind of recap on this we've got our planets lined up and we've got the normal standard emergency changes on one side of the line the it change type still existing and on the right hand of the line we've got Federated change models and what we have for these change models these specific change models how do we do it how do we actually make those flow faster how do we make them more specific so we can use a specific model for a specific service and make it so that it is faster more stable more compliant and we can handle more volume right how do we do that so from a technical point of view in service now we have a different set of States for these things so we have components at the state level that we can wire together to make a model so instead of a change like normal change having those all those seven states in it we can actually take only five of those States and wire them together to make a change model so we can say for instance with deop we're not going to have an assess phas it's already being done to the left we have new we have authorized which is normally skipped we have scheduled when the thing's ready to go and the pipeline's waiting to run we have Implement when the pipeline's running then we have review and close which review happen very quickly and it will close so we can do changes much faster because of that and also we have a specific flow for those States so for devops the way in which the flow works you'll have a devops flow or a set of devops flows which will allow you to be very specific about how devops runs it's not using the normal change flow it's using a specific devops flow which means when you want to do devops or when you want to alter devops how devops flows you don't need to change the normal change flow which is a big activity a risky activity complex activity for instance with patching you can have your own flows as well and we can actually decouple things like approval policies from this as well so we have a set of components we have state model we have a set of flows we have approval policies that are specific to that model of change and we have structured data that's provided like story data like test data and using a combination of those things that's what makes up the model so that's what makes up our change model and I'm going to give an example of that next so we're going to look again at devops it's a really good example but you can think of examples where a lot of customers I talked to are using change models now for normal standard and emergency but they're also using models for things like patching they're also using models for things like infra for firewall changes so starting to spin stuff off and start to look at doing this change differently um having a specific State model a specific set of flows and looking at the data for say having a devops model looking at the devops data incorporating into the change and making the change flow faster because we have this data and not affecting the normal change by what they do so the idea is that we have our change models and we get to do things like automate approvals because we know what type of data we're expecting for that change model so we can tailor approval policies to make sure that change flows as fast as possible we can have policy-driven state models so we can actually start to say okay well this state only applies if these things happen because we know more about that change model and we can start giving teams the ability self optimize to make suggestions about how their model Works without affecting the other teams that are in different models so what we're doing is we're giving the opportunity to encapsulate this stuff this way of working in a thing called A Change Model and then have technical aspects of it like the flow that it flows through State model it uses how it gets approved what tasks get attached what data in the change wrap that together and and have Assurance around it have compliance around it and say this is how devop change works for our organization or this is how high velocity Elite devops change works for our organization and this is how low velocity devop change works you can mix and match and all the time while we're doing this with those components I talked about the states the flows the approval policies they can all be reused across different models so if two different models are using the same approval policies that's fine if they're using the same States that's fine you know a lot of changes will still use new assess authorized scheduled Implement review and close they'll use a combination of those not necessarily in the same order not necessarily the whole lot okay so that's the end of the section on how we're doing Federated change in service now using change models um I think now I'm going to skip forward and we have the second um question which is is anyone actually adopting change models right now we get the questionnaire up again survey all up again while we're doing that there's a lot of stuff in the chat right there is quite a bit uh probably a little bit too much to go through but because there's a lot of commentary too our customers are and our members are communicating with each other and answering the questions so it's uh so it's really good this it's a really good cross collaboration there on uh on that uh I'm going to I'll re launch the poll um and then uh by the way I did save the results Daniel as well so that's cool but [Music] um um I did have a question for you as well so who who is responsible generally for setting up these models at an organization I think there's different roles that play a part in actually driving these models across the organization who do you use see that does that is that the change manager configuration manager I mean who who kind of runs that is from your perspective or or is it a multiple multitude of people depending on the the model okay so the operating model that we see has four layers so first layer you have admins who are responsible for actually building the artifacts right so they won't have the uh knowledge that they need to know how a flow Works um in terms of the steps in a flow or or you know what the approval policies will be but they need to be their building stuff for the change managers so the change managers won't be there like tinkering with the flows you know that will be part of the service now admin team service now engineering team the second layer then you got is kind of change process owners so generally there will be a nominated process owner within the business but there'll also in larger organizations there'll be a few people who have you know very deep knowledge of the change process and so what they'll be doing is looking at the data that they're getting back from change saying right this thing looks like a model to me you know I've got a change that's being repeated here or an area the business that needs to be working faster or moving faster you know looking at things like patching first looking at things like devops maybe they're using site reliability engineering there's a need and a want to move in a different way or maybe they're just a really fast team working on an app you know that that needs to be rolled out quickly and they're just they they're kind of screaming out saying the change normal change process isn't work so that comes into the change managers kind of change process owners the next layer down from that is Federated change teams and people may or may not like this idea but you could have vendors you could have third parties you could have teams that actually own a lot of their own Change Model you know they may not own the flows they may not own the state models but they may be given the opportunity to wire together a set of states and say this is what our process looks like this is what our data looks like this is the kind of process we want to follow and they'd work with the change managers who would then work with the admins to get that stuff built and put together for them so they would have you know you have a kind of catalog of available components things like approval now we have got a set of recordings that we're going to put out in the next couple of months around um kind change adoption journey and steps that we take to do this what I wanted to do on this call is just use the opportunity to talk around how this ties in with Services right and Digital Services digital products um so there's 17% are using models Beyond ideal change types which is great as well that's what we want to see people doing and really that's 60% of people who are using the change types who who using models for change types who want to see you moving and adopting new models right and again it's on the road map to give you a few we have examples in there but to give you a bit more guidance around setting those things up to give a better experience around setting those things up so from the platform you can kind of tell how you're meant to go about setting up additional models because at the moment it's a little bit obscure and hard to find I'll admit that we're looking to improve that uh and then we've got around about on the on the other two questions so I have no idea what you're talking about about 9% um and we're not but talk to me about it we've got about 20% of people in that category so again we're looking to get more materials out we're looking to advertise it more in the platform and we're looking to get better documentation and collateral around it so that you understand better and you can take advantage of what's in your platform right what you've already paid for so um so we want to make that better for you guys as well okay um should we do some questions Jason do you wanna how do you want to do this yeah yeah we can do some questions I um I think there's uh a couple of comments in the in the chat that are really interesting I think there's uh we've got a few uh major kind of areas uh that are have a lot of responses so one of them was um where and it's Allen where he's saying they're considering renaming normal change to custom change to emphasize that each requires its own piece and plans and to encourage transition to standard changes we'd like standard changes to be the norm and then there was a lot of uh a lot of comment commentary underneath that um I I think uh that that's a I get I completely get the sentiment there and I agree with it um what I'd like to see is actually just generally more templating of change right so making it easier for you to set up templates and have a catalog of things that you do like you know specific firewall change that you do and maybe have approvals in that because actually standard change was built for a day when we couldn't really do Dynamic approvals all that well but you think about a standard change right it may be that team a are really successful at rebooting servers and Team B are really unsuccessful at it what you want to be able to do is say team a you can do this as a standard change and Team B we want you to have an approval because it's a bit kind of ropey when you do and that would fall into the category of having an approval policy in the change that just checks as successful right so we have Team success scores in service now um and you can check the success score of a team which gives you idea of you know how many outages p1s p2s those kind of things it gives you a score based on that the last 30 days and it could actually dynamically roote a change for approval based on um whether that team is successful or not and other things as well you know if there's a P1 in production right now it may not be appropriate to start rebooting servers even though that's normally a standard change um so what I'd like to see is an extension of the use of templates within service now change so that we can begin to start looking at you know having that um I think it was on the slide previously I'll clicked it before we had um low risk change down at the bottom there which is changes that we see as being kind of lowrisk but Falling outside the boundaries of what we see at the moment as being you know that kind of very rigid standard change which you need to you need to really um tie down what that thing is but maybe have some changes which still have templates but you can apply approv policies you can allow to flow through maybe it's sub prod maybe it's in a maintenance window you like to go through that approval but if it's during a Blackout Window or there's a P1 right now you may need an approval and again that's the direction I'd like to take things as the change product manager for service now um I want to see the ability to expand on what we do in that kind of standard Paradigm but again using models for it so the idea of s to change completely agree but I want to make it kind of bigger and more flexible yeah that's great there's another one uh thank you for the answer that's that's great uh is there some sort of in this from Jackie M change taxonomy for change owners that goes back to like giving some direction and guidance to the actual owners around this um so they will select the correct categories before arriving at the appropriate change model and form do do that yeah so change models allow you to set who can read them so we either use user criteria um which is like for the C right so you can say a whole load of different queries to make this specific group able to use this type of change you can say that this group can't look at this change so the idea is when you arrive at that change form in s so which is where sorry service operations workspace when you arrive in that form it should only present you with the changes that you're meant to be using and that's one of the cool things about models is that you know with normal change you have to give someone a normal change and then throw that big old form at them um and then you have to give them guidance about what theyve meant to fill in and what they're not meant to fill in and how the process will work for them whereas if you have a model you can tailor specifically and say okay you're going to go to this model because you're one of the infr teams and you're not going to be able to open that change it's because you're one of the infra teams why would you be opening that change and then we're looking to extend that further and say actually the entry point may be a template um for your particular model so it maybe we have 50 different templates um I've worked at Banks where they have three or four thousand templates for changes so um so yeah we we'd like to expand on that but you can limit already out of the box you can limit or restrict who can see certain models of change okay yeah that's a good one there a couple other questions around the the the operating model around it because I think that's where people are because of the the different models and the governance I think that's some of the questions around you know um so one of them was from Althena uh so is a theory that change the change process owner is more looking at data and going back to the change managers on specific teams when there's when they're authorized automated or internally approved yeah to handle the velocity of change and the volume of change that's hitting our organizations like you know I was talking to a big bank the other day and they were looking at 750,000 changes a year a couple of years ago a million changes a year last year two million changes this year you know it's now doubling and the ability to process that the change process owners and even the change managers they can't be looking at individual changes anymore need to be looking across the picture and being able to say okay this is where we think we have problems this is what we need to start improving on and this is a potential model that we could use to make things faster so that we can put this in this particular box and you know template it and allow it to flow a bit faster and worry about it less um so again you know improving the product looking at finding ways that a process owner in the widest sense can look at how their process is performing and then surfacing that you know to to other areas of the product like uh for devops we have um we have time to Value so you can tell how long it took from the story being approved to a pipeline running and getting into production for other changes it's a little bit harder to assess that but we want to know how long a change spent in approval because if we're seeing a high amount of time in approval that means our changes are slow because generally approval is the thing that slows down change right other things so we want to start surfacing more data to allow the change managers to step back into kind of more second line role more of a government's role second thing is in terms of governance you will still have your documents around normal standard change and the whole point of the models the way of do models is you keep them as they are because they're going to stay that way but you can do an addendum that starts looking at things like okay we have these particular States we have these approval policies we have these flows these are the ones we want to use and actually that tells us things like you know when you look at your kobic requirements or ISO 27,000 or 27,1 that says a change will be appropriately approved it's like we do it through approval policies these are our approval policies and then the change itself will be of defined approval policies and then we measure it by making sure that we're looking back on changes and we don't have impact from our changes when we didn't think they were the risk is appropr calculated so there are ways of of making sure as well within change models that we have compliance uh good yeah that's uh let's see some of the other questions I mean some of them are uh I think you're presenting you might not be able to see the chat window but um uh there's a lot of discussion around examples of these uh do we have like kind of real world examples from a service now perspective of the models of models yeah yeah so devops is is the one I chose for this primarily because it's kind of easiest for us to get our heads around because devops has all that shift left data embedded so it's it's it's like obviously a different way of doing change where you're saying we're going to delegate respons to you guys in your devops pipeline for for making sure that thing that change you're doing is is fit for purpose and fit to go into production we're going to make sure that and you will just report to us that the test results you you had 70% pass for your uh unit testing and 100% passes on your security scans that you had Branch protection enabled on your pipeline and that all the work items had a story attached to them and we'll test that and we'll report it on the change so you're compliant but we're not having someone manually approve and look at those things and we're not asking them to cut and pay the second thing is it's very obvious the separation release and deploy for devops as well so for devops it's devops pipelines running is effectively a deployment activity the release activity the release train is separate so that's why I chose it as an example but you know you have infra infra Works differently for um for organizations a lot of them are doing models for starting off with something like firewalls and rolling it out from there Cloud the other example we've got on here so you know you have cloud and ephemeral resources where you may not be doing full devops but the way in which it works means that your change process is slightly different for those teams and it's highly Federated I gave the example of lowrisk change so stuff that doesn't really fit in the standard change box but is really like normal change is really heavy handed for so that's another example of where that happens um measur for those so they like metrics or measurements to determine between what a lowrisk and normal change is and guidelines around that is it um yeah so it's so you so if if you're repeating something a lot if you have a template for it what you want to do is we are we are working with customers to fi to figure out ways that they can automatically identify what should be a model so using things like clustering we need to improve how we use clustering in the platform to do it and and a lot of the experiments we're doing as a product team right now are about that type of Paradigm which is we can present to you um maybe through generative AI or maybe just through clustering or machine learning we can say to you this thing looks like a template to us right or this thing fails a lot and probably shouldn't be a standard change you may want to have some approvals in it yeah that sounds very interesting so features to look out for and I am a product manager so I do talk about features although there is a lot more than features to getting this embedded in an organization and we all know that because I worked in implementation too but features to look out for are success scores so using success scores using approval policies success scores help you measure things so a model team could be measured and also um using predictive intelligence so looking at the risk of changes things that are regularly coming up as low risk in that clustering on them and working out whether there's a particular but actually for the first few group of models when you go out to the organization they already know what they want to see right devops site reliability engineering um patching Network changes they they're all kind of already like yes we want to do that that works for us and that's what we're seeing with customers so that's the real life example I can give you and then there were some qu some questions around quality versus velocity uh and I think there's some and I guess maybe you can comment on that like the quality of the change versus the velocity and the faster changing you know so so there was some commentary about we're talking a lot about velocity but not as much about quality and it I don't maybe you can comment on that so velocity volume stability compliance right that's the change envelope so you want to be able to handle we have to handle more volume uh because more volume is hitting it um and that means change managers need to start monitoring more and we need to have kind of dynamic reactive um policies around how things are approved so as things start failing we put more approvals in as things are more successful we take approvals out velocity Chang is about collecting data from other sources so whereas we gave the example of devops which has stories and pipelines and well everything's tied together with the pipeline devops that kind of is what makes it devops you know it's a rich source of data we can pull test results from other teams used to leum right they use testing tools again we want to be able to tie that into that change so we can say okay well we still need a business approval on this change we still need to know the technical architect reviewed it and I have an approval there but we have the test results in the change right for this particular product so shift left data is really important as well to that and there's no correlation between how fast a change moves so the lead time to change and stability right that's a proven thing in our industry now for Change and actually there's for a lot of teams not all for a lot of teams there's a proven link between doing things fast and better stability that's why people like Google promote uh working with devops and dorom metrics if you need to look have a look at D metrics and offline if you want to have a look at what they're measuring there but ways of measuring how a team are performing you know in a kind of high velocity Paradigm but the point of models is you can have low velocity stuff as well in there right patching could be quite low velocity in terms of the overall time it takes from raising a change through to it actually happening you could be doing it six months in advance there's nothing wrong with that either we just need to have a model that's specific for the speed at which it's moving okay uh yeah there's a number of other ones I think we're starting to run a little bit on time but I mean I think uh this is very helpful um we can uh let me see if I can find another couple interesting questions so while you looking while you looking at that I just just one thing to say so we are running a set of things called launch and learns and they'll be on YouTube right and and you'll be able to get to them on YouTube change management launch and learns around models approval policies Dynamic risk you know using flow instead of workflow those things we having specific topics we're limiting the number of customers coming to them because what we want to do is have a small set of customers that we can have a kind of meaningful question and answer that we then record and report back on and we we want to have Engineers on we will have Engineers on that call as well from the product team who can answer very specific questions with customers who have hit things having done this the idea is we get quite a kind of real life scenario rather than me presenting On A New Concept uh we'll also be hosting a webinar on this kind of wider topic again recording that putting it out there so there will be material being promoted on change management on Modern change management over the next couple of months and will be Revis visiting that and we will be more and more looking to kind of embed some guided setup and help within the product to guide you to the right places because I I would say right now if I was a customer as to set up these things in service now I'd find it really tricky to know where to go and what's set up and what the things were uh and as the product manager I want to make that easier for people so you know my focus right now is not features for change we've got a whole bunch of features right we don't need more features what we need is features that help people use features and that's that's where the focus is excellent well I'm going to take control and appreciate it um let me go back to my share and uh just uh wrap up here and again thank you very much Daniel uh that was very helpful I think there's a very interesting subject I think uh a lot of commentary in the chat and uh just for the members you know you can provide feedback on our community so feel free to go through if you didn't get your question answered here uh and you do want to to get a response you know feel free to go out to the community and go ahead and post um you know post your question there on the content uh link that once uh once John posts the video I will definitely be reviewing the feedback so if you have feedback on the presentation the scope of the presentation or just questions you didn't get answered or things you need answered I would love to hear that or if you've been doing this or you want to do it and you can't find the material you need or you feel technically blocked in some way or from an organization point of view blocked that's kind of the number one priority for me right now is getting that feedback on how to adopt change so we can make it better so please post feedback on the Forum and I will look for it awesome well thank you all appreciate it uh look forward to it we'll we'll post the the results on The Forum and you can pull the the videos and and and Replay that as well so anything you want to follow up on and then obviously you can uh send an email to myself or John uh if you wanted to get more information so thank you have a great day thanks everyone thanks for having me you're welcome