good morning good afternoon good evening everyone Welcome to our fifth um s so modern change life cycle launch and learn session today we'll be focusing on multimodal change Daniel Davidson will be the one walking us through a demo and presentation today as always please do not be shy if you have any questions we do encourage you to use the Q&A function today as post to the chat unless it is you know something you feel that everyone needs to know um the Q&A function just allows us to track your questions a little bit better and answer them in a timely manner um and with that I will hand it off to Daniel hi there everyone so uh yeah welcome to today's session um as just covering some some housekeeping beforeand I think Chris went through most of what's on this slide but you know come off mute and ask questions if you want to if that becomes slightly chaotic then I think we might just structure things through going in the Q&A and asking questions if you ask questions in the Q&A rather than the chat we can make sure they're answered or of course raise your hand in Zoom um and we will someone will prompt me that someone's raised the hand because I won't be able to see it because I'm presenting that's all right okay uh first of all Safe Harbor statement um just read and absorb because um you know we may be talking about things that happen in the future and we're talking with the best of our knowledge and and with the best intentions but um as with all software things change um so uh sayfe hard the slide there for that reason um this is now the fifth right Fifth Fifth uh webinar we've done in this series so we're covering aspects of change management um as service now sees it and as service now has implemented it in the product so the vendor's point of view on change management and uh I think what's interesting is right now we're probably sitting in the middle of of what is one of the biggest shakeups in itm since I started working in it a long time ago um which is a change in how change is done and that's as a reaction to things that are happening around technology things that happening around the business like digital transformation and actually one of the things that ties together a lot of the different features that we've shown in the other and Concepts we've shown in the other webinars is multi change we'll talk more about that as we go through but what we're what we allow you to do with multimodal what we enable you to do is to experiment right and and and use some of these new features in a way which is safe for your business which is safe your change process um and to do that in a way that really wasn't possible before with um with normal standard and emergency change okay so we're going to talk through the evolution change this is a slide that has been at a few of the other webinars I think but it's an important kind of Cornerstone I think to all the um change webinars that we're doing so at the start of the process you know there was a situation where there wasn't really any control of change within it and and so um Change Control had to be put in place and so um that we decided as an industry that we needed to be able to have a structure around how change was managed um later on that was then standardized so we started to have the idea of global processes and that was change management so Frameworks like I came along to manage change and we've more or less been foll them all along and now we come to you know 2020 plus um and the business is now moving faster than ever before an it is more embedded in the business than ever before um the expectations around the velocity of change the volume of change um and probably the compliance of changed as well and how we report on that are greater than ever and more visible than ever so actually of all the itm processes probably changes the one right now which has the biggest business impact which is probably putting the most breaks on the business in terms of um digital transformation so it's really important that we think about change management think about how it should be handled um and move to a change enablement Paradigm and one of the biggest questions that comes out at kind of cxo level when I talk to companies is um how do I Federate whilst I maintain control and a big part of what we're doing there is happens in change management so you know how do we allow areas of the business to work in the way that they want to work whilst we still may have a layer of C control that allows us to um keep things stable uh keep things within our compliance guidelines make sure our Regulators are happy whatever that the parine happens to be in the industry that you work in I don't know if anyone kind of recognizes any part or all of this statement but you know change velocity is is handing High volumes of small incremental changes now and they're exposing the weakness in our in change management so change management is creaking if we do it the old fashioned way you can't expect developers who are doing 100 changes a day to come to a cab right and and also the amount of overhead that implementing those procedures takes on our development teams is extremely costly for the business it's costly not just in terms of the developers time because they're costly resources but it's also costly in terms of our ability to change in the way the business wants us to change because if we don't change fast if we're not agile then competitors who are get the advantage right they're able to respond to market conditions they're able to respond to their consumers they're able to do the business needs to do faster and so that drives obsolescence and and competitive obsolescence so it has an underling business impact the ability to handle velocity and volume and compliance within change has a business impact and we have to do that in a way that doesn't compromise stability and governance so a lot of sides to that to that envelope um if we build out a landscape you know of change management there there's a lot of complexity up until the change process and you know we're seeing things in there we're seeing repos we're seeing different ways of working Sr devop different degrees of of uh of of maturity within devot we're seeing cicd pipelines deploying things and and that could be on a daily basis an hourly basis or it could just be that we have automation around deployment and we're checking that before it goes into an environment for say our firewalls or our Mainframe we have automatic testing tools and we then have an observability layer and we have cloud and we have on Prem still and the Mainframe hasn't gone away there is a lot going on in there um and we need to be able to communicate across from these development teams which are now quite fragmented often around the business into operations teams which are more often not centralized and that gives us that devops stack which again is part of the struggle with implementing true devops is the the hand over from Dev to Ops and sitting in front of that final Safeguard you know that the grown-ups in the room change management is the change process and having cab approvals in that change process having manual approvals in that change process either means that people have to shortcut the process or we find creative ways of working with that process or we slow things down which isn't good and what we need to take is a different approach to to how we do change and so multimodal change enables this different approach so really if we if we think of it as a hypothesis you know at the moment we're trying to serve all these different people doing different things in different ways and we're trying to serve them with three changes of which really there's kind of only two types of change normal and eer normal and standard because emergency change is just going have uh either retrospective or low lead time and that normal process has to jump through some hoops and and involves a lot of manual process a lot of um a lot of manual triage and it isn't taking into account that there may be a team that's shifted left right that are doing things on their side of the fence already we don't need to do them again in the change process but we may need to know about them for the change process or it maybe they have some kind of instrumentation or Telemetry or or or or another system out there which enables us to run change in a different way like site reliability engineering with eror budgets uh it may be that we just have an area the business that doesn't need all those safeguards right like patching um and in order to make those teams work in an efficient way and not swamp the change team with changes in order to have uh the ability to Federate wealth maintaining control we need to do things differently and the hypothesis is that by allowing approvals and transitions to be conditional to that group to allow us to tailor our changes to the way those groups work we can increase lost in volume whilst we also improve stability in governance right so we're pushing out on all areas of the envelope and that's really important but also we need to do this in a way which is scalable which we can do an experiment um and I'm going to if we get time towards the end of the course I'm not sure we will but you know I can go through an example of how we we approach this talking to customers and how we we you know we expect people not to move overnight and scrap normal standard emergency changes but how actually multimodal in itself allows us to do things differently and just as a quick kind of bit of History around multimodal so mode one change or mode one within it is is working in in in in in a way that you you kind of know what's what's happening so it's it's a very structured Paradigm where what we do is is is facing known quantities and actually within mode two change what we're doing is more Purpose Driven So within mode two change we're being more flexible allowing things to be more agile allowing us to work within hypothesis and work within the areas of the business and be appropriate to what they need so the multimodal change approach that we have is around being able to work within both of those paradigms so we still have normal standard emergency change out there but we're providing a new way that you can adopt at your own speed at your own scale uh to work in a different way which is again um be tailored to meet velocity volume um and stability and governance within the appetite of risk of that about the organization and what that enables us to do is to build out a kind of happier picture than we had before where we don't have a block at the end where changes can flow through where we're looking at the work that's already been done in our development pipelines and our automated testing tools and saying you know you you don't break stuff a lot and your processes are solid and we've set some guidelines for you we know you're following them so we actually don't need to do much other than just grab information from you and make sure that's been done and you can do your changes or it may be that we have other types of changes which you know need that level of of uh of approval still we may need manual approval because of some operational context like a PW incident right now we may need that because just that system in itself doesn't have a lot of automation around how it gets things from the developers into the production environment so we can tailor what we do to meet the needs of the team and the maturity of the team um that's providing us with the changes and then not slow them down and also within that if we have that information if we're capturing that information for the change we can also make it visible to the operations team so we can hand over to operations something which tells them what the testing was which tells them what was changed within that change we can tell them you know whether guidelines were adhere to or not and and how many changes a day are happening for that particular system so it breaks down the barrier between Dev and Ops we're doing here is building out just an idea of of how many different areas you know within the business that we're responding to so even within Central it we have people doing things different ways and you can see within cloud services infr patching databases they all will be making changes in subtly different ways they're all following more or less a normal change process or a standard change process and one of the problems is that a lot of changes kind of fall between the two of them or maybe have facets which is c for by none of them and what we want to be able to do is is is tailor our services our change services to those teams um we have modern practices that we could bring into it we have ai ml which we can use it's a very good use case for AI ml is looking at the data that change provides and the more uh the more we iterate the change the higher volume of change obviously volume is something which is a friend of I ml so actually we're taking something that previously was a disadvantage and turning it into an advantage and putting that layer on and what multimodal allows us to do as well is switch on some of these new features in a safe way for smaller parts of the business to prove whether they work and to understand and learn how they work so that we can integrate into a process in a way that allows us to move forward safely and then scale and then outside of the business as well outside the core it we have teams that are working in a distributed way it may be that you know that one part of the business has decided to go out and get it hire its own devop team to do something or maybe they're using a different Cloud platform or a different set of Technology or a partner or vendor again we need to be able to make sure that we can reach out to them and make sure that they're compliant because they will be integrated with systems that we have most probably within the business we will be probably responsible for anything that goes wrong with those systems ultimately um so we need to have a way in which we're working with distributed teams that are not necessarily part of the central it Paradigm uh in an appropriate way and again multimodal change allows us to go to those teams to talk to them about what they're doing to make sure they stay within the guardrails and then to make sure the changes they make all conform to the guard rails or maybe they have to seek a manual approval so we again we're handling the velocity we're handling increasing stability and we're keeping governance in place okay before we move on to uh some of the multimodal features in the demo just one more slide on you know some things it's not the wild West right we have things that you can use but it isn't just as big as normal change right we have a set of states that you can use and we have a set of approval rules that you can use and we will monitor you in this way and this is what we've seen before and we make a contct with them to go through manual approval and we can monitor their success you know using things like success scores which we covered earlier or risk intelligence we can see how risky they are and how successful they are and by doing that we're able to gu different areas of the business and how an appropriate change for them to use and again it's reusable components that we're using for this so we're able to identify where those teams can improve how they make changes we can identify whether they need new data points whether the cmdb needs improving for their area whatever it is in their area that he's doing we're able to see how they're making change so we're able to see who's making change and we're able to see the purpose of the change they're making and the intersection of those two things allows us to to Really tailor change to them and understand what the issues are with their change and so what it's you know ultimately about is change management stepping back a little bit to being kind of second and third line function so allowing change to flow setting up the changes to flow delegating Authority for the individual changes to those teams because they can provide us with data but then stepping in where they need to where there may be a manual approval that's needed or also where they may be failing to make changes appropriately or or they haven't got the velocity they need so we're monitoring the change process in the background using things like AI machine learning success scores um so again stepping back to second and third one so multimodal change traditionally normal change in service now has a set of seven steps and every change flows through those steps and there are slight variances right the workflow may vary slightly at different points but it's one workflow end to end and actually that causes as technical problems and it causes as process problems it's not easy to have uh to change that process because everyone is using it right so if you want to change the change process it can be a huge and costly operation and that lack of the ability to kind of break things down and have smaller individual units that we're deploying out there for change means that it's more or less been impossible to change a change process in a large Organization for the past 15 years that I've worked in this area and so the way the state flows is already nailed down at the start in a normal change and everyone has to use it and so we then think of ways within that process that we can kind of slightly circumvent it look at the risk and make them not go to count but there are all small ways in which the change process changes from Team to team and what we need to do is think differently and think about how what states of the teams use when they're working right so for site reliability engineering we might verify the error budget Implement and close and change because that's what we need to do you know if we're having an authorized change we review before we authorize right a traditional change process it's almost Tech technically impossible to to allow that to happen in a workflow in a way that's um that's traceable Cloud provisioning again just some other examples patching a really good example too where we have a patching program that's been done a hundred times around the organization it still needs to be on the change calendar it's not a standard change we still need to authorize it in some way um but we have a different state flow for patching and as you can see in here what we're doing is we're breaking change down instead of being one big flow that goes end to end with seven states into a set of states that we can reuse and all those states have things which are common to them so those states have flows those states have transitions those states have data that we need and so we can as a change team we can curate a set of states that we use and we can string them together in a way that's appropriate for that area of the business so we can go out to them say we've got some stuff right it's just it's not whatever you want to do but we've got some stuff we can reuse and the Auditors are happy with that as well because by reusing those states by understanding what what a state means again it's not chaos it's something that we can manage and and uh and and maintain and we can continue to use normal change as well in lots of areas of the business because like I said the Mainframe is not going away and maybe that still does use normal change um so we can start to experiment in some of these other areas and create efficiencies and drive efficiencies where we need them so other things that we use within the multimodal Paradigm things like automatic approval State conditions policy-driven state models there's a list on the left hand side um they they what we're able to do is we're able to experiment them within a certain model so we're able to go out to a certain team who may be experiencing a lot of pain with the change process and say to them we'll break you off from what we're doing in normal change or in standard change and we'll give you a change type and we'll monitor it closely and we'll work with you we'll understand how it works and then when it works and we're sure it works we're measuring it works we can then set that up for you and you can go run with it and we'll continue to mon monitor you in the background and then we'll move on to another team we'll work out how they change works so what we're talking about is an area where you look at what the problem is put a hypothesis together on how to fix it work out how you're going to measure it implement it work out whether it works then scale it and multimodal change allows you to do that in a way which doesn't mean you have to approach normal change and change it for every one in one go so that's why it's powerful because it allows you to adopt a lot of the features that we have we shown in the other parts of uh the webinars in a way which is safe and in a way which is um experimental um and allows you to prove the value of what you're doing okay so first feature of Next Generation change to talk about is um is around what the end user gets the end user of change gets because what we're able to do with multimodal change is have a set of State transitions that allow the change to be driven through without intervention so if certain data is filled in we can allow the change to flow through and so if certain condition are met the change will move forward so someone in out in it will select a certain change a change model which is a purpose of the change and they should only be able to select the change model which is appropriate for them and we control that through a layer of role based access so it's like a change catalog or it is a change catalog but instead of just having standard changes in it we have the changes that they should be able to make and once we capture the information that we need from them in the change the change will then move on and follow process appropriate to the purpose of that change it may go through a traditional approval route it may be that approval isn't needed because we collect the right data for the right systems around it like in a devop paradigm or Sr but it goes through an approval and authorization process as we'd expect it to it may be that we layer on some operational data in there right it may be that patching can go ahead as a standard change but if there's a P1 incident right now in a production system you just want to not do some patching for a while or you want some approve them if you're can to do patching in that window so what we're doing is we're able to mix that kind of kind of Paradigm of standard change where you have a purpose a very purpose-driven kind of repeatable thing with the idea that some authorization may be needed where appropriate the implementation of the change carries out and then we close the change and it's all audited within the change and how does that look so in service operations workpace we're working to build out more and more of the experience around change at the moment you can go in and you can pick from a catalog of changes which again is driven towards the audience that's in that page at that time and it shows in the state flow really clearly and it only ask to fill in a few Fields because actually the the amount of fields on most organizations change for is is pretty overwhelming and quite often during a given State there's only three or four fields that you'd be expected to fill in and it may be because of the type of change in making due to Integrations there are fields which will be filled in later by an integration you know into the develop tools or whatever so we only ask them for the fields that they need to fill in at time so as it moves through it may be assigned to different people and they will be asked to to fill in data on the change as that moves through and if the data is filled in if we capture that information it's the right information the change can automatically move from state to state and that speeds up the velocity change it decreases the amount of work the change team need to do in terms of getting changes on stock or moving them forward um and it allows users to be more in control of the change and understand more what they need to fill in at any given state so we're being far more data Dr one of the other components within multimodal change as I said before is breaking down the change flow from being one monolithic flow into being smaller flows for each state and this has two advantages first of all um you can use the states to do what they're meant to do with a flow right so you can change States together in different orders or you can skip States entirely without having to re to re-engineer your process and the other thing that allows you to do is most places where I've looked at someone's change process especially in large organizations I really struggled to understand the normal change process you're looking at an end flow I can't understand what goes on there's so many different branches and decisions that get made in it I struggle to understand how it's properly kind of understood and tested you know and and sometimes people struggle to get changes through end to end in testing because there's so many nuances to that flow and whereas that change can that change flow can still exist within service now we're not advocating for multimodel that you change that you can start working in a different way with areas of the business that it's going to be valuable to so yeah set of a set of flows we provide you a whole Lo of them out of the box um that you can use which is specific to the state so when that state is entered the flow fires and does what it needs to do for that state we have state model definitions and the state model definition will take a set of states and string them together in a way which is appropriate for that change it may also preset some values within the change and it also allows you to set the access within that chain so you can see in the middle of the security and we have advanced security you can use things like user criteria to say who can audience to change or you can script it or whatever so it's a flexible model that we have uh within role base access um within the model States we can then when we add the model State we can then step forward and say how they flow so for a given State transition we can say what it can flow from and to and what data we'd expect to see in that particular state to allow it to flow from to that state okay so they're the main components that we have within multim challenge I'm going to skip to Deo then so just give me a second to my scre okay so within my UT instance I'm just looking at the list of change models and you can see we provide some for you here out the box it's the same stuff as we just saw in the slid so I'm just going to go through on a live instance but you can see in here we've got um if I go into the plan infrastructure model you can see we've got a couple of states in there so we've created a definition of the change model so this would be your Purpose Driven change and then the next thing we do is understand who we' want to access that change if I click on Advanced security down here we can see we can start using a familiar interface familiar from catalog and I think knowledge as well around who it's available for not available for we're using user criteria for that so we can also say who can edit that change so if we really want to Federate change out and allow them to change that change model then that would be the group that could do that we can have record presets because we know these fields are always filled out in a certain way for a certain model um and then kind of most importantly we've got theel model states that we flow to and from in here um so you can see in here we can move from authorized to closed only for this type of change this model of change go back and look [Music] at go into normal change you can see a familiar State flow in here and again uh this is out the box service now so you can see we can go from a test there's a set of four states we can move to in from we Define those State transitions so actually as part of the building a change what we do is we take some compon we take the states we take the state transitions we take the user criteria if you can see it and we put them together into a model so although we can have potentially a lot of different models of change within a business we're not looking after the components for all those things kind of all separately it's something that's maintainable we can reuse um components in a way that allows us to reuse flows allows us to reuse States allows us to reuse State flows just looking at the change flow again in here if I go to in flow designer out the box we provide a whole load of different uh change flows actually in within the latest version that I haven't got on here of um of uh devops and change we have devops flows in here too so we've enabled um as of a couple of weeks ago uh multimodal change for devops so when your devops teams are making changes when they're calling a change from Pipeline and they're passing across the object which creates the change they can now specify the model for that change and potentially you could have devop teams using different models depending on what data they're providing allowing the change to flow slightly differently and also getting rid of that kind of awkward thing where you had a normal change with a category of devops which didn't really make sense to me in terms of um circumventing process but um so now you have a change which is fit for purpose and you can understand when you raise the change because you understand the model and you understand the team doing it you can now look into those areas and see what the success of each one of those things are and you can intersect them and give you a really good idea about what the the chances of success of this change overall are and you can look back and see the performance of teams or the performance of models and Target continual Improvement in that area have we got any questions so far by the way I haven't stopped to ask for how are we doing for questions and hands up no one's interrupted me so we good Chris on the Q&A bud good yeah please continue using the Q&A guys we really appreciate it you're doing great Daniel keep going okay if there's any booing or anything like that and it let me know um just looking over at service Ops workspace so you know I've gone in as as LAX me here who's a first line analyst and um although Al my dialog window is slightly in the way here um if we go into one the instance we can just start looking at what that experience looks like in change um so if I go to create a change request again we're talking about that catalog earlier where you see what your what what your role should make you see for a change so so likely should be able to see a set of changes that she can select from the catalog so these are the changes that we've set using Ro based access for Lely to be able to see and we can see in already you know we've got normal change right nor The Familiar normal changes in there too but we've also got these things called pre-approved changes which is kind of a new wording for standard change and allows us to step out of maybe a little bit about what standard change is slightly and then we've got in here the cloud infrastructure change which is our color true multimodal change and if we click on that and go into it we now have a far neater view of what's happening in that change request we're only asked to fill in a couple of fields and we have an idea about what the flow is of that that change from within service operations workspace so LAX is now able to go in and drive the creation of change um knowing just what she needs to fill in and not being overwhelmed by a huge change form and this what we've got here in terms of the information she's got to fill in is specific to that model of change so we could be asking for more right if it's a more complex change we could be asking for more at that point but we're not constrained by just having one type of change called normal that she has to then work out what feels CH to fill in just going to go back to my [Music] presentation am I sharing the right screen here we're looking at your presenter view but yeah is that better yes yeah looks good it's SW from last time okay so um skip forward they're just thinking about you know what we do to make this real and um we still looking at your present interview Daniel sorry about that better yeah that was good so what we're looking around adopting mod to change is it a kind of continuous loop of improvement both within the changes themselves and within the business um so you know what we've talked about and what we've done with customers who are looking to adopt this is not talk about a wholesale transformation of how the change process works and that applies to whether we're talking about you know the adoption of new features within change or or or multimodal change itself because as I said before multimodal change allows you to experiment learn um and build out ways of working and then scale those when you're confident um of what they're going to do which is really important for change management because um you know people don't survive long if they break change management within the business so what we what we what we suggest doing is you know identifying specific issues you have with the change process maybe for some specific teams and then experimenting with new ways of solving those issues understanding how to measure their success so that you're confident when you're doing them that what you're doing is successful and that you're not kind of just moving forward with something that hasn't worked and you can pilot those improvements with small teams so multimodal allows you to Pilot those improvements in small ways without going across the business and then when you've done that you've got recipe books for scaling so you can start working out who else could on board that murder change or maybe what the next mod of change your building out looks like and so those new ways of working can include things from multimodal like the ability to you know engage with people on first line and present them in a catalog and have role based access and the state transition and state flow that we showed or could be that you're implementing features like Advanced risk for change um or success scores in that area only to see if it works and then that enables you to prove that something works in that area while you're watching it closely when you know it works roll it out to other areas of the business and so you know maybe think about again talk about a kind of main hypothesis around this it's worth working out what you're trying to solve at the time you're trying to solve it so when you're thinking about rolling out multimodal change maybe just take one of the smaller problems you have have um which could still be quite a big problem in itself um just an example here would be um that you know in general our management have lost the ability to predict accurately accurately predict risk or impact within the change management space and our hypothesis is that if we if we increase the quality of risk and impact assessments within change we should be able to have fast and more stable changes and so you would think about what features you can use within service now and and maybe other things as well wider things that could help you with that um and you would go out and discover what teams are are suffering from this where you might want to Pilot this um work out what your plan is and your scope and what you're going to implement to do it and then develop a set of patterns that allow you to test this and then scale it so really you know the first step is about understanding what the changes you're making in the areas you're making how those changes could be improved and that could be something like CNB data it could be the actual change process itself it could be using more automation more AI more machine learning um but when you've worked out what the the root of the problems are you then have to work out some metrics and Baseline what you're doing so you know working out how you measure the success of the of of the pilot that you're do um for that subset of the business and then once you've done that you can start to understand how multimodal change will be rolled out for them and pilot it in those areas um and and measure how successful is and then if it is successful you can take the approaches that you've learned about the new things you've learned about and roll them out to The Wider business so you know in summary what multimodal change is allowing us to do is not only create something in itself that speeds up change that allows you better measurement of change that allows you a more Modern Way of working that allows you to make your stakeholders of change happier because you're working in a way which is fit for them it also allows you to experiment in a safe way in a safe small way scalable way with different areas of the business to work out how you change the change process overall and gradually move people off kind of Monolithic normal change into a more appropriate change process for them thank you we can do some Q&A now don't know if anyone has anything to add we have a question here from Aaron and it's we're talking about site reliability engineering So Daniel is there a reason why SRE change was included as a unique Change Model um I think conceptually right so um it doesn't have to be one unique model um the way in which Sr Works follows a different state process to normal change right that's that's why it was included in that as an example but you wouldn't have to have one model for Sr you probably would start off with one model you could have more right the point is that actually you you start off with one and you pilot it with one team who are doing Sr or two teams or three teams which is you know again working out the scale of what you're doing um work out how you measure whether it's going to be successful and try it with them right and and and lock it down so only they can use that type of change only they can use that model and then if it's successful offer it to other teams you do s and if those other teams need to work in a slightly different way then maybe you need a new model but that's the flexibility it allows you to be in control centralized control of what change is doing whilst allowing a dialogue with other teams with other pods around the business to make the change appropriate to them does that answer the question you can come off mute and chat about it if you want or not I I guess so I I just don't I I I wonder like how much sprawl you get or you end up having if you are you know creating like Boutique change change methods or or change flows um and why you wouldn't try to try to control that by because I think if if if allowed to you know everyone would have a unique unique way to create a change or a unique way to process a change I I I I just I guess I don't I don't totally follow why Sr would wouldn't be just asked to comply with uh uh the normal process or a or a Dev Ops uh change or you know like something of that nature why why would we create a unique one a boutique process for a specific group uh those specific examples is because you shifted left with those areas so the process that they have um has a set of guard rails that they should have according to best practice put up to make sure that they can move faster because they're providing data um and they're providing steps to the left of the change process which traditionally the change process would have had to monitor in itself so what you're doing is you're setting up a mode of change for them which allows them to work within the guard rails that they've set up prove that they're working within those guard rails and work faster than the other teams who are so that's why right up your alley Daniel this question was written for you what is your perspective on using mul M IM modal change in a life sciences regulated environment and explaining this concept to a quality regulatory organization this is you so um so yeah I mean it's it's it's it's built for that right because if you're in a regulatory organization then it's almost impossible to change a change process um I've worked with a lot of them because uh first of all it's going to cost you probably maybe Millions right and I've seen Millions quoted by Big Four to change a change process within that kind of space Financial Services as well um what this allows you to do is to break off a pilot um and say we're going to accept some of the risks on this pilot and we're going to mitigate those risks of doing things differently by having a high degree of contact with that team so we're going to have risk owners who look at the changes and make sure that what we're doing within the pilot when we move it to live for this small area is closely monitored and that's normally accepted as a as an approach to risk by regulators and then especially with the idea that after a short pilot when you're happy that it's sticking within guard rails you can then write up what that change that particular type of change who has access to it because you can control that and what the guard rails are and actually that change should be more stable than what you've done before because it's more Purpose Driven so you're saying we know that they test because we've had a result from the testing tools or we know that they work in this way we're getting budgets back from the SR teams um or we know they've shifted left right because their process is is is within sap transports right so we know they're doing what they're doing over there because we can integrate with the data um so so actually it's it's it's a it's a very powerful tool within regulated Industries to make change flow faster because you don't have to do it all at once you can make sure that what you're doing within the small area you're experimenting with is closely monitored and then assured and then can be scaled out as you feel it's safe and if there's any comments on that I'm welcome to hear [Music] them question from Matt here so reporting and Matt I'm I'm assuming we're talking like performance analytics so how does reporting work on the models is it like the standard change catalog where you can easily check success rates uh so I'm not quite sure the scope of that question so we have success scores for change modes right so the there are two out of the box or there are two success scores for change right that we imp one is team based success and the other is modelbased Success um and then from performance analytics point of view it's a it's a data point right so you have you you have structured data around what model of change and changeing is so you can report on it you can slice and dice that data however you want so um so I think the answer is well I know the answer is yes but I'm not quite sure about the specific cases um I'm pretty sure the answer will be yes to that too it's structured data I'm not sure how much is out the box in terms of PA yeah so with um with the standard change catalog uh it actually adds a field to the change form called standard change template and I think that's what's used to drive the success scores of each individual template so I was wondering if the model would have something similar okay yeah yes we have we have we have model success with an it7 Pro great thanks guys got it man and we have a dashboard for that as well out the box in Pro okay any other questions feel free to come off mute and just ask we do appreciate how much everyone has been utilizing the questions and answers function as well all right think we're I think we've got everything answered in chat have a have a quick question actually if you have a moment it's a little bit tied to those uh flows independent flows kicking off so as we have moved into the change policies and looking at those flows We've ran into to a couple of hiccups where we would use um the you know the roll back functionality to be able to so imagine like let me just paint a really fast scenario your your change just got approved but on the Second Step somebody you know um rejected it and some of the information changed which means we probably want that first team to know about those changes because maybe they wouldn't have approved it in the first place how are you what do you suggest would be the best way on the roll back piece of that or have you seen people struggling in that situation I have seen lots of people struggle with roading back change and not from a technical point of view from a process point of view of actually what happens right and how you handle that um I'd say that a couple of things are appealing about multimodal one is that the state flow is controlled and the flows for each state fire when the state fires right so if you roll a change back previously with a change flow you'd have to implement an then turn flow potentially actively Implement what happened when it rolled back to any stage before that stage you know with within the flow and you'd have to kick off the earlier stages at that point whereas now when you reenter a stage it should kick off a flow a fresh flow for that stage um so it it it just seems much simpler from an implementation point of view to have the the flow defined at the state rather than end to end because you don't so many issues with having to loot back yeah that that's fair I think I think the part that that like very specifically and we and we can Sidetrack this I can we can have a a side chat was more about like the the flow contexts so you have multiple flow contacts running now versus one perhaps before and so if you need it to go back to that first layer of approval it's kicking off now multiple contexts and kind of struggling with that that piece of the process so um interesting what you just said let me chew on that and then maybe I can hit you guys up on the side yeah okay thank you quick question um are there any uh accelerators available in the IMPACT program for using multimodal change or um any good documentation or examples outside of this presentation that you could recommend I provide my change team uh so we have some good documentation on docs around technically how it works um I've worked with a couple of impact customers on large impact customers on on rolling this out and um I think there's been some information out there it's not something I'm particularly familiar with um I think that you know as this as this is adopted and as there's a demand for it I'm sure we'll see some more stuff being buil built but um have a look in the you know have a look in um now create there's definitely some documentation there okay colleague of mine Scott um Scott gamble writes that stuff um so you know if there's a demand for it I'm sure it'll be there if it's not already awesome thanks Daniel great job by the way appreciate it okay just a question on migration process do you do you see you say you work with several customers do you see them converting their normal change into a a modal change kind of as a first step or do you see them starting with you know creating different models for you know Point use cases and and kind of going going from there and then kind of coming back around to kind of everything else later so so no I haven't seen them move to normal as a model yet um the the most common thing I've seen is people who are on Flow designer for normal change so not using workflow anymore I think that makes things a little bit easier because you're not kind of battling two technologies there as um as a as a Dev team your service now Dev team um and then it gives you a route to to maybe move to um convert normal change into into a model and I think that would be uh something to do as well but generally we've you know we've headed off to do patch patching is a good example because it tends to be you know in the grand scale I think it's fairly low risk it's an area that needs to have a different type of change it's high volume so there's a fairly big payoff for implementing a m of change for patching with relatively little risk um I think now that we've got the devops uh multimodal change stuff in there there's a there's a great hook to use um multimodal change for devops and do that integration too because devops are screaming out for multimodal change and I think especially with more Sr integration coming into those now um again that's an area that I see probably people using another um appealing one is is sap um changes because generally speaking sap teams are using change management within the sap uh software stack uh building transports and then really just doing release through change in service now and more or less so those are the areas that I see them building out and to answer your question directly they leave normal changes of flow let people use it and then build out these other things so they understand multi will change a bit later but the aspiration is to move the whole lot across yes but they're just not there yet any other questions I see one from Susan Williams Daniel I don't know if you see that in chat but she asked we migrated all of our CR types to equivalent models for normal standard and emergency and at the same time we created a new informational mmcr there's a migration tool we used to do this there is a post on community that explains how to use that migration tool oh cool um share the post I haven't seen that so is is that a third party thing does anyone know has anyone else seen that I haven't seen that Daniel um just speaking from the engineering perspective but um I have I've encountered quite a few customers who have shifted onto models and they've just one for one uh switched their type mods to get going um and then they've slowly started to add a few more and break up the old if you like old school established types into models that suit their their business case yeah that's quite that is yeah that's building up yeah I'd say over the last few months has definitely been when you visit customers there's been a good chance they will have implemented uh multimodal change and they will be using um models for for things uh whereas you know if you went maybe a year ago I I didn't really find that many if any at all so it's something that's Gathering a bit of momentum I think and um and pace oh one more question popped up uh so there's some documentation that we've got on the API um I think just uses it uses the same API as as normal change isn't it's just a change API that it uses uh Chris I think that's I'm sorry what was that Daniel I was just saying that there's a rest API for multimodal change or does it use the normal API end points it uses the normal API end points yeah so nothing specific if you're if you're hitting if you're hitting change from a rest point of view um the same mend points work behind the scenes if you're using the older types it'll work if you're using new models it'll work yeah the models is just a field on the on the change so yeah pretty much okay yeah I think we are good um Susan I'll keep the chat open so if you do find that link you can send it within the next couple minutes here but I will go ahead and stop recording um thank you everyone for joining and for being so active in the chat today um our next call will be on August 30th and it will be covering devops so if you have any questions between now and then feel free to reach out to me personally um please expect the recap email which will incl the deck from today as well as the recording um within the next 48 hours or so thank you all thank you thank you bye