Request Fulfilment explained
Request fulfilment, as the name implies, deals exclusively with Service Requests.
The process is defined in the Service Operations volume of the ITIL version 3 and is associated with low risk, low cost, frequently occuring issues.
These issues can be as simple as answering "how do I?" questions, relocation of hardware, installation of approved software, low risk access requests.
The primary benefit of defining a seperate process is that it allows the incident management process to focus on actual incidents that indicate a failure in a service, rather than dealing with general questions and requests.
ITIL version 3 introduces several new models and the 'request model' concept is a way predefining procedures to manager frequently occuring service requests (the model will generally include some element of change management (typically via a pre-approved change).
Service Requests can come in a number of forms. The actual service request will detail the requestor, what is required, responsible person, date and time details and eventually closure details.
Requests can also be Requests for Change (RFCs). These will generally be used when a change to a Confguration item is requested (e.g. in a bank each group of users may be defined as a CI; changes to the membership of the group may require a formal change process, but the actual change to the group can be dealt with by a service request team).
There is a very close connection between request fulfilment and the Service Desk/Incident Management process; as calls made by end users to the Service Desk may be intially treated as incidents, but be later classified as requests (following initial questioning).
In most organizations the Service Desk staff will actually fulfil the requests - but the benefit is that requests can be 'stockpiled' and worked on as a seperate exercise, once the more critical incidents are dealt with.
The process is defined in the Service Operations volume of the ITIL version 3 and is associated with low risk, low cost, frequently occuring issues.
These issues can be as simple as answering "how do I?" questions, relocation of hardware, installation of approved software, low risk access requests.
The primary benefit of defining a seperate process is that it allows the incident management process to focus on actual incidents that indicate a failure in a service, rather than dealing with general questions and requests.
ITIL version 3 introduces several new models and the 'request model' concept is a way predefining procedures to manager frequently occuring service requests (the model will generally include some element of change management (typically via a pre-approved change).
Service Requests can come in a number of forms. The actual service request will detail the requestor, what is required, responsible person, date and time details and eventually closure details.
Requests can also be Requests for Change (RFCs). These will generally be used when a change to a Confguration item is requested (e.g. in a bank each group of users may be defined as a CI; changes to the membership of the group may require a formal change process, but the actual change to the group can be dealt with by a service request team).
There is a very close connection between request fulfilment and the Service Desk/Incident Management process; as calls made by end users to the Service Desk may be intially treated as incidents, but be later classified as requests (following initial questioning).
In most organizations the Service Desk staff will actually fulfil the requests - but the benefit is that requests can be 'stockpiled' and worked on as a seperate exercise, once the more critical incidents are dealt with.
Labels: itil request fulfilment, ITIL request model, itil trigger, ITIL version 3
0 Comments:
Post a Comment
<< Home