Posted: Wed May 09, 2007 1:02 pm Post subject: Service Desk - Application Development & Support
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.
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.
Joined: Jan 03, 2007 Posts: 189 Location: Redmond, WA
Posted: Wed May 09, 2007 10:14 pm Post subject: Re: Service Desk - Application Development & Support
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.
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.
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,
Technology Consulting | Service Excellence
Red Badge Certified
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).
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
Posted: Tue May 22, 2007 9:22 pm Post subject: Define groups
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,
cMango.. The Services Management Company
The taste of low quality lingers long after the satisfaction of low price.
Posted: Tue May 22, 2007 9:26 pm Post subject: Routing thru service desk
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,
cMango.. The Services Management Company
The taste of low quality lingers long after the satisfaction of low price.
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Wed May 30, 2007 1:04 pm Post subject:
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.
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