...
- Make it easy for end users (the customers) to know where to go to request what they need and to follow up on their requests.
- Make the back-end processing and workflows as simple and clear cut as possible for the technical users and approvers who must process the requests.
- Make the system easy for administrators to understand and maintain so that changes can be implemented for one kind of request without affecting how other records are processed.
The Service Catalog offers services to the end user that may be created in one of two tables: Service Requests or Incidents. From here the requests can easily be grouped into problems or converted into a change request as shown in the diagram. The system is designed to make it easy to push requests from one place to another for further work. For instance, multiple incidents can be linked to a single problem record and a workaround pushed from the problem into the related incidents, automatically emailing the workaround to the customers.
The arrows in the diagram above show the predefined conversion paths a request may take, if a technician believes it is appropriate: a service request can, with a click of a button, generate an Incident or a Change Request, or can be linked to existing incidents or changes. Likewise, an Incident can generate or link to an existing Problem, while a Problem can generate or link to a Change Request. A change request may also cause an incident.
A Problem may be related to multiple Incidents and a Change Request may be related to multiple Problems, Service Requests, and Incidents. Naturally there are also relationships within each of these tables to Users, Teams, Configuration Items, and other essential components of the system.
Available Services and Request Types
Whether or not a particular group of users can request particular services depends on a few things:
...
Internal customers will submit service requests Service Requests – which can include the purchase of items – to request a standard service, such as onboarding of a new employee or an incident a request for a new software license. They can submit an Incident to report a problem or an interruption to a business or technical service. If merited, that incident may lead to the creation of a Problem and/or a Change Request by technical staff.
Service Requests, Incidents, and Change Requests may include a set of tasks that need to be completed before the request can be completed. Service Requests and Change Requests can also include approval workflows prior to the work being scheduled.
Submission Methods for End Users
The system can be is designed so that end users can either...submit a request in one of three ways:
- By clicking on a service catalog showing their available services.
They can then choose a business service to drill down to the services included, where they see a button to create the appropriate record for the service:
- Create an Incident or Service Request directly and then Create records directly in any of these tables and choose the appropriate service from the service catalog once in the record, or .
- Select from a configurable set of hotlinks quick links to create requests for specific services without them needing . This lets end users create service requests without the need to know what which table will be is used to store and process the requests until after they have created them.
Separating requests into distinct tables simplifies maintenance and processing compared to storing them all in a single table, since the fields, form layouts, access permissions, workflows and rules can be specific to the needs of the particular request type.
The orange arrows in the diagram above show the predefined conversion paths a request may easily take, if a technician believes it is appropriate: a service request can, with a click of a button, generate an Incident or a Change Request, or can be linked to existing incidents or changes. Likewise, an Incident can generate or link to an existing Problem, while a Problem can generate or link to a Change Request.
...
- .
Service Requests vs. Change Requests
For some services, it may be unclear whether they should be offered through a service request or a change request. For instance, account provisioning, employee off-boarding or on-boarding, or simple application changes could go under either category. We like to use the notion criteria that changes that do not require approval may are best be handled in the service request table, while those that do require changes approvals or that require careful scheduling belong in the change request table. Approvals are available to both Service Requests and Change Requests, so the services can be configured accordingly.
SLAs are primarily tied to service requests and incidents, with less weight given to SLA targets for change requests, since changes must often be carefully scheduled during maintenance windows. Thus if you are concerned with measuring turnaround time for standard services, they are generally best handled in service requests.