In the article discussing Service Categories, we explored standardized representations for groupings of Service Request Types (SRTs), called Service Categories, and we touched upon SRTs but did not elaborate on their details. This article gets into those details and discusses how to represent, organize and use them so you can design and built a far more effective and efficient Service Catalog.
Understanding Service Requests
A Service Request (SR) is what a person (or system), called a Service Requestor, generates in order to invoke a specific Service with the intent to generate or receive a controlled outcome, in the form of one or more Service Deliverables.
Implemented correctly, a Service Request leads to a very specific, correlated, and measurable Service Deliverable that can be tracked throughout its life cycle, from request submission to request completion.
The use of the word correlated is intentional and important and because it means that for every unique and standalone Service Request that has been properly submitted and accepted for work there is at least one unique and standalone Service Deliverable. As a result, to most Service Requestors and other key Service Management stakeholders the Service Request Type is equivalent with the individual and unique Service that is being invoked. For this reason, it is important to be very clear about the Service Request Types that are available, with a clear description as to what they mean and how they can be invoked.
Service Request Types
Service Request Types (SRTs) represent standard classifications for the invocation of specific Services that help establish a repeatable and intuitive pattern for Service Management solutions.
There are six (6) classification or categories for Service Request Types (SRTs) that are considered to be the most common and that help create a repeatable and intuitive pattern in Service catalogs:
- Creation Request Types
- Inquiry Request Types
- Modification Request Types
- Deletion Request Types
- Support Request Types
- Estimation Request Types
The establishment of repeatable SRTs ensures that a pattern can be implemented, for each Service Category, which ensures design consistency, implementation consistency, and usability consistency (i.e. intuitiveness for the end users).
1. Creation Service Request Types
Request the Creation and Registration of a New [NAME_OF_DELIVERABLE_TYPE]: This SRT allows a Service Requestor to invoke the creation or initiation of a new instance of something. For example, the creation of a new Contract or Database, or the initiation of a new Business Merger.
2. Inquiry Service Request Types
Request for Information: This SRT is used to allow Service Requestors to ask for general information about something related to the Service Category domain that the Service Providers are qualified to provide data and information about. For example, you might want to ask a question about one more Contracts (Contract domain), Databases (Database domain), or Business Mergers (Business Merger domain).
Request a Report: This SRT allows Service Requestors to ask for one or more reports about a related Service or Service Deliverable. For example, requesting a report about one or more Contracts, Databases, or Business Mergers.
3. Modification Service Request Types
Request an Administrative Change: This SRT allows a Service Requestor to submit a request to execute some specific administrative function against an existing asset. For example, a request to add a new user to an Application or a request to extend a consultant’s badge for another month.
Request a New Requirement be Implemented: This SRT allows a Service Requestor to submit a new requirement for an existing asset. For example, the requestor can submit a new requirement for an existing Product, Service, Application or Software.
Request a Migration or Move: This SRT allows a Service Requestor to migrate one asset, like a Product or Service, to another. For example, migrating a Database from one technology to another or moving one or more people from one physical location (like an office) to another.
4. Deletion Service Request Types (a.k.a. Termination Service Request Type)
Request the Deletion, Destruction, and/or Purge of a/an Existing [NAME_OF_DELIVERABLE_TYPE]: This SRT allows a Service Requestor to submit a request to delete or destroy a Service Deliverable. For example, requesting the destruction or deletion of a Contract, Database, or an Application. Or, we may request to terminate a Business Merger.
5. Support Service Request Types
Register an Incident or Disruption against an existing [NAME_OF_DELIVERABLE_TYPE]: This SRT allows a Service Requestor to submit and report a support incident against an asset or a disruption to a Service. For example, registering an incident or disruption with one of your Business Applications.
Register a Defect or Bug: This SRT allows the Service Requestor to submit a Defect against a known Service Deliverable (e.g. a business or technical asset). For example, submitting a defect for a Consumer Product or a bug for a specific Application or Software Release.
6. Estimation Service Request Types
Request an Estimate for a New [NAME_OF_DELIVERABLE_TYPE]: This SRT allows the Service Requestor to engage the Service Provider and ask for controlled estimates on what it would take to create a new Service Deliverable (instance), given any known constraints. This type of Service Request is critical for roles like Architects (Enterprise, Solutions, IT, etc.) and Project Managers who need to create holistic estimates for work, before the work is approved and actually performed.
Request an Estimate for Modification [OF_AN_EXISTING_DELIVERABLE_TYPE]: This SRT allows the Service Requestor to engage the Service Provider and ask for controlled estimates on what it would take to modify an existing Service Deliverable (instance), given any known constraints. This type of Service Request is critical for roles like Architects (Enterprise, Solutions, IT, etc.) and Project Managers who need to create holistic estimates for work, before the work is approved and actually performed.
Request an Estimate for Deletion or Destruction [OF_AN_EXISTING_DELIVERABLE_TYPE]: This SRT allows the Service Requestor to engage the Service Provider and ask for controlled estimates on what it would take to delete and/or destroy an existing Service Deliverable (instance), given any known constraints. This type of Service Request is critical for roles like Architects (Enterprise, Solutions, IT, etc.) and Project Managers who need to create holistic estimates for work, before the work is approved and actually performed.
Customization of Service Request Types
There are justifiable exception cases, where for specific Service Categories:
- some of the above SRTs will be unnecessary or not applicable, and/or
- new custom Service Request Types (SRTs) will be necessary.
In such justifiable cases where custom SRTs may be required, they should be treated as the exception and not the rule, as the addition of custom SRTs can easily break repeatable design patterns and can influence the complexities, intuitiveness and costs associated with your Service Management solutions.
We can see consistent representations for Service Request Types, across different Service Categories, in the Example Service Catalog.
Every Service Category is set up to be consistent and repeatable, and if you drill into any Service Category, such as Database Management Services, or Environment Management Services, or Laptop Computer Management Services, you will see that they are all set up the exact same way.
Note that exceptions for Service Request Types can easily be added.
The Benefits of using standard and repeatable Service Request Types
- Lower complexity: Because Service Request Types (SRTs) are standard and repeatable, just like Service Categories, design complexity is reduced. Solutions to handle SRT implementation, modification, copying, deletion, etc., can be reused, ultimately leading to a far simpler set of solutions for your processes and for any tools you implement, like your Service Catalog.
- Quicker Service set up: The standard and repeatable nature of SRTs means that setting up new Service Categories and Services is simple, quick, and low cost because things are configurable and require far less custom coding. For example, Service Categories and SRTs can quickly be set up in a spreadsheet and quickly loaded into a Service Catalog. Changes to add new Services, modify existing Services, or to delete existing Services becomes very simple, very quick, and very low cost.
- Quicker Service Catalog set up: Because large quantities of Services can be set up easily and quickly, it translates directly to very simple, quick, and low cost Service Catalog set up. This means you can enable vast communities of End Users that need access to Services very simply, very quickly, and for very low costs.
- Lower costs to set Up and maintain your Service Catalog: We cannot stress the value of lower costs to implement Services and your Service Catalog. Simple, standard, and repeatable patterns like those discussed for Service Categories and Service Request Types lead to far lower process and technology costs.
- A far more intuitive End User Experience: And, while the above benefits are all important, the most important benefit is that the Service Catalog becomes intuitive and easy to use. End Users know that if they can find and invoke Services one way for a specific Service Category they are familiar with, they can accurately guess that the same exact patterns will apply for most other Service Categories (with some minor and justifiable exceptions). After all, the whole purpose of setting up Services and your Service Catalog is to make the work experiences of your End Users better, faster, and cheaper.
Summary and Conclusions
Service Categories and Service Request Types are two very different things. Service Categories act as groupings or indices for Service Request Types that to them.
Service Request Types allow specific Service invocation and result in one or more very specific Service Deliverables. This means that Service Request Types are intended to be transactional, meaning they have a life cycle that starts with their creation and ends with their verified completion.
Understanding the differences between Service Categories and Service Request Types helps IT professionals design and build scalable, easier to maintain, and far more intuitive Service Catalogs.