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.

[jcraneNYC]

I'd relate this to an Amazon shopping experience.

The request is your Amazon order. It has an order number, your payment info, your shipping info and other information related to your overall order.

The items are your individual items in your Amazon order. For example, if you ordered 2 books, a monitor and a mouse, those are your items as part of your order.

Each item probably has its own workflow. Some ship from amazon, some ship from other suppliers. These would be the tasks for the items and make up the workflow for each item.

As the customer (or end user) i care about the request and how it pertains to my items. My request (Amazon order # 123456789) tells me what I ordered, my order status for each of my items and how far along I am. The end user gets this exact same view in ServiceNow. If I go in through self service and check the status of a Request, I can see, graphically, the status of my items under my request (the stages of these items are determined by the workflows for the items).

The request can handle maybe an overall approval process if needed (for instance, using the OOB example for approvals on orders over $1000). The items have their own workflows that are required to get the item from ordering through fulfillment. The tasks make up the individual work to complete those workflows.

Does this help at all?

[adamrauh]

Thanks - yes that's pretty much how I understand it as well.

I think the feedback was based more on the tech's end, as there is more overhead in filling out the various fields in the REQ ticket as well as the RITM ticket to drive the process along.

Thx,
Adam

[AdityaTW]

Is the information that they need fill out in the REQ level the same as on the RITM level? You could write a client script or business rule to populate the fields in the REQ record with the information they type in in the RITM record.

Most of our catalog items are worked at the TASK level, not even the RITM level, but we do have some scripts that populate or update certain fields in the parent records (i.e. the RITM level) when the fulfillment teams complete their TASKs. We also have one or two catalog items where the approval level is done at the REQ level - waiting for RITMs to reach a certain state before an approval is requested.

[pilar]

Hi Aditya

Could you provide the client script or business rule to work with REQ level and RITM level?

Thanks

Pilar