Feature Wish List

Jul 15, 2010 at 3:06 AM
I thought I'd start to document the features I'd like to see in a Service Request Management feature.
Jul 15, 2010 at 4:30 AM
Edited Jul 15, 2010 at 5:41 AM

A Service Request is a type of Change, so it need to have scheduling and the option for review activites.

And because a Service Request is customer focused it needs to have requestor information and SLA's like an incident

Jul 15, 2010 at 4:33 AM
Edited Jul 15, 2010 at 5:43 AM

Any type of Request made from the Portal should create a Service Request, not a Change. Changes should be raised by Subject Matter Experts once they have reviewed the request.

So you need to be able to link Changes to Requests

Jul 15, 2010 at 5:16 AM
Edited Jul 15, 2010 at 5:45 AM

Because many Service Requests actually have many related pieces of work, it would be good to have some sort of child object within a service request. For example a new employee request, this might have child obbjects like; Windows Account, Email Account, Laptop, Mobile Phone, Desk patching, Intranet Training.

Are these child objects Work Activities? I guess some of them are. Maybe you can attach Work Activites, Review Activities and Configuration Item Types. Creating a windows account, email account and training are all types of Work Activitites. A new user should be approved so this would be a review activity. And computers, printers, phones etc are all types of configuration items, so you should be able to attach some sort of request for a Configureation Item Type? 

Jul 15, 2010 at 5:19 AM
Edited Jul 15, 2010 at 5:47 AM

Maybe the Self Service portal could allow users to add work activity and configuration item types to a Service Request.

Like adding items to a shopping cart.

I guess the Work Activites would come from a list of Work Activity templates. And review activites could be created from a work flow depending on the type of Request.

Jul 15, 2010 at 5:27 AM

Could you measure the Service level provided for Service Requests?

Perhaps a Service Request category or type could have an SLA, for example the SLA for a new employee request would be the scheduled start date or three days from the request, whichever is longer.

Aug 30, 2010 at 7:14 AM

I see a service request as being a step in front of a change but not necessarily resulting in a change.

It's hard to get your head around the term change when you may be requesting something like a CI's time or information on something, yet those requests need to be logged and related to the CI.

Using a practical example;

- User requests an IT Trainer (CI) for assistance with Powerpoint (CI).

- I don't want to see this referenced as a change (against Powerpoint/Requester/Trainer) because it isn't a change, but it relates to Powerpoint, the specific Trainer and the requester.

There are also manual activities involved (training) and a result (Completed) and it may end up related to some changes (e.g. we discover something needs re-config in Powerpoint).

 

Is this codeplex re-inventing the wheel?

I would have expected to be able to clone almost the entire Change module with a number of modifications, notably the terminology, also remove impact, risk and the planning tab.

If impact, risk and planning needed to be defined then it would be a change not an SR. If we discover that a change has to be subsequently setup, it is linked via Related Items Tab > Work Items.

We would also need to put in a pop-up warning of open WI's if we attempt to close an SR with WI's that are not closed ... but open WI's should not stop the SR from being closed IMHO, just warn.

My 2 cents ......

Aengus