Service Desk, IT Asset, and Service Configuration

Its role? Well, it's there to provide that clear path for our users to report issues, queries, requests, have them acknowledged, classified, owned, and actioned. And they're some of the things that are particularly important in organizations and to users, that actually if we raise a query that the support organization says, hey, yeah, we've got that that it's classified so that it's actually we talked about in incident management before triage making sure that if it's an incident, it goes down that route.

 

If it's a change control, it goes down that route. If it's a service request, it goes down that route. And that actually is it's sometimes quite a complex activity.

 

Somebody just rings up and says, I can't print, it could be any number of different reasons for that. I think for the users to feel that somebody is owning their call, their query is taking ownership, that promotes customer satisfaction and user satisfaction and, of course, that you fix it. you can all of the ownership, and acknowledgment, and classification in the world you don't fix anything, then the customers are not going to be satisfied and the users are not going to be satisfied.

 

So part of its job is to capture demand for incident resolution and for service requests. So it's there and we'll look at the different methods that it can use. The service desk has progressed way beyond just taking telephone calls. Providing that single point of contact for IT or the service organization, there's a lot of activity now in DevOps Agile product environment, where we're broken down into lots of different teams.

 

One particular organization I know, 112 product teams in their organization. And they thought about, well, do we really need a service desk now? Because if they build it, they support it the product teams before somebody point it out. So if that fails, which of these 112 teams do I actually call? Yeah, you've got a good point there. So long may the service desk survive from that perspective. Their job making sure that we can making sure that we can get the calls to the right people quickly is a major part of their role if, of course, they can't resolve it themselves. So that single point of contact, that one easy number to remember everybody remembers the service desk number 1234, or double 5, double 2 make it something nice and easy to remember.

 

Went to one organization some years ago and they said to me is your service desk number easy to remember? Said, yeah, what is it? 5267. I said, so how's that easy to remember? Well, I've been here seven years. Well, of course, is easy to remember if you've been here seven years.

 

So, yeah but make it nice and easy to remember single point of contact. Focusing on supporting people and the business rather than just technology issues.

 

Service desks are capable of so much more than just fixing technology issues.

 

Yes, OK, it's going to be a primary focus, but it's not everything. So we want your service desk there to serve as an empathetic and informed link between your service provider and your user base.

 

Well, as you can see here there are a number of different ways. The first method of contacting the service desk almost isn't contacting the service desk so self-service. And it depends on your organization, but having the self-service there with typical resolutions, that can make a difference and some people are happy to use self-service. Phone calls the traditional ring the service desk.

 

Hello, service desk, my name's Barry. How can we help you? Service portals and mobile applications so again, dropdown menus, making sure you're getting consistent information so that people can report incidents quite quickly. Chat live chat that you can use now, or chat-bots. One organization I was interacting with recently an airline and when started with the chat bot, asked the chat-bot a question that it didn't understand, and that passed me through to a kind of live agent at the service desk. So you can record calls in that way.

 

Email can be used for logging or updating. So logging the call via email. problem with email, unless using templates and forms, is it's very freeform and you can't necessarily go back and ask questions in an email. I can't print, in an email there's 100 questions you want to ask after that, which you can't necessarily do. But also it's a good medium for updating people as well about the progress of their call.

 

The walk-up service desk is very similar to the kind of Genius Bar type concept that they have at Apple. You can walk up to the service desk and just ask questions. Some organizations like it, some organizations don't. Some allow it, some don't. Some even have you actually book an appointment to go and visit the service desk with your issue if it's a non-urgent one.

 

Text and social media messaging, so you can use social media to contact your service desk. And even wider than there, public or corporate social media and discussion forums. You can quite often be alerted to an incident by your external customers rather than necessarily your own internal people.

 

Now, if you look at that, it starts to give you an idea of some of the complexity of the job of the service desk practice. Because they may use some or all of those different methods. Now, even though all of those methods are in best practice, and might well be asked about in an exam, don't, whatever you do, think I've got to use all of these at your service desk.

 

Who do you ask what they want to use? You. go to your user, you go to your customer. Just because your service desk tool provides chat-bots doesn't necessarily mean that your customer base are going to take to them.

 

So you always need to be careful about which of these different methods of contact for your service desk you actually use. Through relationship management, constantly poll your users and your customers through the service desk, through service level management. Ask them what they want, how they want to contact their service desk.

 

I might have an organization that's got HQ building. I might have an organization that's maybe got a warehouse building and lots of different retail locations around a particular country. One service desk that services them all, is a centralized service desk. So HQ, warehouse, all the retail locations, all ring in to the same service desk. And then that service desk then has got access to all of the different IT teams that they perhaps need to help them to resolve incidents and other issues. Maybe even to third parties as well. So centralized service desk. The benefit of that type of service desk, is it keeps costs down.

 

One of the big downsides, I think, sometimes of a centralized service desk, is that various locations can sometimes feel the service desk isn't their friend. I worked in an organization where the service desk was actually based in the HQ. We knew in the HQ, in the retail organization, that our warehouses were by far and away the most important services. And the service desk knew that, and all the IT teams knew that. Part of the problem was though, that the people in the warehouses didn't think that the service desk was their friend. Oh, the service desk. It's at HQ. It's only there for HQ. And what we had to do eventually, was put service desk people actually into the warehouse to record calls, so that they felt that the service desk was a little bit more friendly towards them.

 

But that's a centralized service desk, where you've got one for the whole organization. The other one we've got, is this idea of a virtual service desk. Now, what can happen here is that all of my users are spread let's say my users are in the United States, and they're spread all over the United States. I've got actually three service desks. I might have one in Chicago. I might have a service desk in New York, and I might have a service desk in San Diego. I've got three service desks. They're in different time zones. And when somebody rings up my organization, they actually get through to one of the service desks. But it's based on things like how heavy the load is each service desk, and then maybe in three different locations. The key is that those service desks are all using the same systems. So from a user's perspective, they just think they're ringing one service desk.

 

The worst thing in the world would be if you ring up with an incident, you get through to the New York desk, they answer your issue. And then you ring back for an update a little bit later, and you just ringing one number. You get through to the Chicago desk, and then who are you? We don't know about your incident. So all three of those locations have got access to the same systems. There's another kind of a view of that as well, that could actually end up being global, and that New York is somewhere in the Far East well, it's in the Far East of the US, but it's in the Far East of globally. You might then have a service desk in Europe. And you've got a service desk perhaps there in Central America. What happens with those is quite often you end up with follow the sun. But again, if you're a user and you ring up and you get through to your European desk. Then a little bit later, hours later, you ring up you're going to get through to your Central America desk. They still need to know about you. So they're both examples of virtual service desks. One of the good things about that is, is if the service desk in Europe for some reason gets taken out, then you got two other places around the globe that can take over. So big natural disasters and so on, you can cater for. So that's the idea of a virtual service desk.

 

To the user, it looks like one, but in reality you're in different locations. So they're the two types of desk. What we do now, is take a quick look at some of the training that these people on the service desk actually need. And there's a whole host of training. It's very, very varied. They're perhaps some of the people in your organization that need training the most. So there'll be lots of people now in service desks looking at this saying yes, I've told them that for years. And now Barry said it. So for those people running training departments, (WHISPERS) I'm sorry. So some of the skills they're going to need empathy is for certain a skill. Not sympathy, nobody's died. It's empathy that they need to be able to understand their users when they ring up.

 

What it means for that service not to be working to that user. Incident analysis and problem solving skills are important. Sometimes that can be done through scripting and certain problem solving skills. They're very, very important. They need training about how to prioritize different incidents. It's not the person who shouts the loudest or whatever else it happens to be. They need training in areas like the tool sets and the technology that they're going to use. They need communication training. One of the most important skills for a service desk I always believe is active listening. Whether somebody calls through to the service desk, they're a little bit upset that their service has failed and nobody's updated it. One of the key skills at the service desk is being able to pick five words out of 500.

 

Microsoft Email That's a key skill for a service desk, the idea of active listening. Lots of technical skills that these guys can pick up as well. Be it Microsoft or AWS or whatever else it happens to be. And knowledge of the business. It's amazing the skill set that you need to have a really, really good and effective service desk.

 

Again, what we're going to see is the darker the color, the more the involvement. Obviously, engage the service desk is that primary channel for operational and tactical engagement with the users, that's two-way with the users and the demand for incidents and service requests, and also the communication channel going the other way with updates and managing expectations and so on. Deliver and support service desk is the coordination point for managing incidents and service requests so definite involvement with those two all the practices is part of deliver and support.

 

Improve service desk activities, they're constantly monitored and evaluated to support continual improvement, alignment, and value creation feedback from users collected by the service desk supporting continual improvement initiatives. Indeed, it's that important that there's the Service Desk Institute in the UK. They actually talk about the service desk being the eyes and the ears of the CEO in the organization to find out what's actually going on with live services.

 

Service desk activity and design and transition service desk provides a channel for communication users about viewing change services. And service desk staff should be able to participate in release, planning, testing, and early life support as part of release management. Now interesting that we talked about that before in incident management and the organization I work with that had the service desk and incident management people sat in another room taking calls when they were doing a pilot and testing activity so that they were making sure service desk could support.

 

And I know many service desks now and indeed, a service desk best practice that a service desk can halt a release of a service if it doesn't feel that it's ready to support it, and it's got all its deliverables in place.

 

Final one in there is obtain and build service desk can be involved in acquiring service components, and that's when they're doing their work on insert of service requests and resolving incidents. so If they need to go out and get whether it be new laptops or something like that to actually resolve an incident, then they can do that, so they can be involved in obtain and build. But it's engage and deliver and support the other two primary areas that service desk is going to be involved.

 

And now we're going to look at service request management. Its goal is to support the agreed quality of a service by handling all predefined, user initiated service requests in an effective and user friendly manner. So obvious question what's a service request? And here's the ITIL definition. A request from a user or a user's authorized representative that initiates a service action that's been agreed as a normal part of service delivery. So making sure they are all pre agreed.

 

Now here are some examples. Now there's been a big, big debate over the years in ITIL, what constitutes an incident, what constitutes a service request. To be honest, ITIL doesn't care. It's your organization. ITIL is all about adopt and adapt. You decide what constitutes an incident. You decide what constitutes a service request. The classic example is the password reset.

 

To be honest, as a user I'm not bothered how you classify it as long as it's classified and you sort it out, and you give me access to my log in and details again. So examples of some of these replacing an ink cartridge might be a service request. A request for information, providing a phone, a laptop to a user, a request for access to a service it might be MS Project, something like that or any feedback that users have got compliments or complaints. They could all very well be, in any organization, service requests.

 

Some of the rules around service request management then first one is to standardize automate as much as possible. Worked with an organization recently who had some 37 different areas that could be requested through a request catalog. It's almost like Amazon for IT and Amazon for IT services where people can go on their standardized request that can be automated, and people can access things very, very quickly. The key to service requests and service request management is giving people, where at all possible, the quickest access we can to standardize services, establishing policies regarding what's approval or authorization is required.

 

It might be done based on somebody's rank or where they sit within the organization. There's somebody that works within perhaps in the finance department gets access to the finance prints. And if you don't work in the finance department, you don't get access. So policies as regards regarding approval and authorization for those requests is set out, and that policy should be very, very clearly stated to the users as well. So you're setting user expectations about the time. You might be setting user expectations in some organizations about the cost of a particular service request, the quality, what they can expect, when they can expect it, how it's going to be delivered, what they've got to do so setting user expectations very, very clearly.

 

Identifying and implementing opportunities for improvement the important part of service request management is making sure that when you fulfill service requests, you ask the question of the user, does this work for you? So you make sure that you can make your service request processes and your individual service requests as slick as possible because central to that is going to be user satisfaction, customer satisfaction with the processes that you're using.

 

So identifying and implementing opportunities to improve, maybe further automation very important part of service request management. Defining the difference between requests and incidents I guess if it's non standard, then it's probably going to be an incident. If it's non standard, it's probably maybe going to be a change control. If it's standard, it's more likely to be a service request. And that brings us back to that classic one there. I don't really care what you call them, neither does ITIL, but make sure you define the difference.

 

And that classic one the password reset if people can reset their password online through a portal, I would call that a service request. So again, it's up to you. It's your organization. And they may require each of these different service requests slightly different workflow models.

 

It's best if they can all use the same user interface to actually access. But what you might do without user interface, you may well have a list of 30 or 40 or even more in your organizations of goods and services, that products and services that can be ordered through service request management. What you might do, though, is based on where somebody works, based on their role within the organization.

 

You gray out half of them because they're not they can't access them. But you might require different workflow models. But what you don't want is necessarily to have 40 different 40 different workflow models for 40 different types of service request. Wherever possible, reuse the workflows to make it as easy as possible, not only for the users to get access to products and services but also for you, as the service provider, to actually provide those products and services.

 

Now before we start to talk specifically about IT asset management, let me tell you it's got a very, very close cousin, service configuration management, which we're going to talk about in the subsequent practice to this one. So please let's stay aware of the fact that there are two that do very, very similar job in the organization, but they've got a different focus service configuration management issue we're going to come on to, supports, service management processes specifically, and supports the management of services where as IT asset management is primarily concerned about money and IT assets have got a financial value. So IT asset management well established in organizations now where we've got iTime, IT asset management, and Samsung software asset management that have been around for a number of years now.

 

IT asset management from an ITIL perspective, it's role to plan and manage the full lifecycle of all IT assets, which means that we've got to do a definition, the definition of an IT asset, any valuable component that can contribute to the delivery of an IT product or service. And by valuable we mean a financial value.

 

IT asset management underpins everything a provider does. wonder how many organizations out there could genuinely hand on heart say that they knew from an IT asset perspective hardware, software, networks they knew what they've got. They know where it is. They know what state it's in. lot of the organizations I've visited, I think that's extremely unlikely. Requires an accurate inventory, therefore, an audit to make sure that on a constant basis you know what you've got, you know where it is, you know what state it's in. That's going to help you. How's it going to help you? Optimizing the use of resources.

 

So for example, if you know the you've got resources in a store, for example, then you can make sure that you don't go out and buy some more. It can support decision making about purchases and reuse, and retirement of assets. So you have retiring assets? Oh, I know that asset is out of warranty now. We're going to need to replace some of our assets. We can replace 50 percent this year. We've got 50 percent that are out warranty this year.

 

Therefore, they'd be the best ones to replace, because otherwise we're going to have to pay more to keep the maintenance up to standard. Meeting regulatory and contractual requirements. Sometimes IT asset management, you've got hold a certain number of spares in reserve. There are rules and regulation around software. Maximizing value, controlling costs, managing risks, they're all benefits of knowing what you've got, knowing where it is, knowing what state it's in, from an IT asset perspective.

 

So hardware assets, in particular, have got to be labeled for clear identification. Some of them might need special handling when they're being decommissioned or they're being reused. so that might be things like shredding of disk drives, depending on information security requirements.

 

And they might be subject to regulation. For example, the European Union has got waste electrical and electronic equipment directives to make sure we don't fall foul of any regulation. Protecting software is also important, to make sure that it can't be illegally copied and we could fall into, again, regulatory issues or just simply issues with the number of copies of software we've got out there, with the providers of that software, when we're not paying for the number of licenses that we're actually using.

 

It's also important that IT asset management assigns client base assets to individuals so they can take care responsibility for the care of those particular assets. And obviously, IT asset management, we talked about it managing the full lifecycle of assets. So that includes the provision of assets, receiving them, decommission, return, disposal, software reuse, leasing management. So a whole host of things that IT asset management can get involved in.

 

Service configuration management going to collect and manage a wide variety of information about CIs. Now CIs, Configuration Items, are typically things like hardware, software, networks, buildings, peoples, suppliers, even the services are treated as CIs, and configuration management is going to help us to understand how those CIs work together to contribute to each service within our organization.

 

So the formal goal is to ensure the accurate and reliable information about configuration of services and CIs that support them is available when and where it's needed, so the right information in the right place at the right time. And this includes information on how the CIs are configured and the relationships between them. Couple of definitions for you then a Configuration Item, a CI as we commonly say. Any component that needs to be managed in order to deliver an IT service is a CI.

 

And an attribute, a piece of information about a configuration item. So for a laptop, say, if that's a configuration item, then it might be the name, the location, the version number of it. The cost whatever it happens to be would be the attribute, the information that we keep about each of the configuration items.

 

So service configuration management's principle value is how affects and enables many other practices. It doesn't necessarily have a tremendous amount of value on its own. You can imagine going to your financial director or your CFO in your organization and saying, look, we need thousands of pounds, thousands of dollars, thousands of euros to be able to implement configuration management. So why do you need that? Well, it's going to make sure that the IT people and the service providers know all about all of our services. So you don't know that already? Yeah, that's good. It's going to be difficult. So its primary goal, is to enable many other practices. So, for example, you can do incident management without configuration management, but it's much better with it. You can do change control without service configuration management, but it's much better with it.

 

You can do problem management without you get the picture. It's certainly a big enabler of those other service management practices. Now, in terms of the information that you keep within configuration management, it's always going to be a balance between the value of the information and the cost of obtaining the information. So if you think about how much information you want to have, then it's going to be absolutely based on the needs of the business and the needs of the stakeholders.

 

Let me give you an example. If you think about although it doesn't fly anymore, you think about something like the space shuttle and you think about configuration management on the space shuttle, you're going to want to know down to the individual nuts and bolts individually how they pieced together to form the service that is the space shuttle. And the value of having that information is massive. And God rest their souls that they lost one going out and one coming in, a space shuttle. And the absolutely invaluable information that you needed to make sure that things like that don't happen again.

 

So you've got to balance that value understanding the needs of the stakeholders. Now how do we access all of this information in configuration management? Well, typically, that's done using what's called the CMS, the Configuration Management System, which is a set of tools and data and information that's used to support service configuration management. And that configuration management system will access underneath it one or more configuration management databases.

 

What you might have in an organization is a single configuration management system, the tools, and so on. And then underneath a database where the data, a CMDB, Configuration Management Database, where the data is actually held.

 

Now, typically, what you'll get in some organizations is the idea of a federated configuration management database where actually the data might be held in different places, but it can all be brought together in a single CMS. So I work with one organization that 12 different locations around the world. Each location had its own CMDB because, typically, the services that run from that location were in a position where, most of the time, they only needed the information in that location.

 

But every so often, they needed to pull information in from all 12 locations. So making sure that they had common naming standards and so on in the databases meant that they could actually analyze the data from all of the databases in that single configuration management system.

 

Automation plays a big part in service configuration management and tools that can sniff around the network, and so on are very, very valuable in keeping up to date information about infrastructure, about software, about documentation so that it can just happen automatically and keep the information in the CMDB, in the CMS up to date. Large organizations will often have dedicated teams working in configuration management, but that's usually very large organizations. What tends to happen in smaller organizations is that they use teams to keep their own configuration management information up to date, keep their own CIs up to date but make sure that they conform to the rules. That means that this information can be brought together for analysis and to provide surprise excellent knowledge through to the different service management practices that use it. So what we will find as well, in many organizations, is the configuration management will tend to end up pertinent service configuration management sorry will tend to end up being planned alongside asset management, change control, release management, and so on because they really are joined at the hip.

 

Processes are going to be needed within configuration management to ensure that you identify any new configuration items and add them to your configuration management system. So that might be drawn automatically. Some organizations, when they get new pieces of infrastructure delivered, it might be laptops and so on, alongside it will come a file. The file has got all of the configuration information in it that can be uploaded directly into a configuration management system. Obviously, updating configuration data when changes are deployed so looking at the status of individual configuration items, looking at the relationships, making sure that they're updated. Quite often, again, that can be done automatically. Key thing about being things being done automatically, though still, they've got to be under control. So if you're going to allow automatic updates of your database and your CMS, then for certain, you're going to want to know what's doing that if I'm the configuration service

 

Configuration Manager and an organization then if something's updating my database automatically, I want to know about it for certain. What else? To verify the configuration records are correct. I'm probably going to be measured as a service configuration manager on the accuracy of my configuration information in my CMS. It's going to end up being a vicious cycle. If the information is inaccurate, people won't update the CMS, so the CMS will be less accurate. So they'll update it even less. And before you know it, CMS ends up costing you lots of money, and you get absolutely no benefit from it so verifying the configuration records are correct.

 

Quite often, if somebody logs on through a laptop or a PC, an organization, then it can verify that those people have got the correct laptop, and it will do a verification on log on to make sure and update, if necessary, information in the CMS. And also to all the things, like your applications, your infrastructure to identify things that are not documented. Now it's particularly important the configuration service configuration management when you go into Cloud and virtual environments where we can build and we can trash environments almost well and very, very quickly. And so configuration management there needs to happen automatically and actually needs to be built and designed into whatever you're doing with your applications.

 

So what we can see are a whole host of in the boxes CIs, the IT service, the client app, the client device, the user, the data center, local storage, local servers, local applications, Cloud infrastructure, a supplier, software as a service component. They can all be CIs and individual configuration items. The gray lines indicate the relationships between them. So if a user rings up and says, I can't work. I'm unable to work. a chain of events that could go out. What service you using? Oh, I'm using X, Y, Z service. Then I can look the client app, the client device, the local server, the local storage. I can look at that. I can look at the impact.

 

I can also look at maybe other people who are connected to that service. So the model is really, really useful to help me to diagnose, perhaps, where it is I need to look to resolve my incident. Equally, if we make changes to a contract with a supplier on the other side, then actually that supplier supplies that Cloud infrastructure. That Cloud infrastructure's got that software component running on it. That software component is actually linked to the IT service. The IT service is used by yep, down the other side that user. So when we're making changes, it can help us to look at what's being used.

 

Now this makes an incredible difference in organizations if you've got this type of information. Quite often in organizations we end up relying on people's of tacit knowledge that they've got to make sure that they perhaps, know about how the services hang together. Every organization has got old Joe working for them. He's been there 35 years, man and boy, knows everything about everything in IT. He's the guy that the IT director goes to when something's going wrong.

 

Oh, we've got a big problem, go and ask Joe. Joe will know. Two weeks of every year, Joe goes off on his holidays. And he's really into hiking, goes to the foothills of the Himalayas, and he's uncontactable for two weeks. And at that point, what happens is the IT director, the CIO, kneels and prays to his personal god that nothing is going to go wrong in those two weeks because all of his IT configuration information is up in the hail foothills of the Himalayas having tea with the Dalai Lama. So it's very, very important that we keep this configuration information, keep it updated, keep it accurate.

 

Now, the first thing I've got to do is, even though it's not covered in the ITIL 4 Foundation syllabus, I've got to make the distinction between change control, which is changes to services, and organizational change management. Organizational change management, which is in the general management practices, that's the one that manages the people aspects of change, to make sure that, when we're making improvements and we're doing organizational transformations, that they're successful. Where what we're looking at here, now, change control, this is usually focused on changes in products and services. So change control what is it going to do?

 

Well, it's there to maximize the number of successful IT changes by ensuring the risks are being properly assessed, authorizing changes to proceed, and managing a schedule of change. One of the things that we've looked at previously, once I've mentioned a topic, be a problem or an incident or, in this case, a change, it's definition time. And a change is the addition, modification, or removal of anything that could have a direct or indirect effect on services. Now, typically that ends up being configuration items and CIs that a lot of changes are made to, particularly when things like services CIs, software CIs, infrastructure CIs, and so on.

 

Change control's got an important job, though. It's got to balance the need to make beneficial changes that will deliver additional value with the need to protect customers and users from any adverse effect and impact of changes. So it's absolutely vital, as part of what change control does, is that it is properly assessed by the right people, it is authorized by the right people, and it makes sense that the correct change authority is assigned for each type of change.

 

So, who actually says, yes, we're going to do that? It might be a group of people. It might be an individual. It might be preapproved. And what we're going to do is look at the different types of changes, coming up in the next slide.

 

And ITIL defines three types of change. The first one the standard change. Now standard changes is a massively important if you're moving into automation a particularly if you're moving into DevOps type environments where you're going all the way from code being cut right the way through to actual delivery into the live environment automatically. So the standard change is happening the addition, the removal of the modification, of anything, hardware, software, using scripts, and coding, and so on right the way through. So standard changes, what are they? Low risk, pre authorized, well understood, and fully documented. Now quite a lot of those changes come through as service requests. But some of them don't. So standard change important. As we say, they're low risk. We've looked at the risk. We've done it a number of times. We understand it.

 

We've got a set procedure for doing it. It's been pre authorized. It's fully documented. Now it makes absolute sense, that then what does that do? Well, it makes sense that what we've done is immediately we have reduced the amounts of administration involved in change management. A lot of people come across change control and suddenly believe that change control is something that's in there to get in the way. No. It is there to control. And the standard change the more that you can convert in your organization to standard changes, the better it is, particularly if you want to automate. We've then got what we call the normal change. Now where as with the standard change it's low risk, it's pre-authorized, it's understood, it's fully documented, we can just go away and do that the normal changes, they need to be scheduled. They need to be individually assessed.

 

They need to be individually authorized. And that normally be through a standard process. So a normal change, little bit higher risk. You don't quite understand the risk, then you don't really want to be creating a standard change. It's quite possible for normal changes, over a period of time, to migrate and become standard changes. If standard changes start to fail, it makes sense to make them back into normal changes. Just because something arrives in one of those categories doesn't mean that it's going to stay there forever. What I see too often in organizations is something that's a standard change. It fails once, and so all of a sudden somebody decides to make that then a normal change as a big knee jerk reaction. And they never make any effort to turn it back into a standard change. The more that you can turn into standard changes, the easier that it becomes for different teams to be able to manage their own changes. So certainly, I think if you're looking at rewarding people, reward them turning things into standard changes for the addition, modification, or removal of components. The third one there is the emergency change. Now the emergency change must be implemented as soon as possible. And it's normally more often than not a fix on a fail.

 

So it's to resolve a major incident or to implement a security patch. The emergency change isn't designed for the situation where you get to Friday afternoon and think oh, that change we wanted to make this weekend I forgot to put it in. Right. So let's put an emergency change in. I forgot isn't the reason for an emergency change. Now I know an organization where people who actually try to put changes through like that, they go into a black list category. And they've actually got to go and explain to the CIO why they need an emergency change. That happens to be a pretty powerful incentive to stop people putting in emergency changes when, hey, they just forgot.

 

So standard, normal, and emergency changes three definitions there I would be wary. Because they're almost certainly, one or the other, going to turn up in the examination at some point. Final thing we've got at the bottom is a change schedule, used to help plan changes, assist in communication, avoid conflicts, assign resources. Now you can have, if you want, two versions of this. This is very, very useful, obviously, to know who's doing what to who and where and when in terms of changes that are going on in your organization particularly you've got normal and emergency changes going on. The last thing the service desk needs call comes in and somebody says such and such isn't working. Let's have a look. Oh.

 

There was a change we didn't know about. The people at the other end of the phone the users they don't distinguish between different parts of the organization. And they sit at the other end of the phone thinking they don't know what they're doing. So there we go with why emergency sorry why the change schedule is so important. But also not only so we know who's doing what to who internally in the service provider, but we can also communicate. It might be that all we need to communicate to the user is service is going to be down between 4:00 PM and 6:00 PM for essential maintenance.

 

They don't need to know what you're doing or we're upgrading the firewall or we're doing that. Yeah. OK. That can be in the long change schedule you've got so you know what you're doing internally as the service provider. But you've got that kind of external view of the change schedule, as well, which makes sure that the users, the customers, are communicating to about any potential service breaks that they're going to encounter.

 

Again, the darker the color, the more involvement. If I'm really honest, I could have probably, from a change control perspective, colored every one of these dark in the change control. And making sure you've got the right governance in place for change is absolutely central to an organization and what it does. if you look all of the practices in ITIL, particularly in service management and the service management practices, change control and incident management are the first two that you're going to put in place in any organization almost. So how does it contribute to the value chain activities? Let's start there at the top with plan changes to products and service portfolios, policies, practices. They're all going to require a level of control. So all of your planning that you're going to be doing, there's going to be a level of control in there. How you exercise that control, whether it's through project management or whether it's through change control, absolutely down to you as an individual organization where you draw the line between what comes under change control's jurisdiction and what comes under let's say project management's jurisdiction.

 

So long as everything's covered, doesn't really matter which side of the line it falls. Improve, many improvements are going to require changes to be made, which should all be assessed and authorized in the same way as all the changes. If you think about where changes are coming from, quite a lot of changes come from fix on fails, so as a result of incidents or problems. But also, changes come from things like scheduled maintenance.

 

Changes come from areas such as project management. And that's where improve, for certain, is going to need to get involved in new functionality coming into services and so on. Change control, absolutely central. And change control, if you're thinking about your organization, looking at things like DevOps, looking at Agile, then change control still massively important in those areas, particularly the standard changes that we discussed earlier.

 

Engage, customers and users may need to be consulted or informed about changes. You've got that schedule of change. Then that might need to be communicated to users and customers. Or indeed, consulting them about when to make a change, whether there's a risk in making the change, making sure that there is engagement there.

 

Design and transition. Many changes are initiated as a result of new change services. So there's a link there. Change control getting very, very heavily involved, particularly once you get into the transition phase. Obtain and build. Changes to components subject to change control, whether they're built in house or they're obtained from suppliers.

 

Even if you build in cloud environments and you build it in virtual environments, still change control in place. And the bottom one, deliver and support. Change control again being involved. Changes have an impact on delivery and support, and information about changes, it's got to be communicated to personnel who carry out this deliver and support value chain activity.

 

So again, when we're looking at support in any organization, any changes are being made, please, please, please, make sure support is delivered and support is informed. Think about, for example, the service desk, who are very, very central to delivering support. What's the old joke? When does the service desk find out about changes that are being made to the infrastructure? When the first call is received at the service desk and not before. Please, let's not fall into that trap.