I think we're good to get started good morning uh good afternoon good good evening everybody Welcome to our modernizing change management webinar really excited to have you all here today uh my name is kayin Castell we'll get the speaker intros in just a sec uh but I'm going to kick us off today could you go to the next slide Dan all right so I'm sure you've seen this slide many times but before we get into the presentation uh we're going to have the Safe Harbor notice here there are four there may be some forward looking statements in this presentation um they're they're based on our best understanding at this point in time just don't take anything as as said in stone they could change uh go to the next slide from an agenda standpoint uh we're going to start with speaker intros two primary speakers today uh then we're going to go into the primary challenges that we hear from customers around modernizing their change processes we're going to talk about our perspective on uh a modern change solution that we're going to cover the key capabilities that comprise that solution and then um we're also going to Showcase to you today uh a modern change maturity or adoption Journey that we we think is a best practice in in enabling yourselves on these capabilities and then we'll have pretty ample time for Q&A but throughout the presentation feel free to use the Q&A um at the bottom of Zoom to ask your questions we have some moderators who will be looking at those throughout the presentation answering as we go also flagging some for for answering live at the the very end of the session all right next slide all right introductions um I'll quickly introduce myself my name is kayin Castello I'm an outbound product manager with itsm focusing primarily on uh our modern change and release uh applications with me today I have Daniel Davidson he's our our true product expert Dan I'll let you introduce yourself yeah so my name is Daniel I'm the product manager for change management um work for service now for about 11 years um previous to working as a product manager um I worked in the field doing leading implementations cross A Mir for itm and a bit of iton too great all right so before we jump into the presentation we want to kick us off with a poll so let me launch that poll really quickly so we just want to see what modern modernizing change means to you does it mean increasing automation is it moving away from itel change types is it managing a high volume of change is it executing those changes more quickly perhaps it's more accurate risk management or is it giving a better experience to the folks raising and processing those changes or maybe you have no idea there's no wrong answers here we just want to see what everyone here is thinking give you guys another 10 to 15 seconds for this and just one housekeeping thing as as you're answering this question at the very end of this webinar uh you'll you'll be prompted to answer a um just a post session survey that'll take just a few minutes please do respond to that your feedback is really valuable all right I think we got good responded I'm going to end this and share the results so it looks like two primary outcomes are are coming out here most folks want a better experience for the folks who are raising and processing changes um and also there's a big desire for automation we think that our modern change capabilities that we're going to cover today can help you with all of these things um so we'll jump into that now and I'll hand it over to you Dan thanks kayen yeah we should probably run this uh this query again at the end of the at the end of the call to see what we're going to talk about is how maybe not moving away but maybe including other types of change outside of the ital change types will help with some of the other things that you've answered in here uh and kind of given us a strong indication that the outcomes you're after Okay so we're going to start with um the color strategic vision of the it organization what problems are we having at cxo level and we've identified three main personas uh that are talking about change management talking about it transformation talking about digital transformation so start with a CIO who's made investments in technology the investment technology has increased rapidly over the past few years as we've heard terms like digital transformation so we're seeing new technologies a roll out of of cloud Technologies microservices um and new ways of working that they're investing in and as that's happened they would expect to see lower service out lower numbers of outages they'd expect to see better performance and better customer satisfaction that hasn't necessarily translated into those outcomes for them so they're asking questions about why from a CTO point of view there are new ways of working they've embedded in the business so they've looked at things like devops they've looked to more automation they've looked at things like infrastructure as code they've looked to things like site Rel reliability engineering and application performance monitoring um and those things allow the it organization to move faster potentially to be able to meet the business needs more rapidly um and that stops the organization getting competitive obsolescence as more and more of the business's products are either directly or indirectly delivered through it um the need to be able to rapidly um rapidly change what's delivered in it is increasing so with seeing an increase in the volume and velocity needed for change from the CTO from a c CSO ceso point of view we can see that there's more compliance needed there's more security vulnerabilities there's more attack vectors coming into the system there's more stuff that's in it there's more stuff that's being delivered digitally so there's more potential for loss through security breaches and as we see compliance increasing we also see the need to deliver compliance reporting um just in time so rather than doing kind of six monthly or or annual audits of of of compliance we're asked to deliver results immediately and so the the impact of brand the impact from security breaches the number of fines the complexity of compliance the complexity of securing the systems as we have hybrid systems as we have still have stuff on Prem as we move to different Cloud environments as we Federate it throughout the business and different teams take on different Technologies to deliver the products that they need that's become more complex too and sitting at the heart of this is change management because if you can't roll things out if you can't get them into production quickly then it doesn't matter what you've invested behind the scenes you need to be able to get them out quickly what happens is if change starts being a blocker to these things these changes start stacking up so changes that were meant to be delivered really rapidly into production environment start being delayed and start being stacked up into larger changes and that in itself could affect stability these changes were never designed to be stacked up and waited on they were designed to be implemented straight away and we know that having smaller incremental changes has a positive impact in stability it also has a positive impact in in the business's ability to deliver rapid change to customers which is what they want to see and innovate quickly and the reason this is happening is we have teams working around the place so we have siloed teams working delivering stuff into production environments we have operations teams aren't necessarily seeing what's happening in the development environments that developers are using um and and as we as we're rolling out security patches and security patching programs and we need to demonstrate compliance again there's there's more pressure in that area so the workload is increasing on change management we're seeing more and more changes being delivered we're seeing them having to be delivered faster and and that has a KnockOn effect of sometimes slowing change down so what we're going to talk about here is some approaches around how we can modernize change how we can deliver within that envelope how we can make higher volume changes more compliant more stable so we can deliver better volume better velocity better stability and better compliance so why transform change why do it now so normal change has now become overloaded we're going to talk more about that in a bit normal change has to cope for so many constituents around the business and it's ill suited for many of the the change use cases this could be dependent on a type of technology or the model that's been used to deliver that technology so it could be a devop team or it could be that we're doing Cloud infra or there's a very big difference in how we deliver technology to the Mainframe in the as 400s as there is to a microservice based application that's in the cloud and we want to be able to innovate fast without increasing the risk because by by innovating fast we're delivering things fast into production we want to make sure the same checks and balances are applied to the changes that are being made that we've always done we don't want to just create a risky environment and move fast uh and leave systems vulnerable and leave systems potentially uh more unstable the Legacy change process is has become a bit of a black box it's something that a lot of customers are kind of frightened to touch and move forward on because it's so complex it's had to be adapted and it's had to kind of morph over the years to sue all the different types of cons situ using it so we've seen an explosion in the number of business rules the complexity of the workflow that's attached to normal change and it can seem quite impossible to transform again we're going to make some suggestions about how we approach that change and as we need to do more changes we need to do them faster we need to be less subjective about risk evaluation we need to have we need to be able to highlight things that are risky and need people to be involved at looking at the changes but we need to minimalize those so we're only looking at the changes that are really important and allow the other changes to flow through and this follows through with an IND Trend about change management moving back more to second line so looking at concentrating on the changes that are particularly risky or that we don't have good data and good structure around but allowing changes that have good data good structure and good practices supporting those changes to move through with minimal or less approval and to be able to do that as well we need to be able to bring different piles of data together we need to be able to take data that's in plan build test and release we need to be able to combine that with operational data um so that both teams can talk to each other so that we have a full visibility of the picture the full end to end pipeline that we have in our product deployment so how do we do this by using change models we can start to decouple change we can start to unpick the vast normal change that we have that's become complex we can start to take things out of that box and start to have purpose fit purpose-built models for the particular areas of the business to allow them to move at the velocity they need to move leveraging the data that they have within their stack and the processes that they've built by having integration into their systems we can start to have visibility of their data we're not talking about having them work in service now we're talking about them being resident in the tools they used to working in the tools that they've chosen but bringing that visibility into service now so that we can look at it from the change and we can have it audited within the change process so that we can automate the change process and so after the fact operations teams can see what's happened or what is going to happen as a set of changes are deployed we need to be able to use things like gen and machine learning to evaluate changes so we need to look at the wider picture of change and start detecting where we think there are patterns which could which could uh which could negative uh negatively impact stability all that could cause us compliance issues so we need to know where teams are performing well where services are performing well where particular types of change are performing well or badly and we need to adjust the change process dynamically to suit those outcomes and by combining this with approval policies we can start to tailor approval dynamically to make the approval as light as possible in the situations where we have very little risk presented but you can have a change for instance where one team doing it are extremely stable at what they do and another team aren't and we need to be able to look at these things within approval policies to take operational data into account to take into account the things that and check the guardrails that should have been applied in in processes like devops and build that into the change process and that means we need to have a different way of doing different changes so what we're doing is we're breaking change down and starting to look at it as a set of components that we can wire together to make specific types of changes and these go beyond traditional normal standard and emergency changes okay next question kayin do you want to do the question happy to give me one second all right launching the poll so this is a two-parter um first question is are you feeling pressure your organizations to modernize change uh from the business if so where is that imperative coming from and why and the second part of this question is what's the biggest challenge you're facing in modernizing change if you are feeling that pressure so give everyone 30 to 40 seconds to answer this seeing a bit more of an equal split here popping up yeah 10 more seconds okay share the results here so like Dan said uh bit more equal results on the the first question um seems like stability is is the the primary driver for a lot of us on looking to modernize change um increase focus on compliance and also the business expects faster uh change processing to to get innovate more quickly terms of challenges seems like the two largest challenges for the group are getting buyin internal alignment we hear that a lot and also awareness of features so hopefully that one will definitely be addressed in today's session all right Dan back to you oh just have the again okay so we have a statement around how we move forward so by taking a model-based approach to change we can start to enable change to be broken up and we're going to show that over the next few slides we can allow you to adapt change to fit your constituents to simplify the normal process as well because the normal process also to suffer stability issues in a lot of cases by being so complex so by breaking changes out of the normal process not only are we able to make those teams able to work faster able to increase the Automation in those teams increase the stability that they can be delivering with their changes we can also increase the stability of the changes we leave inside normal because we make that process less complex so we can increase velocity and volume whilst we're also increasing the stability and the governments so three change types that we know and love in iil and we have no plans to retire these changes okay so these changes will be around for a long time what we have is standard change and for those of you who don't know so standard change is a repeatable change it's a lowrisk change it's a change that's highly templated and what we do is we look at the performance the past performance of this change and if it is something that's low risk if it's if it doesn't cause us any particular outages or any particular problems if it is something that we can drive through a template if we know the performance of the teams making those changes is good then we can allow them to make standard changes with zero approval but what this doesn't take into account are things like operational data points so it could be that a standard change is allowed to be applied even when there's a P1 right now in a production system so it has its limitations the other thing is we need to constantly revise and look at our standard changes there needs to be a process around proposing standard changes looking at the templates there needs to be a process around retiring them when we see that performance isn't so good with those changes and also it's really all or nothing we either see that A change is performing well but one team doing something wrong with the standard change could then make that standard change unavailable for all teams and that might not be the right thing to do it might be the right thing it might not be the thing we have emergency change so emergency change is something that is a change of Last Resort so we've either done something in a system that we had to do straight away and we're raising a change after the fact or maybe something happened that was an unrecorded change that we're now applying a process to to record the fact that system changed and apply uh some policy to it again after it's been done and normal change is just everything else so within this change we need to be able to cope with all the different types of changes that hit the organization that aren't standard and that aren't emergency and because of this it becomes an incredibly complex change type it becomes something that has lots of business rules normally that has a really complex workflow that has approvals in it that need to be able to cater for the worst possible situation and therefore Slow Down Changes which could be done much faster so an example would be something that doesn't quite fit in a standard the change category maybe we've had an issue with it in the past maybe it's just that we don't want to want it to happen in a production system without someone taking a look at it and that change could then would then flow through the normal change process and would hit all the barriers that we would expect to hit for a large system change that's going through a normal change process as well and although there are some nuances around looking at the risk of the change and rooting it in the right direction the more we customize the workflow the more we take that workflow and root that change slightly differently the more complexity we build in the more business rules fire the more complex change becomes and potentially that change process then becomes very brittle to change so this is why we're stuck in a paradigm of of normal change slowing us down but not being able to move forward easily so what people also do so around around the changes again we have these artifacts so people are using workflow still for their changes and it's sometimes difficult to move away from workflow because you've got so much built into it for the normal change there's so much investment in that workflow and maybe even sometimes a lack of understanding of what what that workflow actually does it would be a large scale project to pick it apart and move it into more efficient flows and the approvals are also baked right into that workflow so it's difficult to pull them apart and then there's a set of business rules around the normal change as well that have so many conditions on them to hit the different types of changes again it's kind of a it's kind of difficult to to to see how you would start to decouple things in change how you would start to have different change types so to move away from the it change types we need a different approach so again looking at the constituents within normal change we've just got some examples here other types of change do do exist other models of change to exist and we encourage you to find your own models and make your own models but actually within normal change this is what we're coping with and we can see an emergency change too we've got unauthorized change as part of emergency change so it has to follow the same process as emergency change even though it's a very different type of change and we know some customers as well do devops as part of standard change this is example of where standard change has been used to cover something to make it work faster but actually devops is not a standard change they're not repeatable changes they're not necessarily low risk the reason we're using standard change to do this is because we want those changes to happen fast but it's not the best way of doing things what we should be doing is we should be inspecting the data coming from the devops teams to make sure the guard rils has been followed and allowing the change to flow through with little or no approval when that happens but equally as we can see later we can apply some operational data we can apply some checks and balances that change and we can root the change for approval if we need to so we have the it change models on one side and as I pointed out we have no plans to get rid of these changes or retire them they will be around for a long time and will continue to support them standard change has a very a very valid purpose still in organizations there's still a lot of changes that we do that we need to have in a catalog with a template that people can just repeat they make things very fast it's a very efficient way of working but what we want to do is make normal Chang smaller as you can see the the size of that planet has shrunk and now we've got Federated change models over to the right hand side so what we're doing with these models is creating a very specific way of working and within service now change the first thing we can do is lock down these changes so only the right people can use them so there's mechanisms for doing that so we know that we can't run an app change through the infr model or through the lowrisk model we've got different types of changes as well that'll follow different approval policies So within here we can reuse State models we'll talk about that later we can reuse approval policies we can reuse business rules we can do that but we can also create our own versions of approval policies which fit just that change and because we know only the right people are following that type of change we know only they are going to follow that path we've got in here lowrisk change as well which is kind of that area that we talked about before which is where changes are not necessarily standard change but we want some checks and balances applied to them a lot of changes in organization fall into this category so in here you might do a check like to see how successful a particular team are at making changes there's more about that later you might see whether there's currently a P1 on the system that they're going to reboot the server on something that would normally be a standard change but you don't want to do it in the case where there is some operational issue at the moment and so we can look at operational data we can look at the performance of the teams or the performance of that template also within that we can actually check dynamically at the time the change is rais whether something has happened in the last few days so we can actually check to see whether it's still a valid standard change template or lowrisk change template at the time the change is made and we can root the change for more approval if we've seen some issues recently and so that reduces the amount of work we have to do in maintaining our standard change catalog by having lowrisk change not only are we having more Assurance around what's going on within the changes we also are able to put more changes into that kind of high velocity low effort category and we can also provide logic to allow those changes to be checked at the time they're being raised at the time they're being implemented to make sure that the the assumptions we made around making that a low risk change are still valid and root the change appropriately if those assumptions aren't so again just talking about moving the change moving devops change out of standard change and into its own model and then this allows us to have a purpose specific change for devops that allows them to utilize the Integrations utilize the data they've got in systems allows them to continue working where they were working before but provides data to operational systems to service now so people have visibility of what they're doing and allow those changes to flow faster without compromising uh our compliance so just looking at some of the components that we have in service now around these changes so traditionally again if something went into the normal change process or went into the standard change process or the emergency change process we'd have a set of states that it followed and those would be kind of bolted down right you'd need to follow all those States so most changes that an organization does that are following the normal change process because most changes do would have to go through all those States and by having a purpose specific change what we can do is we can tailor the states for that type of change if we want to we can skip States and just not have them in that particular model of change but we also know for that way of working for that team that are able to Mo to raise changes with that model they are going to follow a specific State flow and the importance of State flows as well is that again they're reusable so we're not talking about building a new set of states for each one of the models you build you reuse your States you just tailor the state flow to fit the model and that comes down into workflow as well because we've implemented state-based workflows so whereas before we had one monolithic workflow for the entire normal change process or emergency change process that workflow would have to go end to endend and we' have to have conditions that roll things back that move things forward that cat different changes so the state transition was quite tricky to tailor because if you didn't move from one state to another the workflow wouldn't be able to handle it or there' be really complex logic to allow it to be handled so by decoupling the workflow and having it state-based each work each one of the states will run its own workflow that means we can chain together States in different orders and we've got an example of that later we have specific approval policies again the approval policies are reusable items we can call them from workflows so we don't have to build up a different approval policy for each one of our models or several approval policies for each one of the models we can reuse them but the point is we can build approval policies if we want to to take into account specific data and again we'll give some examples of that later we can take into account structured data as well with our changes so whereas before for a normal change we'd be we'd be looking across the organization so there's very little opportunity to take to take in specific data that's provided from one system another so if we're looking at infrastructure as code or if we're looking at devops we can't go and key into that data and start bringing it back and using in the change process easily with out a lot of variance within the change process so looking at the Federated change models you can see they have different amounts of approvals in them they have different amounts of use of templates they have different workflows some of them may be State based flows some of them not the advantage of starting with change models is you can continue to do normal change the way you're doing it you can continue to use workflow with normal change we don't recommend it we recommend you move to flow but if you want to you can break off these new models and start experimenting with them with a very small group because we can lock it down so only certain people can use that type of change that new model of change and you can start to learn about how to do state based flows how to use approval policies how to use mod risk management and you can start to apply templates to those things as well that are used for that one so looking specifically at some of the flows in here in the state model because that's one of the key things about change models you can see in here we have the normal change flow which goes through normal assess authorized schedule Implement review flows so as a change flows through them the normal changes will continue to flow through that path but you can see in here for for change registration for example we just go through schedule Implement review close so this is an example of a change where it's an informational change we don't need to go through all the steps we had for normal change we don't need to modify the normal change workflow say if it's coming from this vendor or if it's this got these these aspects of the change then we will just skip these states we don't follow them that would make the chain the normal change process more complex we can have a specific process a specific State model and a specific set of components that work for change registration and not only that when we look at those changes when we look at our changes overall we'll be able to identify which changes via the model were following change registration path looking at an authorized change as well for an authorized change it's no longer an emergency change you can see it comes in a new we review it we authorize it we close it there's no point in scheduling it because it's already happened so by minimizing the amount of states of change goes through we're simplifying the change process we're making it more efficient and we're also making normal change easier to use so just some of the features that we use within change so change approval policies allow us to take data in that's specific to that type of change there's some things which are fairly generic right we may just look at the risk of a change like we do a normal change and root it to cab if it's high risk and then root it for approval if it's low or medium but you can see in this example we've got a specific set of policies for devops changes so we can look at things like whether integration tests failed we can look at things like whether there's Branch protection enabled on the pipe we can also look at things like operational data so your devop teams won't currently have visibility this when they run their pipeline it's very unlikely that they'll know whether there's currently an open incident or whether there's been an outage in the last seven days it may be that your policy says if this team have caused an arog last seven days we need to have a manual check a minimal man manual check on the change before it moves forward we may want to do something like conflict checking and check across the organization to see whether other changes are taking place at the time to minimize the amount that we could have two changes that cross over and cause an outage or cause some kind of disruption so what we're doing with the Dy Dynamic approval engine is we're taking structured data we're ingesting it in to give us decisions around approval and we're able to attach that on the model and make it specific to that type of change so we know only that group following that type of change will have that type of approval applied to them it's fit for purpose and from the decision from from the from our approval policy we get a clear decision it could either be approved D or rejected or go to manual review so it can go for manual approval in the traditional way it can even go to cab if we wanted to we can root these things through approval policies as we see fit Dynamic risk evaluation allows us to take different aspects of the change now we most of us will be doing some form of risk evaluation on a change most people will be doing risk assessments they'll ask some questions uh of the person raising the change via a structured survey and it's a good way to do things it's a good way to capture information but it can be gained we see customers where people fill this in numerous times to get the right answer on a change and although we have documented what their answers were when they gave them so we do have an audit Trail it's better than just getting them to put a risk in um it still has its weaknesses but it's still a good way of doing things we have risk conditions so this is looking at some of the things which you may already have as questions in your risk assessment it may be something like is the change to critical service well if you have a cmdb you should be able to tell that you should be able to to tell whether that CI is of a critical service or not so instead of asking the question a risk assessment we can automatically ask the question via risk condition and again we can set the risk on a change via these risk conditions firing and we can also make a calculated risk score so we can take the probability of something happening and the impact of that happening and look them up and apply like a secondary secondary risk score from that to and then we have risk intelligent so all our itm Pro customers have machine learning for change on the systems you may not May well not have enabled it yet but it's a really good implementation of machine learning what this does is it looks back and clusters changes using either a similarity or classification algorithm and then will'll give you a risk score based on features those changes and whether they were successful or whether they failed and it's a very accurate way of telling whether changes are likely to succeed or fail we find it has really good results in the field the customers that we know are using it they're using it at scale and it's producing good results so what this does is all those particular aspects of risk come into uh a dynamic risk score and we look at them and we take the highest risk that presented to us so if machine learning comes back and says it's low risk but the risk assessment says it's high we'll take a high score as you can see in here the calculated risk score was high so that allows us to make sure that we're always looking at the data which gives us the highest risk so if machine learning again if it comes back and says something's High and the questions we asked said it was low it will come back with a high score for risk and that's the best way of doing it that way we can make sure that a the if any aspect of a change comes back with a high risk score it's rooted according to that score and that's our derived risk score so change success scores a lot of our customers are using change success scores and what we do is we look at the team who are implementing the change and we look at what's happened over the last 30 days with that team and we look at aspects like and this is configurable how many successful and unsuccessful changes they've had how many outages they've caused how many p1s they've caused and we apply a multiply to those numbers and we get a score from that that that is calculated every day using a performance a platform analytics job so we get a change success scorecard for each team we also get a scorecard for uh change models so we can see how well a model is performing and we also get a scorecard for standard changes which c fit is slightly differently so we can look at this when the change is when the change is being assessed we can get it to to contribute to that derived risk score but what we can also do is we can build it into approval policies and there's a link to a Blog which talks about that at the end of the presentation so what we can do is the example with standard change before is we can look at a look at a change a lowrisk change but then we can then see whether the particular team doing that type of change has failed recently and maybe root the change if they're failing a lot maybe root the change for some manual approval equally with a devops team it may be that a team are doing a devop process they've told us that they have all the all the guard rails in place but they just keep on breaking stuff so we want to have some manual checks on their change until they get to a point where their changes are succeeding again again by applying a success score in an approval policy as part of your change model you can interrogate the success of the team or the success of the model and you can build in Dynamic risk into your change so another one of our products devops change velocity what this does is it allows developers to work in the platform they used to working in and there are lots of systems out there we have lots of Integrations to these systems we can bring in data on what they're planning to do on the stories and work items that they're preparing we can we can hook into their pipelines and we can see what they're planning to commit we can see where the code is in the repo that they're working on and as the pipeline runs we can feed that data into service now so we can link that data together and that means that when we when we look at a change we can assess the data that's coming from the devop systems so we can start looking to see whether they included stories with their commit because developer teams should be having stories that describe what they're doing in the commit they're making we can see what the test results are because the pipeline should contain high level data on the test results and security scans for that devops process for that pipeline run and we can also make round trips to other systems we can bring back detailed test coverage from systems like celium and we can see what the actual test results were and again it's recorded on the change so when we make approval decisions as you saw before we're looking at this data but we're also recording why the decision was made on the change why we decided to root this for no approval at all because all the guardrails were adhered to and we also have details of exactly what tests were done or we can have on a change which is created via devops and so these changes are created automatically as the pipeline runs it fires a change in service now it sends us the data we attach it all within service now we put that into the change record and we root the change accordingly and what this also allows us to do is as we have teams working across various systems of various Technologies in the organization you might have people using as your devops on one side of the business and the jir stack on the other side of the business there may be multiple jir Stacks where people are doing different different teams that are Federated around the organization have bought their own instances of J and are happily working away on them we can integrate with all of them and we can provide visibility of of their performance from service now from your operational platform and what this does is not only allows them to see across the devops world but also allows you to then when you've attached that devops data to the cmdb and this common service data model it allows you to slice and dice that data by other things like how is a service performing what's the velocity of change for a given service that's using devops so we have again out the box metrics we have the door metrics which is industry standard we have other metrics as well which we can provide insight into what's happening on the devops stack and that allows change managers to see how the devops teams are performing to understand what good looks like in devops and where teams are not performing so well and take steps to remediate where we're having issues and potentially reward teams that are doing well by allowing them to make changes faster okay so now we have a comparison between two types of changes and you can see in here we've got the normal change life cycle and we've got all the stages of that change life cycle and that change requestor would be asked to fill in the form at the start the the uh start of the webinar we asked the question around making change easier for our for our change raises and so a normal change doesn't really know a lot about the change that's coming in it doesn't really know what data you've got to fill in that change apart from a few kind of key mandatory Fields by using change models you're able to focus the person who's rating the change to fill in the details that they need to fill in for that change so we can highlight for that particular type of change what data is pertinent what we need to move on for a normal change we just can't do that because we can't we don't know what type of change to rating to start off with it's not Purpose Driven but they fill out that change and they do a risk evaluation again the standard risk evaluation for all those changes not a specific one for that particular of change then the approval happens again a generic one which has to look across all the types of change which could be a normal and is either very complex or will be slightly paranoid and root the changes for a lot of approval maybe unnecessarily and more approval means more work so it's a rough proxy for how much work you're doing your change process for how many approvals you're generating when you're generating a lot of approvals not only the change team having to do a lot of work people around the business are having to do a lot of work as well a lot of a lot of State holders involved in the change stakeholder complexity also normally increases the the possibility that that change could have an adverse effect on stability we schedule the changes we Implement them we review them we close them again no specific processes around this for a normal change as you can see here we've got a cloud infrastructure Change Model so we know what changes we would expect from cloud infra when that's raised so because we're using a specific model we can Target that form that experience around raising the change to that particular Persona who's raising the change and we we can make sure only they can open that type of change we can use Dynamic risk in a way that's appropriate for that type of change as well we can have approval policy automation we can look at the performance of that team and root the change for approval if they're performing badly or maybe root it through with minimal or no approval if they're not also we should for a lot of processes the the things like devops the things like Cloud infra a lot of the assessments done to the left of the change process if we know that's happening if we have good evidence that's happening we can skip the asss pH for that change because we can bring that information into the change through devops Integrations so then when we've authorized it that change will happen straight away we have automation that fires that will run the change will run it into a production environment we can check for scheduling you know we can do automatic conflict checks to make sure it's it's not going to clash with something else and we can hold the change in the authorized stage we canot authorize it until those things are resolved but when that change is clear to go we may not get an indication back from those systems in a lot of cases they don't back to us so what we do is when they authorize the change we don't need schedule implement or review anymore we just close out the change so that allows us to minimize the amount of states that cloud infrastructure Change Model will go through now your implementation of cloud infrastructure may vary this is just an example but it's to show that in in this particular instance we don't need all the all the states that were going through the normal change process by using a change model not only have we minimize the amount of states that we're moving through in the change we've also implemented specific policies around approval around risk around the workflow and around the process of raising and filling in that change so the adoption Journey um we recommend as a first step people move towards looking at potential models they can set up and we recommend that they move over to the normal standard emergency models within service now because effectively it's just a label on a form to start off with so we're just replacing the type field on the form with a model that says normal standard emergency and you can use existing work you can use existing approvals around this you can use the work that you've already done in service now with those changes and you don't have to move away from that immediately but what you can do is you can start breaking off types of change like for instance devops like for instance patching like lowrisk change and start experimenting with teams and then that allows you to create the governance for those teams as they're moving forward so it allows you to update your compliance and policy documents for that particular team to work with them to understand how the new components in service now work to work to understand how you on board those teams and how you the quality of the changes they're doing and then you can scale that out by leveraging the data that those teams provide in that particular model you can start to understand the data that exists around your organization you can start to bring it into the change process and what that does is allows you to build traceability of the changes that they're creating so for things like devops we're automatically creating the changes we know what pipeline run they came from we know what artifacts have been deployed and this not only helps a change process it helps Downstream process like operations understanding what stories were were deployed in that particular commit or like security processes wanting to know what particular artifact has made its way where in the business and that gives us the opportunity to have full change automation so where we have a shift left system that's robust and has done all the checks before we raise a change this allows us to use that and make the change process really lightweight but we're still checking to see whether they've done those things we're still checking with approval policies to make sure the guard rails are in place that we've got the data we've received it in service now we're still checking with success scores to make sure those teams are performing well they're not breaking stuff and all these things this automation allows change managers as I said before to step back from being first line change managers into more of a second line Process Management which allows them to have oversight the changes to start looking for opportunities with automation with maybe new models or tweaking existing models to start looking at low performing teams to start looking at where there are Trends in stability to start implementing things like machine learning for risk or maybe further on down the line gen so as you mature along this curve by breaking off change models and by having a specific Change Model to take some of the changes out of normal change you're making normal change less complex and you're making this the change that you're starting to build as a model more specific higher velocity potentially higher stability and you're potentially increasing your chances of doing some Automation and decreasing the workload on the change team so that's how we see the maturity path towards being able to have velocity and volume stability and compliance within the envelope without compromising the stability of the team okay next question kayin do you want to read it out of course right I'm launching the poll so this is our final poll question so um have you started modernizing change and if so how are using service how to do this we have all those capabilities that we just talked about here today you can answer and select all that apply um and please be honest another 20 or so seconds all right and the poll and share so it looks like about half half of those on the call have not yet um started using any of these capabilities so hopefully after today's session uh these seem interesting to you you you'll begin testing those out in subr um but a good portion are also starting to use change models and approval policies about a quarter so that's that's good to see all right so we have I think one more slide that's kind of like a call to action that slide Daniel and then we'll we'll kick off Q&A um so first call to action is just begin experimenting with these capabilities that we talked about and your s PR environment um we have a number of blogs on our community uh we'll send those out in our our post meeting invite so you can reference those Community blogs to learn more about these capabilities beyond what we share today and also to to just help you get started with those and also if you have any questions please engage with us uh we'll be working uh on monitoring the itm form for any Community posts around around change and respond to those there okay with that let's transition into Q&A with have a couple questions here that we flagged uh to answer live so I'll go ahead and ask these and uh Daniel I'll I'll let you respond so first questions from uh Pierre creating change models outside what service now made available out of the boxes uh can be relatively cumbersome are organizations meant to try to stick to what's available or is there flexibility to implement new models that align to an organization yeah so first thing is I don't think change is is short on features or features that deliver value I think what what we may need to or we do need to improve on is customers ability to adopt these things and change models is a great example of it we want to make things easier for you to do for a start so over the next few releases we're going to try and make things easier for you to configure in terms of models in terms of having setup around those models and that easy access to be able to configure them and information around where you would identify change models and what you do around them and the components that we talked about the things like approval policies flows where those things are where they live and how you reuse them um we do provide some basic models out the box but with every like with everything change they're just a template they're a starting point we don't expect customers to be able to use change completely out of the box on day one because most customers will have nuances around how their change process works we expect to be most of the way there so the models we provide out the box for you are there for you to start for you to either go in and use or to to configure on your own or to copy and create your own versions of um so the answer is that every organization will probably have very similar types of models or or models in play but they won't be identical to each other so yeah go out there and create your own change models and um and let us know how it's going let us know how how how easy you find that and where you find blockers uh next question is from Roland uh many clients split the projects and development change process and change release uh from each other how does this fit into the Federated change model uh so we have another product uh that we use for release management so separation of release and deploy is something that we are supporting a service now so again things like normal changes will continue to use the change process that we've known for years but where we see teams that are doing very rapid deployments there's normally an overarching release process and I think we have um have we had or do we have another webinar coming up on digital product release we've had one uh so far we do have another one planned that's actually going to be kind of a joint webinar between change and release so Mod change plus digital product release yeah that'll be I think in June yeah so but but the but in those cases where you have a separation of release and deploy where you're doing checks on what's happening in the release so kind of feature level stuff business checks business sign off operational Readiness and you need to tie the change into that that's the direction that we're moving for separation release and deploy but change models are really important that because like I said before you you will have normal changes that continue to work in the way they've always worked and we need to support that we want to support it but we are looking towards ways as well and we have products a new product around um release management that will support separation of releas and deploy so you can do rapid changes with minimal approval within change management for your deployments um and the release can be handled as a kind of uh longer span over the top of multiple deployments all right next question from SE uh have you ever seen all this successful apply to any customers if so how long would this take to put in place in a conservative it environment the traditional change process so I think it's something you do gradually um yes we have seen customers using rolling this out um I think the traction has been uh we've had now I think change models have been in play for a few releases I think probably six to eight releases someone might be able to correct me on that um and I think we've advertised them I think that that that there's been more of an organizational imper narative over the last couple of years to do this so what I've been hearing is that the change being a blocker to the organization's velocity The Wider organization is what customers are reporting to me more and more and so that's driving again over the last two years has driven more of a need to look at how change is done and so people are looking at change models first and then looking at things like Dynamic approval policies and different ways of doing flow and risk as part of that different customers move forward in different ways at different times a lot of customers will do models first that's the right thing to do uh we have customers who are actively using machine learning for risk we have customers who are actively using Dynamic approval policies we have lots of customers on devops now who are making lots and lots of devops changes with little or no approval and bringing the devops data into the system as well and driving insight into the devops system so you know if you have a lot of devops teams out there then you're probably best setting up a devops model first and moving with devops first um if you have a lot of patching going on then set up a patching model and work with that um if you have an issue with with risk management risk management is slowing you down or or it's an area where you're not perform performing particularly well then look at risk management but I look at models first and just another note in terms of maturity that the curve doesn't have to be executed across the board all in one go so you've got a maturity curve and you look at doing models you look at trying to have impr approval policies you look at trying to embed um Dynamic risk inside those approval policies um and using Dynamic risk within change you could have models that are moved all the way forward with that because you're getting good data from them because those teams are willing to to work with you to do their change differently that you trust them to work in that way and you have other teams that you've kind of held back on because they're they're not particularly good at performing change or the data isn't very good or the CNB isn't very good in that area so I don't think it's a case of having this is one of the points it's not a case of having to move everything for normal change all in one go as one big transformation project that would take two years it's about kind of spinning one bit off and experimenting with it and then scaling that as fast as you can as fast as you're allowed to do within your budgets your constraints so I there's no single answer to that how long it takes I think it takes that the faster you do it the more budget you'll need probably the more risk you're taking with it but by taking a structured approach and using models you can reduce that risk and mitigate great response Daniel all right uh next question how important is a functional cmdb to drive these processes um very important uh I think the so change traditionally the custodians of the cndb so change the quality of the CNB is also driven by the quality of the change process um and that's for a lot of normal changes and then you move into kind of the cloud Paradigm and the CNB starts to kind of shrink a little because you've got these these kind of big entities that sit in the cloud that are very complex but may only be represented by a few CIS you know an API um maybe a maybe a microservice infrastructure which is actually a big thing in the cloud it scales up and scales down and even that scaling is not being controlled by change right you don't raise a change when you get more nodes added to your microservice if that's the right term to use even um so what we do is by by having different ways of doing change you can start looking at the CNB slightly differently for uh for cloud native uh environments for instance so for there you start looking more at when configuration changes and the cloud so when you change the setting that allows you to scale or how you scale when you change cache sizes you want to start looking at that kind of thing so I think the CNB is changing there's still a lot of traditional CNB and there there will be for years and that's really important it's important to for knowing the impact of things that that seem to be is well mapped that you understand what services connect how Services connect to each other uh because you won't be able to effective impacting unless that happens um but I'd say more and more there's automation which is AA ailable to help us populate CNB and the item folks will talk about that but there's more automation around populating CNB as we hook into pipelines and they tell us what's being deployed then there's opportunities for us there to to automate what's happening in CB all right this next questions come twice um how do we solve the problem where approvers from a team are very slow at approving changes causing changes to be rescheduled as they miss their intended implementation Windows a little bit different from the topics we talked about but they came up price Chas them Chas F them up um so if you have less approvers you need to do less work on the change if there are changes that don't need approval people will have less approvals they'll probably take less time to do approvals if you can push things out to their devices if you can push things out to like Microsoft teams if you can push things out to their mobile phones or mobile devices you may get approvals faster if you can provide more information with those approvals so allow them to make an approval um with good information from that device for instance then maybe that's something you can do too there are opportunities out there to speed up approval make approval easier um and also just by minimizing approval so if you have a change um that needs to go to cap then you're going to have to pull a load of people into room make a decision um and and that's that's going to be around as well for a long time but there are lots of changes that are done that need minimal approval and we'll probably putting too many approvals into change so again looking at how many approvals are on the changes and whether those approvals are really needed and how many times the change just gets approved is an important part of making the improvement process as efficient as possible all right uh next question is how do how do most handle unplanned changes that are not emergency changes and fall outside the normal change Windows so I don't uh so you could have a specific model for them I'm not sure if you mean uh changes that are in retrospect so I'll answer that one first so um you can have a there is a specific model that we provide out the box for unauthorized changes that happen that you're approving retrospect um and there's a certain amount of urgency about understanding when they are to a critical system and you want to have that approved because you could get some audit coming along that says you have that not only did the change happen there's been no approval process around the change I think where there's a large number of changes being made to a system you can start to identify it's more like identifying Trends and working out why you're getting changes made in that system um and why they're happening if if it's not particularly impactful or not on a particularly critical system um it can also show potential security vulnerabilities you know where you've got things like mac addresses changing randomly around the organization um some of those or even one of them could be a vulnerability so I think it's about understanding for an authorized change what process picks that up so sometimes it'll be change management picking it up to make sure that changes has been authorized to make sure they close the loop and it doesn't happen that way in the future I think sometimes it'll be security teams picking up on it it's not really a change thing it's more like again with the Mac addresses it's more like understanding why we've got these things appearing on the network that weren't there before and there wasn't a change rate for them so it Loops into another process vulnerability process possibly all right um next session from Carl will anyone be available to discuss modern change one inone at knowledge so I think the answer is yes ien will be there and on anyone else that you know of Daniel we'll have a a modern change uh demo ackn knowledge actually I'm just trying to think there will be people there though yes I'm not there all right um next question from Seb uh coming back to cmdb what can be achieved without confidence in your cmdb data how would you push change process Innovation with an immature config like configuration data I think without it so if you know what service something is if you if you have a a Services set up within your organization if you know how technology is been delivered and who owns it you can make them responsible for the changes in that area so maybe you don't know all the CIS in their area or maybe you don't know how those CIS are connected to each other but you do know that all the windows servers in I don't know uh in Atlanta are owned by this particular person if you root the changes to them so that would be using something called um dynamic queries within cndb to link together a set of CIS with particular attributes to a particular service or service offering and then to a particular person by making them responsible for the changes that they that are happening on their systems you can drive an effective change process because change is about responsibility and also by understanding that there are limitations to that area of the cmdb it may lead you to think that the your ability to to to determine impact and determine risk is going to be pretty low um so you probably make that change a little bit more risky than um than something where you have a lot of detail in that area and that would affect that particular service owner's ability to make changes that technology owners ability to make changes fast so by pushing back to them the need to improve the CNP in their area and by getting them to engage with the conflict team around how they do that maybe through Discovery through service mapping through better Integrations um you can drive better quality and that's kind of a little bit about how you gamify change right you allow people who have good quality cnbs that keep them up to date that follow good processes that have good practice you allow them to move fast with minimal approvals on change um the right approvals but minimal approvals because they're providing data to the change that allows you to do that right it's auditable no one's breaking any rules if systems are not well recorded if you if you don't know what's in your CDP then there'll be more manual checking um another approach is is by having things like cabs and inviting people and and having a policy where if you don't show up you know the change is going to go ahead so so you know rather than kind of broadcast approvals across to a wide uh section of uh of the organization and expect them all to approve it before the change can go forward which will probably mean they won't have approved it by the time you need to do the change cabs can be a really effective way of of managing change and specific cabs Network cabs you know climate management cabs application cabs whatever it happens to be security cabs whatever you whatever you're setting up in that area you can drive some quality just by having structured meetings where people are invited and decisions are made by committee um and that's sometimes what you need to do if you don't have the data then people need to look at the the change and maybe they need to pull a blueprint out the top door of the desk and have a look at it before the change is approved but if they've attested to the change if they've approved it that shows they've done that all right we're about at time um I'm just going to address one question that I saw here and then the questions that we didn't get to we have them listed here we're going to respond to them offline and send you all emails of the answers um but one question from Seb that think love to everyone please uh advertise the upcoming webinars via the post meeting email I'll make sure to do that um look out for that email probably come in a few days because we're looking to publish this webinar recording um to a place that that you can reference it um in the future um but like I said there's a number of questions here we're going to work to answer these and get back to you uh please fill out that post session survey uh particularly if you have any uh interest in engaging with us on anything that we talked about today you can indicate that there and thank you for your attention today it's been a really great session appreciate all the participation thanks to you thank you Daniel thanks