My business is considering using HP service desk for ERP support. However, we are currently using a home grown support system for end user support which the support teams & end users like.
When performing UAT with the main users of the current system in proposing HPSD, some potentially lareg issues emerged. Primary among them is the seeming lack of collaboration HPSD offers for end users submitting issues. Our current system tracks and logs all response between support people and end users - some complex issues will have 10-15 people working them at once, and collaborating within our current system.
It seems no such functionality exists in HPSD 4.5, which is the GE standard version at the moment. Has anyone else faced issues of collaboration between teams, users, and support when using HPSD and can offer some suggestions?
what version of OVSD are you looking at (4.5 or 5.x).
OVSd 4.5 will end of life at the end fo 2009 and 5.x one year later. There is the new version that has just come to market which is called Service Manager 7. Yoiu can get an eval copy of this now from HP. You might want to also evaluate SM7 as we believe that it can do a lot more in certain areas that OVSD - as it is a different product.
Such functionality DOES exist in SD 4.5. It is called History Lines where both specialist solving the case as well as end users can add their notes, etc. However end users usually do not have access to SD client and just use some WEB front-end like Service Pages provided with SD. You just need to modify these a bit to allow end-user to add History Lines and be able to show them History Lines from support staff. This is pretty easy.
About support being phased out at the end of 2009: that's still 2 years away and I have heard it has been extended already. If you'd be considering Service Manager (which is only re-branded Peregrine Service Center) I would be cautios - the system is too complex, too legacy, too ... Just be sure it is appropriate to what you need to do. If it seems to you that I do not like Peregrine, you're right. It's a mess...
Yes, we looked at the History version of the tool, which was deemed insufficient, since it also shows a lot of "IT jargon" like 'sys admin set priority to P2' etc, which confuses users looking at it through the web portal. I will take a look at some of the other offerings - thanks for the great responses!
As an aside, has anyone ever used this tool for large, global, ERP implementation support for interaction with end users? I would be interested to hear others experiences.
What you say is too much "IT jargon" is something that only administrator of the system sees. Your perception is strange - every complex system has complex settings that end users might not understand. Do not expect any other tool will be simpler regarding administration.
On the example side: we have implemented large WEB trouble ticket application on top of SD that is being used by large staff at telco operator to support its end users.
It may just be our implementation of it that has so much system logging. I know how necessary it is to have such logging systems in place.
At issue is our web-SD integration. Once a user enters a ticket, a support person may respond. If the end user and support person go back and forth, it is all captured in the history portion, but no other log is kept - each update to the end user updated field or the end user information field overwrites the previous text.
Now, if an end user (or third person) wants to view the history of communications, they only have the log, which has interspersed each human communication with system logging information. This makes it unusable for the end user with complex questions. (sometimes there will be 5 log entries between a user update and a request for info, with no visual or other filter for the user)
You mention having a large web presence built on top of SD. What version are you using? It sounds like it may be in our web implementation that we screw up. Do you have an easy way to see communication history using SD?
Now it seems to me I know what your problem is. The History Lines contain 2 kind of records:
1) System - these records contain audit log - i.e. SD adds one line for each audited attribute
2) User - these can be created by end users or support persons and contain whatever you want (whatever they fill in).
What you need to do to get more compact view is only to view User History Lines (those that have the System flag cleared). Also end users do not necessarily need to update Description or Information fields (which in turn gets audited in System History Lines that you probably show). You can provide a form where end users can create new (User) History Lines directly and support can add some (User) history Lines as well. That is efficient way for communication between end users and support staff.
Regarding the TT application: it is built on top of SD 4.5 SP14 and besides Service Calls uses Persons, Organizations, Accounts, Workgroups and SLAs from SD. Another one built on top of the same SD does provisioning of triple play services on fiber network together with workforce management.
Forgot about the communication history: both applications display user (not system!) History Lines on their pages so that person viewing them can see what was going on. It even goes further: the application stores some tags within the text of History Line. This enables (amongst other things) to display types of events - i.e. upon performing some action on the WEB form (for example adding comment or question), specific tag is added to the text of History Line. When it is diplayed, the tag i sread and displayed like:
User1 Added comment: I would like to know....
This even adds to the usability and cleanliness of the application.
Thanks a lot for the input. It sounds like you have a solution that is exactly what I am looking for. Currently, we use a homegrown web front end for end users, and HPSD client app for support persons.
You mention the TT app which I have not heard of. Is this an HP offering? If not, I can work with our in house dev team to use some of the functionality you mention.
One more quick question - is there any issue sending email to those involved in the case (Workgroup/end user) for each update? Currently, our support teams are only notified when a new ticket comes in, but not as updates are supplied or status changed.
The application was developed by us - it is not HP offering. To describe it more it sports these features:
*) Tree-structured service classification - the tickets are classified from tree structure that has 4 levels. Each classification can have its own SLA applied. *) Each classification has different set of questions of various types (text, list of pre-defined values, set of checkboxes, etc. - these can be modified through the administration interface) that creator of the ticket has to fill. These are stored in SD CheckLists *) It is possible to create master tickets - i.e. template where you pre-fill all required questions and when calls come in, you just create a copy of it. Then you have possibilities to automatically close all the copies when closing the master ticket and notify all customers. *) The system has its own e-mail daemon which checks configured e-mail boxes (over POP or POP3S or IMAP or IMAPS) and creates new tickets from individual e-mails. *) There's statistical reporting implemented on the front end for various things - number of calls, SLA, workgroup functioning, etc. *) Various integration to external systems - bi-directional synchronizing tickets to ARS Remedy, sending SMS, sending e-mails, bi-directional integration with bug tracking system, etc... *) The system is implemented as Highly Available - i.e.it is deployed on 2 J2EE servers and the load is balanced between those. Those 2 servers also load balance between 2 SD servers and re-direct to the other if one is unavailable.
Regarding sending e-mail to Workgroup: that is easy. In DB Rule in Send mail action you just need put that Workgroup into To/Cc/Bcc field and SD will send that e-mail to all members of that Workgroup.