Posted: Sat Jul 19, 2008 8:45 am Post subject: Service Requests - theory vs. reality
In theory ITIL Service Requests are basically any request for service.
I've read the discussion from 2005 regarding Service Requests and came away with some good fodder. However, I'd like to ask a simple question.
In reality, which service requests are really not practical to run through the Service Desk?
Our draft IM plan currently lists the following examples.
Requests for information
Batch job requests for a specific purpose
Service extension requests
Operational queries and processing
Requests for information and password resets and such are obvious service requests - as are requests for standard changes. But I'm a bit leery of running procurement requests and such through our Service Desk.
I'm in a data center. Our customers talk to their end users; we talk to our customers' programmers, application administrators, project managers, etc.
Our customers aren't going to ask, "Can we add a couple more gigs of storage to our application?" because if they needed it, our admins would work out the details and put in the RFC. But our customers have said, "We're streaming live video on our website between 9-10 Monday morning, can the NOC please monitor the webservers more closely than usual."
Joined: Oct 07, 2007 Posts: 441 Location: Jakarta, INA
Posted: Sat Jul 19, 2008 6:13 pm Post subject:
To your list:
- Request for Information: Service Desk
- Procurement requests: Procurement Team internally; SLM or CRM externally
- Batch job requests: Service Desk
- Service extension requests: SLM
- Password resets: Service Desk
- Operational queries and processing: Service Desk
- Change requests: Change Management Team internally; SLM or CRM externally
But those are what apply in my company. Might not be the same for others.
Joined: Mar 04, 2008 Posts: 1892 Location: Helensburgh
Posted: Sat Jul 19, 2008 7:49 pm Post subject:
in reality all of your list is appropriate to go through the service desk - or not depending on how you operate.
First benefit: you have one central point at which to track progress against commitment. Therefore you have a complete picture in one place of what any customer is waiting for or might be agitated about.
Second benefit: having a consistent central record of all requests (and their outcomes) that come from your users and customers, helps with the analysis, e.g., for service improvement or service re-alignment programs.
The way to make it work is by passing the request promptly to the right group (e.g. procurement, server admin.) and let them manage and perform the process. They can close the request on your service desk when it has been delivered.
If you have customers and users talking directly to different support and service units it is much more difficult to manage the overall customer relationships. The danger areas include customer authority, prioritizing of work (resource management), duplication, inconsistent delivery. Rigorous procedures are needed to minimize these risks. _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum