How long did your company take to implement and go live with Service Catalog?

[dhoffman]

We are a new ServiceNow customer migrating away from a CA Unicenter environment (Service Desk, Service Catalog, UAPM Asset, etc.).   We went live over Summer 2015 with Incident, Problem, Change, some internal Knowledge documents, and a manual load of 30K-40K CIs and assets via an obscene amount of Excel spreadsheets and complex transform maps.   We're on Fuji.

Our next release effort is to migrate a rather large, mature Service Catalog of 800-1300 items from the CA ecosystem to our shiny new ServiceNow ecosystem.   So this is more of a migration from one tool to another instead of new construction, although there's still plenty of build effort needed.   Also mixed in with this major effort is a CMS implementation as well as a more robust Knowledge Management roll-out taking advantage of Fuji's Knowledge v3 with multiple Knowledge Bases.   We're also incorporating more Self-Service (Incident, Knowledge, and Service Catalog).   We have a main corporate HQ and several subsidiary operating companies that add some complexity as far as User Criteria and who can access what items and different processes for fulfilling similar items.

Question/Survey to all of you:   How long did your Service Catalog project take?   How many people were on your team?   How many items did you Go Live with?   How many categories?   How many workflows?   Of your workflows, how many were "crazy complicated and unique" and how many were more simple in nature and could be reused for many items?   How many of your items involved lots of client scripts and UI policies?

In other words, trying to get a feel for how other customers produced a Catalog.   "Our Catalog project took 6 months and we created 300 items."   Any and all information would be really helpful as we better communicate to project leadership as well as IT leadership of what "other" companies typically take.

Thank you!

[poyntzj]

How long is a piece of string ?   I don't feel your questions can be easily answered.

Where possible you want to try to reuse the same workflows over and over again - typically the ones that do in essence just raise an RITM and / or CTASKs

More complex ones can take time depending on their requirements and so on.   (we had one that took Servicenow over 2 months to write....)

If you can, look to write a subworkflow and call it over and over again to save some time,, but this is not practical in all cases, but if you can do this it can really help  

Can some of the existing Service Catalog items be merged into one with options inside the Catalog Item itself ?   (we have one Service Management Service Catalog Item, but the form allows for 10 distinct options.   If the user chooses Service Offering for example, they then get a choice of 3 options - add / modify / retirement.   that example could easily be 3 Service Catalog Items too if we went down that route)

We don't really limit categories, and using different Service Catalogs can help.   We also use some restrictions (based on entitlement scripts) which help

Variable sets - define a good base set that are used over and over again. - do also think about the variable orders, even between sets.   having 2 sets of variable that may use the same orders on a form can have odd repercussions

UI policies / Catalog client scripts can depend on the form you have designed and how you intend to make it work.   gain, keep some in with the variable sets

If you are to use Approvals, I find groups are the best way forward.   Partly down to how we manage groups, but if you have to hunt for an approver in a workflow it can get hard on the more complicated ones. If the approvers are in a group, it is far easier to maintain a group.

When we went live, we made the mistake of trying to hurry it, listening to management and creating some "General Requests" - essentially to get us running quickly.   A lot of users get lazy and use these when there are correct Catalog Items for them to use

Also make sure that whoever is going to be running reports is happy that they capture all the information they are after and can be reported on.   the Catalog Variable Reporting app on the share site is worth while investigating and installing.

[dhoffman]

Thanks for the pointers.   Duly noted, especially the lessons learned.   I'm actually more looking for high-level data points from as many customers as possible.

[Kalaiarasan Pus]

One word of caution from the little experience that I have using ServiceNow.

Hire some sound consultants. When I say sound, people who know the real strengths of ServiceNow. One who can stop you and alert you of the potential pitfalls you are going to face.

People who are migrating from some X tool to ServiceNow, try to create a copy of what they have and are comfortable working with. In trying to recreate a copy of the old system, they tend to mess up the system and don't take advantage of the intrinsic features that are their in ServiceNow.

I also advise you to do the work in Sprints. Divide the catalogs in smaller chucks and find which one are a absolute necessity. Do the sprints and get the bugs out of the system before doing the next sprint. This would take time but the transition would be much smoother and be less of a headache as if otherwise the bugs start creeping in as a whole and would be a pain handling it.

Try making use of variable sets, common workflows, order guides as much as possible. Write reusable script includes that can be used across process. Have a good documentation of the common libraries/scripts you are creating if you are outsourcing the work to some organization. Because, attrition is a common thing in any organization. So even if the consultants change, they can still reuse stuff, thus saving your time and money.

[poyntzj]

On top of this, if you do outsource, make sure your documentation and brief is accurate and cannot be interpreted the wrong way.

One of our management could not wait for us and outsourced a Catalog Item.

Well, what came back we had to use, but it was so "narrow" in its specification it was not usable for us anywhere except this one location.

We try to look at most requirements and make then "global" and often ways to do things so that we can allow some users to make changes to user defined tables and in effect update the Catalog Items without us needing to be involved