Change Management: Made it easy .

hello everyone welcome to my youtube channel smarter every day my name is saya and today I decided to make a video on change management just like I did it last time for incident management first of all I'd like to thank all my viewers who like the video and who found the video was very informative and thank you so much for watching it and continue watching to my videos and this time it will be for change management alright so guys I want to make this video short so I will try my best to keep as simple as I can no hunger no matter how much I try my whole purpose is to make sure that you all understand what is change management right change management in ITL is falls into one of the lifecycle called service transition in service transition we have five processes or six you know the older version have five and newer version have six they have you know divided change management into change management and change validation right so what does we what are the five processes in service transition we have transition planning and support that's one change management number to release in deployment management number three knowledge management number four service a sense in configuration management right so this is the five processes right now what does a change mad what is what is the definition of a change I'm sure you all must be aware of the change definition from my last video that is any any addition modification or removal of an existing CI is called a change and what is the CI CI is a configuration item anything in your organization that has a tag or a bar that can be tracked down in your CMDB for example any table chairs computers your anything that is stacked with a number and your organization knows where it is in which department it belongs to is called a configuration item so any addition modification or deletion of an existing CI is called a change or any addition modification deletion of a CI that is affecting IT services is called a change right now what does the change management anything controls the behavior of the change anything that allows you to perform a proper standard process to control the changes that are happening in an environment is called change management process right so I will explain it to you in a high level water change management and process and a detailed version of change manage process quickly without excuse me without any delays but before we go ahead and understand one should understand what how does a change management or change can help organization so there are many things in the change management that one should understand is how we can successfully implement the change and the success the success rate of the change can be achieved compared to the change failures when you're putting a lot of tasks a lot of efforts to implement the change we need to make sure there are successful changes right so what does the purpose of the change the purpose of the change is to control all the changes in the habit to control the life cycle of all the changes that are happening in that environment that is one of your purpose the second purpose of your change management is to produce or to minimize the business impact right so how does a business in plat compact play a role I will let you know when we are doing a change management process right anything that's broken anything that requires a addition or a modification or removal of what is running fine is called a change in the change management right how does it cause an impact how does it help you say there are some old servers right and they are supposed to be described in by 2015 but then they are still working on it but you know they're still working and you need to have that change right so this was already discussed and this was supposed to be changed in 2016 say exam for example we did that right so when when this server was implemented when this new server was bought in the year 2009 maybe for six years and after that we were supposed to disk opened we brought in the new change a new server in replacement of this this is a standard change so I will come to the types of changes also put a small example of change is anything that does not require a pool to implement that because it's already pre approved or authorized pre-authorized is called a standard change right so we have three types of changes guys so we have standard change we have normal change we have emergency change we also have a retrospective change right so what does a standard change it's a pre approved change or a pre-authorized change that does not require often approval so this change how can you identify it the success rate of this change in the last nine and three months should be 95% right so which means you this change is frequent in the nature like several patches right the patching of the service you you know it is needed for the security of the service the security you know the to make sure the servers are healthy the service the service does not have any degradation while they're working and stuff like that right so we you will see in the environment a lot of patching keeps happening and that does not require a couple because they're already pre approved changes there is all pre approved standard changes so that does not require another layer of approval right so this is other standard changes just remember standard chains are nothing but pre-approval or pre-authorized changes for example if I have to you know do this in Xfinity or a simple term for example any organization that you're working in you will see in your cafeterias there is a water cannons right a lot of people drink water in it and if you see on the water cans right there will be a bar you know which says this aqua guard or this water cooler is you know belong belongs to this organization this company XYZ it is in this block it is in this floor and hence the name XYZ b23 something like that right so this is how a CI is tagged this is how this is a configuration item for example that water cool oh that you know excuse me then what can over there is is is now empty right a lot of people drink water now it's empty now what happens is the facility watches that and they go ahead and refill the water now this is a change this is this is a modification of what it was that right so the water was there now it's empty no you refilling it now it does not require a further approval for a facilities team to go and talk to the managers and they're you know they're their managers saying there's no water and stuff like that it's a pre-approved change which is given to them authorization is given to them hey go ahead and go ahead and you know refill the water this is a standard change it's just like that like how explain it to you in in in your technical background if there are server patching that's happening which is a standard pre-approve Jetix right so having said that moving on to a normal change what does a normal change let's take this normal change is nothing but a Beltran change a change that's already been discussed a change that requires a downtime the change that people have discussed together on a platform and they said this change is important why it is important who will be responsible for it who are the teams that are needed and what is the downtime and when will it be implemented what does the output of the change or what is the return of the change and how critical it is so this is a plan the change is nothing but a normal change right a standard change is a pre approved change or a pre-authorized change a normal change is a well-planned change with the downtime and proper approvals links comes an emergency change what does an emergency change emergency change by the name itself it indicates that during an asset break fix situation during an high-priority major outages or high-priority incidents if you require any changes to be needed then you cannot wait for the approvals to come in play because during major incident management you have an SLA of 120 minutes or maybe 90 minutes for p0 p1 you have very less time to fix the outage or fix the problem part that's causing an impact of the whole business right so in some situations you've implemented emergency change with a a pool a bubble approval will be from the DPS or the global PE project executives or delivery project sectors or even service delivery managers and sometimes even major incident managers right they give them a pre-approval changes which means that they don't have enough time to play that maybe they don't have enough time to get approvals from XYZ people just go ahead and give a verbal approval coherent remain anything that can help us fix the issue as soon as possible right that's an emergency change now there is something also called a retrospective change now before a controllers pertinent respective change emergency change is always associated if not always most of the time 90% of the time this emergency changes associated with the high-priority incidents if you see there's a p1 running and if you see in emergency change to get connected to it or attached to it or associated with me with it which means they have implemented something they are modified anything they maybe they haven't they've added something they have deleted something for an existing CI maybe the about it space maybe they have rebooted as production server maybe maybe they they added a new new nas drive anything during the change to recover is an emergency ticket right so this is associated with the high priorities now moving on to the retrospective change this is similar to emergency change nothing new about it it's only this time this emergency change ticket will be a new change Rickett which will be documented a little later on has a new change itself it won't be an emergency change it will be a retrospective change the world retrospect means which may means that the change is already implemented in the past now you're documenting it retrospectively that's why the word retrospective change it's more or less an emergency change itself alright guys so I hope it makes sense to you the types of changes and you know what does emergency and the difference between an emergency my perspective change yeah right now having said that now let's quickly move on to change management I will start off again with the definition and within ITIM it's under service transition we have changed management right now one more thing I want to talk about in service transition like I said there are five process quickly I want to rehearse this it's important that you know this we have transition planning and support change management tool is in deployment management knowledge management and service asset and configuration management in ital there are 26 processes all together and which is if there is a question and if you are an IT expert or even a foundation certified if you want to know this which is one such process that interlocks which talks to all of the processes within 26 processes is configuration management right that's one of the processes within service transition is configuration where config management is one process that is interval of with all 26 processes and under service transition we also have changed management right see even here CI during the change management any addition modification deletion of an existing CI configuration management right information item is called a change right we I will do configuration management process a little later also I will new video by itself probably I'm gonna get enough time I want to do change management a lot of people have requested for change management right now let's go quickly start off with high level of change high level process of change management so that you understand and then I will move on to the detailed version of change management with an example just like a difference in mass spec right okay guys so I'll go a little slow so that you understand a high level change management has five steps just simple five steps right if you understand this you would understand change management one is a request for change right change the proof second is change approval third is implementation of the change for for this validation of validation or testing of a chain of fifth is a closure simple as that right just like an instant management I show you the process this is the five process change management high level a quest for a change change approval excuse me implementation of the change validation or testing of the change and the corrosion of the change these are the five major steps of change management and this five steps I'm talking about the normal well-planned change remember a plan change is called a normal change I know now that I have said that I'll give you an example a small example see a request for a change right see you have your bike right say you have active a' right now you realize that there is the tire that you have an active a honda right you know it's pre-owned right say like let's let's say you're active a honda is about 10 years old bike right now you want to replace the tire because it's often getting you know you often you often see that you have a flat tire and so on in many reasons to it and now you decided to change to a new tire right now you go to a mechanic oh you do you go to a shop who has all the tires with different brands right so you're requesting him for a change is saying that i want to replace my tire of my active a honda he says okay fine now he is going to give you options so do you want MRF tyre you won't see a tire in any one XYZ tire and so on and so forth while he's explaining that to you is also going to talk to you about what are the benefits of the change or benefits of those tires right but you end up saying listen i am worried about the risk that is involved in it right so which is the best tire that helps me save my life which helps me you know which is a reliable that can sustain for a long time and that can work that can you know that will not give me problem for very often and you know i want a good reliable tire right so he will give you an option and you select MRF tyre and you're approving for that change you are he is asking you with an option he's giving you the benefit you and you give back him the you know the things that you need you decide the risk out of it and you finally come to a conclusion and you approve it saying that yes go ahead take them out of tire change it right now when he's changing it he's going to make sure everything how it was before walking down somewhere right he's noted down somewhere and you know just in case if that tire doesn't fit the bike then he wants to go back to the original tire how it was right so that just in case you know if the tires are not fitting and you know you want to go back home saying that just make my bike how it was looking before and you know it doesn't seem to be good one what you're putting in my bike right now so he can go back right this is a bad plan I will come to it a little later now once you have requested for a change and discussed and decided and you approve for a change now is implementing the change he's implementing you know he's replacing a tire once he is completed doing that then he's gonna ask yourself and it will quickly take a test drive and come back to me and say if the style looks okay to you right so once you go ahead and you test drive and you find everything is fine and you love the tire and you know you love the comfort of the tire and you know it's fine and smooth you say yes it's perfectly fine thank you so much you close it you close the conversation you tell them thank you you pay him you come back right that's the closure remove the five steps that I just told you they pressed for a change change approval which you just gave him then he implemented write it change the tire fourth you validated in you tested and finally you closed the conversation you paid him money for the tire and you came back that's the pollution of the change simple simple right I mean this is how what does change this is a normal change right a standard change let's take the same example quickly same active a Honda ten years down the line you were supposed to you know replace the tire now the act of a Honda person is gonna come to your house he's gonna replace dying he doesn't need your approval because that required that that has been ordered to discuss and pre authorized by you and you know he just first it comes to your doorstep and that's how the service they're providing it he will replace the tie and he goes back home right and this is what he does door-to-door right I mean this is how a pre-authorize changes come in place right this is a standard change now we discuss about well plan change right now normal change now emergency change for example you're just going somewhere and you have a time right and that is something no you cannot call Honda and say that listen I need a new tire and you need to go ahead and you I want you to come here and fix my tire and you know I just want to go back to the place that I wanted to go back and you know um I I need I need approval no Honda person is not going to come and sit there sit there and say so let me take approval from somebody to come over there and all that he is all he's gonna tell you sir take it to the nearest mechanic he's gonna replace the tire or probably he's gonna fix your flat tire you can go back to the place where you want probably you can come back to us later on and they will fix it no in that situation an emergency change has been taken emergency change has been implemented which means he is going back to he is going to the mechanic shop and emerged on an emergency he is going to fix the tire he goes you know back back to his way right that's an emergency change a retrospective change is same just in case you know he is going to go back home and he's going to write a little email to the Honda saying that I did since this is a little perspective change right and imagine situation he might just have just call them and when he's going back home is writing an email to the Honda sir honda showroom saying that excuse me found a showroom saying that this is what happened and this is what I did right this is an introspective change so you understood the high level process of change all right now moving on to a very important aspect of the change during the change there is remember the butterfly effect or the butterfly diagram for incident management I made it this is something this is not something new and invent it invention in change management this is there are seven ours during this plant change 7 RS the letter R right R for Romeo now you need to remember the seminar if you are a change manager you need to ask this questions who raised the change first number one who raised the change second who is responsible for the stage who raised the change who is responsible for the change who is there what does the return or the output of the change number three right then how many resources do you need to implement this change right what is the risk involved in this change right then you will also the last rs2 you will check the relationship of the genie there are multiple changes you will ask the application or the requester for the change do you your multiple changes in the environment do you want do you would you would you mind explaining and this changes are related the relationship of the changes right one like I said the seminars let me just quickly rehash that for you I would it somewhere else but it's easier for you all to understand just give me one second yeah so like I said one is the reason for the change what sorry one is who who raise the change then the reason for the change then what is the return output of the change what does the risk involved for this change then for the resources that are needed for this change then who is responsible for implementing the change and what is the relationship of the change right hope you got it the seminars are very very important as a change manager you need to have these details with you only then you will be able to approve the final approval on the tool I'll come back to that right the final approval when I say there will be lots of approval that would happen during the change during a normal change critical changes you know even changes have been divided or you know they have two different types of chains one is proactive change one is a reactive change proactive change is probably something that you know beforehand that it's going to happen and make it an active attire you know after 10 years it has to be replaced and you know who you proactively do that so you end up you end up getting in that getting that done and plus you know it is a minimal cost right this is a protocol reactive change is something that that something is broken down and you need to react according to the situation right so again the changes the the other problem of the types of changes yes you have proactive changes and reactive changes in the types of changes you have standard normal emergency and retrospective right this understand the word proactive interactive right moving on - like I said seminars a change map change manager should know this 7 RS right if he goes for an interview this is one of your questions that what are the seven R's of change management right now high level will show you and mr. understood right request for a change change approval implementation of the change validation and testing in the closure right once this is complete then you will probably move on how to implement the change in the real-time work in the real world right let me let me take a quick example in alright hope you all can see my screen so I'm going to quickly show you this just playing I've just written this I was giving a training to one online the tables on changes so let me open let's take an example no no this is a detailed version of the change that I'm getting into right now let's say this is a major change right a major critical change right now what was the first are is who is the change right what is the reason of the change number two what does the risk involved interchange number three and then what is the return of the change what is the report of the change or the resources that will be needed the change right and who is responsible to implement the change right and is there any relationship of the other changes that are happening and then market right now let's move on to the first change the requester has raised the change and I'm gonna own that as let me take this quick example this request for a change request an opioid consumer scream request for a change is an application owner is a bursting for the chain and he's going to say I want to upgrade my application from n point o qu n point one this is the request for a change that is going to implemented for a change to right now once that is done he's requested upgrading the application XYZ from 10.0 ten point over ten point one he is going to he is going to prepare for a change right here if you see this is preparing for a change what is he going to do he is going to get he is going to get subject matter experts on the phone he is burning an application owners on the call and he is going to get vendors on the call and he is going to get other teams that are involved in the pot for example you have database teams or network team and all of that once the change request for a change comes in plain right it is all this is not happening by the application owner right or the requester this is happening by a change manager this is the first one is going to set up with the application owners and all of these people once once he has requested for a change this is called RFC once that is done he's going to prepare for a change who along with the change manager application owner the requester is going to get database team is gonna get Network team is going to get application and application vendor and he is going to get network team so on and so forth is gonna propel what will this teams do on the car or beforehand what would they do once they get on with the ball they will understand what does the reason for the change he's going to say my application has to be upgraded and then decided to complete this application this is a new release form an application from make sense they're going to do a technical assessment which means they would look up they're going to complete meant that the test version of the you know they're going to implement the new version in the test environment they're going to perform the estimate of the new release in the test environment and see how the application how application is working how stable it is right so they will perform technical assessment right and this is all been discussed on O'Connor right so which is already been done if that is done that's when the request for a change comes in play right it's been tested so they're going to listen you know all this owners on all these people on you know on the corner they will decide yes it worked fine we are okay with it technical assessment performing technical assessment is not now change manners is going to ask them what does the risk that is involved in it right so what's the risk that's involved in it what was the business impact of the financial impact for this change right he's gonna do that now the next thing the change manager is gonna do is talk to me he is gonna ask for a change documentation documenting the plan what are the steps that you need to do there are 10 steps give me those 10 steps I want to be it has to be documented in on the paper and the change document and steps performed by who and who which team which team is needed who's responsible for it once that is done now he is gonna look for the approvals the right approval or appropriate approvals from each of the team who is going to give approvals to do this one of course the the you know the application owner has requested protein database he must have give approval for it same storage team has to give approval anything that is required during that change has to be in the document plan for the approvals all their names all right their designations and everything will be in the part of the chain documentation right this is what I have written up on technical assessment number one rift that is involved in the impact risk and impact that is involved during this change and also there's something called risk acceptance say for example there is something a slight risk that is that that could occur right there is a slight risk to do so but that's okay that is also something that during this call a risk acceptance is stated right it is six step acceptance criteria is also proved during this one right so then you document the plan you identify which are the teams who has to approve it then you also check if it's a going to be of global impact or it's going to be a local or regional let's say a regional impact and the global impact if there's a global impact there's no change everything remains as images that you get the global DPS delivery project executives and project Global Peace Project executives and CEOs and city was just in case when you're implementing this critical changes then you will get get them on a cab or CA because I'll come I'll come to that right then you will validate the change when this call is happening you will validate the change who's validating change owner and the technical expertise are validating the change yes it will do so we have already tested in the environment in the test environments fine you're validating within the new submit the change right so all this is happening once the request for a change this is all happening on your pool and the pool change managers would have question to all of this once he gets the right amount of approvals he sees everything in the chain document then is where assists submit for a change right once if governments this changes now actually change management team is going to decide and not the time this mostly this is taking care of the first part of it is taken care by the requester by itself he is just going to keep a change manager in the loop during this first one he's been a pool throw everything by himself change managers gonna be maybe may not be a part of the swamp thang in time when this comes to change management team many submits for the change right change managers like I said they are mostly aware of such situations if it's a critical change now comes a change management thing this is a second level of check this is when change manager I'm a change manager now but this is what are we going to check the lead climber the downtime of the change when is happening again I'm going to recess my risk and the business impact right if I perform this change what is what is the outcome of the change what is the return of the chain what is the reason of the change right now once that is assessed what that is impact as assessed and it is kisses SS then I take a risk acceptance criteria which means if there is slight on risk also I want you all to be okay with it only if you say all okay there is all the formal groups approval groups if they say yes we are okay will it's a slight change it's it's completely fine I'm going to look into that as a change manager I am going to approve this change final approval is done by me only right as change manager we can do so and only if he approves it this change invented on wood maybe looking for something called a back-up plan right this is a backup time I want the bathroom to be very very very important I see if in case just in case if you know things don't go find within the change window that is given to me the leap and that's given to me I will go back to what it was right back on track proper documentation I am going to look into it again what has happened over here this is the second time the change man is going to write approvals who is responsible for implementing it what is the lead time do I have a back-up plan are there any conflict of changes for example there are two changes at the same time and that's me now a change manager is going to decide two things one he's going to see if the other change that's being implemented first thing I need to be where the relationship of the changes if this is the application XYZ that's happening and that is ABC first I let me isolate the problem or understand no this is something different and this is something different I will check the relationship of the changes now next thing most important thing I'm going to do is prioritize which incident which change sorry which change has to be implemented in first place right if that is the change that has to be implemented that has a business impact that's more critical in this then I'm going to take a downtime of this maybe next week or maybe after that changes implemented maybe I don't even have a change window for this particular CI to be given at this time because there's another change that's happening when the same CI which is on the same post or something like that right so I'm gonna prioritize based on the impact the impact and the risk that is involved on the changes so he's going to check for conflict of the changes when the downtime is given by the application owners he will also have the disturb that the change is happening on that weekend so he's going to say ok this is possible this is not possible right he's gonna say yes I'll have to prioritize that one maybe not this one if they say yes no even that's important the importance just make sure if they are on the same environment and now you realize that's not important this is important then you give a food once this change window is complete so prioritization is based on the other changes that sorry based on the impact statement sorry impact and the rest of is involved during the change right so that's important Lichter the changes risk acceptance appropriate approvals once that is done now I'm going to ask two important questions as a change manager I need to know this now I have all my internal teams that are performing the change I need to know to me do I need a vendor because this is application owner but the developer will be different I need an application developer who has given the new version of the application I need him on the college I am asked this question do I need vendors on the bar right not just application maybe database vendors I can ask this a generic question to all of them or them whosoever's say yes no but I will still insist them to have more people who are more experts in that arena right so once that is done I will ask another question during this change window I would like to have a bridge called open just in case if anything turns out to be an incident I will be prepared to have a major incident call and I'll have a major incident manager and management involved so this is what a change manager is going to do and if they say yes that's a good idea will mostly mostly for all high critical major outages there will be a bridge call that is open and change manager will insist to have for change bridge call that is that is open over there and it's a critical call a critical change move you know most of the time in the firm that I have worked for and I recommended as a best practice change manager should be part of that during the change even if it is not he is not there throughout the ball but he has to ring keep a regular check of you know on a sanity check every 15 minutes to 30 minutes or maybe everyone over to see if everything breaks down everything is working fine anything is breaking down right so this is what a change man once change the manager would do once all of these things are completed that is he checks for the leave time the documentation plan right approvals change conflicts you know then you have a back-up plan in battle plan do you need vendors bridge line has it been opened risk risk and business risk and impact has been assessed and everything is taken care right once this is completely taken care then he is going to open the cap on what is the cap call now once he is having the meeting with all other experts where service technical teams regional managers so on and so forth now once he decides this right once he's agreed to it the last one is going to ask is it will it be a global impact or a regional impact if they say of global impact during the cab call now he's gonna set up a crap call where all the DP is in peace and all the service delivery man in the same set of people will move you know high in designated higher designation people will join this call during the cab call with all the set of people then in this cab fall they are not going to discuss about all these things that are changing on this is already done anytime you change conflicts which is the one that's good now in the Capcom or on the cab cause they're going to focus only on the technical aspect of the change which means if the change has to be implemented then they're about maybe there are fifteen to twenty steps in the change documentation have this change have this didn't have the change that sorry the change that we are implementing hasn't been tested in the test environment and the UIGEA decide the environment do we have the right amount of people to the right amount of from people were responsible to perform the task within those fifteen to twenty action items so on and so forth they're going to worry about only the business impact they're going to worry about the risk that is involved during the change they're going to worry about the change time that's given to them within that change time the whole you know the change window the change has to be completed right they are worried about the change has to be successful during the validation they worried about the change failures and all of that right so they're going to be only worried about they're going to be worried about all of these things including the technical aspects of this the change in the change document right so the risk that is involved during this change what is the what is the outcome we are expecting or the change so once the DPS and B is they all agree to this right saying yes this change is important yes we need to go and do that if the P is a DP is everyone in Korea in the center for the people who all agree to in doing so then the change manager is going to give a final approval on the tool now this is when one is the change is approved on the pool this is when the changes being implemented otherwise the change is never the change is not gonna get into implemented this is why change managers are so critical regardless the PPE simpie ISM say that yes we need it unless he has everything the leave time in the documentation and the right approval all of that unless he gives the approval on the pool the change will not be implemented once he finds everything is okay that's when he's gonna give enough over then the changes improvements so this is the old way of implementing the changes across the environment reason being imagine not having change managers maybe at the same time there are tons of changes that are happening and are the same same CI you don't know who's communicating who's contacting and you know they randomly do things and they don't have write approval there for backup plans maybe they have everything they will miss out on some of the other thing that right so that is why a change manager is important to control those changes right document those changes and he's also going to say that okay he'll also be helpful during the you know I see is sometimes you know when the change failure happens I'll come to it when the chief in Philly happens you say okay this is something that is lacking the approval of the one of the team is not you're not getting approval reason maybe he's going to say that the the date of his owner was not available maybe he's left the forum so that is one of the feedback the chain he's gonna directly reject it because he's not got the prove he's not received an approval to implement the change however he's going to take that as a feedback that is the gap in the process for this change to implement the next week or maybe next time when you implement the change you will find the holes the next person available to approve the change and who's the right person in the forum for database table approval right so that's one of those important things why change man this is what this is why change managers play a vital role and I also said change management is nothing but a butterfly effect somewhere some changes happen can trigger some trigger an incident somewhere else right so then make sure there is no conflict of changes yeah so so well it's very simple it's taking care once the cab approval is given with them if it's a regional impact if the regional impact is yes let's say if the original part it's not a global foundation impact then you have regional managers technical teams you have say a stay of service delivery manager if it's a global impact is the same thing but instead of regional manager your global change manager you will have a global behavior of low VDP on the cap called change authorization board right so this came to authorization board is very important a change manager sense of this con with all these things given to him and even open a call with all the executives and they all understand the gifts say yes everything is fine they focus on me on the technical aspect they say fine then he is going to approve it on the tool once that's approval once that's approved then the responsible people in that change document who is supposed to do that during that change window the start window the start time of the change to the end time of the tha change and the implement time of the change and the validation time of the change that's not segregated implementation of the if there's a change windows for four hours the ours to our this won't change implementation one RS for change validation right something like that right so that the change is implemented now once the changes implemented remember the tire has been replaced by the mechanic now now it's the part of validation in testing now once the change has been implemented was the change successful which means has the change the change has been completed completed now can you validate it and say is it successful or not now quick test drive is taken then yes if they said no yes - no write down say maybe yes or no if they say no then that will be counted as a change failure you will open up problem ticket you will open a problem ticket and and you will do an RC on it right why was the change failure and immediately during the change window and in the you know the change was not successful they will have a back-up plan I mean they'll go back to the original version what it was before right TenPoint where was the original version they might as well go but during the change failure and you know so happens that the change is not successful it can also trigger and say that's why I change my this is keen on opening a bridge during the change window and he is going to open a bridge just in case the application doesn't work after the change window the downtime was for four hours now it's been four hours 15 minutes users we're aware that before the application won't be working or working but after for us now this is the time we can open the application still down it's a Pima because users are impacted now right now this was a change window that was given to us and it exceeded the change window it was a change overrun probably not maybe the change just succeeded but we're still unsuccessful in implementing the change so is the change failure as I say will be open for it and they will find out why the change was not successful and then back out and go back to the original version for example for on the other hand if the train was successful if the change was successful application owner is gonna say yes everything is fine everyone says everything is fine application is working absolutely fine the way it has to be it has to be right then they're going to document the change all that as a successful change record the change and closure that's all changes I mean that that's how the change management is once the successful change is done change is successful and is valid in find they will document it and they close it if the change is not successful then they will open a problem they can endure RCL that one now what are the types of change failures one is an ex Amex unsuccessful change which means the change was implemented it triggered an incident because it was unsuccessful for some reason validation did not give us a positive result right second thing was to change over run maybe we have got a window of four hours but they estimated to be for us but it exceeded four hours and we still implementing the change right it's another reason change over run is also a change failure improper documentation when they say the documentation was fine even the change manager was not keen enough to look into all the stuff because he is not a technical expert guy what was given to him is what Higgs took that as a Bible he said yes this is fine because all the technical experts said yes these are the steps that are needed later they realize no no we must we jumble up the steps of improper documentation is a change failure the other change failure I was just thinking about is there's no proper backup plan right so that's one of those things if the change that was implemented and the back-up plan was also not tested and now they want to go back and it's not going back to original version it's another change failure right these are the reasons of change failures the success rate of the changes should be very very high because changes are the backbone of four incidents right I not the backbone I would say changes 85% of the incidents major outages today or even let's say medium to high priority myriad medium to moderate to high priority incidents are caused because of the changes right so any sub like butterfly effect right any any changes somewhere leading to some some some incident somewhere else and that's what about a flight back that's why changes are very important change managers take care take care of the changing change my change messages have to be more more cautious about while approving the changes and all of that right change documentation is also opening the chin documentation also has to be planned very well right because if the change don't mean like I said if they're the steps that they say initially yes later they realize no that was incorrect subject matter expert says no what I thought that I was no that's that's a change failure you're causing an impact to the business because you're implementing the change you've given your gotta four hours of your downtime and you know in the meantime you know as well as there's also something now this is where a 50 launcher comes in plays right they've given you 15 to 20 items and you've missed out on the one and four hours have been completed but you want to implement another task or another step that has to be done during this change they will implement it as a retrospective change they will implement that they won't wait for again cab approval and change manager who will change my will give a verbal approval they will do it then they will document another has a change another chain is an emergency chain retrospective date right this is a simple way of understanding change management I made it so much easier for you to I hope I've made it easier for you know it was distinct management and I just wanted to take a little more time to explain about to incident problem and change interlocks like I said in do configuration management is one of the process in Ormond 26 processes is interconnected with all the 26 config management right configuration management how much insulin problem change is in interlock simple if there is a change failure there is an incident that occurs right this is how they are interlocked because of an unfocused unsuccessful change order change failure there is an incident that stripper right how does a problem problem house probably change in-house problem and change interlocked in case of any son successful change you open the problem ticket and why the change was feeling right now how is problem a little incident underlying cause of an incident is called a problem which means there's a good cost somewhere that's when there is an incident right so I usually ask this when I take interviews to people right so then the end up all getting confused but it's a very simple answer to give this I ask them what comes first problem or an incident right most of them selling they say yeah is incident first right so they say incident first then we open a problem to get to talk about cause of repetative incidents then we find out how we can avoid the repetitive incidents or how we can find out the boot route colorful incident that's later so incident comes frozen problem now I go back to the definition of an ins problem it says an underlying cause of an incident which means there is an underlying cost that's when anything comes back now then I asked them know what comes first then they say an underlying cause of an incident means there isn't cause first and then there is an incident because an underlying cause anything know that no it's a problem so they are mostly publics they are mostly confused so a simple answer to that is usually if you look at and in a logical way problem comes first which means there is an underlying cause somewhere a cause somewhere that is hidden and if that's causing an incident that's why you need to do a root cause analysis to find out what's happening so problem somewhere triggers that's when an incident comes in playing right so how this is how they're related but yes when we are going through a process in any company in any organization where we are running an incident management if you're talking in terms of ticketing pool incident comes first problem comes later then you do a problematic because incident has to be resolved with the earliest you cannot do a root cause you need to give a big fix you need to give a workaround you need to give give some you know redundant plans something you know that can happen to resolve this issue or mitigate the impact and get back to the business quickly then do overpass but somewhere there is a root cause the problem comes first incident comes later during with in in terms of ticketing to incident comes first because we have for example then we open up opportunity problem problem record to do this same way and change how instant prom change is created so rather and we also some change failures incident can be triggered because of the change failures are prompted attend the problem can be positive it can be created which means they're interlocked right or in this I just took some time to explain it to you and I thought this is the simplest way that I can arm explain it to you all what is change management I will soon do a video on problem management that will be even more interesting hopefully and now you will understand motors change management you have already under students in management once I do a problem management then you will probably understand what is incident problem in change it's called IBC in service management right so people when they ask there's another things it's a funny stuff people ask what are you doing incident management you know what do you do an organized incident management or when you say service management they don't understand I mean when you say incident management they don't understand when it says service management they still don't understand you need to explain it to them there is a life cycle for anything that you do and you know you have multiple processes in it so when somebody asks what is incident man I want you to say you're part of service management team service operation team right ok guys you all have a great day thank you so much for watching my video and keep commenting and I would love to see your comments and if there's something that I need to do better please let me know as well I will do that alright thank you guys you all have a lovely day ahead and I'll talk to you soon thanks so much

Channel: Syed Ishtiyaq Ahmed

Views: 14,518

Rating: 4.9359999 out of 5

Keywords:

Id: 1cYAKdlPQJc

Length: 50min 7sec (3007 seconds)

Published: Fri Jan 10 2020