Service Catalog Best practices

[Robin W_]

Dear all,

once again I'm rushing in with another best practice question for the service catalog. This time I'd like to ask your the following things:

1) For different Items (in different Categories), is it recommended to either create different Workflows (e.g. for Software and Hardware Items because they differe for expample in the delivery) or to create one big general generic Workflow and modify it to choose the correct path using scripts?

Example: There are two differen types of Hardware - One that is "always" on stock and one that always has to be ordered from an external service provider. If a customer orders an "on-stock Item" he'll receive a notification that he can pick up the item instantly. For "to-order Items" there shall be several other Tasks to be executed.

2) In our company, we'll hand out old Hardware (e.g. Notebooks) before the new ones. Is it recommended to create more generic Items (such as "Standard Notebook") instead of specific Items (e.g. "HP EliteBook 840 G5") to meet this requirements? Or should we create an Item for every Model we're giving out and (de)activate them as needed? Additionally, should everything (Keyboards, Mice, Headsets, Locks) be created as an Item?

3) When should variables be used instead of different Items? Let's think of this for Privacy Screens: Should there be a differen Item for every different Size of a privacy screen or should we use one Item and let the customer choose the size using a variable? If so, how should we handle privacy screens for mobile phones? 

I know that those questions are fairly general but I'd like to head how you guys are solving those issues and I'm looking forward to your recommendations 🙂 

[Ajaykumar1]

Hi Robin,

Refer the following links explaining best practices regarding Service catalog.

Application Guide: Service Catalog Best Practices

13 Service Catalog Best Practices

PLANNING 101 – SERVICENOW SERVICE CATALOG

Mark if Correct/Helpful

Regards,
Ajay

[Stijn Verhulst3 · Accepted solution]

Hi,

• It's definitely not best practice nor recommended to create one "generic" workflow which will offer alternatives paths to be processed. I've seen it myself multiple times being implemented and let me list you up the reasons why it's a no-go:
  
  - If there would be a perfect solution for one generic workflow, ServiceNow would have already implemented and delivered it within their own solution.
  - A workflow represents a business process with know inputs & outputs, therefore we can call it unique.
  - You'd be starting to build custom logic such as additional tables, scripts, etc... to make this generic workflow work, basically implying you're stepping away from the solution ServiceNow already provides to us.
  
  Now, regarding your example; it's a bit different... We're actually not talking about "one" generic workflow for all catalog items you'd like to offer to your customers but a generic one for a specific category of goods, be it Hardware, Software, etc...
  
  It's best practice to have indeed one workflow which covers these particular categories in case you don't have to build very exotic implementations 🙂
  
  As for the example about the Hardware; the processing paths can be setup in such a way, you can implement one workflow which will first check whether the hardware is in stock. If so, you send out a notification. Otherwise, you'll go through the procurement & delivery steps as applied by your organisation (= basically the ordering with the external service provider).
  
  Afterwards you can then define the workflow on all of the items belonging to the category for which this particular workflow has been implemented, definitely a best practice. It removes micro management of many, different workflows and still respect technical best practices.
  
  
• Here I see various options:
  
  - Creating a "generic" item which will not let the requester choose which model they want.
  - Creating a "generic" item which will let the requester choose which model they want (via a variable related to the item).
  - Create items for each model you're offering (and make them available / unavailable when necessary by activating / deactivating).
  
  The approach is dependent on how your business feels about it and wants to organize this from a practical level. Question here primarily is: does the custmer realizes the differences in the capabilities the various models offer, as well as does it provide them a better understanding which model exactly it is they'll need? If we talk about IT personnel, yes, they will. However, sales, HR, etc... (with all respect) will probably not.
  
  Because if you choose for a "generic" item in which the requester cannot choose the model; you can create a catalog task for the fulfillment team to decide which notebook to offer, via the related workflow.
  
  How about using for example Order Guides? They can propose the correct catalog items towards the requester based on the persona they represent within your business. It implies someone of HR for example will receive a different notebook compared to someone of IT. The beauty of it is that people experience it as a wizard with predefined items they are allowed to order with no limit towards the amount of items. And they still can pick the options on each individual item as they need or like.
  
  As for those consumables such as keyboards, mic, locks, etc... Some customers tend to bundle it into one item together with a notebook, others keep it seperate. I believe it matters to provide them as seperate items in case you actively would like to track these assets (in the end they are company property with a financial value, including a lifecycle), which is also best practice in the end. But again, these different consumables made available as seperate items can be included into an Order guide together with the seperate notebook item.
  
  
  
• As for the privacy screens; a privacy screen will always be a privacy screen, right? 🙂 My message here is, it's one type of object or thing. So it represents one item and options such as the size will be a variable.
  
  As for the privacy screens for mobile phones, this should be in my humble opinion a variable on the phone item you're offering via the catalog.
  
  Yet, one important note here, it might be useful of implementing variable sets for the screen options: 1 for the notebooks, 1 for the mobile phones. Each of the variable sets would then contain at least 1 variable called for example "Privacy screen" with some dropdown values. This way you attach the variable sets across multiple items and you only have to maintain the variable from 1 central place 😉

Hope this bring you some more clarity 🙂

Warm regards,

Stijn

[Robin W_]

Wow, this is the most satisfying answer to a question I've ever posted, thank you! 🙂