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.

[adamrauh]

Everyone's feedback is appreciated - I agree with much of what is being said and think once we do our roll-out many of these questions will be answered for us from a user/tech perspective.

I think the main issue for me was the overhead it is to keep up w/ 2+ records (REQ and +RITM) for "one" 'order', and then figuring out what is an acceptable level of reporting.   We don't run a huge huge shop so most all processes are contained within the same team, to scalabilty does obviously lend itself to the REQ/RITM model.

[AdityaTW]

We do our reporting based on the RITM, not REQ.

[Marc A Love]

We went down this road as well...in our first demo to mgmt we tried to hide the REQ as best as possible by only showing the fulfillers the ITMs and TASKS...but mgmt still didn't like that option...because like you, 90+% of ours are 1 item services (nobody liked the idea of adding 1 "password reset" to a shopping cart and again having 3 records REQ - ITM - TASK created for it)....SO ... we created a sort of change request light we call Service Request.   We created our record producer (to use with CMS) to create the the SR and workflow automatically creates the 1 SRTASK to go with it with info copied.   This leaves the ability to create other SRTASKS manually if needed for the other 10%...but the fulfiller works the SRTASK and closes it, and if its the only SRTASK (the 90%) it automatically closes the SR.   Again, really modeled after Change...mgmt likes it...and pretty easy to manage...

[sgrison]

Completely agreed with Jason.   I would read his comment again.  

One last point - An organization introducing a Service Catalog for the first time should be taking small steps - the catalog is ever developing with adding and removing of services all of the time.   Right now most of your requests are 1 item per request, in the future that may not be the case.   To reiterate what everyone else has been saying - changing the base functionality of the Service Catalog will not only take an incredible amount of development work but it could possibly cause you some painful headaches down the road.

[Jim Coyne]

I agree with Jason, Jon, Sean and others - just hide the Request.   I've done this a number of times for clients, we completely ignore that table and deal just with the Requested Items and Catalog Tasks.   You can show fields from the Request table (requested_for, etc...) on the Requested Item table by simply dot-walking.