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.

[randrews]

if you don't use RITM's you limit your ability to order mutliple items for one person in the future...

a classic example of this is when you decide to move new hires into the service catalog... you will need to order hardware, software, and id's... if you are trying to do this with only a request you will have to keep recreating the items <once to order the item once to order a new hire> if you stick with the oob req-ritm-task flow you will be able to create an order guide and not have to recreate every item

[adamrauh]

To clarify, I wasn't saying don't use RITM's, I was wondering peoples experiences w/ only using RITM's (so, while a cart exists, instead of one REQ w/ multiple RITM's attached to that one REQ, there are just multiple RITM's to work).  

[sgrison]

This is a fairly common scenario.   Organizations move from a tool which contains a single form or interface.   With ServiceNow there are 3 forms/tables as you know:   Request/Requested Item and Catalog tasks.   In the majority of the implementations I've been involved with there is certainly a learning curve, that being said, the user who is fulfilling the request will only work from the catalog task.   Any information which is needed to fulfill the request can be displayed on the catalog task.

In your situation you are not using catalog tasks and users are working directly from the requested item, there should be no reason why they need to navigate to the request to perform their work unless there is something configured or some business reason why they need to.

[adamrauh]

Thanks -

I've reviewed some with my leadership and they want to at least understand the option of directly creating RITM's (not REQ>RITM's) from multiple items in the cart - so are there any default workflows I can use for this?   Even when pointed to the request item table the workflows I've tried create a REQ first (b/c of the cart?), and then subsequently the requested item.   I would want to skirt the REQ, and go directly to one (or multiple) requested items.

[randrews]

while you can probably do this with advanced coding <not recommended upgrades would be a nightmare>

or by using record producers.. why??!

You are looking at adding serious amounts of development time to all catalog items and coding difficulties in order to gain what??

I guess the root question i am asking <and hopefully you are asking them> is what is the return on investment for doing this??

IMHO you should think not once or twice but four or five times before you change OOB behavior and have some serious ROI before you contemplate it... in this case i am having difficulty seeing that ROI...

I understand that a lot of people will state "We need to build to the business requirements" but that is only partially true;   WE as developers are the experts on the Service Now product,   the customers can't be expected to understand that costs involved in changing OOB behavior unless WE inform them of it.   It is up to us to guide the business units and our SR. management in these decisions so that choices we make now don't become unmaintainable in the future.

ok i will step off of my soap box now... bottom line is when you are changing basic OOB behavior step back and ask why many times so that you are doing it for a reason not just because you can.