hello hello morning hello morning or evening all right hey everybody I see a lot of folks trickling in on the call we're going to give it about a minute or two before we get started uh thank you all for joining e e all right looks like we have a good number of folks in the call so I think we can get started Dan are you good to get started see you off mute at the moment y there we go all right awesome okay well welcome uh everyone good morning good afternoon good evening wherever you are uh Welcome to our first modern Chang Academy this is a new series that we're launching where we're going to have monthly uh discussions or conversations about different topics that relate to Modern change and modern governance this very first session is more of an overview but focused on our perspective on what modern change management is uh some of the key challenges that we hear from customers like you uh and some of the capabilities that we offer today that can help you modernize your change process uh before we jump into it going to have a safe harbor notice here um I'm sure you've seen this before but there there may be some forward-looking statements in this presentation uh these are really our best assessments at this point in time but don't take any of those statements as said in stone they could change in terms of agenda we're going to go through brief introductions of uh myself and Daniel uh my great colleague on the call then we're going to go into the customer challenges and opportunities around modern change then we're going to go into the solution overview and key capability overviews uh and share our modern change uh maturity Journey with you as well and throughout uh please use the chat the Q&A to ask any questions we'll try to address those as we go through we'll also take pauses throughout to answer some of those questions live uh particularly if we think it'll apply to a lot of folks um and at the very end as well we'll have time for Q&A where we'll let you come off mute and ask those questions okay uh brief introductions I'll start with myself uh my name is kayin castelo I'm an outbound product manager with itm I've been at service now for about 2 years now uh my primary focus now is on Modern governance so this includes our change management devop change velocity and digital product release um uh products so any anything around those please please love to hear your questions uh and with me today I have Daniel Daniel let you introduce yourself hi there yeah so my name is Daniel I am uh the product manager for change management and uh work for service now for just over 10 years um about seven or eight years experience in the field uh running implementations that did um uh everything on service now already but focus on itm and a lot of major change management transformation so after that worked in the product teams for the last couple of years and and now the last year or so owned change management um yeah that's good so let's uh start off with a poll me watch this poll one second okay you should all see it so what does what does modernizing change mean to you we have a few options here is it increasing automation uh is it moving away from Legacy iil change types to something more Nimble is it managing a high volume of change is it enabling your changes to happen more quickly is it uh managing your risk more accurately is it a better experience for your change requesters and the folks who are processing and reviewing changes or maybe you don't have um any specific specific ankling toward what modernizing changes for you and you're here to kind of learn about what the opportunities are so give this about another 15 seconds all right five more seconds okay and the poll sharing the results so with this group and we've seen this with other groups that we've we've had this uh poll question asked as well uh 50% so the vast majority find that the most important thing for modernizing change is around improving the experience for the individuals raising and processing changes this is a trend that we're seeing and we definitely have a lot of capabilities that we're working on um to to address this so good to see that consistency all right and looks like you took over the share so go ahead and jump into it yeah sure thanks K so um the structure of what we're doing today will start off at a fairly high level very brief kind of introduction to where uh why why why it is changing why change is important to that and then we'll talk a little bit more specifically about framing that question in terms of change management and the uh change management with the it and then we'll talk about some specifics around things that we have in the product things that you have available to you now um that you can be using to modernize change management um and that has several aspects it's around how changes are kind of categorized and Pro process uh the different um the different features we have for handling things like Risk and an assessment of the change um and also how we can how we can just handle problems like the velocity volume um stability and compliance envelope which I'll talk about as we go through okay so first of all very high level um what we're seeing is technology is changing it's been changing rapidly um for the last few years um and how we're delivering technology has changed as well as the technology we're delivering on from a CIO point of view and we see this um really reported um across customers across verticals across different sizes of customers there's more being spent on Tech and cios are quite often uh expecting more from that Tech that they're delivering on and sometimes they're not seeing the return on investments they were expecting um so despite more investment on Tech they're still seeing um service aages they're seeing uh poor user experience CTO is making bets on uh new ways of doing things so things like devops um things like faster time to value things like integrating and federating processes outside of it so that we can be more responsive to the business innovating more effectively um without doing that it leads to competitive obsolescence so we see that you know unless we can innovate effectively unless we can make changes fast and make changes the business wants to make um we find ourselves at paced by our competitors who can make those changes faster and from a ceso point of view we have more attack vectors than ever we have more um potential uh fines coming in we have more compliance to handle we have more on the technology that we do with doing more with the tech we have more data on it we have more processes on it so so that the potential impact of it vulnerabilities and and uh and compliance issues is greater than ever before um and there's more to watch as well um so that leads to a set of distinct problems and these things are really summed up uh as a set of disconnected systems that we have so as we've moved the cloud and being on Prem still you know it's made things more complex it's not made things less complex um we have siloed ways of working and and siloed processes and stakeholders we have pipelines that are delivering that are that are broken and development is pretty ungoverned in some areas and we have increasing perimeters so as we get as we go wider as we have more Cloud platforms as employees start working from home as we start bring your own device um and as we have more applications we have more vulnerabilities and more threats to assess and what does that actually mean so that means that we need to transform the way things are done we need to be able to deliver faster we need to be able to deliver more changes more volume of changes and we need to deliver them those those high volume changes we need to be able to deliver with less lead time than ever we need to be able to make changes faster and we need to do this while we're not compromising the stability or the compliance of the organization in terms of Regulatory Compliance and in terms of security so that gives us our change envelope so why transform change so what we have at the moment is really change a way of doing change which is being accepted across the industry so the ideal way of doing change which has worked for years you know and it it was a good thing while it lasted we still have those changes in the system so we still have normal standard emergency change but they're they're fairly inefficient for the for the variety of Technologies the variety of ways of working that we have in organizations today and they're not suited necessarily to high volume highly compliant highly stable changes um so really it's it's the change process has become more complicated especially the normal change process it's become more complicated it's become kind of Black Box we throw things into it and a process happens um and it's not necessarily suited to all things we throw in and it becomes very difficult to transform and also to enable that transformation to enable teams to work faster to work more effectively and more efficiently with the change process it creates risk the change process too so as we want to try and move away from normal change transform what we're doing in normal change for instance um that puts a lot of what the organization does in change management at risk because there's a lot of changes flowing through normal change and also when we're seeing risk evaluation we're seeing being very subjective so quite often risk is a lot of time spent assessing risk for changes and and when we look at those changes when they maybe they fail not a lot happens from changes that we spend a lot of time on and conversely there are changes that we don't spend a lot of time that don't get a lot of scrutiny that have high impact to the organization so we need a more structured way of doing risk we need a more predictable way of doing risk so what we need to move to is a new way of doing things and we've got several kind of major um key movers for this the first one we'll talk about in a bit is change models so fit for purpose changes we've got devops integration so we can actually integrate to other line other other developer systems and pull data into the system create more structured data create the ability to move faster create the ability to have more compliance from within our single system of record for change management not have to swivel chair between many systems we can use approval policies to dynamically move change forward so we can make approval where we need to make approval based on data and we can reduce the number of approvals needed where we don't need approval because the data is sound and we have a good idea of what's happening with that change and equally we can increase the level of scrutiny where we're not seeing the performance that we need from the team that are working or there is there certain complexity within the organization the operations of that time or the specific Chang that's being made and we can also start to use things like machine learning datadriven risk looking at pth change history to make our change decisions more Dynamic so when we need to bring in approvals we can base that on historic data of the team performing or similar changes that have worked in the past or not worked in the past so what we're hearing is is that we need to balance speed with quality compliance so increase of volume of changes could mean an increase in incidence um and also moving faster is sometimes odd with our company's compliance uh and Regulatory um regulatory policies so we need to be able to stay within those Frameworks while we start moving faster while we keep things compliant um we don't want to change what works so you know the current change process has been there for a long time oh just my screen and we have all these these processes that that have stood the test of time but they're blocking parts of the organization and more and more we see people trying to circumvent change processes or using things like standard change in inappropriate places to make things move faster um and we need to have we need to have traceability of data so we need to when we're making decisions we need to have data that's in service now in the system of record that's maybe referent from other systems so we need to use Automation and Integrations which are providing the platform to bring data into service now so we can make effective decisions automate wherever possible and also give people the data they need to make the decisions um when they're looking at changes moving to the next poll kayen all right let's launch this next poll should all see it now so two questions in this poll uh the first is are you feeling a pressure to modernize change from your business uh if so what uh or where is this imperative coming from and why second question is what are your biggest challenges around modernizing your change process give you all about 30 seconds to answer these two always all going in the same place yeah five more seconds sure so it seems like um most folks on the call are feeling that pressure to modernize their change but there are about 20% who feel like they're change process is working pretty fine very happy for you guys it's great to hear uh and of those who are feeling that pressure stability uh is most important so reducing outages minimizing the risk of outages um and also the need to focus on compliance and for those who are facing challenges around modernizing change uh the biggest thing seems to be buyin from different personas internal alignment and also uh General awareness of features and information to get started that second challenge we're definitely going to address in this call oh sorry I wasn't sharing there you go all right Daniel go ahead okay so yeah we we'll the purpose of this is to make you aware of the features that we're using to to modernize change and how to use them to modernize change and also to a certain exent what order you might want to consider adopting these features in to modernize your change management process the other thing we're hoping to do with this and with the other recordings we have so at the end of the presentation we've got call to action which shares some links if we want to share recordings with you that you can use that you can use to create your own narratives within your organizations that you can take to senior stakeholders other stakeholders within the business to to to promote modernizing change and we're also happy to share collateral so we can give you slides that you can use from this deck if you think they'll help you uh create that narrative within your organization um and hopefully from there you'll be able to create a compelling narrative around change modelization that fits your organization from what we're talking about today so the key St starting point for the state change transformation process is a modelbased approach so this moves us away from and alongside the itl change types we will talk about that in more detail as we go through the deck um but we want to adopt new modern ways of working and we want to do that within the Paradigm of a safe and secure change management process so it's compliant it's robust but it's also can move velocity and it can also handle volume this allows us to then kind of step back as change managers and start looking at the process from a second line point of view so although we can get involved with you know first line in changes if we need to we can still do that because there's more data in the changes because the process we're using is more specific to those changes it allows us to Target the changes we look at and also look at the performance of team look at the performance of changes we're making so that we can monitor the overall change process and we can make tweaks to make sure it stays compliant secure and works as fast as possible we get the velocity we need so actually from within this because we have fit for purpose changes because the changes we're making the process and the content of those changes is tailored to the to the group that's using those changes we can make change easier to raise we can make it faster to do and we can automate more of change without first of all without impacting our normal change process so we can do it outside of that box we can experiment and we can grow the change process and we can create new ways of doing change with reusable components that allow us to allow us to modernize our change process and that should also having fit for purpose changes allows us to have specific points of data that we can collect for those changes which give gives us better governance so the change uh types the ital change types that we understand so these are implemented in service now in the platform as change models we have three change models at least for you we have the three change models in place and the reason for changing the language away from types to models is that these control the process that you're going to follow these changes so as we know normal change emergency change and standard change have been around for a long time standard change with low-risk repeatable changes that didn't normally need approval in most organizations they need zero approval so we do these changes with relatively low risk and we can do them fast because no approval is needed we we raise the change using a template we schedule it and then we do the change and we close it emergency changes are either changes that are done in retrospect or changes that we need to make very fast or changes that we have we made very fast and then we need to open a change for uh either while they're going on or just shortly after everything else was normal change so everything else we do in the organization is normal change and that means that change itself normal change has become very bloated in a lot of organizations over time to handle all the different use cases that it was that it's that it's there to serve um so uh if I move on to the next slide um we can see that the artifacts around these changes the features that we were traditionally using to make changes in service now using these change types or change models um have become quite complex for normal change especially so things like our workflow our Legacy work flow or if we're using flow if we convert it over to flow um are quite complex to be able to to be able to cater for all the different constituents that use normal change there are lots of different ways of doing approval quite often manual so people are even manually adding approvals to it because we just don't know when a normal change comes in it's very difficult to tell and and make the approval automatic for that change make the selection of approvers automatic the approval process more automatic there are lots of business rules as well so there's lots of logic built in to say if this is happening then do this if this is happening we need this fill in if this is happening we need this fill in so lots of complex business rules and also a very static State model so normal change has a defined set of States um usually usually circling around the seven states that we have out the box in service now some people have some variants on that it's pretty much set in stone though that normal changes follow all of those States um so we need to be more flexible around the state model too to be able to have to serve different constituents different people who do changes in different ways um use of templates as well although standard changes use a lot of templates by you can't really raise a standard change without a template the ability to use templates from within normal changes is fairly limited and and not particularly widespread although there is a desire to use templates to make change raising changes faster and so by looking at these models by breaking out the specific changes that sit Within These these the normal change model and sometimes the other change models as we'll see we have opportunities that we can streamline the process that we have and create a new model that is fit for the purpose we're using it for so just looking at that in a bit more detail if you look at standard change they are lowrisk repeatable changes um emergency changes also had an authorized change within traditionally in service now and that means that we're doing two types of change from within our emergency change process so we could be just looking at a change that was that was maybe something that's particularly not very significant it could be significant or not very significant but the emergency change process is applied to it so we have to follow the same statement model we have to follow the same process and workflow that we have for emergency change it makes emergency change a little bit more complex and it doesn't allow us to easily break out the changes that weren't authorized from the changes that were just emergency the ones that were done in retrospect uh or the ones that were done because of a P1 incident there are other ways of doing it you know there are ways of collecting that data but we don't have distinct types for that we have to handle them both from within aity change but actually normal change has the biggest block of changes in it so we are doing devop change from within normal change we're doing lowris changes patching changes infr changes application changes we're doing Cloud changes as well as traditional Legacy infrastructure changes from within normal change all these changes have different points they collect data they all have slightly different processes they all have slightly different potentially slightly different state models they all have different people who can access and use those changes but by putting all in normal change what we're doing is we're saying here's a normal change now pick how to use it and what we want to do is switch that around and say to you are you doing an infro change well this is the change that we want you to make this is how it's processed maybe these are the templates are available to you to use and we think that will enable the change process to flow faster it will make changes easier to raise it will make changes more compliant and it will also make your approval and ability to do risk more Dynamic so models are the starting point for the change transformation devop changes tradition is well done either as part of normal change or quite often done as part of standard change it's a good example to focus on because devot change is not a standard change it's not lowrisk and repeatable it has aspects of it that are made lower risk in terms of the change process because things should have happened before the change is raised we should already have inspected uh the code we should already have done testing the pipeline ensures so that the automation which is bringing the code into production or into sub production will ensure that that's happened and should not run if the testing Falls below a certain level but raising a standard change isn't really appropriate for it what we should be doing is checking that change and allowing it to flow through without approval if the necessary uh guard rails have been adhered to and checking to see if the guard haven't been adhered to that we may need approval so for Devo change what we want to do is create maybe create think about creating a new model and again these are provided out the box for we so just looking at splitting that up so we've got our Federated change models that we create for those teams to use we can make it with with change models with the functionality within change models we can make it so that only the infr team can use infr models we can make it so that only the uh teams do patching can use patching models only the app teams can use app models so we can limit who has access to these changes appropriately but by make pulling them out of normal change and by pulling devops out of standard change what we do is we make the number of changes using normal change using standard change using emergency change we make the number of changes being processed by them smaller and that gives us opportunities to optimize those processes as well so on the right hand side we're optimizing processes by creating fit for purpose new change models or by using the ones that we have out the box for you beyond normal standard emergency on the left hand side because we've now taken those changes in for patching Etc out of normal change because we've taken devops out of standard change what we're doing is the ability to then take the logic out of the normal change workflow that would have handled patching that would have handled infra and make the normal change um uh easier to easier to use easier to work with and drisk the transformation of the normal change process as well so we end up with a more stable more robust from a technical point of view normal change process but also stable and robust change models that we can use to do things to to work in the way that area the organization needs to work so again looking at the artifacts that we have looking at the features we have within service now that we can use to make things these things easier you can see in here that all of these change models have a set of things they have States and they've got how we move through those States so they have a set of states which have the ability to move to and from different states so we can move from normal change we can move from new to assess to authorize to schedule to implement um we can control that state transition so there are features that allow us to control that state transition we have flows attached to those models as well and those were traditionally end to endend flows so the same flow or workflow would run for a change from when it's new to when it closes and that meant the flow was actually very complex because it needed to handle all the roll backs between different states um so by having change models what we have the ability to do is have state based flows um I'll talk about that in a little bit approval policies as well so traditionally the approvals were embedded within the workflow as an approval action within the workflow what we do now is we decouple that and we put it into an approval policy approval policies are reusable just like the states we have just like the flows so we can we can have specific approval policies that we build and make available and as we build out our new change models we can apply those approval policies at the right time to that particular model to that particular State we also have the ability to look at structured data from within the change model so for instance where we have a normal change it could be an infer team it could be a patching team or it could be a devops team using that change they all have different structured data around the change um so what we need to do is by having change models we can create the ability to leverage structured data because we know that model devops for instance should have test results security scans um it should have pipeline runs um we know that a patching um program should be linked to release and should have planning associated with it so we can actually make the change work faster and be more more stable and more compliant by leveraging structured data and then we can use that data from within things like approval policies so looking at Federated change models we also have the ability from within Federated change to use to make more use of templates because if we know that infrastructure uses these 10 or 20 different types of different different templates of change we can get them to apply those templates to infra and we know that because it's it's a a firewall change we're going to use the infra model so we can start templating changes and making changes easier to fill out giving a starting point for change so just looking at at a very high level how we can make change work faster so by tailoring the state model to the specific model of Change by having only the states we need we can make that change flow faster we can make less work for the people involved so we have less effort going to the change it can work faster but it's appropriate the area of the business are using it so an example of that would be something like standard change we know already that is basically a normal change with some States taken out most of us use that already it's a customized State model if you like for normal change to take into account we've already pre-approved that change but we can extend this so we can look at having things like change registration where we're just receiving vendor changes for instance or changes from parts of the business that have been allowed to or or by necessity don't use the change process but but by having change registration we're capturing those changes in the forward schedule of change so we can look for things like change conflicts and we can look for things like failed changes we can have our operations team know that a change took place and it might be the reason why they're seeing a lot of incidents so for those changes change registration we just put them in the schedule they move to implement review and close there's no authorization for the changes they're just informational changes that we're getting if you look at unauthorized changes we review the change before we authorize there's no there's no assessment of the change there's no scheduling it's already happened so by getting rid of those States we make sure that we're only following the states we need and that cuts down the amount of time it takes to process a change it cuts down the amount effort it takes to process a change so the point of having change models one of the points the first point is to is to tailor the state model so that it fits the purpose of the change that you're doing by using approval policies we can speed up the approval process so we can we can have by using the approval engine what we can do is we can look at aspects of the change now for instance devops teams may not have visibility in their own tools of operational data so the first thing we would look at in A devops change is whether the guard rail has been adhered to for the devop change itself so we would pull information from the devop systems via the Integrations that you've got out the box with most of the devop tools that are on the market and we would pull in the data that tells us they've adhere to the guardrails and that would allow us to authorize the change automatically but we can also look at data within service now so we can also look at things like whether there are any open uh P1 incidents right now we can look at things like whether the Chang is in a Blackout Window um so by applying operational data we can look at things as well like how successful that team are at making change um so by applying operational data to the change what we can do is we can make sure that things we traditionally might have checked in retrospect or we might have had a look after the changes were made and seeing what change performance we can actually look at that in the change itself as the change is progressing and we can dynamically set the approvals needed for that change as appropriate to the data in the change the change is missing data we can generate more approvals if the change contains data and that data fits within what we need we can have less approvals on the change we can speed things up that applies to devops as the example I gave earlier but it also applies to things like patching so where you have patching programs that are that that have a lot of testing up front and we're just really just scheduling those changes in um we can look to see whether we have the data for the for that particular patching change we can look to see whether we're in a maintenance window we can look to see whether there's a P1 right now and if none of those things are happening the patching goes ahead with minimal approval or no approval so there are lots of other contexts where we want to try and take out the approvals for a change process and that gives us the ability to focus more on where we need approval so as well we have the ability to use different uh different factors in determining risk for a change so first of all the risk of A change is the probability of it going wrong and the impact of it happening so that really drives how much approval we need on a change how much scrutiny the change needs we can look at things like success scores which look at the change the team success in the past of making changes and that is actually a weighted score for that team it's like a credit score for them and we take into account things like how successful past changes have been how many P1 incidents they created and we wait we take the number of occurrences and apply waiting which is configurable um to the to that and that gives us um that gives us a success score for how probable that change is to be successful and then we look at things like impact conditions so risk conditions on the change um and we can look at things that we would traditionally maybe you put in the questionnaire and ask someone are you affecting any P1 Services we can actually look to see whether they're affecting any P1 services and if they are or highly critical Services um we can then rate the change as being uh higher impact and by combining probability and impact it gives us a kind of calculated risk score that we can use to assess the risk of the change so that's datadriven risk but actually that's not the only way of doing risk um we have in our risk condition in our risk evaluation framework we look at the risk conditions and the change themselves we look at the risk assessments of the traditional risk assessments that we used we look at risk intelligence so we look at ml if you're an IT Pro customer we can look at similar changes in the past and work out um from what we've seen very accurately what the risk of that change is based on past performance and then as we said before we look at risk and impact risk and impact and probability and look in that Matrix and see what the probability of it happening uh combined with the impact of that thing happening is so that gives gives us a derived risk score and whichever one of those is highest we will use to give a derived risk on the change so we're looking at several factors of the change um and we're providing a derived risk value based on it so all of our itm Pro customers have all of these features right now they're things that you can use some of the features exist in the standard license as well like Risk assessments on the answer to the question earlier we talked about there was there are some answers saying that we we need to make change kind of easier to use and easier to raise easier to process for our end users it's important because actually most people uh in organizations report to us that users find change sometimes for straight into use they don't necessarily fill in all the details because they have a large confusing form in front of them in our traditional UI in service operations workpace we've really tailored the UI for use uh with change models so as we go through the states in a change model and that could be the change model for normal change or it could be one of the new models like Patchi or infrastructure or devops we have an overview page and that gives us only the information we need to fill in at that stage in the change it makes it easy for people to fill in the change form it gives us buttons we've got on their calcul risk that allow us to take actions at that point in the change so actually what we're seeing is the right information provided at the right time in the right State and the right actions prompted to get to us and the information on the right hand side is showing his relevant record information at that time so as the change progresses we might see things in that on the right hand side like Risk information um and that gives us the ability to to process change much faster to make change less effort to process uh and to get the right information on the change so that the the information we need is filled in at the right time when we combine that with some of the other features of of change models like State transitions we can automate the movement of changes between states if information is filled in or prevent changes moving from state to state if things certain things haven't happened like we haven't had a risk assessment made or we haven't had a short description filled in so we have the power to be able to create um uh to to to mandate what's filled in in a change what we require for it to move to the next uh stages to prompt people to fill in that information in in a really friendly and and easy to use way from within service operations work space and then to reject change or to not allow changes to progress that don't have the right information so as well within the platform for itm pro customers we have devops change velocity so devops change allows us to connect it provides some Integrations out to commonly used developer tools and this collects information from those developer tools so we can see things like the planning that's been made the stories the features um we can see things like the test results for when code is deployed we can see the pipelines that run that automate the movement of code in from those developer systems and build it test it and move it into our production systems so we have things like um we have things like gitlab that handles the the planning for the for for the for the deployment we have things like Jenkins and Ado is your devops handling the pipelines and we have things like selenium doing the testing we need to be able to pull that information into service now the developers need to work where they work with it we don't want them s chairing into service now to use service now what we want them to do is you want to integrate to their systems so we can pull the data into service now have it recorded in service now interrogate it to allow the change move faster but also have a record of why that change maybe needed very little approval because it had the right records it had the right test results in selenium because we had the stories within within gitlab because we know about the pipeline that's within Jenkins these Integrations are provided out the box to itm Pro and they're easy to set up and use from within the devops uh velocity workspace devop change workspace what this allows us to do is automate the change process because we have the data in the tool we can then set approval policies to run that take advantage of that data being in and we can automatically kind of audit the change and move it through if it has the right attributes if it has the if it's adhered to the guard rails so we can see in here we're saying the build was successful the unit test passed the test coverage was good there were security tests that all passed there are no current incidents in the operational uh in the operational space um and there's no deployment freeze right now so we can just allow that change to flow through and that can happen in seconds and it's automated so that's integrated with the tools that are deploying our pipelines that are deploying code out so that allows us to automate change creation and also when we've collected all this data we can measure the performance of those teams so we can use industry standard metrics like Dora which allow us to see uh what the time to Value those these those teams are how long it took them from raising the stories to actually deploying the code into production how often they have issues operational issues like incidents connecting up the data that we have into service now with the data and developer tools allowing developers to work where they work allowing our operational teams to work still within service now but connecting those teams up with Integrations again breaking down the silos allowing things to flow more more effectively more efficiently so giving us the ability to handle the velocity that devops needs the volume of changes the devop needs smaller more frequent changes giving us compliance and stability and also giving us security because we can see those those security scans have been done um from within the developer tools okay so we're just going to cover quickly the adoption Journey for change so first of all uh what we from a technical point of view we need to update our workflows to flows within service now flows are easier to use and easier to develop we also have a set of flows out the box we have state-based flows for change again we at the end of this presentation we will point you towards some videos that are on YouTube which talk about this in more depth but out of the box we have some starting points just like we've always had uh for our change flows and moving from workflow to flow um by having models in place it allows you to make that make that transformation easier because what we can do is we can start setting up new models using the outof thebox state base flows for them whilst we leave the normal change workflow or flow alone for the moment until it becomes less complex and less used and we can begin to attack it and make it uh more efficient and more effective so we when we need when we build our first models we go out to teams that that need to have a new model maybe it's infra maybe it's patching um maybe it's devops and we build the new change model for them we make it available for small number of teams and then as we as we learn how to use change of models and approval policies we can scale it out so we can start make allowing more and more teams to use that as we learn more and more about it um and as we do that we understand more and more things like how to do automated State transitions how to do risk how to do risk calculations with the data we're receiving from these new models to change and because we're doing that within each Change Model it's not affecting the whole of normal change we're able to experiment and work within our change models um to have new risk evaluation Frameworks maybe just for patching or maybe just for infra to see how they work and lays the foundations for The Wider change transformation for doing more uh more changes in purpose built models for allowing change to flow faster and to allow change to be more effective so all that improves governance as well so by having the right data on a change by having the right process of that change we're able to point to a process that's tailored for that bit of the organization and we can show that we're taking the right steps for patching or the right steps for info to make sure that A Change Is compliant secure and well governed it also allows us to investigate the changes which fail so we can tell that you know the change model is infra and we're seeing high high level of change failure within that area we know to talk the infr teams who are using that change so we're able to apply a kind of second line um approach to change management and start looking at more specifically at particular change models or particular change templates um particular approval policies and look to see where they should be applied and where we need to tighten the guardrails a little or where we can allow things to move a bit faster and by using the data and Integrations that we have out the box for instance with the devop change velocity um application that we have we can start collecting data in from third party systems testing tools um build tools planning tools um and that allows us to have a high level of Automation and we can also use this data within machine learning to understand the risk of changes better so what we're doing with this is driving traceability from the change process we're driving change velocity um the ability to look at changes that have happened in the past and see what happened within that change whether or not it was a change that caused an issue we can see from within the change if we have good integration to our tools that we're doing the planning on we can see the stories that the developers wrote which led to that change being executed which led to the the the the code being built or the changes being made that led to that change being executed so we're creating traceability by relating it to other records by having structured data um and this allows us to move towards full change Automation in areas like patching in areas like uh devops uh maybe in areas where we have application performance monitoring we can hook into those systems as well we can bring back data and we can allow changes to happen if we have error budget okay move on to the poll all right this is the final poll let me launch it okay have you started to modernize change uh if you have which of the things that we talked about today are you using you can select more than one option here and if you're not uh feel free to indicate that and hopefully uh today you learned a bit more about these things and if you have any further questions on that like Daniel said we have a lot of great reference material that we're going to share and just a bit that we'll we'll share also after after this webinar for you to review lots of great launch and learn videos and and uh blogs uh and then if you have questions beyond that please interact with us on community uh we're happy to answer questions there we'll give this about 10 more seconds yeah if you're in the we're not category you should definitely look at the next slide and go visit some of other presentations we've got like I said the collateral is out there um and we can help you with the transformation help you understand why there's a need to transform and how we can uh how we can take you through that transformation in more detail than we covered today in those recordings yeah I'm sharing the results now about half of the folks on this call are not yet modernizing their change process so uh a lot of great content for you to review a lot of opportunity to get to some of the outcomes that we discussed as well during this call all right back again so as I said before that we we we've got some places you can go and get information um we do regularly have launch and learn sessions for change we run a series um in the first half of this year um and those have been recorded so you can see them you can play them back in your own time but equally keep an eye out or contact your your account teams for information about when launch lears are happen in the future um as we release new things in service now we will always follow that up with with you know Community sessions launch and learn sessions that will enable you to use those things and understand how they fit into your change framework we've got blogs on change as well so you can go and visit the blogs um and also if you have any particular questions again contact your account teams um and they will be able to put you in contact with the right people to um to kind of power your transformation around change management okay I think we're doing Q&A now kayen right yeah wonderful I haven't seen any questions come through the chat but we do have about 15 minutes left so if anyone has any questions you can either use the Q&A or raise your hand I can I can let you off mute all right we have one in Q&A from Stephen we we currently use record producers to collect specific information for change models when it's submitted is a recommend is there a recommended alternative or something on the change management road mapap to replace the need to need for record producer for change requests so from service operations workspace uh yeah we have replaced the need for record producers I don't know quite the technical context you're talking about so I'm kind of talking more broadly here um because I don't know the specific context but from within service operations workspace when you go to raise a change you're presented with a catalog of changes which includes the change models that available to you and the standard change templates uh looking forward to next year we're we're going to increase the use of templates so more and more templates get used so we're expanding the use of templates is hopefully Beyond uh standard change into other change models so the change model the change model itself provides the the process and the template provides the content that someone could use and we hope to be able to standardize more changes but changes that may need approval um so yes so from within from picking the change in the catalog that then takes you to the overview page that we had a screenshot of earlier let me go find it um and this can be configured uh we this this overview page can be configured to show the fields you need to fill in for each state and highlight those fields to you so you can see in here we have sections like summary scope and impact those sections appear or can be configured to appear for each model to collect the information you need at the model in that particular state so there's a configuration of overview in in service operations workspace the overview page and change you can see it in here um there's a tab I think you can see my cursor probably but if you can't on the screen we've got we can see there's overview there The Details page you can see there's a little tab that says details in there still contains all the information on the change form the overview page is what we see as um as as reducing or eliminating the need for record producers any other questions any other questions out there is anyone using change models hases anyone come across any example where change models have really worked for them or they found some challenges and they want to kind of raise that now or is anyone using Advanced risk is anyone using approval policies effectively or is anyone using devop change velocity and they've seen the speed and velocity of change increase because of that and come off me and tell us your hand and I can let you mute well someone might be reaching to do that did get a question about licensing requirements for devop change velocity itm Pro is necessary for the bo change velocity okay well if we we'll maybe stay on for a few more minutes but if if there another oh there we go got a question all right you can speak now you can come off meute yeah I had a question about um types are using the change model do you have to stick to the AL the Box types when using change models or or do you have to create your own flow if you're creating models yeah so um it's in in our launch and learn series that we pointed to in the previous slide I'll put that up now um from within that Mod change launch and Lear Series this is covered in a lot more detail so recommend going there but basically the type field that was used in service now is not been deprecated we wouldn't do that but it's been replaced with the model field so actually the models there are models for normal standard emergency and we'd recommend moving all your logic for business rules for flows Etc when flows trigger over to models from types um a model is effectively analogous to a type um you can attach uh you can reuse flows for different models so actually the the the the kind of the the best way we see of doing this the most flexible way of doing this the one that enables the most kind of Federation of change is that each of the states has a particular flow so the flow for change starts when a state starts and ends when a state ends and then when it goes into the next day another flow takes over so when you're assessing a stage a change the assess flow will run and when you are authorizing a change the authorized flow will run and when we move out that state those flows shut down so what that means is that we can we have quite a lot of reusability of our flows so you know if if you have if you break down your flows into state-based flows what that means is you don't have to worry about what was happening in other states you can just say right when we authorize a change there are two ways we authorize a change we have a way that we do it for things that go to cab uh changes that need to go to cab for instance like um normal change or like infrastructure changes where if they're medium or high risk they might go to cab but for devop changes it never goes to a cab so we're going to have a cabless authorized and we're going to have an authorized with a with a cab so that gives you two State flows that you can then use and then you then apply that to the state for that change so you build your state model up you apply the correct flows for that particular State um so you have reusable component so I think that's the answer to the question is you don't have to rebuild everything um but you can you can reuse the flows uh within different models great good to know C in more detailed in log great question though uh one question from Anonymous that will answer live um so they're asking we want to integrate and connect our Dev tools uh as your Dev off specifically do we have any collateral videos with some examples of how this way of working would look like the answer is very soon we we are going to post a series of how-to videos to our community site that will walk you actually through how to connect to Azure devop specific speically plus other um csed tools using devops change velocity uh we'll also have uh videos on how to get to initial value um and our maturity model around devops change velocity that'll all be coming to community very soon it is not yet posted but I'll make sure um to send you the link so and also notify the scpt when it is posted uh since it is something we've been working on and are excited to get out there there is as well within the modern change launch and learn series if you go to that there is also uh recording in that that that talks you through a high level view of can be set up the launch and learn is very worthwhile to reference has a lot of great content we basically have an hourong session on each of the topics we discussed today and in much more detail Adesa did you raise your hand again if you did go ahead and ask a question did you are are you raising your hand or are you lowering it sorry I forgot to lower my hand oh all good no worries all right any other questions so just to summarize you know for your change transformation Journey a lot of you're doing this you're moving towards change models start by using change models start by moving across and setting up new change models and experimenting with them with smaller small teams and small numbers of changes and then as you get more confident you understand how that works start expanding into using things like you know the the change model the change State base flows or using risk different risk techniques for that particular model or using approval policies so what you can do is you can start to gradually experiment with new models in a safe way and as you get confident and you use them and you see them being used in a secure way you can start scaling out and move on to the next area to have new models in that area too all right well seeing that we're getting no further questions I'm going to go ahead and end the call here thank you everybody for joining thank you again Daniel for uh the great discussion and and covering all these topics in great depth I look forward to seeing everyone on our next modern change Academy next month thank you thank you