Service Catalog and Request Catalog: To link and how to link?
When it comes to Service Management, we often get the same question during a ServiceNow implementation: should the Service Catalog and Request Catalog be linked? But what exactly is the difference between both? Let’s first have a look at the definition of the 2 types of catalogs in ServiceNow:
ServiceNow Business Service Catalog:
This module equals to what ITIL calls the “Service Catalog” and contains the list of Services and Service Offerings. The audience of the Service Catalog is the customer: in most cases the different departments and business units of a company that use IT services and pay the bill for it. (e.g. Head of Marketing paying for the CRM service provided to his/her department). A Service has its own lifecycle, from development, to operation, retirement and so on. We then refer to the Service Portfolio.
ServiceNow Service Catalog:
This module – used by the customer’s end-users (i.e. the workforce from the departments and business units served by IT) – contains the list of catalog items that an end user can order (for example a printer, an iPad, an access to an application, a software, etc.). This leads to a Service Request for which the delivery progress can be tracked online. In order to avoid confusion with the ITIL Service Catalog, Fruition Partners often proposes to name it “Request Catalog”. The latest Geneva release even allows you to create multiple Request Catalogs, reinforcing the use of ServiceNow for Service Management beyond IT (HR Service Management, Financial Service Management, Facility Management, etc.) by establishing dedicated catalogs for other Shared Services such as HR or Finance.
Now that the distinction between both catalogs has been made, let’s get back to the initial query: can it be useful to link the Service Catalog and the Request Catalog and if yes, in which cases?
To answer this question, let us have a look at the different possibilities of linking the catalogs.
One approach often considered is the “Top-Down” navigation by linking both catalogs so that end users navigate through the Service Catalog structure to find the catalog items from the Request Catalog. For instance, to request a new software to be installed, users would then choose e.g. Workplace Services, then Software Management and would then finally see the “Order a new software item”. The greatest disadvantage of the Top-Down approach and what makes it difficult to apply is that the Service Catalog represents the way IT Services are organised and might not be very meaningful for end users.
Another efficient approach is to organise the Request Catalog with a structure that is meaningful for end users and that usually does not match the structure of the Service Catalog. This approach is a good solution as end users’ main interest is to request the necessary items to be more productive. They are rather not interested in IT organization/structures. An additional benefit of providing a better user experience is the coincidental increase of user adoption. In that case, the link is created by matching the catalog item with the relevant service offering (technically, by creating a new “Service Offering” field in the Catalog item table). A catalog items could eventually be linked to multiple service offerings.
In both cases, the benefits of linking the Service Catalog and the Request Catalog are:
More detailed reporting: In reporting, you can answer the question, how many requested items do we get for a given service offering or service (parent of the service offering). Note that this will work in a simple way if catalog items are only associated to one service offering otherwise it’s more complex (but feasible by leveraging the subscription of the service offering)
Manage entitlement at the level of services: In terms of entitlement of the catalog item, you could propagate the entitlement of the service offering (a service offering is subscribed by a company/department/groups/…) so that only users which are entitled to the service offering can see the associated catalog items. By doing this you manage entitlement only at the level of the service. Beware that this approach works well if your entitlement rules are simple. If they are more complex you might have to complement/overwrite the entitlement at the level of the catalog item to refine it.
So which one to choose? As always, there is certainly no one-size-fits-all approach and it will very much depend on the organization maturity and objectives. As we usually put a strong emphasis on the “Service Experience” – that covers all the components aiming at delivering a delightful experience for the end user – we would be inclined to advise the independent navigation approach. Nevertheless, in certain cases starting with a top-down approach and set the more user-friendly independant navigation as a mid-term objective is the most pragmatic way to move forward.
To help our customers define what’s best for their company, we’ve developed a range of advisory services that tackle such topics. Get in touch if you’re interested in knowing more about it.