so uh good morning good afternoon uh good evening everyone thank you for uh joining our modern change management launch and learn Series so this is our second session covering automated change approval so we'll be going over change approval policies today I'm your host Greg holis and then we have Daniel Davidson back as your speaker and let's jump in hey real quick we have the Safe Harbor here um so there maybe some forward-looking statements in this presentation they're based on our best understanding at this point in time so don't take anything as set in stone as it can change so we've seen this slide before on the webinar that we did introducing the series and also on the uh the last call we had on change modelist so what we're trying to address is a shift in the way that organizations are seeing change change is now more important than ever was it always was important but now the business is starting to notice change more so we're trying to drive the envelope around change in order to uh to drive digital transformation within our organizations so by digital transformation what I mean is that more and more the products that it provide are being are driving the actual business business's engagement or the organizations's engagement with its consumers with its customers and our ability to react to market conditions ability to patch security vulnerabilities quickly to move more quickly to increase time to value is is now being pushed like it never has before so what we need to be able to do is increase change of velocity in volume while simultaneously improving stability and governments we had a modelbased approach to this as well and we'll talk about how that links into change approval policies in a second but it's really important that we adopt change approval policies as a way of doing this they're a key way of hitting velocity volume stability and compliance and governance as it says here um so yeah we have a first look at the maturity Journey we have around this so around the entry point to change so what we're trying to do is is get to a starting point where we can move things forward so start looking our Legacy workflows and replacing them with flows you know reducing our technical debt start using change models just for normal standard emergency changes but start with motion of understanding change models understanding State Transitions and how they work and what we're trying to do with the components in our modern change management feature set is breakdown change the change the technical aspects of change into components so they can be used because what we found with more traditional approaches to change management where we had one big monolithic workflow for each type of change over time that grows right and it becomes very difficult to touch very difficult to understand risky to change um and also technically complex for people to be able to go in there and work out whether they're going to impact something else um on top of that we want to layer in ways of approaching risk so we may not want to actually use those live at the moment but we want to understand what's available to to to switch them on if you like and and and and and have them there collecting data so that when we choose to if we choose to use them we can start embedding them and all these components work together so when we use change models it gives us an opportunity to use change approval policies when we use change approval policies it allows us to use things like success scores it allows us to use things like uh predictive intelligence for risk we can use them all independently right there's no real need to have one or the other you don't need to do change models and then approval policies but as we'll show you in the maturity Journeys that we the slides that will follow this there is a kind of logical path there is a kind of path that we think is is the best approach to how you go about doing this in reality but just to key into that there's no reason why uh it's better to do one person than the other in terms of technical approach it's just more from an organization from a process maturity point of view and you may find in your organization you want to take them slightly different order okay so where we see change moving forward is first of all when we foundations it gives us opportunities to start driving Automation and automation drives velocity and volume we can handle more volume of change when it's more automated we can get a faster time to Value as well because more automation means a lower time that change spends and approval and really the speed of most changes is measured by the amount of time it takes in approval we don't really mind if a change in schedule six months in invance right that can be a really good thing we may need to know six months in advance is scheduled but when we're doing approvals that's when the work is being done equally we don't really mind how long a change spends in in the new state right someone drafting a change early getting themselves ready producing the documentation it's not something that needs a lot of change management oversite so it can stay there in you for a reasonable amount of time the process really kicks in when we're starting to look at the assess and authorized stages and when we move through those stages into schedule then kind of everything goes quiet until we move to uh move to implement we also want to consider some of the shift left processes we'll use that phrase a lot throughout the webinar so by shift left processes I'm talking about things like Ops where you have things that are traditionally been used in the change assess and authorized stages which are now done to the left of where change sits so it's entirely possible that some of the assessments some of the authorizations that some of the data has already been collected by the time the change is raised if we pull that data in we can make things flow faster and again Central to that is change approving policies moving towards a look at you know as we move forward as we're using more devops more site reliability engineering or application performance monitoring we can start to automate more and more around the business and we also want to revisit the ital change types right normal s and emergency and we want to be able to Federate those change types a bit better so what we want to be able to do is allow teams to work within the modes of change that they use like infra like patching like devops um but also apply the right governance at the right times to those changes and we want to be able to track that governance as well and again change approval policies are Central to that so in the journey towards increased velocity in the journey towards increased volume of change and handling that with the same size teams you have now with the same amount of effort you're putting in now we also need to be able to track government and we need to automate the track of that governance because if you have more changes and everyone's getting more and more compliance all the time and there are more security threats than ever we need to be able to make sure that our changes are actually fit for purpose that they're following the change process that the that the authorizations happen at the right time we know why a change needed authorization we know why a person needed to authorize it or we also know why a change was automatically approved because we already had evidence that these steps had taken place okay so change approval policies so looking at velocity volume stability and compliance and this is the first time we've had a slide on these in this series and it's the only time this slide is going to is going to pop up because really this is our change envelope right these are the four things that we're trying to work within and we want to be able to increase all of them at once and traditionally it's been kind of difficult to do that but with change approval policies we get the ability to push on all of these different vectors we have the ability to handle velocity right if we make approval faster if we have zero approval within a chain if we can evidence that then we're able to make changes happen faster we're able to achieve a higher TI of value that's a business imperative right the ability to do that drives our ability to respond to market conditions to get products out faster to waste less time and less cycles and it also gives us the ability to do smaller more incremental changes and with smaller more incremental changes we we we get a higher volume of changes right necessarily if we're doing smaller changes more often we will have a higher volume of changes if we apply the same scrutiny that we always did to all those changes then we're going to need a very big change team and a lot of people doing authorizations and things are going to grind to a hole if we can't achieve the velocity with these changes what we tend to find is these changes start stacking up and that has a knock on effect which is a lot of teams like devops teams are not working in that Paradigm their changes were never designed to be all applied you know 30 40 of their small changes all at once you can get unintended consequences as a result just of stucking changes up so actually by handling velocity and volume we can see an increase in stability so it's it's fairly well received fairly well known that as we make smaller changes and we make them more frequently it has an impact a positive impact on the stability of the organization if we make change faster as well we can fix things faster and we can preempt stability issues sooner we can also take advantage of faster patching Cycles to make systems inherently more stable and while all this is going on if we're able to automate things if we're able to gather and collect evidence if we're able to see a line of sight through from a policy through to an approval policy through to the evidence that collected and the decisions it's made we're going to decrease the workload we need for compliance so we're able to show compliance easier um and we're also able to deflect audit a bit because if we're able to show things to Auditors and give them the change system and say you know go knock yourselves out it's in there there's less chance that we'll receive you know a high level of scrutiny on certain changes whether they can't see the line of sight because Auditors don't like being able to or not being able to see things so being able to go into a system look at it assure themselves that they have a line of sight in what they're seeing they can go into a change and they can see why an approval happened they can see who approved it they can see the data behind why it was approved or why this change was approved automatically that gives them a level of assurance that makes them think they don't maybe need to dig quite as far as if they have to ask you questions about why a change and you have to produce that manually or produce an Exel spreadsheet so talking about the overall modern change management Journey so this is tying what we're talking about today with what we're tying into the other sessions that we're having so we talked about purpose foring change models and that's really the first step because that allows us to start thinking about change differently we don't have to actually actively do change differently at that point right we can still use models for normal standard emergency change and we don't have to have any more we might add on a devops Model within that Paradigm because we have a devops product right a great product out there that you can use and that would give us enough space to play around to experiment and see how to use the new components but as we make that move and we move from workflow to flow we move to State based flows again covered in the previous call as we start using State transitions to automate things we're actually starting to use sets of components which stand independent of each other which we can change and deploy in various different types of change in various different change models so that gives us an opportunity to be more creative with our approval policies because if we apply an approval policy to normal change it's going to immediately affect a load of changes even if it's not set conditionally to fire on every single change that comes into that to to normal change it's still there sitting there in the change flow or workflow and it still has a potential to be hit by any change following the normal change workflow by having Change Model set up we can start looking at change approval policies that would only ever fire in a given model would only ever fire for a lowrisk change or a packing change um or change being made by devops so thinking change models decluttering uh the the flows and workflows around the change models and change types that you have is the first step moving on from that we've got change Improvement policy which is just subject of today so again within that and I'll show this in a couple of slides there is a maturity curve So within each one of these bubbles there's their own little maturity curve and and they don't have to be kind of executed sequentially you can do all these things in parallel you can have different areas of your organization moving at different speeds right but people who run the main frame I'm just gu are likely to be slower at adopting things than the people who are in a devop space or in a cyber relability engineering space that need to start moving fast that have a need and have their own processes that you want to take advantage of so what this approach allows you to do is spin up change models for them and then start moving along the maturity curve in different areas maybe at different speeds and understanding and by doing that we also drisk this transformation because by being able to look at the way teams are working a to work with smaller teams to Pilot to experiment to measure to assure yourselves that things are working and then scale out in that area we have we have less risk overall than just going into normal change applying a load of new approval policies moving it all to flow using Advanced risk management in that space you know you're suddenly going to find yourselves in a position where lots and lots of things change all at once and as we said before smaller incremental change is better even for change management after this we've got another webinar on damic risk so that's around um using techniques like machine learning using things like success scores to look at the change to look at the change performance using things like Risk conditions to gather structured data and embedding them into the change process and how you do that and approval policies is the building block before that because things like Risk scores are great right they tell you about why a change was high medium or low they might give you some insight into a team that's performing badly that shouldn't be allowed to do a change without approval but when you combine them with change approval policies you're building in automation to take advantage of that data so Dynamic risk in a way comes after understanding change approval policies we've got some other things we're looking at in the future as well so it's already important to start looking at change success and understanding how good we are at knowing whether change is successful or not and then when we know that also understanding whether those Chang whether the data around the changes the impact of those unsuccessful changes was accurately measured because it's only when we have a good change success feedback loop that we know how good we are at measuring that that we can start using Dynamic risk properly because there's no point in having success scores if you don't know they're accurate there's no point in having predictive intelligence out there looking at things unless you know the data it's looking at through the changes is accurate and we're also uh looking at generative Ai and insights for risk management for change management in general so the ability to make raising changes easier the ability to draw Insight across the change process but that's for the Future Okay so ital change types not going to dwell on this long we covered it in a lot of depth in the last call but just to show you there are there are a load of things around these Chang is technical things right we have things like business rules that fire we have approvals run we have workflow we have a state model sometimes we have templates to use in these and these changes especially around standard change and we have tasks that get spawned when we make changes so today we're talking about just a subset of these and by looking at these things and by pulling them out and making them into components as we talked about before you're able to have a less risky approach so drisk the process of transforming the change process so specifically uh what we're going to look at today is uh the Legacy approval process and have to move it forward so previously with change we had approvals and they were in workflows we'll show you that when we do a demo so that the approvals were buried in the workflow and that and then we could from there we moved to a point where we could call change approval policies from the workflow that's what happened in 2019 and from there we were able to start using change approval policies as a component outside of the workflow but the workflow is still kind of end to end you still have this big monolithic endtoend change workflow lots of you will have it when I show you a workflow in the platform which is our our out the box workflow that exists now I think a few of you will look at it with a bit of Envy thinking that you wish your normal change workflow was that simple I worked in implementation for a long time I've seen a lot of change workflows and they are rarely simple so from being able to decluster the change workflow being able to break it down into State based workflows we can then start using approval policies to do other things so we can start using approval policies to do things like um the the assess stage in change we'll talk about that later and we also had a state model which was designed for I change types so we had a state model that moved from one end to the other and didn't handle roll backs particularly well you could handle them from within the workflow but from every state you had to work out what you'd roll back and and you had to put that in one workflow so again by moving towards models by using model States and by using State Transitions and state based work flows we can make the workflow a lot simpler when we look at the change workflow you'll see how many items on that workflow are actually just down to the fact that we're not using or we using an ID workflow that we're using um that we're driving our approval in that workflow or making decisions in a single workflow so what we're moving towards is change approvement policies so these are decoupled from the flow so so when you have a workflow or flow that caus a change approval policy some separate logic that lives somewhere else to be fired and and you can reuse approval policies across different processes so you can use them for different change types you can use them for different flows you can use them for different stages you can choose what you use them and you don't have to go and change the flow to go and change the approval policy you can also see where an approval policy has been applied so you can track back and see what types of changes what models of changes are actually using that approval policy so you can be sure you know when you're changing an approval policy who you're going to affect we're going to show that as well approval policy also has conceptually a direct link to policy and compliance so when you have an approval policy you can do things like you know there's policy statements like every change to a P1 uh to a critical Service uh must be approved by appropriate people and we can link that to an approval policy which has that logic in it which checks directly to see whether the change is impacting or is being made to a critical service and applies the right decisions based on that data again we'll have examples of that later and we'll go into the nuances of why that's different to have a way traditional approvals were done and by using State based flow we get to use the approval policies in different stages of the change so we can have a set of approval policies that you use for the assess phase that do things like peer review and by doing that because traditionally what we'd have done is we'd have assigned it to appear ass sign the change to appear and that peer would then move the change forward with approval policies we can have an actual approval in the system that says this was a technical peer review because we know what policy was applied this is why the decision was made to request the peer review maybe it was a change being made to a system which was moderately or highly critical maybe we need 40% of people within the team to approve peer review when it's a critical system we only need one person to approve within the team when it's a non-critical system those are the types of examples that approval policies handle really well and handle within the logic in the approval policy so by building those into approval policies you get a modular item which conceptually links to your policy and compliance and you can demonstrate when it's it's used when it fires the decisions that will being made we'll show you that and by doing this you reduce the technical complexity of your change process because by trying to capture all this in one big workflow and then having anything else that hangs around the side captured by business rules we end up with a very difficult to change process we end up with a very complex workflow that becomes quite brittle if we change it and we also end up with you know lots and lots of business rules around the place that handle all the edge cases which is not a good thing the other component that's important for this is the model States so having a having a set of component states that we can use that we can then attach flows to that we can then attach approval policies to so by doing that we build up a set of components that we can go out to people within it and we can say to them okay what states does your change need you're a Devo team you may not need an assess State because it's already done the pipeline how do we make sure we've captured that data how do we make sure that the change flows through with the right authorizations how do we make sure that we only move from one state to the other when the right data has been captured and we do that with model States so having change approval policies attached to the right model state is an important thing for us to be able to make sure that our change policies are aded to okay so change approval policies what do we use them for so traditionally what we did with approval in change is we looked at the change to see whether it's high medium or low risk and that could be a manual step right it could be a change manager or someone else going in and just setting that field saying I've looked at the change and I think this is a highrisk change or a medium risk change and then moving on from that we had things like questionnaires that went out that could set the change based on the answers and questions or we have things like Risk conditions that actually look at the data on the change and set the change and we have more and more of these things that we can kind of bolt on that are more and more structured as we go but what we want to look at for our policy inputs is this kind of data so rather than just looking at high medium or low risk and then sending the change to cab if it's high and allowing the change to flow through just a manager approval if it's low we can actually examine the things that make up the risk from the approval and that's really important for that line of sight from an auditor looking at a change because it's difficult to say to them okay so this was a medium risk change so why was it a medium risk change or this went to cab because it was a high risk change why was it a high risk change you have to then look at the change record and try to work that various organizations will have various levels of maturity being able to point to exactly why that change with risk is high or medium or low for some of them it is completely a manual effort to be able to kind of pull that change apart and work out why that risk rating happened So within the change approval policy if we look at the aspects of the change and we assess them uh we get the idea of having certain guard rails in place so we don't need to look at all the data right sometimes high medium low for changes is good enough right we've looked at some stuff we've combined these different aspects of the change we've combine them into a risk score high medium low but what we can also do is we can just double check so we can say okay well is there a P1 right now in production on one the affected Services is there a P1 incident right now because we don't want to make a change without a significant level of approvement unless there's no p1s and has the CH has the system that we're looking at had any failed changes recently are we are we talking about a system that's undergone a lot of instability in the past few weeks we can look at things like outage records we can look to see whether things in the change process itself has been completed so for instance things like whether certain Fields have been completed in the change whether there's been conflict detection done already in change whether we've DEC conflicted that change and someone has followed that process we might more look at things like lead time so if you have a process for a lot of people have with it change is a process where um a low lead time means that you want to get additional approvals on the change you want to get some more people looking at it we can look at these things too we can also talk about more Dynamic change approval policy later so we're going to go into some examples but looking at things like team success score and model success score really important so looking at how successful that particular uh model type of changes um is more important is you deploy more and more change models so you can look and see okay how good are we at devop change how good are this team at doing change are there any indicators do they pass within our thresholds to allow them to just use this kind of low approval or no approval process that can be applied to standard change as well we'll talk about that when we talk about low risk change towards the end of the call we can also look at shift left data so we can look at data in other systems we could call out to an application performance monitoring system and see whether we have error budget at the moment to make the change and if not we can call for more approval or we can reject the change and ask them to do it at different time we can see whether the scheduling conflicts we can see whether there's been things like code coverage reviews we can see whether there's test the code's been tested properly near the system we have evidence of the testing and where the test threshold was over certain amount so we don't need to redo these things with the change process we don't need to ask someone to kind of print off a document and show it to us or attach it to the change or type it into the change we can actually pull that data in through the devops change velocity uh product that we have and those Integrations work automatically they will pull it in and they will evidence on the change the data that we're using to make the decisions to approve the change in a certain way to risk the change in a certain way as well and so by having that line of sight straight through to where teams can provide structured data from outside service now is an important thing towards volume handling volume and velocity of change okay so what we do is we look at these aspects and then we put them into the approval engine we have decisions that allow us to to me to to to root change in a certain way so we have inputs and from those inputs we have a set of decisions that are made through the approval engine and then we make a decision for instance whether we approve reject or manually review the change we could have a decision in here we will have a decision in here the change for instance goes to cab if certain things fail if we've seen a P1 incident is happening on the critical system right now that's impacted by the change it may be that you want s that change to cab and that's a slight shift in how we think about things we're not just saying it's high risk we're saying it may be a medium risk change but actually right now there's a P1 in production On a related system so we just want to run it by cab we want to get some stakeholders involved we want to set up a cab we want to run it by some people um and we want to maybe talk about scheduling change later for when that uh that that incident has been cleared that outage has been cleared so we make a decision from the data in the change from the inputs in the change to go for an approval for the change uh automatically to reject change and send it back because it doesn't have some of the data it doesn't meet the thresholds or guardrails that you want to even begin to process the change or to manually review the change to send it to a set of people to make approvals which are then tracked and service now and we have a record of the inputs that are used in making that decision we have a record of which approval policy fired to start analyzing that decision we have a record of what decision was made and then we have a record of the approvals that were sought afterwards so we have a full line of sight through from the people that approved it or the cab that approved it or the automatic approval that happened the decision that got made and then the data that underlies what we were looking at to make that decision so it's a really clear line of sight for compliance and audit so again velocity volume stability and compliance I'm going to switch across to my instance demo but what we're going to look at is what are approvement polies right we'll have a little click through and see what approvement policies are and how we use them we'll also look at more traditional workflow based approaches we'll look at approving policy within workflow you may still be on workflow you may still be on workflow for normal change for some time if you feel like that's something you don't want to touch right now you can use a combination of workflow and flow within service map for different models of change we talked about that in the last call so we want to look at approval policies with in workflow approval policies with in flow approval policies themselves and the decisions they made and the types of data that they can ingest for this part of the demo we're just going to look at really simple cases which is just looking at high medium low risk changes again later in the demo we'll talk about more structured data and how we consume that um and how we can make calls out to apis to pull that data into the change um so we have a full audit Trail and we're looking at more granular data when making the uh the improvements for a change so we'll look at the first things you need to start looking at which is do what we do now only use approval policies to do it so you gain better line of sight you may gain a bit of speed you gain the opportunity to to improve later to understand improval policies and to then to think about how you might use these more Dynamic approval policies for certain models to change for certain types of change at certain stages okay stop the sh sh hopefully all see my screen I'm just going to zoom in a little bit probably have a very big screen okay so from in here we can see um a list of changes within service now and we can see the different states the changes are in so at different states of these changes we want to apply different approval policies as I said before more traditionally changes only been used at the authorization stage of change so we authorize the change with approvals and we used again we used an approval block within the workflow to do that years ago and then we move to approval policies within this stage of change you want to use an approval policy to gather the approval record so that we evidence that these people have approved a so one of the changes we're making with approval policies that we suggest is that you start using approval policies for other things like I said peer reviews can be could be put through architectural reviews could be put through approval policies because we know Not only was a change approved but we also know what approval policy fired to make that approval happen we can see that this person approved the change because it was a peer review at this stage of the change just going to go into service operations workspace okay so from within here we can see what many of our agents will see when they're raising a change and what I wanted to draw uh your attention to is in here we have uh if I go to records this change we can see that from this change there was an applied approval policy again this change approval policies applied change policies is a related list that you may not have currently linked to your change um or currently visible on your change form so within service Ops workspace or within um the the traditional ui16 view of changes you can add this in EAS right so it's just a case of going in configuring which related list show and showing applied change policies so this shows us that for this particular change we applied the normal change policy there was a decision to assess technical approvals and there was an assignment group approval um and the activity name was technical approval so again we're seeing not only that there was an approval generated for this change we're also seeing that uh we're seeing why that happened or or what stage that was generated at so let's have a little look now um other aspects the change so if we go into a workflow so again traditional workflows as we know in love you can see in here this is this is a minimal normal change workflow right this is again I said before some people do quite envious of seeing something as simple for a change workflow I've seen them where you have to scroll like scroll scroll scroll to be able to see all the boxes and change workflow and it's a bit like um a national network well but within here it's worth noting first of all the highlighted box change approval policy and it's a technical change approval policy in there and it has a rejected and approved decision so from within here we have a block that we can call within workflows and that will call uh a certain policy for normal change policy and in here we can provide policy inputs to allow that policy to the data to run so that's from within workflow we do just worth drawing to your attention as well again talking about breaking changes up the components by using change models and using flow there's a few things that are worth pointing out so in here we have wait for conditions assess and on hold you can see there's quite a few of them what we're looking to see weight on hold in there checking Chang is on hold we have lots of boxes that are checking see if is on hold I'll show you in in a couple seconds when we move the flow that there's a there's a thing called parallel flow within FL that hand like for you and get rid of a load of boxes from this we can also see that from within this flow there are a load of things which handle uh the state changing so again we want to break that out to component we talked about that when we talk about change models and that's to do with State Transitions and breaking things down into modular States but for the moment we're talking about change approval policy which is contained within this box and as you can see the the flow will continue down its path according to whether that change is approved or rejected so now I'm going to move into the normal flow that we provide out box and Serv and you can see in here um we have a change normal Implement so actually it's not just the hold of normal change it is during the Implement stage and the reason uh that I um I'm just wondering whether I got the right one here want to get the so you can see me navigating the if I go here I change FL and you can see in here we've got our state based flow so I'll go into the change normal authorized FL which is the right flow to be able do we just wait this opens and we can see in here we're applying a change approval policy so so when we apply a change of policy if I open that up we can see in here again just like with workflow we pick the change policy uh within here um and so that will app fire that change approval policy and we'll go into the change policy and I'll show you that um in uh within how you can figure that change approval policy later how you make that available from within here uh when we go down the flow you can see that we we then evaluate whether the change was rejected or approved and we do what we do tradition workflow we fire out emails or we make notification in teams or whatever we need to do to tell people that change is moving forward and we move this and the state will then flow forward according to our state transitions you can see here how much less cluttered this flow is than the workflow okay and the other thing that I wanted to point out before is do the following in parallel so all those weight conditions are now handled by the fact that we've got parallel flow which handles weight conditions okay just something else to know there so in there uh we are applying the change of like two we'll look at some more policies so out the box we provide some approval policies we're looking in the future to provide more of these approval policies to give you more starting points for change management to give you more ability to have something out the box that you can use as a reference to say go and get some success scores or go and get some data from operational data like there's a P1 incident right now for the moment these are the ones that are provided P the Box plus maybe one or two more that I've got in my instance if I go into normal change policy that we saw before we just want to have a look at how this policy fires now actually this has very limited policy input so the change request is one of the the record itself and that's what I meant about kind of static change of we're just looking at that record and seeing what things are on that record we're not looking at the picture around it we're not looking at any devops data third party data we're not making API calls to pull that data um we're not looking at operational data like whether any P1 incidents exist right now whether there's been outages we're not looking at success scores we're not looking at the other data that sits around the chain the process data that give us insight into how well that team or that model are performing but we take the change request data and then we make a decision with it so as you can see see in here we still have cab approval right so that's one of the decisions that we make we'll go we'll dive into these and show you the conditions that fire in a minute but you can see we have a of decisions that are made based on the data we get from within the change you can see in here as well as I say before we have assess technical approvals so in here we set a condition saying that if the state is an assess and it's high or moderate then we should seek some uh some uh approvals around where the change can move forward from and that's how we have the answer field can we see the popup there great are you able to see the popup so I need to naate into it there should be a change approval definition yep we can see them okay you can see the problem so we can see in here we 40% of the users from this assignment group to approve the change at that point right so what we're doing is we're doing what we did more or less for years with service now but we're doing it in the context of gathering the technical assessment of that change during the assess phase so you could have a process that sends things for infos review for Architectural Review for technical peer review for document review whatever it is that you're sending it for they can be handled by approval policy and it will record why that policy fired what data was used in the policy to Fire and also it will record what the decision was made and who it was sent to and why so we've got a line of sight through there it's not just in you know some of you will have a system where the the assess phase of change is just handled by being assigned to someone and then clicking on the next button to move the change forward into authorized we're now recording that that person has made an assessment this also has the add benefit of them not necessarily having to go into the change record will receive maybe via te teams maybe via email they or on their mobile device um a a a notification telling them they have a change that needs approval so that again allows you to drive a certain level of automation a kind of low degree of automation around change management but it's important we have a lot of manually um reviewed manually authorized changes and we want to have a consistent experience around how we authorize those changes so we use approvals to authorize changes for more than just the authorized state for also forments Etc you can see in here as well we're still using the change request type field normal changes so where the change request type is normal that could equally be the model is set to normal just as a last thing in the demo um I'm going to go and have look at all the other change so from within the standard change policy and we'll talk about this later when we talk about no risk change we've got one policy in there it's kind of just an example right so if someone adds a thousand CIS to a standard change we don't want it to be a standard change anymore this is like a guardrail right no one should be doing that no one should be adding a thousand in this world in my world where we've just set this thing up no one should be adding a th000 CIS to a stand a change if they do we just want to maybe reject that change and make them follow the normal change process maybe we want to seek manager approval which is the case we' got here so we can put guardrails Within things like standard change to make sure that we're not that that we've actually checked that we can demonstrate we've actually checked that certain guard rils have been interative that not too many CIS out on that change as we start to expand this a little it starts looking a lot less like standard change right we want to keep standard change as being something which is zero approval right which is a repeatable change that these no approval that has a high degree of success so as we start moving away and looking at these things and thinking well maybe I don't want to make standard changes and reboot a production server on the critical system when there's a on outage in production you know we can start looking at that thing saying oh we can check for that right we can check to see whether that's the case and if it isn't we can rout the change for some approval it starts to look a little bit like something else that we're calling low risk change again we'll talk about that amaz okay so I'm going to just stop over there and pause for breath W and share the slide you probably in doing so getting the wrong screen again screen right do I need swap yeah yeah SW perfect okay so I'm just so demo recap so we can reuse those approval policies um so we have approval policies now that are modular and we can attach them to flows or workflows and they now sit outside of flows and workflows so we don't need to copy the approval steps from one workflow to another and that really is one of the for change models change models enables us to use that and we can use change models to make that more powerful H by doing it we're drisking the transformational change use approval policies for more than just authorization so use them in assess flows as well and they simplify your flow we saw that workflow and we saw the flow they allow us to just call out the approval policy and the logic is then contained within the approval policy we don't need to build it into the flow itself okay so there is a maturity curve around uh change approval policy so we T we showed them how you would look at something that's very similar to what we've been doing for years in change management which is looking at whether the change is high medium low risk rooting it to cab if it's if it's high risk rooting it for approval if it's medium risk maybe rejecting it if there certain facets to change if it's lead time is too low we want to change that kind of thing um they're they're looking at the change record itself and that's something I kind of call static static change approval policies we when we've got our heads around that we can start looking at more Dynamic change PR policy so that's what we talked about before around looking at data around the change looking at operational data making sure operational guard rails are being adhered to that we have policies like is this being done to a critical system is there a critical system in the impacted CI list so rather than assessing that as part of the risk and using the risk to drive the approval what we're doing is we're directly looking at it from the change approval policy and most times it will just pass it will just go through that because people are used to raising good chain but sometimes that will flip something that will tell us that for instance our Devo our Devo team that are making changes they just haven't done any testing right they said they'd always do testing they said it was always automated they gave us a thumbs up on that process we can now check it right and if one of those teams just isn't doing testing it will reject their changes so actually what we're looking at is dynamic we looking at the data around the change looking at the operational data looking at the shift left data from other systems the next stage is looking at uh change process data so looking at success scores looking at how successful change is so for standard change you can look at the success of that particular template we're looking to expand that maybe for all changes we look you can look at how successful a particular model is so how good are we at infro changes have we got to the point where in the last 30 days we've just been screwing up a lot with our own for changes and we need to root them for more approval because we've been screwing up a lot we can also look at how good a team are making changes so if team a are already good at making changes and Team B are already bad at making changes we can give team a a reward and allow them to progress changes through with less approval less scrutiny again capturing why that decision was made capturing the success for putting it on a change giving a line of sight to our Auditors but if another change if another team are breaking things with their changes or lot we can then look at that and say that they need to have some additional approval some additional scoy or maybe we're just going to reject change it and not let do changes I don't know so we talked about embedding shift left data so the next stage is looking at Integrations to pull data from say devop systems looking at pipeline data looking at things like what they've done security scans what the results of security scans were looking at eding test data didn't change and then looking at that data from the approval policy again we'll have a look at that later and moving forward we want to have more insight around that data how good are we how good are that team identifying they failed with changes you know are they actually do they have a 90% success rate because they're not telling us when they failed what we want to do is have a a a degree of insight into that so we can drive the behavior of reporting change failure because if you if you're fail and you haven't reported it we're going to spot it anyhow right so what we want to be able to do is have a level of confidence around our success scores around our risk scores across the change process that we can then break down into different teams but that's to come so that's the maturity curve around change and what we're doing static approval policy getting used to approval policies doing what we do now with approval policies then moving to looking at more data around the change that's been in service now things like is there P1 right now in production how we had outages in the last seven days then looking at the data on the change process so looking at things like success scores um embedding predictive intelligence risk into your change and looking at that from the change from the um from the approval policies and then embedding shift left data so looking at other data sources application performance monitoring devops key candidates for that other systems like sap for instance have their own quite often have their own change management kind of system within sa it may be that they're cutting and pasting data across from night so it's now again you may want to build your itation into there to build the DAT so now we're going to look at Dynamic policies and we're going to take an example of low risk change so we're going to look at a change as we said before that feels a bit like standard change but we don't want to interfere with our Vital change type we want have standard change as it is at the moment it's a catalog of changes that are repeatable that have a high degree of success um that are highly templated standard change is standard change right we're not rewriting all up policy documents around this what we want to have is a model Change Model called lowrisk change that takes changes in that gray area between standard change and fullon normal change where we know there's a degree of risk around these things that certain aspects can make this change risky you need approval but equally we don't want to have that change accidentally rooted to cap because it's just not in that category so it maybe changes that are repeatable changes which have a low degree of failure which have a low impact but they're being done to a critical system so we need to have a degree of approval within that so what we're doing is we're able to simplify the standard change process for a lot of you that may have some prance in your standard change process again I've seen that a lot we can say standard change is something that just needs no approval but for lowrisk change we're taking that bucket of changes that fall outside of kind of full on normal change but also don't quite make the we for standard change so in here we have for low RK change we have model states which are going to be pretty similar to standard change and though we do have an authorized state within that um that use State based flow for again so using the same components reusable components within change but we're applying approval policy to make that change more Dynamic so we can do things like use State transitions to make sure data is filled in so we may not have quite the degree of templating that we have for standard change we may be some data that require for that change it would prevent it normally being a standard change we can ensure that um data is in the change and we can check it with the approval policy so we can check it with a um with with our state transition definition we can check it with an approval policy we covered this in a bit of depth in the last but we can look in the approval policy we can see okay well this change is a standard change for team a right they they never fail um rebooting this production server but actually Team B fail quite often at it so it's not a standard change for them they need to have approval to make this change they need a a service owner product owner or a change manager maybe even C to kick in for them because their success rate has fallen below the threshold so by doing that we're not preventing every everyone in the organization from making that change quickly it may be that loads of the teams are just making it quickly they don't fail there's one or two teams that problematic this will automatically check the success of the change the historical success of the change and will apply an approval policy which will then all check it through an approval policy which will then apply approval decisions um and rout the change for approval based on the success score of the chain so it gives you a bigger window of or a bigger set of changes that you can put within a kind of high velocity change bracket and again reduce your work you need to changes because you're making approvals reducing amount of time it takes to do a change so increasing time to Value increasing your stability because you're not uh looking at certain changes afterwards and working out that they failed and then kind of shutting down that change later and increasing compliance as well because we can say every time this change runs we check to see how successful with the t- we check to see whether there's a P1 in production and if those things aren't happening we allow the change to go through like a standard change so again better line of sight for approvals hey Daniel real quick just heads up at the last five minutes we only have a it's a shorter session today oh okay cool that's fine um and real quick for everyone uh if we don't get to your question during the session today we'll make sure we answer it offline and I'll send it out with the uh the recap just want to that there so I'm gonna quickly look at some So within [Music] uh so you can see within the devop change flow what we're doing now is we're we're Gathering the change data by using a script before the change runs so um so we have a step within the change that gathers the change policy data this is going out to other systems and looking to see or within service now and Gathering data and and providing it on to change this is actually a subflow from within uh the the the flow here so this is going to gather the data and pull it onto the change some variance and then we apply the change approval policy and the approval policy will look at that data so if I look at a devops change we look at this change approval policy we can see in here the policy inputs we're looking at Tak into account much more operational data from around the change so we're looking at things like whether the tests passing on that change so whether we're getting a testing pass percentage from within devops from within the pipeline whether there's been outage in the last seven days we're looking at whether there's current outages at the moment we're looking at the total number of commits in the change maybe those if those commits have work items from there we're making decisions within the change so we will automatically approve the change if we look down here we can see that these are the conditions under which we will automatically approve that change and these are audited from within the change record so we can see this data we can audit it from within the change if I look very quickly we can see this is this data is recorded from within the change um and we can see what the data was that enabled this to come to the decision we can also see the applied change policies in here uh that applied the change so we can see it went from manual review um and that was because of the data that we've got within the change here that was inspected by the change of PR so we have a clear line of sight so something like a shift left process that allows us to uh understand uh why the change decision been made why a policy was applied who approved it um and we can speed up the change process so just share quickly okay so with our change approval policies what we're doing is we're driving velocity volume and compliance uh within change Daniel flip it over yeah it came out right the first time this time right the first time this time uh so they're modular we can reuse them across different change types as we showed before we can decluster our change process make it simpler make it easier to move forward uh they could be configured to configured to match what you have right now that's what we showed first or we can use Dynamic decision- making within change um to look at data from around the change from thirdparty systems we'll cover more in those third party systems during the devop session that we've got coming and we can look at shift left data so devops pipeline data from within the change and we provide a strong audit Trail within the change um that allows us to to prove why decisions were made what data was made to make those decisions or was colle to make those decisions and when approval policy is f okay cor perfect so I guess we we are right out of time we're we're just typing up some some more answers some of these questions um we didn't get to do some of the live answers today we can make sure um we address either some of these offline or we can carry them over and and talk through them uh their next session so I have the log of all our questions uh so we we'll make sure everything gets answered though so um on that note I think I'll end the call