The service request practice is a practice that takes place at the service desk. It is one of those areas that's specifically designed for users to call the service desk and ask questions. Ask questions about functionality, ask for some pre approved requests or maybe make a compliment and or a complaint. So, what is the definition of a service request? They are requests from users that are initiated at the service desk and as part of normal service delivery, but these requests have been preapproved. And actually, the change authorities have looked at and said that they're pretty low level, low risk calls, and the service desk can actually respond to these types of calls without escalating them up to other teams. So, what is the difference between a service request and a change request? Well, for test purposes, when a user calls a service desk, and they need something modified to a service that affects the entire service for the masses, and that's a service component that's already live in the environment, and they want a modification to it, that request needs approval. So, unlike a service request, a service request has been previously agreed to and approved, and the folks at the service desk can respond, but a change request needs to be looked at by another body of authorization and it needs to be justified. And that is the difference between modification of the service that will affect everybody and a request that will affect one individual user. All service requests are logged at the service desk, and again they are pre approved low level, low risk type of calls that can even be compliments and or complaints. The requests have been pre approved, they have been already looked at and that's why we refer to them as standard. These standard requests and or standard changes because I don't use that term interchangeably in this particular area. They've been labeled as a ticket that the folks at the service desk can follow through and resolve on their own. They do not need to send this up to another authority to be approved. They've already been preapproved. Again, they are not incidents, they're not problems, they're not failures, they're not outages. They're basically like questions where they're asking for some form of information, maybe in the form of walk me through or functionality related. We have defined steps on how we follow through with service request tickets, and we jot those down and record those and we use those for training purposes. If we see a service request call that has been repeated over and over again at the service desk, sometimes a service desk technicians will log those requests as FAQ or frequently asked questions because they see them so often. And they can turn those into standardized self help experiences and use some type of automated tool like password reset tool. So, that is considered a service request because it's preapproved, it's low risk, it is prestandard, and users can help themselves. So, that's why it's necessary to log these requests in addition to other tickets like problems, incidents, and change tickets. For the ITIL four foundation certification exam, you will only be tested on one technical management practice and that is deployment management. But there are others and the other practices will be talked about when you take the intermediate courses. But for our purposes in the foundation exam, we will only cover deployment. It's under the technical management umbrella because this is where we touch the live production environment. We may be adding to the environment and proving and or removing some components or devices that affect the entire enterprise. So, there is a difference between deployment management and release management. Release management was about making components available, but deployment management is about making those components live and ready for use. So, making them available would mean pushing them to some network server and they're sitting out there ready to be pulled down or push to the desktop. With deployment management, not only are they available, but now they are being used. So, they're becoming alive. So, the key word here for the exam is moving components into the live environment. So, please know the difference between deployment and release. Release was making components available, deployment is the activity of moving components to the live environment or a test environment, and making those useful for folks to actually take advantage of. There are a variety of deployment approaches that can be used, where you can push all of the components out to desktops all at the same time to everyone, that's considered big bang, or you can phase the deployment out to certain groups at a time. Maybe the first floor in the building or the East Coast part of the country, and there's continuous delivery, where these activities take place behind the scenes, you don't even know about it, it's pretty hidden. But the technical operations team will make those components accessible via your laptop or your desktop or your mobile phone, and you actually don't have to do anything. There is an activity where the components will be moved to the live environment and you pull those applications or those services down when you're ready to use them. So, please note for test purposes that deployment management is about moving components to live and test environments. In review, we have discussed a variety of management practices, 15 in total. All of those practices are used within the service value system. The foundation exam will cover general management practices, service management practices, and technical management practices. Please become familiar with all 15 in addition to the variety of terms that we've covered as well. Thank you for joining the course, I hope you enjoyed the material.
