WiscIT - Incidents vs. Service Requests (vs. Tasks)
Incident vs. Service Request: ITIL Definitions
Generally, ITIL defines an Incident as:
an unplanned interruption to an IT service or a reduction in the quality of an IT service
whereas a Service Request is:
a formal user request for information, advice, access to a service, or a standard change
Challenges in Definitions
While it would be ideal to have ironclad definitions for incident and service request, the reality is that there are both interactions with customers that cross the boundary between incident and service request as well as tool considerations that might not match the "best" definitions for the terms.
The classic example that helps illustrate the challenges in definitions is a password reset. A password reset is both a standard, routine, request with a repeatable procedure, but it could also be considered a degradation of service from the perspective of the user that can't login.
What are Incidents, Service Requests, and Tasks in WiscIT?
Incidents
Incidents in WiscIT are for issues and requests that don't have a repeatable, documented workflow (or at least don't have a repeatable workflow built in WiscIT). Generic service inquiries, service feedback and non-repeatable requests are represented in WiscIT as inicdents. Fledgling or underdeveloped processes may initially be represented as an incident, but may eventually evolve into a defined service request depending on:
- Process maturity
- Volume of submission
- Resource constraints to document and build the workflow
Service Requests
Service Requests are standardized, documented and repeatable processes. Service Requests in WiscIT must have:
- A Customer so that request eligibility can be evaluated
- A Request Offering i.e. a template/webform to collect the required information for the service request.
Because Request Offerings take time and resources to build, not every process that could be represented as a Service Request in WiscIT will be represented as a Service Request; fledging or underdeveloped process may be represented as incidents until they are able to be developed into Service Requests.
Tasks
A task represents a piece of work to be performed as part of a process. Tasks cannot exist alone; they must have a parent Incident, Service Request or Change object.