Separate catalog items or unique catalog item for different operations related to a common topic

[Fred Jean]

Hello,

Let's take a use case (or actually a set of use cases) where users should be able to request different operations related to a given item. Let's say for instance operations such as installing, moving or disposing a server. 
Knowing that these uses cases would involve some common variables but also a number of different variables depending on the operation, and that the actual process would also be different (involving different tasks),

I consider that the best way to address this is to have one catalog item for each operation.

From the user perspective :

• Given that these operations should be requested through the portal, and that the portal encourages the use of the search field, if the user types "install a new server" he would end up on the relevant from without having to specify again the intended operation is installation
• Having a dedicated form avoids that behaviour hiding and showing variables when selecting the operation. This behaviour, changing the form layout,  can be seen as annoying/disturbing.

Form the developer perspective :

• Simple separate forms are easier the implement and maintain than a more complex common form involving conditions to show/hide variables and may be make some mandatory or not, read only or editable.
• Separating catalog items enables to implement these different requirements in parallel
• Catalog Builder with templates and variables set makes it easy to create similar, yet different catalog items, even making possible to define different approvals and tasks without having to implement a flow.

However :

• some customers still insist on having a common catalog item for such use cases
• the ServiceNow Best Practice document "Design a world-class service catalog" states : "Should we create separate catalog items for the possible options within a request? Avoid
  creating multiple similar catalog items. Instead, build flexibility within the catalog item to allow
  users to pick between multiple options (such as different laptop configurations) within the
  request form. Use Service Catalog variable question choices to develop that flexibility."

I am not sure the ServiceNow Best Practice was written with the same use case in mind, but I'd be curious to know :

• What could be the arguments for that ServiceNow Best practice statement ?
• What's the opinion of Experts, users and customers on this topic (single common item or separate ones) ?

Thanks for your feedback.

[AndyT6190156825]

"Horses for courses", I think it very much depends and there is no right answer - even in a single catalogue. 

I would always try to balance User Experience vs Data Governance and Business output.

In many large organisations IT (and other) procurement is a simple pass-through of pre-determined catalogues from their vendors. To make automation and integration as simple as possible why would I not reflect my catalogue the same way my vendor presents it to me? 

That could be - 5 different product codes / sku for 5 different flavours of laptop or they may give you 1 product code with user selective options. If the former, I may wish to bundle these to make life easier on the end user - as Anders suggests under a single Service Offering for End User Compute / Laptop Provisioning. If I model the catalogue as presented to me - I am much more likely to provide a high quality end to end procurement process with less failure points. But there will always be the customer requirement to make you stop and think - "we don't want to bundle our IT like our supplier does...."

If I take another use-case, lets say I have enterprise licensing agreements for 25 applications. No physical transactions take place in the procurement of licensing when a user requests it, and perhaps the provisioning of that license is fully automated.

Here I may wish to have a single "Request business application" catalogue item where the user can select from the options available, why? The number of results returned to the users search are far smaller speeding up the request time, the process to fulfil the request is the same no matter what I select so I don't need multiple flows and as an admin I have less items to maintain. But there will always be the customer requirement to make you stop and think - "not all employees should see the same applications"

You could also use the age-old measuring stick of "What would Amazon do?". They do both 🙂