Starting Service Catalog Design, looking for best practices

[pat20]

Hi, we are starting project planning for the build of our service catalog. We have been live with ServiceNow for ITSM for six months. Can anyone provide words of wisdom, best practices and share their experiences? Please suggest any tools or resources that would provide value to us for the design and implementation. Any information would be very much appreciated!. Thank you.

[Brad Tilton]

Just to add to Robert's excellent points, I would definitely focus on search over categorization. Take all the time you were going to focus on categorizing your items and put that to optimizing catalog search. Survey the business and try to figure out what search terms people are using and what they're expecting. Think about everything in the Service Catalog through the lens of your customer.

One thing I like to do at the beginning of these types of end user facing projects is to try to identify who might be the people who are going to use your catalog the most (usually these are admins) and get them into a focus/pilot group. Run all your naming/terms by them and let them test the catalog early. Not only do you get great feedback, but you're creating a group of champions for your catalog.

I would also make sure to spend some time writing good descriptions for your catalog items. You want the end user to know what it is they're requesting and what they can expect to happen when when and after they request it. Pictures always help as well. For questions, only ask questions that you absolutely need in order for the workflows to function. The shorter your forms are the easier they will be to fill out.

Good luck!

[Uncle Rob]

Service Catalog building also requires ServiceNow expertise in the range of "actually knows what they're doing" and above.   We all know that's where it starts getting expensive.   To hedge against that expense, it may pay to do some serious BA work ahead of time.

In 2013 I rebuilt a 4 year old ServiceNow instance from scratch.   We built 150 catalog items, each with their own workflow and most consisting of multiple team executions.   A major issue was people thinking in terms of old Incident paradigms: force consumer to pick category, subcategory, subsubcategory, and subsubsubcategory, and $%&*-you-category.   Pre-training was necessary.

We had focus group sessions with each major team in which we ...

1) Gave a demonstration of catalog, with specific intent of highlighting the difference between catalog consumption and incident management.

2) Asked them to consider "if we lived in a world where technology didn't break, what work would you be doing for your customers?   What do people consume from you?"
3) Asked them to consider "what things do you know how to do and require no investigation (ie. workflow)"

After giving them a day to chew it over, we had follow up sessions where we accumulated everything in giant excel artifacts.

- One excel sheet per team, one tab per "consumable"

- On each tab we'd list out the questions they needed to execute the consumable, the question type (string, choice, reference, etc), mandatory, dependency, etc etc.

- At the bottom of each tab we wrote out a "flow" of the work.   It wasn't as good as Visio, but it was built to go *fast*

We'd have frequent catch up sessions when two teams had the same consumable item.   These usually ended up in a unified workflow with both teams represented.

JUST this BA work took a couple of months, but it enabled us to simply hand off the Excel docs to developers (again "actually know what they're doing" developers).   This saved us one *actual* 3 dimensional metric #$%& ton of work when it came to QA and review.   In all but a bare handful of cases we nailed the item definition and workflow on the first try.

[manita_anand]

wonderful points Robert.

I am going to re-built catalog for my client which they have been using from past 5 years. it was built with order guides in dublin.

Now i am re-building it from scratch in Geneva. I am the BA/Developer/Tester -all in one for this project , so Any more suggestions you have, please share.

[randrews]

ok a few different points....

get together a format for submission of new items.. a standard layout for fields required tasks required and a visio/swim diagram of the workflow....

if they can't draw a visio or swim of the workflow they <the owner of the item> are NOT ready for you to build it... work with them on getting a flowchart of their PROCESS because what we found was almost none of the groups had a solid process for what they are doing, it was all tribal knowledge.

build a base variable set <we actually have two one for items that require manager approval and one for items that do not>

in this variable set you can put in variables like requested for and any client scripts that are needed on all items... by adding this vs to all items it will save you having to recreate the wheel on every item.

Mostly i would say KISS <keep it simple .... > simply because you CAN do something doesn't mean you SHOULD do it... resist the temptation to build overly complex items if you can do them simpler because maintenance of them can get out of hand!

and that would be my last comment... remember maintenance... every field/choice/drop down requires maintenance... learn to create choice lists that are generic for things like source state country and have all items choose from those instead of recreating those choices each time... if you are building five items for a group.. and that group has a standard drop down on all of them <say record type> have them all select from the SAME choice list... that way when they add a record type you update ONE place and all their items are up to date.. takes longer on the initial buildout but well worth it on the backend.