Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: LTrethowa
New Today: 24
New Yesterday: 42
Overall: 148210

People Online:
Visitors: 48
Members: 1
Total: 49 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

Note: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


The Itil Community Forum: Forums

ITIL :: View topic - Service Desk - Application Development & Support
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Service Desk - Application Development & Support

 
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk
View previous topic :: View next topic  
Author Message
SweetNov
Newbie
Newbie


Joined: May 08, 2007
Posts: 1

PostPosted: Wed May 09, 2007 1:02 pm    Post subject: Service Desk - Application Development & Support Reply with quote

I'm new to ITIL world, so please patient with my questions.

Background: I am a business analyst and being assigned to ITSM - Service Desk (SD) project recently. My role is to ensure that the processes developed by the Service Desk project team can be used by my department (Application Development & Support)

Currently at my company, when the customers need resources for developing an application, they contact my department directly. My department will assign developer(s), BA(s), PM(s) as needed to complete the application. After the application is implemented in production, customer will continue working directly with the BA to get any issues/bugs resolved. Customers may spend countless hours working directly with us. In short, we have direct contact with the customers.

In ITIL world, it recommends that the customers to contact Service Desk for any request(s). That means the customers can no longer contact my department's staffs directly. It creates a resistant issue from both my department and customers. Customers want to talk to the people who know the business well (app support personnel) and not talk to agents and having to spend extra times explain the issues. The tickets mostly will end up escalating to my department anyway as it requires special knowledge about a certain application. So there seems to be an extra layer if users having to call the SD instead of talking to my department directly.

Questions:
1. How do you implement application solution & support (ADS) at your organization?
2. Is there any best practices for implementing ADS?
3. How do you overcome resistance?
4. My department asks to develop a "Exception Process for handling ADS". Any suggestions on how that exception process should look like?

Your advices are greatly appreciated. Please let me know if I need to clarify anything.
Back to top
View user's profile
dboylan
Senior Itiler


Joined: Jan 03, 2007
Posts: 189
Location: Redmond, WA

PostPosted: Wed May 09, 2007 10:14 pm    Post subject: Re: Service Desk - Application Development & Support Reply with quote

The idea embedded in ITIL is that the Service Desk is the single entry point for End Users into the IT community. If I am an End User I don't have to worry about which phone number to call if the issue is related to an outage (Incident) or if I have a question or IMAC (Install, Move, Add, Change) (Service Request).

But the question about how new features should be requested isn't covered by the Service Support function of the Service Desk. Those requests do not come from End Users. Those requests come from Customers (the individuals who pay for IT services). Communication from Customers go to people in your IT organization who are performing the activities of the Service Level Management process. Most typically the job title of these individuals are Customer Relationship Managers or IT Business Analysts. They take the business requirements from the Customer and approach the needed IT Functional Groups (app dev) with the technical specifications.

It has been said that the people performing the activities of Service Level Management need to be computer engineers with an MBA. This is the group that is capable of speaking to the business in business terms, and talking tech to the technicians. The role of performing the the negotiation between the two groups is part of the Service Level Management process.

You might be the person performing the activity of Service Level Management if you are the contact between the business and the technical team.

I don't know if that specifically answered your questions, but I hope it helps in understanding how Customer/IT interactions can operate outside the Service Desk.
Back to top
View user's profile
officespace
Newbie
Newbie


Joined: May 11, 2007
Posts: 1

PostPosted: Sat May 12, 2007 9:07 am    Post subject: Reply with quote

I am new to ITIL as well but here are my 2 cents.

Once the application goes into production, the actual end users who experience incidents should be directed to the Service Desk so the incident can be logged, initial support provided, and escalated to the appropriate application support team as necessary. A problem or known error record may be opened if there are multiple incidents caused by an application bug. I don't think you would want the end users who use your application to contact you directly without going through the Service Desk, right?

Direct communication between the development/support team and the customer who is paying for the service could still take place to address bugs or new enhancement requests (and Service Level Management could be involved as well). Permanent fixes or new enhancements to the application would still need to go through appropriate Change and Release processes.
Back to top
View user's profile
Fabien
Senior Itiler


Joined: Sep 27, 2005
Posts: 207

PostPosted: Sun May 13, 2007 4:11 am    Post subject: Reply with quote

It actually all depends on the scope of the change you are suggesting. Added features in a report, though it may involve App Dev, would typically come from business users and generally be requested either via the Service Desk, or by a separate communication to the Owner of the service/application. Your Change Management process should route and manage those requests so you have all proper categorization, priorities and approvals.

The process associated in ITIL with the Service Desk places a switch early on to identify request for services, and take another route from Incident Mgt.

Your Service Desk may also be used to get feedback from the user community in a Beta program. I would highly recommend securing a unique/central point of contact for EVERYTHING. What the Service Level Manager will do with customers is business-related. While they should clear some significant requests, they shouldn't be on the phone everyday to discuss the next request for added storage capacity to a storage target. Service Owners should authorize that.
_________________
BR,
Fabien Papleux

Accenture
Technology Consulting | Service Excellence
Red Badge Certified

Twitter @itilgeek
Back to top
View user's profile Send e-mail Visit poster's website MSN Messenger
jpgilles
Senior Itiler


Joined: Mar 29, 2007
Posts: 123
Location: FRance

PostPosted: Sat May 19, 2007 6:34 pm    Post subject: Reply with quote

Hello,

Whether it is a standard request or an RFC this should go via the Service Desk.

One way to fight again the resistance , from my experience, is to make people understand that everytime they call somebody directly:
* that person may already be busy on the phone
* that person may be sitting in a day-long meeting
* that person may be on vacations
* that person may just have moved to a different position
* that may just have left the company
*....
=> there is no guarantee that their request(/query/whatever thay call for) will be treated on time and to the best of the benefits of the company, and that they may spend some valuable time (and company money) just to get a hold on that person
Whereas the Service Desk is just organized to receive their calls , to prioritise them , to route them and to escalate them , no matter who is on duty , and this in the most effective way for the company.

To me , with the exception of direct relationship between the Service Level Managers and the clients , everything should go va the service desk (at least to be logged, checked against predefined format/info, tracked and followed up).

BR
_________________
JP Gilles
Back to top
View user's profile Send e-mail
insider
Newbie
Newbie


Joined: Mar 28, 2007
Posts: 12

PostPosted: Tue May 22, 2007 1:12 am    Post subject: Reply with quote

Dont get the Production and the Development environment world mixed up. Ok;

Once deployed into production, any bugs / production issues etc need to logged via the service desk. The support group is accountable for service and things will just be totally confused if users are going back to the developers directly for 'production' issues they experience (even if they end up with developers for resolution). What happens in projects is a completely different thing and needs its own process.......

You need to explain to the customers / users that things change after a deployment to production; some good reasons have been given already as to why the 'additional layer' is put between the people who will fix the issues and the people who have them- if explained properly then this layer is a benefit rather than a hinderance which it can initially appear
Back to top
View user's profile
jpgilles
Senior Itiler


Joined: Mar 29, 2007
Posts: 123
Location: FRance

PostPosted: Tue May 22, 2007 4:32 am    Post subject: Reply with quote

just to complete my previous post, to be more specific about software issues:

* the person they knew during the development phase may well have moved to another project and is no longer responsible for the now-solution in production.

BR
_________________
JP Gilles
Back to top
View user's profile Send e-mail
Nikhil
Newbie
Newbie


Joined: Mar 21, 2006
Posts: 17
Location: India

PostPosted: Tue May 22, 2007 9:22 pm    Post subject: Define groups Reply with quote

Hi,

Based on my experience, my suggestion would be to define L1, L2 and L3 support groups within your development team for support. So basically, the idea is to separate the development team from the team which will support ongoing issues.

Once this is done, you can then use the incident management and problem management processes for the ongoing issues, which can be directly routed from the service desk to the support teams.

The new changes that you are talking about can be routed to the development team directly through the change management application.

Hope this helps.
_________________
Regards,
Nikhil Kulkarni.
Application Analyst
cMango.. The Services Management Company

The taste of low quality lingers long after the satisfaction of low price.
Back to top
View user's profile MSN Messenger
Nikhil
Newbie
Newbie


Joined: Mar 21, 2006
Posts: 17
Location: India

PostPosted: Tue May 22, 2007 9:26 pm    Post subject: Routing thru service desk Reply with quote

Just to add to my previous response, it will always be a good idea to route all the issues through the central service only. You can explain the end users that it would be helpful for them since they would not need to worry about chasing the right person everytime. Also once the ticket has been assigned to the support engineer, they can communicate directly with him if they need.

You can let your support team know that it would be the best for them , since their work will be more structured once the processes set in.

Thanks.
_________________
Regards,
Nikhil Kulkarni.
Application Analyst
cMango.. The Services Management Company

The taste of low quality lingers long after the satisfaction of low price.
Back to top
View user's profile MSN Messenger
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Wed May 30, 2007 1:04 pm    Post subject: Reply with quote

Hello SweetNov,

Your question is a very good one. The first thing you might want to keep in mind is that ITIL was originally developed to address back-end operational support, with no intent to support front end Product Management/Development processes. The concept that everything should flow through the Service Desk, according to ITIL, is flawed, in that the world is moving toward things like "Self-Serve" models, where end-users can register their own Incidents or Service Requests and have them automatically routed to the appropriate Resources and/or Organizations that will handle them. Like any good business model, you always want to cut out (or at least reduce) the middleman to eliminate as much overhead as possible.

Also, please keep in mind that the Service Desk was never intended to handle large project requests, like what you described. In most enterprises we walk into, that try to provide resources the way you do, they've put in a project management buffer team, that takes project requests, prioritizes them against all other work being done and the pool of resources available and then allocates resources, timeframes, funds, etc., as it makes sense to do so. This is more in line with what is called a "Project Portfolio Management" process, which ITIL fails to cover but which is essential to larger enterprises.

To address requests for your team's services, you may want to go the route of a Service Catalog (not the ITIL V2.0 definition but the traditional defintion, like that of IBM's, which is what ITIL V3.0 is supporting). In this type of a Service Catalog, you list/inventory all of your enterprise's Services, including those that can be "invoked" with intended deliverables and expected times for delivery, so that End-Users and the Service Desk can both go to this Catalog to invoke a Service Request from it. In this case, it doesn't matter whether the End-User comes directly to you, through the catalog or to you through the Service Desk and through the Catalog. Requests will always be captured, with metrics, when invoked through the Service Catalog.

The beauty of a Service Catalog (in the traditional sense) is that you can cleanly start to get metrics about every Service that's inventoried in it and offered through it.

Once you have a Service Catalog in place, all teams can now have work requests routed to them, through it. Believe it or not, this will actually make it easy for most teams to adopt.

However, please keep in mind that there are also other ways to invoke work from Product Management/Development teams, such as new Requirements, defined Risks, identified Problems/Defects, Project-related Tasks, etc. The idea of trying to route all work through one point of interface, such as a Service Desk doesn't scale well, in the long run, and I recommend that you're very careful about trying to make it happen.

Anyhow, I hope this helps.

My Best,

Frank Guerino, CEO
TraverseIT
On-Demand ITIL
Back to top
View user's profile Send e-mail Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
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

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.