REQ vs RITM Best Practices

[adamrauh]

Hey all,

I understand the answer will always be, 'do whatever works best for your organization' - but I was wondering if anyone has any experience and/or best practices of working with the service catalog at the RITM level vs. the REQ level.

I recently gave an initial run-through of our opening Service Catalog offering, and the feedback I got from my techs were, 'Why do we need a REQ # when we'll be working at the RITM level' (right now we're not using tasks, though theoretically that would still not apply to the above as it's a layer down).   I explained to think of things from the user's perspective, and that the REQ was the "shopping cart", and the RITM's were the individual items in the shopping cart, waiting to be fulfilled.

Their feedback was, OK...but then since most of our requests are one for one's (one item requested at a time...rarely more), why not just give the the user the RITM (or multiple RITM's if multiple item's are ordered) vs. 1 REQ, because otherwise they have to manage and provide notes/input at the REQ and RITM level.

Most of their feedback stems from previously only working w/ Incidents, where there is only just 'an incident', not multiples combined together, and they view the REQ as unnecessary overhead that could skew reports or slow down throughput since it's something else they have to keep up with.

I was wondering if anyone else has ever dealt with this as well, and/or found it advantageous to drive their workflows off of multiple RITM's vs. (1) REQ ---> (multiple) RITM's.

[AdityaTW]

Totally agree - just because you can do it, it doesn't mean you should do it.

[pilar]

I think is the best logical work, So why not put all the items in the shopping cart REQ.

I am newbie in Servicesnow.com, but I was analyzing and found out it was little redundant.

[AdityaTW]

It's not the workflow that creates the REQ records; I believe it is the code behind the 'Order Now' button. I don't know if we have visibility to that code. You could open a HI ticket with SN and ask them.

http://wiki.servicenow.com/index.php?title=Introduction_to_Service_Catalog#Request

[Jason Stephens]

Hi Adam,

Just my opinion, but you can easily set things up so that the end users are not seeing any REQ information.   Fire notifications via RITM's, remove the REQ info from the cart, on the ESS page just show "My Requested Items", etc.   I have done it this way in the past, and that seems to help with the confusion.   You can also train your techs on how the system actually works.   They shouldn't be creating REQ's manually for the most part, they should be using catalog items that will in turn create all of the background records.

As Doug said, if you REALLY want to remove the REQ from the equation, you are looking at serious dev time. Again my opinion, but the best way to handle this its hide the REQ's as much as possible, and train the techs that it's not really that important in item creation fulfillment (if that's the view that yourself and your leadership are taking).

Hope that helps some,

Jason

[jcraneNYC]

As Doug said, run far far away from circumventing the REQ record. This is out-of-box functionality based on best practices. Making modifications not only will take some serious efforts, but will also guarantee you will now 'own' your customizations hence locking you out of any future upgrades to the request features.

The million dollar question is - you are trying to solve a problem for your techs, but what about solving even bigger problems for the business?