Service Request vs. Request for Information
In the spirit of recent posts related to ITSM implementation considerations I would like to toss another practical topic into the ring that goes slightly beyond but does not break the good practices documented in ITIL. Many of the readers of this blog may be aware that ITIL v3 has acknowledged that Service Requests as handled by the process of “Request Fulfillment” and found in the Service Operation book has been acknowledge in ITIL v3 as its own process and is not tied to Incident Management as some would espouse.
I for one never saw eye-to-eye with this view and found myself on the side of the debate that preferred to think of a Service Request as a low risk change focused on the request for something that a user did not have or a modification of something they already did.
E.g.: I want a laptop, a new user account, or access to a report that is beyond my access rights
With Request Fulfillment being acknowledged as its own process outside both the domain of Incident and Change Management this effectively silences the ITIL geeks such as myself on this topic and forces us to find some other minor issue to debate as we down our recreational beverages.
The challenge that still remains however is whether there is a difference between a request for service and a request for information. The general description of a Service Request covers both.
From the ITIL v3 glossary we can find the following definitions:
Service Request: A request from a User for information, or advice, or for a Standard Change or for Access to an IT Service. For example to reset a password, or to provide standard IT Services for a new User. Service Requests are usually handled by a Service Desk, and do not require an RFC to be submitted. See Request Fulfillment.
However in practice when implementing an ITSM tool or setting up a Service Desk it has always been my advice to create a different classification for each of the following:
- Service Request: Standard / Pre-approved Change
- Request for Information: Advice, information, on the phone training
- Password Reset: Not an incident since the service is still there ready and waiting, more like a request to let me back in
Note: All of these record types are different from an Incident ticket that supports the restoration of service.
It is my view that a distinction has to be made by the service desk between each of these different types of records both from a management information and process workflow perspective. Regardless of the question of ITIL v2 or v3 this distinction has always been needed when implementing these practices.
Troy’s thoughts what are yours?
Now this is not the end. It is not even the beginning of the end. But it is, perhaps, the end of the beginning. ~Sir Winston Churchill
Does the request for a brand new service or a new appplication fall within the domain of Service Management? If so should these requests be recorded on the Service Request Log?
You are right in your assumption. This is even more so now with the release of ITILV3’s introduction of the Portfolio Management process described in the Service Strategy and Design books. The request for the new service could be potentially submitted to a role in Service Management “The Service Manager”
The way I understand the Service Manager role is that he or she owns a super set of services from a strategic perspective. A service owner owns each Service but you could refer to the head of ERP Applications as the ERP Service Manager in that he or she has ownership for all of the application services in that category. Or alternatively the head of Infrastructure has the ownership of all of the back office infrastructure services.
We documented this role in the service catalog book but called it a Service Delivery Manager (Pre-ITIL v3)
Service Delivery Manager:
However the Service Delivery Manager is accountable for the strategic view of overall IT service offerings as described by the catalog is responsible for the tuning and improvement of those services in order to ensure they continue to meet business needs. It is not uncommon to find a Service Delivery Manager as a direct report to the CIO. In some organizations this role is referred to as a Product Manager.
Service cut across silos, they cross different functions—it is the service delivery managers role to assemble them into bundles that make sense to IT’s customer. The service delivery manager both leads and collaborates in defining, supervising and enhancing services to achieve the needed levels of customer satisfaction, regulatory compliance, and operational effectiveness. Outsourcers and most high-tech companies have this role already.
This role is responsible with coordinating defining both the specific services to be provided as well as the roadmap of future IT services. This is done in conjunction with both the service level managers, IT executive management and service owners. To do this the product managers must own the definition the SLA’s, measures, bundles, resources, pricing, cost allocation.
They are the ones who design the options between quality and cost which the customer can then select. Because of this, they are responsible for the strategic roadmap for improving service quality and cost—they do this in conjunction with the IT planning function.
SDM’s are responsible for the competitiveness of their offer in their marketplace. That means benchmarking their offers against external providers, leaders in their industry, the important metrics.
The Service owner role is accountable for a specific service within an organization regardless of where the technology components or professional capabilities reside which build it. Service ownership is as critical to service management as establishing ownership for processes which crosses multiple silos or departments.
To ensure that a service is managed with a business focus the definition of a single point of accountability is absolutely essential to provide the level of attention and focus required for its delivery.
Much like a process owner the service owner is responsible for continuous improvement and the management of change affecting the service under their care. However in both cases these horizontal roles are as effective or not according to the level of empowerment provided to the role by the executive of the IT organization. The Service owner is a primary stakeholder in all of the IT processes which enable or support it.
Hope this helps
TroyPosted by Troy DuMoulin on 08/16 at 12:00 PM
We are working on Service Requests and getting ‘stuck’ on some verbage we have inherited. The terms are “Standard Service Delivery Request” and “Simple Request”. In trying to classify our services we first need to understand the difference. Have you heard of this before?
While I have not seen the term Simple Request before I can guess what this is.
One of the key deliverables for both Change Mgmt. and Request Fulfillment is the development of classification models (Big to Small) that indicate how much assessment, paperwork or what level approval is required.
See my post called Its Classified
A Standard Request or Change usually means that these are low risk, cost requests that have been documented and are repeatable.
In most cases these types of requests are either pre-approved or only need the cost center approver to give their blessing for the request to be fulfilled.
My guess is that a Standard versus Simply request refers to two levels of authorization. Perhaps a standard request requires a line manager or cost center approver and a simply request (eg: buy a mouse, a password reset) is a pre-approved activity.
TroyPosted by Troy DuMoulin on 08/30 at 09:30 AM
If you consider that a standard operating procedure (SOP) refers to a documented and consistent way of doing things then it can be understood that the term SOP refers to a way of doing things as opposed to what you are doing.
I can create a SOP for emptying my dishwasher, changing my oil or handling a standard service request.
Standard Operating procedures are great when you have a highly repetitive task that is complex, regulated, or resources lack training or do not execute the procedure frequently.
So in short you can have defined SOP’s for the following processes to ensure consistency in execution.
Incident Management: fix something that is not working
Request Fulfillment: Ask for something you don’t have or a modification of something you do that are defined as requestable services within your published catalog.
Change Management: Gain approval to modify the status or attributes of a service or one of its components.
Hope this helps
TroyPosted by Troy DuMoulin on 11/01 at 04:46 PM
Thanks Troy. Your insights are very helpful, since I am trying to re-organize/structure our incident management process (according to ITILv2) towards ITIL v3 and have to take-out the Service Request part into the Request Fulfillment process. The Information Request calltype has proven to be necessary in our organization. So although the ITIL v3 definition tells me it is a Fulfillment Request item, I rather see it as a separate category in our tooling.
RJPosted by Robert-Jan on 10/09 at 05:25 AM
Hello Sunny, you are hitting on a debate the people who care about these things have been having for many years.
For me in the days before ITIL v3 the Service Request was always a kind of baby change (standard change). This was further enforced in that Service Requests like on boarding a new employee usually required many parallel or sequential tasks to complete the full order / provisioning process. Several years ago the tasking engines were to be found in the Change Management module and not usually in the Incident Module of the tool.
However, as time progressed several tools developed a shared tasking engine for all of the ITSM processes so this became less of a deciding factor. The key is that your Request Workflow will have a pre-defined set of steps, activities, approvals, etc. and that they will usually result in updating some element of the CMDB or person record.
Most tools today will have a separate Service Request module which is fed off some sort of Portal or Request Catalog.