Request Handling

Print Friendly, PDF & Email

There are 6 areas where requests will be held and processed:

  • Event monitoring and reporting
  • Incident reports
  • Service Requests
  • Access Rights request
  • Problem records
  • Requests for Change

All requests sent to will start off as being Incidents in the first instant as they are reported. Also, Incidents will be created by Event Management processes such as an automatic monitor or failure report. These will then form part of a Incident Management process.

In the first instance the Incident is logged and then taken or given to an owner. The owner will determine whether it fits into a pre-defined set of Service Requests. If it’s a service request it will marked as so and moved to a Request Fulfullment process. Additionally, it will be determined if the type of request is a Request for Change which is associated with a pre-defined set of Access Rights Changes (such as changing a password or setting the permissions on a shared directory on a file server).

Next the Incident will be evaluated for priority, following an initial diagnosis, will determine if it should be escalated. If normal service can be restored the method of restoration will be documented and the request will be marked as resolved. If the Incident needs to be escalated the original owner will pass the Incident to the determined escalation team and a new process will be applied to determine a resolution to the Incident. This process may contain procedures specific to that team. Reports will be documented by that team and returned back to the original owner for resolution. If further escalation is necessary the Incident will pass back to the Owner before being escalated again.

Once the Incident is confirmed as resolved, normally by the user or by a test mechanism, that triggered the event that created the Incident, being satisfied, the Incident can be closed.

If, by method of trend analysis or monitoring or experience, it is determined that one or more Incidents may have further significant affects on the quality of service(s) delivered in the future, a Problem record will be recorded. A Problem Management process will then be applied. This process will be handled by a Process Manager in a the Systems Operations, Development or Zonal teams. Known Errors and Workarounds will be fed back to the Service Desk so that Incident management can work more efficiently.

Problem analysis may determine that a Change is required to action a permanent fix. If so the Owner of the Problem record will make one or more Requests for Change which will pass through a Change Management process. The Change Management process starts with authority being sought from the service manager or owner for which the change will affect.

If the Request for Change is among a pre-defined and authorised set of changes the change will be coordinated and actioned accordingly. This will involve evaluation, risk assessment, planning, timing, a remediation plan, coordination with other teams and must follow a strict Release and Deployment Management process. The (estimated) average turnaround on Requests for Change is 2 weeks so the RFC must be received well before the change is required. Full formal details of these processes are yet to be documented and agreed upon.

1 Comment
Comments are closed | comments rss [?]
  1. ITIL training finished! • Blog Archive • ILRT SysBlog 03.03.11 / 5pm

    […] Request Handling […]