As we discussed some months ago in When Project Management is Wrong for your Project, it is possible to address smaller, frequently occurring, low-risk changes with a Standard Change.
Why use a Standard Change? One very important reason to have some Standard Changes in your quiver of ITIL tools is the operational efficiencies you can receive by effectively “automating” changes you do all the time. Thus, you can receive the benefits of controlled Change Management while at the same time preventing it from turning into a slow-moving bureaucratic operation.
What ITIL V2 did not address, however, was exactly how to execute a Standard Change, other than to note that the change might be initiated by the Service Desk. Strike up the band! ITIL V3 takes care of that oversight with the creation of the new Request Fulfillment process that deals with user-initiated Service Requests. This newly formalized process ties two parts of ITIL very nicely together – Service Desk and Change Management.
What is a Service Request? We all know what an Incident is, and we all know what constitutes a Request for Change. Imagine, if you will, a Service Desk that recognizes that not everything that flows through it is an Incident. Some, tickets, in fact, are pure and simple requests for Service:
These requests all have a few things in common. They are standard services; i.e., password resets are expected as part of commonly performed activities. They have a pre-defined approval process; i.e., new employees have a standard desktop configuration. They are low-risk; i.e., the tasks and activities to accomplish them are well-known and documented. And, they have a defined budget; i.e., the requester “owns” the budget and budget costs are known.
But, unlike other Requests for Change, these Service Requests do not go through the Change Management Process. Instead, the Service Desk handles them, using a process that is very similar to the Incident Management process.
Of course, a Service Request is not an Incident. Nothing is broken, and there are no disrupted services to restore.Request Fulfillment Process. Instead of following an Incident process model, the Service Desk follows a pre-defined Request Fulfillment process. First, to prepare for the Request Fulfillment process, the Service Desk compiles and presents a “menu” of all the Service Requests that it can fulfill. There can be no “seat-of-the-pants” fulfillment operations here; it must be specific about the types of requests it can handle.
Second, the financial implications of each type of Service Request should be known and documented. This means that the cost estimates should be accurate, and should clearly identify the financial owner who will give approval for the Request Fulfillment.
The Request Fulfillment process identifies any additional approvals that are required for a Service Request, and, like Incident Management, it should always contain a Closure process to indicate that the Request has been successfully fulfilled.
Request Fulfillment Interfaces. Request Fulfillment has several very strong interfaces. The first, and most obvious, is with the Service Desk and Incident Management. The Service Desk provides the staffing and resources to manage the Request Fulfillment lifecycle, and the Incident Management process provides the model for designing the Request Fulfillment process.
In fact, many organizations start out by using their Incident Management process to handle requests, later separating the two streams when they are fully familiar with the Request Fulfillment cycle.
As a modified Change process, it is no surprise that Request Fulfillment has a very close relationship with Release and Deployment, which manages the actual release of changes into the live environment. It also works tightly with Asset and Configuration Management so it can register its changes in the Configuration Management System.
Request Fulfillment may be a new name, but it’s a familiar process. It is a Standard Change, as identified within both ITIL V2 and V3, and it parallels the familiar Incident Management process. And, as we have seen, it follows a pre-defined process that reduces both risk and bureaucracy – and responds to user requests in an efficient and economic manner.