The key for any Service Provider to turn around a poor image of IT is in the service desk. For many organizations that means rethinking who they are, what they do and how they manage the relationship with their business customer, and those who consume the services they provide.
For years IT organizations have fielded a help desk (a place where “users” call to get things fixed) and called it a service desk without providing the fundamental “services” that one would expect from a service desk. Key among the missing is a single point-of-contact between the customer and IT to not only manage incidents (things that are broken), but also to handle requests for routine services and communication between IT and the customer.
This is often the result of an immature technology-focused IT organization, or one that bought a tool that had “service desk” in its name. In both cases the lack of a “service culture” often led to disappointment with IT or down right abandonment by the “users.”
While the ITIL Service Operation volume provides the descriptive framework for an IT organization to deploy a service desk and to manage the incident management process, it wasn’t until the recent release of ITIL’s refresh, version 3, that the whole notion of a structured way of handling routine requests for standard services was integrated into the Service Desk function.
While the guidance in the version 3 is a bit thin when it comes to setting up and integrating a Request Fulfillment process with the Service Desk function, it’s a start. What follows is a quick look at the practical aspects of what it takes to put it all together.
Extending the scope of the “help desk” to include more than just coordinating the rapid restoration of services adds “service” to the “Service Desk.” It enables the Service Desk to actually perform as the single point-of-contact between the Service Provider and the Customer. The Request Fulfillment process allows the Service Desk to deal with the Customer’s requests for the routine delivery of standard services.
Request Fulfillment – The process itself is pretty straightforward; provide the customer with a “menu of services” from which to choose, apply some sort of qualification criteria and if everything is a “go,” then fulfill the request. Of course there are a few “details” that need to be addressed.
Service Menu – As the name implies the Service Menu is a list of standard services that have been designated for routine delivery. That means that they are well-known, low risk and they have well-established financial responsibility and managerial accountability. The term “menu” is used to avoid confusion with the ITIL’s use of “Service Catalog.”
In ITIL terms the Service Catalog is a “database or structured document with information about all live IT Services, including those available for deployment.” However, not all services in the live environment are “exposed” to the customer because not all services are “standard,” or “routine.” In other words, not everything in a Service Catalog is of interest to the customer. This is a critical distinction because the term “service catalog” is commonly used by software publishers in the request fulfillment market space to represent a menu of standard services available for routine delivery.
The actual mechanism for the “menu” is immaterial. What is critical is how these standard services came into being.
Service Portfolio – The Service Portfolio Management process within the Service Strategy domain kicks off the process by managing the collection of investments in services delivered to the customer, including the definition, analysis, approval and chartering of services; including service requests. The design and repeatable nature of the standard services are actually realized via the validation processes of Service Design and the change and acceptance processes of Service Transition. But that’s the topic for another DITY.
Service Request Approval – Once the customer has selected the desired service, the request must pass through the approval part of the process. This is relatively straightforward; first of all, is the service on the Service Menu?” If it is, then it’s already been established as a standard service, with acceptable levels of risk and known resource requirements. Second comes financial approval; this is normally the responsibility of the customer. The costs are known and the “price” has been established for the service. The last step is managerial acceptance of the request which establishes both responsibility for the price of the service and accountability for the use of the service.
Service Request Fulfillment – The fulfillment of the request starts only after the Service Request has been approved. Staff members of the various technical functional groups, under the overall guidance of the Technical Management function, do the work, and the established Service Transition Lifecycle domain processes such as Change, Service Asset & Configuration, Release & Deployment and Access Management processes hold responsibility for its execution. Standard Changes ensure Service Requests are handled with the same rigor as any other change, but remove much of the bureaucracy. The Configuration Management Database (CMDB) is updated via the Configuration Management System (CMS) after the new service has been released for deployment, deployed and has been accepted by the requestor.
Service Request Closure – Upon completion of the delivery of the requested service and its acceptance, the request can be closed. Service Request Closure is similar in nature to Incident Closure; it’s the responsibility of the Service Desk to ensure the request was delivered on time and on budget and meets the expectation of the requestor. Once that has been confirmed the Service Request can be closed.
Summary
Integrating a Fulfillment Process within the Service Desk provides a way for the customer to request a standard service and have it delivered in an efficient and effective manner by the Service Provider. The service can be provided by either an internal or external service provider. The key is that it’s well defined (thought about in advance, planned for within the infrastructure, with costs understood and resources allocated). That means it is part of “normal” and it gets done as part of the normal activities of the Service Provider, and not just when things “slow down.” It makes the Service Desk really a place where customers get service and most importantly, as the face of IT, it’s what the customers remember when they think of IT.