Best Practice - Approach for REQ>RITM>TASK - User and Technical resource comments

[Josh80]

Hello All

This issue has 'sort of' been approached by other Community members, but I'm looking for opinions/advice on implementing Service Catalog items.

Scenario:

1 - User submits a Request that has one RITM and 3 Tasks

2 - 3 Tasks have 3 different resource groups

3 - Whom would we set the RITM's 'assigned to'?

4 - If the User must communicate to the resources working the Request, the update goes to the RITM Additional Comments out of box

5-   This does nothing since the 'assigned to' user is not defined (RITM has 3 tasks with 3 different assigned resources)

I could have the RITM update all related tasks with the comments submitted by user.   But then the Resource would have to navigate to the RITM and update the comments there, maybe not such a big deal.

The question is, what do most of you do in regards to the REQ>RITM>TASK structure?   Do you create more than one task from one RITM which would have multiple assignment groups?

Or do you only use One Task per One RITM, or no Task at all?   We could handle it a number of ways..but what works 'best'?

Thanks for reading!

[Uncle Rob]

Don't make arbitrary rules for number of tasks in a RITM.   The RITM is a container for workflow, and a workflow has as many tasks as it needs.

RITMS (typically) are the customer facing abstraction of a consumed workflow.

TASK (typically) are the executor facing abstraction of work within a workflow.

The only oddball part of the equation is REQ, which is a customer facing abstraction of the entire shopping experience.   I understand *why* SN built that layer, I just don't think the concept meshed well with how people actually consume internally.   Here's some things to consider:

• Imagine you go to Costco and you buy a tent, 5 shirts, a bag of rice, and 8 lbs of beef.   When you get home you realize the tent is damaged.   You call up Costco but you can only talk about the sum total of your purchase, and NOT just hte tent.   Now you're explaining to the meat department the nuances of your tent.
• How many times in your environment have people actually consumed more than one RITM in a single REQ?   In 10 years I've seen *ONE* use case (onboarding) and the customers hated the request layer.   They begged us to break it down into component RITMs that they tracked seperately for one new hire.

About the only thing REQ is useful for is cases where an approval is required for a sum total of shopping.   It practically never happens in IT, or even across the enterprise.   Like... in what reality would you need approval if you ordered a laptop and simultaneously submitted a request for benefits renewal and an ergonomic chair?  

I almost always abstract out the REQ layer and work exclusively with RITM and Task.

[Community Alums]

I agree with rfedoruk that you should not be dealing with arbitrary numbers of tasks, but the REQ is one of the rare times I disagree with him. I feel the Costco analogy falls apart because you are in person and have already handled the sourcing of the items you are purchasing by putting them in your physical shopping cart and pushing them to the register (unless you plan to awkwardly carry that 8 pounds of beef and other items around the store).

Because ordering something through the Service Catalog is more like ordering something from Amazon, you've still got that sourcing of the items in the order to deal with. This allows you to separate the sourcing of the items in the order from the setup or preparation of the items for use. Order that tent, a couple books, and a Lego set from Amazon, the system identifies which of their warehouses it makes sense to ship each of those items from.

• With these separate, you use the REQ to handle the sourcing of the item(s). Associate any purchase orders or transfer orders you need to with the request.
• This leaves the workflow for the RITM to handle the provisioning of the specific item at the point it is received before it is given to the requestor: a computer may need the company image, software, or other updates prior to delivery to the user.

With this setup, the sourcing logic can remain separate and generic without being tied to the workflow for each item. I do admit, the REQ can confuse the approval situation in a manner similar to what Robert describes.

The scenario I describe also makes sense for "sourceable" items (those based on Product Models) in ServiceNow, but less sense for non-sourceable items. For non-sourceable items, I agree completely with Robert. The REQ doesn't make much sense.

[jackinsidend]

Robert,

what is your thought on this now, and a viable solution?

We are looking to push task comments to the ritm so they are communicated to the requestor when needed.

The most frequent question I get asked, is why are three tickets created for one thing, I have explained - Req - RITM - Task so many times and I hate doing it. People just want to find the status of their stuff and the three layers are confusing.

Thanks,

jack

[Uncle Rob]

You're right to be frustrated.  I feel like Req-RITM-SCTask didn't survive first contact with teh customer, and has been the dynamic too long to change.

This is why I basically advocate ignoring Request.  In all but the rarest case, it has absolutely no meaninfull workflow, nor meaningful information. 

If I were steering a ship, I'd have a portal interface that fronts RITMS, not REQ (with the exception being order guides).  

This remains one area of the platform I just shake my head and sigh.